Re: [Python-Dev] Plea to distribute debugging lib

[Dave Abrahams]

Trent Mick  ActiveState.com> writes:

> 
> [Thomas Heller wrote]
> > Anyway, AFAIK, the activestate distribution contains Python debug dlls.
> 
> [Er, a month late, but I was in flitting around Australia at the time. :)]
> 
> Yes, as a separate download.
> 
> ftp://ftp.activestate.com/ActivePython/etc/
> ActivePython--win32-ix86-debug.zip
> 
> And those should be binary compatible with the equivalent python.org
> installs as well. Note that the simple "install.py" script in those
> packages bails if the Python installation isn't ActivePython, but I
> could easily remove that if you think that would be useful for your
> users.

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?

Thanks again,
Dave


___
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] 2.3.6 for the unicode buffer overrun

[Anthony Baxter]

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

[Anthony Baxter]

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

[Fredrik Lundh]

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?

 



___
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

[Nick Craig-Wood]

On Thu, Oct 12, 2006 at 06:08:46PM +1000, 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.

As a data point: python 2.3 is the shipped version of python in
current stable Debian release (sarge).  It is also vulnerable by
default (sys.maxunicode == 1114111).

I'm sure the debian maintainers are capable of picking up the patch
and sending out a security update themselves, but by releasing a fixed
2.3 you'll send a stronger message to all the distributions hopefully!

> 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 sympathise!  I do released for my current workplace and it is time
consuming and exacting work.
-- 
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
___
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?

[Armin Rigo]

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] 2.4.4: backport classobject.c HAVE_WEAKREFS?

[Fredrik Lundh]

Armin Rigo 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.

umm. last time I checked, the tp fields lived in the type object, not in the
instance.

 



___
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

[Nick Maclaren]

"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

[Nick Maclaren]

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

[Nick Maclaren]

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

[Nick Maclaren]

=?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

[Audun Ostrem Nordal]

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

[Greg Willden]

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

[Kristján V . Jónsson]

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 

Re: [Python-Dev] Cloning threading.py using proccesses

[Richard Oudkerk]

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

[Richard Oudkerk]

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

[Raymond Hettinger]

> 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?

[Alexey Borzenkov]

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

[Barry Warsaw]

-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

[Terry Reedy]

"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

[Barry Warsaw]

-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?

[Alexey Borzenkov]

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?

[Aahz]

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

[Anthony Baxter]

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

[Barry Warsaw]

-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

[Giovanni Bajo]

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

[Ronald Oussoren]

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

[Anthony Baxter]

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

[Martin v. Löwis]

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

[Martin v. Löwis]

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

[Georg Brandl]

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

[Martin v. Löwis]

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] Python 2.5 performance

[Martin v. Löwis]

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)?

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

[Gregory P. Smith]

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

[Gregory P. Smith]

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?

[Martin v. Löwis]

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

[Gregory P. Smith]

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

[Martin v. Löwis]

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]

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

[Anthony Baxter]

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  
-- 
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]

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

[Barry Warsaw]

-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

[Barry Warsaw]

-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?

[Alexey Borzenkov]

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

[Brett Cannon]

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] Why spawnvp not implemented on Windows?

[Ronald Oussoren]

On Oct 12, 2006, at 11:53 PM, Alexey Borzenkov wrote:


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?


Unless you have a time machine and manage to get it in before 2.5.0  
is released :-). Micro releases (2.5.1, 2.5.2, ...) only contain  
bugfixes, not new features.


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] Why spawnvp not implemented on Windows?

[Martin v. Löwis]

Alexey Borzenkov schrieb:
> 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?

Yes. No new features can be added to Python 2.5.x; Python 2.5 has
already been released.

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

[Martin v. Löwis]

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

[Michael Foord]

Brett Cannon wrote:
> 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. 
+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

[Martin v. Löwis]

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

[Anthony Baxter]

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

[Greg Ewing]

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

[David Abrahams]

"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?

[Alexey Borzenkov]

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?

[Barry Warsaw]

-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?

[Tim Peters]

[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

[Steve Holden]

Michael Foord wrote:
> Brett Cannon wrote:
> 
>>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. 
> 
> +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

[Martin v. Löwis]

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?

[Martin v. Löwis]

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

[Anthony Baxter]

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 )

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?

[Anthony Baxter]

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] 2.3.6 for the unicode buffer overrun

[Brian Warner]

"Gregory P. Smith" <[EMAIL PROTECTED]> writes:

> 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?

It's a configuration option. If you use mode="update" then your builds will
re-use the same source directory over and over, if you use mode="clobber"
then your builds will get a brand new checkout each time, and if you use
mode="copy" then the source is updated in-place in one directory, but each
build is performed from a copy of that checkout. Each offers different
tradeoffs between disk usage, network usage, and which sorts of Makefile bugs
they are likely to discover.

cheers,
 -Brian (Buildbot author)

___
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]

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?



___
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]

Brett Cannon wrote:

> I know AMK was experimenting with rest2web as a possible way to do the 
> web site.  There has also been talk about trying out another system.  
> But I also know some people would rather put the effort into improving 
> Pyramid.

You forgot the ponies!

> Once again, it's a matter of people putting the time in to make a switch 
> happen to a system that the site maintainers would be happy with.

The people behind the current system and process has invested way too 
much energy and prestige in the current system to ever accept that the 
result is pretty lousy as a site, and complete rubbish as technology. 
It's about sunk costs, not cost- and time-effective solutions.

For reference, here's my effbot.org release procedure:

1) upload the distribution files one by one, as soon as they're 
available.  all links and stuff will appear automatically

2) update the associated description text through the web, when 
necessary, as an HTML fragment.  click "save" to publish.

3) mail out an announcement when everything looks good.

Maybe I should offer Anthony to do the releases via effbot.org instead?



___
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]

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.



___
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]

> For reference, here's my effbot.org release procedure:
>
> 1) upload the distribution files one by one, as soon as they're
> available.  all links and stuff will appear automatically
>
> 2) update the associated description text through the web, when
> necessary, as an HTML fragment.  click "save" to publish.
>
> 3) mail out an announcement when everything looks good.
>
> Maybe I should offer Anthony to do the releases via effbot.org instead?

First off - I'm not going to be posting 10M or 16M files through a 
web-browser. That's insane :-)

The bit of the website that's dealing with the actual files is not the tricky 
bit - I have a dinky little python script that generates the download table. 
The problems are with the other bits of the pages. I keep thinking "next 
release, I'll automate it further", but never have time on the day. 

-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why spawnvp not implemented on Windows?

[Fredrik Lundh]

Alexey Borzenkov wrote:

> P.S. Although it's a bit stretching, one might also say that
> implementing spawn*p* on windows is not actually a new feature, and
> rather is a bugfix for misfeature. Why every other platform can
> benefit from spawn*p* and only Windows can't? This just makes
> os.spawn*p* useless: it becomes unreliable and can't be used in
> portable code at all.

any reason you cannot just use the "subprocess" module instead, like 
everyone else?



___
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