On Thu, 18 Nov 2004, Phillip J. Eby wrote: > > I think it's important to clarify what this is *for*, and then address > whatever that use case is directly. > Ok. Let's see it from the "programming languages" prespective. In my opinion with the addition of __pycode__ (or __source__ from now on), we have a good emulation of "data is code and code is data", just like machine code. In python we already have "data is code". X='''def f(): pass''' exec X But because of the conversion to bytecode we do not have the "code is data" part (unless we consider code object data). Why is this useful? I think it's one of the benefits of interpreted vs compiled languages.. The real thing would be to attach __source__ to code objects, but I think __source__ in functions and classes only is more realistic. Anyway this is getting too theoretical and we can discuss it forever on 'what is and what isn't code and data'.. As I said before: This *can* already be done in python as it is by writing some kind of framework/IDE (Zope, Plone, IDLE, ipython,whatever). With __source__ though, python becomes a framework, we achieve this with the minimum overhead and we are sure it will work with all cases (interactive/exec) and all future extensions. On the issue of saving __source__ to .pyc files, I'm 50-50. I'd vote for -0. Also I'd vote +1 for a command line option which if specified __source__ will be generated for *all* functions/classes (not only interactively defined). Now I will go see about a PEP so that we can stop referring to it as "it" and say "PEP xxx":) Stelios
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