Re: [Python-Dev] PEP: __source__ proposal
[Stelios Xanthakis Fri, Dec 03, 2004 at 11:59:30PM +0200] > On Fri, 3 Dec 2004, holger krekel wrote: > >We are about to test out this approach with the py lib > >(http://codespeak.net/py) and want to have it work for > >for Python 2.2, 2.3. and 2.4. > > Do you plan hacking python ? > It appears that tok_nextc() is the best place to > catch all the source passed to the interpreter. Well, as we want to have the library work on past python versions modifying CPython 2.5 does not make much sense. It's more about (like Martin pointed out) organizing dynamic code generation so that Python's introspect and traceback logic works as much as possible - with tiny runtime "monkey" patches if needed. Now Martin also correctly pointed out that you can store source code before/after you pass it to compile/parse. We are doing this already with an external dictionary. This has multithreading issues, though. So we think that hooking onto code's objects co_filename or a module's __file__ might be an interesting idea. cheers, holger ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: __source__ proposal
I'm opposed to this idea. It creates overhead in the size of .pyc files, No it doesn't. for no additional value that couldn't be obtained otherwise. Martin: I know it is possible to do all this with existing python facilities. I did write such a dynamic code framework in python. Specifically I used a function 'deyndef(code)' which was exactly like 'def' but also stored the source string in a dictionary. The key point is that I think think should be the job of the parser and the functionality provided at the interactive prompt w/o the user having to write 'dyndef' or store the code of exec's or request from himself to use specific commands to create functions. It should be transparent built into python. A file is precisely the level of granularity that is burnt into the Python language. A module is *always* a file, executed from top to bottom. It is not possible to recreate the source code of a module if you have only the source code of all functions, and all classes. That's exactly the rationale for NOT combining __source__ with import. It's in the PEP. It appears that there are the 'module people' who find this feature irrelevant. Indeed. If we are interested in distributing modules and increasing the number of people who use python programs,then __source__ is redundant. OTOH, programming python is easy and fun and I think the proposed feature will make it even more fun and it aims in increasing the number of people who program python for their every day tasks. It'd be interesting to hear if the developers of IDLE/ipython/etc could use this. Oh well. I guess I'm ahead of my time again:) St. ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_shutils.py fails for 2.4 install
"Edward C. Jones" <[EMAIL PROTECTED]> writes: > I have a PC with an AMD cpu and Mandrake 10.1. While installing Python > 2.4 "make test" failed in "test_shutils.py". Here is the output of > "./python ./Lib/test/test_shutil.py": Are you running 'make test' as root? Don't do that (although possibly the test suite should guard against it). Also, did you search the bug tracker? Please do do that. Cheers, mwh -- CDATA is not an integration strategy. -- from Twisted.Quotes ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: __source__ proposal
Stelios Xanthakis wrote:
The key point is that I think think should be the
job of the parser and the functionality provided
at the interactive prompt w/o the user having to
write 'dyndef' or store the code of exec's or request
from himself to use specific commands to create
functions. It should be transparent built into python.
For the case of the interactive prompt, if preserving
the source code is somehow desirable (which I doubt),
it should be the job of the development environment
to offer saving interactively-defined methods.
Such IDE support is necessary even if __source__ was
available, since users probably would not want to write
open("demo.py").write(myfunc.__source__ + "\n" + myclass.__source)
OTOH, programming python is easy and fun and I think
the proposed feature will make it even more fun and it
aims in increasing the number of people who program
python for their every day tasks. It'd be interesting to
hear if the developers of IDLE/ipython/etc could use this.
I think it is the other way 'round. If this is *only* for
interactive mode, than you should *first* change the interactive
environments. If you then find you absolutely need this feature
to implement the IDEs correctly, I'd like to hear the (new)
rationale for the change.
Regards,
Martin
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: __source__ proposal
[Resend, since a minor brain explosion caused me to send this to c.l.p instead
of python-dev]
Stelios Xanthakis wrote:
It appears that there are the 'module people' who
find this feature irrelevant. Indeed. If we are interested
in distributing modules and increasing the number of
people who use python programs,then __source__ is redundant.
OTOH, programming python is easy and fun and I think
the proposed feature will make it even more fun and it
aims in increasing the number of people who program
python for their every day tasks. It'd be interesting to
hear if the developers of IDLE/ipython/etc could use this.
The feedback here (and the initial response on py-dev a while back)
suggests to
me that you should look at making this a feature of the interactive mode.
Something that affects both Python's main interactive shell, plus the relevant
class in the standard library (CommandInterpreter or whatever it is called).
A late-night-train-of-thought example of what might be handy is below - keep in
mind that I haven't looked at what enhanced Python shells like IPython can do,
so it may be there are tools out there that do something like this already. It
would be handy to have a standard library module that supported "on-the-fly"
editing, though (this capability would then be available to anyone embedding
Python as a scripting engine).
Cheers,
Nick.
==
import source
class bob:
... def mary():
...pass
... def tim():
...print 'Tim'
...
print bob.__source__
class bob:
def mary():
pass
def tim():
print 'Tim'
print bob.mary.__source__
def mary():
pass
source.edit(bob.mary)
bob.mary(1)>def mary(text): # [1]
bob.mary(2)> print "Mary:", text
bob.mary(3)>\save
source.edit(bob.tim)
bob.tim(1)>\help
Commands: \help \cancel \save \deleteline
bob.tim(2)>\cancel
print bob.__source__
"class bob:
def mary(text):
print "Mary:", text
def tim():
print 'Tim'
"
bob().mary("Hi!")
Mary: Hi!
The basic ideas of the above:
"import source" triggers the storage of the __source__ attributes (e.g. via
installation of appropriate hooks in the class and function definition process)
The 'edit' function is then able to take advantage of the stored source code to
present each line of the original source for modification (e.g. to fix a minor
bug in one function of a class definition). When the 'edit' is complete, it can
be saved or cancelled.
1. The feature mentioned in the last paragraph is hard to show in the expected
output :)
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: [Python-checkins] python/dist/src/Lib whrandom.py, 1.21, NONE
[EMAIL PROTECTED] > Removed Files: >whrandom.py > Log Message: > Remove the deprecated whrandom module. Woo hoo! It's about friggin' time . ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RE: test_shutils.py fails for 2.4 install
The relevant bug appears to be 1076467 at SourceForge. ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Py2.5: Deprecated Cookie classes and interface
Any objections to removing Cookie.Cookie, Cookie.SmartCookie, and Cookie.SerialCookie? Raymond ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deprecated xmllib module
Hmph. The xmllib module has been deprecated since Py2.0 but is not listed in PEP 4. Question: Do we have to keep it for another two years because of that omission? It seems somewhat silly to keep an obsolete, supplanted module that doesnt full support XML 1.0. Raymond ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Deprecated xmllib module
Raymond Hettinger wrote: > Hmph. The xmllib module has been deprecated since Py2.0 but is not > listed in PEP 4. > > Question: Do we have to keep it for another two years because of that > omission? > > It seems somewhat silly to keep an obsolete, supplanted module that > doesn't full support XML 1.0. it's better to be somewhat silly than to be arrogant and stupid. if python-dev cares about existing users, xmllib should stay in there until 3.0. ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Any reason why CPPFLAGS not used in compiling?
I noticed that Makefile.pre.in uses the value from the environment variable LDFLAGS but not CPPFLAGS. Any reason for this? ``./configure -h`` lists both (and some other environment variables which are not really used either) so it seems a little misleading to have those listed but to not utilize them. The reason I ask is I plan on having setup.py add the directories specified in both of these environment variables for compiling the extension modules. It would be nice to be able to use the same values as used by the Makefile to build the core, but I can if I must just get the values directly from the environment variables themselves. This should allow for the removal of the direct support for Fink and DarwinPorts. It should also remove any hand-editing needed to get setup.py to pick up any non-standard library and header locations. -Brett ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
