[Python-Dev] Before 2.5 - More signed integer overflows
Hi all, There are more cases of signed integer overflows in the CPython source code base... That's on a 64-bits machine: [GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2 abs(-sys.maxint-1) == -sys.maxint-1 I'd expect the same breakage everywhere when GCC 4.2 is used. Note that the above is Python 2.4.4c0 - apparently Python 2.3 compiled with GCC 4.1.2 works, although that doesn't make much sense to me because intobject.c didn't change here - 2.3, 2.4, 2.5, trunk are all the same. Both tested Pythons are Debian packages, not in-house compiled. Humpf! Looks like one person or two need to do a quick last-minute review of all places trying to deal with -sys.maxint-1, and replace them all with the "official" fix from Tim [SF 1545668]. A bientot, Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Grammar change in classdef
I've been porting the grammar for pydev to version 2.5 and I've seen
that you can now declare a class in the format: class B():pass
(without the testlist)
-- from the grammar: classdef: 'class' NAME ['(' [testlist] ')'] ':' suite
I think that this change should be presented at
http://docs.python.org/dev/whatsnew/whatsnew25.html
I'm saying that because I've only stumbled upon it by accident -- and
I wasn't able to find any explanation on the reason or semantics of
the change...
Thanks,
Fabio
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Grammar change in classdef
> I think that this change should be presented at > http://docs.python.org/dev/whatsnew/whatsnew25.html It's already listed there: http://docs.python.org/dev/whatsnew/other-lang.html -- Lawrence http://www.oluyede.org/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Testsuite fails on Windows if a space is in the path
The test suite currently (2.5) has two failures on Windows if Python is installed into a directory with a space in it (such as "Program Files"). The failing tests are test_popen and test_cmd_line. The test_cmd_line failure is shallow: the test fails to properly quote sys.executable when passing it to os.popen. I propose to fix this in Python 2.5.1; see #1559413 test_popen is more tricky. This code has always failed AFAICT, except that the test itself is a recent addition. The test tries to pass the following command to os.popen "c:\Program Files\python25\python.exe" -c "import sys;print sys.version" For some reason, os.popen invokes doesn't directly start Python as a new process, but install invokes cmd.exe /c "c:\Program Files\python25\python.exe" -c "import sys;print sys.version" Can somebody remember what the reason is to invoke cmd.exe (or COMSPEC) in os.popen? In any case, cmd.exe fails to execute this, claiming that c:\Program is not a valid executable. It would run cmd.exe /c "c:\Program Files\python25\python.exe" just fine, so apparently, the problem is with argument that have multiple pairs of quotes. I found, through experimentation, that it *will* accept cmd.exe /c ""c:\Program Files\python25\python.exe" -c "import sys;print sys.version"" (i.e. doubling the quotes at the beginning and the end). I'm not quite sure what algorithm cmd.exe uses for parsing, but it appears that adding a pair of quotes works in all cases (at least those I could think of). See # 1559298 Here are my questions: 1. Should this be fixed before the final release of Python 2.5? 2. If not, should it be fixed in Python 2.5.1? I'd say not: there is a potential of breaking existing applications. Applications might be aware of this mess, and deliberately add a pair of quotes already. If popen then adds yet another pair of quotes, cmd.exe will again fail. 3. If not, should this be fixed in 2.6 in the way I propose in the patch (i.e. add quotes around the command line)? Or can anybody propose a different fix? 4. How should we deal with different values of COMSPEC? Should this patch only apply for cmd.exe, or should we assume that other shells are quirk-compatible with cmd.exe in this respect (or that people stopped setting COMSPEC, anyway)? Any comments appreciated, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Grammar change in classdef
Fabio Zadrozny wrote:
> I've been porting the grammar for pydev to version 2.5 and I've seen
> that you can now declare a class in the format: class B():pass
> (without the testlist)
>
> -- from the grammar: classdef: 'class' NAME ['(' [testlist] ')'] ':' suite
>
> I think that this change should be presented at
> http://docs.python.org/dev/whatsnew/whatsnew25.html
>
> I'm saying that because I've only stumbled upon it by accident -- and
> I wasn't able to find any explanation on the reason or semantics of
> the change...
Lawrence already noted that this is already covered by the What's New document
(semantically, it's identical to omitting the parentheses entirely).
As for the reason: it makes it possible to use the same style for classes
without bases as is used for functions without arguments. Prior to this
change, there was a sharp break in the class syntax, such that if you got rid
of the last base class you had to get rid of the parentheses as well.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testsuite fails on Windows if a space is in the path
On Sat, 16 Sep 2006 19:22:34 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]> wrote: >The test suite currently (2.5) has two failures on Windows >if Python is installed into a directory with a space in it >(such as "Program Files"). The failing tests are test_popen >and test_cmd_line. > >The test_cmd_line failure is shallow: the test fails to properly >quote sys.executable when passing it to os.popen. I propose to >fix this in Python 2.5.1; see #1559413 > >test_popen is more tricky. This code has always failed AFAICT, >except that the test itself is a recent addition. The test tries >to pass the following command to os.popen > >"c:\Program Files\python25\python.exe" -c "import sys;print sys.version" > >For some reason, os.popen invokes doesn't directly start Python as >a new process, but install invokes > >cmd.exe /c "c:\Program Files\python25\python.exe" -c "import sys;print >sys.version" > >Can somebody remember what the reason is to invoke cmd.exe (or COMSPEC) >in os.popen? I would guess it was done to force cmd.exe-style argument parsing in the subprocess, which is optional on Win32. > >In any case, cmd.exe fails to execute this, claiming that c:\Program >is not a valid executable. It would run > >cmd.exe /c "c:\Program Files\python25\python.exe" > >just fine, so apparently, the problem is with argument that have >multiple pairs of quotes. I found, through experimentation, that it >*will* accept > >cmd.exe /c ""c:\Program Files\python25\python.exe" -c "import sys;print >sys.version"" > >(i.e. doubling the quotes at the beginning and the end). I'm not quite >sure what algorithm cmd.exe uses for parsing, but it appears that >adding a pair of quotes works in all cases (at least those I could think >of). See # 1559298 You can find the quoting/dequoting rules used by cmd.exe documented on msdn: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_Parsing_C.2b2b_.Command.2d.Line_Arguments.asp Interpreting them is something of a challenge (my favorite part is how the examples imply that the final argument is automatically uppercased ;) Here is an attempted implementation of the quoting rules: http://twistedmatrix.com/trac/browser/trunk/twisted/python/win32.py#L41 Whether or not it is correct is probably a matter of discussion. If you find a more generally correct solution, I would certainly like to know about it. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IronPython and AST branch
On 9/13/06, Sanghyeon Seo <[EMAIL PROTECTED]> wrote: CPython 2.5, which will be released Real Soon Now, is the firstversion to ship with new "AST branch", which have been in developmentfor a long time.AST branch uses ASDL, Abstract Syntax Description Language http://asdl.sourceforge.net/ to describe Abstract Syntax Tree datastructure used by CPython compiler. In theory this is languageindependant, and the same file could be used to generate C# source files.It would be nice, but see below. Having the same AST for Python implementations will be good for applications and libraries using Python implementations's internalparsers and compilers. Currently, those using CPython parser module orcompiler package can't be easily ported to IronPython.What do you think? I have talked to Jim Hugunin about this very topic at the last PyCon. He pointed out that IronPython was started before he knew about the AST branch so that's why he didn't use it. Plus, by the time he did know, it was too late to switch right then and there. As for making the AST branch itself more of a standard, I have talked to Jeremy Hylton about that and he didn't like the idea, at least for now. The reasons for keeping it as "experimental" in terms of exposure at the Python level is that we do not want to lock ourselves down to some AST spec that we end up changing in the future. It's the same reasoning behind not officially documenting the marshal format; we want the flexibility. How best to resolve all of this, I don't know. I completely understand not wanting to lock ourselves down to an AST too soon. Might need to wait a little while after the AST has been out in the wild to see what the user response is and then make a decision. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testsuite fails on Windows if a space is in the path
Martin v. Löwis wrote: > The test suite currently (2.5) has two failures on Windows > if Python is installed into a directory with a space in it > (such as "Program Files"). The failing tests are test_popen > and test_cmd_line. > > The test_cmd_line failure is shallow: the test fails to properly > quote sys.executable when passing it to os.popen. I propose to > fix this in Python 2.5.1; see #1559413 > > test_popen is more tricky. This code has always failed AFAICT, > except that the test itself is a recent addition. The test tries > to pass the following command to os.popen > > "c:\Program Files\python25\python.exe" -c "import sys;print sys.version" > > For some reason, os.popen invokes doesn't directly start Python as > a new process, but install invokes > > cmd.exe /c "c:\Program Files\python25\python.exe" -c "import sys;print > sys.version" > > Can somebody remember what the reason is to invoke cmd.exe (or COMSPEC) > in os.popen? > > In any case, cmd.exe fails to execute this, claiming that c:\Program > is not a valid executable. It would run > > cmd.exe /c "c:\Program Files\python25\python.exe" > > just fine, so apparently, the problem is with argument that have > multiple pairs of quotes. I found, through experimentation, that it > *will* accept > > cmd.exe /c ""c:\Program Files\python25\python.exe" -c "import sys;print > sys.version"" > > (i.e. doubling the quotes at the beginning and the end). I'm not quite > sure what algorithm cmd.exe uses for parsing, but it appears that > adding a pair of quotes works in all cases (at least those I could think > of). See # 1559298 > > Here are my questions: > 1. Should this be fixed before the final release of Python 2.5? > 2. If not, should it be fixed in Python 2.5.1? I'd say not: there >is a potential of breaking existing applications. Applications >might be aware of this mess, and deliberately add a pair of >quotes already. If popen then adds yet another pair of quotes, >cmd.exe will again fail. > 3. If not, should this be fixed in 2.6 in the way I propose in >the patch (i.e. add quotes around the command line)? >Or can anybody propose a different fix? > 4. How should we deal with different values of COMSPEC? Should >this patch only apply for cmd.exe, or should we assume that >other shells are quirk-compatible with cmd.exe in this >respect (or that people stopped setting COMSPEC, anyway)? > > Any comments appreciated, > 1. Because this is almost certainly Windows version-dependent I would suggest that you definitely hold off trying to fix it for 2.5 - it would almost certainly make another RC necessary, and even that wouldn't guarantee the required testing (I sense that Windows versions get rather less pre-release testing than others). 2. I agree with your opinion: anyone for whom this is an important issue has almost certainly addressed it with their own (version-dependent) workarounds that will break with the change. 3/4. Tricky. I don't think it would be wise to assume quirk-compatibility across all Windows command processors. On balance I suspect we should just alter the documentation to note that quirks int he underlying platform may result in unexpected behavior on quoted arguments, perhaps with an example or two. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testsuite fails on Windows if a space is in the path
[Martin v. Löwis]
> ...
> Can somebody remember what the reason is to invoke cmd.exe (or COMSPEC)
> in os.popen?
Absolutely necessary, as any number of shell gimmicks can be used in
the passed string, same as on non-Windows boxes; .e.g.,
>>> import os
>>> os.environ['STR'] = 'SSL'
>>> p = os.popen("findstr %STR% *.py | sort")
>>> print p.read()
build_ssl.py:print " None of these versions appear suitable
for building OpenSSL"
build_ssl.py:print "Could not find an SSL directory in '%s'" %
(sources,)
build_ssl.py:print "Found an SSL directory at '%s'" % (best_name,)
build_ssl.py:# Look for SSL 2 levels up from pcbuild - ie, same
place zlib etc all live.
...
That illustrates envar substitution and setting up a pipe in the
passed string, and people certainly do things like that.
These are the MS docs for cmd.exe's inscrutable quoting rules after /C:
"""
If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote (") characters:
1. If all of the following conditions are met, then quote characters
on the command line are preserved:
- no /S switch
- exactly two quote characters
- no special characters between the two quote characters,
where special is one of: &<>()@^|
- there are one or more whitespace characters between the
the two quote characters
- the string between the two quote characters is the name
of an executable file.
2. Otherwise, old behavior is to see if the first character is
a quote character and if so, strip the leading character and
remove the last quote character on the command line, preserving
any text after the last quote character.
"""
Your
cmd.exe /c "c:\Program Files\python25\python.exe"
example fit clause #1 above.
cmd.exe /c "c:\Program Files\python25\python.exe" -c "import sys;print
sys.version"
fails the "exactly two quote characters" part of #1, so falls into #2,
and after stripping the first and last quotes leaves the senseless:
cmd.exe /c c:\Program Files\python25\python.exe" -c "import sys;print
sys.version
> (i.e. doubling the quotes at the beginning and the end) [works]
And that follows from the above, although not for a reason any sane
person would guess :-(
I personally wouldn't change anything here for 2.5. It's a minefield,
and people who care a lot already have their own workarounds in place,
which we'd risk breaking. It remains a minefield for newbies, but
we're really just passing on cmd.exe's behaviors. People are
well-advised to accept the installer's default directory.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Grammar change in classdef
Nick Coghlan wrote: > As for the reason: it makes it possible to use the same style for classes > without bases as is used for functions without arguments. Prior to this > change, there was a sharp break in the class syntax, such that if you got rid > of the last base class you had to get rid of the parentheses as well. Is the result a new-style or classic-style class? It would be nice if using the empty parens forced a new-style class... -- Talin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Grammar change in classdef
On 9/16/06, Talin <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: > > As for the reason: it makes it possible to use the same style for classes > > without bases as is used for functions without arguments. Prior to this > > change, there was a sharp break in the class syntax, such that if you got > > rid > > of the last base class you had to get rid of the parentheses as well. > > Is the result a new-style or classic-style class? It would be nice if > using the empty parens forced a new-style class... That was my first thought as well. Unfortunately a quick test shows that class Foo(): creates an old style class instead :( -- Gustavo J. A. M. Carneiro "The universe is always one step beyond logic." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Grammar change in classdef
On 9/16/06, Lawrence Oluyede <[EMAIL PROTECTED]> wrote: > > I think that this change should be presented at > > http://docs.python.org/dev/whatsnew/whatsnew25.html > > It's already listed there: http://docs.python.org/dev/whatsnew/other-lang.html > Thanks... also, I don't know if the empty yield statement is mentioned too (I couldn't find it either). Cheers, Fabio ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Grammar change in classdef
> That was my first thought as well. Unfortunately a quick test shows > that class Foo(): creates an old style class instead :( I think that's because until it'll be safe to break things we will stick with classic by default... -- Lawrence http://www.oluyede.org/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Grammar change in classdef
Lawrence Oluyede wrote: >> That was my first thought as well. Unfortunately a quick test shows >> that class Foo(): creates an old style class instead :( > > I think that's because until it'll be safe to break things we will > stick with classic by default... But in this case nothing will be broken, since the () syntax was formerly not allowed, so it won't appear in any existing code. So it would have been a good opportunity to shift over to increased usage new-style classes without breaking anything. Thus, 'class Foo:' would create a classic class, but 'class Foo():' would create a new-style class. However, once it's released as 2.5 that will no longer be the case, as people might start to use () to indicate a classic class. Oh well. -- Talin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Grammar change in classdef
Talin wrote: > Is the result a new-style or classic-style class? It would be nice if > using the empty parens forced a new-style class... No, it wouldn't, IMO. Too subtle a clue. Best to just wait for Py3k when all classes will be new-style. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Grammar change in classdef
On 9/16/06, Talin <[EMAIL PROTECTED]> wrote: Lawrence Oluyede wrote:>> That was my first thought as well. Unfortunately a quick test shows>> that class Foo(): creates an old style class instead :(>> I think that's because until it'll be safe to break things we will > stick with classic by default...But in this case nothing will be broken, since the () syntax wasformerly not allowed, so it won't appear in any existing code. So itwould have been a good opportunity to shift over to increased usage new-style classes without breaking anything.Thus, 'class Foo:' would create a classic class, but 'class Foo():'would create a new-style class.However, once it's released as 2.5 that will no longer be the case, as people might start to use () to indicate a classic class. Oh well.We didn't want there to suddenly be a way to make a new-style class that didn't explicitly subclass 'object'.-Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
