[Python-Dev] 2.3.6 for the unicode buffer overrun
I've had a couple of queries about whether PSF-2006-001 merits a 2.3.6. Personally, I lean towards no - 2.4 was nearly two years ago now. But I'm open to other opinions - I guess people see the phrase buffer overrun and they get scared. Plus once 2.4.4 final is out next week, I'll have cut 12 releases since March. Assuming a 2.5.1 before March (very likely) that'll be 14 releases in 12 months. 16 releases in 12 months would just about make me go crazy. ___ 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.4.4, release candidate 1
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.4 (release candidate 1). Python 2.4.4 is a bug-fix release. While Python 2.5 is the latest version of Python, we're making this release for people who are still running Python 2.4. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the more than 80 bugs squished in this release, including a number found by the Coverity and Klocwork static analysis tools. We'd like to offer our thanks to both these companies for making this available for open source projects. * Python 2.4.4 contains a fix for PSF-2006-001, a buffer overrun * * in repr() of unicode strings in wide unicode (UCS-4) builds. * * See http://www.python.org/news/security/PSF-2006-001/ for more. * Assuming no major problems crop up, a final release of Python 2.4.4 will follow in about a week's time. This will be the last planned release in the Python 2.4 series - future maintenance releases will be in the 2.5 line. For more information on Python 2.4.4, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.4.4/ Highlights of this new release include: - Bug fixes. According to the release notes, at least 80 have been fixed. - A fix for PSF-2006-001, a bug in repr() for unicode strings on UCS-4 (wide unicode) builds. Highlights of the previous major Python release (2.4) are available from the Python 2.4 page, at http://www.python.org/2.4/highlights.html Enjoy this release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpzcYkwpfnHG.pgp Description: 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] 2.3.6 for the unicode buffer overrun
Anthony Baxter wrote: 16 releases in 12 months would just about make me go crazy. is there any way we could further automate or otherwise streamline or distribute the release process ? ideally, releasing (earlier release + well-defined patch set) should be fairly trivial, compared to releasing (new release from trunk). what do we have to do to make it easier to handle that case? /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.4.4: backport classobject.c HAVE_WEAKREFS?
Hi Fredrik, On Wed, Oct 11, 2006 at 12:35:23PM +0200, Fredrik Lundh wrote: NoddyType = PyType_Setup(noddy.Noddy, sizeof(Noddy)); It doesn't address the problem Martin explained (you can put neither NULLs nor stubs in tp_xxx fields that are beyond the C extension module's sizeof(Nobby)). But I imagine it could with a bit more tweaking. A bientot, Armin ___ 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
M.-A. Lemburg [EMAIL PROTECTED] wrote: This is hard to believe. I've been in that business for a few years and so far have not found an OS/hardware/network combination with the mentioned features. Surely you must have - unless there is another M.-A. Lemburg in IT! Some of the specialist systems, especially those used for communication, were like that, and it is very likely that many still are. But they aren't currently in Python's domain. I have never used any, but have colleagues who have. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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
Josiah Carlson [EMAIL PROTECTED] wrote: It would be convenient, yes, but the question isn't always 'threads or processes?' In my experience (not to say that it is more or better than anyone else's), when going multi-process, the expense on some platforms is significant enough to want to persist the process (this is counter to my previous forking statement, but its all relative). And sometimes one *wants* multiple threads running in a single process handling multiple requests. Yes, indeed. This is all confused by the way that POSIX (and Microsoft) threads have become essentially just processes with shared resources. If one had a system with real, lightweight threads, the same might well not be so. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] Signals, threads, blocking C functions
Sorry. I was on holiday, and then buried this when sorting out my thousands of Emails on my return, partly because I had to look up the information! =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote: | afaik the kernel only sends signals to threads that don't have them blocked. | If python doesn't want anyone but the main thread to get signals, it should just | block signals on all but the main thread and then by nature, all signals will go | to the main thread Well, THAT'S wrong, I am afraid! Things ain't that simple :-( Yes, POSIX implies that things work that way, but there are so many get-out clauses and problems with trying to implement that specification that such behaviour can't be relied on. Can you please give one example for each (one get-out clause, and one problem with trying to implement that). http://www.opengroup.org/onlinepubs/009695399/toc.htm 2.4.1 Signal Generation and Delivery It is extremely unclear what that means, but it talks about the generation and delivery of signals to both threads and processes. I can tell you (from speaking to system developers) that they understand that to mean that they are allowed to send signals to specific threads when that is appropriate. But they are as confused by POSIX's verbiage as I am! I fail to see why it isn't desirable to make all signals occur in the main thread, on systems where this is possible. Oh, THAT's easy. Consider a threaded application running on a muti-CPU machine and consider hardware generated signals (e.g. SIGFPE, SIGSEGV etc.) Sending them to the master thread involves either moving them between CPUs or moving the master thread; both are inefficient and neither may be possible. [ I have brought systems down with signals that did have to be handled on a particular CPU, by flooding that with signals from dozens of others (yes, big SMPs) and blocking out high-priority interrupts. The efficiency point can be serious. ] That also applies to many of the signals that do not reach programs, such as TLB misses, ECC failure etc. But, in those cases, what does Python or even POSIX need to know about them? Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] Signals, threads, blocking C functions
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote: Michael Hudson schrieb: According to [1], all python needs to do to avoid this problem is block all signals in all but the main thread; Argh, no: then people who call system() from non-main threads end up running subprocesses with all signals masked, which breaks other things in very mysterious ways. Been there... Python should register a pthread_atfork handler then, which clears the signal mask. Would that not work? No. It's not the only such problem. Personally, I think that anyone who calls system(), fork(), spawn() or whatever from threads is cuckoo. It is precisely the sort of thing that is asking for trouble, because there are so many ways of doing it 'right' that you can't be sure exactly what mental model the system developers will have. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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
You may already know about a similar project a friend of mine (hi,
Steffen!) did a few years ago called Python Object Sharing (POSH). This
was however unix specific and relied on fork and SYSV IPC iirc. I see
he has a SF projectpage here:
http://poshmodule.sourceforge.net/
(doesn't seem to be a lot of activity there, though).
Best regards
__
Audun Ostrem Nordal tel: +41.22.76.74427
CERN IT/IS
1211 Geneve 23
Switzerland
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Richard Oudkerk
Sent: Monday, October 09, 2006 1:59 PM
To: python-dev@python.org
Subject: [Python-Dev] Cloning threading.py using proccesses
I am not sure how sensible the idea is, but I have had a
first stab at writing a module processing.py which is a near
clone of threading.py but uses processes and sockets for
communication. (It is one way of avoiding the GIL.)
I have tested it on unix and windows and it seem to work pretty well.
(Getting round the lack of os.fork on windows is a bit
awkward.) There is also another module dummy_processing.py
which has the same api but is just a wrapper round threading.py.
Queues, Locks, RLocks, Conditions, Semaphores and some other
shared objects are implemented.
People are welcome to try out the tests in test_processing.py
contained in the zipfile. More information is included in
the README file.
As a quick example, the code
. from processing import Process, Queue, ObjectManager
.
. def f(token):
. q = proxy(token)
. for i in range(10):
. q.put(i*i)
. q.put('STOP')
.
. if __name__ == '__main__':
. manager = ObjectManager()
. token = manager.new(Queue)
. queue = proxy(token)
.
. t = Process(target=f, args=[token])
. t.start()
.
. result = None
. while result != 'STOP':
. result = queue.get()
. print result
.
. t.join()
is not very different from the normal threaded equivalent
. from threading import Thread
. from Queue import Queue
.
. def f(q):
. for i in range(10):
. q.put(i*i)
. q.put('STOP')
.
. if __name__ == '__main__':
. queue = Queue()
.
. t = Thread(target=f, args=[queue])
. t.start()
.
. result = None
. while result != 'STOP':
. result = queue.get()
. print result
.
. t.join()
Richard
___
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] ConfigParser: whitespace leading comment lines
Hello all,I'd like to propose the following change to ConfigParser.py.I won't call it a bug-fix because I don't know the relevant standards.This change will enable multiline comments as follows:[section]
item=value ;first of multiline comment
;second of multiline comment
Right now the behaviour is
In [19]: cfg.get('section','item')
Out[19]: 'value\n;second of multiline comment'
It's a one-line change.RawConfigParser._read lines 434-437 # comment or blank line?- if line.strip() == '' or line[0] in '#;':+ if line.strip() == '' or line.strip()[0] in '#;':
continueRegards,Greg Willden (Not a member of python-dev)-- Linux.Because rebooting is for adding hardware.
___
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] Python 2.5 performance
Hello there. I just got round to do some comparative runs of 2.5 32 bit Release, built with visual studio 2003 and 2005. Here the figures (pybench with default arguments) .NET 2003: Test minimum average operation overhead--- BuiltinFunctionCalls: 262ms 304ms 0.60us 0.251ms BuiltinMethodLookup: 232ms 267ms 0.25us 0.312ms CompareFloats: 148ms 170ms 0.14us 0.377ms CompareFloatsIntegers: 183ms 216ms 0.24us 0.261ms CompareIntegers: 144ms 163ms 0.09us 0.527ms CompareInternedStrings: 157ms 186ms 0.12us 1.606ms CompareLongs: 153ms 174ms 0.17us 0.300ms CompareStrings: 156ms 198ms 0.20us 1.166ms CompareUnicode: 180ms 205ms 0.27us 0.731ms ConcatStrings: 410ms 457ms 0.91us 0.579ms ConcatUnicode: 473ms 610ms 2.03us 0.466ms CreateInstances: 248ms 290ms 2.59us 0.432ms CreateNewInstances: 206ms 243ms 2.89us 0.352ms CreateStringsWithConcat: 164ms 200ms 0.20us 0.971ms CreateUnicodeWithConcat: 268ms 295ms 0.74us 0.343ms DictCreation: 152ms 186ms 0.47us 0.358ms DictWithFloatKeys: 378ms 410ms 0.46us 0.660ms DictWithIntegerKeys: 133ms 161ms 0.13us 0.907ms DictWithStringKeys: 152ms 184ms 0.15us 0.927ms ForLoops: 125ms 133ms 5.32us 0.069ms IfThenElse: 109ms 131ms 0.10us 1.019ms ListSlicing: 193ms 223ms 15.90us 0.072ms NestedForLoops: 147ms 164ms 0.11us 0.021ms NormalClassAttribute: 176ms 195ms 0.16us 0.579ms NormalInstanceAttribute: 171ms 198ms 0.17us 0.598ms PythonFunctionCalls: 207ms 240ms 0.73us 0.326ms PythonMethodCalls: 234ms 287ms 1.27us 0.163ms Recursion: 294ms 328ms 6.56us 0.563ms SecondImport: 191ms 210ms 2.10us 0.241ms SecondPackageImport: 197ms 220ms 2.20us 0.217ms SecondSubmoduleImport: 257ms 276ms 2.76us 0.213ms SimpleComplexArithmetic: 191ms 208ms 0.24us 0.445ms SimpleDictManipulation: 158ms 178ms 0.15us 0.625ms SimpleFloatArithmetic: 183ms 211ms 0.16us 0.703ms SimpleIntFloatArithmetic: 122ms 133ms 0.10us 0.745ms SimpleIntegerArithmetic: 106ms 121ms 0.09us 0.680ms SimpleListManipulation: 132ms 149ms 0.13us 0.750ms SimpleLongArithmetic: 170ms 198ms 0.30us 0.322ms SmallLists: 246ms 274ms 0.40us 0.437ms SmallTuples: 204ms 235ms 0.43us 0.497ms SpecialClassAttribute: 177ms 201ms 0.17us 0.561ms SpecialInstanceAttribute: 257ms 290ms 0.24us 0.598ms StringMappings: 881ms 949ms 3.77us 0.584ms StringPredicates: 321ms 366ms 0.52us 3.207ms StringSlicing: 243ms 286ms 0.51us 1.032ms TryExcept: 87ms 110ms 0.05us 0.957ms TryRaiseExcept: 164ms 197ms 3.08us 0.434ms TupleSlicing: 195ms 230ms 0.88us 0.065ms UnicodeMappings: 158ms 187ms 5.20us 0.699ms UnicodePredicates: 191ms 233ms 0.43us 3.954ms UnicodeProperties: 209ms 251ms 0.63us 3.234ms UnicodeSlicing: 306ms 345ms 0.70us 0.933ms---Totals: 11202ms 12875ms .NET 2005: Test minimum average operation overhead--- BuiltinFunctionCalls: 254ms 279ms 0.55us 0.280ms BuiltinMethodLookup: 269ms 290ms 0.28us 0.327ms CompareFloats: 136ms 147ms 0.12us 0.375ms CompareFloatsIntegers: 158ms 178ms 0.20us 0.268ms CompareIntegers: 118ms 141ms 0.08us 0.603ms CompareInternedStrings: 152ms 203ms 0.14us 1.666ms CompareLongs: 152ms 171ms 0.16us 0.335ms CompareStrings: 118ms 140ms 0.14us 1.374ms CompareUnicode: 160ms 180ms 0.24us 0.730ms ConcatStrings: 430ms 472ms 0.94us 0.681ms ConcatUnicode: 488ms 535ms 1.78us 0.458ms CreateInstances: 249ms 286ms 2.56us 0.437ms CreateNewInstances: 220ms 254ms 3.02us 0.356ms CreateStringsWithConcat: 174ms 204ms 0.20us 1.123ms CreateUnicodeWithConcat: 271ms 294ms 0.74us 0.348ms DictCreation: 151ms 169ms 0.42us 0.365ms DictWithFloatKeys: 350ms 387ms 0.43us 0.666ms DictWithIntegerKeys: 140ms 151ms 0.13us 1.020ms DictWithStringKeys: 154ms 176ms 0.15us 1.070ms ForLoops: 96ms 111ms 4.42us 0.069ms IfThenElse: 115ms 130ms 0.10us 0.697ms ListSlicing: 221ms 261ms 18.66us 0.093ms NestedForLoops: 146ms 167ms 0.11us 0.022ms NormalClassAttribute: 182ms 205ms 0.17us 0.502ms NormalInstanceAttribute: 174ms 192ms 0.16us 0.457ms PythonFunctionCalls: 203ms 221ms 0.67us 0.337ms PythonMethodCalls: 266ms 309ms 1.37us 0.149ms Recursion: 286ms 329ms 6.57us 0.459ms SecondImport: 170ms 197ms 1.97us 0.181ms SecondPackageImport: 187ms 215ms 2.15us 0.178ms SecondSubmoduleImport: 243ms 275ms 2.75us 0.215ms SimpleComplexArithmetic: 177ms 199ms 0.23us 0.370ms SimpleDictManipulation: 159ms 185ms 0.15us 0.498ms SimpleFloatArithmetic: 177ms 196ms 0.15us 1.502ms SimpleIntFloatArithmetic: 109ms 126ms 0.10us 0.574ms SimpleIntegerArithmetic: 108ms 124ms 0.09us 0.611ms SimpleListManipulation: 145ms 169ms 0.14us 0.619ms SimpleLongArithmetic: 167ms 190ms 0.29us 0.324ms SmallLists: 247ms 274ms 0.40us 0.339ms
Re: [Python-Dev] Cloning threading.py using proccesses
On 10/10/06, 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. the really interesting thing here is a ready-made threading-style API, I think. reimplementing queues, locks, and semaphores can be a reasonable amount of work; might as well use an existing implementation. The module uses cPickle. As for speed, on my old laptop I get maybe 1300 objects through a queue a second. For many purposes this might be too slow, in which cases you are better of sticking to threading; for many other cases that should not be a problem. It should quite possible to connect to an ObjectServer on a different machine, though I have not tried it. Although I reuse Queue, I wrote locks, semaphores and conditions from scratch -- I could not see a sensible way to use the original implementations. (The implementations of those classes are actually quite a bit shorter than the ones in threading.py.) By the way, on windows the example files currently need to be executed from commandline rather than clicked on (but that is easily fixable). ___ 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
On 10/10/06, Josiah Carlson [EMAIL PROTECTED] wrote:
the really interesting thing here is a ready-made threading-style API, I
think. reimplementing queues, locks, and semaphores can be a reasonable
amount of work; might as well use an existing implementation.
Really, it is a matter of asking what kind of API is desireable. Do we
want to have threading plus other stuff be the style of API that we want
to replicate? Do we want to have shared queue objects, or would an
XML-RPC-esque remote.queue_put('queue_X', value) and
remote.queue_get('queue_X', blocking=1) be better?
Whatever the API is, I think it is useful if you can swap between
threads and processes just by changing the import line. That way you
can write applications without deciding upfront which to use.
___
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
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. Raymond ___ 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] Why spawnvp not implemented on Windows?
Hi all, I've been looking at python 2.5 today and what I notices is absense of spawnvp with this comment in os.py: # At the moment, Windows doesn't implement spawnvp[e], # so it won't have spawnlp[e] either. I'm wondering, why so? Searching MSDN I can see that these functions are implemented in CRT: spawnvp: http://msdn2.microsoft.com/en-us/library/275khfab.aspx spawnvpe: http://msdn2.microsoft.com/en-us/library/h565xwht.aspx I can also see that spawnvp and spawnvpe are currently wrapped in posixmodule.c, but for some reason on OS/2 only. Forgive me if I'm wrong but shouldn't it work when #if defined(PYOS_OS2) is changed to #if defined(PYOS_OS2) || defined(MS_WINDOWS) around spawnvp and spawnvpe wrappers and in posix_methods? At least when I did it with my copy, nt.spawnvp seems to work fine... ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 12, 2006, at 4:08 AM, Anthony Baxter wrote: I've had a couple of queries about whether PSF-2006-001 merits a 2.3.6. Personally, I lean towards no - 2.4 was nearly two years ago now. But I'm open to other opinions - I guess people see the phrase buffer overrun and they get scared. Plus once 2.4.4 final is out next week, I'll have cut 12 releases since March. Assuming a 2.5.1 before March (very likely) that'll be 14 releases in 12 months. 16 releases in 12 months would just about make me go crazy. I've offered in the past to dust off my release manager cap and do a 2.3.6 release. Having not done one in a long while, the most daunting part for me is getting the website updated, since I have none of those tools installed. I'm still willing to do a 2.3.6, though the last time this came up the response was too underwhelming to care. I'm not sure this advisory is enough to change people's minds about that -- I'm sure any affected downstream distro is fully capable of patching and re- releasing their own packages. Since this doesn't affect the binaries /we/ release, I'm not sure I care enough either. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRS5hD3EjvBPtnXfVAQIlLgP/Rz5ahaeus0VLJT0HmyZUYBf07Crr2e1K KgCoEDqXZq+LyF7B8bqokXZ4uFisBbQTREM3d+8vYEHC9kcQpt0FurkSFc47G0gj rJvm0XbGkhXFGdPqrTwUoT033f/bhabpEILDkNJx6bB+Jk5G23EyTKRRDB531QvY qC6ttgGRfVA= =dECg -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] 2.3.6 for the unicode buffer overrun
Barry Warsaw [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- I've offered in the past to dust off my release manager cap and do a 2.3.6 release. Having not done one in a long while, the most daunting part for me is getting the website updated, since I have none of those tools installed. I'm still willing to do a 2.3.6, though the last time this came up the response was too underwhelming to care. I'm not sure this advisory is enough to change people's minds about that -- I'm sure any affected downstream distro is fully capable of patching and re- releasing their own packages. Since this doesn't affect the binaries /we/ release, I'm not sure I care enough either. Perhaps all that is needed from both a practical and public relations viewpoint is the release of a 2.3.5U4 security patch as a separate file listed just after 2.3.5 on the source downloads page (if this has not been done already). Add a note (or link to a note) to the effect that it should be applied if one has or is going to compile a wide Unicode build for use in an environment exposed to untrusted Unicode text. tjr ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 12, 2006, at 1:34 PM, Terry Reedy wrote: Perhaps all that is needed from both a practical and public relations viewpoint is the release of a 2.3.5U4 security patch as a separate file listed just after 2.3.5 on the source downloads page (if this has not been done already). I don't currently have the ability to update the website, but I think the download page should have a big red star that points to the security patch. The 2.3.5 page should probably be updated with a link to the patch too. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRS6BjnEjvBPtnXfVAQKssAQAnrgoMFbuAQRFSAReCYLBovsXJK481NdB gTk/gaAAXe15Ko+HN0gr1EF7Mpd9a8h+5UaWyiQo+2dEJFPYr8LKcLhVLRO75jwK A7oeXl859cUjwVK1Lc6uR/gFXUIhCsd8kujKb3lE71K6ygVtcqHwxr4OcMlMe/+j YExPu6zELjk= =NcuJ -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] Why spawnvp not implemented on Windows?
On 10/12/06, Alexey Borzenkov [EMAIL PROTECTED] wrote: At least when I did it with my copy, nt.spawnvp seems to work fine... Hi everyone again. I've created patch for spawn*p*, as well as for exec*p* against trunk, so that when possible it uses crt's execvp[e] (defined via HAVE_EXECVP, if there are other platforms that have it they will need to define HAVE_EXECVP and HAVE_SPAWNVP). Fix is in os.py and posixmodule.c: http://snaury.googlepages.com/python-win32-spawn_p_.patch Should I submit it to sourceforge as a patch, or someone can review it as is? ___ 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 Thu, Oct 12, 2006, Alexey Borzenkov wrote: Should I submit it to sourceforge as a patch, or someone can review it as is? Always submit patches; that guarantees your work won't get lost. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you don't know what your program is supposed to do, you'd better not start writing it. --Dijkstra ___ 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 Thursday 12 October 2006 18:18, Fredrik Lundh wrote: Anthony Baxter wrote: 16 releases in 12 months would just about make me go crazy. is there any way we could further automate or otherwise streamline or distribute the release process ? It's already pretty heavily automated (see welease.py in the SVN sandbox). The killer problem is pyramid (the system for the website). Here's (roughly) a breakdown of the workload: - Update the 10 or so files that need the date and version number (about 3m) - Run welease.py, select the branch, enter the version number, press 4 buttons, one after the other. It complains and stops if something goes wrong. (elapsed time about 5-10m, actual work time 30s) - Wait for the Mac/Win/Doc builders (elapsed, 6-12h, depending on timezones, actual work time 0s) - Sign binaries and put in place on website (maybe 2m work, plus 5-10m to scp up to dinsdale) - Update webpages (between 30m and an hour, depending on how much I have to fight with pyramid. I still need to go update the old release pages putting the warnings on them, so there's probably another hour of work today) I've mentioned this on pydotorg enough times, I don't feel I can continue to complain about it (because I can't offer the time to make it better) but pyramid is *not* *good* from my point of view. The older system with Makefiles, ht2html and rsync took maybe 1/4 to 1/3 as long. ideally, releasing (earlier release + well-defined patch set) should be fairly trivial, compared to releasing (new release from trunk). what do we have to do to make it easier to handle that case? 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. -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 12, 2006, at 3:27 PM, Anthony Baxter wrote: 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. Why can't we get buildbot to do most or all of this? At work, we have buildbot slaves that post installers to a share after successful checkout, build, and test on all our supported platforms. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRS6k2HEjvBPtnXfVAQJeawP7BTqVw7tN80h5lB5UZp4MuN2Q/3KWapIi lYZeBqoaiouXKIkKsHbCVb1/OeZQRnDwEqWPu0xKfzlteYUchmDh2h53nzfynyyS PdJ5FaKcAk0LBjR0JsSZKd6TEWxKZZHs04V2LiKZpmsICG8g7uH954wleyGLTl2h 7VZ1aVxGuko= =1Ito -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 2.5 performance
Kristján V. Jónsson wrote: This is an improvement of another 3.5 %. In all, we have a performance increase of more than 10%. Granted, this is from a single set of runs, but I think we should start considering to make PCBuild8 a supported build. Kristján, I wonder if the performance improvement comes from ceval.c only (or maybe a few other selected files). Is it possible to somehow link the PGO-optimized ceval.obj into the VS2003 project? -- 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] 2.3.6 for the unicode buffer overrun
On Oct 12, 2006, at 10:25 PM, Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 12, 2006, at 3:27 PM, Anthony Baxter wrote: 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. Why can't we get buildbot to do most or all of this? At work, we have buildbot slaves that post installers to a share after successful checkout, build, and test on all our supported platforms. The windows build is a single command, but I test the output on 3 different platforms (10.3/ppc, 10.4/ppc and 10.4/x86). If buildbot supports such a configuration I'd be very interested (and not just for Python itself). Ronald smime.p7s Description: S/MIME cryptographic 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] 2.3.6 for the unicode buffer overrun
On Friday 13 October 2006 06:25, Barry Warsaw wrote: On Oct 12, 2006, at 3:27 PM, Anthony Baxter wrote: 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. Why can't we get buildbot to do most or all of this? At work, we have buildbot slaves that post installers to a share after successful checkout, build, and test on all our supported platforms. Speaking for myself, I'd rather do it by hand, if it's not a lot of work (which it isn't) - I don't like the idea of official releases just being an automated thing. If you're instead just talking about daily builds, maybe, but we'd need to have some new way to do versioning for these. -- 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
Barry Warsaw schrieb: Why can't we get buildbot to do most or all of this? Very easy. Because somebody has to set it up. I estimate a man month or so before it works. 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
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. 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
Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 12, 2006, at 4:08 AM, Anthony Baxter wrote: I've had a couple of queries about whether PSF-2006-001 merits a 2.3.6. Personally, I lean towards no - 2.4 was nearly two years ago now. But I'm open to other opinions - I guess people see the phrase buffer overrun and they get scared. Plus once 2.4.4 final is out next week, I'll have cut 12 releases since March. Assuming a 2.5.1 before March (very likely) that'll be 14 releases in 12 months. 16 releases in 12 months would just about make me go crazy. I've offered in the past to dust off my release manager cap and do a 2.3.6 release. Having not done one in a long while, the most daunting part for me is getting the website updated, since I have none of those tools installed. I'm I the only one who feels that the website is a big workflow problem? Georg ___ 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 schrieb: ideally, releasing (earlier release + well-defined patch set) should be fairly trivial, compared to releasing (new release from trunk). what do we have to do to make it easier to handle that case? For the Windows release, I doubt there is much one can do. The time-consuming part is to run the MSI file, on three different architectures, and in various combinations (admin/no-admin, default directory/Program Files, upgrade/no-upgrade). I don't always do all of them, but still it takes a while; I usually need an hour to make a release. Plus, sometimes something goes wrong: there might a backport that doesn't work on Windows, or it might be that I broke my build environment somehow (which I normally keep across releases - if I have to start from scratch on a fresh machine, it takes much longer: a day or so). 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
On Fri, Oct 13, 2006 at 06:43:40AM +1000, Anthony Baxter wrote: On Friday 13 October 2006 06:25, Barry Warsaw wrote: On Oct 12, 2006, at 3:27 PM, Anthony Baxter wrote: 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. Why can't we get buildbot to do most or all of this? At work, we have buildbot slaves that post installers to a share after successful checkout, build, and test on all our supported platforms. Speaking for myself, I'd rather do it by hand, if it's not a lot of work (which it isn't) - I don't like the idea of official releases just being an automated thing. IMHO thats a backwards view; I'm with Barry. Requiring human intervention to do anything other than press the big green go button to launch the official release build process is an opportunity for human error. the same goes for testing the built release installers and tarballs. three macs with some virtual machines could take care of this (damn apple for not allowing their stupid OS to be virtualized). that said, i'm not volunteering to setup an automated system for this but i've got good ideas how to do it if i ever find time or someone wants to chat offline. :( as for buildbot, i haven't looked at its design but from the chatter i've seen i was under the impression that it operates on a continually updated sandbox rather than a 100% fresh checkout for each build? if thats true (is it?) i'd prefer to see a build system setup to do a fresh checkout+build of everything (including externals) in a new directory for each build in use. thats what we do at work. none of the above even considers the web site updating problem.. greg ___ 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 Thu, Oct 12, 2006 at 09:30:49PM +0200, Georg Brandl wrote: Barry Warsaw wrote: I've offered in the past to dust off my release manager cap and do a 2.3.6 release. Having not done one in a long while, the most daunting part for me is getting the website updated, since I have none of those tools installed. I'm I the only one who feels that the website is a big workflow problem? nope, you're not. ___ 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 schrieb: Should I submit it to sourceforge as a patch, or someone can review it as is? Please consider also exposing _wspawnvp, depending on whether path argument is a Unicode object or not. See PEP 277 for guidance. Since this would go into 2.6, support for Windows 95 isn't mandatory. 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] Python 2.5 performance
On Thu, Oct 12, 2006 at 11:00:09PM +0200, Martin v. L?wis wrote: Kristj?n V. J?nsson schrieb: This is an improvement of another 3.5 %. In all, we have a performance increase of more than 10%. Granted, this is from a single set of runs, but I think we should start considering to make PCBuild8 a supported build. What do you mean by that? That Python 2.5.1 should be compiled with VC 2005? Something else (if so, what)? i read that as just suggesting that updates should be checked into the release25-maint tree to get PCBuild8 working out of the box for anyone who wants to build python from source with vs2005. Since 2.5 has already shipped built with vs2003 all of the 2.5.x releases should continue to use that so that third party binary modules continue to work across 2.5.x versions. -g ___ 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
Gregory P. Smith schrieb: three macs with some virtual machines could take care of this (damn apple for not allowing their stupid OS to be virtualized). that said, i'm not volunteering to setup an automated system for this but i've got good ideas how to do it if i ever find time or someone wants to chat offline. :( Of course, that makes the idea die here and now. Without volunteers to do the actual work, it just won't happen. as for buildbot, i haven't looked at its design but from the chatter i've seen i was under the impression that it operates on a continually updated sandbox rather than a 100% fresh checkout for each build? if thats true (is it?) i'd prefer to see a build system setup to do a fresh checkout+build of everything (including externals) in a new directory for each build in use. thats what we do at work. Buildbot could do that easily; in fact, I had to explicitly configure it to not start from scratch each time, to reduce the network traffic of the donated machines. 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] Exceptions and slicing
Thomas Heller schrieb: Martin v. Löwis schrieb: Thomas Heller schrieb: 1. The __str__ of a WindowsError instance hides the 'real' windows error number. So, in 2.4 print error_instance would print for example: [Errno 1002] Das Fenster kann die gesendete Nachricht nicht verarbeiten. while in 2.5: [Error 22] Das Fenster kann die gesendete Nachricht nicht verarbeiten. That's a bug. I changed the string deliberately from Errno to error to indicate that it is not an errno, but a GetLastError. Can you come up with a patch? Yes, but not today. I submitted a patch for this issue: http://python.org/sf/1576174 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] Python 2.5 performance
On Friday 13 October 2006 07:00, Martin v. Löwis wrote: Kristján V. Jónsson schrieb: This is an improvement of another 3.5 %. In all, we have a performance increase of more than 10%. Granted, this is from a single set of runs, but I think we should start considering to make PCBuild8 a supported build. What do you mean by that? That Python 2.5.1 should be compiled with VC 2005? Something else (if so, what)? I don't think we should switch the official compiler for a point release. I'm happy to say something like we make the PCbuild8 environment a supported compiler, which means we need, at a bare minimum, a buildbot slave for that compiler/platform. Kristján, is this something you can offer? Without a buildbot for that compiler, I don't think we can claim it's supported. There's plenty of platforms we support which don't have buildslaves, but they're all variants of Unix - I'm happy that they are all mostly[1] sane. Anthony [1] Offer void on some versions of HP/UX, Irix, AIX wink -- 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
On Friday 13 October 2006 05:30, Georg Brandl wrote: I'm I the only one who feels that the website is a big workflow problem? Assuming you meant Am I, then I absolutely agree with you. -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 12, 2006, at 5:03 PM, Gregory P. Smith wrote: IMHO thats a backwards view; I'm with Barry. Requiring human intervention to do anything other than press the big green go button to launch the official release build process is an opportunity for human error. the same goes for testing the built release installers and tarballs. Oh yes, that's an important step I forgot to mention. At work, we also run automated tests of the built installers, so we have a high degree of confidence that what our buildbot farm produces at least passes the sniff test (/then/ our QA dept takes over from there). The files we upload then are named by product, platform, version, revision id, and date. It takes a manual step to delete old builds, but we have big disks so we generally don't do that except for EOL'd versions. The nice thing about that is that you can go back to almost any build and pull down a working installer. Greg hints at a major benefit of this: the knowledge for how to successfully build products is contained in scripts that are themselves revision controlled. A wiki page providing an overview and the starting points are still needed but rarely consulted. i'm not volunteering to setup an automated system for this but i've got good ideas how to do it if i ever find time or someone wants to chat offline. :( I wish I had the cycles to volunteer to help out implementing this. :( - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRS608nEjvBPtnXfVAQIypAQAtiantWJkvStPYR8tnl+AU+HzI7bZ54s1 oX8Ni0/1IbZQwYloV6UMmhwisirZ5bwAtNWfZnd3UQXFhrCC1MGlRMOWP/y6AwS2 /gSzUV9A1dxUE9iVdPy50gEMFrzrZ32g16+FsHzae/9FgklB+GjogAuYmr2vbxd4 SrB1dgEHnXg= =6rIv -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] 2.3.6 for the unicode buffer overrun
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 12, 2006, at 5:07 PM, Martin v. Löwis wrote: Of course, that makes the idea die here and now. Without volunteers to do the actual work, it just won't happen. True, and there's no carrot/stick of a salary to entice people into doing what is mostly thankless grunt work. ;) OTOH, there's always new blood with lots of time on there hands coming into the community looking for a way to distinguish themselves (read: students :). Maybe someone will step forward and win a little lemony slice of net.fame. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRS610nEjvBPtnXfVAQKtiwP/a+BfIhLupcDQwfY6AhXNxjvnh+scjqTd nutSPfHR8qdbDxAxq6YcBkMeIh55XP0QSu+gYSdDDj9dGkIP0FGhurpZVW1WFrye KEBapAmnPUnC8X5kAj0Wrw6BXacchilrH3cpC1psDtlT58TgAsUxtjmYsSKEI0ZP l+tx3jlp2Ck= =vbwS -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] Why spawnvp not implemented on Windows?
On 10/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Please consider also exposing _wspawnvp, depending on whether path argument is a Unicode object or not. See PEP 277 for guidance. Since this would go into 2.6, support for Windows 95 isn't mandatory. Umm... do you mean that spawn*p* on python 2.5 is an absolute no? ___ 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/12/06, Anthony Baxter [EMAIL PROTECTED] wrote: On Friday 13 October 2006 05:30, Georg Brandl wrote: I'm I the only one who feels that the website is a big workflow problem?Assuming you meant Am I, then I absolutely agree with you. I have touched the web site since the Pyramid switch and thus am not that active, so what I am about to say may be slightly off, but ...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. 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.-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] Python 2.5 performance
Gregory P. Smith schrieb: i read that as just suggesting that updates should be checked into the release25-maint tree to get PCBuild8 working out of the box for anyone who wants to build python from source with vs2005. That's passive voice (should be checked). I think it is unrealistic to expect that anybody making changes will make them to PCbuild8 as well if they are relevant; in many cases, no changes are made to the Windows build process at all. Fortunately, Kristjan has volunteered to maintain PCbuild8, and that's fine with me. 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
Brett Cannon wrote: On 10/12/06, *Anthony Baxter* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Friday 13 October 2006 05:30, Georg Brandl wrote: I'm I the only one who feels that the website is a big workflow problem? Assuming you meant Am I, then I absolutely agree with you. I have touched the web site since the Pyramid switch and thus am not that active, so what I am about to say may be slightly off, but ... I know AMK was experimenting with rest2web as a possible way to do the web site. +1 for rest2web ;-) There has also been talk about trying out another system. But I also know some people would rather put the effort into improving Pyramid. Actually from the little I looked at it, pyramid seemed a very good system. Particularly the SVN integration. If rest2web is a serious option and needs any customisation, I'd be happy to look into it. Michael Foord 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. -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/fuzzyman%40voidspace.org.uk No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.2/472 - Release Date: 11/10/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.2/472 - Release Date: 11/10/2006 ___ 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
Dave Abrahams schrieb: The only problem here is that there appears to be a lag in the release of ActivePython after Python itself is released. Is there any chance of putting up just the debugging libraries a little earlier? I may be out of context here: what is the precise problem in producing them yourself? Why do you need somebody else to do it for you? 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
On Friday 13 October 2006 07:34, Barry Warsaw wrote: i'm not volunteering to setup an automated system for this but i've got good ideas how to do it if i ever find time or someone wants to chat offline. :( I wish I had the cycles to volunteer to help out implementing this. :( Well, regardless of anything else, without someone doing it, it's not going to happen. I don't have the time to spend doing this. Right now, the amount of work this would save me is minimal, so I also have little or no incentive to do it. The thing that does take the time is the website - fixing that is a major investment of time, which I also don't have. Yes, had I spent the probably 20+ hours I've spent doing website stuff I could have made it a bit better, but that's what I know _now_ :) -- 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] Cloning threading.py using proccesses
Fredrik Lundh wrote: marshal hasn't changed in many years: Maybe not, but I was given to understand that it's regarded as a private format that's not guaranteed to remain constant across versions. So even if it happens not to change, it wouldn't be wise to rely on that. -- Greg ___ 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: Dave Abrahams schrieb: The only problem here is that there appears to be a lag in the release of ActivePython after Python itself is released. Is there any chance of putting up just the debugging libraries a little earlier? I may be out of context here: what is the precise problem in producing them yourself? Why do you need somebody else to do it for you? At the moment I have too weak a server to provide those files, but that will change very soon. All that said, the Python and ActiveState teams need to be aware of each and every Python release and go through a standard release procedure anyway, whereas -- except for this problem -- I would not. I'm willing to try to add it if that's what works, and of course it's easy for me to say, but I think it adds a lot more overhead for me than it would for the other two groups. -- 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?
Forgot to include python-dev... On 10/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Umm... do you mean that spawn*p* on python 2.5 is an absolute no? Yes. No new features can be added to Python 2.5.x; Python 2.5 has already been released. Ugh... that's just not fair. Because of this there will be no spawn*p* in python for another two years. x_x I have a workaround for this, that tweaks os module: [...snip wrong code...] It should have been: if (not (hasattr(os, 'spawnvpe') or hasattr(os, 'spawnvp')) and hasattr(os, 'spawnve') and hasattr(os, 'spawnv')): def _os__spawnvpe(mode, file, args, env=None): import sys from errno import ENOENT, ENOTDIR from os import path, spawnve, spawnv, environ, defpath, pathsep, error if env is not None: func = spawnve argrest = (args, env) else: func = spawnv argrest = (args,) env = environ head, tail = path.split(file) if head: return func(mode, file, *argrest) if 'PATH' in env: envpath = env['PATH'] else: envpath = defpath PATH = envpath.split(pathsep) if os.name == 'nt' or os.name == 'os2': PATH.insert(0, '') saved_exc = None saved_tb = None for dir in PATH: fullname = path.join(dir, file) try: return func(mode, fullname, *argrest) except error, e: tb = sys.exc_info()[2] if (e.errno != ENOENT and e.errno != ENOTDIR and saved_exc is None): saved_exc = e saved_tb = tb if saved_exc: raise error, saved_exc, saved_tb raise error, e, tb def _os_spawnvp(mode, file, args): return os._spawnvpe(mode, file, args) def _os_spawnvpe(mode, file, args, env): return os._spawnvpe(mode, file, args, env) def _os_spawnlp(mode, file, *args): return os._spawnvpe(mode, file, args) def _os_spawnlpe(mode, file, *args): return os._spawnvpe(mode, file, args[:-1], args[-1]) os._spawnvpe = _os__spawnvpe os.spawnvp = _os_spawnvp os.spawnvpe = _os_spawnvpe os.spawnlp = _os_spawnlp os.spawnlpe = _os_spawnlpe os.__all__.extend([spawnvp, spawnvpe, spawnlp, spawnlpe]) But the fact that I have to use similar code anywhere I need to use spawnlp is not fair. Notice that _spawnvpe is simply a clone of _execvpe from os.py, maybe if the problem is new API in c source, this approach could be used in os.py? 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. ___ 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 12, 2006, at 8:46 PM, Alexey Borzenkov wrote: Ugh... that's just not fair. Because of this there will be no spawn*p* in python for another two years. x_x Correct, but don't let that stop you. That's what distutils and the Cheeseshop are for. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRS7l+XEjvBPtnXfVAQJy6gP/RkGcTXDCBYM/WL/X+sNiTp6ydvFPg20u SrxUb/vQpNVkjA2GkFJJAXArnsxn8LB2MC+rPDRkkNMYcFw5JAUcf0IR1L+AdFnC h+68f03XDzbeB8uqVrQ6xObEPXmanvhx1uCrApqFq+zOzqMNlbzUlyGCTLu0Cw9v CYLa+aaKFAA= =dX0B -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] Why spawnvp not implemented on Windows?
[Alexey Borzenkov] Umm... do you mean that spawn*p* on python 2.5 is an absolute no? [Martin v. Löwis] Yes. No new features can be added to Python 2.5.x; Python 2.5 has already been released. [Alexey Borzenkov] Ugh... that's just not fair. Because of this there will be no spawn*p* in python for another two years. x_x Or the last 15 years. Yet somehow people still have kids ;-) ... But the fact that I have to use similar code anywhere I need to use spawnlp is not fair. Fair is a very strange word here. Pain in the ass, sure, but not fair? Doesn't make sense. ... 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. No. Introducing any new function is obviously a new feature, which would become acutely and catastrophically visible as soon as someone released code using the new function in 2.5.1, and someone tried to /use/ that new code under 2.5.0. Micro releases of Python do not introduce new features -- take that as given. It's been tried before, for what appeared to be very good reasons at the time, and we lived to regret it deeply. It won't happen again. Why every other platform can benefit from spawn*p* and only Windows can't? Just the obvious reason: because so far nobody cared enough to do the work of writing code, docs and tests for some of these functions on Windows. This just makes os.spawn*p* useless: it becomes unreliable and can't be used in portable code at all. It's certainly true that it can't be used in portable code, at least not before Python 2.6. ___ 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
Michael Foord wrote: Brett Cannon wrote: On 10/12/06, *Anthony Baxter* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Friday 13 October 2006 05:30, Georg Brandl wrote: I'm I the only one who feels that the website is a big workflow problem? Assuming you meant Am I, then I absolutely agree with you. I have touched the web site since the Pyramid switch and thus am not that active, so what I am about to say may be slightly off, but ... I know AMK was experimenting with rest2web as a possible way to do the web site. +1 for rest2web ;-) There has also been talk about trying out another system. But I also know some people would rather put the effort into improving Pyramid. Actually from the little I looked at it, pyramid seemed a very good system. Particularly the SVN integration. The real problem is the more or less complete lack of incremental rebuild, which does make site generation time-consuming. The advantage of pyramid implementation was the regularisation of the site data. I think we probably need to look at taking the now more-or-less regular data structures used to drive pyramid and find some way to use them (still with source control, but hopefully with much less verbiage) to drive something like Django. To retain the advantages of source control this might mean using scripts to generate database content from SVN-controlled data files. Or something [waves hands vaguely and steps back hopefully]. 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
David Abrahams schrieb: At the moment I have too weak a server to provide those files, but that will change very soon. All that said, the Python and ActiveState teams need to be aware of each and every Python release and go through a standard release procedure anyway, whereas -- except for this problem -- I would not. I'm willing to try to add it if that's what works, and of course it's easy for me to say, but I think it adds a lot more overhead for me than it would for the other two groups. It's a significant amount of work, either way. It will be larger for you when you do it the first time; after that, it will be the same amount of work for you that it would be for me. It will be easier for you than for me as you won't be acting under time pressure (whereas additional actions from me will delay the entire Python release, which, due to timezones, already significantly suffers from the need to create Windows binaries). 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. 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] Why spawnvp not implemented on Windows?
Alexey Borzenkov schrieb: On 10/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Umm... do you mean that spawn*p* on python 2.5 is an absolute no? Yes. No new features can be added to Python 2.5.x; Python 2.5 has already been released. Ugh... that's just not fair. Because of this there will be no spawn*p* in python for another two years. x_x It may be inconvenient, but it is certainly fair: the same rule is applied to *all* proposed new features. It would be unfair if that feature was accepted, and other features were rejected. Please try to see this from our view. If new features are added to a bugfix release (say, 2.5.1), then users (programmers) would quickly consider Python as unstable, moving target. They would use the feature, claiming that you need Python 2.5, and not knowing that it is really 2.5.*1* that you need. Users would try to run the program, and find out that it doesn't work, and complain to the author. Unhappy users, unhappy programmers, and unhappy maintainers (as the programmers would then complain which idiot allowed that feature in - they do use strong language at times). It happened once, in 2.2.1 (IIRC) with the introduction of True and False. It was very painful and lead to a lot of bad code, and it still hasn't settled. As you already have a work-around: what is the problem waiting for 2.6, for you personally? If you want to see the feature eventually, please do submit it to sourceforge, anyway. 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
On Friday 13 October 2006 12:56, Steve Holden wrote: The real problem is the more or less complete lack of incremental rebuild, which does make site generation time-consuming. That's _part_ of it. There's other issues. For instance, there's probably 4 places where the list of releases is stored. Every time I do a release, I need to update all of these. If it's a new release, I also have to update the apache config for the /X.Y.Z redirect (anyone who thinks a default URL of www.python.org/download/releases/X.Y.Z is a good idea needs to quit drinking before lunchtime wink) Creating a new release area, or hell, even a new page, is a whole pile of fiddly files. These still don't make sense to me - I end up copying an existing page each time, then reading through them looking for the relevant pieces of text. Personally, I can mostly deal with the reST now, although it still trips me up on a regular basis. YAML as well is just way more complexity - I don't understand the syntax, but it appears to offer massively more than we actually use. The advantage of pyramid implementation was the regularisation of the site data. Sure - and hopefully if we go down another path we can get that out. To retain the advantages of source control this might mean using scripts to generate database content from SVN-controlled data files. Or something [waves hands vaguely and steps back hopefully]. The other thing to watch out for is that I (or whoever) can still do local work on a bunch of different files, then check it in all in one hit once it's done and checked. This was an issue I had with the various wiki-based proposals, I haven't seen many wikis that allow 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] Why spawnvp not implemented on Windows?
On Friday 13 October 2006 10:46, Alexey Borzenkov wrote: But the fact that I have to use similar code anywhere I need to use spawnlp is not fair. Notice that _spawnvpe is simply a clone of _execvpe from os.py, maybe if the problem is new API in c source, this approach could be used in os.py? Oddly, fair isn't a constraint in PEP-0006. Backwards and forwards compatibility between all point releases in a major release is. Adding it to os.py rather than C code doesn't make a difference. 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. One might say that. I wouldn't. It stays out until 2.6. Sorry 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] Cloning threading.py using proccesses
Greg Ewing wrote: Fredrik Lundh wrote: marshal hasn't changed in many years: Maybe not, but I was given to understand that it's regarded as a private format that's not guaranteed to remain constant across versions. So even if it happens not to change, it wouldn't be wise to rely on that. but given that the format *has* been stable for many years, surely it would make more sense to just codify that fact, rather than developing Yet Another Serialization Format 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
