[Python-Dev] no tp_traverse for dict iters

[Robert Schuppenies]

Hi.

Could you please explain to me why some iterators have a tp_traverse
implementation and others do not? For example tupleiterator has one,
but none of the dict iterators. Same for set iterators (and possibly
others). It shows in Python when you use the get_referents function.

>>> t = (1,2,3)
>>> gc.get_referents(iter(t))
[(1, 2, 3)]
>>> s = set([1,2,3])
>>> gc.get_referents(iter(s))
[]
>>> d = {1:1, 2:2}
>>> gc.get_referents(iter(d))
[]

And is it correct that you can rephrase the question to 'why some
iterators are seen as container objects and others are not'?

thanks,
robert



___
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] Should we help pythonmac.org?

[Barry Scott]

On Aug 18, 2008, at 22:06, Bob Ippolito wrote:


The major difference between the packages on macports and
pythonmac.org is that macports is their own distro of nearly
everything, akin to installing a copy of FreeBSD over top of Mac OS X.
pythonmac.org contains packages that are self-contained and don't have
a whole new set of libraries to install (in the cases where they do
require libraries, they link them in statically for the most part).



Theses comments are from my point of view as a developer
for end users on the Mac.

For my pysvn project I release kits for all the python versions

* Apple python 2.3 powerpc
* Apple python 2.4 intel
* MacPython 2.4.x powerpc
* MacPython 2.5.x powerpc and intel

And in the future I intend to support:
* 2.6b3 framework build
* 3.0b3 framework build

These are all framework builds and they are totally isolated from  
each other.


And I release pysvn as DMG kits as well.

For pysvn workbench I use the wxWidgets released DMG kits.
And create a application using python module bundlebuilder.

Whatever you do should point to a framework build including  
bundelbuilder
which is installed using a Mac installer. Which is the status quo so  
far.


Barry

___
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] no tp_traverse for dict iters

[Amaury Forgeot d'Arc]

Hello,

2008/8/25 Robert Schuppenies <[EMAIL PROTECTED]>:
> Hi.
>
> Could you please explain to me why some iterators have a tp_traverse
> implementation and others do not? For example tupleiterator has one,
> but none of the dict iterators. Same for set iterators (and possibly
> others). It shows in Python when you use the get_referents function.
>
 t = (1,2,3)
 gc.get_referents(iter(t))
> [(1, 2, 3)]
 s = set([1,2,3])
 gc.get_referents(iter(s))
> []
 d = {1:1, 2:2}
 gc.get_referents(iter(d))
> []
>
> And is it correct that you can rephrase the question to 'why some
> iterators are seen as container objects and others are not'?

Yes, this can lead to some object cycle that are not collected.
See the attached script: a cycle involving a list iterator is
collected by the garbage collector, but a cycle with a dict iterator
is not.
This is worth a bug report IMO.

-- 
Amaury Forgeot d'Arc
import gc, weakref

def test_container_iterator(i):
class C(object):
pass
obj = C()
ref = weakref.ref(obj)

if i == 1:
container = (obj,)
elif i==2:
container = [obj,]
elif i==3:
container = {obj: 1}
elif i==4:
container = {1: obj}

print "Container:", container,

obj.x = iter(container)

del obj, container
gc.collect()

if ref() is None:
print "OK"
else:
print "Cycle was not collected!!"
# Break the cycle
del ref().x

# Now it is.
assert ref() is None

test_container_iterator(1)
test_container_iterator(2)
test_container_iterator(3)
test_container_iterator(4)
___
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] Unicode 5.1.0

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I was away for the weekend and am struggling to catch up on my email.   
Since I haven't digested this entire thread, I'll refrain for the  
moment from giving my opinion, however this comment jumped out to me.


On Aug 22, 2008, at 9:42 AM, Facundo Batista wrote:


- We always could have a beta4 if it's necessary...


I do not want to slip the schedule if at all possible.  If serious  
security issues, performance problems, show stopper bugs crop up, then  
we will obviously slip so that we don't have to put a brown bag over  
our heads.  Slipping to get yet one more feature in is not (IMO)  
acceptable.


An incentive for keeping the schedule: If we hit our October 1st  
deadline, then 2.6 and 3.0 will almost certainly be included in some  
upcoming major new OS releases.  If we slip, then it's unlikely to  
happen.


- -Barry

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

iQCVAwUBSLKqenEjvBPtnXfVAQJukAP+L93nxTP436Au9GkLZQUhy1Gbk8rDvq2K
jZtJA5Rb9VKUr7TDoqZ2iFRRg9tsxwz+fLzZp0m00WWGRvKHdgqS+c6sHBaXazzk
txFhyspkw0cndD7zsNoqThlY6Q1CkhK3BHYmRLWS+PVhfOm6bRgudL+ePcWneT2X
24pFB83GSjo=
=/lq8
-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] Doc translation -- from LaTeX to reStructuredText

[harp]

Not succeeded. I have done these steps:

- I downloaded the tutorial in LaTeX. (http://www.python.org/doc/2.5.2/
download/ )
- Extracted.
- Put the hungarian tut.tex into the tut directory
- downloaded the files from http://svn.python.org/view/doctools/converter
- Run the `convert.py . ../pydoc` in the /Python-Docs-2.5.2 directory
- Because of some errors* I leave only the 'tut' item in the subdirs
in converter/__init__.py (for subdir in...)
- Run again.
- In the pydoc/tutorial directory there is only an index.rst file. No
appetite.rst and so on. And the index.rst is english as well.

*The error message mentioned above:

(...) lib/libal.tex lib/liballos.tex
Traceback (most recent call last):
  File "./converter/convert.py", line 26, in 
convert_dir(destdir, *sys.argv[3:])
  File "/home/ha/Munkaasztal/Python-Docs-2.5.2/convert/converter/
__init__.py", line 86, in convert_dir
newname = fn_mapping[subdir][filename]
KeyError: 'libamoeba'


On aug. 22, 20:18, "Benjamin Peterson" <[EMAIL PROTECTED]>
wrote:
> On Fri, Aug 22, 2008 at 9:03 AM, harp <[EMAIL PROTECTED]> wrote:
> >  Dear Developers,
>
> > We have translated the tutorial into Hungarian earlier, and I do not
> > know how to convert the LaTeX file into reStructuredText. Could
> > somebody help us?
>
> Have you looked at the LaTeX to reST converter 
> athttp://svn.python.org/view/doctools/converter?
>
>
>
> > HTML:http://pythonlib.pergamen.hu/html/tut/
> > LaTeX file:http://mail.roik.bmf.hu/linux/python/tutorial/tut.tex
>
> > There will be included translations of documentation on the python.org
> > homepage?
>
> >   Arpad
.python.org/mailman/options/python-dev/musiccomposition%40...
>
> --
> Cheers,
> Benjamin Peterson
> "There's no place like 127.0.0.1."
___
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] Unicode 5.1.0

[İsmail Dönmez]

Hi,

On Thu, Aug 21, 2008 at 23:35, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I was just paid a visit by my Google colleague Mark Davis, co-founder
> of the Unicode project and the president of the Unicode Consortium. He
> would like to see improved Unicode support for Python. (Well duh. :-)
> On his list of top priorities are:
>
> 1. Upgrade the unicodata module to the Unicode 5.1.0 standard
> 2. Extende the unicodedata module with some additional properties
> 3. Add support for Unicode properties to the regex syntax, including
> Boolean combinations

Adding support for SpecialCasing rules[0] would be good for full
Unicode support too. It would fix i/I problems that are currently
going on with Turkish locale.

[0] http://unicode.org/Public/UNIDATA/SpecialCasing.txt

Regards,
ismail

-- 
Programmer Excuse #17: The processor stack spring has worn out.
___
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] try-except slower in 2.6 (was: performance)

[M.-A. Lemburg]

On 2008-08-24 21:04, Antoine Pitrou wrote:
>>>TryRaiseExcept:   183ms   122ms  +49.6%   184ms   124ms  
>>> +48.2%
>> Whoa, that's a big slowdown.  I wonder if it's consistent?
> 
> Yes, I can definitely reproduce it.

That's a huge slow-down compared to 2.5.

Are there any obvious reasons for this ? Has the exception handling
mechanism changed that much between 2.5 and 2.6 ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 25 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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] Unicode 5.1.0

[M.-A. Lemburg]

On 2008-08-22 03:25, Guido van Rossum wrote:
> On Thu, Aug 21, 2008 at 2:26 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2008-08-21 22:35, Guido van Rossum wrote:
>>> I was just paid a visit by my Google colleague Mark Davis, co-founder
>>> of the Unicode project and the president of the Unicode Consortium. He
>>> would like to see improved Unicode support for Python. (Well duh. :-)
>>> On his list of top priorities are:
>>>
>>> 1. Upgrade the unicodata module to the Unicode 5.1.0 standard
>>> 2. Extende the unicodedata module with some additional properties
>>> 3. Add support for Unicode properties to the regex syntax, including
>>> Boolean combinations
>>>
>>> I've tried to explain our release schedule and
>>> no-new-features-in-point-releases policies to him, and he understands
>>> that it's too late to add #2 or #3 to 2.6 and 3.0, and that these will
>>> have to wait for 2.7 and 3.1, respectively. However, I've kept the
>>> door sligthtly ajar for adding #1 -- it can't be too much work and it
>>> can't have too much impact. Or can it? I don't actually know what the
>>> impact would be, so I'd like some impact from developers who are
>>> closer to the origins of the unicodedata module.
>>>
>>> The two, quite separate, questions, then, are (a) how much work would
>>> it be to upgrade to version 5.1.0 of the database; and (b) would it be
>>> acceptable to do this post-beta3 (but before rc1). If the answer to
>>> (b) is positive, Google can help with (a).
>>>
>>> In general, Google has needs in this area that can't wait for 2.7/3.1,
>>> so what we may end up doing is create internal implementations of all
>>> three features (compatible with Python 2.4 and later), publish them as
>>> open source on Google Code, and fold them into core Python at the
>>> first opportunity, which would likely be 2.7 and 3.1.
>>>
>>> Comments?
>> There are two things to consider:
>>
>> unicodedata is just an optimized database for accessing code
>> point properties of a specific Unicode version (currently 4.1.0
>> and 3.2.0). Adding support for a new version needs some work on
>> the generation script, perhaps keeping the 4.1.0 version of it
>> like we did for 3.2.0, but that's about it.
>>
>> However, there are other implications to consider when moving to
>> Unicode 5.1.0.
>>
>> Just see the top of http://www.unicode.org/versions/Unicode5.1.0/
>> for a summary of changes compared to 5.0, plus
>> http://www.unicode.org/versions/Unicode5.0.0/ for changes between
>> 4.1.0 and 5.0.
>>
>> So while we could say: "we provide access to the Unicode 5.1.0
>> database", we cannot say: "we support Unicode 5.1.0", simply because
>> we have not reviewed the all the necessary changes and implications.
> 
> Mark's response to this was:
> 
> """
> I'd suspect that you'll be as conformant to U5.1.0 as you were to U4.1.0 ;-)
> 
> More seriously, I don't think this is a roadblock -- I doubt that
> there are real differences between U5.1.0 and U4.10 in terms of
> conformance that would be touched by Python -- the conformance changes
> tend to be either completely backward compatible or very esoteric.
> What I can do is to review the Python support to see if and where
> there are any problems, but I wouldn't anticipate any.
> """
> 
> Which suggests that he believes that the differences in the database
> are very minor, and that upgrading just the database would not cause
> any problems for code that worked well with the 4.1.0 database.

Fine with me.

>> I think it's better to look through all the changes and then come
>> up with proper support for 2.7/3.1. If Google wants to contribute
>> to this, even better. To avoid duplication of work or heading in
>> different directions, it may be a good idea to create a
>> unicode-sig to discuss things.
> 
> Not me. :-)

I would really like to see more Unicode support in Python, e.g.
for collation, compression, indexing based on graphemes and
code points, better support for special casing situations (to
cover e.g. the dotted vs. non-dotted i in the Turkish scripts),
etc.

There are also a few changes that we'd need to incorporate into
the UTF codecs, e.g. warn about more ill-formed byte sequences.

Would Google be willing to contribute such support or part
of it ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 25 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
Python-Dev mailing list
Pyt

Re: [Python-Dev] try-except slower in 2.6 (was: performance)

[Antoine Pitrou]

M.-A. Lemburg  egenix.com> writes:
> 
> That's a huge slow-down compared to 2.5.
> 
> Are there any obvious reasons for this ? Has the exception handling
> mechanism changed that much between 2.5 and 2.6 ?

I've looked at it a bit and I think it's because of the
issubclass()/isinstance() slowdown (which itself is due to ABCs).

If I apply the patch in http://bugs.python.org/issue2534, the exception handling
slowdown seems to disappear.



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

[Guido van Rossum]

2008/8/25 M.-A. Lemburg <[EMAIL PROTECTED]>:
> I would really like to see more Unicode support in Python, e.g.
> for collation, compression, indexing based on graphemes and
> code points, better support for special casing situations (to
> cover e.g. the dotted vs. non-dotted i in the Turkish scripts),
> etc.
>
> There are also a few changes that we'd need to incorporate into
> the UTF codecs, e.g. warn about more ill-formed byte sequences.
>
> Would Google be willing to contribute such support or part
> of it ?

That depends purely on how much need Google itself has for these features.
I'll ask around, but for now I wouldn't bet on anything beyond the three
points I raised at the start of this thread:

1. Upgrade the unicodata module to the Unicode 5.1.0 standard
2. Extende the unicodedata module with some additional properties
3. Add support for Unicode properties to the regex syntax, including
Boolean combinations

-- 
--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] subprocess insufficiently platform-independent?

[Guido van Rossum]

Several people at Google seem to have independently discovered that
despite all of the platform-independent goodness in subprocess.py, you
still need to be platform aware. One of my colleagues summarized it
like this:

"""
Given a straightforward command list like:

cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk']

You apparently cannot pass this list to any subprocess function
(subprocess.call() or otherwise) with a set of arguments that allow it
to "just work" on both Windows and non-Windows systems.

If you call:

subprocess.call(cmd, shell=False)

Then it works on Linux, but fails on Windows because it does not
perform the Windows %PATHEXT% search that allows it to find that
"svn.exe" is the actual executable to be invoked.

If you call:

subprocess.call(cmd, shell=True)

Then it works on Windows (it finds the "svn.exe" executable), but it
fails on Linux because it *only* executes the first argument in the
list ("svn") and does not pass the remaining arguments in the list to
the "svn" invocation.

This forces you to code platform-dependent behavior in how you call
subprocess.call() when using a list.  For example, you can make the
shell= argument depend on the platform you're running on, like:

subprocess.call(cmd, shell=(sys.platform=='win32'))

Or you could vary cmd[0] in your list based on the platform:

if sys.platform == 'win32':
svn = 'svn.exe'
else:
svn = 'svn'
cmd = [svn, 'ls', 'http://rietveld.googlecode.com/svn/trunk']

But either way, this seems clearly broken (or at least sub-optimal)
for a module that's supposed to abstract platform-specific execution
issues from the user.
"""

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

[Terry Reedy]

Guido van Rossum wrote:

2008/8/25 M.-A. Lemburg <[EMAIL PROTECTED] >:
 > I would really like to see more Unicode support in Python, e.g.
 > for collation, compression, indexing based on graphemes and
 > code points, better support for special casing situations (to
 > cover e.g. the dotted vs. non-dotted i in the Turkish scripts),
 > etc.
 >
 > There are also a few changes that we'd need to incorporate into
 > the UTF codecs, e.g. warn about more ill-formed byte sequences.
 >
 > Would Google be willing to contribute such support or part
 > of it ?

That depends purely on how much need Google itself has for these 
features. I'll ask around, but for now I wouldn't bet on anything beyond 
the three points I raised at the start of this thread:


1. Upgrade the unicodata module to the Unicode 5.1.0 standard
2. Extende the unicodedata module with some additional properties
3. Add support for Unicode properties to the regex syntax, including
Boolean combinations


I think an Improve Unicode Support PEP would be a good idea to collect 
(and get approval or not for) various ideas from various people, even if 
Google only implements part of 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] subprocess insufficiently platform-independent?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 25, 2008, at 1:13 PM, Guido van Rossum wrote:


Several people at Google seem to have independently discovered that
despite all of the platform-independent goodness in subprocess.py, you
still need to be platform aware. One of my colleagues summarized it
like this:

"""
Given a straightforward command list like:

   cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk']

You apparently cannot pass this list to any subprocess function
(subprocess.call() or otherwise) with a set of arguments that allow it
to "just work" on both Windows and non-Windows systems.


Unless I'm misremembering (I no longer have access to Windows), I  
believe that if you use ' '.join(cmd) as the first argument, it will  
work cross-platform.


- -Barry

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

iQCVAwUBSLLsU3EjvBPtnXfVAQJapQP+N4HY0I/uczbdQKB1bi6OV0BZgj5JS8an
Tz4FEnaD9LDegTnV8fqAx5/blIidZEdPjVkdmW4m4bz8tRNIEdoZyghHUmKycgRj
d65FU0e1tL40u0AoKl3ARO6WWkKKhaqn4R17065lh+V1ZNKutu2btiAso6VfWVW5
V7hvo/61ACM=
=P0Nb
-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] subprocess insufficiently platform-independent?

[Oleg Broytmann]

On Mon, Aug 25, 2008 at 01:30:58PM -0400, Barry Warsaw wrote:
> Unless I'm misremembering (I no longer have access to Windows), I  
> believe that if you use ' '.join(cmd) as the first argument, it will  
> work cross-platform.

   What about arguments that contain spaces?

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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 insufficiently platform-independent?

[Guido van Rossum]

On Mon, Aug 25, 2008 at 10:30 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Unless I'm misremembering (I no longer have access to Windows), I believe
> that if you use ' '.join(cmd) as the first argument, it will work
> cross-platform.

That will mean something different if there are spaces or shell
metacharacters in the arguments.

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

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote:


http://www.unicode.org/versions/Unicode5.1.0/
"Unicode 5.1.0 contains over 100,000 characters, and provides  
significant additions and improvements..." to existing features,  
including new files and upgrades to existing files.  Sounds close to  
adding features ;-)


I agree.  This seriously feels like new, potentially high risk code to  
be adding this late in the game.  The BDFL can always override, but  
unless someone is really convincing that this is low risk high  
benefit, I'd vote no for 2.6/3.0.


- -Barry

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

iQCVAwUBSLLtMnEjvBPtnXfVAQKg0wP+LJ1XYXhEQHUAvT3fPbPzStCN8Lb+D7XG
hZOANnTCbPGaeCY19B8mYZbXkvjkCBptauKGB5yGOAnb1KCkSaQWx0wCInkeyIFE
mVMupGZCUsdsO7KreEwvyhBpOJ/HNY0+eacv8GZKCwC9xW3WmhaOjry7sZFhjffw
hAX1AuxaPWA=
=2j8a
-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] subprocess insufficiently platform-independent?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 25, 2008, at 1:33 PM, Oleg Broytmann wrote:


On Mon, Aug 25, 2008 at 01:30:58PM -0400, Barry Warsaw wrote:

Unless I'm misremembering (I no longer have access to Windows), I
believe that if you use ' '.join(cmd) as the first argument, it will
work cross-platform.


  What about arguments that contain spaces?


Oh sure, throw a monkey wrench into it .

Guido's original problem statement is still correct though.  It's  
advertised to take a sequence of arguments, so that should work.


- -Barry

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

iQCVAwUBSLLtr3EjvBPtnXfVAQKJpgP/TPmVgsRdRiAE+jvZOCl9unHWU6LtLSx/
uU3gIkQfvPYcyv9oUS0mcTwWsRDCeP42foQxP+MgX2Zx1ItQPi8/QDbW2bS809pF
q8igObharc0kSokhTw2zrkNXsEx3S+epPJXaiueY2cs9jC4mCvXnlnt67ZtWEc8r
r+eNLlI2/eo=
=SfRl
-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] subprocess insufficiently platform-independent?

[Steven Bethard]

On Mon, Aug 25, 2008 at 11:30 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Aug 25, 2008, at 1:13 PM, Guido van Rossum wrote:
>
>> Several people at Google seem to have independently discovered that
>> despite all of the platform-independent goodness in subprocess.py, you
>> still need to be platform aware. One of my colleagues summarized it
>> like this:
>>
>> """
>> Given a straightforward command list like:
>>
>>   cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk']
>>
>> You apparently cannot pass this list to any subprocess function
>> (subprocess.call() or otherwise) with a set of arguments that allow it
>> to "just work" on both Windows and non-Windows systems.
>
> Unless I'm misremembering (I no longer have access to Windows), I believe
> that if you use ' '.join(cmd) as the first argument, it will work
> cross-platform.

FWIW, I've also struggled with similar issues. For example, with no
shell= argument, Windows typically opens up an extra window to run the
command, while Unix doesn't. My most recent hack around this looked
something like::

try:
import win32con
except ImportError:
win32con = None

kwargs = dict(...)
if win32con is not None:
kwargs['creationflags'] = win32con.CREATE_NO_WINDOW
subprocess.Popen(cmd, **kwargs)

I'd love to see subprocess become more consistent cross-platform.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
 --- Bucky Katt, Get Fuzzy
___
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 insufficiently platform-independent?

[Robert Brewer]

Guido van Rossum wrote:
> Several people at Google seem to have independently discovered that
> despite all of the platform-independent goodness in subprocess.py, you
> still need to be platform aware.

I can verify this. For CP we went back to using spawnl, but in an
internal project we checked sys.platform and set shell=True for Windows.


Robert Brewer
[EMAIL PROTECTED]

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

Re: [Python-Dev] subprocess insufficiently platform-independent?

[Jean-Paul Calderone]

On Mon, 25 Aug 2008 10:13:32 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote:

Several people at Google seem to have independently discovered that
despite all of the platform-independent goodness in subprocess.py, you
still need to be platform aware. One of my colleagues summarized it
like this:

"""
Given a straightforward command list like:

   cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk']



Launching child processes on Windows is actually pretty hard to do.
The idea of an array of arguments is more like a group hallucination
than a reality there.  If you assume certain things about how the
launched process will interpret its command line (something each
program gets to decide for itself on Windows), and many programs do
actually use the same rules, then you can get something together that
mostly works and is mostly general.

Twisted's process support does this and presents a cross-platform API
(at least as far as arguments are concerned).  Perhaps the subprocess
module should borrow that implementation?

http://twistedmatrix.com/trac/browser/trunk/twisted/python/win32.py#L66

This doesn't handle all possible inputs correctly (you can read about its
flaws in some detail at ) but
it does handle *most* inputs.  It also isn't appropriate for all programs,
but for the programs which don't follow these quoting rules, it's probably
a mistake to have a list-based API anyway: they should be invoked using one
string giving the entire command line.

Jean-Paul
___
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] Unicode 5.1.0

[Benjamin Peterson]

On Mon, Aug 25, 2008 at 12:34 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote:
>>
>> http://www.unicode.org/versions/Unicode5.1.0/
>> "Unicode 5.1.0 contains over 100,000 characters, and provides significant
>> additions and improvements..." to existing features, including new files and
>> upgrades to existing files.  Sounds close to adding features ;-)
>
> I agree.  This seriously feels like new, potentially high risk code to be
> adding this late in the game.  The BDFL can always override, but unless
> someone is really convincing that this is low risk high benefit, I'd vote no
> for 2.6/3.0.

+1

Something I think we should also be considering is the 2.7/3.1 release
cycle. I propose that we shorten it to ~1 year from 2.6/3.0's release
with our main aim being binding 2.x and 3.x more closely. This would
get the new unicode features out fairly quickly without having to wait
another 2.5 years like 2.5 -> 2.6.



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
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] Unicode 5.1.0

[Fredrik Lundh]

Barry Warsaw wrote:

I agree.  This seriously feels like new, potentially high risk code to 
be adding this late in the game.  The BDFL can always override, but 
unless someone is really convincing that this is low risk high benefit, 
I'd vote no for 2.6/3.0.


at least two Unicode experts have stated that they don't think the 
changes are that important.  determining exactly what the changes to the 
*core* character database was the whole point of my offer to tinker with 
this.


(I got distracted due to compiler issues and certain other things to be 
announced later, but I expect to have some results later this week).




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

[Guido van Rossum]

On Mon, Aug 25, 2008 at 10:52 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Mon, Aug 25, 2008 at 12:34 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote:
>>>
>>> http://www.unicode.org/versions/Unicode5.1.0/
>>> "Unicode 5.1.0 contains over 100,000 characters, and provides significant
>>> additions and improvements..." to existing features, including new files and
>>> upgrades to existing files.  Sounds close to adding features ;-)
>>
>> I agree.  This seriously feels like new, potentially high risk code to be
>> adding this late in the game.  The BDFL can always override, but unless
>> someone is really convincing that this is low risk high benefit, I'd vote no
>> for 2.6/3.0.
>
> +1
>
> Something I think we should also be considering is the 2.7/3.1 release
> cycle. I propose that we shorten it to ~1 year from 2.6/3.0's release
> with our main aim being binding 2.x and 3.x more closely. This would
> get the new unicode features out fairly quickly without having to wait
> another 2.5 years like 2.5 -> 2.6.

I was never proposing to support any new features in 2.6/3.0. I was
only proposing to update the data files that we already support to the
versions provided by 5.1.0. Those data files should have the same
format, just slightly improved content: some new characters, some
corrected properties. Fredrik says it best:

> at least two Unicode experts have stated that they don't think the changes
> are that important.  determining exactly what the changes to the *core*
> character database was the whole point of my offer to tinker with this.
>
> (I got distracted due to compiler issues and certain other things to be
> announced later, but I expect to have some results later this week).

-- 
--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] 2to3 patches and reviews

[Benjamin Peterson]

I've been working on and reviewing some of the release blocking 2to3
patches and issues. Unfortunately, it seems like we don't have many
core devs available for reviewing 2to3 changes. I have one patch in
particular [1] that I would like to get in soon, since it changes the
API a bit to make it more extensible.

[1] http://bugs.python.org/3637

-- 
Thanks,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
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] Unicode 5.1.0

[M.-A. Lemburg]

On 2008-08-25 19:34, Barry Warsaw wrote:
> On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote:
> 
>> http://www.unicode.org/versions/Unicode5.1.0/
>> "Unicode 5.1.0 contains over 100,000 characters, and provides
>> significant additions and improvements..." to existing features,
>> including new files and upgrades to existing files.  Sounds close to
>> adding features ;-)
> 
> I agree.  This seriously feels like new, potentially high risk code to
> be adding this late in the game.  The BDFL can always override, but
> unless someone is really convincing that this is low risk high benefit,
> I'd vote no for 2.6/3.0.

The above quote from the Unicode site is misleading in this context.

Guido's request was just for updating the Unicode database with
the data from 5.1 - without adding new support for properties or
changing the interfaces.

See this page for a list of changes to the Unicode database:

http://www.unicode.org/Public/UNIDATA/UCD.html

The main file used for the unicodedata module is called "UnicodeData.txt".

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 25 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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] Unicode 5.1.0

[Brett Cannon]

On Mon, Aug 25, 2008 at 10:56 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 25, 2008 at 10:52 AM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
>> On Mon, Aug 25, 2008 at 12:34 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>>> On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote:

 http://www.unicode.org/versions/Unicode5.1.0/
 "Unicode 5.1.0 contains over 100,000 characters, and provides significant
 additions and improvements..." to existing features, including new files 
 and
 upgrades to existing files.  Sounds close to adding features ;-)
>>>
>>> I agree.  This seriously feels like new, potentially high risk code to be
>>> adding this late in the game.  The BDFL can always override, but unless
>>> someone is really convincing that this is low risk high benefit, I'd vote no
>>> for 2.6/3.0.
>>
>> +1
>>
>> Something I think we should also be considering is the 2.7/3.1 release
>> cycle. I propose that we shorten it to ~1 year from 2.6/3.0's release
>> with our main aim being binding 2.x and 3.x more closely. This would
>> get the new unicode features out fairly quickly without having to wait
>> another 2.5 years like 2.5 -> 2.6.
>
> I was never proposing to support any new features in 2.6/3.0. I was
> only proposing to update the data files that we already support to the
> versions provided by 5.1.0. Those data files should have the same
> format, just slightly improved content: some new characters, some
> corrected properties. Fredrik says it best:
>
>> at least two Unicode experts have stated that they don't think the changes
>> are that important.  determining exactly what the changes to the *core*
>> character database was the whole point of my offer to tinker with this.
>>
>> (I got distracted due to compiler issues and certain other things to be
>> announced later, but I expect to have some results later this week).
>

Plus the Europeans who probably use Unicode more than the dissenting
Americans also seem to think it's a good idea. It's just a data table,
and it's auto-generated, *and* one of the main guys from the Unicode
Consortium is willing to help. I say let the change go in.

-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

[Python-Dev] [PATCH] Respect LDFLAGS

[Arfrever Frehtes Taifersar Arahesis]

I'm attaching the patch which fixes respecting LDFLAGS when
building libpython$(VERSION).so.

-- 
Arfrever Frehtes Taifersar Arahesis
Index: Makefile.pre.in
===
--- Makefile.pre.in	(revision 66032)
+++ Makefile.pre.in	(working copy)
@@ -412,10 +412,10 @@
 
 libpython$(VERSION).so: $(LIBRARY_OBJS)
 	if test $(INSTSONAME) != $(LDLIBRARY); then \
-		$(LDSHARED) -Wl,-h$(INSTSONAME) -o $(INSTSONAME) $(LIBRARY_OBJS) $(SHLIBS) $(LIBC) $(LIBM); \
+		$(LDSHARED) $(LDFLAGS) -Wl,-h$(INSTSONAME) -o $(INSTSONAME) $(LIBRARY_OBJS) $(SHLIBS) $(LIBC) $(LIBM); \
 		$(LN) -f $(INSTSONAME) $@; \
 	else\
-		$(LDSHARED) -o $@ $(LIBRARY_OBJS) $(SHLIBS) $(LIBC) $(LIBM); \
+		$(LDSHARED) $(LDFLAGS) -o $@ $(LIBRARY_OBJS) $(SHLIBS) $(LIBC) $(LIBM); \
 	fi
 
 libpython$(VERSION).sl: $(LIBRARY_OBJS)


signature.asc
Description: This is a digitally signed message part.
___
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] Unicode 5.1.0

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 25, 2008, at 1:53 PM, Fredrik Lundh wrote:


Barry Warsaw wrote:

I agree.  This seriously feels like new, potentially high risk code  
to be adding this late in the game.  The BDFL can always override,  
but unless someone is really convincing that this is low risk high  
benefit, I'd vote no for 2.6/3.0.


at least two Unicode experts have stated that they don't think the  
changes are that important.  determining exactly what the changes to  
the *core* character database was the whole point of my offer to  
tinker with this.


You don't mean the experts claimed they weren't important, right?   
Unimportant changes definitely don't need to go in now .


- -Barry

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

iQCVAwUBSLMCSHEjvBPtnXfVAQKgLwP/YlrqcdlmoeBsK9JdJMnxkgN92L1K86cg
lzvQT6bv8vda64Su8bV81UT+NdoB+/ZGpZ1t+Dn4Z0uvB0uaVrZZ7uOUoqQTkvG7
yrj/Clbedi2v35vYjudqAaZyBnJtz+V0rH8tdgpDVU5zILSK4gQm385nFuoUXQpC
iJlqok3tjuU=
=YfQR
-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] Unicode 5.1.0

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 25, 2008, at 2:15 PM, M.-A. Lemburg wrote:


Guido's request was just for updating the Unicode database with
the data from 5.1 - without adding new support for properties or
changing the interfaces.

See this page for a list of changes to the Unicode database:

http://www.unicode.org/Public/UNIDATA/UCD.html

The main file used for the unicodedata module is called  
"UnicodeData.txt".


That's much less scary.

- -Barry

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

iQCVAwUBSLMDCHEjvBPtnXfVAQIrYQQAoABjn/KWd8VdFeplR1i3Lqx5lNAWiJu9
6QWhE/4PPGpCBWhsUejnqHTdCOHmo7y6g3YWwPJ1hDZbl+oXrHd4/bcnHWMJgbOO
BV7ACRdVcf9tuewiyNkWXGDn99WcXrGHSTXEnhQsQWL58PDbLxbbDgDUPdbXsGgC
zCQbSykYv2E=
=yheO
-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] Unicode 5.1.0

[Fredrik Lundh]

Barry Warsaw wrote:

You don't mean the experts claimed they weren't important, right?  
Unimportant changes definitely don't need to go in now .


Well, at least Guido managed to figure out what I was trying to say ;-)



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

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 25, 2008, at 3:17 PM, Fredrik Lundh wrote:


Barry Warsaw wrote:

You don't mean the experts claimed they weren't important, right?   
Unimportant changes definitely don't need to go in now .


Well, at least Guido managed to figure out what I was trying to  
say ;-)


Yeah, I was just being curmudgeonly. :)

- -B

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

iQCVAwUBSLMJq3EjvBPtnXfVAQKG6QQAl3MliLaqhaibf12INX6EUoeIiYBEJlhY
IiFgdc6VXe7evMsxUj2xE+1S+rg9BEhwiY38NTZdaqDCRiHBUY6aKFYlnawuyaKf
8m+jIdkJyudBpT5dBvfBCvYlwmXl/RwKHzDRDCHUjKfBVgAo9elv+EDy2kFLUpM1
W8dVEYwo3dg=
=fue6
-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] no tp_traverse for dict iters

[Robert Schuppenies]

Created bug report at http://bugs.python.org/issue3546.

Amaury Forgeot d'Arc wrote:
> Yes, this can lead to some object cycle that are not collected.
> See the attached script: a cycle involving a list iterator is
> collected by the garbage collector, but a cycle with a dict iterator
> is not.
> This is worth a bug report IMO.

___
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] no tp_traverse for dict iters

[Robert Schuppenies]

Sry, wrong link. I meant http://bugs.python.org/issue3680.

Robert Schuppenies wrote:
> Created bug report at http://bugs.python.org/issue3546.
> 
> Amaury Forgeot d'Arc wrote:
>> Yes, this can lead to some object cycle that are not collected.
>> See the attached script: a cycle involving a list iterator is
>> collected by the garbage collector, but a cycle with a dict iterator
>> is not.
>> This is worth a bug report IMO.

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

[Steve Holden]

Barry Warsaw wrote:
> On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote:
> 
>> http://www.unicode.org/versions/Unicode5.1.0/
>> "Unicode 5.1.0 contains over 100,000 characters, and provides
>> significant additions and improvements..." to existing features,
>> including new files and upgrades to existing files.  Sounds close to
>> adding features ;-)
> 
> I agree.  This seriously feels like new, potentially high risk code to
> be adding this late in the game.  The BDFL can always override, but
> unless someone is really convincing that this is low risk high benefit,
> I'd vote no for 2.6/3.0.

But it's [the] wafer-thin [end of the wedge] ...

The difficulties with subprocess suggest there's plenty to do without
adding yet one more tiny little task.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.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] [PATCH] Respect LDFLAGS

[Aahz]

On Mon, Aug 25, 2008, Arfrever Frehtes Taifersar Arahesis wrote:
>
> I'm attaching the patch which fixes respecting LDFLAGS when
> building libpython$(VERSION).so.

Please post your patch to bugs.python.org
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!
___
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 insufficiently platform-independent?

[Greg Ewing]

Guido van Rossum wrote:


If you call:

subprocess.call(cmd, shell=False)

Then it works on Linux, but fails on Windows because it does not
perform the Windows %PATHEXT% search that allows it to find that
"svn.exe" is the actual executable to be invoked.


Maybe the Windows implementation should do its own
%PATHEXT% lookup when the shell is not being used.

--
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] subprocess insufficiently platform-independent?

[James Y Knight]

On Aug 25, 2008, at 9:52 PM, Greg Ewing wrote:


Guido van Rossum wrote:


If you call:
   subprocess.call(cmd, shell=False)
Then it works on Linux, but fails on Windows because it does not
perform the Windows %PATHEXT% search that allows it to find that
"svn.exe" is the actual executable to be invoked.


Maybe the Windows implementation should do its own
%PATHEXT% lookup when the shell is not being used.


+1 to that.

It's really nice to be able to *not* invoke a shell, and thus not have  
to worry about the shell doing nasty things to your process spawning.  
So, any solution that aids portability to windows without requiring  
the invocation of a shell seems like a good thing to me.


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