Issue 1448297: decorator module - Python tracker (original) (raw)
Issue1448297
➜
This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.
This issue has been migrated to GitHub: https://github.com/python/cpython/issues/43021
classification
| Title: | decorator module | ||
|---|---|---|---|
| Type: | Stage: | ||
| Components: | Extension Modules | Versions: | Python 2.5 |
process
| Status: | closed | Resolution: | out of date |
|---|---|---|---|
| Dependencies: | Superseder: | ||
| Assigned To: | Nosy List: | georg.brandl, loewis | |
| Priority: | normal | Keywords: | patch |
Created on 2006-03-12 13:35 by georg.brandl, last changed 2022-04-11 14:56 by admin. This issue is now closed.
| Files | |||
|---|---|---|---|
| File name | Uploaded | Description | Edit |
| decoratormodule.diff | georg.brandl,2006-03-12 13:35 | patch v1 |
| Messages (3) | ||
|---|---|---|
| msg49719 - (view) | Author: Georg Brandl (georg.brandl) *  |
Date: 2006-03-12 13:35 |
| This is a first attempt to a decorator standard module containing only @decorator in a C implementation. | ||
| msg49720 - (view) | Author: Martin v. Löwis (loewis) * |
Date: 2007-02-15 09:41 |
| Why does this implementation have to be in C? I can't see any performance reason - this is all import-time stuff, and not computationally expensive, no? I'm otherwise fine with adding it to 2.6 (perhaps with a reference in the Python implementation where the C version is stored -ie in this issue- in case anybody ever wants to do this in C again). | ||
| msg49721 - (view) | Author: Georg Brandl (georg.brandl) * |
Date: 2007-02-15 10:38 |
| I think this is now outdated anyway with the inclusion of wraps() in functools -- it solves the same problem in a more general way. |
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:56:15 | admin | set | github: 43021 |
| 2006-03-12 13:35:32 | georg.brandl | create |