Stelios Xanthakis wrote: > > Hi. > > > I posted a message on c.l.p a couple of days ago about a > python patch which adds a member __pycde__ to functions and > classes. This member is a string which holds the python code of > the function/class. (It works in interactively defined code > and exec'd definitions) I think this is a potentially interesting idea, but one worth taking through the PEP process for 2.5. This would have the benefit of clearly identifying the gains provided by the feature, and also identifying potential downsides to be addressed. The number one downside I can see (beyond the extra memory consumed) is the bloating effect on pyc files - for this to work, the compiled bytecode is going to have to contain the original source code as strings. Instead of pyc files being smaller than the originals, they will suddenly be larger (roughly the current size of the py file added to the current size of the pyc file). This may also impact the time required to parse the pyc files at import time - potentially slowing the startup time of the Python interpreter itself, as well as Python applications (a trend in exactly the *wrong* direction). Also, Python does get used in embedded environments, so memory and filesystem space considerations do need to be addressed. One option would be an addition to coflags that is off by default - then the feature could be selectively enabled by an application without impacting normal operation. Cheers, Nick. -0, but willing to be persuaded otherwise (hence, PEP) -- Nick Coghlan | Brisbane, Australia Email: ncoghlan at email.com | Mobile: +61 409 573 268
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4