Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
Josiah Carlson schrieb: > 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. I don't think that would be appropriate. There are differences in usage which might be significant to some users, e.g. in automated install scenarios. We should attempt not to break this. 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
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
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
[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] 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 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? 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] 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] 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] 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
[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] 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
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] 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] 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
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
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
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] 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...) ___ 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] 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] 2.3.6 for the unicode buffer overrun
Anthony: >> 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 scp or scp access? the former isn't much of a requirement, really. I would be surprised to find a developer that didn't already have it on all machines, or knew how to run it off the internet (type "putty download" into google and click "I feel lucky"). >> 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?!" that's a worthwhile goal, now that we have plenty of build volunteers, but I think that could be solved simply by delaying the *public* announcement until everything is in place. this is open source, after all - we don't need to hide how we're doing things. 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. that's another interesting advantage of a more asynchronous release process. if we can reduce the costly parts to a few 8-minute slots, it's a lot easier for any busy developer to find the time, even on a hectic day. and if we can dis- tribute those slots, things will be even easier. ___ 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
[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] 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 cut&pasted 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
Re: [Python-Dev] Python 2.5 performance
Raymond Hettinger wrote: >> From: Kristján V. Jónsson >> I think we should start considering to make PCBuild8 a "supported" build. > > +1 and not just for the free speed-up. VC8 is what more and more Windows > developers will have on there machines. Without a supported build, it > becomes > much harder to make patches or build compatible extensions. It also makes hobbyist hacking on the core more straightforward, as it makes it possible to use VC++ Express Edition to try out changes locally. 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
___
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] 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=detail&aid=1569040&group_id=5470&atid=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.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] 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. ___ 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
