Testing the patch under a Windows XP Qemu virtual machine gives the following error. Works fine under 64-bit Linux.

======================================================================
ERROR: testGetaddrinfo (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Z:\cpython\__svn__\lib\test\test_socket.py", line 568, in testGetaddrinf
o
    socket.getaddrinfo('::1', 80)
gaierror: [Errno 11001] getaddrinfo failed

----------------------------------------------------------------------
Ran 99 tests in 14.851s

FAILED (errors=1)
test test_socket failed -- Traceback (most recent call last):
  File "Z:\cpython\__svn__\lib\test\test_socket.py", line 568, in testGetaddrinf
o
    socket.getaddrinfo('::1', 80)
gaierror: [Errno 11001] getaddrinfo failed

I don't think it's a good idea to make a change like this in a bugfix release, since it could break existing code (though admittedly code that probably isn't doing anything useful).

It's not a huge thing:  both the risk and the gain from making the change are small, but IMO the risk for a bugfix release outweighs the gain.

So I don't think 2.7.1 is an option.  2.7 is an option, but I'm trying to be disciplined given that we're already in release candidate stage.

Thanks.

I'm not sure this is a correct change.  And in fact, I would say that the current quoting of | is also incorrect.

& and | (and ^ and perhaps several others) have special meaning to cmd.exe.  list2cmdline is documented as applying the quoting rules which the "MS C runtime" uses: cmd.exe and the C runtime are different and have different rules.

It seems to me that whoever added the | handling to list2cmdline was confused about the purpose of this function, or failed to properly document the function.

It would make more sense to document list2cmdline as applying cmd.exe-style quoting rules, if those are the rules it is actually going to implement.

A better option, though, would probably be to implement the cmd.exe quoting rules in a different function from the MS C runtime rules.

This all might benefit from a sanity check from someone who's actually worked with the subprocess module before, though (ie, not me).

http://www.autohotkey.net/~deleyd/parameters/parameters.htm#WINCRULES is a helpful reference, by the way.

Attaching issue8983.diff patch.  I am a bit unsure about __init__ docstring change:

1. Are cases when help(type(x)) differs from help(x) important enough to distinguish in docstring?


2. Do we need a default docstring on __init__ at all?  If so, should we keep a reference to class doc which may not be correct?  See issue8973.

3. Why __init__ has a default docstring but __new__ and __del__ don't?

4. There are some other inconsistencies in type docstrings.  E.g., "__subclasschck__ -> check if an class is a subclass" (misspelling and and missing ()).

I've added sizes to the table, reordered some of the sections, and made a couple of other tweaks (like renaming the 'Objects' section to 'Classes') in r81957 (trunk) and r81955-81956 (py3k).

I'll backport these changes to release26-maint and release31-maint;  leaving open for that.

Attaching issue5094f.diff which implements 'UTC±HH:MM' and adds unit tests for more error cases.

Does that mean has_ipv6() is broken maybe?
I've just tested it against a Windows XP sp3 without IPv6 installed (socket.has_ipv6 returns True thought) and it doesn't fail.

Merged to maintenance branches in r81959 (release26-maint) and r81960 (release31-maint).  Closing.

How does issue8973-Struct.diff look?

Looks fine.  I'd probably call the argument 'fmt' rather than 'format', for consistency.  Please commit, with or without the 'format' -> 'fmt' change, as you choose.

Committed in r81961.   Yes, I used "format" for consistency with the manual, but on the second thought consistency within help() is more important.

1. For old-style class instances, both help(i) and help(type(i)) give the help for the instance type, which is highly unhelpful IMO. Otherwise it seems than both C class instances and regular Python new-style class instances give the class doc for help(i). Summary: help(x) is good, help(type(x)) unnecessary.

2. 3. Magic methods are documented through docs.python.org and eventually ABCs, not docstrings. I see no reason to make an exception for __init__, except if removing its docstring breaks code.

4. There are actually two typos ;) Regarding parens, I personally think it’s not helpful to always put them, since e.g. “len()” is not valid, but my choice is not Python’s.

Python 3.1.2 hasn't any arguments except the file name in sys.argv[0]. For example: build.py test
sys.argv[1] will be empty. I tried even the first example from the documentation 15.4 (optparse) but the filename is None. In Python 2.6.5 all is working fine.

The str.format() method allows index lookup on an object that supports __getitem__(). However, negative indexes are not supported.

Examples (using Python 2.6.5):

>>> "{0[0]}".format([0, 1, 2])
'0'

>>> "{0[-1]}".format([0, 1, 2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not str

>>> u"{0[0]}".format([0, 1, 2])
u'0'
>>> u"{0[-1]}".format([0, 1, 2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not unicode

Also notice that spaces matter:

>>> "{0[ 0 ]}".format([0, 1, 2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not str

(The same thing happens on Python 3.1.2)

The problem is that the function get_integer() on Objects/stringlib/string_format.h don't expect spaces or a '-' char, only digits. If the index is not a continuous sequence of digits, it assumes that it is a key for a dict and the index is treated as a string, and that's the cause of the TypeError exception.

This code is the same from 2.6.5 up to trunk.

get_integer() is not very robust to parsing numbers. I'm not familiar with CPython but perhaps the same code used in int(str) can be applied here to take advantage of the better parsing that int() has.

It's not entirely clear to me what issue you're reporting here:  could you provide a short example script that exhibits the problem, and list the exact steps necessary to reproduce, along with actual and expected results?

The behaviour is by design (I think), though perhaps the error messages could be improved.

Are you asking for negative indices and extra space to be accepted?  In that case this should be a feature request rather than a bug report.

Given that the one obvious way of using dict-style syntax given a Python object is to call vars(), I thing adding a __getitem__ is probably a bad idea.

That's right, it doesn't support subscripting. The docs are silent on what namespace is mainly because I don't want to commit to anything other than an object with attributes. But that could be made clearer in the docs.

Examplescript test.py:

import sys
print(sys.argv[1])


Call this script now with an argument, for exmaple: test.py 1234
I expect to see the string 1234 in the console but Python 3 says "IndexError: list index out of range". With Python 2.6.5 I be able to see the correct string 1234.

Thanks for your help and I apologize for the unnecessary ticket.  I was unfamiliar with vars() which seems to accomplish what I wanted.

Don’t hesitate to propose future ideas to the python-ideas mailing list
http://mail.python.org/mailman/listinfo/python-ideas

FYI, the version field is used to note versions where the bug will be fixed, not versions where it’s found. New features and bug fixes go to the dev branch (3.2), security and documentation fixes go to the stable branches (2.6 and 3.1). (2.7 is in release candidate, so it’s frozen.)

Can’t reproduce here:
$ python3.1 -c "import sys; print(sys.argv[1])" 1234
1234
$ python3.1 --version
Python 3.1.2

Hmm.  I don't see any difference between the two here (OS X 10.6).  What platform are you on, and where did your copy of Python 3.1.2 come from?

newton:~ dickinsm$ cat test.py
import sys
print(sys.argv[1])
newton:~ dickinsm$ python3.1 test.py 1234
1234
newton:~ dickinsm$ python2.6 test.py 1234
1234
newton:~ dickinsm$ python3.1
Python 3.1.2 (r312:79147, May 18 2010, 17:21:15) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 
newton:~ dickinsm$ python2.6
Python 2.6.5 (r265:79063, May 18 2010, 17:12:15) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

I'm using Windows XP Professional SP3. I downloaded Python 3.1.2 from this site. Even Python 3.0.1 hasn't worked.

3.0 should not be used and does not get fixes.

Can you try downloading Python again and testing?

P.S. please do not change the component; Lib means “Python files under Lib/ in the source checkout”, but sys is a module built by the interpreter core.

I have already installed Python 3.1.2 a second time. I have selected during the installation that the files shall be compiled into bytecode.

get_integer uses the narrowest possible definition for integer indexes, in order to pass all other strings to mappings.

>>> '{0[ 0 ]} {0[-1]}'.format({' 0 ': 'foo', '-1': 'bar'})
'foo bar'

Remember, it has to guess what type of lookup to do based on whether the value inside [] looks like an integer or not.

From the PEP:
    Because keys are not quote-delimited, it is not possible to
    specify arbitrary dictionary keys (e.g., the strings "10" or
    ":-]") from within a format string.

I don't believe this restriction causes any practical problem.

I'm not sure the error could be improved. The code that's being called is essentially:

>>> [0, 1, 2]['-1']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not str

I'm failing to reproduce this on Windows 7, too.

It sounds as though you're starting the python script without an explict 'python'.  What are your filetype associations for python scripts?

i.e., what's the result of typing 'assoc py' at a console prompt?
And what's the result of the 'ftype' command for the above?

Just for reference, I get:

>assoc.py
.py=Python.File

>ftype Python.File
Python.File=C:\Python31\python.exe "%1" %*

assoc .py
.py=Python.File

I tried this now with Ubuntu and Python 3.1.2 and all works fine. But under Windows XP it doesn't work.

Okay, thanks.  What does

ftype Python.File

give?

ftype Python.File
Python.File="E:\Python31\python.exe" "%1" %*

I've just found issue #7936, which looks like the same problem.  I'm going to close this issue as a duplicate of that one;  further discussion should be moved there.

Closed issue 8984 as a duplicate of this;  merging nosy lists.

Tom, did you ever find a solution to this problem?

Here's a link to a similar discussion about Perl on Windows:

http://community.activestate.com/forum-topic/problem-passing-arguments

A work-around could be that the caller puts double quotes around the individual elements of the sequence that need it.
However, this won't work because list2cmdline doesn't handle backslash quoting properly. An element like r'"foo"' is translated to r'\"foo\"'. This is incorrect because cmd.exe cannot handle this. The backslash may be appropriate for embedded quotes (like in r'foo"bar'), but not for outer quotes (like in r'"foobar"').

The user shouldn't have to worry with adding quotes anyway, so it would be better to demand that '|' and '&' are passed as separate elements in the sequence. Example ['echo', 'foo', '&', 'bar'].
When someone passes ['echo', 'foo&bar'], it is very obvious that r'echo "foo&bar"' is expected and not r'echo foo & bar'.

I have added a patch for this way of working of list2cmdline.

From various other sites, and from experiments (thanks Eric Smith) it looks like the associations reported by 'assoc' and 'ftype' aren't necessarily the associations that are actually being used.

Sworddragon:  can you get any useful information out of the Windows registry (e.g., using regedit, searching for Python.File, and looking under shell\open\command), or by setting file associations through the Control Panel?

I don't know enough about Python on Windows to know whether there's any hope that this is a problem that can be solved at the Python end, but I'd guess not.

I agree with Mark: there's probably nothing Python can do about this. It's almost certainly an error with how Python is being invoked.

That being said, it would be interesting to see what the registry key HKEY_CLASSES_ROOT\Python.File\shell\open\command contains.

Thanks for improving the documentation!

A couple of comments for possible further improvements:

I think it would be helpful to also see an early notice about how to achieve platform independence, versus the default of the local platform.

And perhaps the description of "standard" perhaps could be improved.

Perhaps something like the following could be used. Relative to release26-maint/Doc/library/struct.rst rev 81959.

In Python3.2, calling math.erfc with a value in [-27.2, -30) raises
an OverflowError: math range error. This is inconsistent with the
erfc function from scipy (scipy.special.erfc) as well as with the C99
function by the same name, both of which return 2. I suspect that
this is the result of the cutoff for the use of the continuing fraction
approximation of erfc beginning when abs(x) > 30, but I'm not sure.

> * I would list them all in one directive, like this:

Ok, done. Attaching the updated patch


> There is no description in that directive.  Best move part of the
description above them in it.

I am not sure I understand your request. Could you clarify?


>  NL and COMMENT are defined in tokenize because they are neither 
defined nor used by the Python tokenizer.

Oh, I just realized the source of my misunderstanding: token.py captures token types as they are returned by python's own tokenizer. While tokenize module  does its own tokenization and produces results which are a bit different. COMMENT and NL tokens is one of the differences but there is a difference in how the operation tokens are treated. In fact tokenize's docstring explicitly says so.

... It is designed to match the working of the Python tokenizer exactly, except that it produces COMMENT tokens for comments and gives type OP for all operators ...

I think this clarification should go into official docs as well, would you agree?

PS. even with this clarification, I find the situation quite a bit confusing: especially given that tok_name dict from token module does have a name for COMMENT and that name is inserted by tokenize module..  So I still feel that just adding COMMENT and NL to token module (with clarification that they are not generated by the python's own tokenizer) would be a bit cleaner.

Revert seems sensible in this situation.

I'm not sure my last message was clear.

> A work-around could be that ...

What problem is being worked around?

I discovered this investigating a bug report that python-cjson doesn't compile properly on Windows (http://pypi.python.org/pypi/python-cjson). Cjson's setup.py asks distutils to compile with the flag '-DMODULE_VERSION="1.0.5"', but distutils.spawn._nt_quote_args is not escaping the quotes correctly.

Specifically, the current behaviour is:
>>> distutils.spawn._nt_quote_args(['-DMODULE_VERSION="1.0.5"'])
['-DMODULE_VERSION="1.0.5"']

I expect the following:
>>> distutils.spawn._nt_quote_args(['-DMODULE_VERSION="1.0.5"'])
['"-DMODULE_VERSION=""1.0.5"""']

Not surprising, since that function contains a big comment:
    # XXX this doesn't seem very robust to me -- but if the Windows guys
    # say it'll work, I guess I'll have to accept it.  (What if an arg
    # contains quotes?  What other magic characters, other than spaces,
    # have to be escaped?  Is there an escaping mechanism other than
    # quoting?)

It only escapes spaces, and that's it. I've proposed a patch which escapes the following characters properly: "&()<>^| (as far as I can tell, these are the "reserved" characters on Windows).

Note: I did not escape * or ?, the wildcard characters. As far as I can tell, these only have special meaning on the command-line itself, and not when supplied to a program.

Alternatively, it could call subprocess.list2cmdline (but there seem to be issues with that: http://bugs.python.org/issue8972).

Reverted in r81964, marking as 3.2 only.

For 3.2, I'll get rid of the hack by having SetArgV treat both "-c" and "-m" as special values for sys.argv[0], and by adding some unit tests that make sure the presence of files with those names has no effect on the value of sys.path[0] when the corresponding command line switches are used.

This registry key contains "E:\Python31\python.exe" "%1" %*. I have too 2 python versions installed and manually associated the .py files to Python 3.

Can you provide a patch?

Thanks for the report.  What platform are you on?  I'm not seeing this behaviour on OS X:

Python 3.2a0 (py3k:81935M, Jun 12 2010, 10:01:38) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import erfc
>>> erfc(-28.0)
2.0

It should be easy to fix, since erfc is already 2.0 (to within machine accuracy) in that argument range, but I'd like to understand where the problem is coming from first.