Re: [Python-Dev] GSoC Student Introduction, again
2008/5/8 "Martin v. Löwis" <[EMAIL PROTECTED]>: >> Regarding the project, I expect it to be integrated into Python's >> stdlib sometime in the future, I believe it will be in very good shape >> before binaries compiled against tcl/tk 8.5 start showing up. > > Actually, I would like to release Python 2.6 and 3.0 on Windows with Tk > 8.5 included, preferably starting at the next betas. Would you see a > problem with that? > I've already wrapped all the Ttk functionality by now, and I will complete the documentation till the first betas. But as you know there isn't much people using (I know myself and a Tcl guy) so I'm not sure if it would be acceptable to include this module right into these betas, or would it be ? Should I start doing something more/else ? > Regards, > Martin > > Thanks, -- -- Guilherme H. Polo Goncalves ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r62848 - python/trunk/Objects/setobject.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 8, 2008, at 12:35 AM, raymond.hettinger wrote: Author: raymond.hettinger Date: Thu May 8 06:35:20 2008 New Revision: 62848 Log: Frozensets do not benefit from autoconversion. Since the trunk buildbots appear to be mostly happy (well those that are connected anyway), and because I couldn't get the releases out last night, I'll let this one slide. I'd like to find a way to more forcefully enforce commit freezes for the betas though. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCLk2nEjvBPtnXfVAQJxiwP/VPTmeKVLoKkc/xIF0tc/lb6pT7kZ0swL b1M2TUkl/+xOuKf3J2EIkHOiKdNNmivl80nG/wP9/VTa7lVJGnWgIeLi0yC20Q9n wvtHaXCrHDc4/ibiShjwYqD4YR0BGwJI7BrlyCYzohbjFK6QYsxd+5a96Cipb/cB +K/Akjqry4Q= =xQfb -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r62848 - python/trunk/Objects/setobject.c
On Thu, May 8, 2008 at 6:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > Since the trunk buildbots appear to be mostly happy (well those that are > connected anyway), and because I couldn't get the releases out last night, > I'll let this one slide. I'd like to find a way to more forcefully enforce > commit freezes for the betas though. I wonder if you couldn't alter the server side commit hook to reject everything with the message "Sorry, we're in a freeze." (You'd have to make an exception for yourself.) -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r62848 - python/trunk/Objects/setobject.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 8, 2008, at 7:54 AM, Benjamin Peterson wrote: On Thu, May 8, 2008 at 6:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: Since the trunk buildbots appear to be mostly happy (well those that are connected anyway), and because I couldn't get the releases out last night, I'll let this one slide. I'd like to find a way to more forcefully enforce commit freezes for the betas though. I wonder if you couldn't alter the server side commit hook to reject everything with the message "Sorry, we're in a freeze." (You'd have to make an exception for yourself.) This is exactly what I'm thinking about! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCLrNnEjvBPtnXfVAQITDwP/WGqlRHSfvE668clPM3gshhYbAapZcF+e mNKGwu407/q03LYRqHr2QY0gBxsySJBWl5OsozmJUOTc7NEY/E/MtiauauzCJiyO 24sJ2V52aROwYBLG+4tLFcaGmWmnsWPg79Qj/yJQKMMiH5OznPfagLECOjlwDZZA ianWqOZxeYc= =xyD7 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
Jeremy Hylton wrote: On Wed, May 7, 2008 at 11:43 AM, Thomas Lee <[EMAIL PROTECTED]> wrote: Nick Coghlan wrote: As Thomas mentions in a later message, making it possible to annotate nodes would permit Functions to be annotated as being a generator at the AST stage (currently it is left to the bytecode compiler's symtable generation pass to make that determination). Although I guess an alternative solution to that would be to have separate AST nodes for Functions and Generators as well... I've actually backtracked a little and gone back down the Const path again. I know this is the third time I've changed my mind, but it's primarily because annotations tend to get a little clunky (or my implementation was, at least). Using Const nodes feels a lot more natural inside the optimizer. I think it's going to stick, at least in the short term. Rather than separate FunctionDef and GeneratorDef nodes, I think a new bool attribute (is_generator?) on FunctionDef should do the job nicely. Further, I'm thinking we can move the "generator detection code" from the symtable into Python/ast.c so the generator/function information is available to the optimizer. Does the optimizer run after the symtable? I'd expect the symbol table information to be essential for almost all analysis, so it should be fine to wait until that pass to mark the generators. There are a lot of micro-optimisations that are actually context independent, so moving them before the symtable pass should be quite feasible - e.g. replacing "return None" with "return", stripping dead code after a return statement, changing a "if not" statement into an "if" statement with the two suites reversed, changing "(1, 2, 3)" into a stored constant, folding "1 + 2" into the constant "3". I believe the goal is to see how many of the current bytecode optimisations can actually be brought forward to the AST generation stage, rather than waiting until after the bytecode symtable calculation and compilation passes. The current structure goes: tokenisation->AST construction->symtable construction->bytecode compilation->bytecode optimisation My understanding of what Thomas is trying to do is to make it look more like this: tokenisation->AST construction->AST optimisation->symtable construction->bytecode compilation There may still be a direct bytecode optimisation step left at the end if it turns out something relies on information that isn't worked out until the symtable construction pass (and that can't easily be worked out earlier, such as adding an 'is_generator' flag to the FunctionDef AST node). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r62848 - python/trunk/Objects/setobject.c
Barry Warsaw schrieb: > This is exactly what I'm thinking about! -1 A technical solution never solves a social problem. It's just going to cause more social and technical problems. All community members with svn write privileges must subscribe to the Python developer list. Committers must check the lists prior to a check in if a release is immanent. Releases are announced at least four days prior to svn freeze so it's not going to be a problem. The problem often lies with occasional committers and maintainers of stdlib packages. People need to show more discipline or eventually we have to (temporarily) revoke their privileges. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
On Thu, May 8, 2008 at 8:00 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Jeremy Hylton wrote: > > > On Wed, May 7, 2008 at 11:43 AM, Thomas Lee <[EMAIL PROTECTED]> wrote: > > > > > Nick Coghlan wrote: > > > > > > > > > > As Thomas mentions in a later message, making it possible to annotate > > > > > > > nodes would permit Functions to be annotated as being a generator at the > AST > > > stage (currently it is left to the bytecode compiler's symtable > generation > > > pass to make that determination). > > > > > > > Although I guess an alternative solution to that would be to have > separate > > > > > > > AST nodes for Functions and Generators as well... > > > > > > > > > > > > > > I've actually backtracked a little and gone back down the Const path > again. > > > I know this is the third time I've changed my mind, but it's primarily > > > because annotations tend to get a little clunky (or my implementation > was, > > > at least). Using Const nodes feels a lot more natural inside the > optimizer. > > > I think it's going to stick, at least in the short term. > > > > > > Rather than separate FunctionDef and GeneratorDef nodes, I think a new > bool > > > attribute (is_generator?) on FunctionDef should do the job nicely. > Further, > > > I'm thinking we can move the "generator detection code" from the > symtable > > > into Python/ast.c so the generator/function information is available to > the > > > optimizer. > > > > > > > Does the optimizer run after the symtable? I'd expect the symbol > > table information to be essential for almost all analysis, so it > > should be fine to wait until that pass to mark the generators. > > > > There are a lot of micro-optimisations that are actually context > independent, so moving them before the symtable pass should be quite > feasible - e.g. replacing "return None" with "return", stripping dead code > after a return statement, changing a "if not" statement into an "if" > statement with the two suites reversed, changing "(1, 2, 3)" into a stored > constant, folding "1 + 2" into the constant "3". > > I believe the goal is to see how many of the current bytecode optimisations > can actually be brought forward to the AST generation stage, rather than > waiting until after the bytecode symtable calculation and compilation > passes. > > The current structure goes: > > tokenisation->AST construction->symtable construction->bytecode > compilation->bytecode optimisation > > My understanding of what Thomas is trying to do is to make it look more > like this: > > tokenisation->AST construction->AST optimisation->symtable > construction->bytecode compilation > > There may still be a direct bytecode optimisation step left at the end if > it turns out something relies on information that isn't worked out until the > symtable construction pass (and that can't easily be worked out earlier, > such as adding an 'is_generator' flag to the FunctionDef AST node). The symbol table pass is not important for deciding where to place the optimizations. Either the optimization operates on the AST itself, in which case it needs to run before bytecode compilation or it operators on the lowered bytecode representation, in which case it needs to run after bytecode compilation. Since the symbol table passes doesn't change the representation, you ought to be able to put the optimizations before or after it. But I haven't looked closely at the actual code, so maybe I'm missing something. Jeremy > > > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r62848 - python/trunk/Objects/setobject.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 8, 2008, at 8:21 AM, Christian Heimes wrote: Barry Warsaw schrieb: This is exactly what I'm thinking about! -1 A technical solution never solves a social problem. It's just going to cause more social and technical problems. In this case I disagree. Given our global nature and the vast amounts of email we all get, I think a friendly little svn commit hook reminder is a simple and workable solution. This commit lock really doesn't need to be in place for very long. Optimistically, I only need it long enough to create the tags, which /normally/ should take me 10 minutes. All community members with svn write privileges must subscribe to the Python developer list. Committers must check the lists prior to a check in if a release is immanent. Releases are announced at least four days prior to svn freeze so it's not going to be a problem. The problem often lies with occasional committers and maintainers of stdlib packages. People need to show more discipline or eventually we have to (temporarily) revoke their privileges. Or aggressively back out any changes from freeze time to tag time. If we don't add the commit hook lock, I will be very strict about this come the betas. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCL+KnEjvBPtnXfVAQIkxgQAqXXwZjHyI93L1xEvrIPYGkTugxlgEva/ bj9ip59XqB6EYS8NnciJU29WZhcc3WnEoOsdWk7qwYV0qOc2YOgYh775GF4Q2S/A 5qVw+oePFIGCWMhezVG/JYph8V6T0QL36hhgd78WqBJKa2C7IpKEjh3HATwY8DQL nouyqdmIDJo= =Vohh -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] [Python-checkins] r62848 - python/trunk/Objects/setobject.c
Christian Heimes wrote: Barry Warsaw schrieb: This is exactly what I'm thinking about! -1 A technical solution never solves a social problem. It's just going to cause more social and technical problems. All community members with svn write privileges must subscribe to the Python developer list. Committers must check the lists prior to a check in if a release is immanent. Releases are announced at least four days prior to svn freeze so it's not going to be a problem. The problem often lies with occasional committers and maintainers of stdlib packages. People need to show more discipline or eventually we have to (temporarily) revoke their privileges. It's actually the time zone issues that get me in relation to code freezes... so I just try to avoid committing anything for a day or two :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] [Python-checkins] r62848 - python/trunk/Objects/setobject.c
On Thu, May 8, 2008 at 8:20 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > Or aggressively back out any changes from freeze time to tag time. If we > don't add the commit hook lock, I will be very strict about this come the > betas. I know this way is fairly entrenched in the python release process, but it sounds like it's using the tools incorrectly. In particular with subversion is very easy (compared to cvs) to branch and to switch branches locally. Why not create a new prerelease branch at the beginning of freeze and only merge in the critical changes? This way only the release manager need know or care about the branch, and nobody else has to really modify his behavior. Then tag, move, and/or delete the branch as desired. The obvious stumbling blocks include buildbots not following the new branch (this could be a blocker), and release scripts possibly needing modifications if they contain direct svn url references. -- Michael Urman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Freeze lifted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've created the tags for 3.0a5 and 2.6a3, and the tarballs look good, so I'm lifting the commit freeze for these two branches. Thanks everyone, and look for the release announcements in a little while. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCMFYXEjvBPtnXfVAQKwyAP/bVnUtGzHMaJcwdc6BZR+kZJ0M22k/Vbp Nk1IfPts3HPKC7cNWzEkpWlqeXnGC0piuqDGrv2igY2Ori7LVMaTOea1xj8L1KqA QxiSHT0qtkW9J/io/q3Vw4cdXjshUQahSVPL2upafmCF1ROGDM0IKODq6kzjxgGV I8XI4BciN20= =NIY+ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r62848 - python/trunk/Objects/setobject.c
On Thu, 8 May 2008 10:21:54 pm Christian Heimes wrote: > Barry Warsaw schrieb: > > This is exactly what I'm thinking about! > > -1 > > A technical solution never solves a social problem. It's just going > to cause more social and technical problems. That's certainly not true. The social problem of people throwing their "night soil" out into the streets had a technical solution, namely sewerage systems. Or if you prefer a more computer-related example, the social problem of having people on a shared computer have access to files you don't want them to have access to is solved by the technical solution of file permissions and ACLs. I have no opinion on this specific problem, but it is equally fallacious to say that social problems_never_ have technical solutions as it is to say that they _always_ have technical solutions. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] [Python-3000] r62848 - python/trunk/Objects/setobject.c
On Thu, May 08, 2008 at 11:23:11PM +1000, Nick Coghlan wrote: > It's actually the time zone issues that get me in relation to code > freezes... so I just try to avoid committing anything for a day or two :) Subscribers to the python-dev digests may also not see a posting immediately, waiting until the next digest is sent. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] [Python-checkins] r62848 - python/trunk/Objects/setobject.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 8, 2008, at 9:41 AM, Michael Urman wrote: On Thu, May 8, 2008 at 8:20 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: Or aggressively back out any changes from freeze time to tag time. If we don't add the commit hook lock, I will be very strict about this come the betas. I know this way is fairly entrenched in the python release process, but it sounds like it's using the tools incorrectly. In particular with subversion is very easy (compared to cvs) to branch and to switch branches locally. Why not create a new prerelease branch at the beginning of freeze and only merge in the critical changes? This way only the release manager need know or care about the branch, and nobody else has to really modify his behavior. Then tag, move, and/or delete the branch as desired. The obvious stumbling blocks include buildbots not following the new branch (this could be a blocker), and release scripts possibly needing modifications if they contain direct svn url references. I definitely think we'd want the buildbots to track the release branches, and it's a bit of a pain to get the release scripts to deal with the svn switches. Right now I think the freeze window is pretty short (barring unforeseen networking snafus) that it's not worth it. However, once the release process is smooth enough, maybe this little freeze hiccup will be worth eliminating. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCMNEHEjvBPtnXfVAQIDogP+NVpyE7AhUS1Eerqv/N+ERTuKnmy/rSNQ wQhOlAxlvx/lPgm0Mi70C9cA60ogxwGE+nJPf0RQxN2bVfhE/+fvElRl9x7xuoo3 wAK6/zzItqMCP4bpaT8sbsqn4tPB4OCKr0eM/SgZMxrHZkHHZwLTVAw81h40Fmr3 A30V6JpZpdU= =q3uu -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] [Python-3000] r62848 - python/trunk/Objects/setobject.c
On Thu, May 08, 2008, A.M. Kuchling wrote: > On Thu, May 08, 2008 at 11:23:11PM +1000, Nick Coghlan wrote: >> >> It's actually the time zone issues that get me in relation to code >> freezes... so I just try to avoid committing anything for a day or two :) > > Subscribers to the python-dev digests may also not see a posting > immediately, waiting until the next digest is sent. Heck, I'm not on the digest and I still have been seeing posts after a week (though that's the fault of a balky mailserver that should be fixed). -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Help a hearing-impaired person: http://rule6.info/hearing.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 370 extras
I'm working on some extra cool and useful additions to PEP 370. It's going to make compilation and usage of custom libraries very easy. Sit back and watch the slide show. :) The site module has two new options. The --user-base option prints the path to the user base directory to stdout. $ ~/dev/python/trunk/python -m site --user-base /home/heimes/.local I install libxslt-1.1.19 into my ~/.local directory. libxslt-1.1.19$ ./configure --prefix `~/dev/python/trunk/python -m site --user-base` libxslt-1.1.19$ make libxslt-1.1.19$ make install ... test -z "/home/heimes/.local/lib" || mkdir -p -- "/home/heimes/.local/lib" /bin/bash ../libtool --mode=install /usr/bin/install -c 'libxslt.la' '/home/heimes/.local/lib/libxslt.la' /usr/bin/install -c .libs/libxslt.so.1.1.19 /home/heimes/.local/lib/libxslt.so.1.1.19 Now I compile lxml against the libraries and include directories in ~/.local. But first I have to add ~/.local/bin to PATH so lxml picks up the right xslt-config binary. $ export PATH=~/.local/bin:$PATH lxml-1.3.6$ ~/dev/python/trunk/python setup.py build_ext --user Building lxml version 1.3.6-8122 setupinfo.py:137: DeprecationWarning: os.popen3 is deprecated. Use the subprocess module. wf, rf, ef = os.popen3(cmd) /home/heimes/dev/python/trunk/Lib/distutils/dist.py:263: UserWarning: Unknown distribution option: 'zip_safe' warnings.warn(msg) running build_ext building 'lxml.etree' extension creating build creating build/temp.linux-i686-2.6-pydebug creating build/temp.linux-i686-2.6-pydebug/src creating build/temp.linux-i686-2.6-pydebug/src/lxml gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -fPIC -I/home/heimes/.local/include -I/usr/include/libxml2 -I/home/heimes/dev/python/trunk/Include -I/home/heimes/dev/python/trunk -I/home/heimes/.local/include -c src/lxml/etree.c -o build/temp.linux-i686-2.6-pydebug/src/lxml/etree.o -w creating build/lib.linux-i686-2.6-pydebug creating build/lib.linux-i686-2.6-pydebug/lxml gcc -pthread -shared build/temp.linux-i686-2.6-pydebug/src/lxml/etree.o -L/home/heimes/.local/lib -L/home/heimes/.local/lib -Wl,-R/home/heimes/.local/lib -lxslt -lexslt -lxml2 -lz -lm -o build/lib.linux-i686-2.6-pydebug/lxml/etree.so building 'lxml.objectify' extension gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -fPIC -I/home/heimes/.local/include -I/usr/include/libxml2 -I/home/heimes/dev/python/trunk/Include -I/home/heimes/dev/python/trunk -I/home/heimes/.local/include -c src/lxml/objectify.c -o build/temp.linux-i686-2.6-pydebug/src/lxml/objectify.o -w gcc -pthread -shared build/temp.linux-i686-2.6-pydebug/src/lxml/objectify.o -L/home/heimes/.local/lib -L/home/heimes/.local/lib -Wl,-R/home/heimes/.local/lib -lxslt -lexslt -lxml2 -lz -lm -o build/lib.linux-i686-2.6-pydebug/lxml/objectify.so building 'lxml.pyclasslookup' extension gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -fPIC -I/home/heimes/.local/include -I/usr/include/libxml2 -I/home/heimes/dev/python/trunk/Include -I/home/heimes/dev/python/trunk -I/home/heimes/.local/include -c src/lxml/pyclasslookup.c -o build/temp.linux-i686-2.6-pydebug/src/lxml/pyclasslookup.o -w gcc -pthread -shared build/temp.linux-i686-2.6-pydebug/src/lxml/pyclasslookup.o -L/home/heimes/.local/lib -L/home/heimes/.local/lib -Wl,-R/home/heimes/.local/lib -lxslt -lexslt -lxml2 -lz -lm -o build/lib.linux-i686-2.6-pydebug/lxml/pyclasslookup.so lxml-1.3.6$ ~/dev/python/trunk/python setup.py install --user ... As you can see etree.so is going to load my local libxslt library instead of the system one. $ ldd /home/heimes/.local/lib/python2.6/site-packages/lxml/etree.so linux-gate.so.1 => (0xb7fc5000) libxslt.so.1 => /home/heimes/.local/lib/libxslt.so.1 (0xb7e89000) libexslt.so.0 => /home/heimes/.local/lib/libexslt.so.0 (0xb7e78000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7d3d000) libz.so.1 => /usr/lib/libz.so.1 (0xb7d28000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d03000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7ceb000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b9c000) libgcrypt.so.11 => /lib/libgcrypt.so.11 (0xb7b4e000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7b4a000) /lib/ld-linux.so.2 (0xb7fc6000) libgpg-error.so.0 => /lib/libgpg-error.so.0 (0xb7b46000) Comments? :) Christian ___ Python-Dev mailing list Python-Dev@python.org 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 370 extras
On Fri, May 9, 2008 at 12:05 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > I'm working on some extra cool and useful additions to PEP 370. It's > going to make compilation and usage of custom libraries very easy. Sit > back and watch the slide show. :) > > The site module has two new options. The --user-base option prints the > path to the user base directory to stdout. > What is the second option? And BTW, I wish we had this in 2.5 since I could finally install packages that can be used by both the OS X Python installation as well as my own build. =) This will be a handy feature once it is in a widely distributed version of Python. -Brett ___ Python-Dev mailing list Python-Dev@python.org 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 370 extras
Brett Cannon schrieb: > On Fri, May 9, 2008 at 12:05 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: >> I'm working on some extra cool and useful additions to PEP 370. It's >> going to make compilation and usage of custom libraries very easy. Sit >> back and watch the slide show. :) >> >> The site module has two new options. The --user-base option prints the >> path to the user base directory to stdout. >> > > What is the second option? --user-site $ ~/dev/python/trunk/python -m site --help /home/heimes/dev/python/trunk/Lib/site.py [--user-base] [--user-site] Without arguments print some useful information With arguments print the value of USER_BASE and/or USER_SITE separated by ':'. Exit codes with --user-base or --user-site: 0 - user site directory is enabled 1 - user site diretory is disabled by user 2 - uses site directory is disabled by super user or for security reasons >2 - unknown error ___ Python-Dev mailing list Python-Dev@python.org 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 370 extras
On Fri, May 9, 2008 at 12:30 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: > > > On Fri, May 9, 2008 at 12:05 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > >> I'm working on some extra cool and useful additions to PEP 370. It's > >> going to make compilation and usage of custom libraries very easy. Sit > >> back and watch the slide show. :) > >> > >> The site module has two new options. The --user-base option prints the > >> path to the user base directory to stdout. > >> > > > > What is the second option? > > --user-site > Ah, OK. > $ ~/dev/python/trunk/python -m site --help > /home/heimes/dev/python/trunk/Lib/site.py [--user-base] [--user-site] > > Without arguments print some useful information > With arguments print the value of USER_BASE and/or USER_SITE separated > by ':'. > > Exit codes with --user-base or --user-site: > 0 - user site directory is enabled > 1 - user site diretory is disabled by user Typo: missing a "c" in "directory". > 2 - uses site directory is disabled by super user > or for security reasons > >2 - unknown error > > Yeah, they should both be useful for various path-related stuff. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
Nick Coghlan wrote: There are a lot of micro-optimisations that are actually context independent, so moving them before the symtable pass should be quite feasible - e.g. replacing "return None" with "return", stripping dead code after a return statement, changing a "if not" statement into an "if" statement with the two suites reversed, changing "(1, 2, 3)" into a stored constant, folding "1 + 2" into the constant "3". I believe the goal is to see how many of the current bytecode optimisations can actually be brought forward to the AST generation stage, rather than waiting until after the bytecode symtable calculation and compilation passes. That's been the aim so far. It's been largely successful with the exception of a few edge cases (most notably the functions vs. generator stuff). The elimination of unreachable paths (whether they be things like "if 0: ..." or "return; ... more code ...") completely breaks generators since we might potentially be blowing away "yield" statements during the elimination process. The rest of the optimizations, as far as I can see, are much less scary. The current structure goes: tokenisation->AST construction->symtable construction->bytecode compilation->bytecode optimisation My understanding of what Thomas is trying to do is to make it look more like this: tokenisation->AST construction->AST optimisation->symtable construction->bytecode compilation That's exactly right. I made a quick and dirty attempt at moving the AST optimization step after the symtable generation on the train home last night to see if Jeremy's suggestion gives us anything. Now, it does make the detection of generators a little easier, but it really doesn't give us all that much else. I'm happy to post a patch so you can see what I mean, but for now I think visiting the FunctionDef subtree to check for Yield nodes will be fine. Again, I might be wrong (as I've often been throughout this process!) but let's see how it goes. Obviously a bit less efficient, but function bodies really shouldn't be all that deep anyway. I've got a good idea about how I'm going to go forward with this. Cheers, T ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
On Thu, May 8, 2008 at 5:22 PM, Thomas Lee <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: >> >> There are a lot of micro-optimisations that are actually context >> independent, so moving them before the symtable pass should be quite >> feasible - e.g. replacing "return None" with "return", stripping dead code >> after a return statement, changing a "if not" statement into an "if" >> statement with the two suites reversed, changing "(1, 2, 3)" into a stored >> constant, folding "1 + 2" into the constant "3". >> >> I believe the goal is to see how many of the current bytecode >> optimisations can actually be brought forward to the AST generation stage, >> rather than waiting until after the bytecode symtable calculation and >> compilation passes. >> > That's been the aim so far. It's been largely successful with the exception > of a few edge cases (most notably the functions vs. generator stuff). The > elimination of unreachable paths (whether they be things like "if 0: ..." or > "return; ... more code ...") completely breaks generators since we might > potentially be blowing away "yield" statements during the elimination > process. Also breaks various sanity checks relating to the global statement. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.6a3 and 3.0a5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team and the Python community, I am happy to announce the third alpha release of Python 2.6, and the fifth alpha release of Python 3.0. Please note that these are alpha releases, and as such are not suitable for production environments. We continue to strive for a high degree of quality, but there are still some known problems and the feature sets have not been finalized. These alphas are being released to solicit feedback and hopefully discover bugs, as well as allowing you to determine how changes in 2.6 and 3.0 might impact you. If you find things broken or incorrect, please submit a bug report at http://bugs.python.org For more information and downloadable distributions, see the Python 2.6 website: http://www.python.org/download/releases/2.6/ and the Python 3.0 web site: http://www.python.org/download/releases/3.0/ These are the last planned alphas for both versions. If all goes well, next month will see the first beta releases of both, which will also signal feature freeze. Two beta releases are planned, with the final releases scheduled for September 3, 2008. See PEP 361 for release details: http://www.python.org/dev/peps/pep-0361/ Enjoy, - -Barry Barry Warsaw [EMAIL PROTECTED] Python 2.6/3.0 Release Manager (on behalf of the entire python-dev team) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCORrnEjvBPtnXfVAQIK+QQAgEUtAvW7uo0BxMiT1bCAo2E9ZecWJ9xe DBgd/5IK8moITkqhqGAH5UvfytV6uPkOMgGIS/Uvk4hzhU3jwSopEIDJLFQ5nGtC lCzOHzkDjSNZ8Q2OOAI9mbSHY8grvVxCMB4X2SVXIEMZ6M/X1AcV2b0utp9O1w/l T/PEvP8U1uY= =2Tnb -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
Adam Olsen wrote: On Thu, May 8, 2008 at 5:22 PM, Thomas Lee <[EMAIL PROTECTED]> wrote: Nick Coghlan wrote: There are a lot of micro-optimisations that are actually context independent, so moving them before the symtable pass should be quite feasible - e.g. replacing "return None" with "return", stripping dead code after a return statement, changing a "if not" statement into an "if" statement with the two suites reversed, changing "(1, 2, 3)" into a stored constant, folding "1 + 2" into the constant "3". I believe the goal is to see how many of the current bytecode optimisations can actually be brought forward to the AST generation stage, rather than waiting until after the bytecode symtable calculation and compilation passes. That's been the aim so far. It's been largely successful with the exception of a few edge cases (most notably the functions vs. generator stuff). The elimination of unreachable paths (whether they be things like "if 0: ..." or "return; ... more code ...") completely breaks generators since we might potentially be blowing away "yield" statements during the elimination process. Also breaks various sanity checks relating to the global statement. What sanity checks are these exactly? Is this related to the lnotab? Cheers, T ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] RELEASED Python 2.6a3 and 3.0a5
On Thu, May 8, 2008 at 6:50 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On behalf of the Python development team and the Python community, I am > happy to announce the third alpha release of Python 2.6, and the fifth alpha > release of Python 3.0. Special thanks goes to Christian Heimes for his last minute detection and fix of a ref leak. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] [Python-3000] r62848 - python/trunk/Objects/setobject.c
amk> Subscribers to the python-dev digests may also not see a posting amk> immediately, waiting until the next digest is sent. Or python-dev subscribers might delete the announcement of the freeze without paying close attention to it then wonder a few hours later whether or not it's okay to check anything in. (Speaking as someone with a problem in this area.) I'm all in favor of a technical fix to my memory problems. <0.5 wink> Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
Thomas Lee wrote: Adam Olsen wrote: On Thu, May 8, 2008 at 5:22 PM, Thomas Lee <[EMAIL PROTECTED]> wrote: Nick Coghlan wrote: There are a lot of micro-optimisations that are actually context independent, so moving them before the symtable pass should be quite feasible - e.g. replacing "return None" with "return", stripping dead code after a return statement, changing a "if not" statement into an "if" statement with the two suites reversed, changing "(1, 2, 3)" into a stored constant, folding "1 + 2" into the constant "3". I believe the goal is to see how many of the current bytecode optimisations can actually be brought forward to the AST generation stage, rather than waiting until after the bytecode symtable calculation and compilation passes. That's been the aim so far. It's been largely successful with the exception of a few edge cases (most notably the functions vs. generator stuff). The elimination of unreachable paths (whether they be things like "if 0: ..." or "return; ... more code ...") completely breaks generators since we might potentially be blowing away "yield" statements during the elimination process. Also breaks various sanity checks relating to the global statement. What sanity checks are these exactly? Is this related to the lnotab? Cheers, T ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org While not strictly related to the global statement, perhaps Adam refers to the possibility of optimizing away code with an assignment which would make a name be recognized as local? If you're worried about "yield" disappearing you should also be worried about assignments disappearing, since that might cause names to be interpreted as globals. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
On Thu, May 8, 2008 at 5:54 PM, Thomas Lee <[EMAIL PROTECTED]> wrote: > Adam Olsen wrote: >> >> On Thu, May 8, 2008 at 5:22 PM, Thomas Lee <[EMAIL PROTECTED]> wrote: >> >>> >>> Nick Coghlan wrote: >>> There are a lot of micro-optimisations that are actually context independent, so moving them before the symtable pass should be quite feasible - e.g. replacing "return None" with "return", stripping dead code after a return statement, changing a "if not" statement into an "if" statement with the two suites reversed, changing "(1, 2, 3)" into a stored constant, folding "1 + 2" into the constant "3". I believe the goal is to see how many of the current bytecode optimisations can actually be brought forward to the AST generation stage, rather than waiting until after the bytecode symtable calculation and compilation passes. >>> >>> That's been the aim so far. It's been largely successful with the >>> exception >>> of a few edge cases (most notably the functions vs. generator stuff). The >>> elimination of unreachable paths (whether they be things like "if 0: ..." >>> or >>> "return; ... more code ...") completely breaks generators since we might >>> potentially be blowing away "yield" statements during the elimination >>> process. >>> >> >> Also breaks various sanity checks relating to the global statement. >> >> > > What sanity checks are these exactly? Is this related to the lnotab? Here we are. In 2.4.4: >>> def foo(): ... print test ... if 0: ... import test ... >>> foo() Traceback (most recent call last): File "", line 1, in ? File "", line 2, in foo NameError: global name 'test' is not defined 2.5.1 correctly raises an UnboundLocalError instead. Searching the bug DB for old bugs involving the optimizer showed several variations on this, such as "if 0: yield None" at module scope not raising a SyntaxError (Issue 1875, still open in trunk). Clearly there needs to be a general approach to avoid affecting these checks with optimizations. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
Steve Holden wrote: While not strictly related to the global statement, perhaps Adam refers to the possibility of optimizing away code with an assignment which would make a name be recognized as local? If you're worried about "yield" disappearing you should also be worried about assignments disappearing, since that might cause names to be interpreted as globals. And once you start annotating functions as generators or not, and variable names as locals or cell variables or globals, you're starting to build up a substantial fraction of the information that is already collected during the symtable construction pass. Perhaps the initial attempt at this should just focus on identifying those operations which have the potential to alter the results of the symtable construction, and leave those to the bytecode optimisation step for the moment. Doing the symtable pass twice seems fairly undesirable, even if it does let us trim some dead code out of the AST. Cheers, Nick. P.S. Here's a nonsensical example where optimising away the dead code after the return statement would significantly change the code's semantics: >>> def silly(): ... def inner(): ... print cell_var ... return inner ... cell_var = None ... >>> silly()() Traceback (most recent call last): File "", line 1, in File "", line 3, in inner NameError: free variable 'cell_var' referenced before assignment in enclosing scope -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
Nick Coghlan wrote: Steve Holden wrote: While not strictly related to the global statement, perhaps Adam refers to the possibility of optimizing away code with an assignment which would make a name be recognized as local? If you're worried about "yield" disappearing you should also be worried about assignments disappearing, since that might cause names to be interpreted as globals. And once you start annotating functions as generators or not, and variable names as locals or cell variables or globals, you're starting to build up a substantial fraction of the information that is already collected during the symtable construction pass. Perhaps the initial attempt at this should just focus on identifying those operations which have the potential to alter the results of the symtable construction, and leave those to the bytecode optimisation step for the moment. Doing the symtable pass twice seems fairly undesirable, even if it does let us trim some dead code out of the AST. Sounds good. We can always come back to it. Cheers, T ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
