Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
Brett Cannon wrote: I know AMK was experimenting with rest2web as a possible way to do the web site. There has also been talk about trying out another system. But I also know some people would rather put the effort into improving Pyramid. You forgot the ponies! Once again, it's a matter of people putting the time in to make a switch happen to a system that the site maintainers would be happy with. The people behind the current system and process has invested way too much energy and prestige in the current system to ever accept that the result is pretty lousy as a site, and complete rubbish as technology. It's about sunk costs, not cost- and time-effective solutions. For reference, here's my effbot.org release procedure: 1) upload the distribution files one by one, as soon as they're available. all links and stuff will appear automatically 2) update the associated description text through the web, when necessary, as an HTML fragment. click save to publish. 3) mail out an announcement when everything looks good. Maybe I should offer Anthony to do the releases via effbot.org instead? /F ___ 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] 2.3.6 for the unicode buffer overrun
Anthony Baxter wrote: The other thing to watch out for is that I (or whoever) can still do local work on a bunch of different files the point of my previous post is that you *shouldn't* have to edit a bunch of different files to make a new release. /F ___ 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] 2.3.6 for the unicode buffer overrun
For reference, here's my effbot.org release procedure: 1) upload the distribution files one by one, as soon as they're available. all links and stuff will appear automatically 2) update the associated description text through the web, when necessary, as an HTML fragment. click save to publish. 3) mail out an announcement when everything looks good. Maybe I should offer Anthony to do the releases via effbot.org instead? First off - I'm not going to be posting 10M or 16M files through a web-browser. That's insane :-) The bit of the website that's dealing with the actual files is not the tricky bit - I have a dinky little python script that generates the download table. The problems are with the other bits of the pages. I keep thinking next release, I'll automate it further, but never have time on the day. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] Why spawnvp not implemented on Windows?
Alexey Borzenkov wrote: P.S. Although it's a bit stretching, one might also say that implementing spawn*p* on windows is not actually a new feature, and rather is a bugfix for misfeature. Why every other platform can benefit from spawn*p* and only Windows can't? This just makes os.spawn*p* useless: it becomes unreliable and can't be used in portable code at all. any reason you cannot just use the subprocess module instead, like everyone else? /F ___ 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] 2.3.6 for the unicode buffer overrun
Anthony Baxter wrote: For reference, here's my effbot.org release procedure: 1) upload the distribution files one by one, as soon as they're available. all links and stuff will appear automatically 2) update the associated description text through the web, when necessary, as an HTML fragment. click save to publish. 3) mail out an announcement when everything looks good. Maybe I should offer Anthony to do the releases via effbot.org instead? First off - I'm not going to be posting 10M or 16M files through a web-browser. That's insane :-) oh, I only edit the pages through the web, not the files. there's nothing wrong with scp or sftp or rsync-over-ssh or whatever you're using today. The bit of the website that's dealing with the actual files is not the tricky bit - I have a dinky little python script that generates the download table. yeah, but *you* are doing it. if the server did that, Martin and other trusted contributors could upload the files as soon as they're available, instead of first transferring them to you, and then waiting for you to find yet another precious time slot to spend on this release. The problems are with the other bits of the pages. I keep thinking next release, I'll automate it further, but never have time on the day. that's why you have to have an overall infrastructure that lets you make incremental tweaks to the tool chain, so things can get a little better all the time. Pyramid obviously isn't such a system. /F ___ 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] 2.3.6 for the unicode buffer overrun
On Friday 13 October 2006 16:59, Fredrik Lundh wrote: yeah, but *you* are doing it. if the server did that, Martin and other trusted contributors could upload the files as soon as they're available, instead of first transferring them to you, and then waiting for you to find yet another precious time slot to spend on this release. Sure - I get that. There's a couple of reasons for me doing it. First is gpg signing the release files, which has to happen on my local machine. There's also the variation in who actually builds the releases; at least one of the Mac builds was done by Bob I. But there could be ways around this. I don't want to have to ensure every builder has scp, and I'd also prefer for it to all go live at once. A while back, the Mac installer would follow up some time after the Windows and source builds. Every release, I'd get emails saying where's the mac build?! The problems are with the other bits of the pages. I keep thinking next release, I'll automate it further, but never have time on the day. that's why you have to have an overall infrastructure that lets you make incremental tweaks to the tool chain, so things can get a little better all the time. Pyramid obviously isn't such a system. I can't disagree with this. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom
I've uploaded a new patch to Sourceforge in response to feedback: * I purged all // comments and fixed all 80 characters added by my patch, as per Neil Norwitz. * I added a definition of max() for those who don't already have one, as per [EMAIL PROTECTED] It now compiles cleanly on Linux again without modification; sorry for not checking that since the original patch. I've also uploaded my hacked-together benchmark script, for all that's worth. That patch tracker page again: http://sourceforge.net/tracker/index.php?func=detailaid=1569040group_id=5470atid=305470 M.-A. Lemburg wrote: When comparing results, please look at the minimum runtime. The average times are just given to indicate how much the mintime differs from the average of all runs. I'll do that next time. In the meantime, I've also uploaded a zip file containing the results of my benchmarking, including the stdout from the run and the -f file which contains the pickled output. So you can examine my results yourself, including doing analysis on the pickled data if you like. If however the speedups are not consistent across several runs of pybench, then it's likely that you have some background activity going on on the machine which causes a slowdown in the unmodified run you chose as basis for the comparison. The machine is dual-core, and was quiescent at the time. XP's scheduler is hopefully good enough to just leave the process running on one core. I ran the benchmarks just once on my Linux 2.6 machine; it's a dual-CPU P3 933EB (or maybe just 866EB, I forget). It's faster overall there too, by 1.9% (minimum run-time). The two tests I expected to be faster (ConcatStrings and CreateStringsWithConcat) were consistently much faster; beyond that the results don't particularly resemble the results from my XP machine. (I uploaded those .txt and .pickle files too.) The mystery overall speedup continues, not that I find it unwelcome. :) Just to make sure: you are using pybench 2.0, right ? I sure was. And I used stringbench.py downloaded from here: http://svn.python.org/projects/sandbox/branches/jim-fix-setuptools-cli/stringbench/stringbench.py Cheers, /larry/ ___ 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] 2.4.4: backport classobject.c HAVE_WEAKREFS?
Fredrik Lundh wrote: Martin v. Löwis wrote: Of course, if everybody would always recompile all extension modules for a new Python feature release, those flags weren't necessary. a dynamic registration approach would be even better, with a single entry point used to register all methods and hooks your C extension has implemented, and code on the other side that builds a properly initialized type descriptor from that set, using fallback functions and error stubs where needed. e.g. the impossible-to-write-from-scratch NoddyType struct initialization in http://docs.python.org/ext/node24.html would collapse to static PyTypeObject NoddyType; Wouldn't that have to be a pointer to allow the Python runtime complete control of the structure size without recompiling the extension?: static PyTypeObject *NoddyType; NoddyType = PyType_Alloc(noddy.Noddy); if (!NoddyType) return; PyType_Register(NoddyType, PY_TP_DEALLOC, Noddy_dealloc); PyType_Register(NoddyType, PY_TP_DOC, Noddy objects); PyType_Register(NoddyType, PY_TP_TRAVERSE, Noddy_traverse); PyType_Register(NoddyType, PY_TP_CLEAR, Noddy_clear); PyType_Register(NoddyType, PY_TP_METHODS, Noddy_methods); PyType_Register(NoddyType, PY_TP_MEMBERS, Noddy_members); PyType_Register(NoddyType, PY_TP_INIT, Noddy_init); PyType_Register(NoddyType, PY_TP_NEW, Noddy_new); if (PyType_Ready(NoddyType) 0) return; 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] 2.4.4: backport classobject.c HAVE_WEAKREFS?
Nick Coghlan wrote: would collapse to static PyTypeObject NoddyType; Wouldn't that have to be a pointer to allow the Python runtime complete control of the structure size without recompiling the extension?: static PyTypeObject *NoddyType; yeah, that's a silly typo. or maybe I was thinking of something really clever that I can no longer remember. NoddyType = PyType_Alloc(noddy.Noddy); if (!NoddyType) return; the fewer places you have to check for an error, the less chance you have to forget to do it. my proposal implied that the NULL check should be done in Ready. I've posted slightly cleaned up version of my rough proposal here: http://effbot.org/zone/idea-register-type.htm /F ___ 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] Proposal: No more standard library additions
Antoine wrote: The standard library is not about easeness of installation. It is about having a consistent fixed codebase to work with. I don't want to go Perl/CPAN, where you have 3-4 alternatives to do thing A which will never interoperate with whatever you chose among the 3-4 alternatives to do thing B. Currently in Python: http://docs.python.org/lib/module-xml.dom.html http://docs.python.org/lib/module-xml.dom.minidom.html http://docs.python.org/lib/module-xml.sax.html http://docs.python.org/lib/module-xml.parsers.expat.html http://docs.python.org/lib/module-xml.etree.ElementTree.html The problem of consistent fixed codebase is that standards get higher, so eventually those old stable modules lose popularity in favor of newer, better modules. Those are different paradigms of doing XML. For instance, the standard library was missing a pythonic library to do XML processing, and several arose. ElementTree (fortunately) won and joined the standard distribution. This should allievate the need for other libraries in future. Instead of looking what we have inside, look outside. There are dozens of different XML pythonic libraries. I have fought in the past with programs that required large XML frameworks, that in turn required to be downloaded, built, installed, and *understood* to make the required modifictions to the programs themselves. This slowed down my own development, and caused infinite headaches before of version compatibilities (A requires the XML library B, but only versions 1.2, otherwise you can use A 2.0, which needs Python 2.4+, and then you can use latest B; etc. etc. repeat and complicate ad-libitum). A single version number (that of Python) and a large fixed set of libraries anybody can use is a *strong* PLUS. Then, there is the opposite phenomenom, which is interesting as well. I met many perl programmers which simply re-invented their little wheel everytime. They were mostly system administrators, so they *knew* very well what hell the dependency chains are for both programmers and users. Thus, since perl does not have a standard library, they simply did not import *any* module. This way, the program is easier to ship, distribute and use, but it's harder to code, read, fix, and contain unnecessary duplications with everybody's else script. Need to send an e-mail? Why using a library, just paste chunks of cutpasted mail headers (with MIME, etc.) and do some basic string substitution; and the SMTP protocol is easy, just open a socket a dump some strings to it; or you can use 'sendmail' which is available on any UNIX (and there it goes portability, just because they did not want to evaluate and choose one of the 6 Perl SMTP libraries... and rightfully so!). Therefore, you have to obsolete old stuff if you want there to be only One Obvious Way To Do It. I'm totally in favor of obsoletion and removal of old cruft from the standard library. I'm totally against *not* having a standard library. Giovanni Bajo ___ 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] [py3k] Re: Proposal: No more standard library additions
I apologize, this had to go to [EMAIL PROTECTED] ___ 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] 2.3.6 for the unicode buffer overrun
On 10/13/06, Anthony Baxter [EMAIL PROTECTED] wrote: On Friday 13 October 2006 16:59, Fredrik Lundh wrote: yeah, but *you* are doing it. if the server did that, Martin and other trusted contributors could upload the files as soon as they're available, instead of first transferring them to you, and then waiting for you to find yet another precious time slot to spend on this release. Sure - I get that. There's a couple of reasons for me doing it. First is gpg signing the release files, which has to happen on my local machine. There's also the variation in who actually builds the releases; at least one of the Mac builds was done by Bob I. But there could be ways around this. I don't want to have to ensure every builder has scp, and I'd also prefer for it to all go live at once. A while back, the Mac installer would follow up some time after the Windows and source builds. Every release, I'd get emails saying where's the mac build?! With most consumer connections it's a lot faster to download than to upload. Perhaps it would save you a few minutes if the contributors uploaded directly to the destination (or to some other fast server) and you could download and sign it, rather than having to scp it back up somewhere from your home connection. To be fair, (thanks to Ronald) the Mac build is entirely automated by a script with the caveat that you should be a little careful about what your environment looks like (e.g. don't install fink or macports, or to move them out of the way when building). It downloads all of the third party dependencies, builds them with some special flags to make it universal, builds Python, and then wraps it up in an installer package. Given any Mac OS X 10.4 machine, the builds could happen automatically. Apple could probably provide one if someone asked. They did it for Twisted. Or maybe the Twisted folks could appropriate part of that machine's time to also build Python. -bob ___ 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] 2.3.6 for the unicode buffer overrun
On Friday 13 October 2006 20:35, Bob Ippolito wrote: With most consumer connections it's a lot faster to download than to upload. Perhaps it would save you a few minutes if the contributors uploaded directly to the destination (or to some other fast server) and you could download and sign it, rather than having to scp it back up somewhere from your home connection. I actually pull them down to both dinsdale and home, then verify they're the same with SHA and MD5 before signing, and uploading the keys. The only thing I upload directly are the keys and the source tarballs. Given any Mac OS X 10.4 machine, the builds could happen automatically. Apple could probably provide one if someone asked. They did it for Twisted. Or maybe the Twisted folks could appropriate part of that machine's time to also build Python. We have one, macteagle. For some reason builds fail on it right now - Ronald might be able to supply more details as to why. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] Why spawnvp not implemented on Windows?
On 10/13/06, Fredrik Lundh [EMAIL PROTECTED] wrote: any reason you cannot just use the subprocess module instead, like everyone else? Oh! Wow! I just simply didn't know of its existance (I'm pretty much new to python), and both distutils and SCons (I was looking inside them because they are major build systems and surely had to execute compilers somehow), and upon seeing that each of them invented their own method of searching path created a delusion as if inventing custom workarounds was the only way... Sorry... x_x ___ 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] Why spawnvp not implemented on Windows?
Alexey Borzenkov wrote: any reason you cannot just use the subprocess module instead, like everyone else? Oh! Wow! I just simply didn't know of its existance (I'm pretty much new to python), and both distutils and SCons (I was looking inside them because they are major build systems and surely had to execute compilers somehow), and upon seeing that each of them invented their own method of searching path created a delusion as if inventing custom workarounds was the only way... Sorry... x_x no problem. someone should really update the documentation to make sure that os.spawn and os.open and commands and popen2 and all the other 80%-solutions at least point to the subprocess module... (and if the library reference had been stored in a wiki, I'd fixed that before any- one else even got this mail...) /F ___ 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] 2.3.6 for the unicode buffer overrun
Martin v. Löwis schrieb: Anthony Baxter schrieb: Mostly it is easy for me, with the one huge caveat. As far as I know, the Mac build is a single command to run for Ronald, and the Doc build similarly for Fred. I don't know what Martin has to do for the Windows build. Actually, for 2.3.x, I wouldn't do the Windows builds. I think Thomas Heller did the 2.3.x series. Yes. But I've switched machines since I last build an installer, and I do not have all of the needed software installed any longer, for example the Wise Installer. Thomas ___ 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] 2.3.6 for the unicode buffer overrun
On Friday, October 13, 2006, at 01:10PM, Anthony Baxter [EMAIL PROTECTED] wrote: On Friday 13 October 2006 20:35, Bob Ippolito wrote: With most consumer connections it's a lot faster to download than to upload. Perhaps it would save you a few minutes if the contributors uploaded directly to the destination (or to some other fast server) and you could download and sign it, rather than having to scp it back up somewhere from your home connection. I actually pull them down to both dinsdale and home, then verify they're the same with SHA and MD5 before signing, and uploading the keys. The only thing I upload directly are the keys and the source tarballs. Given any Mac OS X 10.4 machine, the builds could happen automatically. Apple could probably provide one if someone asked. They did it for Twisted. Or maybe the Twisted folks could appropriate part of that machine's time to also build Python. We have one, macteagle. For some reason builds fail on it right now - Ronald might be able to supply more details as to why. IIRC it has the wrong version of Xcode installed (or rather another one than I use and test with). It also has darwinports installed at the default location, which can cause problems because the setup.py adds that directory to the include/link paths. I don't want to release installers that require that the user has darwinports installed :-) I can supply a newer version of Xcode if someone with an admin account is willing to install that. I don't know if the admin of that machine has GUI access to the machine, if not I'd have to investigate how to ensure that the proper subpackages get installed using a command-line install (using RemoteDesktop to administrator servers has spoiled me a bit in that regard). I guess this comes down to the usual problem: I have a working setup for building the mac installer and fixing macteagle takes time which I don't have available in great amounts (who does?). Ronald ___ 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] 2.3.6 for the unicode buffer overrun
On Friday, October 13, 2006, at 12:36PM, Bob Ippolito [EMAIL PROTECTED] wrote: To be fair, (thanks to Ronald) the Mac build is entirely automated by a script with the caveat that you should be a little careful about what your environment looks like (e.g. don't install fink or macports, or to move them out of the way when building). That (the don't install Fink or macports part) is because setup.py explicitly adds those directories to the library and include search path. IMHO that is a misfeature because it is much to easy to accidently contaminate a build that way. Fink and macports can easily add their directories to the search paths using OPTS and LDFLAGS, there's no need to automate this in setup.py. The beauty of macports is that /opt/local is the default prefix, but you can easily pick another prefix and most ports work fine that way (or rather not worse than with the default prefix). Ronald ___ 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] 2.3.6 for the unicode buffer overrun
Fredrik Lundh wrote: Anthony Baxter wrote: The other thing to watch out for is that I (or whoever) can still do local work on a bunch of different files the point of my previous post is that you *shouldn't* have to edit a bunch of different files to make a new release. Indeed. I seem to remember suggesting a while ago on pydotorg that whatever replaces pyramid should cater to groups such as the release team by allowing everything necessary to be generated from a simple set of data that wouldn't be difficult to maintain. Anthony has enough on his plate without having to fight the web server too ... regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] 2.3.6 for the unicode buffer overrun
Fredrik Lundh wrote: Brett Cannon wrote: I know AMK was experimenting with rest2web as a possible way to do the web site. There has also been talk about trying out another system. But I also know some people would rather put the effort into improving Pyramid. You forgot the ponies! Once again, it's a matter of people putting the time in to make a switch happen to a system that the site maintainers would be happy with. The people behind the current system and process has invested way too much energy and prestige in the current system to ever accept that the result is pretty lousy as a site, and complete rubbish as technology. It's about sunk costs, not cost- and time-effective solutions. I don't believe that's true, but I'm certainly not the one with the most time invested in pyramid. Tim Parkin is on record as saying he'd be willing to help with a(nother) migration project. I think there's a general appreciation of pyramid's strangths *and* deficiencies. For reference, here's my effbot.org release procedure: 1) upload the distribution files one by one, as soon as they're available. all links and stuff will appear automatically 2) update the associated description text through the web, when necessary, as an HTML fragment. click save to publish. 3) mail out an announcement when everything looks good. Maybe I should offer Anthony to do the releases via effbot.org instead? You can try. Or you can start to promote Django again ... regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] Plea to distribute debugging lib
Martin v. Löwis [EMAIL PROTECTED] writes: I'm not sure whether you are requesting these for yourself or for somebody else. If for somebody else, that somebody else should seriously consider building Python himself, and publishing the result. I'm requesting it for the many Boost.Python (heck, all Python 'C' API) users who find it a usability hurdle when their first visual studio projects fail to work properly in the default mode (debug) just because they don't have the right Python libraries. -- Dave Abrahams Boost Consulting www.boost-consulting.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] Why spawnvp not implemented on Windows?
Alexey Borzenkov wrote: Oh! Wow! I just simply didn't know of its existance (I'm pretty much new to python), and both distutils and SCons (I was looking inside them because they are major build systems and surely had to execute compilers somehow), and upon seeing that each of them invented their own method of searching path created a delusion as if inventing custom workarounds was the only way... Sorry... x_x SCons is still compatible with Python 1.5. Distutils was written in the 1.5-1.6 timeframe; it has been updated since, but it is basically unmaintained at this point (if you exclude the setuptools stuff which is its disputed maintenance/evolution). subprocess has been introduced in Python 2.4. -- Giovanni Bajo ___ 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] Modulefinder
I have patched Lib/modulefinder.py to work with absolute and relative imports. It also is faster now, and has basic unittests in Lib/test/test_modulefinder.py. The work was done in a theller_modulefinder SVN branch. If nobody objects, I will merge this into trunk, and possibly also into release25-maint, when I have time. Thanks, Thomas ___ 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] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom
Larry Hastings [EMAIL PROTECTED] wrote: [snip] The machine is dual-core, and was quiescent at the time. XP's scheduler is hopefully good enough to just leave the process running on one core. It's not. Go into the task manager (accessable via Ctrl+Alt+Del by default) and change the process' affinity to the second core. In my experience, running on the second core (in both 2k and XP) tends to produce slightly faster results. Linux tends to keep processes on a single core for a few seconds at a time. - Josiah ___ 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] Cloning threading.py using proccesses
I just got around to reading the messages.When I first saw this, I thought this is so that the processes that need to share and work on shared objects. That is where the locks are required. However, all shread objects are managed by the object manager and thus all such operations are in effect sequential, even acquires on different locks. Thus other shared objects in the object manager will actually not require any (additional) synchronization. Of course, the argument here is that it is still possible to use that code. Cleanup of shared objects seems to be another thing to look out for. This is a problem that subprocesses seem to avoid and has been already suggested.-ChetanOn 10/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Message: 5Date: Wed, 11 Oct 2006 10:23:40 +0200From: M.-A. Lemburg [EMAIL PROTECTED]Subject: Re: [Python-Dev] Cloning threading.py using proccessesTo: Josiah Carlson [EMAIL PROTECTED]Cc: python-dev@python.orgMessage-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1Josiah Carlson wrote: Fredrik Lundh [EMAIL PROTECTED] wrote: Josiah Carlson wrote: Presumably with this library you have created, you have also written a fast object encoder/decoder (like marshal or pickle).If it isn't any faster than cPickle or marshal, then users may bypass the module and opt for fork/etc. + XML-RPC XML-RPC isn't close to marshal and cPickle in performance, though, so that statement is a bit misleading. You are correct, it is misleading, and relies on a few unstated assumptions. In my own personal delving into process splitting, RPC, etc., I usually end up with one of two cases; I need really fast call/return, or I need not slow call/return.The not slow call/return is (in my opinion) satisfactorally solved with XML-RPC.But I've personally not been satisfied with the speed of any remote 'fast call/return' packages, as they usually rely on cPickle or marshal, which are slow compared to even moderately fast 100mbit network connections.When we are talking about local connections, I have even seen cases where the cPickle/marshal calls can make it so that forking the process is faster than encoding the input to a called function.This is hard to believe. I've been in that business for a fewyears and so far have not found an OS/hardware/network combinationwith the mentioned features. Usually the worst part in performance breakdown for RPC is networklatency, ie. time to connect, waiting for the packets to come through,etc. and this parameter doesn't really depend on the OS or hardware you're running the application on, but is more a factor of whichnetwork hardware, architecture and structure is being used.It also depends a lot on what you send as arguments, of course,but I assume that you're not pickling a gazillion objects :-) I've had an idea for a fast object encoder/decoder (with limited support for certain built-in Python objects), but I haven't gotten around to actually implementing it as of yet.Would be interesting to look at. BTW, did you know about http://sourceforge.net/projects/py-xmlrpc/ ?--Marc-Andre LemburgeGenix.comProfessional Python Services directly from the Source(#1, Oct 11 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! -- ___ 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] Plea to distribute debugging lib
David Abrahams schrieb: I'm not sure whether you are requesting these for yourself or for somebody else. If for somebody else, that somebody else should seriously consider building Python himself, and publishing the result. I'm requesting it for the many Boost.Python (heck, all Python 'C' API) users who find it a usability hurdle when their first visual studio projects fail to work properly in the default mode (debug) just because they don't have the right Python libraries. And there is not one of them who would be willing and able to build a debug release, and distribute that Regards, Martin ___ 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] 2.3.6 for the unicode buffer overrun
Steve Holden schrieb: The other thing to watch out for is that I (or whoever) can still do local work on a bunch of different files the point of my previous post is that you *shouldn't* have to edit a bunch of different files to make a new release. Indeed. I seem to remember suggesting a while ago on pydotorg that whatever replaces pyramid should cater to groups such as the release team by allowing everything necessary to be generated from a simple set of data that wouldn't be difficult to maintain. Anthony has enough on his plate without having to fight the web server too ... There is always some sort of text that accompanies a release. That has to be edited to be correct; a machine can't do that. Regards, Martin ___ 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] 2.3.6 for the unicode buffer overrun
Martin v. Löwis [EMAIL PROTECTED] wrote: Thomas Heller schrieb: Yes. But I've switched machines since I last build an installer, and I do not have all of the needed software installed any longer, for example the Wise Installer. Ok. So we are technically incapable of producing the Windows binaries of another 2.3.x release, then? I've got a build setup for 2.3.x, but I lack the Wise Installer. It may be possible to use the 2.4 or 2.5 .msi creation tools, if that was sufficient. - Josiah ___ 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] 2.3.6 for the unicode buffer overrun
[Thomas Heller] Yes. But I've switched machines since I last build an installer, and I do not have all of the needed software installed any longer, for example the Wise Installer. [Martin v. Löwis] Ok. So we are technically incapable of producing the Windows binaries of another 2.3.x release, then? FYI, I still have the Wise Installer. But since my understanding is that the Unicode buffer overrun thingie is a non-issue on Windows, I've got no interest in wrestling with a 2.3.6 for Windows. ___ 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] Plea to distribute debugging lib
Martin v. Löwis [EMAIL PROTECTED] writes: David Abrahams schrieb: I'm not sure whether you are requesting these for yourself or for somebody else. If for somebody else, that somebody else should seriously consider building Python himself, and publishing the result. I'm requesting it for the many Boost.Python (heck, all Python 'C' API) users who find it a usability hurdle when their first visual studio projects fail to work properly in the default mode (debug) just because they don't have the right Python libraries. And there is not one of them who would be willing and able to build a debug release, and distribute that I don't know. -- Dave Abrahams Boost Consulting www.boost-consulting.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] 2.3.6 for the unicode buffer overrun
Tim Peters schrieb: FYI, I still have the Wise Installer. But since my understanding is that the Unicode buffer overrun thingie is a non-issue on Windows, I've got no interest in wrestling with a 2.3.6 for Windows. In 2.3.6, there wouldn't just be that change, but also a few other changes that have been collected, some relevant for Windows as well: there are several updates to the email package, and a fix to pcre to prevent a buffer overrun. I'm not saying that you should produce a Windows binary then, just that it would be good if one was produced if there was another release. Of course, people might also get the binaries from ActiveState should they produce some. Regards, Martin ___ 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
