At 04:14 PM 11/18/04 +0200, Stelios Xanthakis wrote: >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. [snip lots of explanation] Your explanation still hasn't answered the question of what you plan to *do* with __source__. Absent that, there are no criteria for making design decisions regarding the implementation. >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). In the absence of use cases, this is an argument for *not* making a change to the Python core. >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). And I'd vote differently on both these matters. Please state what your use cases are, so that solutions can be evaluated on the basis of what use cases they satisfy, not merely votes without any context. >Now I will go see about a PEP so that we can stop referring >to it as "it" and say "PEP xxx":) Please take especial care to include in the Motivation section what *specific* use cases this is intended to address. So far the *only* use case you have presented is saving functions that were entered interactively, but this can be accomplished in far less controversial ways.
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