Re: [Python-Dev] subprocess crossplatformness and async communication

[anatoly techtonik]

Hi, Guido

You can't launch a process and communicate with it without blocking at
some point. The scenario where you can periodically check output and
error pipes without blocking and send input is not supported.

Scenario One: control console program. This implies reading from input
and writing replies asyncronously
- Popen.stdin, stdout, stderr - stdin.write(), stdout.read() or
stderr.read() block script execution if any of the other OS pipe
buffers fills up and blocks the child process. Advice is to use
communicate(), but it waits for process to exit and hence doesn't
allow to send the input based on reply from previous send.

Scenario Two: waiting for process that terminates with extensive output blocks
- Popen.wait() blocks if the child process generates enough output to
a stdout or stderr pipe, advice is to use Popen.communicate()
http://docs.python.org/library/subprocess.html#subprocess.Popen.wait
- Popen.communicate() - Waits for process to terminate, reads data
from stdout and stderr until end-of-file. Cashes data in memory -
should not be used for if the data size is large or unlimited.

Solution - read(maxsize) and write(maxsize) functions that will return
immediately.

-- 
anatoly t.

On Sat, Jan 24, 2009 at 5:58 PM, Guido van Rossum  wrote:
> Anatoly,
>
> I'm confused. The subprocess already allows reading/writing its
> stdin/stdout/stderr, and AFAIK it's a platform-neutral API. I'm sure
> there's something missing, but your post doesn't make it clear what
> exactly, and the recipe you reference is too large to digest easily.
> Can you explain what it is that the current subprocess does't have
> beyond saying "async communication" (which could mean many things to
> many people)?
>
> --Guido
>
> On Sat, Jan 24, 2009 at 5:07 AM, anatoly techtonik  
> wrote:
>> Greetings,
>>
>> This turned out to be a rather long post that in short can be summarized as:
>> "please-please-please, include asynchronous process communication in
>> subprocess module and do not allow "available only on ..."
>> functionality", because it hurts the brain".
>>
>> Code to speak for itself: http://code.activestate.com/recipes/440554/
>>
>>
>> The subprocess module was a great step forward to unify various spawn
>> and system and exec and etc. calls in one module, and more importantly
>> - in one uniform API. But this API is partly crossplatform, and I
>> believe I've seen recent commits to docs with more unix-only
>> differences in this module.
>>
>> The main point of this module is to "allows you to spawn new
>> processes, connect to their input/output/error pipes, and obtain their
>> return codes". PEP 324 goal is also to make "make Python an even
>> better replacement language for over-complicated shell scripts".
>>
>> Citing pre-subrocess PEP 324, "Currently, Python has a large number of
>> different functions for process creation. This makes it hard for
>> developers to choose." Now there is one class with many methods and
>> many platform-specific comments and notices. To make thing worse
>> people on Unix use subprocess with fcntl and people on windows tend
>> not to use it at all, because it looks complicated and doesn't solve
>> the problem with asynchronous communication.
>>
>> That I suggest is to add either support for async crossplatfrom
>> read/write/probing of executed process or a comment at the top of
>> module documentation that will warn that subprocess works in blocking
>> mode. With async mode you can emulate blocking, the opposite is not
>> possible. This will save python users a lot of time.
>>
>> Thanks for reading my rant.
>>
>>
>> BTW, the proposed change is top 10 python recipe on ActiveState
>> http://code.activestate.com/recipes/langs/python/
>>
>> --
>> --anatoly t.
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: 
>> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>



-- 
--anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[David Cournapeau]

On Mon, Jan 26, 2009 at 1:38 PM, Stephen J. Turnbull  wrote:

>
> Again, I don't take the cost of learning a new tool lightly, but
> please let's call that cost by its name, and not bring "distributed"
> into it.

I can only strongly agree on this point - most people asserting that
DVCS are much more complicated than CVS/SVN/etc..., forget their long
experience with the later. I had little experience with svn before
using bzr, and I find bzr much simpler than svn in almost every way,
both for personal projects and more significant open source projects.

>
> That's false.  Again, those people who want to use a DVCS as a DVCS
> will benefit from having the master repository(s) coordinate history
> for them.  This doesn't work very well across VCS systems, essentially
> forcing all committers who want to use the distributed features to
> coordinate with each other directly, and only with those who use the
> same DVCS.  The mental models used by git users, hg users, and bzr
> users differ significantly, though they probably differ more from the
> model that's appropriate for Subversion.  Nevertheless, there is a lot
> of potential benefit to be gained from having a common DVCS for all
> developers.

Agreed. A point shared by all svn-to-bzr/git/whatever in my experience
is the pain of merging. In particular, although git-svn on top of svn
is very useful, and brings some power of git without forcing git pain
on other users, merging between branches is not really doable without
going back to svn. And that's certainly a big plus of DVCS compared to
svn: since svn is inherently incapable of tracking merge (at least
until recently, I have no experience with 1.5), you can't use svn as a
backend and benefeting from all the DVCS advantages at the same time.

cheers,

David
___
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] subprocess crossplatformness and async communication

[Nick Craig-Wood]

On Sat, Jan 24, 2009 at 07:58:40AM -0800, Guido van Rossum wrote:
> I'm confused. The subprocess already allows reading/writing its
> stdin/stdout/stderr, and AFAIK it's a platform-neutral API. I'm sure
> there's something missing, but your post doesn't make it clear what
> exactly, and the recipe you reference is too large to digest easily.
> Can you explain what it is that the current subprocess does't have
> beyond saying "async communication" (which could mean many things to
> many people)?

The main problem with subprocess is that it doesn't work if you want
to have a conversation / interact with your child process.

subprocess works very well indeed for this case :-

  run child
  send stuff to stdin
  child reads stdin and writes stdout
  child exits
  read stuff from stdout

But for the conversational case (eg using it to do a remote login) it
doesn't work at all :-

  run child
  send stuff to stdin
  child reads stdin and writes stdout
  read stuff from stdout
  send stuff to stdin
  child reads stdin and writes stdout
  read stuff from stdout
  send stuff to stdin
  child reads stdin and writes stdout
  read stuff from stdout
  child exits

In subprocess "read stuff from stdout" means read stdout until the
other end closes it, not read what is available and return it, so it
blocks on reading the first reply and never returns.

Hence Anatoly's request for "async communication" and the existence of
that recipe.

  http://code.activestate.com/recipes/440554/

I've spend quite a lot of time explaning this to people on
comp.lang.python.  I usually suggest either the recipe as suggested by
Anatoly or if on unix the pexpect module.  There are other solutions I
know of, eg in twisted and wxPython.

I heard rumours of a pexpect port to Windows but I don't know how far
that has progressed.

A cross platform async subprocess would indeed be a boon!

-- 
Nick Craig-Wood  -- 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] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.

[Nick Coghlan]

Scott Dial wrote:
> I think
> it's been made clear that nobody is opposed to having an all-free build
> of Python for Win32, however it is not the focus of anyone's interest
> here because it's "free enough" for our purposes. I believe Martin wrote
> you a reply that explained that quite well.

One thing to keep in mind is the fact that CPython uses a BSD-style
licensing model and hence will tend to attract developers that have no
problem with the idea of someone making a proprietary fork of our code.
One consequence of this self-selection process is that the Python core
developers aren't likely to see anything inherently wrong with the idea
of closed source proprietary software (it may be an inefficient and
wasteful method of development when it comes to commodity software, but
it isn't actually morally *wrong* in any way).

Visual Studio is the best available tool for native Windows C/C++
development and these days it even comes with the free-as-in-beer
Express edition. The fact that VS is itself a non-free closed source
application may bother developers out there with a stronger
philosophical preference for free software, but it doesn't really bother
me or, I believe, most of the core committers in the slightest.

I have no problem with anyone that dislikes non-free software and
chooses to opt out of the Windows world altogether (I myself use my
Windows machine almost solely to play games, as I prefer Linux for
development and general computing tasks). But if a developer decides
(for whatever reason) to opt into that world and support the platform,
it doesn't make any sense to me to complain that the recommended tools
for developing in a non-free environment are themselves non-free (at
least in the software libre sense). Going "Oh, I may be targeting a
non-free platform, but at least I used free software tools to do it"
strikes me as sheer sophistry and a fairly pointless waste of time.

If a developer can't even find someone to either build Windows binaries
for them or else to donate the cash for a single Windows license to run
Visual Studio Express in a virtual machine, then it seems to me that any
supposed demand for Windows support must be pretty damn tenuous.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] subprocess crossplatformness and async communication

[Hrvoje Niksic]

Nick Craig-Wood wrote:

But for the conversational case (eg using it to do a remote login) it
doesn't work at all :-

  run child
  send stuff to stdin
  child reads stdin and writes stdout


Can this really be made safe without an explicit flow control protocol, 
such as a pseudo-TTY?  stdio reads data from pipes such as stdin in 4K 
or so chunks.  I can easily imagine the child blocking while it waits 
for its stdin buffer to fill, while the parent in turn blocks waiting 
for the child's output arrive.


Shell pipelines (and the subprocess module as it stands) don't have this 
problem because they're unidirectional: you read input from one process 
and write output to another, but you typically don't feed data back to 
the process you've read it from.

___
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] subprocess crossplatformness and async communication

[Daniel Stutzbach]

I'm confused.  What's wrong with the following?

p = Popen('do_something', stdin=PIPE, stdout=PIPE)
p.stdin.write('la la la\n')
p.stdin.flush()
line = p.stdout.readline()
p.stdin.write(process(line))
p.stdin.flush()

If you want to see if data is available on p.stdout, use the select module
(unless you're on Windows).

The child process has to flush its output buffer for this to work, but that
isn't Python's problem.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Paul Hummer]

On Mon, 26 Jan 2009 17:44:15 +0900, David Cournapeau 
wrote:

> >
> > Again, I don't take the cost of learning a new tool lightly, but
> > please let's call that cost by its name, and not bring "distributed"
> > into it.
> 
> I can only strongly agree on this point - most people asserting that
> DVCS are much more complicated than CVS/SVN/etc..., forget their long
> experience with the later. I had little experience with svn before
> using bzr, and I find bzr much simpler than svn in almost every way,
> both for personal projects and more significant open source projects.
> 
> >
> > That's false.  Again, those people who want to use a DVCS as a DVCS
> > will benefit from having the master repository(s) coordinate history
> > for them.  This doesn't work very well across VCS systems, essentially
> > forcing all committers who want to use the distributed features to
> > coordinate with each other directly, and only with those who use the
> > same DVCS.  The mental models used by git users, hg users, and bzr
> > users differ significantly, though they probably differ more from the
> > model that's appropriate for Subversion.  Nevertheless, there is a lot
> > of potential benefit to be gained from having a common DVCS for all
> > developers.
> 
> Agreed. A point shared by all svn-to-bzr/git/whatever in my experience
> is the pain of merging. In particular, although git-svn on top of svn
> is very useful, and brings some power of git without forcing git pain
> on other users, merging between branches is not really doable without
> going back to svn. And that's certainly a big plus of DVCS compared to
> svn: since svn is inherently incapable of tracking merge (at least
> until recently, I have no experience with 1.5), you can't use svn as a
> backend and benefeting from all the DVCS advantages at the same time.
> 

At a previous employer, we had this same discussion about switching to a DVCS,
and the time and cost required to learn the new tool.  We switched to bzr, and
while there were days where someone got lost in the DVCS, the overall
advantages with merging allowed that cost to be offset by the fact that merging
was so cheap (and we merged a lot).

That's a big consideration to be made when you're considering a DVCS.  Merges
in SVN and CVS can be painful, where merging well is a core feature of any
DVCS.

-- 
Paul Hummer
http://theironlion.net
1024/862FF08F C921 E962 58F8 5547 6723 0E8C 1C4D 8AC5 862F F08F
___
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] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.

[Ulrich Eckhardt]

On Sunday 25 January 2009, Luke Kenneth Casson Leighton wrote:
> matthieu, thank you for responding.  from
> http://en.wikipedia.org/wiki/Dynamic-link_library:
>
> "Third, dynamic linking is inherently the wrong model for paged memory
> managed systems. Such systems work best with the idea that code is
> invariant from the time of assembly/compilation on.
> ... Data references do not need to be so vectored because
>  DLLs do not share data."
> 
>
> does anyone happen to know what this means?

I can only guess: The difference between code and data is that code can be 
loaded into a process by simply mapping it into the virtual memory. For data 
that is constant, the same applies. For non-const data, you absolutely must 
not do that though, because it would make processes interfere with each 
other, and that is what the above text probably means.

So, the important difference is rather that read-only stuff can be 
memory-mapped while read-write stuff can't. Since code is read-only (barring 
self-modifying code and trampolines etc), it is automatically always 
sharable.

> curt, thank you for responding.  i'd seen this: i understood it -
> and... yet... mingw happily segfaults when asked to access _any_ data
> in _any_ object file of the python2N dll.

Dump the address of said data and its size from inside that DLL and from 
outside just to see if they differ, both from the same process. I'd also dump 
the size, in case different compiler settings messed up padding or something 
like that.

> from looking so far. e.g. i expected MSVCRT.DLL errno to be an
> int - it's not: it's a function).

'errno' can't be an int, because it needs to be thread-local. Also, note the 
important difference between "errno is an int" and "errno yields an lvalue of 
type int". The latter is how the standard defines it.

> *sigh*.  if this turns out to be yet another gcc / mingw bug i'm going
> to be slightly annoyed.  only slightly, because this _is_ free
> software, after all :)

Can you reproduce this with a separate example?

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

___
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] FormatError() in callproc.c under win32

[Ulrich Eckhardt]

Hi!

In callproc.c from trunk is a function called SetException(), which calls 
FormatError() only to discard the contents. Can anyone enlighten me to the 
reasons thereof? Is it just to check if the errorcode is registered in the 
stringtables?

The reason I ask is the CE port. The FormatMessage API exists there (or, 
rather, the FormatMessageW API), but the tables containing the error messages 
are optional for the OS and for space reasons many vendors chose not to 
include them. That means that the function there regularly fails to retrieve 
the requested string.

My first approach was to fall back to simply providing a sting with a numeric 
representation of the errorcode, but that would change the meaning of above 
function, because then it could never fails.

My second approach was to enhance PyErr_SetFromWindowsErr() to handle the 
additional error codes that are checked in SetException(). However, those 
require more context than just the error code, they use the EXCEPTION_RECORD 
passed to SetException() for that.

My third approach would be to filter out the special error codes first and 
delegate all others to PyErr_SetFromWindowsErr(). The latter already handles 
the lack of a string for the code by formatting it numerically. This would 
also improve consistency, since the two functions use different ways to 
format unrecognised errors numerically. This approach would change where and 
how a completely unrecognised error code is formatted, but would otherwise be 
pretty equivalent.


Suggestions?

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Guido van Rossum]

On Mon, Jan 26, 2009 at 8:08 AM, Paul Hummer  wrote:
> At a previous employer, we had this same discussion about switching to a DVCS,
> and the time and cost required to learn the new tool.  We switched to bzr, and
> while there were days where someone got lost in the DVCS, the overall
> advantages with merging allowed that cost to be offset by the fact that 
> merging
> was so cheap (and we merged a lot).
>
> That's a big consideration to be made when you're considering a DVCS.  Merges
> in SVN and CVS can be painful, where merging well is a core feature of any
> DVCS.

I hear you. I for one have been frustrated (now that you mention it)
by the inability to track changes across merges. We do lots of merges
from the trunk into the py3k branch, and the merge revisions in the
branch quotes the full text of the changes merged from the trunk, but
not the list of affected files for each revision merged. Since merges
typically combine a lot of revisions, it is very painful to find out
more about a particular change to a file when that change came from
such a merge -- often even after reading through the entire list of
descriptions you still have no idea which merged revision is
responsible for a particular change. Assuming this problem does not
exist in DVCS, that would be a huge bonus from switching to a DVCS!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] IDLE docs at python.org/idle

[Georg Brandl]

(re #5066)

Is that documentation maintained in some way?  Shouldn't it be merged
into the main docs?

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] subprocess crossplatformness and async communication

[Guido van Rossum]

On Mon, Jan 26, 2009 at 12:44 AM, anatoly techtonik  wrote:
> You can't launch a process and communicate with it without blocking at
> some point. The scenario where you can periodically check output and
> error pipes without blocking and send input is not supported.
>
> Scenario One: control console program. This implies reading from input
> and writing replies asyncronously
> - Popen.stdin, stdout, stderr - stdin.write(), stdout.read() or
> stderr.read() block script execution if any of the other OS pipe
> buffers fills up and blocks the child process. Advice is to use
> communicate(), but it waits for process to exit and hence doesn't
> allow to send the input based on reply from previous send.
>
> Scenario Two: waiting for process that terminates with extensive output blocks
> - Popen.wait() blocks if the child process generates enough output to
> a stdout or stderr pipe, advice is to use Popen.communicate()
> http://docs.python.org/library/subprocess.html#subprocess.Popen.wait
> - Popen.communicate() - Waits for process to terminate, reads data
> from stdout and stderr until end-of-file. Cashes data in memory -
> should not be used for if the data size is large or unlimited.
>
> Solution - read(maxsize) and write(maxsize) functions that will return
> immediately.

Hi Anatoly -- thanks for clarifying your issues. I hope other
developers more familiar with subprocess.py will chime in and either
help you figure out a way to do this without changes to the subprocess
module, or, if that would be too painful, help you develop additional
APIs. You could start by proposing a set of changes to subprocess.py
and submit them as a patch to bugs.python.org; that is easier to deal
with than pointing to a recipe on the Activestate site.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] IDLE docs at python.org/idle

[Terry Reedy]

Georg Brandl wrote:

re

http://bugs.python.org/issue5066


Is that documentation maintained in some way?


Not currently, pretty obviously. Screenshots are 1.5.2.  Windows was 95/98.


Shouldn't it be merged into the main docs?


If and only if updated.  As noted on the issue, I am willing to help.

Terry Jan Reedy

___
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] FormatError() in callproc.c under win32

[Thomas Heller]

Ulrich Eckhardt schrieb:
> Hi!
> 
> In callproc.c from trunk is a function called SetException(), which calls 
> FormatError() only to discard the contents. Can anyone enlighten me to the 
> reasons thereof? Is it just to check if the errorcode is registered in the 
> stringtables?

I think that your guess is somewhat similar to what I thought when I
wrote the code.

> 
> The reason I ask is the CE port. The FormatMessage API exists there (or, 
> rather, the FormatMessageW API), but the tables containing the error messages 
> are optional for the OS and for space reasons many vendors chose not to 
> include them. That means that the function there regularly fails to retrieve 
> the requested string.
> 
> My first approach was to fall back to simply providing a sting with a numeric 
> representation of the errorcode, but that would change the meaning of above 
> function, because then it could never fails.
> 
> My second approach was to enhance PyErr_SetFromWindowsErr() to handle the 
> additional error codes that are checked in SetException(). However, those 
> require more context than just the error code, they use the EXCEPTION_RECORD 
> passed to SetException() for that.
> 
> My third approach would be to filter out the special error codes first and 
> delegate all others to PyErr_SetFromWindowsErr(). The latter already handles 
> the lack of a string for the code by formatting it numerically. This would 
> also improve consistency, since the two functions use different ways to 
> format unrecognised errors numerically. This approach would change where and 
> how a completely unrecognised error code is formatted, but would otherwise be 
> pretty equivalent.

The third approach is fine with me.  Sidenote: The only error codes that I 
remember
having seen in practice are 'access violation reading...' and 'access violation 
writing...',
although it may be that on WinCE 'datatype misalignment' may also be possible.

-- 
Thanks,
Thomas

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] enabling a configure option

[Antoine Pitrou]

Hello python-dev,

r68924 in py3k introduced a new configure option named --with-computed-gotos. It
would be nice if one of the buildbots could exercise this option, so that the
code doesn't rot (the buildbot has to use gcc). Whom should I ask for this?

Speaking of which, there are only five buildbots remaining in the "stable"
bunch... What has happened to the others?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Giovanni Bajo]

On Mon, 26 Jan 2009 10:31:55 -0800, Guido van Rossum wrote:

> On Mon, Jan 26, 2009 at 8:08 AM, Paul Hummer 
> wrote:
>> At a previous employer, we had this same discussion about switching to
>> a DVCS, and the time and cost required to learn the new tool.  We
>> switched to bzr, and while there were days where someone got lost in
>> the DVCS, the overall advantages with merging allowed that cost to be
>> offset by the fact that merging was so cheap (and we merged a lot).
>>
>> That's a big consideration to be made when you're considering a DVCS. 
>> Merges in SVN and CVS can be painful, where merging well is a core
>> feature of any DVCS.
> 
> I hear you. I for one have been frustrated (now that you mention it) by
> the inability to track changes across merges. We do lots of merges from
> the trunk into the py3k branch, and the merge revisions in the branch
> quotes the full text of the changes merged from the trunk, but not the
> list of affected files for each revision merged. Since merges typically
> combine a lot of revisions, it is very painful to find out more about a
> particular change to a file when that change came from such a merge --
> often even after reading through the entire list of descriptions you
> still have no idea which merged revision is responsible for a particular
> change. Assuming this problem does not exist in DVCS, that would be a
> huge bonus from switching to a DVCS!

Well, not only it does not exist by design in any DVCS, but I have a 
better news: it does not exist anymore in Subversion 1.5. You just need 
to upgrade your SVN server to 1.5, migrate your merge history from the 
format of svnmerge to the new builtin format (using the official script), 
and you're done: say hello to "-g/--use-merge-history", to be use with 
svn log and svn blame.

This is a good writeup of the new features:
http://chestofbooks.com/computers/revision-control/subversion-svn/Merge-
Sensitive-Logs-And-Annotations-Branchmerge-Advanced-Lo.html
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.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] enabling a configure option on a buildbot

[Antoine Pitrou]

(Apologies for the incomplete title! I sometimes eat my words...)


Antoine Pitrou  pitrou.net> writes:
> 
> Hello python-dev,
> 
[snip]


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Guido van Rossum]

On Mon, Jan 26, 2009 at 1:57 PM, Giovanni Bajo  wrote:
> On Mon, 26 Jan 2009 10:31:55 -0800, Guido van Rossum wrote:
>
>> On Mon, Jan 26, 2009 at 8:08 AM, Paul Hummer 
>> wrote:
>>> At a previous employer, we had this same discussion about switching to
>>> a DVCS, and the time and cost required to learn the new tool.  We
>>> switched to bzr, and while there were days where someone got lost in
>>> the DVCS, the overall advantages with merging allowed that cost to be
>>> offset by the fact that merging was so cheap (and we merged a lot).
>>>
>>> That's a big consideration to be made when you're considering a DVCS.
>>> Merges in SVN and CVS can be painful, where merging well is a core
>>> feature of any DVCS.
>>
>> I hear you. I for one have been frustrated (now that you mention it) by
>> the inability to track changes across merges. We do lots of merges from
>> the trunk into the py3k branch, and the merge revisions in the branch
>> quotes the full text of the changes merged from the trunk, but not the
>> list of affected files for each revision merged. Since merges typically
>> combine a lot of revisions, it is very painful to find out more about a
>> particular change to a file when that change came from such a merge --
>> often even after reading through the entire list of descriptions you
>> still have no idea which merged revision is responsible for a particular
>> change. Assuming this problem does not exist in DVCS, that would be a
>> huge bonus from switching to a DVCS!
>
> Well, not only it does not exist by design in any DVCS, but I have a
> better news: it does not exist anymore in Subversion 1.5. You just need
> to upgrade your SVN server to 1.5, migrate your merge history from the
> format of svnmerge to the new builtin format (using the official script),
> and you're done: say hello to "-g/--use-merge-history", to be use with
> svn log and svn blame.
>
> This is a good writeup of the new features:
> http://chestofbooks.com/computers/revision-control/subversion-svn/Merge-
> Sensitive-Logs-And-Annotations-Branchmerge-Advanced-Lo.html

Unfortunately I've heard we shouldn't upgrade to svn 1.5 until more
Linux distributions ship with it by default.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] FormatError() in callproc.c under win32

[Martin v. Löwis]

> In callproc.c from trunk is a function called SetException(), which calls 
> FormatError() only to discard the contents. Can anyone enlighten me to the 
> reasons thereof? 

Interestingly enough, the code used to say

   PyErr_SetString(PyExc_WindowsError, lpMsgBuf);

Then it was changed to its current form, with a log message of

   Changes for windows CE, contributed by Luke Dunstan.  Thanks a lot!

See

http://ctypes.cvs.sourceforge.net/viewvc/ctypes/ctypes/source/callproc.c?hideattic=0&r1=1.127.2.15&r2=1.127.2.16

I suggest you ask Thomas Heller and Luke Dunstan (if available) what the
rationale for this partial change was.

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] IDLE docs at python.org/idle

[Martin v. Löwis]

> Is that documentation maintained in some way?

I don't think so. It isn't in the pydotorg repository, and the
files were last touched in 2005.

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] PEP 374 (DVCS) now in reST

[Jeffrey Yasskin]

On Mon, Jan 26, 2009 at 2:00 PM, Guido van Rossum  wrote:
> On Mon, Jan 26, 2009 at 1:57 PM, Giovanni Bajo  wrote:
>> On Mon, 26 Jan 2009 10:31:55 -0800, Guido van Rossum wrote:
>>
>>> On Mon, Jan 26, 2009 at 8:08 AM, Paul Hummer 
>>> wrote:
 At a previous employer, we had this same discussion about switching to
 a DVCS, and the time and cost required to learn the new tool.  We
 switched to bzr, and while there were days where someone got lost in
 the DVCS, the overall advantages with merging allowed that cost to be
 offset by the fact that merging was so cheap (and we merged a lot).

 That's a big consideration to be made when you're considering a DVCS.
 Merges in SVN and CVS can be painful, where merging well is a core
 feature of any DVCS.
>>>
>>> I hear you. I for one have been frustrated (now that you mention it) by
>>> the inability to track changes across merges. We do lots of merges from
>>> the trunk into the py3k branch, and the merge revisions in the branch
>>> quotes the full text of the changes merged from the trunk, but not the
>>> list of affected files for each revision merged. Since merges typically
>>> combine a lot of revisions, it is very painful to find out more about a
>>> particular change to a file when that change came from such a merge --
>>> often even after reading through the entire list of descriptions you
>>> still have no idea which merged revision is responsible for a particular
>>> change. Assuming this problem does not exist in DVCS, that would be a
>>> huge bonus from switching to a DVCS!
>>
>> Well, not only it does not exist by design in any DVCS, but I have a
>> better news: it does not exist anymore in Subversion 1.5. You just need
>> to upgrade your SVN server to 1.5, migrate your merge history from the
>> format of svnmerge to the new builtin format (using the official script),
>> and you're done: say hello to "-g/--use-merge-history", to be use with
>> svn log and svn blame.
>>
>> This is a good writeup of the new features:
>> http://chestofbooks.com/computers/revision-control/subversion-svn/Merge-
>> Sensitive-Logs-And-Annotations-Branchmerge-Advanced-Lo.html
>
> Unfortunately I've heard we shouldn't upgrade to svn 1.5 until more
> Linux distributions ship with it by default.

Besides that, `svn merge` cannot handle parallel branches like
trunk/py3k without lots of handholding. Unlike svnmerge.py, when you
merge to and then from a branch, it tries to merge changes that came
from trunk and produces lots of conflicts. (Before you point me at
--reintegrate, note "In Subversion 1.5, once a --reintegrate merge is
done from branch to trunk, the branch is no longer usable for further
work." from the book.) In principle, the svn devs could fix this, but
they didn't in svn 1.5.

To keep this slighly on topic ... maybe the abilities and limits of
svnmerge.py and `svn merge` should be mentioned in the PEP?
___
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] enabling a configure option

[Martin v. Löwis]

Antoine Pitrou wrote:
> Hello python-dev,
> 
> r68924 in py3k introduced a new configure option named --with-computed-gotos. 
> It
> would be nice if one of the buildbots could exercise this option, so that the
> code doesn't rot (the buildbot has to use gcc). Whom should I ask for this?

Me. Does it have to be a configure option? It is difficult to invoke
different commands in different branches; better if the configures in
all branches get the same options. Of course, the configure command
doesn't have to be "configure"; any other script available in all
branches would work (there is already Tools/buildbot for such scripts).

> Speaking of which, there are only five buildbots remaining in the "stable"
> bunch... What has happened to the others?

I've removed all slaves that were down and where the owners either
didn't respond, or indicated that they can't bring the slaves up anytime
soon.

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] PEP 374 (DVCS) now in reST

[Jesse Noller]

On Jan 26, 2009, at 5:18 PM, Jeffrey Yasskin  wrote:

On Mon, Jan 26, 2009 at 2:00 PM, Guido van Rossum   
wrote:
On Mon, Jan 26, 2009 at 1:57 PM, Giovanni Bajo   
wrote:

On Mon, 26 Jan 2009 10:31:55 -0800, Guido van Rossum wrote:

On Mon, Jan 26, 2009 at 8:08 AM, Paul Hummer >

wrote:
At a previous employer, we had this same discussion about  
switching to

a DVCS, and the time and cost required to learn the new tool.  We
switched to bzr, and while there were days where someone got  
lost in
the DVCS, the overall advantages with merging allowed that cost  
to be
offset by the fact that merging was so cheap (and we merged a  
lot).


That's a big consideration to be made when you're considering a  
DVCS.

Merges in SVN and CVS can be painful, where merging well is a core
feature of any DVCS.


I hear you. I for one have been frustrated (now that you mention  
it) by
the inability to track changes across merges. We do lots of  
merges from
the trunk into the py3k branch, and the merge revisions in the  
branch
quotes the full text of the changes merged from the trunk, but  
not the
list of affected files for each revision merged. Since merges  
typically
combine a lot of revisions, it is very painful to find out more  
about a
particular change to a file when that change came from such a  
merge --
often even after reading through the entire list of descriptions  
you
still have no idea which merged revision is responsible for a  
particular
change. Assuming this problem does not exist in DVCS, that would  
be a

huge bonus from switching to a DVCS!


Well, not only it does not exist by design in any DVCS, but I have a
better news: it does not exist anymore in Subversion 1.5. You just  
need
to upgrade your SVN server to 1.5, migrate your merge history from  
the
format of svnmerge to the new builtin format (using the official  
script),
and you're done: say hello to "-g/--use-merge-history", to be use  
with

svn log and svn blame.

This is a good writeup of the new features:
http://chestofbooks.com/computers/revision-control/subversion-svn/Merge-
Sensitive-Logs-And-Annotations-Branchmerge-Advanced-Lo.html


Unfortunately I've heard we shouldn't upgrade to svn 1.5 until more
Linux distributions ship with it by default.


Besides that, `svn merge` cannot handle parallel branches like
trunk/py3k without lots of handholding. Unlike svnmerge.py, when you
merge to and then from a branch, it tries to merge changes that came
from trunk and produces lots of conflicts. (Before you point me at
--reintegrate, note "In Subversion 1.5, once a --reintegrate merge is
done from branch to trunk, the branch is no longer usable for further
work." from the book.) In principle, the svn devs could fix this, but
they didn't in svn 1.5.

To keep this slighly on topic ... maybe the abilities and limits of
svnmerge.py and `svn merge` should be mentioned in the PEP?



Everytime I merge with subversion, it makes me appreciate perforce's  
branching and merging that much more.


Jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Martin v. Löwis]

> Unfortunately I've heard we shouldn't upgrade to svn 1.5 until more
> Linux distributions ship with it by default.

We *could* upgrade to subversion 1.5 on the server (if only Debian
would get their ... together and release the version they promised
for last September).

The question is then whether we would drop svnmerge, in favour of
the 1.5 merge tracking. IIUC, that would require all committers to
use 1.5 - I'm not sure whether this poses a challenge to any committer.

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] enabling a configure option

[Antoine Pitrou]

Martin v. Löwis  v.loewis.de> writes:
> 
> Me. Does it have to be a configure option? It is difficult to invoke
> different commands in different branches; better if the configures in
> all branches get the same options.

Well, after a quick test, it seems that configure doesn't complain if you pass
it an unknown option (at least one that begins with '--with'). So we can still
use the same options on all branches.

(as for the need for it to be a configure option, it was the consensus which
emerged after discussion in the tracker entry, both to provide some flexibility
and for fear that enabling it by default could trigger some compiler bugs --
although the latter is of course unlikely)

Regards

Antoine.


___
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] subprocess crossplatformness and async communication

[Nick Coghlan]

Daniel Stutzbach wrote:
> I'm confused.  What's wrong with the following?
> 
> p = Popen('do_something', stdin=PIPE, stdout=PIPE)
> p.stdin.write('la la la\n')
> p.stdin.flush()
> line = p.stdout.readline()
> p.stdin.write(process(line))
> p.stdin.flush()
>  
> If you want to see if data is available on p.stdout, use the select
> module (unless you're on Windows).
> 
> The child process has to flush its output buffer for this to work, but
> that isn't Python's problem.

Anatoly covered that in his response to Guido: "You can't launch a
process and communicate with it without blocking at some point. The
scenario where you can periodically check output and error pipes without
blocking and send input is not supported."

With the vanilla subprocess Popen implmentation, the stdin.write calls
can actually both block if the stdin buffer is full (waiting for the
child process to clear space) and the stdout.readline call can
definitely block (waiting for the child process to end the line).

So it isn't async communication in general that is the concern: it is
*non-blocking* async communication. (Since I'm happy with the idea of
threaded programs, I'd personally just farm the task off to some worker
threads and make it non-blocking that way, but that approach effectively
abandons the whole concept of non-blocking IO and it's ability to avoid
using threads).

As Guido said though, while there doesn't seem to be anything
fundamentally wrong with the idea of adding better support for
non-blocking IO to subprocess, it's difficult to have an opinion without
a concrete proposal for API changes to subprocess.Popen. The linked
recipe certainly can't be adopted as is (e.g. due to the dependency on
pywin32)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] subprocess crossplatformness and async communication

[Daniel Stutzbach]

On Mon, Jan 26, 2009 at 4:43 PM, Nick Coghlan  wrote:

> With the vanilla subprocess Popen implmentation, the stdin.write calls
> can actually both block if the stdin buffer is full (waiting for the
> child process to clear space) and the stdout.readline call can
> definitely block (waiting for the child process to end the line).


That's true, but for the use cases presented so far, .readline() is
satisfactory, unless you have an unusual application that will fill the pipe
without sending a single newline (in which case, see below).


> So it isn't async communication in general that is the concern: it is
> *non-blocking* async communication. (Since I'm happy with the idea of
> threaded programs, I'd personally just farm the task off to some worker
> threads and make it non-blocking that way, but that approach effectively
> abandons the whole concept of non-blocking IO and it's ability to avoid
> using threads).


If you really need to communicate with multiple subprocesses (which so far
has not been suggested as a motivating example), then you can use select().

You don't need non-blocking IO to avoid using threads (although that is a
common misconception).  If a program never blocks, then it uses 100% of CPU
by definition, which is undesirable. ;-)  A program just needs select() so
it knows which file descriptors it can call os.read() or os.write() on
without blocking.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] subprocess crossplatformness and async communication

[Andrew Bennetts]

Daniel Stutzbach wrote:
[...]
> 
> If you really need to communicate with multiple subprocesses (which so far has
> not been suggested as a motivating example), then you can use select().

Not portably.  select() on windows only works on sockets.

-Andrew.

___
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] subprocess crossplatformness and async communication

[Nick Coghlan]

Andrew Bennetts wrote:
> Daniel Stutzbach wrote:
> [...]
>> If you really need to communicate with multiple subprocesses (which so far 
>> has
>> not been suggested as a motivating example), then you can use select().
> 
> Not portably.  select() on windows only works on sockets.

In addition, select() is exactly what the linked recipe uses to
implement non-blocking I/O for subprocesses on non-Windows platforms.

I agree the actual use cases need to be better articulated in any RFE
that is actually posted, but a cleanly encapsulated approach to
non-blocking communication with subprocesses over stdin/out/err
certainly sounds like something that could reasonably be added to the
subprocess module.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] subprocess crossplatformness and async communication

[Martin v. Loewis]

> Can this really be made safe without an explicit flow control protocol,
> such as a pseudo-TTY?  stdio reads data from pipes such as stdin in 4K
> or so chunks.

I don't think the subprocess module uses stdio.

> I can easily imagine the child blocking while it waits
> for its stdin buffer to fill, while the parent in turn blocks waiting
> for the child's output arrive.

That would be a bug in the parent process, for expecting output when
none will arrive. As a consequence, some child programs might not be
suitable for this kind of operation. This is no surprise - some programs
are not suitable for automated operation at all, because they bring
up windows, and communicate with their environment by means other than
stdin and stdout (or, if you want to operate them automatically, you
have to use AppleScript, or COM).

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] PEP 374 (DVCS) now in reST

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jan 25, 2009, at 10:27 PM, Jared Grubb wrote:

Regardless of the outcome, those that want to use SVN can use SVN,  
and those that want to use "chosen DVCS" can use that. In the end,  
which is the more "lossy" repository? It seems like if the change is  
transparent to everyone who is using it, then the only thing that we  
care about is that the chosen backend will preserve all the  
information to make it truly transparent to everyone involved.


svn is the more lossy repository format.

Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSX5vZnEjvBPtnXfVAQJzcgP/SweUwXoECPJpO5BEkmdTLDoEfPP1X1Lg
m4AALSFZ3cfRUPX3UgGmT7anY604o5oaElFR8b0HkIScJvhF56nzs9oAR0Yqi8jN
zThG1rizDHh+RSqUZ0yXKHVF6ScNf8aRg/cLoVtV+J6KGpYtTCSGTQWGnvSQxCj9
I+BY75DHOI8=
=9A3a
-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] enabling a configure option

[Neal Norwitz]

If you only care about this running on a single machine to get some
coverage and don't care about all architectures, you can change
Misc/build.sh to add the configure option.

n

On Mon, Jan 26, 2009 at 2:31 PM, Antoine Pitrou  wrote:
> Martin v. Löwis  v.loewis.de> writes:
>>
>> Me. Does it have to be a configure option? It is difficult to invoke
>> different commands in different branches; better if the configures in
>> all branches get the same options.
>
> Well, after a quick test, it seems that configure doesn't complain if you pass
> it an unknown option (at least one that begins with '--with'). So we can still
> use the same options on all branches.
>
> (as for the need for it to be a configure option, it was the consensus which
> emerged after discussion in the tracker entry, both to provide some 
> flexibility
> and for fear that enabling it by default could trigger some compiler bugs --
> although the latter is of course unlikely)
>
> Regards
>
> Antoine.
>
>
> ___
> 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/nnorwitz%40gmail.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