From report at bugs.python.org  Sat Oct  1 00:07:26 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 30 Sep 2011 22:07:26 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1317414642.85.0.0881821462071.issue12753@psf.upfronthosting.co.za>
Message-ID: <29624.1317420430@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

>Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Leaving named sequences for unicodedata.lookup() only (and not for
> \N{}) makes sense.

There are certainly advantages to that strategy: you don't have to
deal with [\N{sequence}] issues.  If the argument to unicode.lookup()
and be any of name, alias, or sequence, that seems ok.  \N{} should
still do aliases, though, since those don't have the complication that
sequences have.

You may wish unicode.name() to return the alias in preference, however.
That's what we do.  And of course, there is no issue of sequences there.

The rest of this perhaps painfully long message is just elaboration
and icing on what I've said above.

--tom

> The list of aliases is so small (11 entries) that I'm not sure using a
> binary search for it would bring any advantage.  Having a single
> lookup algorithm that looks in both tables doesn't work because the
> aliases lookup must be in _getcode for \N{...} to work, whereas the
> lookup of named sequences will happen in unicodedata_lookup
> (Modules/unicodedata.c:1187).  I think we can leave the for loop over
> aliases in _getcode and implement a separate (and binary) search in
> unicodedata_lookup for the named sequences.  Does that sound fine?

If you mean, is it ok to add just the aliases and not the named sequences to
\N{}, it is certainly better than not doing so at all.  Plus that way you do
*not* have to figure out what in the world to to do with [^a-c\N{sequence}],
since that would have be something like (?!\N{sequence})[^a-c]), which is 
hardly obvious, especially if \N{sequence} actually starts with [a-c].

However, because the one namespace comprises all three of names,
aliases, and named sequences, it might be best to have a functional
(meaning, non-regex) API that allows one to do a fetch on the whole
namespace, or on each individual component.

The ICU library supports this sort of thing.  In ICU4J's Java bindings, 
we find this:

    static int getCharFromExtendedName(String name) 
       [icu] Find a Unicode character by either its name and return its code point value.
    static int	getCharFromName(String name) 
       [icu] Finds a Unicode code point by its most current Unicode name and return its code point value.
    static int	getCharFromName1_0(String name) 
       [icu] Find a Unicode character by its version 1.0 Unicode name and return its code point value.
    static int	getCharFromNameAlias(String name) 
       [icu] Find a Unicode character by its corrected name alias and return its code point value.

The first one obviously has a bug in its definition, as the English
doesn't scan.  Looking at the full definition is even worse.  Rather
than dig out the src jar, I looked at ICU4C, but its own bindings are
completely different.  There you have only one function, with an enum to
say what namespace to access:

    UChar32 u_charFromName  (       UCharNameChoice         nameChoice, 
		    const char *    name, 
		    UErrorCode *    pErrorCode 
	    )

The UCharNameChoice enum tells what sort of thing you want:

    U_UNICODE_CHAR_NAME,
    U_UNICODE_10_CHAR_NAME,
    U_EXTENDED_CHAR_NAME,
    U_CHAR_NAME_ALIAS,          
    U_CHAR_NAME_CHOICE_COUNT

Looking at the src for the Java is no more immediately illuminating, 
but I think that "extended" may refer to a union of the old 1.0 names 
with the current names.

Now I'll tell you what Perl does.  I do this not to say it is "right",
but just to show you one possible strategy.  I also am in the middle
of writing about this for the Camel, so it is in my head.

Perl does not provide the old 1.0 names at all.  We don't have a Unicode
1.0 legacy to support, which makes this cleaner.  However, we do provide
for the names of the C0 and C1 Control Codes, because apart from Unicode
1.0, they don't condescend to name the ASCII or Latin1 control codes.  

We also provide for certain well known aliases from the Names file:
anything that says "* commonly abbreviated as ...", so things like LRO
and ZWJ and such.

Perl makes no distinction between anything in the namespace when using
the \N{} form for string and regex escapes.  That means when you use
"\N{...}" or /\N{...}/, you don't know which it is, nor can you.
(And yes, the bracketed character class issue is annoying and unsolved.)

However, the "functional" API does make a slight distinction.  

 -- charnames::vianame() takes a name or alias (as a string) and returns a single 
	integer code point.

	eg: This therefore converts "LATIN SMALL LETTER A" into 0x61.
	    It also converts both 
		BYZANTINE MUSICAL SYMBOL FHTORA SKLIRON CHROMA VASIS
	    and 
		BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS
	    into 0x1D0C5.  See below.

 -- charnames::string_vianame() takes a string name, alias, *or* sequence, 
	and gives back a string.   

	eg: This therefore converts "LATIN SMALL LETTER A" into "a".
            Since it has a string return instead of an int, it now also
            handles everything from NamedSequences file as well. (See below.)

 -- charnames::viacode() takes an integer can gives back the official alias 
	if there is one, and the official name if there is not.

	eg: This converts 0x61 into "LATIN SMALL LETTER A".
            It also converts 0x1D0C5 into "BYZANTINE MUSICAL SYMBOL FTHORA
            SKLIRON CHROMA VASIS".

Consider

    BYZANTINE MUSICAL SYMBOL FHTORA SKLIRON CHROMA VASIS

That was an error, and there is an official alias fixing it:

    BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS

(That's FHTORA vs FTHORA.)

You may use either as the name, and if you reverse the code 
point to name, you get the replacement alias.

 % perl -mcharnames -wle 'printf "%04X\n", charnames::vianame("BYZANTINE MUSICAL SYMBOL FHTORA SKLIRON CHROMA VASIS")'
 1D0C5

 % perl -mcharnames -wle 'printf "%04X\n", charnames::vianame("BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS")'
 1D0C5

 % perl -mcharnames -wle 'print charnames::viacode(charnames::vianame("BYZANTINE MUSICAL SYMBOL FHTORA SKLIRON CHROMA VASIS"))'
 BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS

So on round-tripping, I gave it the "wrong" one (the original) and it gave
me back the "right" one (the replacement).

Using the \N{} thing, it again doesn't matter:

 % perl -mcharnames=:full -wle 'printf "%04X\n", ord "\N{BYZANTINE MUSICAL SYMBOL FHTORA SKLIRON CHROMA VASIS}"'
 1D0C5

 % perl -mcharnames=:full -wle 'printf "%04X\n", ord "\N{BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS}"'
 1D0C5

The interesting thing is the named sequences. string_vianame() works just fine on those:

 % perl -mcharnames -wle 'print length charnames::string_vianame("LATIN CAPITAL LETTER A WITH MACRON AND GRAVE")'
 2

 % perl -mcharnames -wle 'printf "U+%v04X\n",  charnames::string_vianame("LATIN CAPITAL LETTER A WITH MACRON AND GRAVE")'
 U+0100.0300

And that works fine with \N{} as well (provided you don't try charclasses):

 % perl -mcharnames=:full -wle 'print "\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}"'
 ??

 % perl -mcharnames=:full -wle 'print "\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}"' | uniquote -v
 \N{LATIN CAPITAL LETTER A WITH MACRON}\N{COMBINING GRAVE ACCENT}

 % perl -mcharnames=:full -wle 'print length "\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}"'
 2

 % perl -mcharnames=:full -wle 'printf "U+%v04X\n", "\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}"'
 U+0100.0300

It's kinda sad that for \N{} and sequneces you can't just "do the right
thing" with strings and say that charclass stuff just isn't supported.
But my guess is that this simply won't work because you don't have 
first class regexes.  If you pass both of these to the regex engine,
they should behave the same (and would, assuming the regex compiler
knows about \N{} escapes):

    "\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}"
    r'\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}'

However, that falls part if you do 

    "[^\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}]"
    r'[^\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}]'

Because the compiler will do the substitution early on the first
one but not the second.  This seems a problem, eh?  So I guess
you can't do it at all?  Or could you document it?   I think there
is no good solution here.  Perl can and does actually do something
quite reasonable in the noncharclass case, but that is because we
know that we are compiling a regex in virtually all scenarios.

    % perl -Mcharnames=:full -le 'print qr/\N{LATIN SMALL LETTER A}/'
    (?^u:\N{U+61})

    % perl -Mcharnames=:full -le 'print qr/\N{LATIN CAPITAL LETTER A WITH MACRON}/'
    (?^u:\N{U+100})

    % perl -Mcharnames=:full -le 'print qr/\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}/'
    (?^u:\N{U+100.300})

So you can do:

    % perl -Mcharnames=:full -le 'print "\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}" =~ /\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}/'
    1

And it is just fine.  The issue is that there are ways for you to get
yoruself into trouble if you do string-string stuff:

    % perl -Mcharnames=:full -le 'print "\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}" =~ "\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}"'
    1
    % perl -Mcharnames=:full -le 'print "\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}" =~ "^[\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}]+\$"'
    1

That works, but only accidentally, because of course U+0100.0300 contains
nothing but either U+0100 or U+0300.

This is not a solved problem.

I hope this helps.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sat Oct  1 00:18:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Sep 2011 22:18:39 +0000
Subject: [issue13071] IDLE refuses to open on windows 7
In-Reply-To: <1317341122.37.0.866117748717.issue13071@psf.upfronthosting.co.za>
Message-ID: <1317421119.87.0.0227784627219.issue13071@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

IDLE with Py3.2.2 works fine on Win 7 for me (desktop) and daughter (laptop), so there is something peculiar with your system.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13071>
_______________________________________

From report at bugs.python.org  Sat Oct  1 01:54:18 2011
From: report at bugs.python.org (Victor Semionov)
Date: Fri, 30 Sep 2011 23:54:18 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317426858.54.0.0535941427661.issue13070@psf.upfronthosting.co.za>


Victor Semionov <vsemionov at gmail.com> added the comment:

Thanks Charles-Fran?ois,

I tested your patch with "make test" and with my program. Both work fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Sat Oct  1 02:24:38 2011
From: report at bugs.python.org (Alexander)
Date: Sat, 01 Oct 2011 00:24:38 +0000
Subject: [issue13082] Can't open new window in python
Message-ID: <1317428678.05.0.613085535741.issue13082@psf.upfronthosting.co.za>


New submission from Alexander <akeenjames at gmail.com>:

When I try to open a new window in python to actually type a program and not just make single python instructions (this is while running on IDLE), python stops working and I have to force quit

----------
assignee: ronaldoussoren
components: Macintosh
messages: 144711
nosy: Reason2Rage, ronaldoussoren
priority: normal
severity: normal
status: open
title: Can't open new window in python
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13082>
_______________________________________

From report at bugs.python.org  Sat Oct  1 03:17:59 2011
From: report at bugs.python.org (Mike Hoy)
Date: Sat, 01 Oct 2011 01:17:59 +0000
Subject: [issue13075] PEP-0001 contains dead links
In-Reply-To: <1317374485.54.0.239839552518.issue13075@psf.upfronthosting.co.za>
Message-ID: <1317431879.92.0.681828900965.issue13075@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

I'm working on making a patch for this. I just want to confirm that the information I found is correct:

Article Name
OLD URL
ARCHIVED URL

How Python is Developed 
OLD: http://www.python.org/dev/intro/
ARCHIVE: http://www.etsimo.uniovi.es/python/dev/intro/

Python's Development Process
http://www.python.org/dev/process/
http://www.etsimo.uniovi.es/python/dev/process/

Why Develop Python?
http://www.python.org/dev/why/
http://www.etsimo.uniovi.es/python/dev/why/

Development Tools
http://www.python.org/dev/tools/
http://www.etsimo.uniovi.es/python/dev/tools/

Frequently Asked Questions for Developers
http://www.python.org/dev/faq/
http://www.etsimo.uniovi.es/python/dev/faq/

----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13075>
_______________________________________

From report at bugs.python.org  Sat Oct  1 03:19:07 2011
From: report at bugs.python.org (Mike Hoy)
Date: Sat, 01 Oct 2011 01:19:07 +0000
Subject: [issue13075] PEP-0001 contains dead links
In-Reply-To: <1317374485.54.0.239839552518.issue13075@psf.upfronthosting.co.za>
Message-ID: <1317431947.96.0.55975689313.issue13075@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

Of course I would be creating new articles based on the archived pages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13075>
_______________________________________

From report at bugs.python.org  Sat Oct  1 03:50:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Oct 2011 01:50:51 +0000
Subject: [issue13083] _sre: getstring() releases the buffer before using it
Message-ID: <1317433851.47.0.137164360321.issue13083@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

getstring() of the _sre module contains the following code:
-------------
    ...
    buffer = Py_TYPE(string)->tp_as_buffer;
    if (!buffer || !buffer->bf_getbuffer ||
        (*buffer->bf_getbuffer)(string, &view, PyBUF_SIMPLE) < 0) {
            PyErr_SetString(PyExc_TypeError, "expected string or buffer");
            return NULL;
    }

    /* determine buffer size */
    bytes = view.len;
    ptr = view.buf;

    /* Release the buffer immediately --- possibly dangerous
       but doing something else would require some re-factoring
    */
    PyBuffer_Release(&view);
    ...
-------------

getstring() is used to initialize a state or a pattern. State and pattern have destructors (pattern_dealloc() and state_fini()), so it should be possible to keep the view active and call PyBuffer_Release() in the destructor.

----------
components: Library (Lib)
messages: 144714
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: _sre: getstring() releases the buffer before using it
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13083>
_______________________________________

From report at bugs.python.org  Sat Oct  1 03:52:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 01 Oct 2011 01:52:00 +0000
Subject: [issue13075] PEP-0001 contains dead links
In-Reply-To: <1317374485.54.0.239839552518.issue13075@psf.upfronthosting.co.za>
Message-ID: <1317433920.76.0.141121490091.issue13075@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

These pages are all still on python.org - the links just need to be updated to point to the devguide equivalents (under http://docs.python.org/devguide)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13075>
_______________________________________

From report at bugs.python.org  Sat Oct  1 04:15:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 01 Oct 2011 02:15:43 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1317435343.47.0.967017479927.issue12753@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached a new patch that adds support for named sequences (still needs some test and can probably be improved).

> There are certainly advantages to that strategy: you don't have to
> deal with [\N{sequence}] issues.

I assume with [] you mean a regex character class, right?

> If the argument to unicode.lookup() and be any of name, alias, or 
> sequence, that seems ok. 

With my latest patch, all 3 are supported.

> \N{} should still do aliases, though, since those don't have the 
> complication that sequences have.

\N{} will only support names and aliases (maybe this can go in 2.7/3.2 too).

> You may wish unicode.name() to return the alias in preference,
> however. That's what we do.  And of course, there is no issue of 
> sequences there.

This can be done for 3.3, but I wonder if it might create problems.  People might use unicodedata.name() to get a name and use it elsewhere, and the other side might not be aware of aliases.

----------
Added file: http://bugs.python.org/file23280/issue12753-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sat Oct  1 08:39:35 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 01 Oct 2011 06:39:35 +0000
Subject: [issue13080] test_email fails in refleak mode
In-Reply-To: <1317411097.99.0.612727168161.issue13080@psf.upfronthosting.co.za>
Message-ID: <1317451175.5.0.233175581313.issue13080@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think this is a duplicate of #12788.

----------
nosy: +skrah
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> test_email fails with -R

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13080>
_______________________________________

From report at bugs.python.org  Sat Oct  1 11:48:23 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 01 Oct 2011 09:48:23 +0000
Subject: [issue13084] test_signal failure
Message-ID: <1317462503.63.0.0518543153457.issue13084@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Got this failure on Debian lenny amd64:

[1/1] test_signal
test test_signal failed -- Traceback (most recent call last):
  File "/home/stefan/cpython/Lib/test/test_signal.py", line 339, in test_pending
    """,  *signals)
  File "/home/stefan/cpython/Lib/test/test_signal.py", line 263, in check_wakeup
    assert_python_ok('-c', code)
  File "/home/stefan/cpython/Lib/test/script_helper.py", line 50, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/home/stefan/cpython/Lib/test/script_helper.py", line 42, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
Traceback (most recent call last):
  File "<string>", line 41, in <module>
  File "<string>", line 16, in check_signum
Exception: (10, 12) != (12, 10)

1 test failed:
    test_signal
[103837 refs]

----------
components: Tests
messages: 144718
nosy: skrah
priority: normal
severity: normal
status: open
title: test_signal failure
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13084>
_______________________________________

From report at bugs.python.org  Sat Oct  1 11:51:39 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 01 Oct 2011 09:51:39 +0000
Subject: [issue13085] : memory leaks
Message-ID: <1317462699.45.0.870961708747.issue13085@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I think a couple of leaks were introduced by the pep-393
changes (see the patch).

----------
components: Interpreter Core
files: pep-393-leaks.diff
keywords: patch
messages: 144719
nosy: haypo, loewis, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: : memory leaks
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file23281/pep-393-leaks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13085>
_______________________________________

From report at bugs.python.org  Sat Oct  1 11:52:15 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 01 Oct 2011 09:52:15 +0000
Subject: [issue13085] pep-393: memory leaks
In-Reply-To: <1317462699.45.0.870961708747.issue13085@psf.upfronthosting.co.za>
Message-ID: <1317462735.78.0.198685401056.issue13085@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
title: : memory leaks -> pep-393: memory leaks

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13085>
_______________________________________

From report at bugs.python.org  Sat Oct  1 11:54:05 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 01 Oct 2011 09:54:05 +0000
Subject: [issue13084] test_signal failure
In-Reply-To: <1317462503.63.0.0518543153457.issue13084@psf.upfronthosting.co.za>
Message-ID: <1317462845.66.0.0454078462025.issue13084@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13084>
_______________________________________

From report at bugs.python.org  Sat Oct  1 12:19:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 01 Oct 2011 10:19:05 +0000
Subject: [issue13084] test_signal failure
In-Reply-To: <1317462503.63.0.0518543153457.issue13084@psf.upfronthosting.co.za>
Message-ID: <1317464345.91.0.210701626116.issue13084@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

See http://bugs.python.org/issue12469, specifically http://bugs.python.org/issue12469#msg139831

"""
> > When signals are unblocked, pending signal ared delivered in the reverse order
> > of their number (also on Linux, not only on FreeBSD 6).
> 
> I don't like this.
> POSIX doesn't make any guarantee about signal delivery order, except
> for real-time signals.
> It might work on FreeBSD and Linux, but that's definitely not
> documented, and might break with new kernel releases, or other
> kernels.

It looks like it works like this on most OSes (Linux, Mac OS X, Solaris,
FreeBSD): I don't see any test_signal failure on 3.x buildbots. If we
have a failure, we can use set() again, but only for test_pending:
signal order should be reliable if signals are not blocked.
"""

Looks like we now have a failure :-)

----------
nosy: +haypo, neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13084>
_______________________________________

From report at bugs.python.org  Sat Oct  1 12:57:42 2011
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 01 Oct 2011 10:57:42 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about 3.x instead
	of 3.0
Message-ID: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

The title of howto/cporting.rst is "Porting Extension Modules To 3.0".  It then talks about 3.0 in a whole bunch of places.  Considering that we're working on 3.3, and considering that 3.0 is end-of-lifed (not even meriting a branch in hg), wouldn't it be better for the document to talk about "3.x"?  It already talks about "2.x" in several places, so it's not like this would confuse the reader.

Alternatively, we could remove the ".0" (and maybe the ".x"s) so the document talks about porting from "Python 2" to "Python 3".

I'd be happy to make the patch / check in the change.

----------
assignee: larry
components: Documentation
messages: 144721
nosy: larry
priority: low
severity: normal
status: open
title: Update howto/cporting.rst so it talks about 3.x instead of 3.0
type: feature request
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sat Oct  1 12:59:48 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 01 Oct 2011 10:59:48 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining
	marks	inappropriately
In-Reply-To: <26418.1317386261@chthon>
Message-ID: <4E86F2A2.9020107@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>  * Word characters are Alphabetic + Mn+Mc+Me + Nd + Pc.

Where did you get that definition from? UTS#18 defines
"<word_character>", which is Alphabetic + U+200C + U+200D
(i.e. not including marks, but including those

> I think you are looking for here are Word characters without 
> Nd + Pc, so just Alphabetic + Mn+Mc+Me.  
> 
> Is that right?

With your definition of "Word character" above, yes, that's right.
Marks won't start a word, though.

As for terminology: I think the documentation should continue to
speak about "words" and "letters", and then define what is meant
in this context. It's not that the Unicode consortium invented
the term "letter", so we should use it more liberally than just
referring to the L* categories.

----------
title: str.title() is overzealous by upcasing combining marks inappropriately -> str.title() is overzealous by upcasing combining marks	inappropriately

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12737>
_______________________________________

From report at bugs.python.org  Sat Oct  1 13:07:49 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sat, 01 Oct 2011 11:07:49 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <4E86F2A2.9020107@v.loewis.de>
Message-ID: <32317.1317467261@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Martin v. L?wis <report at bugs.python.org> wrote
   on Sat, 01 Oct 2011 10:59:48 -0000: 

>>  * Word characters are Alphabetic + Mn+Mc+Me + Nd + Pc.

> Where did you get that definition from? UTS#18 defines
> "<word_character>", which is Alphabetic + U+200C + U+200D
> (i.e. not including marks, but including those

>From UTS#18 RL1.2A in Annex C, where a \p{word} or \w character 
is defined to be 

 \p{alpha}
 \p{gc=Mark}
 \p{digit}
 \p{gc=Connector_Punctuation}

>> I think you are looking for here are Word characters without 
>> Nd + Pc, so just Alphabetic + Mn+Mc+Me.  
>> 
>> Is that right?
> 
> With your definition of "Word character" above, yes, that's right.

It's not mine.  It's tr18's.

> Marks won't start a word, though.

That's the smarter boundary thing they talk about.  

I'm not myself familiar with \pM

> As for terminology: I think the documentation should continue to
> speak about "words" and "letters", and then define what is meant
> in this context. It's not that the Unicode consortium invented
> the term "letter", so we should use it more liberally than just
> referring to the L* categories.

I really don't think it wise to have private definitions of these.

If Letter doesn't mean L?, things get too weird.  That's why 
there are separate definitions of alphabetic, word, etc.

--tom

----------
title: str.title() is overzealous by upcasing combining marks	inappropriately -> str.title() is overzealous by upcasing combining marks inappropriately

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12737>
_______________________________________

From report at bugs.python.org  Sat Oct  1 13:13:56 2011
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 01 Oct 2011 11:13:56 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <1317467636.96.0.0753461105779.issue13053@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Attached is a patch against trunk branch "2.7" (rev dec00ae64ca8) adding documentation on how to migrate CObjects to Capsules.  Delta the inevitable formatting bikeshedding, this should be ready to go.  I've smoke-tested the "capsulethunk.h" locally and it works fine.

When accepted, I'll check this in to the 2.7 branch, then merge into the 3.1, 3.2, and trunk branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Sat Oct  1 13:14:37 2011
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 01 Oct 2011 11:14:37 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <1317467677.08.0.487945214.issue13053@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Whoops, forgot to attach.  *Here's* the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file23282/larry.cporting.capsules.r1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Sat Oct  1 13:39:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 01 Oct 2011 11:39:15 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about 3.x instead
	of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1317469155.24.0.940219483241.issue13086@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
versions:  -Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sat Oct  1 13:47:32 2011
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 01 Oct 2011 11:47:32 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about 3.x instead
	of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1317469652.17.0.802115057196.issue13086@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Why shouldn't I check this in to the 2.7 / 3.1 branches?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sat Oct  1 13:52:38 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Oct 2011 11:52:38 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about 3.x instead
	of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1317469958.43.0.105880138486.issue13086@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

3.1 because it won't have any effect; it's in security-fix mode.

For 2.7 go ahead.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sat Oct  1 13:58:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 Oct 2011 11:58:07 +0000
Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format
In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za>
Message-ID: <1317470287.77.0.789193837648.issue13072@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mark.dickinson, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13072>
_______________________________________

From report at bugs.python.org  Sat Oct  1 14:02:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 Oct 2011 12:02:49 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317470569.15.0.467009188866.issue13070@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Shouldn't the test use "self.BufferedRWPair" instead of "io.BufferedRWPair"?
Also, is it ok to just return NULL or should the error state also be set?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Sat Oct  1 14:17:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Oct 2011 12:17:07 +0000
Subject: [issue13084] test_signal failure
In-Reply-To: <1317462503.63.0.0518543153457.issue13084@psf.upfronthosting.co.za>
Message-ID: <1317471427.31.0.485011570963.issue13084@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

WakeupSignalTests.test_pending() doesn't really check our signal handler but more the operating system, especially pthread_sigmask(SIG_UNBLOCK). I don't think that Python should test the signal order delivered by the operating systems when SIG_UNBLOCK.

Anyone motivated to write a patch to use again a set()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13084>
_______________________________________

From report at bugs.python.org  Sat Oct  1 15:43:59 2011
From: report at bugs.python.org (etuardu)
Date: Sat, 01 Oct 2011 13:43:59 +0000
Subject: [issue13077] Unclear behavior of daemon threads on main thread exit
In-Reply-To: <1317396642.03.0.535538271179.issue13077@psf.upfronthosting.co.za>
Message-ID: <1317476639.29.0.288812849627.issue13077@psf.upfronthosting.co.za>


etuardu <edonan at gmail.com> added the comment:

Let me put it this way: the definition of daemon thread describes the behaviour of the Python program running it (its exit condition in particular) instead of going straight to the point describing the behaviour of the daemon thread itself first, and finally add other considerations.

Specifically, I think a situation like the following is not quite clear from the given definition:
- I have a main thread and a secondary thread, both printing to stdout.
- At some point, I press Ctrl+c raising an unhandled KeyboardInterrupt exception in the main thread, which kills it.

This is what I get using a daemon thread:

etuardu at subranu:~/Desktop$ python foo.py # other = daemon
other thread
main thread
other thread
main thread
^C
Traceback [...]
KeyboardInterrupt
etuardu at subranu:~/Desktop$ # process terminates

This is what I get using a non-daemon thread:

etuardu at subranu:~/Desktop$ python foo.py # other = non-daemon
other thread
main thread
other thread
main thread
^C
Traceback [...]
KeyboardInterrupt
other thread
other thread
other thread
... (process still running)

So, to explain the significance of the "daemon" flag, I'd say something like:

A daemon thread is shut down when the main thread and all others non-daemon threads end.
This means a Python program runs as long as non-daemon threads, such as the main thread, are running.
When only daemon threads are left, the Python program exits.

Of course this can be understood from the current definition (?the entire Python program exits when only daemon threads are left?), still it looks a bit sybilline to me.

----------
Added file: http://bugs.python.org/file23283/foo.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13077>
_______________________________________

From report at bugs.python.org  Sat Oct  1 16:24:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 01 Oct 2011 14:24:10 +0000
Subject: [issue13084] test_signal failure
In-Reply-To: <1317462503.63.0.0518543153457.issue13084@psf.upfronthosting.co.za>
Message-ID: <1317479050.55.0.125396587147.issue13084@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23284/check_signum_order.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13084>
_______________________________________

From report at bugs.python.org  Sat Oct  1 16:35:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Oct 2011 14:35:49 +0000
Subject: [issue13085] pep-393: memory leaks
In-Reply-To: <1317462699.45.0.870961708747.issue13085@psf.upfronthosting.co.za>
Message-ID: <E1RA0fL-0001RA-R0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1b203e741fb2 by Martin v. L?wis in branch 'default':
Issue 13085: Fix some memory leaks. Patch by Stefan Krah.
http://hg.python.org/cpython/rev/1b203e741fb2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13085>
_______________________________________

From report at bugs.python.org  Sat Oct  1 16:36:37 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 01 Oct 2011 14:36:37 +0000
Subject: [issue13085] pep-393: memory leaks
In-Reply-To: <1317462699.45.0.870961708747.issue13085@psf.upfronthosting.co.za>
Message-ID: <1317479797.26.0.623219116204.issue13085@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13085>
_______________________________________

From report at bugs.python.org  Sat Oct  1 16:37:39 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 01 Oct 2011 14:37:39 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about 3.x instead
	of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1317479859.54.0.853932632552.issue13086@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I like "Python 2" more than "2.x".

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sat Oct  1 16:37:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 Oct 2011 14:37:50 +0000
Subject: [issue12804] make test should not enable the urlfetch resource
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <1317479870.49.0.708137548835.issue12804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please consider reverting this patch. If you have flaky network connection, you can override the test flags yourself.

----------
nosy: +brett.cannon, pitrou
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Sat Oct  1 16:42:35 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 01 Oct 2011 14:42:35 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining
	marks	inappropriately
In-Reply-To: <32317.1317467261@chthon>
Message-ID: <4E8726D9.2040604@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> As for terminology: I think the documentation should continue to
>> speak about "words" and "letters", and then define what is meant
>> in this context. It's not that the Unicode consortium invented
>> the term "letter", so we should use it more liberally than just
>> referring to the L* categories.
> 
> I really don't think it wise to have private definitions of these.
> 
> If Letter doesn't mean L?, things get too weird.  That's why 
> there are separate definitions of alphabetic, word, etc.

But I won't be using the word "Letter", but "letter" (lower case).
Nobody will assume that this refers to the Unicode standard;
people would rather expect that this is [A-Za-z] (i.e. not expect
non-ASCII characters to be considered at all). So elaboration is
necessary, anyway. I take the risk of confusing the 10 people that
ever read UTS#18 :-)

----------
title: str.title() is overzealous by upcasing combining marks inappropriately -> str.title() is overzealous by upcasing combining marks	inappropriately

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12737>
_______________________________________

From report at bugs.python.org  Sat Oct  1 16:45:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Oct 2011 14:45:26 +0000
Subject: [issue12804] make test should not enable the urlfetch resource
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <E1RA0of-0002O3-FV@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7fabd75a6ae4 by Antoine Pitrou in branch 'default':
Backout of changeset 228fd2bd83a5 by Nadeem Vawda in branch 'default':
http://hg.python.org/cpython/rev/7fabd75a6ae4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Sat Oct  1 16:48:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 Oct 2011 14:48:28 +0000
Subject: [issue12804] make test should not enable the urlfetch resource
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <1317480508.44.0.991334430589.issue12804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Change reverted. "make test" should run a comprehensive test of Python's facilities, and that includes network facilities. We only exclude functionality where testing is hostile to the user (largefile,audio,gui).

You could add "make offlinetest" if you care, though.

----------
components: +Tests
priority: normal -> low
resolution: fixed -> 
stage: committed/rejected -> 
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Sat Oct  1 17:04:40 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 01 Oct 2011 15:04:40 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences
	from	Unicode charnames namespace
In-Reply-To: <1317414642.85.0.0881821462071.issue12753@psf.upfronthosting.co.za>
Message-ID: <4E872C06.8080506@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Does that sound fine?

Yes, that's fine as well.

----------
title: \N{...} neglects formal aliases and named sequences from Unicode charnames namespace -> \N{...} neglects formal aliases and named sequences from	Unicode charnames namespace

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sat Oct  1 17:17:52 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 01 Oct 2011 15:17:52 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences
	from	Unicode charnames namespace
In-Reply-To: <29624.1317420430@chthon>
Message-ID: <4E872F1E.6050604@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> You may wish unicode.name() to return the alias in preference, however.

-1. .name() is documented (and users familiar with it expect it) as
returning the name of the character from the UCD.

It doesn't really matter much to me if it's non-sensical - it's just
a label. Notice that many characters have names like "CJK UNIFIED
IDEOGRAPH-4E20", which isn't very descriptive, either. What does matter
is that the name returned matches the same name in many other places
in the net, which (rightfully) all use the UCD name (they might provide
the alias as well if they are aware of aliases, but often don't).

> If you mean, is it ok to add just the aliases and not the named sequences to
> \N{}, it is certainly better than not doing so at all.  Plus that way you do
> *not* have to figure out what in the world to to do with [^a-c\N{sequence}],

Python doesn't use regexes in the language parser, but does do \N
escapes in the parser. So there is no way this transformation could
possibly be made - except when you are talking about escapes in regexes,
and not escapes in Unicode strings.

> Perl does not provide the old 1.0 names at all.  We don't have a Unicode
> 1.0 legacy to support, which makes this cleaner.  However, we do provide
> for the names of the C0 and C1 Control Codes, because apart from Unicode
> 1.0, they don't condescend to name the ASCII or Latin1 control codes.  

If there would be a reasonably official source for these names, and one
that guarantees that there is no collision with UCD names, I could
accept doing so for Python as well.

> We also provide for certain well known aliases from the Names file:
> anything that says "* commonly abbreviated as ...", so things like LRO
> and ZWJ and such.

-1. Readability counts, writability not so much (I know this is
different for Perl :-). If there is too much aliasing, people will
wonder what these codes actually mean.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sat Oct  1 19:26:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Oct 2011 17:26:03 +0000
Subject: [issue13034] Python does not read Alternative Subject Names from SSL
	certificates larger than 1024 bits
In-Reply-To: <1316778793.21.0.229691764484.issue13034@psf.upfronthosting.co.za>
Message-ID: <E1RA3K6-0005rd-Im@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 65e7f40fefd4 by Antoine Pitrou in branch '3.2':
Issue #13034: When decoding some SSL certificates, the subjectAltName extension could be unreported.
http://hg.python.org/cpython/rev/65e7f40fefd4

New changeset 90a06fbb1f85 by Antoine Pitrou in branch 'default':
Issue #13034: When decoding some SSL certificates, the subjectAltName extension could be unreported.
http://hg.python.org/cpython/rev/90a06fbb1f85

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13034>
_______________________________________

From report at bugs.python.org  Sat Oct  1 19:34:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Oct 2011 17:34:39 +0000
Subject: [issue13034] Python does not read Alternative Subject Names from SSL
	certificates larger than 1024 bits
In-Reply-To: <1316778793.21.0.229691764484.issue13034@psf.upfronthosting.co.za>
Message-ID: <E1RA3SQ-0006PH-C8@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8e6694387c98 by Antoine Pitrou in branch '2.7':
Issue #13034: When decoding some SSL certificates, the subjectAltName extension could be unreported.
http://hg.python.org/cpython/rev/8e6694387c98

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13034>
_______________________________________

From report at bugs.python.org  Sat Oct  1 19:35:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 Oct 2011 17:35:20 +0000
Subject: [issue13034] Python does not read Alternative Subject Names from SSL
	certificates larger than 1024 bits
In-Reply-To: <1316778793.21.0.229691764484.issue13034@psf.upfronthosting.co.za>
Message-ID: <1317490520.91.0.406089580227.issue13034@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This should be fixed now.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13034>
_______________________________________

From report at bugs.python.org  Sat Oct  1 19:35:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 Oct 2011 17:35:45 +0000
Subject: [issue13034] Python does not read Alternative Subject Names from some
	SSL certificates
In-Reply-To: <1316778793.21.0.229691764484.issue13034@psf.upfronthosting.co.za>
Message-ID: <1317490545.78.0.75203820451.issue13034@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(fixing the title)

----------
title: Python does not read Alternative Subject Names from SSL certificates larger than 1024 bits -> Python does not read Alternative Subject Names from some SSL certificates

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13034>
_______________________________________

From report at bugs.python.org  Sat Oct  1 19:47:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 01 Oct 2011 17:47:03 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317491223.79.0.275640510789.issue13070@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Shouldn't the test use "self.BufferedRWPair" instead of
> "io.BufferedRWPair"?

Yes.

> Also, is it ok to just return NULL or should the error state also be
> set?

Well, I'm not sure, that why I made you and Amaury noisy :-)
AFAICT, this is the only case where _check_closed can encounter a NULL self->writer. And this specific situation is not an error (nothing prevents the rwpair from being garbaged collected before the textio) ,and _PyIOBase_finalize() explicitely clears any error returned:
"""
    /* If `closed` doesn't exist or can't be evaluated as bool, then the
       object is probably in an unusable state, so ignore. */
    res = PyObject_GetAttr(self, _PyIO_str_closed);
    if (res == NULL)
        PyErr_Clear();
    else {
        closed = PyObject_IsTrue(res);
        Py_DECREF(res);
        if (closed == -1)
            PyErr_Clear();
    }
"""

Furthermore, I'm not sure about what kind of error would make sense here.

----------
Added file: http://bugs.python.org/file23285/buffered_closed_gc-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Sat Oct  1 19:47:18 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 01 Oct 2011 17:47:18 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317491238.2.0.838011927947.issue13070@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file23279/buffered_closed_gc-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Sat Oct  1 20:21:03 2011
From: report at bugs.python.org (Dan Kenigsberg)
Date: Sat, 01 Oct 2011 18:21:03 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1317493263.8.0.90067564446.issue4147@psf.upfronthosting.co.za>


Dan Kenigsberg <danken at redhat.com> added the comment:

Here's another take on fixing this bug, with an accompanying unit test. Personally, I'm monkey-patching xml.dom.minidom in order to avoid it, but please consider fixing it properly upstream.

----------
Added file: http://bugs.python.org/file23286/minidom-Text-toprettyxml.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Sat Oct  1 21:18:11 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 01 Oct 2011 19:18:11 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1317496691.08.0.0585901595676.issue6632@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Sat Oct  1 22:49:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Oct 2011 20:49:15 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <E1RA6Uj-0003V6-U6@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 086ca132e161 by R David Murray in branch '3.2':
#4147: minidom's toprettyxml no longer adds whitespace to text nodes.
http://hg.python.org/cpython/rev/086ca132e161

New changeset fa0b1e50270f by R David Murray in branch 'default':
merge #4147: minidom's toprettyxml no longer adds whitespace to text nodes.
http://hg.python.org/cpython/rev/fa0b1e50270f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Sat Oct  1 22:49:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Oct 2011 20:49:38 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <E1RA6V7-0003WR-JI@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 406c5b69cb1b by R David Murray in branch '2.7':
#4147: minidom's toprettyxml no longer adds whitespace to text nodes.
http://hg.python.org/cpython/rev/406c5b69cb1b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Sat Oct  1 22:53:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Oct 2011 20:53:01 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1317502381.15.0.708404454341.issue4147@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This looks correct to me, and it tested out fine on the test suite (and the provided test failed without the provided fix), so I committed it.

I have a small concern that the change in output might be a bit radical for a bug fix release, but it does seem to me that this is clearly a bug.  If people think it shouldn't go in the bug fix releases let me know and I'll back it out.

Thanks for the patch, Dan.

----------
nosy: +r.david.murray
stage: test needed -> committed/rejected
status: open -> closed
type: feature request -> behavior
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Sat Oct  1 22:59:19 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 01 Oct 2011 20:59:19 +0000
Subject: [issue10156] Initialization of globals in unicodeobject.c
In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>
Message-ID: <1317502759.72.0.0483075027418.issue10156@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The PEP-393 changes apparently fix this leak; at least I can't reproduce
it in default any longer (but still in 3.2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Sun Oct  2 00:08:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Oct 2011 22:08:42 +0000
Subject: [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1317506922.75.0.289810147628.issue13081@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I suppose that the application uses extensions written in C and one on these extensions is buggy. Can you write a script to reproduce the bug without the application? If not, we cannot help you :-(

You may try the faulthandler to get more information:
https://github.com/haypo/faulthandler/wiki

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13081>
_______________________________________

From report at bugs.python.org  Sun Oct  2 00:32:49 2011
From: report at bugs.python.org (John O'Connor)
Date: Sat, 01 Oct 2011 22:32:49 +0000
Subject: [issue13087] C BufferedReader seek() is inconsistent with
	UnsupportedOperation for unseekable streams
Message-ID: <1317508369.4.0.585699022019.issue13087@psf.upfronthosting.co.za>


New submission from John O'Connor <tehjcon at gmail.com>:

The C implementation of BufferedReader.seek() does not throw an UnsupportedOperation exception when its underlying stream is unseekable IF the current buffer can accommodate the seek in memory. It probably saves a few cycles for the seekable streams but, I think currently, it is inconsistent with the _pyio implementation and documentation.

----------
components: IO
files: unseekable.patch
keywords: patch
messages: 144751
nosy: haypo, jcon, pitrou
priority: normal
severity: normal
status: open
title: C BufferedReader seek() is inconsistent with UnsupportedOperation for unseekable streams
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23287/unseekable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13087>
_______________________________________

From report at bugs.python.org  Sun Oct  2 00:41:33 2011
From: report at bugs.python.org (John O'Connor)
Date: Sat, 01 Oct 2011 22:41:33 +0000
Subject: [issue12807] Optimization/refactoring for {bytearray, bytes,
	unicode}.strip()
In-Reply-To: <1313981941.49.0.99491814096.issue12807@psf.upfronthosting.co.za>
Message-ID: <1317508893.41.0.642593920744.issue12807@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

The patch no longer applies cleanly. Is there enough interest in this to justify rebasing?

----------
title: Optimizations for {bytearray,bytes,unicode}.strip() -> Optimization/refactoring for {bytearray,bytes,unicode}.strip()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12807>
_______________________________________

From report at bugs.python.org  Sun Oct  2 01:14:49 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 01 Oct 2011 23:14:49 +0000
Subject: [issue13082] Can't open new window in python
In-Reply-To: <1317428678.05.0.613085535741.issue13082@psf.upfronthosting.co.za>
Message-ID: <1317510889.76.0.760958056683.issue13082@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

>From the symptoms you describe, you are almost certainly trying to use a version of IDLE with the Cocoa Tcl/Tk 8.5 supplied by Apple in Mac OS X 10.6.  That version of Tcl/Tk is known to be buggy.  If you installed a 64-bit/32-bin version of Python 3.2 using an installer downloaded from python.org, the download pages and the installer splash screen and IDLE itself all warn you to read the up-to-date information here:

    http://www.python.org/download/mac/tcltk/

If, after installing a current version of ActiveTcl 8.5 or a 32-bit version of Python, the problem persists, please re-open with appropriate information about versions and how to reproduce.

----------
assignee: ronaldoussoren -> ned.deily
nosy: +ned.deily
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13082>
_______________________________________

From report at bugs.python.org  Sun Oct  2 01:32:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Oct 2011 23:32:57 +0000
Subject: [issue13088] Add Py_hexdigits constant: use one unique constant to
	format a digit to hexadecimal
Message-ID: <1317511977.11.0.738521421258.issue13088@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

CPython source code contains a lot of duplicate "0123456789abcdef" constants, declared as static variables. Attached patch uses one unique variable. Use also Py_hexdigit instead of ((c>9) ? c+'a'-10 : c + '0') in binascii, _hashopenssl, md5, sha1, sha256 and sha512 modules.

----------
files: hexdigits.patch
keywords: patch
messages: 144754
nosy: haypo
priority: normal
severity: normal
status: open
title: Add Py_hexdigits constant: use one unique constant to format a digit to hexadecimal
versions: Python 3.3
Added file: http://bugs.python.org/file23288/hexdigits.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13088>
_______________________________________

From report at bugs.python.org  Sun Oct  2 03:14:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Oct 2011 01:14:16 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1317518056.81.0.194361185901.issue4147@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The patch seems wrong to me:
>>> d = minidom.parseString('<foo><bar>AAA</bar>BBB<bar>CCC</bar></foo>')
>>> print(d.toprettyxml())
<?xml version="1.0" ?>
<foo>
        <bar>AAA        </bar>
BBB     <bar>CCC        </bar>
</foo>

Even if the newlines are gone, the indentation before the closing tag is preserved.  Also a newline is added before the text node BBB.

It would be good to check what the XML standard says about the whitespace.  I'm pretty sure HTML has well defined rules about it, but I don't know if that's the same for XML.

FWIW the link in msg102247 contains a different fix (not sure if it's any better), and also a link to an article about XML and whitespace: http://www.oracle.com/technetwork/articles/wang-whitespace-092897.html (the link seems broken in the page).

----------
nosy: +ezio.melotti -BreamoreBoy
stage: committed/rejected -> test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Sun Oct  2 05:29:04 2011
From: report at bugs.python.org (Mike Hoy)
Date: Sun, 02 Oct 2011 03:29:04 +0000
Subject: [issue13075] PEP-0001 contains dead links
In-Reply-To: <1317374485.54.0.239839552518.issue13075@psf.upfronthosting.co.za>
Message-ID: <1317526144.22.0.878821995463.issue13075@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

Added links under Resources to the new Dev Guide. Added a link to the Guide itself and a link to the faq.

----------
keywords: +patch
Added file: http://bugs.python.org/file23289/pep-0001-broken-links.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13075>
_______________________________________

From report at bugs.python.org  Sun Oct  2 07:33:41 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 02 Oct 2011 05:33:41 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <4E872F1E.6050604@v.loewis.de>
Message-ID: <6829.1317533598@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

>> Perl does not provide the old 1.0 names at all.  We don't have a Unicode
>> 1.0 legacy to support, which makes this cleaner.  However, we do provide
>> for the names of the C0 and C1 Control Codes, because apart from Unicode
>> 1.0, they don't condescend to name the ASCII or Latin1 control codes. =20

> If there would be a reasonably official source for these names, and one
> that guarantees that there is no collision with UCD names, I could
> accept doing so for Python as well.

The C0 and C1 control code names don't change.  There is/was one stability
issue where they screwed up, because they ended up having a UAX (required)
and a UTS (not required) fighting because of the dumb stuff they did with
the Emoji names. They neglected to prefix them with "Emoji ..." or some
such, the way things like "GREEK ... LETTER ..." or "MATHEMATICAL ..." or
"MUSICAL ..." did.  The problem is they stole BELL without calling it EMOJI
BELL.  This is C0 name for Control-G.  Dimwits.

The problem with official names is that they have things in them that you
are not expected in names.  Do you really and truly mean to tell me you
think it is somehow **good** that people are forced to write

    \N{LINE FEED (LF)}

Rather than the more obvious pair of 

    \N{LINE FEED}
    \N{LF}

??

If so, then I don't understand that.  Nobody in their right 
mind prefers "\N{LINE FEED (LF)}" over "\N{LINE FEED}" -- do they?

    % perl -Mcharnames=:full -le 'printf "U+%04X\n", ord "\N{LINE FEED}"'
    U+000A
    % perl -Mcharnames=:full -le 'printf "U+%04X\n", ord "\N{LF}"'
    U+000A
    % perl -Mcharnames=:full -le 'printf "U+%04X\n", ord "\N{LINE FEED (LF)}"'
    U+000A

    % perl -Mcharnames=:full -le 'printf "U+%04X\n", ord "\N{NEXT LINE}"'
    U+0085
    % perl -Mcharnames=:full -le 'printf "U+%04X\n", ord "\N{NEL}"'
    U+0085
    % perl -Mcharnames=:full -le 'printf "U+%04X\n", ord "\N{NEXT LINE (NEL)}"'
    U+0085

>> We also provide for certain well known aliases from the Names file:
>> anything that says "* commonly abbreviated as ...", so things like LRO
>> and ZWJ and such.

> -1. Readability counts, writability not so much (I know this is
> different for Perl :-). 

I actually very strongly resent and rebuff that entire mindset in the most
extreme way possible.  Well-written Perl code is perfectly readable by
people who speak that langauge.  If you find Perl code that isn't readable,
it is by definition not well-written.

*PLEASE* don't start.  

Yes, I just got done driving 16 hours and am overtired, but it's 
something I've been fighting against all of professional career.
It's a "leyenda negra".

> If there is too much aliasing, people will
> wonder what these codes actually mean.

There are 15 "commonly abbreviated as" aliases in the Names.txt file.

    * commonly abbreviated as NBSP
    * commonly abbreviated as SHY
    * commonly abbreviated as CGJ
    * commonly abbreviated ZWSP
    * commonly abbreviated ZWNJ
    * commonly abbreviated ZWJ
    * commonly abbreviated LRM
    * commonly abbreviated RLM
    * commonly abbreviated LRE
    * commonly abbreviated RLE
    * commonly abbreviated PDF
    * commonly abbreviated LRO
    * commonly abbreviated RLO
    * commonly abbreviated NNBSP
    * commonly abbreviated WJ

All of the standards documents *talk* about things like LRO and ZWNJ.
I guess the standards aren't "readable" then, right? :)

>From the charnames manpage, which shows that we really don't just make
these up as we feel like (although we could; see below).  They're all from
this or that standard:

    ALIASES
       A few aliases have been defined for convenience: instead
       of having to use the official names

           LINE FEED (LF)
           FORM FEED (FF)
           CARRIAGE RETURN (CR)
           NEXT LINE (NEL)

       (yes, with parentheses), one can use

           LINE FEED
           FORM FEED
           CARRIAGE RETURN
           NEXT LINE
           LF
           FF
           CR
           NEL

       All the other standard abbreviations for the controls,
       such as "ACK" for "ACKNOWLEDGE" also can be used.

       One can also use

           BYTE ORDER MARK
           BOM

       and these abbreviations

           Abbreviation        Full Name

           CGJ                 COMBINING GRAPHEME JOINER
           FVS1                MONGOLIAN FREE VARIATION SELECTOR ONE
           FVS2                MONGOLIAN FREE VARIATION SELECTOR TWO
           FVS3                MONGOLIAN FREE VARIATION SELECTOR THREE
           LRE                 LEFT-TO-RIGHT EMBEDDING
           LRM                 LEFT-TO-RIGHT MARK
           LRO                 LEFT-TO-RIGHT OVERRIDE
           MMSP                MEDIUM MATHEMATICAL SPACE
           MVS                 MONGOLIAN VOWEL SEPARATOR
           NBSP                NO-BREAK SPACE
           NNBSP               NARROW NO-BREAK SPACE
           PDF                 POP DIRECTIONAL FORMATTING
           RLE                 RIGHT-TO-LEFT EMBEDDING
           RLM                 RIGHT-TO-LEFT MARK
           RLO                 RIGHT-TO-LEFT OVERRIDE
           SHY                 SOFT HYPHEN
           VS1                 VARIATION SELECTOR-1
           .
           .
           .
           VS256               VARIATION SELECTOR-256
           WJ                  WORD JOINER
           ZWJ                 ZERO WIDTH JOINER
           ZWNJ                ZERO WIDTH NON-JOINER
           ZWSP                ZERO WIDTH SPACE

       For backward compatibility one can use the old names for
       certain C0 and C1 controls

           old                         new

           FILE SEPARATOR              INFORMATION SEPARATOR FOUR
           GROUP SEPARATOR             INFORMATION SEPARATOR THREE
           HORIZONTAL TABULATION       CHARACTER TABULATION
           HORIZONTAL TABULATION SET   CHARACTER TABULATION SET
           HORIZONTAL TABULATION WITH JUSTIFICATION    CHARACTER TABULATION
                                                       WITH JUSTIFICATION
           PARTIAL LINE DOWN           PARTIAL LINE FORWARD
           PARTIAL LINE UP             PARTIAL LINE BACKWARD
           RECORD SEPARATOR            INFORMATION SEPARATOR TWO
           REVERSE INDEX               REVERSE LINE FEED
           UNIT SEPARATOR              INFORMATION SEPARATOR ONE
           VERTICAL TABULATION         LINE TABULATION
           VERTICAL TABULATION SET     LINE TABULATION SET

       but the old names in addition to giving the character will
       also give a warning about being deprecated.

       And finally, certain published variants are usable,
       including some for controls that have no Unicode names:

           name                                   character

           END OF PROTECTED AREA                  END OF GUARDED AREA, U+0097
           HIGH OCTET PRESET                      U+0081
           HOP                                    U+0081
           IND                                    U+0084
           INDEX                                  U+0084
           PAD                                    U+0080
           PADDING CHARACTER                      U+0080
           PRIVATE USE 1                          PRIVATE USE ONE, U+0091
           PRIVATE USE 2                          PRIVATE USE TWO, U+0092
           SGC                                    U+0099
           SINGLE GRAPHIC CHARACTER INTRODUCER    U+0099
           SINGLE-SHIFT 2                         SINGLE SHIFT TWO, U+008E
           SINGLE-SHIFT 3                         SINGLE SHIFT THREE, U+008F
           START OF PROTECTED AREA                START OF GUARDED AREA, U+0096

    perl v5.14.0                2011-05-07                          2

Those are the defaults.  They are overridable.  That's because we feel that
people should be able to name their character constants however they feel
makes sense for them.  If they get tired of typing 

    \N{LATIN SMALL LETTER U WITH DIAERESIS}

let alone

    \N{LATIN CAPITAL LETTER THORN WITH STROKE THROUGH DESCENDER}

then they can, because there is a mechanism for making aliases:

    use charnames ":full", ":alias" => {
	U_uml => "LATIN CAPITAL LETTER U WITH DIAERESIS",
	u_uml => "LATIN SMALL LETTER U WITH DIAERESIS",
    };

That way you can do 

    s/\N{U_uml}/UE/;
    s/\N{u_uml}/ue/;

This is probably not as persuasive as the private-use case described below.

It is important to remember that all charname bindings in Perl are attached
to a *lexically-scoped declaration.  It is completely constrained to
operate only within that lexical scope.  That's why the compiler replaces
things like

    use charnames ":full", ":alias" => {
	U_uml => "LATIN CAPITAL LETTER U WITH DIAERESIS",
	u_uml => "LATIN SMALL LETTER U WITH DIAERESIS",
    };

    my $find_u_uml = qr/\N{u_uml}/i;

    print "Seach pattern is: $find_u_uml\n";

Which dutifully prints out:

    Seach pattern is: (?^ui:\N{U+FC})

So charname bindings are never "hard to read" because the effect is
completely lexically constrained, and can never leak outside of the scope.

I realize (or at least, believe) that Python has no notion of nested
lexical scopes, and like many things, this sort of thing can therefore
never work there because of that.

The most persuasive use-case for user-defined names is for private-use
area code points.  These will never have an official name.  But it is 
just fine to use them.  Don't they deserve a better name, one that makes
sense within your own program that uses them?  Of course they do.

For example, Apple has a bunch of private-use glyphs they use all the time.
In the 8-bit MacRoman encoding, the byte 0xF0 represents the Apple corporate
logo/glyph thingie of an apple with a bite taken out of it.  (Microsoft
also has a bunch of these.)  If you upgrade MacRoman to Unicode, you will
find that that 0xF0 maps to code point U+F8FF using the regular converter.

Now what are you supposed to do in your program when you want a named character
there?  You certainly do not want to make users put an opaque magic number
as a Unicode escape.  That is always really lame, because the whole reason 
we have \N{...} escapes is so we don't have to put mysterious unreadable magic
numbers in our code!!

So all you do is 

    use charnames ":alias" => {
        "APPLE LOGO" => 0xF8FF,
    };

and now you can use \N{APPLE LOGO} anywhere within that lexical scope.  The
compiler will dutifully resolve it to U+F8FF, since all name lookups happen
at compile-time.  And it cannot leak out of the scope.

I assert that this facility makes your program more readable, and its
absence  makes your program less readable.

Private use characters are important in Asian texts, but they are also
important for other things.  For example, Unicode intends to get around
to allocating Tengwar up the the SMP.  However, lots of stupid old code
can't use full Unicode, being constrained to UCS-2 only.  So many Tengwar
fonts start at a different base, and put it in the private use area instead
or the SMP.  Here are two constants:

    use constant {
        TB_CONSCRIPT_UNICODE_REGISTRY    => 0x00_E000,  # private use
        TB_UNICODE_CONSORTIIUM           => 0x01_6080,  # where it will really go
    };

I have an entire Tengwar module that makes heavy use of named 
private-use characters.  All I do is this:

    use constant TENGWAR_BASE => TB_CONSCRIPT_UNICODE_REGISTRY;

    use charnames ":alias" => { 
      reverse (
        (TENGWAR_BASE + 0x00) => "TENGWAR LETTER TINCO",
        (TENGWAR_BASE + 0x01) => "TENGWAR LETTER PARMA",
        (TENGWAR_BASE + 0x02) => "TENGWAR LETTER CALMA",
        (TENGWAR_BASE + 0x03) => "TENGWAR LETTER QUESSE",
        (TENGWAR_BASE + 0x04) => "TENGWAR LETTER ANDO",
        ....
      )
    };

Now you can write \N{TENGWAR LETTER TINCO} etc.  See how slick that is?
Consider the alternative.  Magic numbers.  Worse, magic numbers with funny
calculations in them.  That is just so wrong that it completely justifies
letting people name things how they want to, so long as they don't make
other people do the same.  What people do in the privacy of their own
lexical scope is their own business.

It gets better.  Perl lets you define your character properties, too.
Therefore I can write things like \p{Is_Tengwar_Decimal} and such.
Right now I have these properties:

    In_Tengwar, Is_Tengwar
    In_Tengwar_Alphanumerics
    In_Tengwar_Consonants, In_Tengwar_Vowels, In_Tengwar_Alphabetics
    In_Tengwar_Numerals, Is_Tengwar_Decimal, Is_Tengwar_Duodecimal
    In_Tengwar_Punctuation
    In_Tengwar_Marks 

So I have code in my Tengwar module that does stuff like this, using
my own named characters (which again, are compile-time resolved and 
work only within this lexical scope):

     chr( $1 + ord("\N{TENGWAR DIGIT ZERO}") )

Not to mention this using my own properties:

    $TENGWAR_GRAPHEME_RX = qr/(?:(?=\p{In_Tengwar})\P{In_Tengwar_Marks}\p{In_Tengwar_Marks}*)|\p{In_Tengwar_Marks}/x;

Actually, I'm fibbing.  I *never* write regexes all on one line like
that: they are abhorrent to me.  The pattern really looks like this in
the code:

    $TENGWAR_GRAPHEME_RX = qr{
        (?:
            (?= \p{In_Tengwar} ) \P{In_Tengwar_Marks}   # Either one basechar...
            \p{In_Tengwar_Marks} *                      # ... plus 0 or more marks
        ) | 
            \p{In_Tengwar_Marks}                        # or else a naked unpaired mark.
    }x;

People who write patterns without whitespace for cognitive chunking (plus
comments for explanation) are wicked wicked wicked.  Frankly I'm surprised 
Python doesn't require it. :)/2

Anyway, do you see how much better that is than opaque unreadable magic
numbers?  Can you just imagine the sheer horror of writing that sort of
code without the ability to define your own named characters *and* your 
own character properties?  It's beautiful, simple, clean, and readable.
I'll even go so far as to call it intuitive.

No, I don't expect Python to do this sort of thing.  You don't have proper
scoping, so you can't ever do it cleanly the way Perl can.

I just wanted to give a concrete example where flexibility leads to a 
much more readable program than inflexibility ever can.  

--tom

    "We hates magic numberses.  We hates them forevers!"
        --Sm?agol the Hacker

----------
title: \N{...} neglects formal aliases and named sequences from	Unicode charnames namespace -> \N{...} neglects formal aliases and named sequences from Unicode charnames namespace

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sun Oct  2 08:46:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Oct 2011 06:46:26 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1317537986.58.0.797304932484.issue12753@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> The problem with official names is that they have things in them that 
> you are not expected in names.  Do you really and truly mean to tell 
> me you think it is somehow **good** that people are forced to write
>    \N{LINE FEED (LF)}
> Rather than the more obvious pair of 
>    \N{LINE FEED}
>    \N{LF}
> ??

Actually Python doesn't seem to support \N{LINE FEED (LF)}, most likely because that's a Unicode 1 name, and nowadays these codepoints are simply marked as '<control>'.

> If so, then I don't understand that.  Nobody in their right 
> mind prefers "\N{LINE FEED (LF)}" over "\N{LINE FEED}" -- do they?

They probably don't, but they just write \n anyway.  I don't think we need to support any of these aliases, especially if they are not defined in the Unicode standard.

I'm also not sure humans use \N{...}: you don't want to write
  'R\N{LATIN SMALL LETTER E WITH ACUTE}sum\N{LATIN SMALL LETTER E WITH ACUTE}'
and you would need to look up the exact name somewhere anyway before using it (unless you know them by heart).
If 'R\xe9sum\xe9' or 'R\u00e9sum\u00e9' are too obscure and/or magic, you can always print() them and get 'R?sum?' (or just write 'R?sum?' directly in the source).

> All of the standards documents *talk* about things like LRO and ZWNJ.
> I guess the standards aren't "readable" then, right? :)

Right, I had to read down till the table with the meanings before figuring out what they were (and I already forgot it).

> The most persuasive use-case for user-defined names is for private-use
> area code points.  These will never have an official name.  But it is
> just fine to use them.  Don't they deserve a better name, one that 
> makes sense within your own program that uses them?  Of course they do.
>
> For example, Apple has a bunch of private-use glyphs they use all the time.
> In the 8-bit MacRoman encoding, the byte 0xF0 represents the Apple corporate
> logo/glyph thingie of an apple with a bite taken out of it.  (Microsoft
> also has a bunch of these.)  If you upgrade MacRoman to Unicode, you will
> find that that 0xF0 maps to code point U+F8FF using the regular converter.
>
> Now what are you supposed to do in your program when you want a named character
> there?  You certainly do not want to make users put an opaque magic number
> as a Unicode escape.  That is always really lame, because the whole reason 
> we have \N{...} escapes is so we don't have to put mysterious unreadable magic
> numbers in our code!!
>
> So all you do is 
>    use charnames ":alias" => {
>        "APPLE LOGO" => 0xF8FF,
>    };
>
> and now you can use \N{APPLE LOGO} anywhere within that lexical scope.  The
> compiler will dutifully resolve it to U+F8FF, since all name lookups happen
> at compile-time.  And it cannot leak out of the scope.

This is actually a good use case for \N{..}.

One way to solve that problem is doing:
    apples = {
        'APPLE': '\uF8FF',
        'GREEN APPLE': '\U0001F34F',
        'RED APPLE': '\U0001F34E',
    }
and then:
   print('I like {GREEN APPLE} and {RED APPLE}, but not {APPLE}.'.format(**apples))

This requires the format call for each string and it's a workaround, but at least is readable (I hope you don't have too many apples in your strings).

I guess we could add some way to define a global list of names, and that would probably be enough for most applications.  Making it per-module would be more complicated and maybe not too elegant.

> People who write patterns without whitespace for cognitive chunking (plus
> comments for explanation) are wicked wicked wicked.  Frankly I'm surprised 
> Python doesn't require it. :)/2

I actually find those *less* readable.  If there's something fancy in the regex, a comment *before* it is welcomed, but having to read a regex divided on several lines and remove meaningless whitespace and redundant comments just makes the parsing more difficult for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sun Oct  2 09:32:21 2011
From: report at bugs.python.org (Ben Hayden)
Date: Sun, 02 Oct 2011 07:32:21 +0000
Subject: [issue13073] message_body argument of HTTPConnection.endheaders is
	undocumented
In-Reply-To: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>
Message-ID: <1317540741.36.0.628580760096.issue13073@psf.upfronthosting.co.za>


Ben Hayden <hayden767 at gmail.com> added the comment:

I added in docs for the method from the actual method docstring from the http.client module.

----------
keywords: +patch
nosy: +beardedp
Added file: http://bugs.python.org/file23290/issue13073.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13073>
_______________________________________

From report at bugs.python.org  Sun Oct  2 09:34:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Oct 2011 07:34:21 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1317540861.82.0.203778046548.issue12753@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached a new patch with more tests and doc.

----------
Added file: http://bugs.python.org/file23291/issue12753-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sun Oct  2 10:18:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Oct 2011 08:18:23 +0000
Subject: [issue13076] Bad links to 'time' in datetime documentation
In-Reply-To: <1317390308.93.0.874341309843.issue13076@psf.upfronthosting.co.za>
Message-ID: <1317543503.59.0.981181094898.issue13076@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The broken links seem to be only in the "time objects" section, and only in the body of attribute/method directives.

The attached patch fixes the issue by using :class:`~datetime.time` explicitly where the links are broken.

Georg, is this a bug in Sphinx?

----------
assignee: docs at python -> ezio.melotti
keywords: +patch
nosy: +ezio.melotti, georg.brandl
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23292/issue13076.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13076>
_______________________________________

From report at bugs.python.org  Sun Oct  2 10:23:18 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Oct 2011 08:23:18 +0000
Subject: [issue13076] Bad links to 'time' in datetime documentation
In-Reply-To: <1317390308.93.0.874341309843.issue13076@psf.upfronthosting.co.za>
Message-ID: <1317543798.27.0.509906321551.issue13076@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No, it's not, it's how Sphinx works. Use :class:`.time` to refer to the datetime class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13076>
_______________________________________

From report at bugs.python.org  Sun Oct  2 10:50:16 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 02 Oct 2011 08:50:16 +0000
Subject: [issue13089] parsetok.c: memory leak
Message-ID: <1317545416.55.0.717898890924.issue13089@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Seen in test_mailbox:

==31621== 6 bytes in 2 blocks are definitely lost in loss record 27 of 10,370
==31621==    at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==31621==    by 0x5271A5: parsetok (parsetok.c:179)
==31621==    by 0x526E8A: PyParser_ParseStringFlagsFilenameEx (parsetok.c:67)
==31621==    by 0x4BC385: PyParser_ASTFromString (pythonrun.c:1898)
==31621==    by 0x4BC1E1: Py_CompileStringExFlags (pythonrun.c:1842)
==31621==    by 0x478AB8: builtin_compile (bltinmodule.c:626)
==31621==    by 0x5759F3: PyCFunction_Call (methodobject.c:84)
==31621==    by 0x48F2CF: ext_do_call (ceval.c:4292)
==31621==    by 0x489992: PyEval_EvalFrameEx (ceval.c:2646)
==31621==    by 0x48E67B: fast_function (ceval.c:4068)
==31621==    by 0x48E3C7: call_function (ceval.c:4001)
==31621==    by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605)

----------
components: Interpreter Core
messages: 144763
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: parsetok.c: memory leak
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13089>
_______________________________________

From report at bugs.python.org  Sun Oct  2 11:10:29 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 02 Oct 2011 09:10:29 +0000
Subject: [issue13090] posix_read: memory leak
Message-ID: <1317546629.79.0.861373881282.issue13090@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Seen in test_multiprocessing:

==31662== 37 bytes in 1 blocks are definitely lost in loss record 629 of 10,548
==31662==    at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==31662==    by 0x53BBE9: PyBytes_FromStringAndSize (bytesobject.c:98)
==31662==    by 0x4E2363: posix_read (posixmodule.c:6980)
==31662==    by 0x5759D8: PyCFunction_Call (methodobject.c:81)
==31662==    by 0x48E294: call_function (ceval.c:3980)
==31662==    by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605)
==31662==    by 0x48C54F: PyEval_EvalCodeEx (ceval.c:3355)
==31662==    by 0x48E786: fast_function (ceval.c:4078)
==31662==    by 0x48E3C7: call_function (ceval.c:4001)
==31662==    by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605)
==31662==    by 0x48C54F: PyEval_EvalCodeEx (ceval.c:3355)
==31662==    by 0x48E786: fast_function (ceval.c:4078)

----------
components: Extension Modules
messages: 144764
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: posix_read: memory leak
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13090>
_______________________________________

From report at bugs.python.org  Sun Oct  2 11:11:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 02 Oct 2011 09:11:58 +0000
Subject: [issue13091] ctypes: memory leak
Message-ID: <1317546718.25.0.742978918789.issue13091@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Seen in test_multiprocessing:

==31662== 44 bytes in 1 blocks are definitely lost in loss record 687 of 10,548
==31662==    at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==31662==    by 0x41CC27: PyMem_Malloc (object.c:1699)
==31662==    by 0x127D9F51: resize (callproc.c:1664)
==31662==    by 0x5759D8: PyCFunction_Call (methodobject.c:81)
==31662==    by 0x48E294: call_function (ceval.c:3980)
==31662==    by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605)
==31662==    by 0x48E67B: fast_function (ceval.c:4068)
==31662==    by 0x48E3C7: call_function (ceval.c:4001)
==31662==    by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605)
==31662==    by 0x48C54F: PyEval_EvalCodeEx (ceval.c:3355)
==31662==    by 0x48E786: fast_function (ceval.c:4078)
==31662==    by 0x48E3C7: call_function (ceval.c:4001)

----------
components: Extension Modules
messages: 144765
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: ctypes: memory leak
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13091>
_______________________________________

From report at bugs.python.org  Sun Oct  2 11:47:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Oct 2011 09:47:24 +0000
Subject: [issue13076] Bad links to 'time' in datetime documentation
In-Reply-To: <1317390308.93.0.874341309843.issue13076@psf.upfronthosting.co.za>
Message-ID: <E1RAIdn-0008TM-Dn@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 854e31d80151 by Ezio Melotti in branch '2.7':
#13076: fix links to datetime.time.
http://hg.python.org/cpython/rev/854e31d80151

New changeset 95689ed69097 by Ezio Melotti in branch '3.2':
#13076: fix links to datetime.time and datetime.datetime.
http://hg.python.org/cpython/rev/95689ed69097

New changeset 175cd2a51ea9 by Ezio Melotti in branch 'default':
#13076: merge with 3.2.
http://hg.python.org/cpython/rev/175cd2a51ea9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13076>
_______________________________________

From report at bugs.python.org  Sun Oct  2 11:49:05 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 02 Oct 2011 09:49:05 +0000
Subject: [issue13092] pep-393: memory leaks #2
Message-ID: <1317548945.05.0.236513746453.issue13092@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I found a couple of additional leaks related to the PEP-393 changes.

----------
components: Interpreter Core
files: pep-393-leaks-2.diff
keywords: patch
messages: 144767
nosy: loewis, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: pep-393: memory leaks #2
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file23293/pep-393-leaks-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13092>
_______________________________________

From report at bugs.python.org  Sun Oct  2 11:49:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Oct 2011 09:49:51 +0000
Subject: [issue13076] Bad links to 'time' in datetime documentation
In-Reply-To: <1317390308.93.0.874341309843.issue13076@psf.upfronthosting.co.za>
Message-ID: <1317548991.65.0.778030714562.issue13076@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This should be fixed now, thanks for the report.
FTR with Sphinx 1.0 all the links to :class:`time` and also :class:`datetime` needed to be fixed because they were pointing to the modules, with 0.6 only the :class:`time` in the body of attribute/method directives were broken.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13076>
_______________________________________

From report at bugs.python.org  Sun Oct  2 11:59:54 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 02 Oct 2011 09:59:54 +0000
Subject: [issue13084] test_signal failure
In-Reply-To: <1317462503.63.0.0518543153457.issue13084@psf.upfronthosting.co.za>
Message-ID: <1317549594.77.0.441464525613.issue13084@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Patch looks good to me (and it fixes the problem).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13084>
_______________________________________

From report at bugs.python.org  Sun Oct  2 12:51:43 2011
From: report at bugs.python.org (Lance Hepler)
Date: Sun, 02 Oct 2011 10:51:43 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317552703.0.0.59446883722.issue7689@psf.upfronthosting.co.za>


Changes by Lance Hepler <nlhepler at gmail.com>:


----------
nosy: +nlhepler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Sun Oct  2 14:03:19 2011
From: report at bugs.python.org (Dan Kenigsberg)
Date: Sun, 02 Oct 2011 12:03:19 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1317556999.25.0.183199780575.issue4147@psf.upfronthosting.co.za>


Dan Kenigsberg <danken at redhat.com> added the comment:

Oh dear.

Thanks, Enzio, for pointing out that former patch is wrong. It is also quite naive, since the whole NATURE of toprettyprint() is to add whitespace to Text nodes. Tomas Lee's http://bugs.python.org/file11832/minidom-toprettyxml-01.patch made an effort to touch only "simple" Text nodes, that are confined within a single <elem></elem>.

I did not expect http://bugs.python.org/file23286/minidom-Text-toprettyxml.patch to get in so quickly, after the former one spent several years on queue. However now is time to fix it, possible by my second patch.

----------
Added file: http://bugs.python.org/file23294/minidom-Text-toprettyxml-02.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Sun Oct  2 14:58:00 2011
From: report at bugs.python.org (Dan Kenigsberg)
Date: Sun, 02 Oct 2011 12:58:00 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1317560280.44.0.350953952281.issue4147@psf.upfronthosting.co.za>


Dan Kenigsberg <danken at redhat.com> added the comment:

btw, http://www.w3.org/TR/xml/#sec-white-space is a bit vague on how should a parser deal with whitespace, and seems to allow non-preservation of text nodes. Preserving "simple" text nodes is allowed, too, and is more polite to applications reading the prettyxml.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Sun Oct  2 15:07:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 02 Oct 2011 13:07:53 +0000
Subject: [issue12804] make test should not enable the urlfetch resource
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <1317560873.33.0.874228604028.issue12804@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t have a flaky connection, I have none at all; until this change I could always run just use ?make test? for all Python versions.  OTOH, I agree with your point that testing networking facilities in the standard test suite makes sense, as most people probably have network access.  If it is easy to detect network availability programmatically, we could just use the skip system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Sun Oct  2 16:14:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 02 Oct 2011 14:14:32 +0000
Subject: [issue3902] Packages containing only extension modules have to
	contain __init__.py
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1317564872.31.0.584948185524.issue3902@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We?re working on a patch on the core-mentorship list.

----------
components: +Distutils
nosy: +alexis
stage: needs patch -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Sun Oct  2 17:11:20 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 02 Oct 2011 15:11:20 +0000
Subject: [issue13089] parsetok.c: memory leak
In-Reply-To: <1317545416.55.0.717898890924.issue13089@psf.upfronthosting.co.za>
Message-ID: <1317568280.25.0.194906812849.issue13089@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13089>
_______________________________________

From report at bugs.python.org  Sun Oct  2 17:12:12 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 02 Oct 2011 15:12:12 +0000
Subject: [issue13091] ctypes: memory leak
In-Reply-To: <1317546718.25.0.742978918789.issue13091@psf.upfronthosting.co.za>
Message-ID: <1317568332.1.0.586734618512.issue13091@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
components: +ctypes
nosy: +amaury.forgeotdarc, belopolsky, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13091>
_______________________________________

From report at bugs.python.org  Sun Oct  2 17:39:15 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 02 Oct 2011 15:39:15 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
Message-ID: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I can't see what this code is supposed to accomplish (see patch):

  while (collend < end) {
      if ((0 < *collend && *collend < 256) ||
          !Py_UNICODE_ISSPACE(*collend) ||
          Py_UNICODE_TODECIMAL(*collend))
          break;
  }


Since 'collend' and 'end' don't change in the loop, it would be
infinite if the 'if' condition evaluated to false. But the 'if'
condition is always true.

----------
components: Interpreter Core
files: encode_decimal_redundant_code.diff
keywords: needs review, patch
messages: 144774
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Redundant code in PyUnicode_EncodeDecimal()
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23295/encode_decimal_redundant_code.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Sun Oct  2 18:07:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Oct 2011 16:07:55 +0000
Subject: [issue13090] posix_read: memory leak
In-Reply-To: <1317546629.79.0.861373881282.issue13090@psf.upfronthosting.co.za>
Message-ID: <1317571675.31.0.431159272919.issue13090@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13090>
_______________________________________

From report at bugs.python.org  Sun Oct  2 18:08:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Oct 2011 16:08:19 +0000
Subject: [issue13092] pep-393: memory leaks #2
In-Reply-To: <1317548945.05.0.236513746453.issue13092@psf.upfronthosting.co.za>
Message-ID: <1317571699.48.0.778042837917.issue13092@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13092>
_______________________________________

From report at bugs.python.org  Sun Oct  2 18:33:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Oct 2011 16:33:36 +0000
Subject: [issue13084] test_signal failure
In-Reply-To: <1317462503.63.0.0518543153457.issue13084@psf.upfronthosting.co.za>
Message-ID: <E1RAOyt-00052x-Et@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e4f4272479d0 by Charles-Fran?ois Natali in branch 'default':
Issue #13084: Fix a test_signal failure: the delivery order is only defined for
http://hg.python.org/cpython/rev/e4f4272479d0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13084>
_______________________________________

From report at bugs.python.org  Sun Oct  2 18:43:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 02 Oct 2011 16:43:10 +0000
Subject: [issue13001] test_socket.testRecvmsgTrunc failure on FreeBSD 7.2
	buildbot
In-Reply-To: <1316340627.52.0.056452746704.issue13001@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2Cv_TUxnZjcBMH_b7=Hcbze8aim34t0XdZtJqrAhPGcw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> @requires_freebsd_version should be factorized with
> @requires_linux_version.

Patches attached.

> Can we workaround FreeBSD (< 8) bug in C/Python?

Not really.

> Or should we remove the function on FreeBSD < 8?

There's really no reason to do that (and it's really a minor bug).

----------
Added file: http://bugs.python.org/file23296/freebsd_msgtrunc-1.diff
Added file: http://bugs.python.org/file23297/requires_unix_version.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13001>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py
--- a/Lib/test/test_socket.py
+++ b/Lib/test/test_socket.py
@@ -1659,6 +1659,9 @@
     def _testRecvmsgShorter(self):
         self.sendToServer(MSG)
 
+    # FreeBSD < 8 doesn't always set the MSG_TRUNC flag when a truncated
+    # datagram is received (issue #13001).
+    @support.requires_freebsd_version(8)
     def testRecvmsgTrunc(self):
         # Receive part of message, check for truncation indicators.
         msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
@@ -1668,6 +1671,7 @@
         self.assertEqual(ancdata, [])
         self.checkFlags(flags, eor=False)
 
+    @support.requires_freebsd_version(8)
     def _testRecvmsgTrunc(self):
         self.sendToServer(MSG)
 
-------------- next part --------------
diff --git a/Lib/test/support.py b/Lib/test/support.py
--- a/Lib/test/support.py
+++ b/Lib/test/support.py
@@ -44,8 +44,8 @@
     "Error", "TestFailed", "ResourceDenied", "import_module",
     "verbose", "use_resources", "max_memuse", "record_original_stdout",
     "get_original_stdout", "unload", "unlink", "rmtree", "forget",
-    "is_resource_enabled", "requires", "requires_linux_version",
-    "requires_mac_ver", "find_unused_port", "bind_port",
+    "is_resource_enabled", "requires", "requires_freebsd_version",
+    "requires_linux_version", "requires_mac_ver", "find_unused_port", "bind_port",
     "IPV6_ENABLED", "is_jython", "TESTFN", "HOST", "SAVEDCWD", "temp_cwd",
     "findfile", "create_empty_file", "sortdict", "check_syntax_error", "open_urlresource",
     "check_warnings", "CleanImport", "EnvironmentVarGuard", "TransientResource",
@@ -312,17 +312,17 @@
             msg = "Use of the %r resource not enabled" % resource
         raise ResourceDenied(msg)
 
-def requires_linux_version(*min_version):
-    """Decorator raising SkipTest if the OS is Linux and the kernel version is
-    less than min_version.
+def _requires_unix_version(sysname, min_version):
+    """Decorator raising SkipTest if the OS is `sysname` and the version is less
+    than `min_version`.
 
-    For example, @requires_linux_version(2, 6, 35) raises SkipTest if the Linux
-    kernel version is less than 2.6.35.
+    For example, @_requires_unix_version('FreeBSD', (7, 2)) raises SkipTest if
+    the FreeBSD version is less than 7.2.
     """
     def decorator(func):
         @functools.wraps(func)
         def wrapper(*args, **kw):
-            if sys.platform == 'linux':
+            if platform.system() == sysname:
                 version_txt = platform.release().split('-', 1)[0]
                 try:
                     version = tuple(map(int, version_txt.split('.')))
@@ -332,13 +332,29 @@
                     if version < min_version:
                         min_version_txt = '.'.join(map(str, min_version))
                         raise unittest.SkipTest(
-                            "Linux kernel %s or higher required, not %s"
-                            % (min_version_txt, version_txt))
-            return func(*args, **kw)
-        wrapper.min_version = min_version
+                            "%s version %s or higher required, not %s"
+                            % (sysname, min_version_txt, version_txt))
         return wrapper
     return decorator
 
+def requires_freebsd_version(*min_version):
+    """Decorator raising SkipTest if the OS is FreeBSD and the FreeBSD version is
+    less than `min_version`.
+
+    For example, @requires_freebsd_version(7, 2) raises SkipTest if the FreeBSD
+    version is less than 7.2.
+    """
+    return _requires_unix_version('FreeBSD', min_version)
+
+def requires_linux_version(*min_version):
+    """Decorator raising SkipTest if the OS is Linux and the Linux version is
+    less than `min_version`.
+
+    For example, @requires_linux_version(2, 6, 32) raises SkipTest if the Linux
+    version is less than 2.6.32.
+    """
+    return _requires_unix_version('Linux', min_version)
+
 def requires_mac_ver(*min_version):
     """Decorator raising SkipTest if the OS is Mac OS X and the OS X
     version if less than min_version.

From report at bugs.python.org  Sun Oct  2 18:45:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 02 Oct 2011 16:45:33 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1316813717.26.0.696772580838.issue10141@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3smm=BJsob7Fx94R2O-e0WU3ZBDLphS7nKxDX0Bo1RRA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

So, Victor, what do you think of the last version?
This patch has been lingering for quite some time, and it's really a
cool feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Sun Oct  2 18:55:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 02 Oct 2011 16:55:14 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1317574514.57.0.743346754185.issue4147@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Heh, you happened to post your patch at a time when I wanted something to do as a break from something I didn't want to do...and I *thought* I understood the problem, after reading the various links.  But clearly I didn't.  We don't have someone who has stepped forward to be xml maintainer, so I just went ahead and committed it.

I should find time to look at your new patch some time today, or perhaps Ezio will have time.  (Clearly minidom doesn't have enough tests.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Sun Oct  2 18:58:12 2011
From: report at bugs.python.org (lesmana)
Date: Sun, 02 Oct 2011 16:58:12 +0000
Subject: [issue12458] Tracebacks should contain the first line of continuation
	lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1317574692.03.0.231370396881.issue12458@psf.upfronthosting.co.za>


Changes by lesmana <lesmana at gmx.de>:


----------
nosy: +lesmana

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12458>
_______________________________________

From report at bugs.python.org  Sun Oct  2 19:00:59 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 02 Oct 2011 17:00:59 +0000
Subject: [issue13084] test_signal failure
In-Reply-To: <1317462503.63.0.0518543153457.issue13084@psf.upfronthosting.co.za>
Message-ID: <1317574859.63.0.0629543325795.issue13084@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13084>
_______________________________________

From report at bugs.python.org  Sun Oct  2 20:41:12 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 02 Oct 2011 18:41:12 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1317537986.58.0.797304932484.issue12753@psf.upfronthosting.co.za>
Message-ID: <32145.1317580838@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Ezio Melotti <report at bugs.python.org> wrote
   on Sun, 02 Oct 2011 06:46:26 -0000: 

> Actually Python doesn't seem to support \N{LINE FEED (LF)}, most likely bec=
> ause that's a Unicode 1 name, and nowadays these codepoints are simply mark=
> ed as '<control>'.

Yes, but there are a lot of them, 65 of them in fact.  I do not care to 
see people being forced to use literal control characters or inscrutable
magic numbers.  It really bothers me that you have all these defined code 
points with properties and all that have no name.   People do use these.
Some of them a lot.  I don't mind \n and such -- and in fact, prefer them 
even -- but I feel I should not have scratch my head over character \033, \0177,
and brethren.  The C0 and C1 standards are not just inventions, so we use 
them.  Far better than one should write \N{ESCAPE} for \033 or \N{DELETE} 
for \0177, don't you think?  

>> If so, then I don't understand that.  Nobody in their right=20
>> mind prefers "\N{LINE FEED (LF)}" over "\N{LINE FEED}" -- do they?

> They probably don't, but they just write \n anyway.  I don't think we need =
> to support any of these aliases, especially if they are not defined in the =
> Unicode standard.

If you look at Names.txt, there are significant "aliases" there for 
the C0/C1 stuff.  My bottom line is that I don't like to be forced
to use magic numbers.  I prefer to name my abstactions.  It is more
readable and more maintainble that way.   

There are still "holes" of course.  Code point 128 has no name even in C1.
But something is better than nothing.  Plus at least in Perl we *can* give
things names if we want, per the APPLE LOGO example for U+F8FF.  So nothing
needs to remain nameless.  Why, you can even name your Kanji if you want, 
using whatever Romanization you prefer.  I think the private-use case
example is really motivating, but I have no idea how to do this for Python
because there is no lexical scope.  I suppose you could attach it to the
module, but that still doesn't really work because of how things get evaluated.
With a Perl compile-time use, we can change the compiler's ideas about
things, like adding function prototypes and even extending the base types:

    % perl -Mbigrat -le 'print 1/2 + 2/3 * 4/5'
    31/30

    % perl -Mbignum -le 'print 21->is_odd'
    1
    % perl -Mbignum -le 'print 18->is_odd'
    0

    % perl -Mbignum -le 'print substr(2**5000, -3)'
    376
    % perl -Mbignum -le 'print substr(2**5000-1, -3)'
    375

    % perl -Mbignum -le 'print length(2**5000)'
    1506
    % perl -Mbignum -le 'print length(10**5000)'
    5001

    % perl -Mbignum -le 'print ref 10**5000'
    Math::BigInt
    % perl -Mbigrat -le 'print ref 1/3'
    Math::BigRat

I recognize that redefining what sort of object the compiler treats some 
of its constants as is never going to happen in Python, but we actually
did manage that with charnames without having to subclass our strings:
the hook for \N{...} doesn't require object games like the ones above.

But it still has to happen at compile time, of course, so I don't know
what you could do in Python.  Is there any way to change how the compiler
behaves even vaguely along these lines?

The run-time looks of Python's unicodedata.lookup (like Perl's
charnames::viacode) and unicodedata.name (like Perl's charnames::viacode
on the ord) could be managed with a hook, but the compile-time lookups
of \N{...} I don't see any way around.  But I don't know anything about
Python's internals, so don't even know what is or is not possible.

I do note that if you could extend \N{...} the way we do with charname
aliases for private-use characters, the user could load something that 
did the C0 and C1 control if they wanted to.  I just don't know how to 
do that early enough that the Python compiler would see it.  Your import
happens at run-time or at compile-time?  This would be some sort of
compile-time binding of constants.

d=20
>> Python doesn't require it. :)/2

> I actually find those *less* readable.  If there's something fancy in the r=
> egex, a comment *before* it is welcomed, but having to read a regex divided=
> on several lines and remove meaningless whitespace and redundant comments =
> just makes the parsing more difficult for me.

Really?  White space makes things harder to read?  I thought Pythonistas
believed the opposite of that.  Whitespace is very useful for cognitive
chunking: you see how things logically group together.

Inomorewantaregexwithoutwhitespacethananyothercodeortext. :)

I do grant you that chatty comments may be a separate matter.

White space in patterns is also good when you have successive patterns
across multiple lines that have parts that are the same and parts that
are different, as in most of these, which is from a function to render
an English headline/book/movie/etc title into its proper casing:

    # put into lowercase if on our stop list, else titlecase
    s/  ( \pL [\pL']* )  /$stoplist{$1} ? lc($1) : ucfirst(lc($1))/xge;

    # capitalize a title's last word and its first word
    s/^ ( \pL [\pL']* )  /\u\L$1/x;  
    s/  ( \pL [\pL']* ) $/\u\L$1/x;  

    # treat parenthesized portion as a complete title
    s/ \( ( \pL [\pL']* )    /(\u\L$1/x;
    s/    ( \pL [\pL']* ) \) /\u\L$1)/x;

    # capitalize first word following colon or semi-colon
    s/ ( [:;] \s+ ) ( \pL [\pL']* ) /$1\u\L$2/x;

Now, that isn't good code for all *kinds* of reasons, but white space
is not one of them.  Perhaps what it is best at demonstrating is why
Python goes about this the right way and that Perl does not.  Oh drat,
I'm about to attach this to the wrong bug.  But it was the dumb code
above that made me think about the following.

By virtue of having a "titlecase each word's first letter and lowercase the
rest" function in Python, you can put the logic in just one place, and
therefore if a bug is found, you can fix all code all at one.

But because Perl has always made it easy to grab "words" (actually,
traditional programming language identifiers) and diddle their case, 
people write this all the time:

    s/(\w+)/\u\L$1/g;

all the time, and that has all kind of problems.  If you prefer the
functional approach, that is really

    s/(\w+)/ucfirst(lc($1))/ge;

but that is still wrong.

 1. Too much code duplication.  Yes, it's nice to see \pL[\pL']* 
    stand out on each line, but shouldn't that be in a variable, like

        $word = qr/\pL[\pL']*/;

 2. What is a "word"?  That code above is better than \w because it
    avoids numbers and underscores; however, it still uses letters
    only, not letters and marks, let alone number letters like Roman
    numerals.

 3. I see the apostrophe there, which is a good start, but what if 
    it is a RIGHT SINGLE QUOTATION MARK, as in "Henry?s"?  And 
    what about hyphens?  Those should not trigger capitalization
    in normal titles.

 4. It turns out that all code that does a titlecase on the first 
    character of a string it has already converted to lowercase has
    irreversibly lost information.  Unicode casing it not reversable.
    Using \w for convenience, these can do different things:

        s/(\w+)/\u\L$1/g;
        s/(\w)(\w*)/\u$1\L$2/g;

    or in the functional approach, 

        s/(\w+)/ucfirst(lc($1))/ge;
        s/(\w)(\w*)/ucfirst($1) . lc($2)/ge;

    Now while it is true that only these code points alone do the wrong 
    thing using the na?ve approach under Unicode 6.0:

     % unichars -gas 'ucfirst ne ucfirst lc'
      ?  U+00130 GC=Lu SC=Latin        LATIN CAPITAL LETTER I WITH DOT ABOVE
      ?  U+003F4 GC=Lu SC=Greek        GREEK CAPITAL THETA SYMBOL
      ?  U+01E9E GC=Lu SC=Latin        LATIN CAPITAL LETTER SHARP S
      ?  U+02126 GC=Lu SC=Greek        OHM SIGN
      K  U+0212A GC=Lu SC=Latin        KELVIN SIGN
      ?  U+0212B GC=Lu SC=Latin        ANGSTROM SIGN

    But it is still the wrong thing, and we never know what might happen
    in the future.

I think Python is being smarter than Perl in simply providing people
with a titlecase-each-word('s-first-letterand-lowercase-the-rest)in-the-whole-
string function, because this means people won't be tempted to write

    s/(\w+)/ucfirst(lc($1))/ge;

all the time.  However, as I have written elsewhere, I question a lot of
its underlying assumptions.  It's clear that a "word" must in general
include not just Letters but also Marks, or else you get different
results in NFD and NFC, and the Unicode Standard is very against that.

However, the problem is that what a word is cannot be considered
independent of language.  Words in English can contain apostrophes
(whether written as an APOSTROPHE or as RIGHT SINGLE QUOTATION MARK) 
and hyphens (written as HYPHEN-MINUS, HYPHEN, and rarely even EN DASH).

Each of these is a single word:

    ?tisn?t
    anti?intellectual
    earth?moon

The capitalization there should be 

    ?Tisn?t
    Anti?intellectual
    Earth?Moon

Notice how you can't do the same with the first apostrophe+t as with the
second on "?Tisn?t"". That is all challenging to code correctly (did you
notice the EN DASH?), especially when you find something like
red?violet?colored.  You problably want that to be Red?violet?colored,
because it is not an equal compound like earth?moon or yin?yang, which
in correct orthography take an EN DASH not a HYPHEN, just as occurs
when you hyphenate an already hyphenated word like red?violet against
colored, as in a red?violet?colored flower.  English titling rules 
only capitalize the first word in hyphenated words, which is why it's
Anti?intellectual not Anti-Intellectual.  

And of course, you can't actually create something in true English
titlecase without knowing having a stop list of articles and (short)
prepositions, and paying attention to whether it is the first or last word
in the title, and whether it follows a colon or semicolon.  Consider that
phrasal verbs are construed to take adverbs not prepositions, and so
"Bringing In the Sheaves" would be the correct capitalization of that song,
since "to bring in" is a phrasal verb, but "A Ringing in My Ears" would be
right for that.  It is remarkably complicated.  

With English titlecasing, you have to respect what your publishing house
considers a "short" preposition.  A common cut-off is that short preps
have 4 or fewer characters, but I have seen longer cutoffs.  Here is one
rather exhaustive list of English prepositions sorted by length:

 2: as  at  by  in  of  on  to  up  vs

 3: but  for  off  out  per  pro  qua  via

 4: amid atop down from into like near next onto over
    pace past plus sans save than till upon with

<cutoff point for O'Reilly Media>

 5: about above after among below circa given minus
    round since thru times under until worth

 6: across amidst around before behind beside beside beyond
    during except inside toward unlike versus within

 7: against barring beneath besides between betwixt
    despite failing outside through thruout towards without

10: throughout underneath

The thing is that prepositions become adverbs in phrasal verbs, like "to
go out" or "to come in", and all adverbs are capitalized.  So a complete
solution requires actual parsing of English!!!!  Just say no -- or stronger.

Merely getting something like this right:

    the lord of the rings: the fellowship of the ring  # Unicode lowercase
    THE LORD OF THE RINGS: THE FELLOWSHIP OF THE RING  # Unicode uppercase
    The Lord of the Rings: The Fellowship of the Ring  # English titlecase

is going to take a bit of work.  So is 

    the sad tale of king henry ?   and caterina de arag?n  # Unicode lowercase
    THE SAD TALE OF KING HENRY ?   AND CATERINA DE ARAG?N  # Unicode uppercase
    The Sad Tale of King Henry ?   and Caterina de Arag?n  # English titlecase

(and that must give the same answer in NFC vs NFD, of course.)

Plus what to do with something like num2ascii is ill-defined in English,
because having digits in the middle of a word is a very new phenomenon.
Yes, Y2K gets caps, but that is for another reason.  There is no agreement
on what one should do with num2ascii or people42see.  A function name
shouldn't be capitalized at all of course.

And that is just English.  Other languages have completely different rules.
For example, per Wikipedia's entry on the colon:

    In Finnish and Swedish, the colon can appear inside words in a
    manner similar to the English apostrophe, between a word (or
    abbreviation, especially an acronym) and its grammatical (mostly
    genitive) suffixes. In Swedish, it also occurs in names, for example
    Antonia Ax:son Johnson (Ax:son for Axelson). In Finnish it is used
    in loanwords and abbreviations; e.g., USA:han for the illative case
    of "USA". For loanwords ending orthographically in a consonant but
    phonetically in a vowel, the apostrophe is used instead: e.g. show'n
    for the genitive case of the English loan "show" or Versailles'n for
    the French place name Versailles.

Isn't that tricky!  I guess that you would have to treat punctuation
that has a word character immediately following it (and immediately 
preceding it) as being part of the word, and that it doesn't signal
that a change in case is merited.

I'm really not sure. It is not obvious what the right thing to do here.

I do believe that Python's titlecase function can and should be fixed to
work correctly with Unicode.  There really is no excuse for turning Arago?n
into Arago?N, for example, or not doing the right thing with ?   and ?  .

I fear the only thing you can do with the confusion of Unicode titlecase
and English titlecase is to explain that properly rendering English titles
and headlines is a much more complicated job which you will not even
attempt.  (And shoudln't. English titelcase is clear too specialized for a
general function.)

However, I'm still bothered by things with apostrophes though.

    can't 
    isn't 
    woudn't've
    Bill's
    'tisn't

since I can't countenance the obviously wrong:

    Can'T 
    Isn'T 
    Woudn'T'Ve
    Bill'S
    'Tisn'T

with the last the hardest to get right.  I do have code that correctly
handles English words and code that correctly handles English titles,
but  it is much tricker the titlecase() function.

And Swedes might be upset seeing Antonia Ax:Son Johnson instead 
of Antonia Ax:son Johnson.

Maybe we should just go back to the Pythonic equivalent of 

    s/(\w)(\w*)/ucfirst($1) . lc($2)/ge;

where \w is specifically per tr18's Annex C, and give up on punctuation
altogether, with a footnoted caveat or something.  I wouldn't complain
about that.  The rest is just too, too hard.  Wouldn't you agree?

Thank you very much for all your hard work -- and patience with me.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sun Oct  2 22:43:50 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 02 Oct 2011 20:43:50 +0000
Subject: [issue5001] Remove assertion-based checking in multiprocessing
In-Reply-To: <1232382762.58.0.610641171059.issue5001@psf.upfronthosting.co.za>
Message-ID: <1317588230.22.0.452780658169.issue5001@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

I attached a patch which replaces all asserts with checks that raise exceptions. I used my judgement in determining exception types but I might have been off in some places. Also, this patch replaces ALL asserts. It is possible that some of the internal functions should be kept using asserts but I am not familiar enough with the module to say which. I figured I'd better do the whole thing than reviewers can say where lines should be reverted to asserts.

----------
keywords: +patch
nosy: +vladris
Added file: http://bugs.python.org/file23298/issue5001.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5001>
_______________________________________

From report at bugs.python.org  Sun Oct  2 23:26:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Oct 2011 21:26:27 +0000
Subject: [issue5001] Remove assertion-based checking in multiprocessing
In-Reply-To: <1232382762.58.0.610641171059.issue5001@psf.upfronthosting.co.za>
Message-ID: <1317590787.08.0.584271293637.issue5001@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you. I've attached some comments, click on the "review" link to read them.

----------
assignee: jnoller -> 
nosy: +pitrou -BreamoreBoy
stage: needs patch -> patch review
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5001>
_______________________________________

From report at bugs.python.org  Sun Oct  2 23:46:38 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 02 Oct 2011 21:46:38 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1317591998.92.0.34006048175.issue1625@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> This is all fine and well, but this is clearly a bug and not a feature.

No, it is not at all clear that this is a bug. I agree that this is a desirable
capability to have, but nowhere does the module claim to support multi-stream files.
Nor is it an inherent feature of the underlying bzip2 library that we are failing
to expose to users.

> [...] python 2.x users will never be able to extract multiple-stream bz2 files.

Incorrect. It is perfectly possible to extract a multi-stream bz2 file in 2.x -
you just need to open it with open() and decompress the data using
BZ2Decompressor (pretty much the same way that 3.3's BZ2File does it).

If there is really a large demand for these facilities in 2.x, I would be willing
to port 3.3's BZ2File implementation to 2.x and make it available on PyPI. But 
this patch is not going in to the 2.7 stdlib; it is simply not the sort of
behavior change that is acceptable in a bugfix release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Sun Oct  2 23:56:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Oct 2011 21:56:59 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <32145.1317580838@chthon>
Message-ID: <4E88DE0D.2020800@udel.edu>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> Really?  White space makes things harder to read?  I thought Pythonistas
> believed the opposite of that.

I was surprised at that too ;-). One person's opinion in a specific 
context. Don't generaliza.

> English titling rules
> only capitalize the first word in hyphenated words, which is why it's
> Anti?intellectual not Anti-Intellectual.

Except that I can imagine someone using the latter as a noun to make the 
work more officious or something. There are no official English titling 
rules and as you noted, publishers vary. I agree that str.title should 
do something sensible based on Unicode, with the improvements you mentioned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Oct  3 00:13:54 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 02 Oct 2011 22:13:54 +0000
Subject: [issue13091] ctypes: memory leak
In-Reply-To: <1317546718.25.0.742978918789.issue13091@psf.upfronthosting.co.za>
Message-ID: <1317593634.85.0.642585577102.issue13091@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

How did you obtain this? the resize() function is not called by test_multiprocessing.
And are you sure that it's not some kind of reference leak? (this pointer is tied to a CDataObject; its tp_alloc should free the memory)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13091>
_______________________________________

From report at bugs.python.org  Mon Oct  3 00:27:40 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 02 Oct 2011 22:27:40 +0000
Subject: [issue12804] "make test" fails on systems without internet access
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <1317594460.75.0.686221808347.issue12804@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Change reverted. "make test" should run a comprehensive test of
> Python's facilities

Fair enough.

> If it is easy to detect network availability programmatically, we could
> just use the skip system.

+1. I don't know if there is a reasonable way to do this, but if so, that
would be the best solution.

----------
stage:  -> needs patch
title: make test should not enable the urlfetch resource -> "make test" fails on systems without internet access

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Mon Oct  3 00:31:53 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 02 Oct 2011 22:31:53 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <1317594713.75.0.531206922598.issue13053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Mostly looks good - couple of minor comments in Reitveld.

As far as the patch flow goes, the 2.x and 3.x branches are actually handled independently (they're too divergent for merging to make sense).

So 2.7 and 3.2 will be independent commits, then the changes will be merged into default from the 3.2 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Mon Oct  3 00:45:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Oct 2011 22:45:53 +0000
Subject: [issue12804] "make test" fails on systems without internet access
In-Reply-To: <1317594460.75.0.686221808347.issue12804@psf.upfronthosting.co.za>
Message-ID: <1317595344.3562.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > If it is easy to detect network availability programmatically, we could
> > just use the skip system.
> 
> +1. I don't know if there is a reasonable way to do this, but if so, that
> would be the best solution.

Actually, the skip system is already supposed to work for that if used
properly (see test.support.transient_internet()). However, perhaps it
actually doesn't work in all situations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Mon Oct  3 00:49:23 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 02 Oct 2011 22:49:23 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317595763.49.0.480994691997.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Thanks for investigating the Windows situation.

> - liblzma can't be compiled by Visual Studio: too many C99 isms, mostly
> variables declared in the middle of a block.  It's doable for sure, but it's a
> lot of work.

I don't think that creating our own MSVC-friendly fork of liblzma is really an
option. Over and above the work of porting it in the first place (and all the
opportunities for bugs to creep in along the way), we'd also have to worry about
keeping up to date with upstream changes. I believe we currently do something
similar with libffi (for ctypes), and the impression I've gotten is that it's
caused a lot of trouble.

> - The way recommended by XZ is to use a precompiled liblzma.dll; Then it
> should be easy to build an extension module, but its would be the first time
> that we distribute an extension module which needs a non-system DLL.  Is it
> enough to copy it next to _lzma.pyd?  Is there some work to do in the
> installer?

I would guess that this is sufficient, but my knowledge of how Windows DLLs work
is minimal. Could someone with more platform knowledge weigh in on whether this
would work (and if there are any problems it might cause)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon Oct  3 00:55:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Oct 2011 22:55:06 +0000
Subject: [issue12911] Expose a private accumulator C API
In-Reply-To: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za>
Message-ID: <1317596106.47.0.26052755268.issue12911@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch implementing Martin's suggested optimization (only instantiate the large list when necessary).

----------
Added file: http://bugs.python.org/file23299/accu3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12911>
_______________________________________

From report at bugs.python.org  Mon Oct  3 00:55:42 2011
From: report at bugs.python.org (Dan Stromberg)
Date: Sun, 02 Oct 2011 22:55:42 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1317595763.49.0.480994691997.issue6715@psf.upfronthosting.co.za>
Message-ID: <CAOvKW55TMLOof-8bMAbBXa49Kao8EkrynS3JYsiR776G=jdf2w@mail.gmail.com>


Dan Stromberg <strombrg at gmail.com> added the comment:

On Sun, Oct 2, 2011 at 3:49 PM, Nadeem Vawda <report at bugs.python.org> wrote:

>
> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:
>
> Thanks for investigating the Windows situation.
>
> > - liblzma can't be compiled by Visual Studio: too many C99 isms, mostly
> > variables declared in the middle of a block.  It's doable for sure, but
> it's a
> > lot of work.
>
> I don't think that creating our own MSVC-friendly fork of liblzma is really
> an
> option. Over and above the work of porting it in the first place (and all
> the
> opportunities for bugs to creep in along the way), we'd also have to worry
> about
> keeping up to date with upstream changes. I believe we currently do
> something
> similar with libffi (for ctypes), and the impression I've gotten is that
> it's
> caused a lot of trouble.

It's much better to contribute patches upstream.

> > - The way recommended by XZ is to use a precompiled liblzma.dll; Then it
> > should be easy to build an extension module, but its would be the first
> time
> > that we distribute an extension module which needs a non-system DLL.  Is
> it
> > enough to copy it next to _lzma.pyd?  Is there some work to do in the
> > installer?
>
> I would guess that this is sufficient, but my knowledge of how Windows DLLs
> work
> is minimal. Could someone with more platform knowledge weigh in on whether
> this
> would work (and if there are any problems it might cause)?

I've not done much with windows dll's, but I've heard they're pretty similar
to AIX shared libraries which I've done some work with.  AIX shared
libraries don't deal with versioning well - if you have two version of the
same library on a system, you have to pop them into two different loader
domains, or suffer unresolved externals at runtime.  Then your applications
are in of the two loader domains, and if they're in the wrong one, you again
suffer unresolved externals at runtime.

----------
Added file: http://bugs.python.org/file23300/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________
-------------- next part --------------
<br><div class="gmail_quote">On Sun, Oct 2, 2011 at 3:49 PM, Nadeem Vawda <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
Nadeem Vawda &lt;<a href="mailto:nadeem.vawda at gmail.com">nadeem.vawda at gmail.com</a>&gt; added the comment:<br>
<br>
</div>Thanks for investigating the Windows situation.<br>
<div class="im"><br>
&gt; - liblzma can&#39;t be compiled by Visual Studio: too many C99 isms, mostly<br>
&gt; variables declared in the middle of a block. ??It&#39;s doable for sure, but it&#39;s a<br>
&gt; lot of work.<br>
<br>
</div>I don&#39;t think that creating our own MSVC-friendly fork of liblzma is really an<br>
option. Over and above the work of porting it in the first place (and all the<br>
opportunities for bugs to creep in along the way), we&#39;d also have to worry about<br>
keeping up to date with upstream changes. I believe we currently do something<br>
similar with libffi (for ctypes), and the impression I&#39;ve gotten is that it&#39;s<br>
caused a lot of trouble.</blockquote><div><br></div><div>It&#39;s much better to contribute patches upstream.</div><div>??</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
&gt; - The way recommended by XZ is to use a precompiled liblzma.dll; Then it<br>
&gt; should be easy to build an extension module, but its would be the first time<br>
&gt; that we distribute an extension module which needs a non-system DLL. ??Is it<br>
&gt; enough to copy it next to _lzma.pyd? ??Is there some work to do in the<br>
&gt; installer?<br>
<br>
</div>I would guess that this is sufficient, but my knowledge of how Windows DLLs work<br>
is minimal. Could someone with more platform knowledge weigh in on whether this<br>
would work (and if there are any problems it might cause)?</blockquote><div><br></div><div>I&#39;ve not done much with windows dll&#39;s, but I&#39;ve heard they&#39;re pretty similar to AIX shared libraries which I&#39;ve done some work with. ??AIX shared libraries don&#39;t deal with versioning well - if you have two version of the same library on a system, you have to pop them into two different loader domains, or suffer unresolved externals at runtime. ??Then your applications are in of the two loader domains, and if they&#39;re in the wrong one, you again suffer unresolved externals at runtime.</div>
<div>??</div></div>-- <br>Dan Stromberg<br>

From report at bugs.python.org  Mon Oct  3 00:58:36 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 02 Oct 2011 22:58:36 +0000
Subject: [issue13091] ctypes: memory leak
In-Reply-To: <1317546718.25.0.742978918789.issue13091@psf.upfronthosting.co.za>
Message-ID: <1317596316.01.0.352885503928.issue13091@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I can reproduce this with:

valgrind --tool=memcheck --log-file=leaks.txt --leak-check=full --suppressions=Misc/valgrind-python.supp ./python -m test test_ctypes

Where as:

valgrind --tool=memcheck --log-file=leaks.txt --leak-check=full --suppressions=Misc/valgrind-python.supp ./python -m test test_multiprocessing

turns up nothing in 'ctypes.resize'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13091>
_______________________________________

From report at bugs.python.org  Mon Oct  3 01:03:31 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 02 Oct 2011 23:03:31 +0000
Subject: [issue12804] "make test" fails on systems without internet access
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <1317596611.07.0.224669598146.issue12804@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Oh, neat. I'll take a look at that when I get a chance.

----------
assignee:  -> nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Mon Oct  3 01:23:55 2011
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 02 Oct 2011 23:23:55 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <1317597835.01.0.401483616141.issue13053@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Attached is r2 of the patch, incorporating Nick's suggestions.  Base revision hasn't changed.

----------
Added file: http://bugs.python.org/file23301/larry.cporting.capsules.r2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Mon Oct  3 01:30:05 2011
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 02 Oct 2011 23:30:05 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <1317598205.65.0.0406181880199.issue13053@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

In case you're curious, here's how I tested "capsulethunk.h".  I added the file to Python 2.7 (hg head), 3.0.0 (tarball), and 3.1.0 (tarball).  For 2.7 ad 3.0.0 I quickly hacked four files to use the Capsule API instead of CObjects:
 * Python/compile.c
 * Python/getargs.c
 * Modules/_ctypes/callproc.c
 * Modules/_ctypes/cfield.c
(For 3.1 I simply included the file in those four files, as they already use the Capsule API.)  I then built and ran regrtest.py.

While developing capsulethunk.h, I had a more thorough test suite; sadly that's on a laptop that is shut off, and I'm on vacation across the Atlantic and can't get at it.  But everything was working fine last I checked ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Mon Oct  3 01:37:30 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 02 Oct 2011 23:37:30 +0000
Subject: [issue5001] Remove assertion-based checking in multiprocessing
In-Reply-To: <1232382762.58.0.610641171059.issue5001@psf.upfronthosting.co.za>
Message-ID: <1317598650.93.0.651603368224.issue5001@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Thanks for the quick review! I attached second iteration addressing feedback + changed all occurrences of checks like "type(x) is y" to "isinstance(x, y)".

I would appreciate a second look because this patch has many small changes and even though I ran full test suit which passed, I'm afraid I made a typo somewhere :)

----------
Added file: http://bugs.python.org/file23302/issue5001_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5001>
_______________________________________

From report at bugs.python.org  Mon Oct  3 01:39:31 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 02 Oct 2011 23:39:31 +0000
Subject: [issue13073] message_body argument of HTTPConnection.endheaders is
	undocumented
In-Reply-To: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>
Message-ID: <1317598771.59.0.292415701319.issue13073@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

This is fixed the following changesets.

changeset a3f2dba93743
changeset 1ed413b52af3
changeset 277688052c5a

Thanks for the patch, Ben Hayden.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13073>
_______________________________________

From report at bugs.python.org  Mon Oct  3 02:22:15 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 03 Oct 2011 00:22:15 +0000
Subject: [issue13091] ctypes: memory leak
In-Reply-To: <1317546718.25.0.742978918789.issue13091@psf.upfronthosting.co.za>
Message-ID: <1317601335.6.0.176142368064.issue13091@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> this pointer is tied to a CDataObject; its tp_alloc should free the 
> memory

The free in 'PyCData_clear' is conditional:

    if ((self->b_needsfree)
        && ((size_t)dict->size > sizeof(self->b_value)))
        PyMem_Free(self->b_ptr);

As written, 'PyCData_clear' has no way of knowing that memory has been 
{m,re}alloc'd in 'resize'.  So in some cases memory will leak.  Here is 
a small reproduction case extracted from 'test_varsize_struct.py'.

    from ctypes import *

    class X(Structure):
        _fields_ = [("item", c_int),
                    ("array", c_int * 1)]

    x = X()
    x.item = 42
    x.array[0] = 100
    new_size = sizeof(X) + sizeof(c_int) * 5
    resize(x, new_size)

One potential fix is:

diff --git a/Modules/_ctypes/_ctypes.c b/Modules/_ctypes/_ctypes.c
--- a/Modules/_ctypes/_ctypes.c
+++ b/Modules/_ctypes/_ctypes.c
@@ -2440,7 +2440,7 @@ PyCData_clear(CDataObject *self)
     assert(dict); /* Cannot be NULL for CDataObject instances */
     Py_CLEAR(self->b_objects);
     if ((self->b_needsfree)
-        && ((size_t)dict->size > sizeof(self->b_value)))
+        && (self->b_ptr != (char *)&self->b_value))
         PyMem_Free(self->b_ptr);
     self->b_ptr = NULL;
     Py_CLEAR(self->b_base);

I need to think about that more, though.

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13091>
_______________________________________

From report at bugs.python.org  Mon Oct  3 03:36:06 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 03 Oct 2011 01:36:06 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317605766.23.0.467816301133.issue13062@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Here is a first cut at a patch.  There is one slight deviation from the original spec:

> some nice error checking for when the generator's frame is already gone > (or the supplied object isn't a generator iterator).

The attached patch returns empty mappings for these cases.  I can easily
add the error checks, but in what cases is it useful to know *exactly*
why a mapping could not be created?  Having an empty mapping for all 
invalid cases is simpler and seems more robust.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23303/issue13062.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13062>
_______________________________________

From report at bugs.python.org  Mon Oct  3 04:02:59 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 03 Oct 2011 02:02:59 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317607379.86.0.272110831639.issue13062@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Because a generator can legitimately have no locals:

>>> def gen():
...     yield 1
... 
>>> g = gen()
>>> g.gi_frame.f_locals
{}

Errors should be reported as exceptions - AttributeError or TypeError if there's no gi_frame and then ValueError or RuntimeError if gi_frame is None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13062>
_______________________________________

From report at bugs.python.org  Mon Oct  3 04:09:09 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 03 Oct 2011 02:09:09 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1317607749.78.0.985477200064.issue12943@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Fixed a few more nits pointed out in review.

----------
Added file: http://bugs.python.org/file23304/issue12943-6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12943>
_______________________________________

From report at bugs.python.org  Mon Oct  3 04:12:03 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 03 Oct 2011 02:12:03 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317607923.92.0.651978518474.issue13062@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The function case is simpler - AttributeError or TypeError if there's no __closure__ attribute, empty mapping if there's no closure.

I've also changed my mind on the "no frame" generator case - since that mapping will evolve over time as the generator executes anyway, the empty mapping accurately reflects the "no locals currently defined" that applies when the generator either hasn't been started yet or has finished. People can use getgeneratorstate() to find that information if they need to know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13062>
_______________________________________

From report at bugs.python.org  Mon Oct  3 04:25:23 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 03 Oct 2011 02:25:23 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <4E88DE0D.2020800@udel.edu>
Message-ID: <9072.1317605488@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

>> Really?  White space makes things harder to read?  I thought Pythonistas
>> believed the opposite of that.

> I was surprised at that too ;-). One person's opinion in a specific 
> context. Don't generalize.

The example I initially showed probably wasn't the best for that.
Mostly I was trying to demonstrate how useful it is to have user-defined
properties is all.  But I have no asked for that (I have asked for properties,
though).

>> English titling rules
>> only capitalize the first word in hyphenated words, which is why it's
>> Anti?intellectual not Anti-Intellectual.

> Except that I can imagine someone using the latter as a noun to make the 
> work more officious or something. 

If Good-Looking looks more officous than Good-looking, I bet GOOD-LOOKING
is better still. :)

> There are no official English titling rules and as you noted,
> publishers vary. 

If there aren't any rules, then how come all book and movie titles always
look the same?  :)  I don't think anyone would argue with these two:

 1. Capitalize the first word, the last word, and the word right after a
    colon (or semicolon).

 2. Capitalize all intervening words except for articles (a, an, the)
    and short prepositions.

Those are the basic rules.  The main problem is that "short" isn't
well defined--and indeed, there are even places where "preposition" 
isn't well defined either.  

English has sentence casing (only the first word) and headline casing (most of them).
It's problematic that computer people call capitalizing each word titlecasing,
since in English, this is never correct.

    http://www.chicagomanualofstyle.org/CMS_FAQ/CapitalizationTitles/CapitalizationTitles23.html

     Although Chicago style lowercases prepositions (but see CMOS 8.157
     for exceptions), some style guides uppercase them. Ask your editor
     for a style guide.

I myself usually fall back to the Chicago Manual of Style or the Oxford
Guide to Style.  I don't think I do anything neither of them says to do.

But I completely agree that this should *not* be in the titlecase()
function.  I think the docs for the function might perhaps say something
about how it does not mean correct English headline case when it says
titlecase, but that's largely just nitpicking.

> I agree that str.title should do something sensible
> based on Unicode, with the improvements you mentioned.

One of the goals of Unicode is that casing not be language dependent.  And
they almost got there, too.  The Turkic I is the most notable exception.

Did you know there is a problem with all the case stuff in Python?  It 
was clearly put in before they had realized that they needed to have
things other the Lu/Lt/Ll have casing properties.  That's why there is
a difference betwen GC=Ll and the Lowercase property.

    str.islower()

    Return true if all cased characters in the string are lowercase and
    there is at least one cased character, false otherwise. Cased
    characters are those with general category property being one of
    ?Lu?, ?Ll?, or ?Lt? and lowercase characters are those with general
    category property ?Ll?.

    http://docs.python.org/release/3.2/library/stdtypes.html

That really isn't right.  A cased character is one with the Unicode "Cased"
property, and a lowercase character is one wiht the Unicode "Lowercase"
property.  The General Category is actually immaterial here.

I've spent all bloody day trying to model Python's islower, isupper, and istitle
functions, but I get all kinds of errors, both in the definitions and in the
models of the definitions.    Under both 2.7 and 3.2, I get all these bugs:

    ? not islower() but has at least one cased character with all cased characters lowercase!
    ? not islower() but has at least one cased character with all cased characters lowercase!
    ? not islower() but has at least one cased character with all cased characters lowercase!
    ? not islower() but has at least one cased character with all cased characters lowercase!
    ? not isupper() but has at least one cased character with all cased characters uppercase!
    ? not istitle() but should be
    ? not islower() but has at least one cased character with all cased characters lowercase!
    2?? not islower() but has at least one cased character with all cased characters lowercase!
    2?? not islower() but has at least one cased character with all cased characters lowercase!
    ?? isupper() but fails to have at least one cased character with all cased characters uppercase!
    ThisIsInTitleCaseYouKnow not istitle() but should be
    M? isupper() but fails to have at least one cased character with all cased characters uppercase!
    ?M isupper() but fails to have at least one cased character with all cased characters uppercase!
    ?M istitle() but should not be
    M?KINLEY isupper() but fails to have at least one cased character with all cased characters uppercase!

I really don't understand.    BTW, I feel that M?Kinley is titlecase in that lowercase
always follows uppercase and uppercase never follows itself.  And Python agrees with me.
But that same definition should vet ThisIsInTitleCaseYouKnow, but Python disagrees.

I really don't understand any of these functions.  I'm very sad.  I think they are
wrong, but maybe I am.  It is extremely confusing.

Shall I file a separate bug report?

--tom

from __future__ import unicode_literals
from __future__ import print_function

import regex

VERBOSE = 0 

data = [

  # first test the problem cases just one at a time
    "\N{MODIFIER LETTER SMALL C}",
    "\N{SUPERSCRIPT LATIN SMALL LETTER N}",
    "\N{MODIFIER LETTER CAPITAL D}", 
    "\N{CIRCLED LATIN SMALL LETTER K}",
    "\N{COMBINING GREEK YPOGEGRAMMENI}",
    "\N{ROMAN NUMERAL EIGHT}",
    "\N{SMALL ROMAN NUMERAL EIGHT}",
    "\N{LATIN CAPITAL LETTER D WITH SMALL LETTER Z}",
    "\N{LATIN LETTER SMALL CAPITAL R}",

  # test superscripts
    "2\N{SUPERSCRIPT LATIN SMALL LETTER N}\N{MODIFIER LETTER SMALL D}", 
    "2\N{MODIFIER LETTER CAPITAL N}\N{MODIFIER LETTER CAPITAL D}",
    "2\N{FEMININE ORDINAL INDICATOR}", # as in "segunda"

  # test romans
    "ROMAN NUMERAL EIGHT IS \N{ROMAN NUMERAL EIGHT}",
    "roman numeral eight is \N{SMALL ROMAN NUMERAL EIGHT}",

  # test small caps
    "\N{LATIN LETTER SMALL CAPITAL R}\N{LATIN LETTER SMALL CAPITAL A}\N{LATIN LETTER SMALL CAPITAL R}\N{LATIN LETTER SMALL CAPITAL E}",

  # test cased combining mark (this is in titlecase)
    "\N{GREEK CAPITAL LETTER ALPHA WITH VARIA}\N{COMBINING GREEK YPOGEGRAMMENI}",
    "\N{GREEK CAPITAL LETTER ALPHA WITH VARIA}\N{COMBINING GREEK YPOGEGRAMMENI} \N{GREEK CAPITAL LETTER SIGMA}\N{GREEK SMALL LETTER TAU}\N{GREEK SMALL LETTER OMICRON} \N{GREEK CAPITAL LETTER DELTA}\N{GREEK SMALL LETTER IOTA}\N{GREEK SMALL LETTER ALPHA WITH TONOS}\N{GREEK SMALL LETTER OMICRON}\N{GREEK SMALL LETTER LAMDA}\N{GREEK SMALL LETTER OMICRON}",

  # test cased symbols
    "circle  \N{CIRCLED LATIN SMALL LETTER K}",
    "CIRCLE  \N{CIRCLED LATIN CAPITAL LETTER K}",

  # test titlecased code point 3-way
    "\N{LATIN CAPITAL LETTER DZ}",
    "\N{LATIN CAPITAL LETTER DZ}UR",
    "\N{LATIN CAPITAL LETTER D WITH SMALL LETTER Z}ur",
    "\N{LATIN CAPITAL LETTER D WITH SMALL LETTER Z}",
    "\N{LATIN SMALL LETTER DZ}ur",
    "\N{LATIN SMALL LETTER DZ}",

  # test titlecase

    "FBI", "F B I", "F.B.I",
    "HP Company", "H.P. Company",
    "ThisIsInTitleCaseYouKnow",

    "M\N{MODIFIER LETTER SMALL C}",
    "\N{MODIFIER LETTER SMALL C}M",

    "M\N{MODIFIER LETTER SMALL C}Kinley",  # titlecase
    "M\N{MODIFIER LETTER SMALL C}KINLEY",  # uppercase
    "m\N{MODIFIER LETTER SMALL C}kinley",  # lowercase

    # Return true if the string is a titlecased string and there
    # is at least one character, for example uppercase characters may
    # only follow uncased characters and lowercase characters only
    # cased ones. Return false otherwise.

    # Return true if all cased characters in the string are lowercase and there is at least one cased character,
]

for s in data:

  # "Return true if all cased characters in the string are lowercase 
  #  and there is at least one cased character"

    if s.islower():
        if not (        regex.search(r'\p{cased}', s) 
                and not regex.search(r'(?=\p{cased})\P{LOWERCASE}', s)):
            print(s+" islower() but fails to have at least one cased character with all cased characters lowercase!")
    else:
        if (        regex.search(r'\p{cased}', s) 
            and not regex.search(r'(?=\p{cased})\P{LOWERCASE}', s)):
            print(s+" not islower() but has at least one cased character with all cased characters lowercase!")

  # "Return true if all cased characters in the string are uppercase 
  #  and there is at least one cased character"

    if s.isupper():
        if not (        regex.search(r'\p{cased}', s) 
                and not regex.search(r'(?=\p{cased})\P{UPPERCASE}', s)):
            print(s+" isupper() but fails to have at least one cased character with all cased characters uppercase!")
    else:
        if (        regex.search(r'\p{cased}', s) 
            and not regex.search(r'(?=\p{cased})\P{UPPERCASE}', s)):
            print(s+" not isupper() but has at least one cased character with all cased characters uppercase!")

  # "Return true if the string is a titlecased string and there is at
  # least one character, for example uppercase characters may only
  # follow uncased characters and lowercase characters only cased ones."

    has_it  = s.istitle()
    want_it1 = (  
          # at least one title/uppercase
                regex.search(r'[\p{Lt}\p{uppercase}]', s) 
                  and not 
          # plus no title/uppercase follows cased character
               regex.search(r'(?<=\p{cased})[\p{Lt}\p{uppercase}]', s)
                  and not 
          # plus no lowercase follows uncased character
               regex.search(r'(?<=\P{CASED})\p{lowercase}', s)
              )

    want_it  = regex.search(r'''(?x) 
        ^ 
            (?:
                \P{CASED} * 
                [\p{Lt}\p{uppercase}] 
                (?! [\p{Lt}\p{uppercase}] )
                    \p{lowercase} *
            ) +
            \P{CASED} * 
        $
    ''', s)

    if VERBOSE:
        if has_it and want_it:
            print( s + " istitle() and should be (OK)")
        if not has_it and not want_it:
            print( s + " not istitle() and should not be (OK)")

    if has_it and not want_it:
        print( s + " istitle() but should not be")

    if want_it and not has_it:
        print( s + " not istitle() but should be")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Oct  3 06:15:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Oct 2011 04:15:50 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1317615350.8.0.846192018045.issue12753@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> But it still has to happen at compile time, of course, so I don't know
> what you could do in Python.  Is there any way to change how the compiler
> behaves even vaguely along these lines?

I think things like "from __future__ import ..." do something similar, but I'm not sure it will work in this case (also because you will have to provide the list of aliases somehow).

>> Really?  White space makes things harder to read?  I thought Pythonistas
>> believed the opposite of that.  Whitespace is very useful for cognitive
>> chunking: you see how things logically group together.

> I was surprised at that too ;-). One person's opinion in a specific 
> context. Don't generaliza.

Also don't generalize my opinion regarding *where* whitespace makes thing less readable: I was just talking about regex.
What I was trying to say here is best summarized by a quote from Paul Graham's article "Succinctness is Power":
"""
If you're used to reading novels and newspaper articles, your first experience of reading a math paper can be dismaying. It could take half an hour to read a single page. And yet, I am pretty sure that the notation is not the problem, even though it may feel like it is. The math paper is hard to read because the ideas are hard. If you expressed the same ideas in prose (as mathematicians had to do before they evolved succinct notations), they wouldn't be any easier to read, because the paper would grow to the size of a book.
"""
Try replacing
  s/novels and newspaper articles|prose/Python code/g
  s/single page/single regex/
  s/math paper/regex/g.

To provide an example, I find:

# define a function to capitalize s
def my_capitalize(s):
    """This function capitalizes the argument s and returns it"""
    the_first_letter = s[0]  # 0 means the first char
    the_rest_of_s = s[1:]  # 1: means from the second till the end
    the_first_letter_uppercased = the_first_letter.upper()  # upper makes the string uppercase
    the_rest_of_s_lowercased = the_rest_of_s.lower()  # lower makes the string lowercase
    s_capitalized = the_first_letter_uppercased + the_rest_of_s_lowercased  # + concatenates
    return s_capitalized

less readable than:

def my_capitalize(s):
    return s[0].upper() + s[1:].lower()

You could argue that the first is much more explicit and in a way clearer, but overall I think you agree with me that is less readable.  Also this clearly depends on how well you know the notation you are reading: if you don't know it very well, you might still prefer the commented/verbose/extended/redundant version.  Another important thing to mention, is that notation of regular expressions is fairly simple (especially if you leave out look-arounds and Unicode-related things that are not used too often), but having a similar succinct notation for a whole programming language (like Perl) might not work as well (I'm not picking on Perl here, as you said you can write readable programs if you don't abuse the notation, and the succinctness offered by the language has some advantages, but with Python we prefer more readable, even if we have to be a little more verbose).  Another example of a trade-off between verbosity and succinctness is the new string formatting mini-language.

> That really isn't right.  A cased character is one with the Unicode "Cased"
> property, and a lowercase character is one wiht the Unicode "Lowercase"
> property.  The General Category is actually immaterial here.

You might want to take a look and possibly add a comment on #12204 about this.

> I've spent all bloody day trying to model Python's islower, isupper, and istitle
> functions, but I get all kinds of errors, both in the definitions and in the
> models of the definitions.

If by "model" you mean "trying to figure out how they work", it's probably easier to look at the implementation (I assume you know enough C to understand what they do).  You can find the code for str.istitle() at http://hg.python.org/cpython/file/default/Objects/unicodeobject.c#l10358 and the actual implementation of some macros like Py_UNICODE_ISTITLE at http://hg.python.org/cpython/file/default/Objects/unicodectype.c.

> I really don't understand any of these functions.  I'm very sad.  I think they are
> wrong, but maybe I am.  It is extremely confusing.

> Shall I file a separate bug report?

If after reading the code and/or the documentation you still think they are broken and/or that they can be improved, then you can open another issue.

BTW, instead of writing custom scripts to test things, it might be better to use unittest (see http://docs.python.org/py3k/library/unittest.html#basic-example), or even better write a patch for Lib/test/test_unicode.py.
Using unittest has the advantage that is then easy to integrate those tests within our test suite, but on the other hand as soon as something fails the failure is returned without evaluating the following assertions in the method.
This as the advantage that

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Oct  3 07:22:11 2011
From: report at bugs.python.org (jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal)
Date: Mon, 03 Oct 2011 05:22:11 +0000
Subject: [issue13071] IDLE refuses to open on windows 7
In-Reply-To: <1317341122.37.0.866117748717.issue13071@psf.upfronthosting.co.za>
Message-ID: <1317619331.76.0.626152135204.issue13071@psf.upfronthosting.co.za>


jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal <christopherdarkas at gmail.com> added the comment:

Traceback (most recent call last):
  File "C:\Python32\Lib\idlelib/idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "C:\Python32\Lib\idlelib\PyShell.py",line 1377, in main
    shell = flist.open_shell()
  File "C:\Python32\Lib\idlelib\PyShell.py", line 273, in open_shell
    self.pyshell = PyShell(self)
  File "C:\Python32\Lib\idlelib\Pyshell.py", line 802, in __init__
    OutputWindow.__init__(self,flist, none, none)
  File "C:\Python32\Lib\idlelib\OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self,*args)
  File "C:\Python32\Lib\idlelib\EditorWindow.py", line 145, in __init__
    self.aply_bindings()
  File "C:\Python32\Lib\idlelib\EditorWindow.py", line 985, in apply_bindings
    text.event_add(event, *keylist)
  File "C:\Python32\Lib\idlelib\MultiCall.py", line 359, in event_add
    widget.event_add(self, virtual, seq)
  File C:\Python32\Lib\tkinter\__init__.py", line 1353, in event_add
    self.tk.call(args)
_tkinter.TclError: bad event type or keysym "Alt"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13071>
_______________________________________

From report at bugs.python.org  Mon Oct  3 07:23:03 2011
From: report at bugs.python.org (jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal)
Date: Mon, 03 Oct 2011 05:23:03 +0000
Subject: [issue13071] IDLE refuses to open on windows 7
In-Reply-To: <1317341122.37.0.866117748717.issue13071@psf.upfronthosting.co.za>
Message-ID: <1317619383.85.0.443772759877.issue13071@psf.upfronthosting.co.za>


jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal <christopherdarkas at gmail.com> added the comment:

That is the traceback given when I run idle.py through windows command prompt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13071>
_______________________________________

From report at bugs.python.org  Mon Oct  3 08:36:53 2011
From: report at bugs.python.org (Mark Hammond)
Date: Mon, 03 Oct 2011 06:36:53 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1317623813.09.0.874194510321.issue7833@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

This is biting people (including me :) so I'm going to try hard to get this fixed.  One user on the python-win32 mailing list resorts to rebuilding every 3rd party module he uses with this patch to get things working again (although apps which use only builtin modules or pywin32 modules - which already hacks this basic functionality in - don't see the problem.)

I'm attaching a different patch that should have the same default effect as Christoph's, but also allows the behaviour to be overridden.  Actually overriding it is quite difficult as distutils isn't setup to easily allow such compiler customizations - but at least it *is* possible.  To test this out I hacked both the pywin32 and py2erxe build processes to use those customizations and it works fine and allows them both to customize the behaviour to meet various modules' requirements.

Finally, this whole thing is still fundamentally broken for extensions which need a manifest (eg, to reference the common controls or the requestedExecutionLevel cruft).  These extension will still need to include the CRT reference in their manifest and thus will need a copy of the CRT next to each of them.  I *think* this also means they basically get a private copy of the CRT - they are not sharing the CRT with Python, which means they are at risk of hitting problems such as trying to share FILE * objects.  In practice, this means such modules are probably better of just embedding the CRT statically.  This is the route I've taken for one pywin32 module so the module can have a manifest and still work without a complete, private copy of the CRT needing to live next to it.  But even with that problem I think this patch should land.

It would be great if someone can review and test this version of the patch and I'll check it in.

----------
versions: +Python 3.3, Python 3.4 -Python 2.6
Added file: http://bugs.python.org/file23305/bug-7833-overridable-manifest-settings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Mon Oct  3 10:17:51 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Oct 2011 08:17:51 +0000
Subject: [issue13071] IDLE refuses to open on windows 7
In-Reply-To: <1317341122.37.0.866117748717.issue13071@psf.upfronthosting.co.za>
Message-ID: <1317629871.2.0.459395112092.issue13071@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Are you using the .msi installer from python.org?
Or one from activestate or enthought?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13071>
_______________________________________

From report at bugs.python.org  Mon Oct  3 10:20:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Oct 2011 08:20:37 +0000
Subject: [issue13071] IDLE refuses to open on windows 7
In-Reply-To: <1317341122.37.0.866117748717.issue13071@psf.upfronthosting.co.za>
Message-ID: <1317630037.98.0.973499009545.issue13071@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Are you using some "unusual" keyboard layout?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13071>
_______________________________________

From report at bugs.python.org  Mon Oct  3 10:51:45 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 03 Oct 2011 08:51:45 +0000
Subject: [issue13071] IDLE refuses to open on windows 7
In-Reply-To: <1317341122.37.0.866117748717.issue13071@psf.upfronthosting.co.za>
Message-ID: <1317631905.55.0.824742964473.issue13071@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This issue is very similar to issue5707: it is possible to define a custom key binding to "<Alt>" or "<Control>": just click the Alt box and don't select a letter.
There is no check, it's possible to save this buggy key binding, and IDLE won't start anymore.

IDLE should:
- check the validity of the binding and refuse to save it when it is invalid
- gracefully skip invalid bindings from the config file

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13071>
_______________________________________

From report at bugs.python.org  Mon Oct  3 12:09:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Oct 2011 10:09:58 +0000
Subject: [issue12804] "make test" fails on systems without internet access
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <1317636598.22.0.929523788925.issue12804@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW there's also support.open_urlresource that can be used to download test data.  open_urlresouce calls requires('urlfetch') and skips the test when the resource is not enabled.  For instance, test_normalization uses it:
try:
    testdata = support.open_urlresource(TESTDATAURL, encoding="utf-8",
                                        check=check_version)
except (IOError, HTTPException):
    self.skipTest("Could not retrieve " + TESTDATAURL)
self.addCleanup(testdata.close)

This also saves the file on the disk and reuses it when the test is run again, so the connection is actually used once and only if available.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Mon Oct  3 12:20:11 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 03 Oct 2011 10:20:11 +0000
Subject: [issue7425] Improve the robustness of "pydoc -k" in the face of
	broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <1317637211.05.0.491072884624.issue7425@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It turns out that the proposed fix here for pydoc was independently added in the early days of Python 3 but was not backported.  That fix for 2.7 plus a fix-in-progress for Issue7367 (for both 2.7 and 3.x) and additional test cases (also in progress) should address most if not all of the pydoc crash issues.  I'll also review the other open issues.

----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7425>
_______________________________________

From report at bugs.python.org  Mon Oct  3 12:34:34 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 03 Oct 2011 10:34:34 +0000
Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format
In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za>
Message-ID: <1317638074.27.0.573358700089.issue13072@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The automatic conversion of 'u' to 'I' or 'L' causes test_buffer
(PEP-3118 repo) to fail:


# Not implemented formats. Ugly, but inevitable. This is the same as
# issue #2531: equality is also used for membership testing and must
# return a result.
a = array.array('u', 'xyz')
v = memoryview(a)
self.assertNotEqual(v, a)
self.assertNotEqual(a, v)


I don't have a better idea though what to do about 'u' except
officially implementing it for struct and memoryview as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13072>
_______________________________________

From report at bugs.python.org  Mon Oct  3 12:44:48 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 03 Oct 2011 10:44:48 +0000
Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format
In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za>
Message-ID: <1317638688.48.0.173780283507.issue13072@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13072>
_______________________________________

From report at bugs.python.org  Mon Oct  3 12:49:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Oct 2011 10:49:35 +0000
Subject: [issue12458] Tracebacks should contain the first line of continuation
	lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1317638975.4.0.223337846609.issue12458@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is an interesting proposal.

The line number comes from Python/traceback.c:120:
    tb->tb_lineno = PyFrame_GetLineNumber(frame);
and this function is defined in Objects/frameobject.c:35:
int PyFrame_GetLineNumber(PyFrameObject *f) {
    if (f->f_trace)
        return f->f_lineno;
    else
        return PyCode_Addr2Line(f->f_code, f->f_lasti);
}
and documented as "Return the line number that frame is currently executing.", so that would explain why it's pointing to the last line.

I'm not sure if there's an easy way to get the line where the beginning of the expression is, but if you find a way to get it, we could try to use it in PyFrame_GetLineNumber and see how it works.

----------
nosy: +ezio.melotti, georg.brandl, ncoghlan
stage:  -> test needed
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12458>
_______________________________________

From report at bugs.python.org  Mon Oct  3 12:52:43 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 03 Oct 2011 10:52:43 +0000
Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format
In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za>
Message-ID: <1317639163.43.0.12362076793.issue13072@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

>It would be better to use a format for a Py_UCS4 string, but struct doesn't support such type.

PEP-3118 suggests for the extended struct syntax:

'c' -> ucs-1 (latin-1) encoding
'u' -> ucs-2
'w' -> ucs-4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13072>
_______________________________________

From report at bugs.python.org  Mon Oct  3 12:59:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Oct 2011 10:59:47 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1317639587.07.0.341077909878.issue6632@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +tchrist

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Mon Oct  3 13:44:14 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 Oct 2011 11:44:14 +0000
Subject: [issue12911] Expose a private accumulator C API
In-Reply-To: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za>
Message-ID: <1317642254.13.0.480486303814.issue12911@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It's not a container type, just a small C struct that 
> gets allocated on the stack. Think of it as a library, like stringlib.

That's what I call a container type: a structure with a library :-)

> That's another possibility. But we'd have to expose a 
> C API anyway, and this one is as good as any other.

No, it's not: it's additional clutter. If new API needs to be added,
adding it for existing structures is better. Notice that you don't
*need* new API, as you can use StringIO just fine from C also.

> Note that StringIO will copy data twice (once when calling 
> write(), once when calling getvalue()), while ''.join() only once (at 
> the end, when concatenating all strings).

Sounds like a flaw in StringIO to me. It could also manage a list of strings that have been written, rather than only using a flat buffer. Only when someone actually needs a linear buffer, it could convert it (and use a plain string.join when getvalue is called and there is no buffer at all).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12911>
_______________________________________

From report at bugs.python.org  Mon Oct  3 13:58:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Oct 2011 11:58:02 +0000
Subject: [issue12911] Expose a private accumulator C API
In-Reply-To: <1317642254.13.0.480486303814.issue12911@psf.upfronthosting.co.za>
Message-ID: <1317642873.3670.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > That's another possibility. But we'd have to expose a 
> > C API anyway, and this one is as good as any other.
> 
> No, it's not: it's additional clutter. If new API needs to be added,
> adding it for existing structures is better. Notice that you don't
> *need* new API, as you can use StringIO just fine from C also.

Yes, but using StringIO without a dedicated C API is more tedious and
quite slower.

> > Note that StringIO will copy data twice (once when calling 
> > write(), once when calling getvalue()), while ''.join() only once (at 
> > the end, when concatenating all strings).
> 
> Sounds like a flaw in StringIO to me. It could also manage a list of
> strings that have been written, rather than only using a flat buffer.
> Only when someone actually needs a linear buffer, it could convert it
> (and use a plain string.join when getvalue is called and there is no
> buffer at all).

That's what I thought as well. However, that's probably too much for a
bugfix release (and this issue is meant to allow test_bigmem to pass on
3.x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12911>
_______________________________________

From report at bugs.python.org  Mon Oct  3 15:01:45 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 03 Oct 2011 13:01:45 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1317646905.81.0.00533848408685.issue670664@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fred at fdrake.net>:


----------
nosy:  -fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Mon Oct  3 15:34:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Oct 2011 13:34:27 +0000
Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format
In-Reply-To: <1317638074.27.0.573358700089.issue13072@psf.upfronthosting.co.za>
Message-ID: <4E89B9E1.3020801@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The automatic conversion of 'u' to 'I' or 'L' causes test_buffer
> (PEP-3118 repo) to fail:
>
>
> # Not implemented formats. Ugly, but inevitable. This is the same as
> # issue #2531: equality is also used for membership testing and must
> # return a result.
> a = array.array('u', 'xyz')
> v = memoryview(a)
> self.assertNotEqual(v, a)
> self.assertNotEqual(a, v)

I don't understand: a buffer format is a format for the struct module, 
or for the array module?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13072>
_______________________________________

From report at bugs.python.org  Mon Oct  3 16:00:51 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 03 Oct 2011 14:00:51 +0000
Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format
In-Reply-To: <4E89B9E1.3020801@haypocalc.com>
Message-ID: <20111003135737.GA6212@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

STINNER Victor <report at bugs.python.org> wrote:
> > # Not implemented formats. Ugly, but inevitable. This is the same as
> > # issue #2531: equality is also used for membership testing and must
> > # return a result.
> > a = array.array('u', 'xyz')
> > v = memoryview(a)
> > self.assertNotEqual(v, a)
> > self.assertNotEqual(a, v)
> 
> I don't understand: a buffer format is a format for the struct module, 
> or for the array module?

It's like this: memoryview follows the current struct syntax, which
doesn't have 'u'. memory_richcompare() does not understand 'u', but
is required to return something for __eq__ and __ne__, so it returns
'not equal'.

This isn't so important, since I discovered (see my later post)
that 'u' and 'w' were scheduled for inclusion in the struct
module anyway.

So I think we should focus on whether the proposed 'c', 'u' and 'w'
format specifiers still make sense after the PEP-393 changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13072>
_______________________________________

From report at bugs.python.org  Mon Oct  3 16:39:57 2011
From: report at bugs.python.org (=?utf-8?b?VG9tw6HFoSBEdm/FmcOhaw==?=)
Date: Mon, 03 Oct 2011 14:39:57 +0000
Subject: [issue13094] setattr misbehaves when used with lambdas inside for loop
Message-ID: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za>


New submission from Tom?? Dvo??k <dvtomas at gmail.com>:

I have this python script, and run it in python 2.7.2 (installed from EPD_free 7.1-2 (32-bit), but I guess this has nothing to do with EPD.
----8<---fail.py------

class X(object):
    pass

x = X()
items = ["foo", "bar", "baz"]

for each in items:
    setattr(x, each, lambda: each)
    
print("foo", x.foo())    
print("bar", x.bar())
print("baz", x.baz())

----8<---fail.py------

I'd naively expect it to print 
('foo', 'foo')
('bar', 'bar')
('baz', 'baz')

,but it surprisingly (and annoyingly) outputs
('foo', 'baz')
('bar', 'baz')
('baz', 'baz')

Please, tell me that this is a bug :) I'd hate it if this was the intended behaviour. I spent two hours today before I found out this was the cause of my program to fail.

Best regards,
  Tom?? Dvo??k

----------
components: None
messages: 144819
nosy: Tom??.Dvo??k
priority: normal
severity: normal
status: open
title: setattr misbehaves when used with lambdas inside for loop
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13094>
_______________________________________

From report at bugs.python.org  Mon Oct  3 16:45:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Oct 2011 14:45:28 +0000
Subject: [issue13094] setattr misbehaves when used with lambdas inside for loop
In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za>
Message-ID: <1317653128.63.0.875115518309.issue13094@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sorry.  It is intended behavior.  The lambda 'each' is bound to the local 'each', and by the time the lambda's execute, the value of 'each' is 'baz'.

I'm going to turn this into a doc bug, because while I'm pretty sure this is documented *somewhere*, I don't see it in the programming FAQ, and it should be there.

----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python, r.david.murray
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13094>
_______________________________________

From report at bugs.python.org  Mon Oct  3 16:46:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Oct 2011 14:46:35 +0000
Subject: [issue13094] Need Programming FAQ entry for the behavior of closures
In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za>
Message-ID: <1317653195.47.0.0454031356019.issue13094@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: setattr misbehaves when used with lambdas inside for loop -> Need Programming FAQ entry for the behavior of closures

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13094>
_______________________________________

From report at bugs.python.org  Mon Oct  3 17:03:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Oct 2011 15:03:19 +0000
Subject: [issue13094] Need Programming FAQ entry for the behavior of closures
In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za>
Message-ID: <1317654199.49.0.0212202123252.issue13094@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

To understand better what's going on, try to change the value of 'each' after the 3 prints and then call again the 3 methods: you will see that they now return the new value of each.  This is because the lambdas refer to global 'each' (that at the end of the loop is set to 'baz').
If you do setattr(x, each, lambda each=each: each), the each will be local to the lambda, and it will then work as expected.

An entry in the FAQ would be useful, I thought it was there already but apparently it's not (I'm pretty sure I saw this already somewhere in the doc, but I can't seem to find where).

----------
assignee: docs at python -> 
components: +None -Documentation
nosy: +ezio.melotti
stage: needs patch -> 
type: behavior -> 
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13094>
_______________________________________

From report at bugs.python.org  Mon Oct  3 17:13:33 2011
From: report at bugs.python.org (=?utf-8?b?VG9tw6HFoSBEdm/FmcOhaw==?=)
Date: Mon, 03 Oct 2011 15:13:33 +0000
Subject: [issue13094] Need Programming FAQ entry for the behavior of closures
In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za>
Message-ID: <1317654813.95.0.772062209318.issue13094@psf.upfronthosting.co.za>


Tom?? Dvo??k <dvtomas at gmail.com> added the comment:

Thank you all very much for the super-quick responses. I'm used to smalltalk, so the python variable binding behaviour is unnatural to me, but I guess there must have been some reasons for making it behave this way. 

Ezio, the 
"lambda each=each: each" 
trick works nicely, thanks a lot. But - what does it mean? :) I just don't know how to parse and understand it :-)

Best regards,
  Tom?? Dvo??k

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13094>
_______________________________________

From report at bugs.python.org  Mon Oct  3 17:19:15 2011
From: report at bugs.python.org (Artyom Gavrichenkov)
Date: Mon, 03 Oct 2011 15:19:15 +0000
Subject: [issue13045] socket.getsockopt may require custom buffer contents
In-Reply-To: <1316970740.88.0.976956666008.issue13045@psf.upfronthosting.co.za>
Message-ID: <1317655155.84.0.736571217854.issue13045@psf.upfronthosting.co.za>


Changes by Artyom Gavrichenkov <ximaera at highloadlab.com>:


----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13045>
_______________________________________

From report at bugs.python.org  Mon Oct  3 17:22:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Oct 2011 15:22:44 +0000
Subject: [issue13094] Need Programming FAQ entry for the behavior of closures
In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za>
Message-ID: <1317655364.34.0.784602471719.issue13094@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Maybe with a different name is less confusing: lambda return_value=each: return_value
This copies the value of 'each' in a variable called 'return_value' that is local to the lambda.  Since the copy happens when the lambdas are defined, 'return_value' has then the right value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13094>
_______________________________________

From report at bugs.python.org  Mon Oct  3 18:33:08 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 03 Oct 2011 16:33:08 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1317659588.19.0.256725431039.issue11816@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Oct  3 18:41:08 2011
From: report at bugs.python.org (Artyom Gavrichenkov)
Date: Mon, 03 Oct 2011 16:41:08 +0000
Subject: [issue13045] socket.getsockopt may require custom buffer contents
In-Reply-To: <1316970740.88.0.976956666008.issue13045@psf.upfronthosting.co.za>
Message-ID: <1317660068.61.0.564487931286.issue13045@psf.upfronthosting.co.za>


Changes by Artyom Gavrichenkov <ximaera at highloadlab.com>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13045>
_______________________________________

From report at bugs.python.org  Mon Oct  3 18:48:27 2011
From: report at bugs.python.org (Artyom Gavrichenkov)
Date: Mon, 03 Oct 2011 16:48:27 +0000
Subject: [issue13045] socket.getsockopt may require custom buffer contents
In-Reply-To: <1316970740.88.0.976956666008.issue13045@psf.upfronthosting.co.za>
Message-ID: <1317660507.85.0.606315347557.issue13045@psf.upfronthosting.co.za>


Changes by Artyom Gavrichenkov <ximaera at highloadlab.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13045>
_______________________________________

From report at bugs.python.org  Mon Oct  3 19:04:47 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 03 Oct 2011 17:04:47 +0000
Subject: [issue13045] socket.getsockopt may require custom buffer contents
In-Reply-To: <1316970740.88.0.976956666008.issue13045@psf.upfronthosting.co.za>
Message-ID: <1317661487.13.0.16150929828.issue13045@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Hello,

method:: socket.getsockopt(level, optname[, optarg])

The overloading of the third parameter is confusing: it can already be an integer value or a buffer size, I don't think that adding a third possibility is a good idea. It might be better to add another optional `buffer` argument (and ignore `buflen` if this argument is provided).

Also, it would be nice to have a corresponding unit test: since I doubt this buffer argument is supported by many Unices out there, you can probably reuse a subset of what ipset does (just take care and guard it by @support.requires_linux_version() if applicable).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13045>
_______________________________________

From report at bugs.python.org  Mon Oct  3 19:29:46 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 Oct 2011 17:29:46 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences
	from	Unicode charnames namespace
In-Reply-To: <9072.1317605488@chthon>
Message-ID: <4E89F108.8090301@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> There are no official English titling rules and as you noted,
>> publishers vary. 
> 
> If there aren't any rules, then how come all book and movie titles always
> look the same?  :)

Can we please leave the English language out of this issue?
Else I will ask that Python uses German text-processing rules,
just so that this gets fewer comments :-)

As a point of order, please all try to stick at the issue at hand.
Linguistics discussions or general Unicode discussion have better
places than this bug tracker. I just had to stop reading Tom's
comments as too verbose (which is more difficult since it's in
a foreign language).

----------
title: \N{...} neglects formal aliases and named sequences from Unicode charnames namespace -> \N{...} neglects formal aliases and named sequences from	Unicode charnames namespace

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Oct  3 19:41:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 03 Oct 2011 17:41:07 +0000
Subject: [issue13001] test_socket.testRecvmsgTrunc failure on FreeBSD 7.2
	buildbot
In-Reply-To: <1316270071.04.0.179563462632.issue13001@psf.upfronthosting.co.za>
Message-ID: <E1RAmVl-0003sm-8B@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4378bae6b8dc by Charles-Fran?ois Natali in branch 'default':
Issue #13001: Fix test_socket.testRecvmsgTrunc failure on FreeBSD < 8, which
http://hg.python.org/cpython/rev/4378bae6b8dc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13001>
_______________________________________

From report at bugs.python.org  Mon Oct  3 19:44:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Oct 2011 17:44:44 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences
	from	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1317663884.57.0.332916970151.issue12753@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The patch is pretty much complete, it just needs a review (I left some comments on the review page).
One thing that can be added is some compression for the names of the named sequences.  I'm not sure I can reuse the same compression used for the other names easily.  Does the size of the db really matters?  Are the new names using too much extra space?

----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Oct  3 20:29:28 2011
From: report at bugs.python.org (Artyom Gavrichenkov)
Date: Mon, 03 Oct 2011 18:29:28 +0000
Subject: [issue13045] socket.getsockopt may require custom buffer contents
In-Reply-To: <1316970740.88.0.976956666008.issue13045@psf.upfronthosting.co.za>
Message-ID: <1317666568.73.0.957785734202.issue13045@psf.upfronthosting.co.za>


Artyom Gavrichenkov <ximaera at highloadlab.com> added the comment:

Hi Charles-Fran?ois,

I've attached an update for the previous patch. Now there's no more overloading for the third argument and socket.getsockopt accepts one more optional argument -- a buffer to use as an input to kernel.

I can provide a manual sample script, with getsockopt being used this way, that depends on Linux ipset kernel module being installed and modprobe'd. However, automatic unit test is not that easy to implement. Generally ipset requires certain kernel modules to operate, and we either have to install ipset in order to run a unit test, or to implement some mock Linux kernel module purely for testing and support it against all possible kernel versions. Not to mention that such a test should be carried out by root user only.

By the way, I don't really think that any POSIX-compliant UNIX out there would treat the buffer given to getsockopt in any way different from what Linux does. It is very easy to copy the buffer from user to kernel and back, and it is so inconvenient to prevent kernel from reading it prior to modification, that I bet no one has ever bothered to do this.

----------
Added file: http://bugs.python.org/file23306/getsockopt_buffer_input_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13045>
_______________________________________

From report at bugs.python.org  Mon Oct  3 20:30:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Oct 2011 18:30:50 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1317666650.85.0.486187378965.issue12555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Should the input of OSError be checked?

It could, but pre-PEP it is not, so I assumed it's better to minimize compatibility-breaking changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Mon Oct  3 20:31:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Oct 2011 18:31:56 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1317666716.74.0.563443938608.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file23307/554524a74bbe.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Mon Oct  3 20:32:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Oct 2011 18:32:48 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1317666768.91.0.761296781545.issue12555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch update against latest default. There shouldn't be anything interesting to see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Mon Oct  3 20:39:55 2011
From: report at bugs.python.org (Cal Leeming)
Date: Mon, 03 Oct 2011 18:39:55 +0000
Subject: [issue13095] Support for splitting lists/tuples into chunks
Message-ID: <1317667195.74.0.956951285114.issue13095@psf.upfronthosting.co.za>


New submission from Cal Leeming <cal.leeming at simplicitymedialtd.co.uk>:

After a while of digging around, I noticed that the core libs don't provide an easy way of splitting a list/tuple into chunks - as per the following discussion:

http://www.aspwinhost.com/In-what-way-do-you-split-an-list-into-evenly-sized-chunks-on-Python/

Therefore, I'd like to +1 feature request this.

Any thoughts??

Cal

----------
components: Library (Lib)
messages: 144831
nosy: sleepycal
priority: normal
severity: normal
status: open
title: Support for splitting lists/tuples into chunks
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13095>
_______________________________________

From report at bugs.python.org  Mon Oct  3 20:44:25 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 Oct 2011 18:44:25 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences
	from	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1317667465.84.0.262627039258.issue12753@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch needs to take versioning into account. It seems that NamedSequences where added in 4.1, and NameAliases in 5.0. So for the moment, when using 3.2 (i.e. when self is not NULL), it is fine to lookup neither. Please put an assertion into makeunicodedata that this needs to be reviewed when an old version other than 3.2 needs to be supported.

The size of the DB does matter; there are frequent complaints about it. The named sequences take 20kB on my system; not sure whether that's too much. If you want to reduce the size (and also speedup lookup), you could use private-use characters, like so:
- add the named sequences as PUA characters to the names table of makeunicodename, in the range(P, P+418) (for some P).
- in lookup, check whether the _getcode result is in range(P,P+418). If so, subtract P from the code and use this as an index into _namedsequences.
- add a _getcode wrapper that filters out all private use characters, for regular lookup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Oct  3 20:47:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Oct 2011 18:47:00 +0000
Subject: [issue13095] Support for splitting lists/tuples into chunks
In-Reply-To: <1317667195.74.0.956951285114.issue13095@psf.upfronthosting.co.za>
Message-ID: <1317667620.38.0.47815609184.issue13095@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This sounds like the grouper() recipe of itertools.  You could try to convince Raymond and see if he wants to include it in itertools.

----------
nosy: +ezio.melotti, rhettinger
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13095>
_______________________________________

From report at bugs.python.org  Mon Oct  3 20:56:33 2011
From: report at bugs.python.org (Cal Leeming)
Date: Mon, 03 Oct 2011 18:56:33 +0000
Subject: [issue13095] Support for splitting lists/tuples into chunks
In-Reply-To: <1317667195.74.0.956951285114.issue13095@psf.upfronthosting.co.za>
Message-ID: <1317668193.93.0.970561499463.issue13095@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

Oh - and while we are at it - how about having merge_list() and unique_list() as part of the core too??


def unique_list(seq): # Dave Kirby
    # Order preserving
    seen = set()
    return [x for x in seq if x not in seen and not seen.add(x)]
    
def merge_list(seq):
    merged = []
    for s in seq:
        for x in s:
            merged.append(x)
    return merged

Raymond - any thoughts on these 3 requests???

Cal

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13095>
_______________________________________

From report at bugs.python.org  Mon Oct  3 20:57:14 2011
From: report at bugs.python.org (Amorilia)
Date: Mon, 03 Oct 2011 18:57:14 +0000
Subject: [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1317668234.4.0.377356380025.issue13081@psf.upfronthosting.co.za>


Amorilia <amorilia.gamebox at gmail.com> added the comment:

I'm the author of the application. The tool is written in pure Python, and only uses libraries from stdlib.

It would be really nice to have a simple standalone script to reproduce the crash, however I am still trying to reproduce it myself. So far no success.

----------
nosy: +amorilia

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13081>
_______________________________________

From report at bugs.python.org  Mon Oct  3 20:57:20 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 03 Oct 2011 18:57:20 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1317615350.8.0.846192018045.issue12753@psf.upfronthosting.co.za>
Message-ID: <9892.1317668226@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Ezio Melotti <report at bugs.python.org> wrote
   on Mon, 03 Oct 2011 04:15:51 -0000: 

>> But it still has to happen at compile time, of course, so I don't know
>> what you could do in Python.  Is there any way to change how the compiler
>> behaves even vaguely along these lines?

> I think things like "from __future__ import ..." do something similar,
> but I'm not sure it will work in this case (also because you will have
> to provide the list of aliases somehow).

Ah yes, that's right.  Hm.  I bet then it *would* be possible, just perhaps
a bit of a run-around to get there.  Not a high priority, but interesting.

> less readable than:
> 
> def my_capitalize(s):
>    return s[0].upper() + s[1:].lower()

> You could argue that the first is much more explicit and in a way
> clearer, but overall I think you agree with me that is less readable.

Certainly.

It's a bit like the way bug rate per lines of code is invariant across
programming languages.  When you have more opcodes, it gets harder to
understand because there are more interactions and things to remember.

>> That really isn't right.  A cased character is one with the Unicode "Cased"
>> property, and a lowercase character is one wiht the Unicode "Lowercase"
>> property.  The General Category is actually immaterial here.

> You might want to take a look and possibly add a comment on #12204 about this.

>> I've spent all bloody day trying to model Python's islower, isupper, and istitle
>> functions, but I get all kinds of errors, both in the definitions and in the
>> models of the definitions.

> If by "model" you mean "trying to figure out how they work", it's
> probably easier to look at the implementation (I assume you know
> enough C to understand what they do).  You can find the code for
> str.istitle() at http://hg.python.org/cpython/file/default/Objects/un-
> icodeobject.c#l10358 and the actual implementation of some macros like
> Py_UNICODE_ISTITLE at
> http://hg.python.org/cpython/file/default/Objects/unicodectype.c.

Thanks, that helps immensely.  I'm completely fluent in C.  I've gone 
and built a tags file of your whole v3.2 source tree to help me navigate.

The main underlying problem is that the internal macros are defined in a
way that made sense a long time ago, but no longer do ever since (for
example) the Unicode lowercase property stopped being synonymous with
GC=Ll and started also including all code points with the
Other_Lowercase property as well.

The originating culprit is Tools/unicode/makeunicodedata.py.
It builds your tables only using UnicodeData.txt, which is
not enough.  For example:

    if category in ["Lm", "Lt", "Lu", "Ll", "Lo"]:
	flags |= ALPHA_MASK
    if category == "Ll":
	flags |= LOWER_MASK
    if 'Line_Break' in properties or bidirectional == "B":
	flags |= LINEBREAK_MASK
	linebreaks.append(char)
    if category == "Zs" or bidirectional in ("WS", "B", "S"):
	flags |= SPACE_MASK
	spaces.append(char)
    if category == "Lt":
	flags |= TITLE_MASK
    if category == "Lu":
	flags |= UPPER_MASK

It needs to use DerivedCoreProperties.txt to figure out whether
something is Other_Uppercase, Other_Lowercase, etc. In particular:

    Alphabetic := Lu+Ll+Lt+Lm+Lo + Nl + Other_Alphabetic
    Lowercase  := Ll + Other_Lowercase
    Uppercase  := Ll + Other_Uppercase

This affects a lot of things, but you should be able to just fix it
in Tools/unicode/makeunicodedata.py and have all of them start
working correctly.

You will probably also want to add 

    Py_UCS4 _PyUnicode_IsWord(Py_UCS4 ch)

that uses the UTS#18 Annex C definition, so that you catch marks, too.
That definition is:

    Word := Alphabetic + Mc+Me+Mn + Nd + Pc

where Alphabetic is defined above to include Nl and Other_Alphabetic.

Soemwhat related is stuff like this:

    typedef struct {
	const Py_UCS4 upper;
	const Py_UCS4 lower;
	const Py_UCS4 title;
	const unsigned char decimal;
	const unsigned char digit;
	const unsigned short flags;
    } _PyUnicode_TypeRecord;

There are two different bugs here.  First, you are missing 

	const Py_UCS4 fold;

which is another field from UnicodeData.txt, one that is critical 
for doing case-insensitive matches correctly.

Second, there's also the problem that Py_UCS4 is an int.  That means you
are stuck with just the character-based simple versions of upper-, title-,
lower-, and foldcase.  You need to have fields for the full mappings, which
are now strings (well, int arrays) not single ints.  I'll use ??? for the
int-array type that I don't know:

	const ??? upper_full;
	const ??? lower_full;
	const ??? title_full;
	const ??? fold_full;

You will also need to extend the API from just

    Py_UCS4 _PyUnicode_ToUppercase(Py_UCS4 ch)

to something like

    ??? _PyUnicode_ToUppercase_Full(Py_UCS4 ch)

I don't know what the ??? return type is there, but it's whatever the
upper_full filed in _PyUnicode_TypeRecord would be.

I know that Matthew Barnett has had to cover a bunch of these for his regex
module, including generating his own tables.  It might be possible to
piggy-back on that effort; certainly it would be desirable to try.

> I really don't understand any of these functions.  I'm very sad.  I think they are
> wrong, but maybe I am.  It is extremely confusing.

>> Shall I file a separate bug report?

> If after reading the code and/or the documentation you still think
> they are broken and/or that they can be improved, then you can open
> another issue.

I handn't actually *looked* at capitalize yet, because I stumbled over
these errors in the way-underlying code that necessarily supports it.
The errors in definitions explain a lot of what I was 

Ok, more bugs.  Consider this:

    static 
    int fixcapitalize(PyUnicodeObject *self)
    {
	Py_ssize_t len = self->length;
	Py_UNICODE *s = self->str;
	int status = 0;

	if (len == 0)
	    return 0;
	if (Py_UNICODE_ISLOWER(*s)) {
	    *s = Py_UNICODE_TOUPPER(*s);
	    status = 1;
	}
	s++;
	while (--len > 0) {
	    if (Py_UNICODE_ISUPPER(*s)) {
		*s = Py_UNICODE_TOLOWER(*s);
		status = 1;
	    }
	    s++;
	}
	return status;
    }

There are several bugs there.  First, you have to use the TITLECASE if there
is one, and only use the uppercase if there is no titlecase.  Uppercase
is wrong.

Second, you cannot decide to do the case change only if it starts out as a
certain case.  You have to do it unconditionally, especially since your
tests for whether something is upper or lower are wrong.  For example,
Roman numerals, the iota subscript, the circled letters, and a few other
things all are case-changing but are not themselves Letters in the
GC=Ll/Lu/Lt sense.  Also, there are also cased letters in the GC=Lm
category, which you miss.  Unicode has properties like Cased that you
should be using to determine whether something is cased.  It also have
properties like Changes_When_Uppercased (aka CWU) that tell you whether
something will change.  For example, most of the small capitals are cased
code points that are considered lowercase and which do not change when
uppercase.  However, The LATIN SMALL CAPITAL R (which is a lowercase code
point) actually does have an uppercase mapping.  Strange but true.

Does this help at all?  I have to go to a meeting now.

--tom

----------
title: \N{...} neglects formal aliases and named sequences from	Unicode charnames namespace -> \N{...} neglects formal aliases and named sequences from Unicode charnames namespace

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Oct  3 21:01:04 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 03 Oct 2011 19:01:04 +0000
Subject: [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1317668464.52.0.28107553647.issue13081@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I recently created "minidumper" to write Visual Studio "MiniDump" files of interpreter crashes, but it's currently only available on 3.x. If I port it to 2.x, you could add "import minidumper;minidumper.enable()" to the top of your script, then we could probably get somewhere with it.

An additional example script, possibly including sample data to run through it, would be even better.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13081>
_______________________________________

From report at bugs.python.org  Mon Oct  3 21:12:37 2011
From: report at bugs.python.org (Victor Semionov)
Date: Mon, 03 Oct 2011 19:12:37 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317669157.48.0.434474447977.issue13070@psf.upfronthosting.co.za>


Victor Semionov <vsemionov at gmail.com> added the comment:

Any plans to fix this in the next release?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Mon Oct  3 21:19:40 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 Oct 2011 19:19:40 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences
	from	Unicode charnames namespace
In-Reply-To: <9892.1317668226@chthon>
Message-ID: <4E8A0ACA.7000508@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The main underlying problem is that the internal macros are defined in a
> way that made sense a long time ago, but no longer do ever since (for
> example) the Unicode lowercase property stopped being synonymous with
> GC=Ll and started also including all code points with the
> Other_Lowercase property as well.

Tom: PLEASE focus on one issue at a time. This is about formal
aliases and named sequences, NOT about upper and lower case.
If you want to have a discussion about upper and lower case,
please open a separate issue. There I would explain why I
think your reasoning is flawed (i.e. just because your interpretation
of Unicode differs from Python's implementation doesn't already
make Python's implementation incorrect - just different).

----------
title: \N{...} neglects formal aliases and named sequences from Unicode charnames namespace -> \N{...} neglects formal aliases and named sequences from	Unicode charnames namespace

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Oct  3 22:53:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 03 Oct 2011 20:53:21 +0000
Subject: [issue13001] test_socket.testRecvmsgTrunc failure on FreeBSD 7.2
	buildbot
In-Reply-To: <1316270071.04.0.179563462632.issue13001@psf.upfronthosting.co.za>
Message-ID: <1317675201.52.0.0357782599526.issue13001@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13001>
_______________________________________

From report at bugs.python.org  Mon Oct  3 23:18:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 03 Oct 2011 21:18:06 +0000
Subject: [issue12156] test_multiprocessing.test_notify_all() timeout (1 hour)
	on FreeBSD 7.2
In-Reply-To: <1306147254.92.0.286085135906.issue12156@psf.upfronthosting.co.za>
Message-ID: <1317676686.26.0.639651817903.issue12156@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

test_multiprocessing frequently hangs on FreeBSD < 8 buildbots, and this probably has to do with the limit on the max number of POSIX semaphores:
"""
======================================================================
ERROR: test_notify_all (test.test_multiprocessing.WithProcessesTestCondition)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 777, in test_notify_all
    cond = self.Condition()
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/__init__.py", line 189, in Condition
    return Condition(lock)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/synchronize.py", line 198, in __init__
    self._lock = lock or RLock()
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/synchronize.py", line 172, in __init__
    SemLock.__init__(self, RECURSIVE_MUTEX, 1, 1)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/synchronize.py", line 75, in __init__
    sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue)
OSError: [Errno 23] Too many open files in system
"""

There are probably dangling semaphores, since the test doesn't use that much POSIX semaphores. Either way, we can't do much about it...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12156>
_______________________________________

From report at bugs.python.org  Mon Oct  3 23:25:44 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 03 Oct 2011 21:25:44 +0000
Subject: [issue12210] test_smtplib: intermittent failures on FreeBSD
In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za>
Message-ID: <1317677144.07.0.214175759376.issue12210@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I haven't seen this in a while, so let's assume it's fixed.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12210>
_______________________________________

From report at bugs.python.org  Mon Oct  3 23:32:40 2011
From: report at bugs.python.org (jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal)
Date: Mon, 03 Oct 2011 21:32:40 +0000
Subject: [issue13071] IDLE refuses to open on windows 7
In-Reply-To: <1317341122.37.0.866117748717.issue13071@psf.upfronthosting.co.za>
Message-ID: <1317677560.73.0.136480849626.issue13071@psf.upfronthosting.co.za>


jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal <christopherdarkas at gmail.com> added the comment:

ok i have solved the problem it was the same as issue 4765

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13071>
_______________________________________

From report at bugs.python.org  Mon Oct  3 23:36:57 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 03 Oct 2011 21:36:57 +0000
Subject: [issue13071] IDLE refuses to open on windows 7
In-Reply-To: <1317341122.37.0.866117748717.issue13071@psf.upfronthosting.co.za>
Message-ID: <1317677817.06.0.424674935975.issue13071@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What did you do to solve the problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13071>
_______________________________________

From report at bugs.python.org  Tue Oct  4 00:08:17 2011
From: report at bugs.python.org (Brent Payne)
Date: Mon, 03 Oct 2011 22:08:17 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317679697.41.0.986771333914.issue7689@psf.upfronthosting.co.za>


Changes by Brent Payne <brent.payne at gmail.com>:


----------
nosy: +Brent.Payne

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 00:09:07 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Oct 2011 22:09:07 +0000
Subject: [issue4765] IDLE fails to "Delete Custom Key Set" properly
In-Reply-To: <1230525520.13.0.417394561266.issue4765@psf.upfronthosting.co.za>
Message-ID: <1317679747.31.0.845413080677.issue4765@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Note the config-main.cfg contains all custom configurations and appears if you make any one of them. Mine currently says

[EditorWindow]
font = lucida sans unicode

[General]
autosave = 1

So deleting it is a hack workaround until the bug is fixed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4765>
_______________________________________

From report at bugs.python.org  Tue Oct  4 00:15:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Oct 2011 22:15:19 +0000
Subject: [issue13071] IDLE accepts, then crashes, on invalid key bindings.
In-Reply-To: <1317341122.37.0.866117748717.issue13071@psf.upfronthosting.co.za>
Message-ID: <1317680119.5.0.825119778711.issue13071@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

While this issue and #4765 are about the same effect, with a similar workaround, Amaury has indentified a separate bug in the custom key mechanism. So I retitled it to refer to that bug.

----------
title: IDLE refuses to open on windows 7 -> IDLE accepts, then crashes, on invalid key bindings.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13071>
_______________________________________

From report at bugs.python.org  Tue Oct  4 00:23:35 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 03 Oct 2011 22:23:35 +0000
Subject: [issue13095] Support for splitting lists/tuples into chunks
In-Reply-To: <1317667195.74.0.956951285114.issue13095@psf.upfronthosting.co.za>
Message-ID: <1317680615.59.0.412900633251.issue13095@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

These have been rejected before.  There is always a trade-off in adding tools such as this -- it can take more time to learn and remember them than to write a trivial piece of code to do it yourself.  Another issue is that people tend to disagree on how to handle an odd sized left-over group -- different use cases require different handling.

We're trying to keep the core toolset reasonably small so that python remains simple and learnable.  That raises the threshold for adding new tools.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13095>
_______________________________________

From report at bugs.python.org  Tue Oct  4 01:08:56 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 03 Oct 2011 23:08:56 +0000
Subject: [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1317683336.46.0.903118608795.issue13081@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Without the aforementioned minidump library, you can also kick off the Python interpreter using a debugger (or have a debugger break into an already-running one) [1]. When the crash happens--presumably the debugger will break at this point--you can export the mini dump into a file for us to look at [2].

[1] I like using windbg (http://msdn.microsoft.com/en-us/windows/hardware/gg463009).

[2] It would be something like, `.dump /ma C:\path\to\crash.DMP`

----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13081>
_______________________________________

From report at bugs.python.org  Tue Oct  4 01:09:02 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 03 Oct 2011 23:09:02 +0000
Subject: [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1317683342.64.0.938641159316.issue13081@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13081>
_______________________________________

From report at bugs.python.org  Tue Oct  4 03:14:46 2011
From: report at bugs.python.org (John O'Connor)
Date: Tue, 04 Oct 2011 01:14:46 +0000
Subject: [issue12053] Add prefetch() for Buffered IO (experiment)
In-Reply-To: <1305056245.15.0.0737815347229.issue12053@psf.upfronthosting.co.za>
Message-ID: <1317690886.94.0.997272218868.issue12053@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

Here is an update with the C implementation. I think a working prototype will be helpful before another round on python-dev. 


I'm not sure how to handle unseekable, non-blocking streams where the read returns before `skip` bytes are exhausted. If prefetch() returns 0, then the caller would then have to use tell() to ensure subsequent reads are sane. In other words it seems prefetch() will leave the stream in an unpredictable state. Antoine, what are your thoughts?

----------
Added file: http://bugs.python.org/file23308/prefetch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12053>
_______________________________________

From report at bugs.python.org  Tue Oct  4 05:01:44 2011
From: report at bugs.python.org (Matt Joiner)
Date: Tue, 04 Oct 2011 03:01:44 +0000
Subject: [issue1887] distutils doesn't support out-of-source builds
In-Reply-To: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za>
Message-ID: <1317697304.47.0.459721676277.issue1887@psf.upfronthosting.co.za>


Changes by Matt Joiner <anacrolix at gmail.com>:


----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1887>
_______________________________________

From report at bugs.python.org  Tue Oct  4 05:40:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Oct 2011 03:40:21 +0000
Subject: [issue12881] ctypes: segfault with large structure field names
In-Reply-To: <1314935452.01.0.397268917791.issue12881@psf.upfronthosting.co.za>
Message-ID: <E1RAvrf-0002vr-Rr@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset aa3ebc2dfc15 by Meador Inge in branch '2.7':
Issue #12881: ctypes: Fix segfault with large structure field names.
http://hg.python.org/cpython/rev/aa3ebc2dfc15

New changeset d05350c14e77 by Meador Inge in branch '3.2':
Issue #12881: ctypes: Fix segfault with large structure field names.
http://hg.python.org/cpython/rev/d05350c14e77

New changeset 2eab632864f6 by Meador Inge in branch 'default':
Issue #12881: ctypes: Fix segfault with large structure field names.
http://hg.python.org/cpython/rev/2eab632864f6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12881>
_______________________________________

From report at bugs.python.org  Tue Oct  4 05:47:39 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 04 Oct 2011 03:47:39 +0000
Subject: [issue13096] ctypes: segfault with large POINTER type names
Message-ID: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

Reproducible in 2.7 and tip:

[meadori at motherbrain cpython]$ ./python 
Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct  3 2011, 21:47:04) 
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> T = type('x' * 2 ** 25, (Structure,), {})
>>> p = POINTER(T)
Segmentation fault (core dumped)

----------
components: Extension Modules, ctypes
messages: 144850
nosy: amaury.forgeotdarc, belopolsky, meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: ctypes: segfault with large POINTER type names
type: crash
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13096>
_______________________________________

From report at bugs.python.org  Tue Oct  4 05:51:56 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 04 Oct 2011 03:51:56 +0000
Subject: [issue13096] ctypes: segfault with large POINTER type names
In-Reply-To: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za>
Message-ID: <1317700316.99.0.785254056011.issue13096@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

There is similar crasher to this one that can be reproduced like:

[meadori at motherbrain cpython]$ ./python 
Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct  3 2011, 21:47:04) 
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> p = POINTER('x' * 2 ** 25)
Segmentation fault (core dumped)

It should be fixed as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13096>
_______________________________________

From report at bugs.python.org  Tue Oct  4 05:57:17 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 04 Oct 2011 03:57:17 +0000
Subject: [issue13097] ctypes: segfault with large number of callback arguments
Message-ID: <1317700637.71.0.186696346618.issue13097@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

Reproducible in 2.7 and tip:

[meadori at motherbrain cpython]$ ./python 
Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct  3 2011, 21:47:04) 
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> NARGS = 2 ** 20
>>> proto = CFUNCTYPE(None, *(c_int,) * NARGS)
>>> def func(*args):
...    return (1, "abc", None)
... 
>>> cb = proto(func)
>>> cb(*(1,) * NARGS)
Segmentation fault (core dumped)

----------
components: ctypes
messages: 144852
nosy: amaury.forgeotdarc, belopolsky, meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: ctypes: segfault with large number of callback arguments
type: crash
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13097>
_______________________________________

From report at bugs.python.org  Tue Oct  4 05:58:14 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 04 Oct 2011 03:58:14 +0000
Subject: [issue12881] ctypes: segfault with large structure field names
In-Reply-To: <1314935452.01.0.397268917791.issue12881@psf.upfronthosting.co.za>
Message-ID: <1317700694.67.0.00274053256914.issue12881@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Fixed.  Opened issue13096 and issue13097 for the other crashers.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12881>
_______________________________________

From report at bugs.python.org  Tue Oct  4 06:21:34 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 04 Oct 2011 04:21:34 +0000
Subject: [issue12880] ctypes: clearly document how structure bit fields are
	allocated
In-Reply-To: <1317403151.53.0.993055557363.issue12880@psf.upfronthosting.co.za>
Message-ID: <CAK1Qoor_ZD-9sdVJVBb-wN=xshbZCD_ri4t8cH7nME3=GbT4DA@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Fri, Sep 30, 2011 at 12:19 PM, Vlad Riscutia <report at bugs.python.org> wrote:

> I believe this is the better thing to do rather than detailing how GCC and MSVC allocated their bitfields because that would just
> encourage people to use this feature incorrectly.

So clearly documenting how a feature works will cause people to use
the feature incorrectly?  I think not.  In any case, I agree that
documenting the low-level specifics of each compiler's algorithm is too much.

> Most bugs opened on bit fields are because people are toying with the underlying buffer and get other results than what they expect.

The issues that I have looked at (issue6069, issue11920, and
issue11920) all involve fundamental misunderstandings of *how* the
structure layout is determined.  I don't know if I would generalize
these misunderstanding as "toying with the underlying buffer".  Some
times people need to know the exact layout for proper C interop.  In
some of the bugs reported folks are casting buffers in an attempt
to discover the structure layout since it is not clearly documented.

The general content of your patch seems reasonable.  I will provide
more specific comments shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12880>
_______________________________________

From report at bugs.python.org  Tue Oct  4 06:49:47 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 04 Oct 2011 04:49:47 +0000
Subject: [issue12880] ctypes: clearly document how structure bit fields are
	allocated
In-Reply-To: <1314930851.91.0.112444630543.issue12880@psf.upfronthosting.co.za>
Message-ID: <1317703787.61.0.662563806056.issue12880@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Added some comments in rietveld.  P.S. watch out for trailing whitespace
when writing patches.  Use 'make patchcheck' to help find bad whitespace
formatting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12880>
_______________________________________

From report at bugs.python.org  Tue Oct  4 07:42:03 2011
From: report at bugs.python.org (Lance Hepler)
Date: Tue, 04 Oct 2011 05:42:03 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317706923.08.0.157657135549.issue7689@psf.upfronthosting.co.za>


Lance Hepler <nlhepler at gmail.com> added the comment:

Hello all, sorry to be a bother, but what's the progress on this issue? I have a codebase that requires resolution of this issue to enable multiprocessing. What are the remaining outstanding problems herein preventing the attached patches from being merged?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 08:04:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 06:04:23 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317708263.34.0.612597595218.issue7689@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+    def __eq__(self, other):
+        r = (type(self) == type(other))
+        if r:
+            return r

I think this should be "if not r".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 08:57:21 2011
From: report at bugs.python.org (Craig Citro)
Date: Tue, 04 Oct 2011 06:57:21 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317711441.65.0.305999199855.issue7689@psf.upfronthosting.co.za>


Craig Citro <craigcitro at gmail.com> added the comment:

Antoine -- why do you want to switch "if r" for "if not r"? 

If we did, the test would just confirm that the unpicked object was of the same type as the original; if we were going to do that, we might as well just replace the whole `__cmp__` function with just `return cmp(type(self), type(other))`. On the flipside, I could see an argument for adding *more* content to the test, but that seemed like overkill.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 09:03:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 07:03:05 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317711785.67.0.671613891867.issue7689@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Craig: I'm talking about the __eq__ version (durban's patch). The __cmp__ version is probably fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 09:13:12 2011
From: report at bugs.python.org (Craig Citro)
Date: Tue, 04 Oct 2011 07:13:12 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317712392.73.0.349808009542.issue7689@psf.upfronthosting.co.za>


Craig Citro <craigcitro at gmail.com> added the comment:

Antoine -- ah, that makes sense. Is that the only blocker? I've let this patch rot on the vine a long time; if so, I'll happily switch `__eq__` back to `__cmp__` and re-post if it'll get submitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 09:14:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Oct 2011 07:14:50 +0000
Subject: [issue12156] test_multiprocessing.test_notify_all() timeout (1 hour)
	on FreeBSD 7.2
In-Reply-To: <1306147254.92.0.286085135906.issue12156@psf.upfronthosting.co.za>
Message-ID: <1317712490.61.0.26671581503.issue12156@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> "OSError: [Errno 23] Too many open files in system"

Yes, see issue #10348.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12156>
_______________________________________

From report at bugs.python.org  Tue Oct  4 09:25:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 07:25:11 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317713111.47.0.747778371133.issue7689@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

No need, I'll do it myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 09:34:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Oct 2011 07:34:56 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <E1RAzWg-0003Jh-KM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 760ac320fa3d by Antoine Pitrou in branch '3.2':
Issue #7689: Allow pickling of dynamically created classes when their
http://hg.python.org/cpython/rev/760ac320fa3d

New changeset 46c026a5ccb9 by Antoine Pitrou in branch 'default':
Issue #7689: Allow pickling of dynamically created classes when their
http://hg.python.org/cpython/rev/46c026a5ccb9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 09:39:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Oct 2011 07:39:15 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <E1RAzar-0003fs-CX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 64053bd79590 by Antoine Pitrou in branch '2.7':
Issue #7689: Allow pickling of dynamically created classes when their
http://hg.python.org/cpython/rev/64053bd79590

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 09:40:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 07:40:55 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317714055.24.0.599683161763.issue7689@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is fixed now, thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 10:12:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 08:12:37 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317715957.46.0.42408983329.issue6715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Based on Amaury's report, I would suggest going forward integrating the xz module for configure-based systems, and letting someone else handle Windows integration later if a solution is found.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct  4 11:52:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 09:52:30 +0000
Subject: [issue13098] the struct module should support storage for size_t /
	Py_ssize_t C types
Message-ID: <1317721950.11.0.748294685734.issue13098@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Title says it all.

----------
components: Library (Lib)
messages: 144867
nosy: mark.dickinson, meador.inge, pitrou, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: the struct module should support storage for size_t / Py_ssize_t C types
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13098>
_______________________________________

From report at bugs.python.org  Tue Oct  4 12:33:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Oct 2011 10:33:02 +0000
Subject: [issue13087] C BufferedReader seek() is inconsistent with
	UnsupportedOperation for unseekable streams
In-Reply-To: <1317508369.4.0.585699022019.issue13087@psf.upfronthosting.co.za>
Message-ID: <E1RB2J2-0000is-K2@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d287f0654349 by Antoine Pitrou in branch '3.2':
Issue #13087: BufferedReader.seek() now always raises UnsupportedOperation
http://hg.python.org/cpython/rev/d287f0654349

New changeset 0cf38407a3a2 by Antoine Pitrou in branch 'default':
Issue #13087: BufferedReader.seek() now always raises UnsupportedOperation
http://hg.python.org/cpython/rev/0cf38407a3a2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13087>
_______________________________________

From report at bugs.python.org  Tue Oct  4 12:37:14 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Tue, 04 Oct 2011 10:37:14 +0000
Subject: [issue12876] Make Test Error : ImportError: No module named _sha256
In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za>
Message-ID: <1317724634.39.0.446895549236.issue12876@psf.upfronthosting.co.za>


Wong Wah Meng <r32813 at freescale.com> added the comment:

Hello there,

I am encountering more modules/commands that uses the harslib that needs _sha256. I still haven't found a solution. Can anyone shed some lights here whether or not this is related to the way I "include" and "link" the library, or is that the _sha256 is not found on the server though I already have the server installed with the latest OpenSSL software? Thanks in advance for any reply, and I appreciate your input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12876>
_______________________________________

From report at bugs.python.org  Tue Oct  4 12:39:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 10:39:18 +0000
Subject: [issue13087] C BufferedReader seek() is inconsistent with
	UnsupportedOperation for unseekable streams
In-Reply-To: <1317508369.4.0.585699022019.issue13087@psf.upfronthosting.co.za>
Message-ID: <1317724758.38.0.38099691856.issue13087@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed, thanks!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13087>
_______________________________________

From report at bugs.python.org  Tue Oct  4 12:40:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 10:40:42 +0000
Subject: [issue12807] Optimization/refactoring for {bytearray, bytes,
	unicode}.strip()
In-Reply-To: <1317508893.41.0.642593920744.issue12807@psf.upfronthosting.co.za>
Message-ID: <1317724630.3784.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The patch no longer applies cleanly. Is there enough interest in this to justify rebasing?

Yes, I think it's worth it.

----------
title: Optimization/refactoring for {bytearray,bytes,unicode}.strip() -> Optimization/refactoring for {bytearray, bytes, unicode}.strip()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12807>
_______________________________________

From report at bugs.python.org  Tue Oct  4 12:42:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 10:42:14 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317491223.79.0.275640510789.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317724722.3784.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Also, is it ok to just return NULL or should the error state also be
> > set?
> 
> Well, I'm not sure, that why I made you and Amaury noisy :-)
> AFAICT, this is the only case where _check_closed can encounter a NULL
> self->writer.

Probably. OTOH, not setting the error state when returning NULL is
usually an error (and can result in difficult-to-debug problems), so
let's stay on the safe side.

> Furthermore, I'm not sure about what kind of error would make sense here.

RuntimeError perhaps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Tue Oct  4 12:46:39 2011
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 04 Oct 2011 10:46:39 +0000
Subject: [issue13099] Sqlite3 & turkish locale
Message-ID: <1317725199.69.0.486458552577.issue13099@psf.upfronthosting.co.za>


New submission from Thomas Kluyver <takowl at gmail.com>:

When using sqlite3 with the Turkish locale, cursor.lastrowid is not accessible after an insert statement if "INSERT" is upper case.

I believe that the cause is that the detect_statement_kind function [1] calls the locale-dependent C function tolower(). The Turkish locale specifies a different case mapping for I (to a dotless lowercase i: ?), so it's not recognised as an insert statement, which looks like it will cause the transaction to be committed immediately.

See also the discussion on issue 1813 [2], and a Redhat bug with a test case for this [3].


[1] http://hg.python.org/cpython/file/c4b6d9312da1/Modules/_sqlite/cursor.c#l41
[2] http://bugs.python.org/issue1813
[3] https://bugzilla.redhat.com/show_bug.cgi?id=720209

----------
components: Extension Modules
messages: 144873
nosy: takluyver
priority: normal
severity: normal
status: open
title: Sqlite3 & turkish locale
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13099>
_______________________________________

From report at bugs.python.org  Tue Oct  4 12:55:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 10:55:43 +0000
Subject: [issue13063] test_concurrent_futures failures on Windows:
	IOError('[Errno 232] The pipe is being closed') on _send_bytes()
In-Reply-To: <1317323234.29.0.73593324718.issue13063@psf.upfronthosting.co.za>
Message-ID: <1317725743.29.0.85105754409.issue13063@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the solution would be to map ERROR_NO_DATA (232 - "The pipe is being closed") to EPIPE. Attached patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file23309/error_no_data.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13063>
_______________________________________

From report at bugs.python.org  Tue Oct  4 12:56:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 10:56:25 +0000
Subject: [issue13063] test_concurrent_futures failures on Windows:
	IOError('[Errno 232] The pipe is being closed') on _send_bytes()
In-Reply-To: <1317323234.29.0.73593324718.issue13063@psf.upfronthosting.co.za>
Message-ID: <1317725785.44.0.811058233234.issue13063@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Tests
nosy: +amaury.forgeotdarc
stage:  -> patch review
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13063>
_______________________________________

From report at bugs.python.org  Tue Oct  4 13:00:10 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Oct 2011 11:00:10 +0000
Subject: [issue13098] the struct module should support storage for size_t /
	Py_ssize_t C types
In-Reply-To: <1317721950.11.0.748294685734.issue13098@psf.upfronthosting.co.za>
Message-ID: <1317726010.95.0.659499145266.issue13098@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See issue #3163.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13098>
_______________________________________

From report at bugs.python.org  Tue Oct  4 13:07:03 2011
From: report at bugs.python.org (Victor Semionov)
Date: Tue, 04 Oct 2011 11:07:03 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317726423.54.0.203502621213.issue13070@psf.upfronthosting.co.za>


Victor Semionov <vsemionov at gmail.com> added the comment:

> Probably. OTOH, not setting the error state when returning NULL is
> usually an error (and can result in difficult-to-debug problems), so
> let's stay on the safe side.
> 
> > Furthermore, I'm not sure about what kind of error would make sense here.
> 
> RuntimeError perhaps.

Does that mean that an application will see a Python exception?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Tue Oct  4 13:19:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 04 Oct 2011 11:19:33 +0000
Subject: [issue13099] Sqlite3 & turkish locale
In-Reply-To: <1317725199.69.0.486458552577.issue13099@psf.upfronthosting.co.za>
Message-ID: <1317727173.6.0.887209522737.issue13099@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13099>
_______________________________________

From report at bugs.python.org  Tue Oct  4 13:32:50 2011
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 04 Oct 2011 11:32:50 +0000
Subject: [issue13099] Sqlite3 & turkish locale
In-Reply-To: <1317725199.69.0.486458552577.issue13099@psf.upfronthosting.co.za>
Message-ID: <1317727970.85.0.819713692309.issue13099@psf.upfronthosting.co.za>


Thomas Kluyver <takowl at gmail.com> added the comment:

What form does the test need to be in? There's a script at the redhat bug I linked that demonstrates the issue. Do I need to turn it into a function? A patch for the existing test suite?

----------
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13099>
_______________________________________

From report at bugs.python.org  Tue Oct  4 13:35:11 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 04 Oct 2011 11:35:11 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317728111.84.0.0174860160427.issue13070@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

An "unraisable exception" warning will be displayed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Tue Oct  4 13:35:51 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 04 Oct 2011 11:35:51 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317728151.55.0.216157545721.issue13070@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Probably. OTOH, not setting the error state when returning NULL is
> usually an error (and can result in difficult-to-debug problems), so
> let's stay on the safe side.

> RuntimeError perhaps.

OK, I'll update the patch accordingly.

> Does that mean that an application will see a Python exception?

No, the finalization code explicitly clears any exception set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Tue Oct  4 13:40:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 04 Oct 2011 11:40:54 +0000
Subject: [issue13099] Sqlite3 & turkish locale
In-Reply-To: <1317725199.69.0.486458552577.issue13099@psf.upfronthosting.co.za>
Message-ID: <1317728454.2.0.60189687819.issue13099@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

A patch against Lib/sqlite3/test/regression.py would be nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13099>
_______________________________________

From report at bugs.python.org  Tue Oct  4 13:41:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Oct 2011 11:41:46 +0000
Subject: [issue13099] Sqlite3 & turkish locale
In-Reply-To: <1317725199.69.0.486458552577.issue13099@psf.upfronthosting.co.za>
Message-ID: <E1RB3NZ-00069N-4S@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 469555867244 by Antoine Pitrou in branch '3.2':
Issue #13099: Fix sqlite3.Cursor.lastrowid under a Turkish locale.
http://hg.python.org/cpython/rev/469555867244

New changeset 652e2dacbf4b by Antoine Pitrou in branch 'default':
Issue #13099: Fix sqlite3.Cursor.lastrowid under a Turkish locale.
http://hg.python.org/cpython/rev/652e2dacbf4b

New changeset 89713606b654 by Antoine Pitrou in branch '2.7':
Issue #13099: Fix sqlite3.Cursor.lastrowid under a Turkish locale.
http://hg.python.org/cpython/rev/89713606b654

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13099>
_______________________________________

From report at bugs.python.org  Tue Oct  4 13:42:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 11:42:17 +0000
Subject: [issue13099] Sqlite3 & turkish locale
In-Reply-To: <1317725199.69.0.486458552577.issue13099@psf.upfronthosting.co.za>
Message-ID: <1317728537.85.0.510696997906.issue13099@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed, thank you.

----------
nosy: +pitrou
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13099>
_______________________________________

From report at bugs.python.org  Tue Oct  4 13:45:19 2011
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 04 Oct 2011 11:45:19 +0000
Subject: [issue13099] Sqlite3 & turkish locale
In-Reply-To: <1317725199.69.0.486458552577.issue13099@psf.upfronthosting.co.za>
Message-ID: <1317728719.71.0.19420461483.issue13099@psf.upfronthosting.co.za>


Thomas Kluyver <takowl at gmail.com> added the comment:

Thanks, Antoine. Should I still try to write a regression test for it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13099>
_______________________________________

From report at bugs.python.org  Tue Oct  4 13:56:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 11:56:05 +0000
Subject: [issue13099] Sqlite3 & turkish locale
In-Reply-To: <1317728719.71.0.19420461483.issue13099@psf.upfronthosting.co.za>
Message-ID: <1317729152.3784.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Thanks, Antoine. Should I still try to write a regression test for it?

I've had issues writing regression tests for other Turkish
locale-related failures (namely, there are other bugs in some glibcs
that could cause the test to fail anyway). I'm not sure it's worth it
here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13099>
_______________________________________

From report at bugs.python.org  Tue Oct  4 14:08:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 12:08:00 +0000
Subject: [issue13098] the struct module should support storage for size_t /
	Py_ssize_t C types
In-Reply-To: <1317721950.11.0.748294685734.issue13098@psf.upfronthosting.co.za>
Message-ID: <1317730080.63.0.0483052657804.issue13098@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> module struct support for ssize_t and size_t

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13098>
_______________________________________

From report at bugs.python.org  Tue Oct  4 14:08:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 12:08:27 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317730107.96.0.330061637666.issue3163@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

#3163 is a duplicate.

----------
nosy: +pitrou
priority: low -> normal
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Tue Oct  4 14:08:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 12:08:50 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317730130.0.0.617855999608.issue3163@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ooops, I meant #13098.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Tue Oct  4 14:21:09 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 04 Oct 2011 12:21:09 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317730869.69.0.846288828958.issue3163@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Tue Oct  4 14:37:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Oct 2011 12:37:46 +0000
Subject: [issue13063] test_concurrent_futures failures on Windows:
	IOError('[Errno 232] The pipe is being closed') on _send_bytes()
In-Reply-To: <1317323234.29.0.73593324718.issue13063@psf.upfronthosting.co.za>
Message-ID: <1317731866.31.0.583204642071.issue13063@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Attached patch.

Could you please explain your change in generrmap.c in a comment? For example, just add a reference to this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13063>
_______________________________________

From report at bugs.python.org  Tue Oct  4 14:41:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 12:41:28 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317732088.5.0.945349865438.issue3163@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
Added file: http://bugs.python.org/file23310/struct_nn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Tue Oct  4 15:03:14 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 04 Oct 2011 13:03:14 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1317733394.1.0.349233272923.issue12326@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I have a better idea... Why don't we change the "linux2" string into just "linux". That way we will never run into this kind of issue, even in the future when Linux kernel version 4 is going to exist. Any thoughts on this?

----------
nosy: +Retro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Oct  4 16:24:54 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 04 Oct 2011 14:24:54 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1317733394.1.0.349233272923.issue12326@psf.upfronthosting.co.za>
Message-ID: <20111004102446.1218c227@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Oct 04, 2011, at 01:03 PM, Bo?tjan Mejak wrote:

>I have a better idea... Why don't we change the "linux2" string into just
>"linux". That way we will never run into this kind of issue, even in the
>future when Linux kernel version 4 is going to exist. Any thoughts on this?

Python 3.3 already sets sys.platform to 'linux'.  It can't be done for older
versions due to backward compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Oct  4 16:26:37 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 04 Oct 2011 14:26:37 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317738397.63.0.922330981396.issue3163@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Mostly LGTM.  I have a few comments in rietveld.

----------
nosy: +meador.inge
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Tue Oct  4 16:34:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 14:34:13 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317738853.04.0.924661648783.issue3163@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks. I have answered one of your comments, and here is a new patch.

----------
Added file: http://bugs.python.org/file23311/struct_nn2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Tue Oct  4 16:54:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 14:54:44 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317740084.86.0.513812335462.issue3163@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch with cosmetic doc fix.

----------
Added file: http://bugs.python.org/file23312/struct_nn3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Tue Oct  4 17:21:46 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Tue, 04 Oct 2011 15:21:46 +0000
Subject: [issue12880] ctypes: clearly document how structure bit fields are
	allocated
In-Reply-To: <1314930851.91.0.112444630543.issue12880@psf.upfronthosting.co.za>
Message-ID: <1317741706.31.0.492233657134.issue12880@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Thanks for the "make patchcheck" tip, I didn't know about that. I will update the patch soon.

In the mean time, I want to point out a couple of things:
First, I'm saying "toying with the underlying buffer" because none of the bugs are actual issues of the form "I created this bitfield structure with Python, passed it to C function but C structure was different". That would be a bitfield bug. All of these bugs are people setting raw memory to some bytes, then looking at bitfield members and not seeing what they expect. 

Since this is platform dependent, they shouldn't worry about the raw memory as long as C interop works fine. Bitfield layout is complex as it involves both allocation algorithm and structure packing and same Python code will work differently on Windows and Unix.

My point is that documenting all this low-level stuff will encourage people to work with the raw memory which will open the door for other issues. I believe it would be better to encourage users to stick to declaring members and accessing them by name as raw memory WILL be different for the same code on different OSes.

Second, one of your review comments is: "GCC is used for most Unix systems and Microsoft VC++ is used on Windows.". This is not how ctypes works. Ctypes implements the bitfield allocation algorithm itself, it doesn't use the compiler with which it is built. Basically it says #ifdef WIN32 - allocate like VC++ - #else - allocate like GCC. So it doesn't really matter with which compiler you are building Python. It will still do GCC style allocation on Solaris.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12880>
_______________________________________

From report at bugs.python.org  Tue Oct  4 17:30:13 2011
From: report at bugs.python.org (Oren Held)
Date: Tue, 04 Oct 2011 15:30:13 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1317742213.38.0.423272429033.issue9035@psf.upfronthosting.co.za>


Oren Held <oren at held.org.il> added the comment:

Anything wrong with the following simple approach? (e.g. is it bad to depend on win32file?)

def win_ismount(path):
  import win32file
  volume_path = win32file.GetVolumePathName(path)
  return volume_path == path # May have to ignore a trailing backslash

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Tue Oct  4 17:33:30 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 04 Oct 2011 15:33:30 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1317742410.82.0.629122944017.issue9035@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

We can't depend on stuff from pywin32, but we could expose GetVolumePathName ourselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Tue Oct  4 18:06:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Oct 2011 16:06:24 +0000
Subject: [issue13054] sys.maxunicode value after PEP-393
In-Reply-To: <1317224855.38.0.863349241023.issue13054@psf.upfronthosting.co.za>
Message-ID: <E1RB7Vf-0007yR-Ca@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f39b26ca7f3d by Ezio Melotti in branch 'default':
#13054: fix usage of sys.maxunicode after PEP-393.
http://hg.python.org/cpython/rev/f39b26ca7f3d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13054>
_______________________________________

From report at bugs.python.org  Tue Oct  4 18:13:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 04 Oct 2011 16:13:23 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317744803.94.0.364164577652.issue6715@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23300/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct  4 18:17:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 04 Oct 2011 16:17:08 +0000
Subject: [issue12804] "make test" fails on systems without internet access
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <1317745028.93.0.258450218551.issue12804@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Actually, the skip system is already supposed to work for that if used
> properly (see test.support.transient_internet()). However, perhaps it
> actually doesn't work in all situations.

It?s better than that: nearly all tests requiring network access use skips, it?s only a few modules like test_urllib*net that fails instead of skipping (certainly because it relied on the urlfetch resource being disabled by default).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Tue Oct  4 18:35:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 04 Oct 2011 16:35:36 +0000
Subject: [issue13055] Distutils tries to handle null versions but fails
In-Reply-To: <1317238322.67.0.925527851228.issue13055@psf.upfronthosting.co.za>
Message-ID: <1317746136.32.0.51452952004.issue13055@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, will fix it.

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis
versions: +3rd party, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13055>
_______________________________________

From report at bugs.python.org  Tue Oct  4 18:53:09 2011
From: report at bugs.python.org (Brent Payne)
Date: Tue, 04 Oct 2011 16:53:09 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317747189.49.0.990398670241.issue7689@psf.upfronthosting.co.za>


Brent Payne <brent.payne at gmail.com> added the comment:

will the 2.7 patch also be incorporated into a 2.7 release?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 18:56:45 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Oct 2011 16:56:45 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1316207701.26.0.62836662317.issue6715@psf.upfronthosting.co.za>
Message-ID: <4E8B3ACA.4020309@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> - liblzma can't be compiled by Visual Studio: too many C99 isms,
> mostly variables declared in the middle of a block.  It's doable for
> sure, but it's a lot of work.

I'd be in favor of doing so, and then feeding patches upstream.
Hopefully, eventually, the code would compile out of the box on VS.

> - liblzma is normally compiled with mingw, but we have to be sure
> that is uses the correct MSCRT C runtime, and what about debug
> builds?

In principle, it's not necessary to use the same CRT, as long as
we aren't passing CRT objects across DLL boundaries (memory
blocks managed by malloc/free would be candidates). I haven't reviewed
the module to find out whether the liblzma interface involves CRT
objects.

> - The way recommended by XZ is to use a precompiled liblzma.dll; Then
> it should be easy to build an extension module, but its would be the
> first time that we distribute an extension module which needs a
> non-system DLL.  Is it enough to copy it next to _lzma.pyd?  Is there
> some work to do in the installer?

It wouldn't actually be the first time. We also ship Tcl DLLs. But
it's a pain, so it would be much better if the sources were actually
referenced in the VS project - so we would not need a library at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:00:01 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Oct 2011 17:00:01 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1317715957.46.0.42408983329.issue6715@psf.upfronthosting.co.za>
Message-ID: <4E8B3B8F.4020508@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Based on Amaury's report, I would suggest going forward integrating
> the xz module for configure-based systems, and letting someone else
> handle Windows integration later if a solution is found.

-1000. I feel quite strongly that this should not be added unless there
is also support in the Windows build process for it. I'll see what I
can do, but it may take some time - until then, I urge to stall this
issue, i.e. not proceed with checking it in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:05:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 17:05:49 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317747949.83.0.631993272959.issue7689@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, it will.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:08:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 17:08:03 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <4E8B3B8F.4020508@v.loewis.de>
Message-ID: <1317747866.3784.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Based on Amaury's report, I would suggest going forward integrating
> > the xz module for configure-based systems, and letting someone else
> > handle Windows integration later if a solution is found.
> 
> -1000. I feel quite strongly that this should not be added unless there
> is also support in the Windows build process for it.

Why?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:11:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Oct 2011 17:11:58 +0000
Subject: [issue13100] sre_compile._optimize_unicode() needs a cleanup
Message-ID: <1317748318.81.0.992039803801.issue13100@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following comment is wrong, 

    except IndexError:
        # non-BMP characters; XXX now they should work
        return charset

sys.maxunicode != 65535 is now always true in Python 3.3

        if sys.maxunicode != 65535:
            # XXX: negation does not work with big charsets
            # XXX2: now they should work, but removing this will make the
            # charmap 17 times bigger
            return charset

See the related commit: f39b26ca7f3d (from issue #13054).

----------
components: Library (Lib), Regular Expressions, Unicode
messages: 144905
nosy: ezio.melotti, haypo, pitrou
priority: normal
severity: normal
status: open
title: sre_compile._optimize_unicode() needs a cleanup
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13100>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:15:31 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 04 Oct 2011 17:15:31 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1317748531.68.0.113143780359.issue7689@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Specifically, 2.7.3. A date for that has not yet been set, but somewhere in the December/January time frame is likely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:17:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Oct 2011 17:17:52 +0000
Subject: [issue11956] 3.3 : test_import.py causes 'make test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <E1RB8co-0006FV-Pt@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7697223df6df by Charles-Fran?ois Natali in branch '3.2':
Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as
http://hg.python.org/cpython/rev/7697223df6df

New changeset 58870fe9a604 by Charles-Fran?ois Natali in branch 'default':
Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as
http://hg.python.org/cpython/rev/58870fe9a604

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11956>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:30:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 04 Oct 2011 17:30:57 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1317749457.07.0.53451424878.issue10348@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

-1
IMHO, implementing SysV semaphores would be a step backwards, plus the API is a real pain.
I think there's no reason to complicate the code to accomodate such corner cases, especially since the systems that don't support POSIX semaphores will eventually die out...

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10348>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:31:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 17:31:50 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1317749510.49.0.399656352609.issue10348@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed with Charles-Fran?ois.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10348>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:43:37 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Oct 2011 17:43:37 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1317747866.3784.6.camel@localhost.localdomain>
Message-ID: <4E8B45C7.10708@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 04.10.11 19:08, schrieb Antoine Pitrou:
>
> Antoine Pitrou<pitrou at free.fr>  added the comment:
>
>>> Based on Amaury's report, I would suggest going forward integrating
>>> the xz module for configure-based systems, and letting someone else
>>> handle Windows integration later if a solution is found.
>>
>> -1000. I feel quite strongly that this should not be added unless there
>> is also support in the Windows build process for it.
>
> Why?

This module is only useful in the standard library if it is available
on all systems. If it is not available on all systems, it may just as
well be available from PyPI only. Now, as it needs to be available on
Windows, I want to see the actual Windows support, else we would have
to block the release until Windows support is available, possibly then
reverting the module because no Windows support is forthcoming. So it's
easier not to commit in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:44:30 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 04 Oct 2011 17:44:30 +0000
Subject: [issue12880] ctypes: clearly document how structure bit fields are
	allocated
In-Reply-To: <1317741706.31.0.492233657134.issue12880@psf.upfronthosting.co.za>
Message-ID: <CAK1QoopLaZrkokwQwM91Cei9PNryOaFdJ3dEV_077rVdO00mew@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Tue, Oct 4, 2011 at 10:21 AM, Vlad Riscutia <report at bugs.python.org> wrote:

> First, I'm saying "toying with the underlying buffer" because none of the bugs are actual issues of the form "I created this bitfield
> structure with Python, passed it to C function but C structure was different". That would be a bitfield bug. All of these bugs are people
> setting raw memory to some bytes, then looking at bitfield members and not seeing what they expect.

Please qualify "all" instead of generalizing.  I can point to two
issues (issue11990 "I'm generating python code from real c code.",
issue12945 "We have raw data packages from some tools. These packages
contains bitfields, arrays, simple data and so on.") where C
code or raw data was, in fact, involved and the reporters just don't
understand what layout algorithm is being used.  They may not need
to know the specifics of the algorithm, but they *do* need to know if
it matches the compiler they are using to do interop or the one
that generated the raw data.

The reason that we are seeing folks cast raw memory into a cyptes
bitfield structure is because they do not understand how the structure
layout algorithm works and are trying to figure it out via these
examples.

> Second, one of your review comments is: "GCC is used for most Unix systems and Microsoft VC++ is used on Windows.". This is not
> how ctypes works. Ctypes implements the bitfield allocation algorithm itself, it doesn't use the compiler with which it is built. Basically
> it says #ifdef WIN32 - allocate like VC++ - #else - allocate like GCC. So it doesn't really matter with which compiler you are building
> Python. It will still do GCC style allocation on Solaris.

I understand how it works.  This quote is taken somewhat out of
context as the preceding sentence is important.  Perhaps saying GCC-
style and VC++-style would have been more clear.  The reason that I
mentioned the compiler used to build Python is that it is an easy
reference point and more times than not the bitfield allocation and
layout *do* match that of the compiler used to build the interpreter.
Anyway, I am fine with dropping the "used to build the Python
interpreter" and going with something similar to what you originally
had.

Also, in general, the compiler used to build the ctypes extension
*does* matter.  Look in 'cfield.c' where all of the native alignments
are
computed at compile time.  These alignments affect the structure
layout and are defined by the compiler building the ctypes extension.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12880>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:46:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 17:46:23 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <4E8B45C7.10708@v.loewis.de>
Message-ID: <1317750171.3784.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This module is only useful in the standard library if it is available
> on all systems.

Not really. xz is becoming a defacto standard under Linux (and perhaps
other free Unices) while I guess it is marginal under Windows. 
We have other system-specific functionality, and nobody sees it as a bad
thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:46:36 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 04 Oct 2011 17:46:36 +0000
Subject: [issue12880] ctypes: clearly document how structure bit fields are
	allocated
In-Reply-To: <1314930851.91.0.112444630543.issue12880@psf.upfronthosting.co.za>
Message-ID: <1317750396.47.0.0335003197932.issue12880@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> Look in 'cfield.c' where all of the native alignments

Well, not *all* the native alignments, but many of them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12880>
_______________________________________

From report at bugs.python.org  Tue Oct  4 19:47:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 04 Oct 2011 17:47:27 +0000
Subject: [issue13054] sys.maxunicode value after PEP-393
In-Reply-To: <1317224855.38.0.863349241023.issue13054@psf.upfronthosting.co.za>
Message-ID: <1317750447.26.0.485302388496.issue13054@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The buildbot seems happy, so I'm closing this.
Antoine already took care of test_bigmem, and Victor opened #13100 for sre_compile.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13054>
_______________________________________

From report at bugs.python.org  Tue Oct  4 20:05:57 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Oct 2011 18:05:57 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1317750171.3784.8.camel@localhost.localdomain>
Message-ID: <4E8B4B02.60306@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Not really. xz is becoming a defacto standard under Linux (and perhaps
> other free Unices) while I guess it is marginal under Windows.
> We have other system-specific functionality, and nobody sees it as a bad
> thing.

That's because all system-specific functionality that we have really 
depends on system features which just can't be available elsewhere.
For all functionality that in principle works on all systems, it also
actually works on all systems for Python. In cases where stuff was
only available on Linux even though it could work on other systems,
people *did* see it as a bad thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct  4 20:08:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 18:08:09 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <4E8B4B02.60306@v.loewis.de>
Message-ID: <1317751477.3784.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That's because all system-specific functionality that we have really 
> depends on system features which just can't be available elsewhere.
> For all functionality that in principle works on all systems, it also
> actually works on all systems for Python. In cases where stuff was
> only available on Linux even though it could work on other systems,
> people *did* see it as a bad thing.

Agreed, but it's a probably with the external library. That's like
saying we are responsible if libffi fails building with the AIX
compiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct  4 20:08:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Oct 2011 18:08:55 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1317751477.3784.9.camel@localhost.localdomain>
Message-ID: <1317751516.3784.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > That's because all system-specific functionality that we have really 
> > depends on system features which just can't be available elsewhere.
> > For all functionality that in principle works on all systems, it also
> > actually works on all systems for Python. In cases where stuff was
> > only available on Linux even though it could work on other systems,
> > people *did* see it as a bad thing.
> 
> Agreed, but it's a probably with the external library. That's like
> saying we are responsible if libffi fails building with the AIX
> compiler.

s/probably/problem/ ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct  4 20:36:49 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 04 Oct 2011 18:36:49 +0000
Subject: [issue13101] Module Doc viewer closes when browser window closes on
	Windows 8
Message-ID: <1317753409.09.0.358970019617.issue13101@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

Reported by Ryan Wells (v-rywel at microsoft.com) of Microsoft, in reference to a problem with the Module Doc viewer on Windows 8 when using Internet Explorer 10. This was reported on 3.2.2, but it's likely the same on 2.7.


Reference #: 70652
Description of the Problem: The application Python Module Doc is automatically closed when Internet Explorer 10 is closed.
Steps to Reproduce:
1.       Install Windows Developer Preview
2.       Install Python 3.2.2
3.       Launch Module Doc.  Start Menu -> All Program -> Python -> Manual Docs
4.       Click on the button open browser
5.       It should open the site http://localhost:7464/ In Internet Explorer 10 and the contents should be displayed
6.       Should be able to view list of Modules, Scripts, DLLs, and Libraries etc.
7.       Close Internet Explorer

Expected Result: Internet Explorer 10 should only get closed and we should be able to work with the application Module Doc.
Actual Result: The application Module Doc is closed with Internet Explorer 10.
 
Developer Notes: There is likely a difference in return values between IE8 and IE9/10 when launched from the app.

----------
assignee: docs at python
components: Documentation, Windows
messages: 144918
nosy: brian.curtin, docs at python
priority: normal
severity: normal
status: open
title: Module Doc viewer closes when browser window closes on Windows 8
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13101>
_______________________________________

From report at bugs.python.org  Tue Oct  4 20:39:27 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Tue, 04 Oct 2011 18:39:27 +0000
Subject: [issue12880] ctypes: clearly document how structure bit fields are
	allocated
In-Reply-To: <1314930851.91.0.112444630543.issue12880@psf.upfronthosting.co.za>
Message-ID: <1317753567.25.0.786594630469.issue12880@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

I agree compiler matters for alignment but if you look at PyCField_FromDesc, you will see the layout is pretty much #ifdef MS_WIN32 - #else.

Sorry for generalizing, "all" indeed is not the right word. My point is that we should set expectation correctly - VC++-style on Windows, GCC-style everywhere else and encourage users to access structure members by name, not raw memory. Issues opened for bitfields *usually* are of the form I mentioned - setting raw memory to some bytes then seeing members are not what user expected, even if ctypes algorithm works correctly.

As I said, I will revise the patch and maybe make it more clear that users should look up how bitfield allocation works for their compiler instead of trying to understand this via structure raw memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12880>
_______________________________________

From report at bugs.python.org  Tue Oct  4 20:40:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Oct 2011 18:40:51 +0000
Subject: [issue11956] 3.3 : test_import.py causes 'make test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <E1RB9v8-0005Am-Fc@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cbda512c6d7f by Charles-Fran?ois Natali in branch '3.2':
Issue #11956: Always skip test_import.test_unwritable_directory when run as
http://hg.python.org/cpython/rev/cbda512c6d7f

New changeset 971093a75613 by Charles-Fran?ois Natali in branch 'default':
Issue #11956: Always skip test_import.test_unwritable_directory when run as
http://hg.python.org/cpython/rev/971093a75613

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11956>
_______________________________________

From report at bugs.python.org  Tue Oct  4 20:56:18 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 04 Oct 2011 18:56:18 +0000
Subject: [issue13101] Module Doc viewer closes when browser window closes on
	Windows 8
In-Reply-To: <1317753409.09.0.358970019617.issue13101@psf.upfronthosting.co.za>
Message-ID: <1317754578.99.0.926548764728.issue13101@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If that's the app I think it is (pydoc -g), we're probably going to kill it off in 3.3 in favour of the -b option.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13101>
_______________________________________

From report at bugs.python.org  Tue Oct  4 21:01:26 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 04 Oct 2011 19:01:26 +0000
Subject: [issue13101] Module Doc viewer closes when browser window closes on
	Windows 8
In-Reply-To: <1317753409.09.0.358970019617.issue13101@psf.upfronthosting.co.za>
Message-ID: <1317754886.65.0.967783598215.issue13101@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Slight correction, pydoc.gui() is already gone in current hg tip.

However, this error may be indicative of an underlying problem with webbrowser.open(url) throwing an exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13101>
_______________________________________

From report at bugs.python.org  Tue Oct  4 21:04:08 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 04 Oct 2011 19:04:08 +0000
Subject: [issue13101] Module Doc viewer closes when browser window closes on
	Windows 8
In-Reply-To: <1317753409.09.0.358970019617.issue13101@psf.upfronthosting.co.za>
Message-ID: <1317755048.33.0.0500806581238.issue13101@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

The menu shortcut opens up the following: "C:\Python32\pythonw.exe" "C:\Python32\Tools\scripts\pydocgui.pyw", which is just pydoc.gui()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13101>
_______________________________________

From report at bugs.python.org  Tue Oct  4 22:11:54 2011
From: report at bugs.python.org (Glenn Washburn)
Date: Tue, 04 Oct 2011 20:11:54 +0000
Subject: [issue13102] xml.dom.minidom does not support default namespaces
Message-ID: <1317759114.05.0.782450819911.issue13102@psf.upfronthosting.co.za>


New submission from Glenn Washburn <crass at berlios.de>:

When using getAttributeNS, attributes with no namespace should be considered as having the default namespace for that scope.  See examples in http://www.w3.org/TR/REC-xml-names/#defaulting.  Python's xml.dom.minidom will always set the namespace to None for attributes that have no namespace prefix.

I've attached a test program to illustrate this issue in action.  The output I get is:
[((None, u'attr'), u'value1')]
[(('http://www.w3.org/2000/xmlns/', 'xmlns'), u'http://path/to/ns2#'), ((None, u'attr'), u'value2')]
[((u'http://path/to/ns2#', u'attr'), u'value3')]
Successfully got child3 attr value

In the first two cases the namespaceURI is None, but it should be set to the default namespace specified in the root element.  I believe this problem occurs with all *NS functions.  Not tested in 3.x.

----------
components: XML
files: test.py
messages: 144924
nosy: crass
priority: normal
severity: normal
status: open
title: xml.dom.minidom does not support default namespaces
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file23313/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13102>
_______________________________________

From report at bugs.python.org  Tue Oct  4 22:41:20 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 04 Oct 2011 20:41:20 +0000
Subject: [issue13103] copy of an asyncore dispatcher causes infinite recursion
Message-ID: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

A regression occurs in python 3.2 when doing a copy of an asyncore
dispatcher.

$ python3.1
Python 3.1.2 (r312:79147, Apr  4 2010, 17:46:48) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncore, copy
>>> copy.copy(asyncore.dispatcher())
<asyncore.dispatcher at 0x7fcfb3590e90>


$ python3.2
Python 3.2 (r32:88445, Jun 18 2011, 20:30:18) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncore, copy
>>> copy.copy(asyncore.dispatcher())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/copy.py", line 97, in copy
    return _reconstruct(x, rv, 0)
  File "/usr/local/lib/python3.2/copy.py", line 291, in _reconstruct
    if hasattr(y, '__setstate__'):
  File "/usr/local/lib/python3.2/asyncore.py", line 410, in __getattr__
    retattr = getattr(self.socket, attr)
  ....
  File "/usr/local/lib/python3.2/asyncore.py", line 410, in __getattr__
    retattr = getattr(self.socket, attr)
  File "/usr/local/lib/python3.2/asyncore.py", line 410, in __getattr__
    retattr = getattr(self.socket, attr)
RuntimeError: maximum recursion depth exceeded while calling a Python object


This occurs after the 'copy' module has created the new instance with
__new__(). This new instance does not have the 'socket' attribute,
hence the infinite recursion.

Adding the following methods to the dispatcher class, fixes the infinite
recursion:

    def __getstate__(self):
        state = self.__dict__.copy()
        return state

    def __setstate__(self, state):
        self.__dict__.update(state)

But it does not explain why the recursion occurs in 3.2 and not in
3.1.

----------
components: Extension Modules
messages: 144925
nosy: xdegaye
priority: normal
severity: normal
status: open
title: copy of an asyncore dispatcher causes infinite recursion
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13103>
_______________________________________

From report at bugs.python.org  Tue Oct  4 23:31:51 2011
From: report at bugs.python.org (Amorilia)
Date: Tue, 04 Oct 2011 21:31:51 +0000
Subject: [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1317763911.39.0.927652261818.issue13081@psf.upfronthosting.co.za>


Amorilia <amorilia.gamebox at gmail.com> added the comment:

Quick update: apparently, fixing another seemingly unrelated bug, fixed this crashing issue as well for rlibiez. Here's relevant the commit:

https://github.com/amorilia/pyffi/commit/bd7886eefedfce8fb108c4701cf0467e2a707907

Basically, the problem was with multiprocessing.Pools not getting closed and joined.

I'm attaching a script (poolcrash.py) which, theoretically, ought to reproduce the crash - although it doesn't quite reproduce it on my machine; I'm running out of memory and my machine just hangs desperately accessing the swap file before anything happens...

Beware that running the bugged script may force you perform a hard reboot of your system, particularly if you wait until all physical memory is used up by zombie processes.

----------
Added file: http://bugs.python.org/file23314/poolcrash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13081>
_______________________________________

From report at bugs.python.org  Tue Oct  4 23:32:53 2011
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 04 Oct 2011 21:32:53 +0000
Subject: [issue13102] xml.dom.minidom does not support default namespaces
In-Reply-To: <1317759114.05.0.782450819911.issue13102@psf.upfronthosting.co.za>
Message-ID: <1317763973.25.0.614840648667.issue13102@psf.upfronthosting.co.za>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

Please read the link which you posted.  Quoting the second paragraph, second sentence:

"Default namespace declarations do not apply directly to attribute names;"

and from the third paragraph, third sentence:

"The namespace name for an unprefixed attribute name always has no value."

Therefore minidom *is* conformant by having None as the namespace-uri for unprefixed attribute names.

----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13102>
_______________________________________

From report at bugs.python.org  Wed Oct  5 00:29:31 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 04 Oct 2011 22:29:31 +0000
Subject: [issue13061] Decimal module yields incorrect results when Python
	compiled with clang
In-Reply-To: <1317317264.78.0.478675633552.issue13061@psf.upfronthosting.co.za>
Message-ID: <1317767371.34.0.464564030141.issue13061@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee: ronaldoussoren -> ned.deily
stage:  -> committed/rejected
status: pending -> closed
title: Decimal module yields incorrect results when Python compiled with llvm -> Decimal module yields incorrect results when Python compiled with clang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13061>
_______________________________________

From report at bugs.python.org  Wed Oct  5 01:01:23 2011
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 04 Oct 2011 23:01:23 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <1317769283.59.0.720844711677.issue13053@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

New patch based on comments from Ezio Melotti--thanks, Ezio!

* capsulethunk.h is now its own file in Doc/includes.
* Various minor formatting touchups.
* I added some rationale behind the thunked PyCapsule_SetName behavior.

----------
Added file: http://bugs.python.org/file23315/larry.cporting.capsules.r3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Wed Oct  5 01:02:51 2011
From: report at bugs.python.org (Deokhwan Kim)
Date: Tue, 04 Oct 2011 23:02:51 +0000
Subject: [issue13104] urllib.request.thishost() returns a garbage value
Message-ID: <1317769371.74.0.590194297783.issue13104@psf.upfronthosting.co.za>


New submission from Deokhwan Kim <dkim at csail.mit.edu>:

There is a minor typo in Lib/urllib/request.py:thishost(). Because of it, the thishost() function is returning a garbage value:

  >>> import urllib.request
  >>> urllib.request.thishost()
  ('XXXXXXX.XXXXX.XXX.com', ['X.XXXXX.XXX.com'], ['123.45.67.89'])

It is expected to return the IP addresses of the current host, so the correct return value would be like:

  >>> urllib.request.thishost.__doc__
  'Return the IP addresses of the current host.'
  >>> urllib.request.thishost()
  ('127.0.0.1', '127.0.1.1')

The attached patch will fix the mistake .

----------
components: Library (Lib)
files: thishost.patch
keywords: patch
messages: 144929
nosy: dkim
priority: normal
severity: normal
status: open
title: urllib.request.thishost() returns a garbage value
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file23316/thishost.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13104>
_______________________________________

From report at bugs.python.org  Wed Oct  5 01:24:16 2011
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 04 Oct 2011 23:24:16 +0000
Subject: [issue13105] Please elaborate on how 2.x and 3.x are different heads
Message-ID: <1317770656.72.0.880626385137.issue13105@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

It wasn't clear to me after reading the "Forward Porting" section exactly what was going on.  Nick Coghlan spelled it out for me in a private email, and suggested that maybe this stuff should be in the devguide proper.  Here's some specific stuff that I didn't understand until Nick explained it to me with simple words:

* 2.x and 3.x have separate heads in the same repository
* Since they're totally divorced, the order you check in to 2.x and 3.x does not matter
* DO NOT MERGE between 2.x and 3.x
* Branches that are in security-fix-only mode (e.g. 3.1) don't get bugfixes or documentation fixes (surely mentioned elsewhere, but I personally would have been helped with a reminder)

I suggest it'd be clearer to start with discussing "2.x and 3.x are separate heads", and *then* move on to "But when merging changes solely inside a major version" and talk about forward-porting.

Would you be interested in a patch?

----------
components: Devguide
messages: 144930
nosy: larry
priority: normal
severity: normal
status: open
title: Please elaborate on how 2.x and 3.x are different heads
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13105>
_______________________________________

From report at bugs.python.org  Wed Oct  5 01:26:39 2011
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 04 Oct 2011 23:26:39 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1317770799.23.0.287521451059.issue10348@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Charles and Antoine's votes match my own, therefore closing the bug wont fix

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10348>
_______________________________________

From report at bugs.python.org  Wed Oct  5 01:51:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 Oct 2011 23:51:15 +0000
Subject: [issue12880] ctypes: clearly document how structure bit fields are
	allocated
In-Reply-To: <1314930851.91.0.112444630543.issue12880@psf.upfronthosting.co.za>
Message-ID: <1317772275.78.0.121151886567.issue12880@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If I understand correctly, this doc patch would apply to 2.7 and 3.2 also. I have two style comments. I believe

"It is important to note that bit field allocation and layout in memory is not defined as a standard, rather its implementation is compiler-specific." 

could be shortened to

"Bit field allocation and memory layout is compiler-specific."

To me, this leads nicely into the proposed sentence that follows.

"it is recommended that no assumptions are made about the structure size and layout."

I do not like 'it is recommended'. Let us state the fact.

"any assumptions about the structure size and layout may be wrong."

----------
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12880>
_______________________________________

From report at bugs.python.org  Wed Oct  5 02:09:09 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 05 Oct 2011 00:09:09 +0000
Subject: [issue13104] urllib.request.thishost() returns a garbage value
In-Reply-To: <1317769371.74.0.590194297783.issue13104@psf.upfronthosting.co.za>
Message-ID: <1317773349.39.0.20605170014.issue13104@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +orsenthil
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13104>
_______________________________________

From report at bugs.python.org  Wed Oct  5 02:50:24 2011
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 05 Oct 2011 00:50:24 +0000
Subject: [issue13101] Module Doc viewer closes when browser window closes on
	Windows 8
In-Reply-To: <1317753409.09.0.358970019617.issue13101@psf.upfronthosting.co.za>
Message-ID: <1317775824.63.0.290294797485.issue13101@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

For some reason, IE is struggling to even display the page - it just seems to sit there loading the page without displaying anything, but hitting "stop" then "refresh" usually brings it up.  But if you kill IE (which best I can tell can only be done via the task manager - it has no other Windows controls) the doc server process does also terminate.

If you run the doc server using python.exe, you will notice tracebacks in the console due to the socket connection being reset (which is probably related to the above problems - the socket should have been fully read by the time you manage to kill IE) - but using python.exe the process stays alive serving requests.  I *guess* that the problem is pythonw.exe is hitting an error when it attempts to print to the invalid stderr handle.  It might be possible that somehow under Windows 8, stderr isn't buffered (or has as large of a buffer) as other Windows versions, so dies when a small amount of data is written to stderr - but I suspect the same problem could be provoked on other Windows versions by arranging for > 8k of "connection reset by peer" tracebacks to be written, at which point the buffer is attempted to be flushed and fails.

Here endeth my speculation for the day ;)

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13101>
_______________________________________

From report at bugs.python.org  Wed Oct  5 04:11:49 2011
From: report at bugs.python.org (Aaron Staley)
Date: Wed, 05 Oct 2011 02:11:49 +0000
Subject: [issue13106] Incorrect pool.py distributed with Python 2.7 windows
	32bit
Message-ID: <1317780709.51.0.218213650028.issue13106@psf.upfronthosting.co.za>


New submission from Aaron Staley <usaar33 at gmail.com>:

The multiprocess/pool.py distributed with the Python 2.7.2 Windows Installer is different from the one distributed with the 64 bit windows installer or source tarball - and is buggy.

Specifically, see Pool._terminate_pool:


    def _terminate_pool(cls, taskqueue, inqueue, outqueue, pool,
                        worker_handler, task_handler, result_handler, cache):
        # this is guaranteed to only be called once
        debug('finalizing pool')

        worker_handler._state = TERMINATE
        task_handler._state = TERMINATE
        taskqueue.put(None)                 # THIS LINE MISSING!


Without that line, termination may deadlock during Pool._help_stuff_finish.  The consequence to the user is the interpreter not shutting down.

----------
components: Windows
messages: 144934
nosy: Aaron.Staley
priority: normal
severity: normal
status: open
title: Incorrect pool.py distributed with Python 2.7 windows 32bit
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13106>
_______________________________________

From report at bugs.python.org  Wed Oct  5 04:27:02 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 05 Oct 2011 02:27:02 +0000
Subject: [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1317781622.86.0.97390353077.issue13081@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I tried that script on 2.7 and like it did for you, it just ran until my machine became unusable.

On 3.x I think I got a RuntimeError after a while, but I forgot exactly what happened since the machine ended up being hosed later from the 2.7 run. In any event, it certainly didn't crash there and only went a short time before erroring out with some exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13081>
_______________________________________

From report at bugs.python.org  Wed Oct  5 04:41:47 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 05 Oct 2011 02:41:47 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317782507.79.0.972955552598.issue3163@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Found a few test case nits.  Comments in rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Wed Oct  5 05:48:02 2011
From: report at bugs.python.org (Olivier Refalo)
Date: Wed, 05 Oct 2011 03:48:02 +0000
Subject: [issue9098] MSYS build fails with `S_IXGRP' undeclared
In-Reply-To: <1277729031.36.0.263470334817.issue9098@psf.upfronthosting.co.za>
Message-ID: <1317786482.03.0.664531017952.issue9098@psf.upfronthosting.co.za>


Olivier Refalo <orefalo at yahoo.com> added the comment:

hum, your patch actually works on MSYS !

ok.. so I am pretty much having the very some issue.


Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: unable to load the file system codec
LookupError: no codec search functions registered: can't find encoding

----------
nosy: +orefalo
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9098>
_______________________________________

From report at bugs.python.org  Wed Oct  5 06:25:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 05 Oct 2011 04:25:17 +0000
Subject: [issue13106] Incorrect pool.py distributed with Python 2.7 windows
	32bit
In-Reply-To: <1317780709.51.0.218213650028.issue13106@psf.upfronthosting.co.za>
Message-ID: <1317788717.46.0.0789620430526.issue13106@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +jnoller
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13106>
_______________________________________

From report at bugs.python.org  Wed Oct  5 06:26:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 05 Oct 2011 04:26:48 +0000
Subject: [issue13105] Please elaborate on how 2.x and 3.x are different heads
In-Reply-To: <1317770656.72.0.880626385137.issue13105@psf.upfronthosting.co.za>
Message-ID: <1317788808.31.0.699840919829.issue13105@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13105>
_______________________________________

From report at bugs.python.org  Wed Oct  5 06:28:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 05 Oct 2011 04:28:16 +0000
Subject: [issue13104] urllib.request.thishost() returns a garbage value
In-Reply-To: <1317769371.74.0.590194297783.issue13104@psf.upfronthosting.co.za>
Message-ID: <1317788896.12.0.517068127424.issue13104@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13104>
_______________________________________

From report at bugs.python.org  Wed Oct  5 06:29:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 05 Oct 2011 04:29:21 +0000
Subject: [issue13102] xml.dom.minidom does not support default namespaces
In-Reply-To: <1317759114.05.0.782450819911.issue13102@psf.upfronthosting.co.za>
Message-ID: <1317788961.56.0.700516520037.issue13102@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13102>
_______________________________________

From report at bugs.python.org  Wed Oct  5 06:30:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 05 Oct 2011 04:30:49 +0000
Subject: [issue13103] copy of an asyncore dispatcher causes infinite recursion
In-Reply-To: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za>
Message-ID: <1317789049.85.0.733550478247.issue13103@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +giampaolo.rodola, josiahcarlson, stutzbach
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13103>
_______________________________________

From report at bugs.python.org  Wed Oct  5 11:24:04 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 05 Oct 2011 09:24:04 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317806644.12.0.254163617697.issue6715@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I agree with Martin here. We should *NOT* have first and second class OS support, if we can avoid it.

That said, I wonder what happens in Windows with the BZ2 module, for instance :-?. Do we include the BZ2 sourcecode to compile it under windows?.

I know, for instance, that Windows 2.* builds include Berkeley DB.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct  5 11:27:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Oct 2011 09:27:57 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1317806644.12.0.254163617697.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317806663.3674.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I agree with Martin here. We should *NOT* have first and second class
> OS support, if we can avoid it.

The key word being "if we can avoid it".
Jesus, if you are a Windows expert, your contribution is welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct  5 11:31:16 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 05 Oct 2011 09:31:16 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317807076.13.0.945347413393.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

For bz2, Tools/buildbot/external-common.bat has code to download bz2 source, and PCbuild/_bz2.vcproj include and compile these files together with _bz2.pyd.

The _ssl module does a similar thing, except that libeay32.lib and libssleay32.lib are built in a separate step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct  5 11:58:12 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 Oct 2011 09:58:12 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1317806644.12.0.254163617697.issue6715@psf.upfronthosting.co.za>
Message-ID: <4E8C2A31.2040206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> That said, I wonder what happens in Windows with the BZ2 module, for instance :-?.

External code currently lives at 
http://svn.python.org/projects/external/. The build process gets it from 
there, and we may
have local modifications to libraries where necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct  5 12:00:56 2011
From: report at bugs.python.org (Jens Diemer)
Date: Wed, 05 Oct 2011 10:00:56 +0000
Subject: [issue11638] pysetup un sdist crashes with weird trace if version is
	unicode by accident
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1317808856.68.0.144598007986.issue11638@psf.upfronthosting.co.za>


Changes by Jens Diemer <bugs.python.org at jensdiemer.de>:


----------
nosy: +jens

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Wed Oct  5 12:09:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Oct 2011 10:09:22 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317809362.03.0.0890804054503.issue6715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I agree with Martin here. We should *NOT* have first
> and second class OS support, if we can avoid it.

Ok but who will do the job? If nobody is motivated to fix compiler issues, it would be a pity to not add the module for that.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct  5 12:13:26 2011
From: report at bugs.python.org (Jens Diemer)
Date: Wed, 05 Oct 2011 10:13:26 +0000
Subject: [issue11638] pysetup un sdist crashes with weird trace if version is
	unicode by accident
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1317809606.42.0.655470832066.issue11638@psf.upfronthosting.co.za>


Jens Diemer <bugs.python.org at jensdiemer.de> added the comment:

I have the same problem, using distutils (and not distutils2):


Traceback (most recent call last):
  File "./setup.py", line 60, in <module>
    test_suite="creole.tests.run_all_tests",
  File "/usr/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/home/jens/python2creole_env/local/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/sdist.py", line 147, in run
  File "/usr/lib/python2.7/distutils/command/sdist.py", line 448, in make_distribution
    owner=self.owner, group=self.group)
  File "/usr/lib/python2.7/distutils/cmd.py", line 392, in make_archive
    owner=owner, group=group)
  File "/usr/lib/python2.7/distutils/archive_util.py", line 237, in make_archive
    filename = func(base_name, base_dir, **kwargs)
  File "/usr/lib/python2.7/distutils/archive_util.py", line 101, in make_tarball
    tar = tarfile.open(archive_name, 'w|%s' % tar_compression[compress])
  File "/usr/lib/python2.7/tarfile.py", line 1687, in open
    _Stream(name, filemode, comptype, fileobj, bufsize),
  File "/usr/lib/python2.7/tarfile.py", line 431, in __init__
    self._init_write_gz()
  File "/usr/lib/python2.7/tarfile.py", line 459, in _init_write_gz
    self.__write(self.name + NUL)
  File "/usr/lib/python2.7/tarfile.py", line 475, in __write
    self.buf += s
UnicodeDecodeError: 'ascii' codec can't decode byte 0x8b in position 1: ordinal not in range(128)


The Problem seems that tarfile._Stream() can't handle 'name' as unicode. With this changes, it works:

class _Stream:
    ...
    def __init__(self, name, mode, comptype, fileobj, bufsize):
        ...
        self.name = str(name) or ""
                    ++++    +

Don't know it this is related to the usage of: from __future__ import unicode_literals ?

----------
components: +Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Wed Oct  5 12:30:42 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 05 Oct 2011 10:30:42 +0000
Subject: [issue13073] message_body argument of HTTPConnection.endheaders is
	undocumented
In-Reply-To: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>
Message-ID: <1317810642.73.0.210514641552.issue13073@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The 2.7 documentation should mention the version in which the argument was added. I believe it was 2.7.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13073>
_______________________________________

From report at bugs.python.org  Wed Oct  5 12:32:29 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 05 Oct 2011 10:32:29 +0000
Subject: [issue13073] message_body argument of HTTPConnection.endheaders is
	undocumented
In-Reply-To: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>
Message-ID: <1317810749.55.0.422552656027.issue13073@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I also left some comments on the review page that should be addressed.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13073>
_______________________________________

From report at bugs.python.org  Wed Oct  5 12:50:45 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 05 Oct 2011 10:50:45 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317811845.51.0.893391050844.issue6715@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Antoine, I am a Linux/Solaris/Illumos guy. I only use Windows (virtualized) to sync my iPhone with iTunes :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct  5 13:08:23 2011
From: report at bugs.python.org (Adam Byrtek)
Date: Wed, 05 Oct 2011 11:08:23 +0000
Subject: [issue13107] Text width in optparse.py can become negative
Message-ID: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za>


New submission from Adam Byrtek <adambyrtek at gmail.com>:

Code snippet from optparse.py:

   344         self.help_position = min(max_len + 2, self.max_help_position)
   345         self.help_width = self.width - self.help_position

Where self.width is initialized with the COLUMNS environment variable. On narrow terminals it can happen that self.help_position < self.width, leading to an exception in textwrap.py:

    raise ValueError("invalid width %r (must be > 0)" % self.width)
ValueError: invalid width -15 (must be > 0)

A reasonable workaround would be to trim part of the help text instead of causing an exception.

----------
components: Library (Lib)
messages: 144947
nosy: adambyrtek
priority: normal
severity: normal
status: open
title: Text width in optparse.py can become negative
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13107>
_______________________________________

From report at bugs.python.org  Wed Oct  5 13:16:13 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 05 Oct 2011 11:16:13 +0000
Subject: [issue13103] copy of an asyncore dispatcher causes infinite recursion
In-Reply-To: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za>
Message-ID: <1317813373.95.0.798266766344.issue13103@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

The infinite recursion occurs also when running python 3.2 with the
extension modules copy, copyreg and asyncore from python 3.1. So it
seems this regression is not caused by a modification in these
modules.

Anyway, the bug is in asyncore. The attached patch fixes it and is
more robust than adding the __getstate__ and __setstate__ methods to
dispatcher.

The patch includes a test case.

----------
keywords: +patch
Added file: http://bugs.python.org/file23317/infinite_recursion_asyncore.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13103>
_______________________________________

From report at bugs.python.org  Wed Oct  5 13:41:11 2011
From: report at bugs.python.org (Aaron Staley)
Date: Wed, 05 Oct 2011 11:41:11 +0000
Subject: [issue13106] Incorrect pool.py distributed with Python 2.7 windows
	32bit
In-Reply-To: <1317780709.51.0.218213650028.issue13106@psf.upfronthosting.co.za>
Message-ID: <1317814871.42.0.701796806576.issue13106@psf.upfronthosting.co.za>


Aaron Staley <usaar33 at gmail.com> added the comment:

Never mind; looks like this functionality was moved to handle_workers. I had inadvertently been testing under a modified pool.py.

Sorry for the inconvenience!

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13106>
_______________________________________

From report at bugs.python.org  Wed Oct  5 13:45:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 05 Oct 2011 11:45:42 +0000
Subject: [issue13106] Incorrect pool.py distributed with Python 2.7 windows
	32bit
In-Reply-To: <1317780709.51.0.218213650028.issue13106@psf.upfronthosting.co.za>
Message-ID: <1317815142.32.0.456186579595.issue13106@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13106>
_______________________________________

From report at bugs.python.org  Wed Oct  5 15:46:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Oct 2011 13:46:54 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317822414.04.0.564528197138.issue3163@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the comments. Here is an updated patch.

----------
Added file: http://bugs.python.org/file23318/struct_nn4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Wed Oct  5 16:18:37 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 Oct 2011 14:18:37 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317824317.96.0.302082374193.issue3163@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: mark.dickinson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Wed Oct  5 17:27:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Oct 2011 15:27:53 +0000
Subject: [issue13073] message_body argument of HTTPConnection.endheaders is
	undocumented
In-Reply-To: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>
Message-ID: <E1RBTNv-0004Ur-B5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset befa7b926aad by Senthil Kumaran in branch '3.2':
Issue  #13073 - Address the review comments made by Ezio.
http://hg.python.org/cpython/rev/befa7b926aad

New changeset a7b7ba225de7 by Senthil Kumaran in branch 'default':
merge from 3.2. Issue  #13073 - Address the review comments made by Ezio.
http://hg.python.org/cpython/rev/a7b7ba225de7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13073>
_______________________________________

From report at bugs.python.org  Wed Oct  5 17:53:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Oct 2011 15:53:12 +0000
Subject: [issue13073] message_body argument of HTTPConnection.endheaders is
	undocumented
In-Reply-To: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>
Message-ID: <E1RBTmR-00073Y-4H@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 64fae6f7b64c by Senthil Kumaran in branch '2.7':
Issue13073 - Address review comments and add versionchanged information in the docs.
http://hg.python.org/cpython/rev/64fae6f7b64c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13073>
_______________________________________

From report at bugs.python.org  Wed Oct  5 17:54:12 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 05 Oct 2011 15:54:12 +0000
Subject: [issue13073] message_body argument of HTTPConnection.endheaders is
	undocumented
In-Reply-To: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>
Message-ID: <1317830052.93.0.129183242088.issue13073@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I believe, I have addressed all the comments. Closing this report.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13073>
_______________________________________

From report at bugs.python.org  Wed Oct  5 18:21:26 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 05 Oct 2011 16:21:26 +0000
Subject: [issue13103] copy of an asyncore dispatcher causes infinite recursion
In-Reply-To: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za>
Message-ID: <1317831686.47.0.685622901498.issue13103@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

About why the asyncore bug shows up in python 3.2:

The simple test below is ok with python 3.1 but triggers a
"RuntimeError: maximum recursion depth exceeded..." with python 3.2:

$ python3.1
Python 3.1.2 (r312:79147, Apr  4 2010, 17:46:48) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class C:
...   def __getattr__(self, attr):
...     return getattr(self.foo, attr)
... 
>>> c = C()
>>> hasattr(c, 'bar')
False
>>> 

For the reasoning behind this change made in python 3.2, see issue
9666 and the mail
http://mail.python.org/pipermail/python-dev/2010-August/103178.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13103>
_______________________________________

From report at bugs.python.org  Wed Oct  5 18:27:18 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 05 Oct 2011 16:27:18 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317728151.55.0.216157545721.issue13070@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM22RLsSMYgU59Q+fnAHuyTEv8zx8bkwgQsDoseABW78Ag@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Sorry, forgot about this issue...
Updated patch (I'm not really satisfied with the error message, don't
hesitate if you can think of a better wording).

----------
Added file: http://bugs.python.org/file23319/buffered_closed_gc-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_io.py b/Lib/test/test_io.py
--- a/Lib/test/test_io.py
+++ b/Lib/test/test_io.py
@@ -2421,6 +2421,20 @@
         with self.open(support.TESTFN, "rb") as f:
             self.assertEqual(f.read(), b"456def")
 
+    def test_rwpair_cleared_before_textio(self):
+        # Issue 13070: TextIOWrapper's finalization would crash when called
+        # after the reference to the underlying BufferedRWPair got cleared.
+        for i in range(1000):
+            b1 = self.BufferedRWPair(self.MockRawIO(), self.MockRawIO())
+            t1 = self.TextIOWrapper(b1, encoding="ascii")
+            b2 = self.BufferedRWPair(self.MockRawIO(), self.MockRawIO())
+            t2 = self.TextIOWrapper(b2, encoding="ascii")
+            # circular references
+            t1.buddy = t2
+            t2.buddy = t1
+        support.gc_collect()
+
+
 class PyTextIOWrapperTest(TextIOWrapperTest):
     pass
 
diff --git a/Modules/_io/bufferedio.c b/Modules/_io/bufferedio.c
--- a/Modules/_io/bufferedio.c
+++ b/Modules/_io/bufferedio.c
@@ -2307,6 +2307,10 @@
 static PyObject *
 bufferedrwpair_closed_get(rwpair *self, void *context)
 {
+    if (self->writer == NULL) {
+        PyErr_SetString(PyExc_RuntimeError, "the writer object has been cleared");
+        return NULL;
+    }
     return PyObject_GetAttr((PyObject *) self->writer, _PyIO_str_closed);
 }
 

From report at bugs.python.org  Wed Oct  5 18:33:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Oct 2011 16:33:08 +0000
Subject: [issue13104] urllib.request.thishost() returns a garbage value
In-Reply-To: <1317769371.74.0.590194297783.issue13104@psf.upfronthosting.co.za>
Message-ID: <E1RBUP5-0002mG-3z@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 805a0a1e3c2b by Senthil Kumaran in branch '3.2':
Issue13104 - Fix urllib.request.thishost() utility function.
http://hg.python.org/cpython/rev/805a0a1e3c2b

New changeset a228e59ad693 by Senthil Kumaran in branch 'default':
merge from 3.2.  Issue13104 - Fix urllib.request.thishost() utility function.
http://hg.python.org/cpython/rev/a228e59ad693

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13104>
_______________________________________

From report at bugs.python.org  Wed Oct  5 18:34:06 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 05 Oct 2011 16:34:06 +0000
Subject: [issue13104] urllib.request.thishost() returns a garbage value
In-Reply-To: <1317769371.74.0.590194297783.issue13104@psf.upfronthosting.co.za>
Message-ID: <1317832446.33.0.368319366982.issue13104@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for the report. This is fixed now. I hope in 3.3 I remove this old utility functions. (real soon).

----------
assignee:  -> orsenthil
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13104>
_______________________________________

From report at bugs.python.org  Wed Oct  5 18:45:32 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 05 Oct 2011 16:45:32 +0000
Subject: [issue13045] socket.getsockopt may require custom buffer contents
In-Reply-To: <1317666568.73.0.957785734202.issue13045@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3enEVo0KVCziv+E4x33ytU2jF7sqwV9+AtsiteHbg0kQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I've attached an update for the previous patch. Now there's no more
> overloading for the third argument and socket.getsockopt accepts one more
> optional argument -- a buffer to use as an input to kernel.

Remarks:
"""
+   length.  If *buffer* is absent and *buflen* is an integer, then *buflen*
[...]
+   this buffer is returned as a bytes object.  If *buflen* is absent,
an integer
"""
There's a problem here, the first buflen part should probably be removed.

Also, you might want to specify that if a custom buffer is provided,
the length argument will be ignored.

> By the way, I don't really think that any POSIX-compliant UNIX out there
> would treat the buffer given to getsockopt in any way different from what
> Linux does. It is very easy to copy the buffer from user to kernel and back,
> and it is so inconvenient to prevent kernel from reading it prior to
> modification, that I bet no one has ever bothered to do this.

Me neither, I don't expect the syscall to return EINVAL: the goal is
just to test the correct passing of the input buffer, and the length
computation.

If we can't test this easily within test_socket, it's ok, I guess the
following should be enough:
- try supplying a non-buffer argument as fourth parameter (e.g. and
int), and check that you get a ValueError
- supply a buffer with a size == sizeof(int) (SIZEOF_INT is defined in
Lib/test/test_socket.py), and call getsockopt(socket.SOL_SOCKET,
socket.SO_REUSEADDR, 0, <buffer>): this should normally succeed, and
return a buffer (check the return type)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13045>
_______________________________________

From report at bugs.python.org  Wed Oct  5 18:47:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 05 Oct 2011 16:47:27 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1317833247.16.0.747153035621.issue10141@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Wed Oct  5 18:54:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 05 Oct 2011 16:54:46 +0000
Subject: [issue11956] 3.3 : test_import.py causes 'make test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <1317833686.16.0.744852950141.issue11956@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11956>
_______________________________________

From report at bugs.python.org  Wed Oct  5 19:04:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Oct 2011 17:04:15 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1317834255.64.0.861880532954.issue10141@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't have much to say about the patch, given that I don't know anything about CAN and my system doesn't appear to have a "vcan0" interface. I think it's ok to commit and refine later if something turns out insufficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Wed Oct  5 19:09:23 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 05 Oct 2011 17:09:23 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1317834563.88.0.461612720392.issue10141@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I don't have much to say about the patch, given that I don't know
> anything about CAN and my system doesn't appear to have a "vcan0"
> interface.

I had never heard about it before this issue, but the protocol is really simple.

If you want to try it out (just for fun :-), you just have to do the following:
# modprobe vcan
# ip link add dev vcan0 type vcan
# ifconfig vcan0 up

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Wed Oct  5 19:17:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Oct 2011 17:17:18 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1317834563.88.0.461612720392.issue10141@psf.upfronthosting.co.za>
Message-ID: <1317834824.3713.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I had never heard about it before this issue, but the protocol is really simple.
> 
> If you want to try it out (just for fun :-), you just have to do the following:
> # modprobe vcan
> # ip link add dev vcan0 type vcan
> # ifconfig vcan0 up

Ah, thanks! Can you add a comment about that in test_socket.py?
I can confirm that all tests pass ok on my Linux system (kernel
2.6.38.8-desktop-5.mga).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Wed Oct  5 19:20:55 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 05 Oct 2011 17:20:55 +0000
Subject: [issue13103] copy of an asyncore dispatcher causes infinite recursion
In-Reply-To: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za>
Message-ID: <1317835255.59.0.833614583816.issue13103@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

So, in 3.1 hasattr(y, '__setstate__') *did* recurse and hit the limit, but the exception was caught and hasattr returned False?

I think I prefer the new behavior...
The patch looks good, I would simply have raised AttributeError(name) though.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13103>
_______________________________________

From report at bugs.python.org  Wed Oct  5 19:22:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Oct 2011 17:22:48 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317835368.86.0.598178860941.issue13070@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The latest patch looks good to me.
As for the error message, how about "the BufferedRWPair object is being garbage-collected".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Wed Oct  5 19:32:55 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 05 Oct 2011 17:32:55 +0000
Subject: [issue13103] copy of an asyncore dispatcher causes infinite recursion
In-Reply-To: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za>
Message-ID: <1317835975.0.0.342139987767.issue13103@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

IMO, patch should only be applied to Python 3.2.
For 3.3 we finally have the chance to get rid of the dispatcher.__getattr__ aberration (see issue 8483) so I say let's just remove it and fix this issue as a consequence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13103>
_______________________________________

From report at bugs.python.org  Wed Oct  5 19:53:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Oct 2011 17:53:35 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <E1RBVes-0002p2-Ff@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d60c00015f01 by Charles-Fran?ois Natali in branch '3.2':
Issue #13070: Fix a crash when a TextIOWrapper caught in a reference cycle
http://hg.python.org/cpython/rev/d60c00015f01

New changeset 7defc1e5d13a by Charles-Fran?ois Natali in branch 'default':
Issue #13070: Fix a crash when a TextIOWrapper caught in a reference cycle
http://hg.python.org/cpython/rev/7defc1e5d13a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Wed Oct  5 20:15:37 2011
From: report at bugs.python.org (Amorilia)
Date: Wed, 05 Oct 2011 18:15:37 +0000
Subject: [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1317838537.66.0.0157022031873.issue13081@psf.upfronthosting.co.za>


Amorilia <amorilia.gamebox at gmail.com> added the comment:

Thanks for also trying it out, Brian.

I feel there's little more I can do. I guess the multiprocessing module could be documented a bit better that join() ought to be called before the pool is deleted? Currently, the docs merely say:

"Wait for the worker processes to exit. One must call close() or terminate() before using join()." (http://docs.python.org/library/multiprocessing.html#multiprocessing.pool.multiprocessing.Pool.join)

Something along the following lines could be added:

"You must call join() when you no longer need the pool; otherwise, zombie processes may keep running."

I'm happy to provide a patch, if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13081>
_______________________________________

From report at bugs.python.org  Wed Oct  5 20:44:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 05 Oct 2011 18:44:10 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317840250.36.0.80690024783.issue13070@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Committed to 3.2 and default.

Victor, thanks for the report!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Wed Oct  5 21:25:05 2011
From: report at bugs.python.org (Victor Semionov)
Date: Wed, 05 Oct 2011 19:25:05 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317842705.14.0.409525881885.issue13070@psf.upfronthosting.co.za>


Victor Semionov <vsemionov at gmail.com> added the comment:

Great, thanks to you too, for fixing it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Wed Oct  5 21:26:10 2011
From: report at bugs.python.org (David Andrzejewski)
Date: Wed, 05 Oct 2011 19:26:10 +0000
Subject: [issue8813] SSLContext doesn't support loading a CRL
In-Reply-To: <1274735830.03.0.714974872377.issue8813@psf.upfronthosting.co.za>
Message-ID: <1317842770.02.0.118232909457.issue8813@psf.upfronthosting.co.za>


Changes by David Andrzejewski <site+python.org at davidandrzejewski.com>:


----------
nosy: +dandrzejewski

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8813>
_______________________________________

From report at bugs.python.org  Wed Oct  5 21:55:49 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 05 Oct 2011 19:55:49 +0000
Subject: [issue13103] copy of an asyncore dispatcher causes infinite recursion
In-Reply-To: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za>
Message-ID: <1317844549.28.0.551481965401.issue13103@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Let's add the test to 3.3 nonetheless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13103>
_______________________________________

From report at bugs.python.org  Wed Oct  5 23:00:25 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 05 Oct 2011 21:00:25 +0000
Subject: [issue13103] copy of an asyncore dispatcher causes infinite recursion
In-Reply-To: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za>
Message-ID: <1317848425.1.0.101840696169.issue13103@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> So, in 3.1 hasattr(y, '__setstate__') *did* recurse and hit the limit,
> but the exception was caught and hasattr returned False?

This is right.


> I think I prefer the new behavior...
> The patch looks good, I would simply have raised AttributeError(name)
> though.

It is fine with me to raise AttributeError(name).
Note that when raising AttributeError('socket'), the user gets
notified of the exceptions on both 'socket' and 'name'.
For example with the patch applied:

$ python3
Python 3.2 (r32:88445, Jun 18 2011, 20:30:18) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncore
>>> a = asyncore.dispatcher()
>>> del a.socket
>>> a.foo
Traceback (most recent call last):
  File "asyncore.py", line 415, in __getattr__
    retattr = getattr(self.socket, attr)
  File "asyncore.py", line 413, in __getattr__
    % self.__class__.__name__)
AttributeError: dispatcher instance has no attribute 'socket'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "asyncore.py", line 418, in __getattr__
    %(self.__class__.__name__, attr))
AttributeError: dispatcher instance has no attribute 'foo'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13103>
_______________________________________

From report at bugs.python.org  Wed Oct  5 23:04:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 05 Oct 2011 21:04:49 +0000
Subject: [issue13108] test_urllib: buildbot failure
Message-ID: <1317848689.77.0.919610092444.issue13108@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The FreeBSD-amd64 and Fedora buildbots are recently failing with: 

======================================================================
ERROR: test_thishost (test.test_urllib.Utility_Tests)
Test the urllib.request.thishost utility function returns a tuple
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_urllib.py", line 1063, in test_thishost
    self.assertIsInstance(urllib.request.thishost(), tuple)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/urllib/request.py", line 2128, in thishost
    _thishost = tuple(socket.gethostbyname_ex(socket.gethostname())[2])
socket.gaierror: [Errno -2] Name or service not known

----------------------------------------------------------------------

----------
components: Tests
messages: 144971
nosy: skrah
priority: normal
severity: normal
status: open
title: test_urllib: buildbot failure
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13108>
_______________________________________

From report at bugs.python.org  Wed Oct  5 23:08:09 2011
From: report at bugs.python.org (xy zzy)
Date: Wed, 05 Oct 2011 21:08:09 +0000
Subject: [issue13109] telnetlib insensitive to connection loss
Message-ID: <1317848889.2.0.2461830982.issue13109@psf.upfronthosting.co.za>


New submission from xy zzy <the.stuffduff at gmail.com>:

Using python's telnetlib I can connect and communicate with a device.

While the telnet session is active I can disconnect the network cable of the device.

At this point, I would expect read_until() with a timeout to throw a socket.error, EOFError or perhaps an IOError, but what I actually get is a null string.

Because I'm reading in a loop, when the cable is reconnected the device will resume communicating, and the program will continue.

My best guess ts that read_until() or perhaps everything except open() is insensitive to the loss of a connection.

----------
components: IO
messages: 144972
nosy: xy.zzy
priority: normal
severity: normal
status: open
title: telnetlib insensitive to connection loss
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13109>
_______________________________________

From report at bugs.python.org  Wed Oct  5 23:50:06 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 05 Oct 2011 21:50:06 +0000
Subject: [issue13109] telnetlib insensitive to connection loss
In-Reply-To: <1317848889.2.0.2461830982.issue13109@psf.upfronthosting.co.za>
Message-ID: <1317851406.44.0.756311285278.issue13109@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Can you post some example code?

I would not expect disconnecting the network cable to close any TCP connections, unless you are transmitting data and/or you have keepalives turned on.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13109>
_______________________________________

From report at bugs.python.org  Wed Oct  5 23:51:15 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 Oct 2011 21:51:15 +0000
Subject: [issue13110] test_socket.py failures on ARM
Message-ID: <1317851475.03.0.915061914039.issue13110@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Initial results from warsaw-ubuntu-arm buildbot indicates two failures in test_socket.py

======================================================================
ERROR: test_create_connection_timeout (test.test_socket.NetworkConnectionNoServer)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/buildarea/2.7.warsaw-ubuntu-arm/build/Lib/test/test_socket.py", line 1198, in test_create_connection_timeout
    socket.create_connection((HOST, 1234))
  File "/var/lib/buildbot/buildarea/2.7.warsaw-ubuntu-arm/build/Lib/socket.py", line 571, in create_connection
    raise err
error: [Errno 97] Address family not supported by protocol

======================================================================
FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/buildarea/2.7.warsaw-ubuntu-arm/build/Lib/test/test_socket.py", line 1191, in test_create_connection
    self.assertEqual(cm.exception.errno, errno.ECONNREFUSED)
AssertionError: 97 != 111

----------------------------------------------------------------------

I'm still investigating, but wanted to file the bug now so there's an issue number to reference.

----------
components: Tests
messages: 144974
nosy: barry
priority: normal
severity: normal
status: open
title: test_socket.py failures on ARM
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13110>
_______________________________________

From report at bugs.python.org  Wed Oct  5 23:52:45 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 Oct 2011 21:52:45 +0000
Subject: [issue13110] test_socket.py failures on ARM
In-Reply-To: <1317851475.03.0.915061914039.issue13110@psf.upfronthosting.co.za>
Message-ID: <1317851565.88.0.945508072434.issue13110@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13110>
_______________________________________

From report at bugs.python.org  Thu Oct  6 00:55:27 2011
From: report at bugs.python.org (MA S)
Date: Wed, 05 Oct 2011 22:55:27 +0000
Subject: [issue13111] Error 2203 when installing Python/Perl?
Message-ID: <1317855327.52.0.585487977144.issue13111@psf.upfronthosting.co.za>


New submission from MA S <matthewsotoudeh at gmail.com>:

I can't install Python or Strawberry Perl on the Windows 8 Developer Preview :( I keep getting installer error 2203; the log file's attached. I really don't know what's wrong...

----------
components: Windows
files: python.log
messages: 144975
nosy: MA.S
priority: normal
severity: normal
status: open
title: Error 2203 when installing Python/Perl?
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file23320/python.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13111>
_______________________________________

From report at bugs.python.org  Thu Oct  6 01:31:34 2011
From: report at bugs.python.org (yoch)
Date: Wed, 05 Oct 2011 23:31:34 +0000
Subject: [issue13112] backreferences in comprehensions
Message-ID: <1317857494.55.0.915280284739.issue13112@psf.upfronthosting.co.za>


New submission from yoch <yoch.melka at gmail.com>:

Hi,

I would like to use backreferences in list comprehensions (or other comprehensions), such as :

[[elt for elt in lst if elt] for lst in matrix if \{1}]
# \{1} is back reference to [elt for elt in lst if elt] 
# to filter the result of the first comprehension

It would be possible to do this ?

Thanks

----------
messages: 144976
nosy: yoch.melka
priority: normal
severity: normal
status: open
title: backreferences in comprehensions
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13112>
_______________________________________

From report at bugs.python.org  Thu Oct  6 02:09:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Oct 2011 00:09:49 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1317859789.66.0.858386672243.issue7732@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This broke the Windows buildbots in Python 2.7.

----------
assignee:  -> haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Thu Oct  6 02:28:18 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 06 Oct 2011 00:28:18 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317860898.84.0.323806433769.issue3163@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

No problem.  This last version LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Thu Oct  6 02:34:18 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 06 Oct 2011 00:34:18 +0000
Subject: [issue13110] test_socket.py failures on ARM
In-Reply-To: <1317851475.03.0.915061914039.issue13110@psf.upfronthosting.co.za>
Message-ID: <1317861258.27.0.0389769831311.issue13110@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This appears to be the problem:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/868812

I'm going to close this Python bug since it seems to be related to the Linux kernel on armel.  Editing the /etc/hosts file gets around the problem and lets the test pass.  I could imagine that the test should be able to deal with the unexpected exceptions though.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13110>
_______________________________________

From report at bugs.python.org  Thu Oct  6 02:50:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Oct 2011 00:50:48 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317862248.22.0.891609832993.issue13070@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The issue doesn't affect Python 2.7?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Thu Oct  6 02:52:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Oct 2011 00:52:17 +0000
Subject: [issue13104] urllib.request.thishost() returns a garbage value
In-Reply-To: <1317769371.74.0.590194297783.issue13104@psf.upfronthosting.co.za>
Message-ID: <1317862337.57.0.672156948755.issue13104@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There is a failure on FreeBSD 8.2 buildbot:

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1104/steps/test/logs/stdio

======================================================================
ERROR: test_thishost (test.test_urllib.Utility_Tests)
Test the urllib.request.thishost utility function returns a tuple
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_urllib.py", line 1063, in test_thishost
    self.assertIsInstance(urllib.request.thishost(), tuple)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/urllib/request.py", line 2128, in thishost
    _thishost = tuple(socket.gethostbyname_ex(socket.gethostname())[2])
socket.gaierror: [Errno 8] hostname nor servname provided, or not known

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13104>
_______________________________________

From report at bugs.python.org  Thu Oct  6 02:52:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Oct 2011 00:52:26 +0000
Subject: [issue13104] urllib.request.thishost() returns a garbage value
In-Reply-To: <1317769371.74.0.590194297783.issue13104@psf.upfronthosting.co.za>
Message-ID: <1317862346.94.0.715280468107.issue13104@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13104>
_______________________________________

From report at bugs.python.org  Thu Oct  6 03:50:27 2011
From: report at bugs.python.org (Diego Mascialino)
Date: Thu, 06 Oct 2011 01:50:27 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1317865827.71.0.0650957887768.issue8087@psf.upfronthosting.co.za>


Diego Mascialino <dmascialino at gmail.com> added the comment:

I worked a few hours today and I have this patch.
I tried to make a test but could not.

I know this is not a really good patch, but it's my first one and I wanted to show my idea.

----------
keywords: +patch
versions:  -Python 2.7
Added file: http://bugs.python.org/file23321/issue8087.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Thu Oct  6 04:36:05 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 06 Oct 2011 02:36:05 +0000
Subject: [issue13104] urllib.request.thishost() returns a garbage value
In-Reply-To: <1317769371.74.0.590194297783.issue13104@psf.upfronthosting.co.za>
Message-ID: <1317868565.91.0.195130573901.issue13104@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

hmm. interesting case in FreeBSD. Looks like socket.gethostname() did not return the hostname in freebsd buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13104>
_______________________________________

From report at bugs.python.org  Thu Oct  6 08:53:25 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 06 Oct 2011 06:53:25 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317862248.22.0.891609832993.issue13070@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0Jk1x5YU1MxP81ehagLq8yTPPUojXkNyVSUVOLYAjq_A@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The issue doesn't affect Python 2.7?
>

Duh!
I was sure the _io module had been introduced in Python 3 (I/O layer
rewrite, etc).
Yes, it does apply to 2.7. I'll commit the patch later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Thu Oct  6 08:58:23 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 06 Oct 2011 06:58:23 +0000
Subject: [issue13108] test_urllib: buildbot failure
In-Reply-To: <1317848689.77.0.919610092444.issue13108@psf.upfronthosting.co.za>
Message-ID: <1317884303.78.0.154067239873.issue13108@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> urllib.request.thishost() returns a garbage value
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13108>
_______________________________________

From report at bugs.python.org  Thu Oct  6 08:58:40 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 06 Oct 2011 06:58:40 +0000
Subject: [issue13104] urllib.request.thishost() returns a garbage value
In-Reply-To: <1317769371.74.0.590194297783.issue13104@psf.upfronthosting.co.za>
Message-ID: <1317884320.01.0.592201061802.issue13104@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13104>
_______________________________________

From report at bugs.python.org  Thu Oct  6 09:22:32 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 06 Oct 2011 07:22:32 +0000
Subject: [issue13104] urllib.request.thishost() returns a garbage value
In-Reply-To: <1317769371.74.0.590194297783.issue13104@psf.upfronthosting.co.za>
Message-ID: <1317885752.3.0.17651944283.issue13104@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

/etc/hosts was incomplete; works fine now. Closing again.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13104>
_______________________________________

From report at bugs.python.org  Thu Oct  6 11:57:34 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 06 Oct 2011 09:57:34 +0000
Subject: [issue12210] test_smtplib: intermittent failures on FreeBSD
In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za>
Message-ID: <1317895054.61.0.162759403762.issue12210@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Naturally, as soon as I declare it fixed, it occurs again:

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%202.7/builds/326

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12210>
_______________________________________

From report at bugs.python.org  Thu Oct  6 12:15:29 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 06 Oct 2011 10:15:29 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317896129.05.0.749333653336.issue13070@psf.upfronthosting.co.za>


Victor Semionov <vsemionov at gmail.com> added the comment:

I did not see any segfaults when I ran my app on 2.7. Please verify that 2.7 is really affected before making changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Thu Oct  6 12:39:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 06 Oct 2011 10:39:47 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1317897587.25.0.618037713412.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -vsemionov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Thu Oct  6 12:41:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 06 Oct 2011 10:41:33 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1317897587.31.0.526787966097.issue2771@psf.upfronthosting.co.za>
Message-ID: <CACBhJdHuMXjZiNGwLdC_pc3Gyo0dwmtdPs7nafgcnP4mL886aQ@mail.gmail.com>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

test attachments

----------
Added file: http://bugs.python.org/file23322/unnamed
Added file: http://bugs.python.org/file23323/issue12753-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________
-------------- next part --------------
test attachments<br>
-------------- next part --------------
diff --git a/Doc/library/unicodedata.rst b/Doc/library/unicodedata.rst
--- a/Doc/library/unicodedata.rst
+++ b/Doc/library/unicodedata.rst
@@ -29,6 +29,9 @@
    Look up character by name.  If a character with the given name is found, return
    the corresponding character.  If not found, :exc:`KeyError` is raised.
 
+   .. versionchanged:: 3.3
+      Support for name aliases [#]_ and named sequences [#]_ has been added.
+
 
 .. function:: name(chr[, default])
 
@@ -160,3 +163,9 @@
    >>> unicodedata.bidirectional('\u0660') # 'A'rabic, 'N'umber
    'AN'
 
+
+.. rubric:: Footnotes
+
+.. [#] http://www.unicode.org/Public/6.0.0/ucd/NameAliases.txt
+
+.. [#] http://www.unicode.org/Public/6.0.0/ucd/NamedSequences.txt
diff --git a/Doc/reference/lexical_analysis.rst b/Doc/reference/lexical_analysis.rst
--- a/Doc/reference/lexical_analysis.rst
+++ b/Doc/reference/lexical_analysis.rst
@@ -492,13 +492,13 @@
 +-----------------+---------------------------------+-------+
 | Escape Sequence | Meaning                         | Notes |
 +=================+=================================+=======+
-| ``\N{name}``    | Character named *name* in the   |       |
+| ``\N{name}``    | Character named *name* in the   | \(4)  |
 |                 | Unicode database                |       |
 +-----------------+---------------------------------+-------+
-| ``\uxxxx``      | Character with 16-bit hex value | \(4)  |
+| ``\uxxxx``      | Character with 16-bit hex value | \(5)  |
 |                 | *xxxx*                          |       |
 +-----------------+---------------------------------+-------+
-| ``\Uxxxxxxxx``  | Character with 32-bit hex value | \(5)  |
+| ``\Uxxxxxxxx``  | Character with 32-bit hex value | \(6)  |
 |                 | *xxxxxxxx*                      |       |
 +-----------------+---------------------------------+-------+
 
@@ -516,10 +516,14 @@
    with the given value.
 
 (4)
+   .. versionchanged:: 3.3
+      Support for name aliases [#]_ has been added.
+
+(5)
    Individual code units which form parts of a surrogate pair can be encoded using
    this escape sequence.  Exactly four hex digits are required.
 
-(5)
+(6)
    Any Unicode character can be encoded this way, but characters outside the Basic
    Multilingual Plane (BMP) will be encoded using a surrogate pair if Python is
    compiled to use 16-bit code units (the default).  Exactly eight hex digits
@@ -706,3 +710,8 @@
 occurrence outside string literals and comments is an unconditional error::
 
    $       ?       `
+
+
+.. rubric:: Footnotes
+
+.. [#] http://www.unicode.org/Public/6.0.0/ucd/NameAliases.txt
diff --git a/Lib/test/test_ucn.py b/Lib/test/test_ucn.py
--- a/Lib/test/test_ucn.py
+++ b/Lib/test/test_ucn.py
@@ -8,8 +8,11 @@
 """#"
 
 import unittest
+import unicodedata
 
 from test import support
+from http.client import HTTPException
+from test.test_normalization import check_version
 
 class UnicodeNamesTest(unittest.TestCase):
 
@@ -59,8 +62,6 @@
         )
 
     def test_ascii_letters(self):
-        import unicodedata
-
         for char in "".join(map(chr, range(ord("a"), ord("z")))):
             name = "LATIN SMALL LETTER %s" % char.upper()
             code = unicodedata.lookup(name)
@@ -81,7 +82,6 @@
         self.checkletter("HANGUL SYLLABLE HWEOK", "\ud6f8")
         self.checkletter("HANGUL SYLLABLE HIH", "\ud7a3")
 
-        import unicodedata
         self.assertRaises(ValueError, unicodedata.name, "\ud7a4")
 
     def test_cjk_unified_ideographs(self):
@@ -97,14 +97,11 @@
         self.checkletter("CJK UNIFIED IDEOGRAPH-2B81D", "\U0002B81D")
 
     def test_bmp_characters(self):
-        import unicodedata
-        count = 0
         for code in range(0x10000):
             char = chr(code)
             name = unicodedata.name(char, None)
             if name is not None:
                 self.assertEqual(unicodedata.lookup(name), char)
-                count += 1
 
     def test_misc_symbols(self):
         self.checkletter("PILCROW SIGN", "\u00b6")
@@ -112,8 +109,65 @@
         self.checkletter("HALFWIDTH KATAKANA SEMI-VOICED SOUND MARK", "\uFF9F")
         self.checkletter("FULLWIDTH LATIN SMALL LETTER A", "\uFF41")
 
+    def test_aliases(self):
+        # Check that the aliases defined in the NameAliases.txt file work.
+        # This should be updated when new aliases are added or the file
+        # should be downloaded and parsed instead.  See #12753.
+        aliases = [
+            ('LATIN CAPITAL LETTER GHA', 0x01A2),
+            ('LATIN SMALL LETTER GHA', 0x01A3),
+            ('KANNADA LETTER LLLA', 0x0CDE),
+            ('LAO LETTER FO FON', 0x0E9D),
+            ('LAO LETTER FO FAY', 0x0E9F),
+            ('LAO LETTER RO', 0x0EA3),
+            ('LAO LETTER LO', 0x0EA5),
+            ('TIBETAN MARK BKA- SHOG GI MGO RGYAN', 0x0FD0),
+            ('YI SYLLABLE ITERATION MARK', 0xA015),
+            ('PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRACKET', 0xFE18),
+            ('BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS', 0x1D0C5)
+        ]
+        for alias, codepoint in aliases:
+            self.checkletter(alias, chr(codepoint))
+            name = unicodedata.name(chr(codepoint))
+            self.assertNotEqual(name, alias)
+            self.assertEqual(unicodedata.lookup(alias),
+                             unicodedata.lookup(name))
+
+    def test_named_sequences_sample(self):
+        # Check a few named sequences.  See #12753.
+        sequences = [
+            ('LATIN SMALL LETTER R WITH TILDE', '\u0072\u0303'),
+            ('TAMIL SYLLABLE SAI', '\u0BB8\u0BC8'),
+            ('TAMIL SYLLABLE MOO', '\u0BAE\u0BCB'),
+            ('TAMIL SYLLABLE NNOO', '\u0BA3\u0BCB'),
+            ('TAMIL CONSONANT KSS', '\u0B95\u0BCD\u0BB7\u0BCD'),
+        ]
+        for seqname, codepoints in sequences:
+            self.assertEqual(unicodedata.lookup(seqname), codepoints)
+            with self.assertRaises(SyntaxError):
+                self.checkletter(seqname, None)
+
+    def test_named_sequences_full(self):
+        # Check all the named sequences
+        url = ("http://www.unicode.org/Public/%s/ucd/NamedSequences.txt" %
+               unicodedata.unidata_version)
+        try:
+            testdata = support.open_urlresource(url, encoding="utf-8",
+                                                check=check_version)
+        except (IOError, HTTPException):
+            self.skipTest("Could not retrieve " + url)
+        self.addCleanup(testdata.close)
+        for line in testdata:
+            line = line.strip()
+            if not line or line.startswith('#'):
+                continue
+            seqname, codepoints = line.split(';')
+            codepoints = ''.join(chr(int(cp, 16)) for cp in codepoints.split())
+            self.assertEqual(unicodedata.lookup(seqname), codepoints)
+            with self.assertRaises(SyntaxError):
+                self.checkletter(seqname, None)
+
     def test_errors(self):
-        import unicodedata
         self.assertRaises(TypeError, unicodedata.name)
         self.assertRaises(TypeError, unicodedata.name, 'xx')
         self.assertRaises(TypeError, unicodedata.lookup)
diff --git a/Modules/unicodedata.c b/Modules/unicodedata.c
--- a/Modules/unicodedata.c
+++ b/Modules/unicodedata.c
@@ -1054,7 +1054,7 @@
 static int
 _getcode(PyObject* self, const char* name, int namelen, Py_UCS4* code)
 {
-    unsigned int h, v;
+    unsigned int h, v, k;
     unsigned int mask = code_size-1;
     unsigned int i, incr;
 
@@ -1100,6 +1100,17 @@
         return 1;
     }
 
+    /* check for aliases defined in NameAliases.txt */
+    for (k=0; k<aliases_count; k++) {
+        /* name might not be nul-terminated, so it's necessary to check
+           that the len of the two names is the same before comparing them */
+        if ((name_aliases[k].namelen == namelen) &&
+            (strncmp(name, name_aliases[k].name, namelen) == 0)) {
+            *code = name_aliases[k].codepoint;
+            return 1;
+        }
+    }
+
     /* the following is the same as python's dictionary lookup, with
        only minor changes.  see the makeunicodedata script for more
        details */
@@ -1176,6 +1187,26 @@
     return PyUnicode_FromString(name);
 }
 
+static PyObject *
+_lookup_named_sequences(char* name) {
+    int low, mid, high, cmp;
+    low = 0;
+    high = named_sequences_count;
+    while (low <= high) {
+        mid = (low+high) / 2;
+        cmp = strcmp(name, named_sequences[mid].name);
+        if (cmp < 0)
+            high = mid - 1;
+        else if (cmp > 0)
+            low = mid + 1;
+        else
+            return PyUnicode_FromKindAndData(PyUnicode_2BYTE_KIND,
+                                             named_sequences[mid].seq,
+                                             named_sequences[mid].seqlen);
+    }
+    return NULL;
+}
+
 PyDoc_STRVAR(unicodedata_lookup__doc__,
 "lookup(name)\n\
 \n\
@@ -1187,6 +1218,7 @@
 unicodedata_lookup(PyObject* self, PyObject* args)
 {
     Py_UCS4 code;
+    PyObject *codes; /* for named sequences */
 
     char* name;
     int namelen;
@@ -1194,9 +1226,13 @@
         return NULL;
 
     if (!_getcode(self, name, namelen, &code)) {
-        PyErr_Format(PyExc_KeyError, "undefined character name '%s'",
-                     name);
-        return NULL;
+        /* if the normal lookup fails try with named sequences */
+        codes = _lookup_named_sequences(name);
+        if (codes == NULL) {
+            PyErr_Format(PyExc_KeyError, "undefined character name '%s'", name);
+            return NULL;
+        }
+        return codes;
     }
 
     return PyUnicode_FromOrdinal(code);
diff --git a/Modules/unicodename_db.h b/Modules/unicodename_db.h
--- a/Modules/unicodename_db.h
+++ b/Modules/unicodename_db.h
@@ -18811,3 +18811,452 @@
 #define code_magic 47
 #define code_size 32768
 #define code_poly 32771
+
+typedef struct Alias {
+    char *name;
+    int namelen;
+    int codepoint;
+} alias;
+
+static const int aliases_count = 11;
+static const alias name_aliases[] = {
+    {"LATIN CAPITAL LETTER GHA", 24, 0x01A2},
+    {"LATIN SMALL LETTER GHA", 22, 0x01A3},
+    {"KANNADA LETTER LLLA", 19, 0x0CDE},
+    {"LAO LETTER FO FON", 17, 0x0E9D},
+    {"LAO LETTER FO FAY", 17, 0x0E9F},
+    {"LAO LETTER RO", 13, 0x0EA3},
+    {"LAO LETTER LO", 13, 0x0EA5},
+    {"TIBETAN MARK BKA- SHOG GI MGO RGYAN", 35, 0x0FD0},
+    {"YI SYLLABLE ITERATION MARK", 26, 0xA015},
+    {"PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRACKET", 61, 0xFE18},
+    {"BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS", 52, 0x1D0C5},
+};
+
+typedef struct NamedSequence {
+    char *name;
+    int seqlen;
+    Py_UCS2 seq[4];
+} named_sequence;
+
+static const int named_sequences_count = 418;
+static const named_sequence named_sequences[] = {
+    {"BENGALI LETTER KHINYA", 3, {0x0995, 0x09CD, 0x09B7}},
+    {"GEORGIAN LETTER U-BRJGU", 2, {0x10E3, 0x0302}},
+    {"HIRAGANA LETTER BIDAKUON NGA", 2, {0x304B, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGE", 2, {0x3051, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGI", 2, {0x304D, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGO", 2, {0x3053, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGU", 2, {0x304F, 0x309A}},
+    {"KATAKANA LETTER AINU CE", 2, {0x30BB, 0x309A}},
+    {"KATAKANA LETTER AINU P", 2, {0x31F7, 0x309A}},
+    {"KATAKANA LETTER AINU TO", 2, {0x30C8, 0x309A}},
+    {"KATAKANA LETTER AINU TU", 2, {0x30C4, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGA", 2, {0x30AB, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGE", 2, {0x30B1, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGI", 2, {0x30AD, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGO", 2, {0x30B3, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGU", 2, {0x30AF, 0x309A}},
+    {"KHMER CONSONANT SIGN COENG BA", 2, {0x17D2, 0x1794}},
+    {"KHMER CONSONANT SIGN COENG CA", 2, {0x17D2, 0x1785}},
+    {"KHMER CONSONANT SIGN COENG CHA", 2, {0x17D2, 0x1786}},
+    {"KHMER CONSONANT SIGN COENG CHO", 2, {0x17D2, 0x1788}},
+    {"KHMER CONSONANT SIGN COENG CO", 2, {0x17D2, 0x1787}},
+    {"KHMER CONSONANT SIGN COENG DA", 2, {0x17D2, 0x178A}},
+    {"KHMER CONSONANT SIGN COENG DO", 2, {0x17D2, 0x178C}},
+    {"KHMER CONSONANT SIGN COENG HA", 2, {0x17D2, 0x17A0}},
+    {"KHMER CONSONANT SIGN COENG KA", 2, {0x17D2, 0x1780}},
+    {"KHMER CONSONANT SIGN COENG KHA", 2, {0x17D2, 0x1781}},
+    {"KHMER CONSONANT SIGN COENG KHO", 2, {0x17D2, 0x1783}},
+    {"KHMER CONSONANT SIGN COENG KO", 2, {0x17D2, 0x1782}},
+    {"KHMER CONSONANT SIGN COENG LA", 2, {0x17D2, 0x17A1}},
+    {"KHMER CONSONANT SIGN COENG LO", 2, {0x17D2, 0x179B}},
+    {"KHMER CONSONANT SIGN COENG MO", 2, {0x17D2, 0x1798}},
+    {"KHMER CONSONANT SIGN COENG NA", 2, {0x17D2, 0x178E}},
+    {"KHMER CONSONANT SIGN COENG NGO", 2, {0x17D2, 0x1784}},
+    {"KHMER CONSONANT SIGN COENG NO", 2, {0x17D2, 0x1793}},
+    {"KHMER CONSONANT SIGN COENG NYO", 2, {0x17D2, 0x1789}},
+    {"KHMER CONSONANT SIGN COENG PHA", 2, {0x17D2, 0x1795}},
+    {"KHMER CONSONANT SIGN COENG PHO", 2, {0x17D2, 0x1797}},
+    {"KHMER CONSONANT SIGN COENG PO", 2, {0x17D2, 0x1796}},
+    {"KHMER CONSONANT SIGN COENG RO", 2, {0x17D2, 0x179A}},
+    {"KHMER CONSONANT SIGN COENG SA", 2, {0x17D2, 0x179F}},
+    {"KHMER CONSONANT SIGN COENG SHA", 2, {0x17D2, 0x179D}},
+    {"KHMER CONSONANT SIGN COENG SSA", 2, {0x17D2, 0x179E}},
+    {"KHMER CONSONANT SIGN COENG TA", 2, {0x17D2, 0x178F}},
+    {"KHMER CONSONANT SIGN COENG THA", 2, {0x17D2, 0x1790}},
+    {"KHMER CONSONANT SIGN COENG THO", 2, {0x17D2, 0x1792}},
+    {"KHMER CONSONANT SIGN COENG TO", 2, {0x17D2, 0x1791}},
+    {"KHMER CONSONANT SIGN COENG TTHA", 2, {0x17D2, 0x178B}},
+    {"KHMER CONSONANT SIGN COENG TTHO", 2, {0x17D2, 0x178D}},
+    {"KHMER CONSONANT SIGN COENG VO", 2, {0x17D2, 0x179C}},
+    {"KHMER CONSONANT SIGN COENG YO", 2, {0x17D2, 0x1799}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG QE", 2, {0x17D2, 0x17AF}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG QU", 2, {0x17D2, 0x17A7}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG RY", 2, {0x17D2, 0x17AB}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG RYY", 2, {0x17D2, 0x17AC}},
+    {"KHMER VOWEL SIGN AAM", 2, {0x17B6, 0x17C6}},
+    {"KHMER VOWEL SIGN COENG QA", 2, {0x17D2, 0x17A2}},
+    {"KHMER VOWEL SIGN OM", 2, {0x17BB, 0x17C6}},
+    {"LATIN CAPITAL LETTER A WITH MACRON AND GRAVE", 2, {0x0100, 0x0300}},
+    {"LATIN CAPITAL LETTER A WITH OGONEK AND ACUTE", 2, {0x0104, 0x0301}},
+    {"LATIN CAPITAL LETTER A WITH OGONEK AND TILDE", 2, {0x0104, 0x0303}},
+    {"LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND CARON", 2, {0x00CA, 0x030C}},
+    {"LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND MACRON", 2, {0x00CA, 0x0304}},
+    {"LATIN CAPITAL LETTER E WITH DOT ABOVE AND ACUTE", 2, {0x0116, 0x0301}},
+    {"LATIN CAPITAL LETTER E WITH DOT ABOVE AND TILDE", 2, {0x0116, 0x0303}},
+    {"LATIN CAPITAL LETTER E WITH OGONEK AND ACUTE", 2, {0x0118, 0x0301}},
+    {"LATIN CAPITAL LETTER E WITH OGONEK AND TILDE", 2, {0x0118, 0x0303}},
+    {"LATIN CAPITAL LETTER E WITH VERTICAL LINE BELOW", 2, {0x0045, 0x0329}},
+    {"LATIN CAPITAL LETTER E WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00C9, 0x0329}},
+    {"LATIN CAPITAL LETTER E WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00C8, 0x0329}},
+    {"LATIN CAPITAL LETTER I WITH MACRON AND GRAVE", 2, {0x012A, 0x0300}},
+    {"LATIN CAPITAL LETTER I WITH OGONEK AND ACUTE", 2, {0x012E, 0x0301}},
+    {"LATIN CAPITAL LETTER I WITH OGONEK AND TILDE", 2, {0x012E, 0x0303}},
+    {"LATIN CAPITAL LETTER J WITH TILDE", 2, {0x004A, 0x0303}},
+    {"LATIN CAPITAL LETTER L WITH TILDE", 2, {0x004C, 0x0303}},
+    {"LATIN CAPITAL LETTER M WITH TILDE", 2, {0x004D, 0x0303}},
+    {"LATIN CAPITAL LETTER O WITH VERTICAL LINE BELOW", 2, {0x004F, 0x0329}},
+    {"LATIN CAPITAL LETTER O WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00D3, 0x0329}},
+    {"LATIN CAPITAL LETTER O WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00D2, 0x0329}},
+    {"LATIN CAPITAL LETTER R WITH TILDE", 2, {0x0052, 0x0303}},
+    {"LATIN CAPITAL LETTER S WITH VERTICAL LINE BELOW", 2, {0x0053, 0x0329}},
+    {"LATIN CAPITAL LETTER U WITH MACRON AND ACUTE", 2, {0x016A, 0x0301}},
+    {"LATIN CAPITAL LETTER U WITH MACRON AND GRAVE", 2, {0x016A, 0x0300}},
+    {"LATIN CAPITAL LETTER U WITH MACRON AND TILDE", 2, {0x016A, 0x0303}},
+    {"LATIN CAPITAL LETTER U WITH OGONEK AND ACUTE", 2, {0x0172, 0x0301}},
+    {"LATIN CAPITAL LETTER U WITH OGONEK AND TILDE", 2, {0x0172, 0x0303}},
+    {"LATIN SMALL LETTER A WITH MACRON AND GRAVE", 2, {0x0101, 0x0300}},
+    {"LATIN SMALL LETTER A WITH OGONEK AND ACUTE", 2, {0x0105, 0x0301}},
+    {"LATIN SMALL LETTER A WITH OGONEK AND TILDE", 2, {0x0105, 0x0303}},
+    {"LATIN SMALL LETTER AE WITH GRAVE", 2, {0x00E6, 0x0300}},
+    {"LATIN SMALL LETTER E WITH CIRCUMFLEX AND CARON", 2, {0x00EA, 0x030C}},
+    {"LATIN SMALL LETTER E WITH CIRCUMFLEX AND MACRON", 2, {0x00EA, 0x0304}},
+    {"LATIN SMALL LETTER E WITH DOT ABOVE AND ACUTE", 2, {0x0117, 0x0301}},
+    {"LATIN SMALL LETTER E WITH DOT ABOVE AND TILDE", 2, {0x0117, 0x0303}},
+    {"LATIN SMALL LETTER E WITH OGONEK AND ACUTE", 2, {0x0119, 0x0301}},
+    {"LATIN SMALL LETTER E WITH OGONEK AND TILDE", 2, {0x0119, 0x0303}},
+    {"LATIN SMALL LETTER E WITH VERTICAL LINE BELOW", 2, {0x0065, 0x0329}},
+    {"LATIN SMALL LETTER E WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00E9, 0x0329}},
+    {"LATIN SMALL LETTER E WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00E8, 0x0329}},
+    {"LATIN SMALL LETTER HOOKED SCHWA WITH ACUTE", 2, {0x025A, 0x0301}},
+    {"LATIN SMALL LETTER HOOKED SCHWA WITH GRAVE", 2, {0x025A, 0x0300}},
+    {"LATIN SMALL LETTER I WITH DOT ABOVE AND ACUTE", 3, {0x0069, 0x0307, 0x0301}},
+    {"LATIN SMALL LETTER I WITH DOT ABOVE AND GRAVE", 3, {0x0069, 0x0307, 0x0300}},
+    {"LATIN SMALL LETTER I WITH DOT ABOVE AND TILDE", 3, {0x0069, 0x0307, 0x0303}},
+    {"LATIN SMALL LETTER I WITH MACRON AND GRAVE", 2, {0x012B, 0x0300}},
+    {"LATIN SMALL LETTER I WITH OGONEK AND DOT ABOVE AND ACUTE", 3, {0x012F, 0x0307, 0x0301}},
+    {"LATIN SMALL LETTER I WITH OGONEK AND DOT ABOVE AND TILDE", 3, {0x012F, 0x0307, 0x0303}},
+    {"LATIN SMALL LETTER J WITH DOT ABOVE AND TILDE", 3, {0x006A, 0x0307, 0x0303}},
+    {"LATIN SMALL LETTER L WITH TILDE", 2, {0x006C, 0x0303}},
+    {"LATIN SMALL LETTER M WITH TILDE", 2, {0x006D, 0x0303}},
+    {"LATIN SMALL LETTER NG WITH TILDE ABOVE", 3, {0x006E, 0x0360, 0x0067}},
+    {"LATIN SMALL LETTER O WITH VERTICAL LINE BELOW", 2, {0x006F, 0x0329}},
+    {"LATIN SMALL LETTER O WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00F3, 0x0329}},
+    {"LATIN SMALL LETTER O WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00F2, 0x0329}},
+    {"LATIN SMALL LETTER OPEN O WITH ACUTE", 2, {0x0254, 0x0301}},
+    {"LATIN SMALL LETTER OPEN O WITH GRAVE", 2, {0x0254, 0x0300}},
+    {"LATIN SMALL LETTER R WITH TILDE", 2, {0x0072, 0x0303}},
+    {"LATIN SMALL LETTER S WITH VERTICAL LINE BELOW", 2, {0x0073, 0x0329}},
+    {"LATIN SMALL LETTER SCHWA WITH ACUTE", 2, {0x0259, 0x0301}},
+    {"LATIN SMALL LETTER SCHWA WITH GRAVE", 2, {0x0259, 0x0300}},
+    {"LATIN SMALL LETTER TURNED V WITH ACUTE", 2, {0x028C, 0x0301}},
+    {"LATIN SMALL LETTER TURNED V WITH GRAVE", 2, {0x028C, 0x0300}},
+    {"LATIN SMALL LETTER U WITH MACRON AND ACUTE", 2, {0x016B, 0x0301}},
+    {"LATIN SMALL LETTER U WITH MACRON AND GRAVE", 2, {0x016B, 0x0300}},
+    {"LATIN SMALL LETTER U WITH MACRON AND TILDE", 2, {0x016B, 0x0303}},
+    {"LATIN SMALL LETTER U WITH OGONEK AND ACUTE", 2, {0x0173, 0x0301}},
+    {"LATIN SMALL LETTER U WITH OGONEK AND TILDE", 2, {0x0173, 0x0303}},
+    {"MODIFIER LETTER EXTRA-HIGH EXTRA-LOW CONTOUR TONE BAR", 2, {0x02E5, 0x02E9}},
+    {"MODIFIER LETTER EXTRA-LOW EXTRA-HIGH CONTOUR TONE BAR", 2, {0x02E9, 0x02E5}},
+    {"TAMIL CONSONANT C", 2, {0x0B9A, 0x0BCD}},
+    {"TAMIL CONSONANT H", 2, {0x0BB9, 0x0BCD}},
+    {"TAMIL CONSONANT J", 2, {0x0B9C, 0x0BCD}},
+    {"TAMIL CONSONANT K", 2, {0x0B95, 0x0BCD}},
+    {"TAMIL CONSONANT KSS", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCD}},
+    {"TAMIL CONSONANT L", 2, {0x0BB2, 0x0BCD}},
+    {"TAMIL CONSONANT LL", 2, {0x0BB3, 0x0BCD}},
+    {"TAMIL CONSONANT LLL", 2, {0x0BB4, 0x0BCD}},
+    {"TAMIL CONSONANT M", 2, {0x0BAE, 0x0BCD}},
+    {"TAMIL CONSONANT N", 2, {0x0BA8, 0x0BCD}},
+    {"TAMIL CONSONANT NG", 2, {0x0B99, 0x0BCD}},
+    {"TAMIL CONSONANT NN", 2, {0x0BA3, 0x0BCD}},
+    {"TAMIL CONSONANT NNN", 2, {0x0BA9, 0x0BCD}},
+    {"TAMIL CONSONANT NY", 2, {0x0B9E, 0x0BCD}},
+    {"TAMIL CONSONANT P", 2, {0x0BAA, 0x0BCD}},
+    {"TAMIL CONSONANT R", 2, {0x0BB0, 0x0BCD}},
+    {"TAMIL CONSONANT RR", 2, {0x0BB1, 0x0BCD}},
+    {"TAMIL CONSONANT S", 2, {0x0BB8, 0x0BCD}},
+    {"TAMIL CONSONANT SH", 2, {0x0BB6, 0x0BCD}},
+    {"TAMIL CONSONANT SS", 2, {0x0BB7, 0x0BCD}},
+    {"TAMIL CONSONANT T", 2, {0x0BA4, 0x0BCD}},
+    {"TAMIL CONSONANT TT", 2, {0x0B9F, 0x0BCD}},
+    {"TAMIL CONSONANT V", 2, {0x0BB5, 0x0BCD}},
+    {"TAMIL CONSONANT Y", 2, {0x0BAF, 0x0BCD}},
+    {"TAMIL SYLLABLE CAA", 2, {0x0B9A, 0x0BBE}},
+    {"TAMIL SYLLABLE CAI", 2, {0x0B9A, 0x0BC8}},
+    {"TAMIL SYLLABLE CAU", 2, {0x0B9A, 0x0BCC}},
+    {"TAMIL SYLLABLE CE", 2, {0x0B9A, 0x0BC6}},
+    {"TAMIL SYLLABLE CEE", 2, {0x0B9A, 0x0BC7}},
+    {"TAMIL SYLLABLE CI", 2, {0x0B9A, 0x0BBF}},
+    {"TAMIL SYLLABLE CII", 2, {0x0B9A, 0x0BC0}},
+    {"TAMIL SYLLABLE CO", 2, {0x0B9A, 0x0BCA}},
+    {"TAMIL SYLLABLE COO", 2, {0x0B9A, 0x0BCB}},
+    {"TAMIL SYLLABLE CU", 2, {0x0B9A, 0x0BC1}},
+    {"TAMIL SYLLABLE CUU", 2, {0x0B9A, 0x0BC2}},
+    {"TAMIL SYLLABLE HAA", 2, {0x0BB9, 0x0BBE}},
+    {"TAMIL SYLLABLE HAI", 2, {0x0BB9, 0x0BC8}},
+    {"TAMIL SYLLABLE HAU", 2, {0x0BB9, 0x0BCC}},
+    {"TAMIL SYLLABLE HE", 2, {0x0BB9, 0x0BC6}},
+    {"TAMIL SYLLABLE HEE", 2, {0x0BB9, 0x0BC7}},
+    {"TAMIL SYLLABLE HI", 2, {0x0BB9, 0x0BBF}},
+    {"TAMIL SYLLABLE HII", 2, {0x0BB9, 0x0BC0}},
+    {"TAMIL SYLLABLE HO", 2, {0x0BB9, 0x0BCA}},
+    {"TAMIL SYLLABLE HOO", 2, {0x0BB9, 0x0BCB}},
+    {"TAMIL SYLLABLE HU", 2, {0x0BB9, 0x0BC1}},
+    {"TAMIL SYLLABLE HUU", 2, {0x0BB9, 0x0BC2}},
+    {"TAMIL SYLLABLE JAA", 2, {0x0B9C, 0x0BBE}},
+    {"TAMIL SYLLABLE JAI", 2, {0x0B9C, 0x0BC8}},
+    {"TAMIL SYLLABLE JAU", 2, {0x0B9C, 0x0BCC}},
+    {"TAMIL SYLLABLE JE", 2, {0x0B9C, 0x0BC6}},
+    {"TAMIL SYLLABLE JEE", 2, {0x0B9C, 0x0BC7}},
+    {"TAMIL SYLLABLE JI", 2, {0x0B9C, 0x0BBF}},
+    {"TAMIL SYLLABLE JII", 2, {0x0B9C, 0x0BC0}},
+    {"TAMIL SYLLABLE JO", 2, {0x0B9C, 0x0BCA}},
+    {"TAMIL SYLLABLE JOO", 2, {0x0B9C, 0x0BCB}},
+    {"TAMIL SYLLABLE JU", 2, {0x0B9C, 0x0BC1}},
+    {"TAMIL SYLLABLE JUU", 2, {0x0B9C, 0x0BC2}},
+    {"TAMIL SYLLABLE KAA", 2, {0x0B95, 0x0BBE}},
+    {"TAMIL SYLLABLE KAI", 2, {0x0B95, 0x0BC8}},
+    {"TAMIL SYLLABLE KAU", 2, {0x0B95, 0x0BCC}},
+    {"TAMIL SYLLABLE KE", 2, {0x0B95, 0x0BC6}},
+    {"TAMIL SYLLABLE KEE", 2, {0x0B95, 0x0BC7}},
+    {"TAMIL SYLLABLE KI", 2, {0x0B95, 0x0BBF}},
+    {"TAMIL SYLLABLE KII", 2, {0x0B95, 0x0BC0}},
+    {"TAMIL SYLLABLE KO", 2, {0x0B95, 0x0BCA}},
+    {"TAMIL SYLLABLE KOO", 2, {0x0B95, 0x0BCB}},
+    {"TAMIL SYLLABLE KSSA", 3, {0x0B95, 0x0BCD, 0x0BB7}},
+    {"TAMIL SYLLABLE KSSAA", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BBE}},
+    {"TAMIL SYLLABLE KSSAI", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC8}},
+    {"TAMIL SYLLABLE KSSAU", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCC}},
+    {"TAMIL SYLLABLE KSSE", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC6}},
+    {"TAMIL SYLLABLE KSSEE", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC7}},
+    {"TAMIL SYLLABLE KSSI", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BBF}},
+    {"TAMIL SYLLABLE KSSII", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC0}},
+    {"TAMIL SYLLABLE KSSO", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCA}},
+    {"TAMIL SYLLABLE KSSOO", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCB}},
+    {"TAMIL SYLLABLE KSSU", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC1}},
+    {"TAMIL SYLLABLE KSSUU", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC2}},
+    {"TAMIL SYLLABLE KU", 2, {0x0B95, 0x0BC1}},
+    {"TAMIL SYLLABLE KUU", 2, {0x0B95, 0x0BC2}},
+    {"TAMIL SYLLABLE LAA", 2, {0x0BB2, 0x0BBE}},
+    {"TAMIL SYLLABLE LAI", 2, {0x0BB2, 0x0BC8}},
+    {"TAMIL SYLLABLE LAU", 2, {0x0BB2, 0x0BCC}},
+    {"TAMIL SYLLABLE LE", 2, {0x0BB2, 0x0BC6}},
+    {"TAMIL SYLLABLE LEE", 2, {0x0BB2, 0x0BC7}},
+    {"TAMIL SYLLABLE LI", 2, {0x0BB2, 0x0BBF}},
+    {"TAMIL SYLLABLE LII", 2, {0x0BB2, 0x0BC0}},
+    {"TAMIL SYLLABLE LLAA", 2, {0x0BB3, 0x0BBE}},
+    {"TAMIL SYLLABLE LLAI", 2, {0x0BB3, 0x0BC8}},
+    {"TAMIL SYLLABLE LLAU", 2, {0x0BB3, 0x0BCC}},
+    {"TAMIL SYLLABLE LLE", 2, {0x0BB3, 0x0BC6}},
+    {"TAMIL SYLLABLE LLEE", 2, {0x0BB3, 0x0BC7}},
+    {"TAMIL SYLLABLE LLI", 2, {0x0BB3, 0x0BBF}},
+    {"TAMIL SYLLABLE LLII", 2, {0x0BB3, 0x0BC0}},
+    {"TAMIL SYLLABLE LLLAA", 2, {0x0BB4, 0x0BBE}},
+    {"TAMIL SYLLABLE LLLAI", 2, {0x0BB4, 0x0BC8}},
+    {"TAMIL SYLLABLE LLLAU", 2, {0x0BB4, 0x0BCC}},
+    {"TAMIL SYLLABLE LLLE", 2, {0x0BB4, 0x0BC6}},
+    {"TAMIL SYLLABLE LLLEE", 2, {0x0BB4, 0x0BC7}},
+    {"TAMIL SYLLABLE LLLI", 2, {0x0BB4, 0x0BBF}},
+    {"TAMIL SYLLABLE LLLII", 2, {0x0BB4, 0x0BC0}},
+    {"TAMIL SYLLABLE LLLO", 2, {0x0BB4, 0x0BCA}},
+    {"TAMIL SYLLABLE LLLOO", 2, {0x0BB4, 0x0BCB}},
+    {"TAMIL SYLLABLE LLLU", 2, {0x0BB4, 0x0BC1}},
+    {"TAMIL SYLLABLE LLLUU", 2, {0x0BB4, 0x0BC2}},
+    {"TAMIL SYLLABLE LLO", 2, {0x0BB3, 0x0BCA}},
+    {"TAMIL SYLLABLE LLOO", 2, {0x0BB3, 0x0BCB}},
+    {"TAMIL SYLLABLE LLU", 2, {0x0BB3, 0x0BC1}},
+    {"TAMIL SYLLABLE LLUU", 2, {0x0BB3, 0x0BC2}},
+    {"TAMIL SYLLABLE LO", 2, {0x0BB2, 0x0BCA}},
+    {"TAMIL SYLLABLE LOO", 2, {0x0BB2, 0x0BCB}},
+    {"TAMIL SYLLABLE LU", 2, {0x0BB2, 0x0BC1}},
+    {"TAMIL SYLLABLE LUU", 2, {0x0BB2, 0x0BC2}},
+    {"TAMIL SYLLABLE MAA", 2, {0x0BAE, 0x0BBE}},
+    {"TAMIL SYLLABLE MAI", 2, {0x0BAE, 0x0BC8}},
+    {"TAMIL SYLLABLE MAU", 2, {0x0BAE, 0x0BCC}},
+    {"TAMIL SYLLABLE ME", 2, {0x0BAE, 0x0BC6}},
+    {"TAMIL SYLLABLE MEE", 2, {0x0BAE, 0x0BC7}},
+    {"TAMIL SYLLABLE MI", 2, {0x0BAE, 0x0BBF}},
+    {"TAMIL SYLLABLE MII", 2, {0x0BAE, 0x0BC0}},
+    {"TAMIL SYLLABLE MO", 2, {0x0BAE, 0x0BCA}},
+    {"TAMIL SYLLABLE MOO", 2, {0x0BAE, 0x0BCB}},
+    {"TAMIL SYLLABLE MU", 2, {0x0BAE, 0x0BC1}},
+    {"TAMIL SYLLABLE MUU", 2, {0x0BAE, 0x0BC2}},
+    {"TAMIL SYLLABLE NAA", 2, {0x0BA8, 0x0BBE}},
+    {"TAMIL SYLLABLE NAI", 2, {0x0BA8, 0x0BC8}},
+    {"TAMIL SYLLABLE NAU", 2, {0x0BA8, 0x0BCC}},
+    {"TAMIL SYLLABLE NE", 2, {0x0BA8, 0x0BC6}},
+    {"TAMIL SYLLABLE NEE", 2, {0x0BA8, 0x0BC7}},
+    {"TAMIL SYLLABLE NGAA", 2, {0x0B99, 0x0BBE}},
+    {"TAMIL SYLLABLE NGAI", 2, {0x0B99, 0x0BC8}},
+    {"TAMIL SYLLABLE NGAU", 2, {0x0B99, 0x0BCC}},
+    {"TAMIL SYLLABLE NGE", 2, {0x0B99, 0x0BC6}},
+    {"TAMIL SYLLABLE NGEE", 2, {0x0B99, 0x0BC7}},
+    {"TAMIL SYLLABLE NGI", 2, {0x0B99, 0x0BBF}},
+    {"TAMIL SYLLABLE NGII", 2, {0x0B99, 0x0BC0}},
+    {"TAMIL SYLLABLE NGO", 2, {0x0B99, 0x0BCA}},
+    {"TAMIL SYLLABLE NGOO", 2, {0x0B99, 0x0BCB}},
+    {"TAMIL SYLLABLE NGU", 2, {0x0B99, 0x0BC1}},
+    {"TAMIL SYLLABLE NGUU", 2, {0x0B99, 0x0BC2}},
+    {"TAMIL SYLLABLE NI", 2, {0x0BA8, 0x0BBF}},
+    {"TAMIL SYLLABLE NII", 2, {0x0BA8, 0x0BC0}},
+    {"TAMIL SYLLABLE NNAA", 2, {0x0BA3, 0x0BBE}},
+    {"TAMIL SYLLABLE NNAI", 2, {0x0BA3, 0x0BC8}},
+    {"TAMIL SYLLABLE NNAU", 2, {0x0BA3, 0x0BCC}},
+    {"TAMIL SYLLABLE NNE", 2, {0x0BA3, 0x0BC6}},
+    {"TAMIL SYLLABLE NNEE", 2, {0x0BA3, 0x0BC7}},
+    {"TAMIL SYLLABLE NNI", 2, {0x0BA3, 0x0BBF}},
+    {"TAMIL SYLLABLE NNII", 2, {0x0BA3, 0x0BC0}},
+    {"TAMIL SYLLABLE NNNAA", 2, {0x0BA9, 0x0BBE}},
+    {"TAMIL SYLLABLE NNNAI", 2, {0x0BA9, 0x0BC8}},
+    {"TAMIL SYLLABLE NNNAU", 2, {0x0BA9, 0x0BCC}},
+    {"TAMIL SYLLABLE NNNE", 2, {0x0BA9, 0x0BC6}},
+    {"TAMIL SYLLABLE NNNEE", 2, {0x0BA9, 0x0BC7}},
+    {"TAMIL SYLLABLE NNNI", 2, {0x0BA9, 0x0BBF}},
+    {"TAMIL SYLLABLE NNNII", 2, {0x0BA9, 0x0BC0}},
+    {"TAMIL SYLLABLE NNNO", 2, {0x0BA9, 0x0BCA}},
+    {"TAMIL SYLLABLE NNNOO", 2, {0x0BA9, 0x0BCB}},
+    {"TAMIL SYLLABLE NNNU", 2, {0x0BA9, 0x0BC1}},
+    {"TAMIL SYLLABLE NNNUU", 2, {0x0BA9, 0x0BC2}},
+    {"TAMIL SYLLABLE NNO", 2, {0x0BA3, 0x0BCA}},
+    {"TAMIL SYLLABLE NNOO", 2, {0x0BA3, 0x0BCB}},
+    {"TAMIL SYLLABLE NNU", 2, {0x0BA3, 0x0BC1}},
+    {"TAMIL SYLLABLE NNUU", 2, {0x0BA3, 0x0BC2}},
+    {"TAMIL SYLLABLE NO", 2, {0x0BA8, 0x0BCA}},
+    {"TAMIL SYLLABLE NOO", 2, {0x0BA8, 0x0BCB}},
+    {"TAMIL SYLLABLE NU", 2, {0x0BA8, 0x0BC1}},
+    {"TAMIL SYLLABLE NUU", 2, {0x0BA8, 0x0BC2}},
+    {"TAMIL SYLLABLE NYAA", 2, {0x0B9E, 0x0BBE}},
+    {"TAMIL SYLLABLE NYAI", 2, {0x0B9E, 0x0BC8}},
+    {"TAMIL SYLLABLE NYAU", 2, {0x0B9E, 0x0BCC}},
+    {"TAMIL SYLLABLE NYE", 2, {0x0B9E, 0x0BC6}},
+    {"TAMIL SYLLABLE NYEE", 2, {0x0B9E, 0x0BC7}},
+    {"TAMIL SYLLABLE NYI", 2, {0x0B9E, 0x0BBF}},
+    {"TAMIL SYLLABLE NYII", 2, {0x0B9E, 0x0BC0}},
+    {"TAMIL SYLLABLE NYO", 2, {0x0B9E, 0x0BCA}},
+    {"TAMIL SYLLABLE NYOO", 2, {0x0B9E, 0x0BCB}},
+    {"TAMIL SYLLABLE NYU", 2, {0x0B9E, 0x0BC1}},
+    {"TAMIL SYLLABLE NYUU", 2, {0x0B9E, 0x0BC2}},
+    {"TAMIL SYLLABLE PAA", 2, {0x0BAA, 0x0BBE}},
+    {"TAMIL SYLLABLE PAI", 2, {0x0BAA, 0x0BC8}},
+    {"TAMIL SYLLABLE PAU", 2, {0x0BAA, 0x0BCC}},
+    {"TAMIL SYLLABLE PE", 2, {0x0BAA, 0x0BC6}},
+    {"TAMIL SYLLABLE PEE", 2, {0x0BAA, 0x0BC7}},
+    {"TAMIL SYLLABLE PI", 2, {0x0BAA, 0x0BBF}},
+    {"TAMIL SYLLABLE PII", 2, {0x0BAA, 0x0BC0}},
+    {"TAMIL SYLLABLE PO", 2, {0x0BAA, 0x0BCA}},
+    {"TAMIL SYLLABLE POO", 2, {0x0BAA, 0x0BCB}},
+    {"TAMIL SYLLABLE PU", 2, {0x0BAA, 0x0BC1}},
+    {"TAMIL SYLLABLE PUU", 2, {0x0BAA, 0x0BC2}},
+    {"TAMIL SYLLABLE RAA", 2, {0x0BB0, 0x0BBE}},
+    {"TAMIL SYLLABLE RAI", 2, {0x0BB0, 0x0BC8}},
+    {"TAMIL SYLLABLE RAU", 2, {0x0BB0, 0x0BCC}},
+    {"TAMIL SYLLABLE RE", 2, {0x0BB0, 0x0BC6}},
+    {"TAMIL SYLLABLE REE", 2, {0x0BB0, 0x0BC7}},
+    {"TAMIL SYLLABLE RI", 2, {0x0BB0, 0x0BBF}},
+    {"TAMIL SYLLABLE RII", 2, {0x0BB0, 0x0BC0}},
+    {"TAMIL SYLLABLE RO", 2, {0x0BB0, 0x0BCA}},
+    {"TAMIL SYLLABLE ROO", 2, {0x0BB0, 0x0BCB}},
+    {"TAMIL SYLLABLE RRAA", 2, {0x0BB1, 0x0BBE}},
+    {"TAMIL SYLLABLE RRAI", 2, {0x0BB1, 0x0BC8}},
+    {"TAMIL SYLLABLE RRAU", 2, {0x0BB1, 0x0BCC}},
+    {"TAMIL SYLLABLE RRE", 2, {0x0BB1, 0x0BC6}},
+    {"TAMIL SYLLABLE RREE", 2, {0x0BB1, 0x0BC7}},
+    {"TAMIL SYLLABLE RRI", 2, {0x0BB1, 0x0BBF}},
+    {"TAMIL SYLLABLE RRII", 2, {0x0BB1, 0x0BC0}},
+    {"TAMIL SYLLABLE RRO", 2, {0x0BB1, 0x0BCA}},
+    {"TAMIL SYLLABLE RROO", 2, {0x0BB1, 0x0BCB}},
+    {"TAMIL SYLLABLE RRU", 2, {0x0BB1, 0x0BC1}},
+    {"TAMIL SYLLABLE RRUU", 2, {0x0BB1, 0x0BC2}},
+    {"TAMIL SYLLABLE RU", 2, {0x0BB0, 0x0BC1}},
+    {"TAMIL SYLLABLE RUU", 2, {0x0BB0, 0x0BC2}},
+    {"TAMIL SYLLABLE SAA", 2, {0x0BB8, 0x0BBE}},
+    {"TAMIL SYLLABLE SAI", 2, {0x0BB8, 0x0BC8}},
+    {"TAMIL SYLLABLE SAU", 2, {0x0BB8, 0x0BCC}},
+    {"TAMIL SYLLABLE SE", 2, {0x0BB8, 0x0BC6}},
+    {"TAMIL SYLLABLE SEE", 2, {0x0BB8, 0x0BC7}},
+    {"TAMIL SYLLABLE SHAA", 2, {0x0BB6, 0x0BBE}},
+    {"TAMIL SYLLABLE SHAI", 2, {0x0BB6, 0x0BC8}},
+    {"TAMIL SYLLABLE SHAU", 2, {0x0BB6, 0x0BCC}},
+    {"TAMIL SYLLABLE SHE", 2, {0x0BB6, 0x0BC6}},
+    {"TAMIL SYLLABLE SHEE", 2, {0x0BB6, 0x0BC7}},
+    {"TAMIL SYLLABLE SHI", 2, {0x0BB6, 0x0BBF}},
+    {"TAMIL SYLLABLE SHII", 2, {0x0BB6, 0x0BC0}},
+    {"TAMIL SYLLABLE SHO", 2, {0x0BB6, 0x0BCA}},
+    {"TAMIL SYLLABLE SHOO", 2, {0x0BB6, 0x0BCB}},
+    {"TAMIL SYLLABLE SHRII", 4, {0x0BB6, 0x0BCD, 0x0BB0, 0x0BC0}},
+    {"TAMIL SYLLABLE SHU", 2, {0x0BB6, 0x0BC1}},
+    {"TAMIL SYLLABLE SHUU", 2, {0x0BB6, 0x0BC2}},
+    {"TAMIL SYLLABLE SI", 2, {0x0BB8, 0x0BBF}},
+    {"TAMIL SYLLABLE SII", 2, {0x0BB8, 0x0BC0}},
+    {"TAMIL SYLLABLE SO", 2, {0x0BB8, 0x0BCA}},
+    {"TAMIL SYLLABLE SOO", 2, {0x0BB8, 0x0BCB}},
+    {"TAMIL SYLLABLE SSAA", 2, {0x0BB7, 0x0BBE}},
+    {"TAMIL SYLLABLE SSAI", 2, {0x0BB7, 0x0BC8}},
+    {"TAMIL SYLLABLE SSAU", 2, {0x0BB7, 0x0BCC}},
+    {"TAMIL SYLLABLE SSE", 2, {0x0BB7, 0x0BC6}},
+    {"TAMIL SYLLABLE SSEE", 2, {0x0BB7, 0x0BC7}},
+    {"TAMIL SYLLABLE SSI", 2, {0x0BB7, 0x0BBF}},
+    {"TAMIL SYLLABLE SSII", 2, {0x0BB7, 0x0BC0}},
+    {"TAMIL SYLLABLE SSO", 2, {0x0BB7, 0x0BCA}},
+    {"TAMIL SYLLABLE SSOO", 2, {0x0BB7, 0x0BCB}},
+    {"TAMIL SYLLABLE SSU", 2, {0x0BB7, 0x0BC1}},
+    {"TAMIL SYLLABLE SSUU", 2, {0x0BB7, 0x0BC2}},
+    {"TAMIL SYLLABLE SU", 2, {0x0BB8, 0x0BC1}},
+    {"TAMIL SYLLABLE SUU", 2, {0x0BB8, 0x0BC2}},
+    {"TAMIL SYLLABLE TAA", 2, {0x0BA4, 0x0BBE}},
+    {"TAMIL SYLLABLE TAI", 2, {0x0BA4, 0x0BC8}},
+    {"TAMIL SYLLABLE TAU", 2, {0x0BA4, 0x0BCC}},
+    {"TAMIL SYLLABLE TE", 2, {0x0BA4, 0x0BC6}},
+    {"TAMIL SYLLABLE TEE", 2, {0x0BA4, 0x0BC7}},
+    {"TAMIL SYLLABLE TI", 2, {0x0BA4, 0x0BBF}},
+    {"TAMIL SYLLABLE TII", 2, {0x0BA4, 0x0BC0}},
+    {"TAMIL SYLLABLE TO", 2, {0x0BA4, 0x0BCA}},
+    {"TAMIL SYLLABLE TOO", 2, {0x0BA4, 0x0BCB}},
+    {"TAMIL SYLLABLE TTAA", 2, {0x0B9F, 0x0BBE}},
+    {"TAMIL SYLLABLE TTAI", 2, {0x0B9F, 0x0BC8}},
+    {"TAMIL SYLLABLE TTAU", 2, {0x0B9F, 0x0BCC}},
+    {"TAMIL SYLLABLE TTE", 2, {0x0B9F, 0x0BC6}},
+    {"TAMIL SYLLABLE TTEE", 2, {0x0B9F, 0x0BC7}},
+    {"TAMIL SYLLABLE TTI", 2, {0x0B9F, 0x0BBF}},
+    {"TAMIL SYLLABLE TTII", 2, {0x0B9F, 0x0BC0}},
+    {"TAMIL SYLLABLE TTO", 2, {0x0B9F, 0x0BCA}},
+    {"TAMIL SYLLABLE TTOO", 2, {0x0B9F, 0x0BCB}},
+    {"TAMIL SYLLABLE TTU", 2, {0x0B9F, 0x0BC1}},
+    {"TAMIL SYLLABLE TTUU", 2, {0x0B9F, 0x0BC2}},
+    {"TAMIL SYLLABLE TU", 2, {0x0BA4, 0x0BC1}},
+    {"TAMIL SYLLABLE TUU", 2, {0x0BA4, 0x0BC2}},
+    {"TAMIL SYLLABLE VAA", 2, {0x0BB5, 0x0BBE}},
+    {"TAMIL SYLLABLE VAI", 2, {0x0BB5, 0x0BC8}},
+    {"TAMIL SYLLABLE VAU", 2, {0x0BB5, 0x0BCC}},
+    {"TAMIL SYLLABLE VE", 2, {0x0BB5, 0x0BC6}},
+    {"TAMIL SYLLABLE VEE", 2, {0x0BB5, 0x0BC7}},
+    {"TAMIL SYLLABLE VI", 2, {0x0BB5, 0x0BBF}},
+    {"TAMIL SYLLABLE VII", 2, {0x0BB5, 0x0BC0}},
+    {"TAMIL SYLLABLE VO", 2, {0x0BB5, 0x0BCA}},
+    {"TAMIL SYLLABLE VOO", 2, {0x0BB5, 0x0BCB}},
+    {"TAMIL SYLLABLE VU", 2, {0x0BB5, 0x0BC1}},
+    {"TAMIL SYLLABLE VUU", 2, {0x0BB5, 0x0BC2}},
+    {"TAMIL SYLLABLE YAA", 2, {0x0BAF, 0x0BBE}},
+    {"TAMIL SYLLABLE YAI", 2, {0x0BAF, 0x0BC8}},
+    {"TAMIL SYLLABLE YAU", 2, {0x0BAF, 0x0BCC}},
+    {"TAMIL SYLLABLE YE", 2, {0x0BAF, 0x0BC6}},
+    {"TAMIL SYLLABLE YEE", 2, {0x0BAF, 0x0BC7}},
+    {"TAMIL SYLLABLE YI", 2, {0x0BAF, 0x0BBF}},
+    {"TAMIL SYLLABLE YII", 2, {0x0BAF, 0x0BC0}},
+    {"TAMIL SYLLABLE YO", 2, {0x0BAF, 0x0BCA}},
+    {"TAMIL SYLLABLE YOO", 2, {0x0BAF, 0x0BCB}},
+    {"TAMIL SYLLABLE YU", 2, {0x0BAF, 0x0BC1}},
+    {"TAMIL SYLLABLE YUU", 2, {0x0BAF, 0x0BC2}},
+};
diff --git a/Tools/unicode/makeunicodedata.py b/Tools/unicode/makeunicodedata.py
--- a/Tools/unicode/makeunicodedata.py
+++ b/Tools/unicode/makeunicodedata.py
@@ -25,7 +25,12 @@
 # written by Fredrik Lundh (fredrik at pythonware.com)
 #
 
-import sys, os, zipfile
+import os
+import sys
+import zipfile
+
+from textwrap import dedent
+from operator import itemgetter
 
 SCRIPT = sys.argv[0]
 VERSION = "3.2"
@@ -39,6 +44,8 @@
 DERIVED_CORE_PROPERTIES = "DerivedCoreProperties%s.txt"
 DERIVEDNORMALIZATION_PROPS = "DerivedNormalizationProps%s.txt"
 LINE_BREAK = "LineBreak%s.txt"
+NAME_ALIASES = "NameAliases%s.txt"
+NAMED_SEQUENCES = "NamedSequences%s.txt"
 
 old_versions = ["3.2.0"]
 
@@ -692,6 +699,40 @@
     print("/* name->code dictionary */", file=fp)
     codehash.dump(fp, trace)
 
+    print(dedent("""
+        typedef struct Alias {
+            char *name;
+            int namelen;
+            int codepoint;
+        } alias;
+        """), file=fp)
+
+    print('static const int aliases_count = %d;' % len(unicode.aliases), file=fp)
+
+    print('static const alias name_aliases[] = {', file=fp)
+    for name, codepoint in unicode.aliases:
+        print('    {"%s", %d, 0x%04X},' % (name, len(name), codepoint), file=fp)
+    print('};', file=fp)
+
+    # the Py_UCS2 seq[4] should use Py_UCS4 if non-BMP chars are added to the
+    # sequences and have an higher number of elements if the sequences get longer
+    print(dedent("""
+        typedef struct NamedSequence {
+            char *name;
+            int seqlen;
+            Py_UCS2 seq[4];
+        } named_sequence;
+        """), file=fp)
+
+    print('static const int named_sequences_count = %d;' % len(unicode.named_sequences),
+          file=fp)
+
+    print('static const named_sequence named_sequences[] = {', file=fp)
+    for name, sequence in unicode.named_sequences:
+        seq_str = ', '.join('0x%04X' % cp for cp in sequence)
+        print('    {"%s", %d, {%s}},' % (name, len(sequence), seq_str), file=fp)
+    print('};', file=fp)
+
     fp.close()
 
 
@@ -855,6 +896,31 @@
         self.table = table
         self.chars = list(range(0x110000)) # unicode 3.2
 
+        self.aliases = []
+        with open_data(NAME_ALIASES, version) as file:
+            for s in file:
+                s = s.strip()
+                if not s or s.startswith('#'):
+                    continue
+                char, name = s.split(';')
+                char = int(char, 16)
+                self.aliases.append((name, char))
+
+        self.named_sequences = []
+        with open_data(NAMED_SEQUENCES, version) as file:
+            for s in file:
+                s = s.strip()
+                if not s or s.startswith('#'):
+                    continue
+                name, chars = s.split(';')
+                chars = tuple(int(char, 16) for char in chars.split())
+                # check that the structure defined in makeunicodename is OK
+                assert 2 <= len(chars) <= 4, "change the Py_UCS2 array size"
+                assert all(c <= 0xFFFF for c in chars), "use Py_UCS4 instead"
+                self.named_sequences.append((name, chars))
+        # sort names to enable binary search
+        self.named_sequences.sort(key=itemgetter(0))
+
         self.exclusions = {}
         with open_data(COMPOSITION_EXCLUSIONS, version) as file:
             for s in file:

From report at bugs.python.org  Thu Oct  6 12:48:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 06 Oct 2011 10:48:52 +0000
Subject: [issue2771] Test issue
In-Reply-To: <CACBhJdHuMXjZiNGwLdC_pc3Gyo0dwmtdPs7nafgcnP4mL886aQ@mail.gmail.com>
Message-ID: <CACBhJdFmcQJb5BarQ26N_2k0DCKKk24+5JhOZc+A0yHVy_ky0w@mail.gmail.com>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

test attachments

----------
Added file: http://bugs.python.org/file23324/issue12753-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/unicodedata.rst b/Doc/library/unicodedata.rst
--- a/Doc/library/unicodedata.rst
+++ b/Doc/library/unicodedata.rst
@@ -29,6 +29,9 @@
    Look up character by name.  If a character with the given name is found, return
    the corresponding character.  If not found, :exc:`KeyError` is raised.
 
+   .. versionchanged:: 3.3
+      Support for name aliases [#]_ and named sequences [#]_ has been added.
+
 
 .. function:: name(chr[, default])
 
@@ -160,3 +163,9 @@
    >>> unicodedata.bidirectional('\u0660') # 'A'rabic, 'N'umber
    'AN'
 
+
+.. rubric:: Footnotes
+
+.. [#] http://www.unicode.org/Public/6.0.0/ucd/NameAliases.txt
+
+.. [#] http://www.unicode.org/Public/6.0.0/ucd/NamedSequences.txt
diff --git a/Doc/reference/lexical_analysis.rst b/Doc/reference/lexical_analysis.rst
--- a/Doc/reference/lexical_analysis.rst
+++ b/Doc/reference/lexical_analysis.rst
@@ -492,13 +492,13 @@
 +-----------------+---------------------------------+-------+
 | Escape Sequence | Meaning                         | Notes |
 +=================+=================================+=======+
-| ``\N{name}``    | Character named *name* in the   |       |
+| ``\N{name}``    | Character named *name* in the   | \(4)  |
 |                 | Unicode database                |       |
 +-----------------+---------------------------------+-------+
-| ``\uxxxx``      | Character with 16-bit hex value | \(4)  |
+| ``\uxxxx``      | Character with 16-bit hex value | \(5)  |
 |                 | *xxxx*                          |       |
 +-----------------+---------------------------------+-------+
-| ``\Uxxxxxxxx``  | Character with 32-bit hex value | \(5)  |
+| ``\Uxxxxxxxx``  | Character with 32-bit hex value | \(6)  |
 |                 | *xxxxxxxx*                      |       |
 +-----------------+---------------------------------+-------+
 
@@ -516,10 +516,14 @@
    with the given value.
 
 (4)
+   .. versionchanged:: 3.3
+      Support for name aliases [#]_ has been added.
+
+(5)
    Individual code units which form parts of a surrogate pair can be encoded using
    this escape sequence.  Exactly four hex digits are required.
 
-(5)
+(6)
    Any Unicode character can be encoded this way, but characters outside the Basic
    Multilingual Plane (BMP) will be encoded using a surrogate pair if Python is
    compiled to use 16-bit code units (the default).  Exactly eight hex digits
@@ -706,3 +710,8 @@
 occurrence outside string literals and comments is an unconditional error::
 
    $       ?       `
+
+
+.. rubric:: Footnotes
+
+.. [#] http://www.unicode.org/Public/6.0.0/ucd/NameAliases.txt
diff --git a/Lib/test/test_ucn.py b/Lib/test/test_ucn.py
--- a/Lib/test/test_ucn.py
+++ b/Lib/test/test_ucn.py
@@ -8,8 +8,11 @@
 """#"
 
 import unittest
+import unicodedata
 
 from test import support
+from http.client import HTTPException
+from test.test_normalization import check_version
 
 class UnicodeNamesTest(unittest.TestCase):
 
@@ -59,8 +62,6 @@
         )
 
     def test_ascii_letters(self):
-        import unicodedata
-
         for char in "".join(map(chr, range(ord("a"), ord("z")))):
             name = "LATIN SMALL LETTER %s" % char.upper()
             code = unicodedata.lookup(name)
@@ -81,7 +82,6 @@
         self.checkletter("HANGUL SYLLABLE HWEOK", "\ud6f8")
         self.checkletter("HANGUL SYLLABLE HIH", "\ud7a3")
 
-        import unicodedata
         self.assertRaises(ValueError, unicodedata.name, "\ud7a4")
 
     def test_cjk_unified_ideographs(self):
@@ -97,14 +97,11 @@
         self.checkletter("CJK UNIFIED IDEOGRAPH-2B81D", "\U0002B81D")
 
     def test_bmp_characters(self):
-        import unicodedata
-        count = 0
         for code in range(0x10000):
             char = chr(code)
             name = unicodedata.name(char, None)
             if name is not None:
                 self.assertEqual(unicodedata.lookup(name), char)
-                count += 1
 
     def test_misc_symbols(self):
         self.checkletter("PILCROW SIGN", "\u00b6")
@@ -112,8 +109,65 @@
         self.checkletter("HALFWIDTH KATAKANA SEMI-VOICED SOUND MARK", "\uFF9F")
         self.checkletter("FULLWIDTH LATIN SMALL LETTER A", "\uFF41")
 
+    def test_aliases(self):
+        # Check that the aliases defined in the NameAliases.txt file work.
+        # This should be updated when new aliases are added or the file
+        # should be downloaded and parsed instead.  See #12753.
+        aliases = [
+            ('LATIN CAPITAL LETTER GHA', 0x01A2),
+            ('LATIN SMALL LETTER GHA', 0x01A3),
+            ('KANNADA LETTER LLLA', 0x0CDE),
+            ('LAO LETTER FO FON', 0x0E9D),
+            ('LAO LETTER FO FAY', 0x0E9F),
+            ('LAO LETTER RO', 0x0EA3),
+            ('LAO LETTER LO', 0x0EA5),
+            ('TIBETAN MARK BKA- SHOG GI MGO RGYAN', 0x0FD0),
+            ('YI SYLLABLE ITERATION MARK', 0xA015),
+            ('PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRACKET', 0xFE18),
+            ('BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS', 0x1D0C5)
+        ]
+        for alias, codepoint in aliases:
+            self.checkletter(alias, chr(codepoint))
+            name = unicodedata.name(chr(codepoint))
+            self.assertNotEqual(name, alias)
+            self.assertEqual(unicodedata.lookup(alias),
+                             unicodedata.lookup(name))
+
+    def test_named_sequences_sample(self):
+        # Check a few named sequences.  See #12753.
+        sequences = [
+            ('LATIN SMALL LETTER R WITH TILDE', '\u0072\u0303'),
+            ('TAMIL SYLLABLE SAI', '\u0BB8\u0BC8'),
+            ('TAMIL SYLLABLE MOO', '\u0BAE\u0BCB'),
+            ('TAMIL SYLLABLE NNOO', '\u0BA3\u0BCB'),
+            ('TAMIL CONSONANT KSS', '\u0B95\u0BCD\u0BB7\u0BCD'),
+        ]
+        for seqname, codepoints in sequences:
+            self.assertEqual(unicodedata.lookup(seqname), codepoints)
+            with self.assertRaises(SyntaxError):
+                self.checkletter(seqname, None)
+
+    def test_named_sequences_full(self):
+        # Check all the named sequences
+        url = ("http://www.unicode.org/Public/%s/ucd/NamedSequences.txt" %
+               unicodedata.unidata_version)
+        try:
+            testdata = support.open_urlresource(url, encoding="utf-8",
+                                                check=check_version)
+        except (IOError, HTTPException):
+            self.skipTest("Could not retrieve " + url)
+        self.addCleanup(testdata.close)
+        for line in testdata:
+            line = line.strip()
+            if not line or line.startswith('#'):
+                continue
+            seqname, codepoints = line.split(';')
+            codepoints = ''.join(chr(int(cp, 16)) for cp in codepoints.split())
+            self.assertEqual(unicodedata.lookup(seqname), codepoints)
+            with self.assertRaises(SyntaxError):
+                self.checkletter(seqname, None)
+
     def test_errors(self):
-        import unicodedata
         self.assertRaises(TypeError, unicodedata.name)
         self.assertRaises(TypeError, unicodedata.name, 'xx')
         self.assertRaises(TypeError, unicodedata.lookup)
diff --git a/Modules/unicodedata.c b/Modules/unicodedata.c
--- a/Modules/unicodedata.c
+++ b/Modules/unicodedata.c
@@ -1054,7 +1054,7 @@
 static int
 _getcode(PyObject* self, const char* name, int namelen, Py_UCS4* code)
 {
-    unsigned int h, v;
+    unsigned int h, v, k;
     unsigned int mask = code_size-1;
     unsigned int i, incr;
 
@@ -1100,6 +1100,17 @@
         return 1;
     }
 
+    /* check for aliases defined in NameAliases.txt */
+    for (k=0; k<aliases_count; k++) {
+        /* name might not be nul-terminated, so it's necessary to check
+           that the len of the two names is the same before comparing them */
+        if ((name_aliases[k].namelen == namelen) &&
+            (strncmp(name, name_aliases[k].name, namelen) == 0)) {
+            *code = name_aliases[k].codepoint;
+            return 1;
+        }
+    }
+
     /* the following is the same as python's dictionary lookup, with
        only minor changes.  see the makeunicodedata script for more
        details */
@@ -1176,6 +1187,26 @@
     return PyUnicode_FromString(name);
 }
 
+static PyObject *
+_lookup_named_sequences(char* name) {
+    int low, mid, high, cmp;
+    low = 0;
+    high = named_sequences_count;
+    while (low <= high) {
+        mid = (low+high) / 2;
+        cmp = strcmp(name, named_sequences[mid].name);
+        if (cmp < 0)
+            high = mid - 1;
+        else if (cmp > 0)
+            low = mid + 1;
+        else
+            return PyUnicode_FromKindAndData(PyUnicode_2BYTE_KIND,
+                                             named_sequences[mid].seq,
+                                             named_sequences[mid].seqlen);
+    }
+    return NULL;
+}
+
 PyDoc_STRVAR(unicodedata_lookup__doc__,
 "lookup(name)\n\
 \n\
@@ -1187,6 +1218,7 @@
 unicodedata_lookup(PyObject* self, PyObject* args)
 {
     Py_UCS4 code;
+    PyObject *codes; /* for named sequences */
 
     char* name;
     int namelen;
@@ -1194,9 +1226,13 @@
         return NULL;
 
     if (!_getcode(self, name, namelen, &code)) {
-        PyErr_Format(PyExc_KeyError, "undefined character name '%s'",
-                     name);
-        return NULL;
+        /* if the normal lookup fails try with named sequences */
+        codes = _lookup_named_sequences(name);
+        if (codes == NULL) {
+            PyErr_Format(PyExc_KeyError, "undefined character name '%s'", name);
+            return NULL;
+        }
+        return codes;
     }
 
     return PyUnicode_FromOrdinal(code);
diff --git a/Modules/unicodename_db.h b/Modules/unicodename_db.h
--- a/Modules/unicodename_db.h
+++ b/Modules/unicodename_db.h
@@ -18811,3 +18811,452 @@
 #define code_magic 47
 #define code_size 32768
 #define code_poly 32771
+
+typedef struct Alias {
+    char *name;
+    int namelen;
+    int codepoint;
+} alias;
+
+static const int aliases_count = 11;
+static const alias name_aliases[] = {
+    {"LATIN CAPITAL LETTER GHA", 24, 0x01A2},
+    {"LATIN SMALL LETTER GHA", 22, 0x01A3},
+    {"KANNADA LETTER LLLA", 19, 0x0CDE},
+    {"LAO LETTER FO FON", 17, 0x0E9D},
+    {"LAO LETTER FO FAY", 17, 0x0E9F},
+    {"LAO LETTER RO", 13, 0x0EA3},
+    {"LAO LETTER LO", 13, 0x0EA5},
+    {"TIBETAN MARK BKA- SHOG GI MGO RGYAN", 35, 0x0FD0},
+    {"YI SYLLABLE ITERATION MARK", 26, 0xA015},
+    {"PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRACKET", 61, 0xFE18},
+    {"BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS", 52, 0x1D0C5},
+};
+
+typedef struct NamedSequence {
+    char *name;
+    int seqlen;
+    Py_UCS2 seq[4];
+} named_sequence;
+
+static const int named_sequences_count = 418;
+static const named_sequence named_sequences[] = {
+    {"BENGALI LETTER KHINYA", 3, {0x0995, 0x09CD, 0x09B7}},
+    {"GEORGIAN LETTER U-BRJGU", 2, {0x10E3, 0x0302}},
+    {"HIRAGANA LETTER BIDAKUON NGA", 2, {0x304B, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGE", 2, {0x3051, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGI", 2, {0x304D, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGO", 2, {0x3053, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGU", 2, {0x304F, 0x309A}},
+    {"KATAKANA LETTER AINU CE", 2, {0x30BB, 0x309A}},
+    {"KATAKANA LETTER AINU P", 2, {0x31F7, 0x309A}},
+    {"KATAKANA LETTER AINU TO", 2, {0x30C8, 0x309A}},
+    {"KATAKANA LETTER AINU TU", 2, {0x30C4, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGA", 2, {0x30AB, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGE", 2, {0x30B1, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGI", 2, {0x30AD, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGO", 2, {0x30B3, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGU", 2, {0x30AF, 0x309A}},
+    {"KHMER CONSONANT SIGN COENG BA", 2, {0x17D2, 0x1794}},
+    {"KHMER CONSONANT SIGN COENG CA", 2, {0x17D2, 0x1785}},
+    {"KHMER CONSONANT SIGN COENG CHA", 2, {0x17D2, 0x1786}},
+    {"KHMER CONSONANT SIGN COENG CHO", 2, {0x17D2, 0x1788}},
+    {"KHMER CONSONANT SIGN COENG CO", 2, {0x17D2, 0x1787}},
+    {"KHMER CONSONANT SIGN COENG DA", 2, {0x17D2, 0x178A}},
+    {"KHMER CONSONANT SIGN COENG DO", 2, {0x17D2, 0x178C}},
+    {"KHMER CONSONANT SIGN COENG HA", 2, {0x17D2, 0x17A0}},
+    {"KHMER CONSONANT SIGN COENG KA", 2, {0x17D2, 0x1780}},
+    {"KHMER CONSONANT SIGN COENG KHA", 2, {0x17D2, 0x1781}},
+    {"KHMER CONSONANT SIGN COENG KHO", 2, {0x17D2, 0x1783}},
+    {"KHMER CONSONANT SIGN COENG KO", 2, {0x17D2, 0x1782}},
+    {"KHMER CONSONANT SIGN COENG LA", 2, {0x17D2, 0x17A1}},
+    {"KHMER CONSONANT SIGN COENG LO", 2, {0x17D2, 0x179B}},
+    {"KHMER CONSONANT SIGN COENG MO", 2, {0x17D2, 0x1798}},
+    {"KHMER CONSONANT SIGN COENG NA", 2, {0x17D2, 0x178E}},
+    {"KHMER CONSONANT SIGN COENG NGO", 2, {0x17D2, 0x1784}},
+    {"KHMER CONSONANT SIGN COENG NO", 2, {0x17D2, 0x1793}},
+    {"KHMER CONSONANT SIGN COENG NYO", 2, {0x17D2, 0x1789}},
+    {"KHMER CONSONANT SIGN COENG PHA", 2, {0x17D2, 0x1795}},
+    {"KHMER CONSONANT SIGN COENG PHO", 2, {0x17D2, 0x1797}},
+    {"KHMER CONSONANT SIGN COENG PO", 2, {0x17D2, 0x1796}},
+    {"KHMER CONSONANT SIGN COENG RO", 2, {0x17D2, 0x179A}},
+    {"KHMER CONSONANT SIGN COENG SA", 2, {0x17D2, 0x179F}},
+    {"KHMER CONSONANT SIGN COENG SHA", 2, {0x17D2, 0x179D}},
+    {"KHMER CONSONANT SIGN COENG SSA", 2, {0x17D2, 0x179E}},
+    {"KHMER CONSONANT SIGN COENG TA", 2, {0x17D2, 0x178F}},
+    {"KHMER CONSONANT SIGN COENG THA", 2, {0x17D2, 0x1790}},
+    {"KHMER CONSONANT SIGN COENG THO", 2, {0x17D2, 0x1792}},
+    {"KHMER CONSONANT SIGN COENG TO", 2, {0x17D2, 0x1791}},
+    {"KHMER CONSONANT SIGN COENG TTHA", 2, {0x17D2, 0x178B}},
+    {"KHMER CONSONANT SIGN COENG TTHO", 2, {0x17D2, 0x178D}},
+    {"KHMER CONSONANT SIGN COENG VO", 2, {0x17D2, 0x179C}},
+    {"KHMER CONSONANT SIGN COENG YO", 2, {0x17D2, 0x1799}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG QE", 2, {0x17D2, 0x17AF}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG QU", 2, {0x17D2, 0x17A7}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG RY", 2, {0x17D2, 0x17AB}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG RYY", 2, {0x17D2, 0x17AC}},
+    {"KHMER VOWEL SIGN AAM", 2, {0x17B6, 0x17C6}},
+    {"KHMER VOWEL SIGN COENG QA", 2, {0x17D2, 0x17A2}},
+    {"KHMER VOWEL SIGN OM", 2, {0x17BB, 0x17C6}},
+    {"LATIN CAPITAL LETTER A WITH MACRON AND GRAVE", 2, {0x0100, 0x0300}},
+    {"LATIN CAPITAL LETTER A WITH OGONEK AND ACUTE", 2, {0x0104, 0x0301}},
+    {"LATIN CAPITAL LETTER A WITH OGONEK AND TILDE", 2, {0x0104, 0x0303}},
+    {"LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND CARON", 2, {0x00CA, 0x030C}},
+    {"LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND MACRON", 2, {0x00CA, 0x0304}},
+    {"LATIN CAPITAL LETTER E WITH DOT ABOVE AND ACUTE", 2, {0x0116, 0x0301}},
+    {"LATIN CAPITAL LETTER E WITH DOT ABOVE AND TILDE", 2, {0x0116, 0x0303}},
+    {"LATIN CAPITAL LETTER E WITH OGONEK AND ACUTE", 2, {0x0118, 0x0301}},
+    {"LATIN CAPITAL LETTER E WITH OGONEK AND TILDE", 2, {0x0118, 0x0303}},
+    {"LATIN CAPITAL LETTER E WITH VERTICAL LINE BELOW", 2, {0x0045, 0x0329}},
+    {"LATIN CAPITAL LETTER E WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00C9, 0x0329}},
+    {"LATIN CAPITAL LETTER E WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00C8, 0x0329}},
+    {"LATIN CAPITAL LETTER I WITH MACRON AND GRAVE", 2, {0x012A, 0x0300}},
+    {"LATIN CAPITAL LETTER I WITH OGONEK AND ACUTE", 2, {0x012E, 0x0301}},
+    {"LATIN CAPITAL LETTER I WITH OGONEK AND TILDE", 2, {0x012E, 0x0303}},
+    {"LATIN CAPITAL LETTER J WITH TILDE", 2, {0x004A, 0x0303}},
+    {"LATIN CAPITAL LETTER L WITH TILDE", 2, {0x004C, 0x0303}},
+    {"LATIN CAPITAL LETTER M WITH TILDE", 2, {0x004D, 0x0303}},
+    {"LATIN CAPITAL LETTER O WITH VERTICAL LINE BELOW", 2, {0x004F, 0x0329}},
+    {"LATIN CAPITAL LETTER O WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00D3, 0x0329}},
+    {"LATIN CAPITAL LETTER O WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00D2, 0x0329}},
+    {"LATIN CAPITAL LETTER R WITH TILDE", 2, {0x0052, 0x0303}},
+    {"LATIN CAPITAL LETTER S WITH VERTICAL LINE BELOW", 2, {0x0053, 0x0329}},
+    {"LATIN CAPITAL LETTER U WITH MACRON AND ACUTE", 2, {0x016A, 0x0301}},
+    {"LATIN CAPITAL LETTER U WITH MACRON AND GRAVE", 2, {0x016A, 0x0300}},
+    {"LATIN CAPITAL LETTER U WITH MACRON AND TILDE", 2, {0x016A, 0x0303}},
+    {"LATIN CAPITAL LETTER U WITH OGONEK AND ACUTE", 2, {0x0172, 0x0301}},
+    {"LATIN CAPITAL LETTER U WITH OGONEK AND TILDE", 2, {0x0172, 0x0303}},
+    {"LATIN SMALL LETTER A WITH MACRON AND GRAVE", 2, {0x0101, 0x0300}},
+    {"LATIN SMALL LETTER A WITH OGONEK AND ACUTE", 2, {0x0105, 0x0301}},
+    {"LATIN SMALL LETTER A WITH OGONEK AND TILDE", 2, {0x0105, 0x0303}},
+    {"LATIN SMALL LETTER AE WITH GRAVE", 2, {0x00E6, 0x0300}},
+    {"LATIN SMALL LETTER E WITH CIRCUMFLEX AND CARON", 2, {0x00EA, 0x030C}},
+    {"LATIN SMALL LETTER E WITH CIRCUMFLEX AND MACRON", 2, {0x00EA, 0x0304}},
+    {"LATIN SMALL LETTER E WITH DOT ABOVE AND ACUTE", 2, {0x0117, 0x0301}},
+    {"LATIN SMALL LETTER E WITH DOT ABOVE AND TILDE", 2, {0x0117, 0x0303}},
+    {"LATIN SMALL LETTER E WITH OGONEK AND ACUTE", 2, {0x0119, 0x0301}},
+    {"LATIN SMALL LETTER E WITH OGONEK AND TILDE", 2, {0x0119, 0x0303}},
+    {"LATIN SMALL LETTER E WITH VERTICAL LINE BELOW", 2, {0x0065, 0x0329}},
+    {"LATIN SMALL LETTER E WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00E9, 0x0329}},
+    {"LATIN SMALL LETTER E WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00E8, 0x0329}},
+    {"LATIN SMALL LETTER HOOKED SCHWA WITH ACUTE", 2, {0x025A, 0x0301}},
+    {"LATIN SMALL LETTER HOOKED SCHWA WITH GRAVE", 2, {0x025A, 0x0300}},
+    {"LATIN SMALL LETTER I WITH DOT ABOVE AND ACUTE", 3, {0x0069, 0x0307, 0x0301}},
+    {"LATIN SMALL LETTER I WITH DOT ABOVE AND GRAVE", 3, {0x0069, 0x0307, 0x0300}},
+    {"LATIN SMALL LETTER I WITH DOT ABOVE AND TILDE", 3, {0x0069, 0x0307, 0x0303}},
+    {"LATIN SMALL LETTER I WITH MACRON AND GRAVE", 2, {0x012B, 0x0300}},
+    {"LATIN SMALL LETTER I WITH OGONEK AND DOT ABOVE AND ACUTE", 3, {0x012F, 0x0307, 0x0301}},
+    {"LATIN SMALL LETTER I WITH OGONEK AND DOT ABOVE AND TILDE", 3, {0x012F, 0x0307, 0x0303}},
+    {"LATIN SMALL LETTER J WITH DOT ABOVE AND TILDE", 3, {0x006A, 0x0307, 0x0303}},
+    {"LATIN SMALL LETTER L WITH TILDE", 2, {0x006C, 0x0303}},
+    {"LATIN SMALL LETTER M WITH TILDE", 2, {0x006D, 0x0303}},
+    {"LATIN SMALL LETTER NG WITH TILDE ABOVE", 3, {0x006E, 0x0360, 0x0067}},
+    {"LATIN SMALL LETTER O WITH VERTICAL LINE BELOW", 2, {0x006F, 0x0329}},
+    {"LATIN SMALL LETTER O WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00F3, 0x0329}},
+    {"LATIN SMALL LETTER O WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00F2, 0x0329}},
+    {"LATIN SMALL LETTER OPEN O WITH ACUTE", 2, {0x0254, 0x0301}},
+    {"LATIN SMALL LETTER OPEN O WITH GRAVE", 2, {0x0254, 0x0300}},
+    {"LATIN SMALL LETTER R WITH TILDE", 2, {0x0072, 0x0303}},
+    {"LATIN SMALL LETTER S WITH VERTICAL LINE BELOW", 2, {0x0073, 0x0329}},
+    {"LATIN SMALL LETTER SCHWA WITH ACUTE", 2, {0x0259, 0x0301}},
+    {"LATIN SMALL LETTER SCHWA WITH GRAVE", 2, {0x0259, 0x0300}},
+    {"LATIN SMALL LETTER TURNED V WITH ACUTE", 2, {0x028C, 0x0301}},
+    {"LATIN SMALL LETTER TURNED V WITH GRAVE", 2, {0x028C, 0x0300}},
+    {"LATIN SMALL LETTER U WITH MACRON AND ACUTE", 2, {0x016B, 0x0301}},
+    {"LATIN SMALL LETTER U WITH MACRON AND GRAVE", 2, {0x016B, 0x0300}},
+    {"LATIN SMALL LETTER U WITH MACRON AND TILDE", 2, {0x016B, 0x0303}},
+    {"LATIN SMALL LETTER U WITH OGONEK AND ACUTE", 2, {0x0173, 0x0301}},
+    {"LATIN SMALL LETTER U WITH OGONEK AND TILDE", 2, {0x0173, 0x0303}},
+    {"MODIFIER LETTER EXTRA-HIGH EXTRA-LOW CONTOUR TONE BAR", 2, {0x02E5, 0x02E9}},
+    {"MODIFIER LETTER EXTRA-LOW EXTRA-HIGH CONTOUR TONE BAR", 2, {0x02E9, 0x02E5}},
+    {"TAMIL CONSONANT C", 2, {0x0B9A, 0x0BCD}},
+    {"TAMIL CONSONANT H", 2, {0x0BB9, 0x0BCD}},
+    {"TAMIL CONSONANT J", 2, {0x0B9C, 0x0BCD}},
+    {"TAMIL CONSONANT K", 2, {0x0B95, 0x0BCD}},
+    {"TAMIL CONSONANT KSS", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCD}},
+    {"TAMIL CONSONANT L", 2, {0x0BB2, 0x0BCD}},
+    {"TAMIL CONSONANT LL", 2, {0x0BB3, 0x0BCD}},
+    {"TAMIL CONSONANT LLL", 2, {0x0BB4, 0x0BCD}},
+    {"TAMIL CONSONANT M", 2, {0x0BAE, 0x0BCD}},
+    {"TAMIL CONSONANT N", 2, {0x0BA8, 0x0BCD}},
+    {"TAMIL CONSONANT NG", 2, {0x0B99, 0x0BCD}},
+    {"TAMIL CONSONANT NN", 2, {0x0BA3, 0x0BCD}},
+    {"TAMIL CONSONANT NNN", 2, {0x0BA9, 0x0BCD}},
+    {"TAMIL CONSONANT NY", 2, {0x0B9E, 0x0BCD}},
+    {"TAMIL CONSONANT P", 2, {0x0BAA, 0x0BCD}},
+    {"TAMIL CONSONANT R", 2, {0x0BB0, 0x0BCD}},
+    {"TAMIL CONSONANT RR", 2, {0x0BB1, 0x0BCD}},
+    {"TAMIL CONSONANT S", 2, {0x0BB8, 0x0BCD}},
+    {"TAMIL CONSONANT SH", 2, {0x0BB6, 0x0BCD}},
+    {"TAMIL CONSONANT SS", 2, {0x0BB7, 0x0BCD}},
+    {"TAMIL CONSONANT T", 2, {0x0BA4, 0x0BCD}},
+    {"TAMIL CONSONANT TT", 2, {0x0B9F, 0x0BCD}},
+    {"TAMIL CONSONANT V", 2, {0x0BB5, 0x0BCD}},
+    {"TAMIL CONSONANT Y", 2, {0x0BAF, 0x0BCD}},
+    {"TAMIL SYLLABLE CAA", 2, {0x0B9A, 0x0BBE}},
+    {"TAMIL SYLLABLE CAI", 2, {0x0B9A, 0x0BC8}},
+    {"TAMIL SYLLABLE CAU", 2, {0x0B9A, 0x0BCC}},
+    {"TAMIL SYLLABLE CE", 2, {0x0B9A, 0x0BC6}},
+    {"TAMIL SYLLABLE CEE", 2, {0x0B9A, 0x0BC7}},
+    {"TAMIL SYLLABLE CI", 2, {0x0B9A, 0x0BBF}},
+    {"TAMIL SYLLABLE CII", 2, {0x0B9A, 0x0BC0}},
+    {"TAMIL SYLLABLE CO", 2, {0x0B9A, 0x0BCA}},
+    {"TAMIL SYLLABLE COO", 2, {0x0B9A, 0x0BCB}},
+    {"TAMIL SYLLABLE CU", 2, {0x0B9A, 0x0BC1}},
+    {"TAMIL SYLLABLE CUU", 2, {0x0B9A, 0x0BC2}},
+    {"TAMIL SYLLABLE HAA", 2, {0x0BB9, 0x0BBE}},
+    {"TAMIL SYLLABLE HAI", 2, {0x0BB9, 0x0BC8}},
+    {"TAMIL SYLLABLE HAU", 2, {0x0BB9, 0x0BCC}},
+    {"TAMIL SYLLABLE HE", 2, {0x0BB9, 0x0BC6}},
+    {"TAMIL SYLLABLE HEE", 2, {0x0BB9, 0x0BC7}},
+    {"TAMIL SYLLABLE HI", 2, {0x0BB9, 0x0BBF}},
+    {"TAMIL SYLLABLE HII", 2, {0x0BB9, 0x0BC0}},
+    {"TAMIL SYLLABLE HO", 2, {0x0BB9, 0x0BCA}},
+    {"TAMIL SYLLABLE HOO", 2, {0x0BB9, 0x0BCB}},
+    {"TAMIL SYLLABLE HU", 2, {0x0BB9, 0x0BC1}},
+    {"TAMIL SYLLABLE HUU", 2, {0x0BB9, 0x0BC2}},
+    {"TAMIL SYLLABLE JAA", 2, {0x0B9C, 0x0BBE}},
+    {"TAMIL SYLLABLE JAI", 2, {0x0B9C, 0x0BC8}},
+    {"TAMIL SYLLABLE JAU", 2, {0x0B9C, 0x0BCC}},
+    {"TAMIL SYLLABLE JE", 2, {0x0B9C, 0x0BC6}},
+    {"TAMIL SYLLABLE JEE", 2, {0x0B9C, 0x0BC7}},
+    {"TAMIL SYLLABLE JI", 2, {0x0B9C, 0x0BBF}},
+    {"TAMIL SYLLABLE JII", 2, {0x0B9C, 0x0BC0}},
+    {"TAMIL SYLLABLE JO", 2, {0x0B9C, 0x0BCA}},
+    {"TAMIL SYLLABLE JOO", 2, {0x0B9C, 0x0BCB}},
+    {"TAMIL SYLLABLE JU", 2, {0x0B9C, 0x0BC1}},
+    {"TAMIL SYLLABLE JUU", 2, {0x0B9C, 0x0BC2}},
+    {"TAMIL SYLLABLE KAA", 2, {0x0B95, 0x0BBE}},
+    {"TAMIL SYLLABLE KAI", 2, {0x0B95, 0x0BC8}},
+    {"TAMIL SYLLABLE KAU", 2, {0x0B95, 0x0BCC}},
+    {"TAMIL SYLLABLE KE", 2, {0x0B95, 0x0BC6}},
+    {"TAMIL SYLLABLE KEE", 2, {0x0B95, 0x0BC7}},
+    {"TAMIL SYLLABLE KI", 2, {0x0B95, 0x0BBF}},
+    {"TAMIL SYLLABLE KII", 2, {0x0B95, 0x0BC0}},
+    {"TAMIL SYLLABLE KO", 2, {0x0B95, 0x0BCA}},
+    {"TAMIL SYLLABLE KOO", 2, {0x0B95, 0x0BCB}},
+    {"TAMIL SYLLABLE KSSA", 3, {0x0B95, 0x0BCD, 0x0BB7}},
+    {"TAMIL SYLLABLE KSSAA", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BBE}},
+    {"TAMIL SYLLABLE KSSAI", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC8}},
+    {"TAMIL SYLLABLE KSSAU", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCC}},
+    {"TAMIL SYLLABLE KSSE", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC6}},
+    {"TAMIL SYLLABLE KSSEE", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC7}},
+    {"TAMIL SYLLABLE KSSI", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BBF}},
+    {"TAMIL SYLLABLE KSSII", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC0}},
+    {"TAMIL SYLLABLE KSSO", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCA}},
+    {"TAMIL SYLLABLE KSSOO", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCB}},
+    {"TAMIL SYLLABLE KSSU", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC1}},
+    {"TAMIL SYLLABLE KSSUU", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC2}},
+    {"TAMIL SYLLABLE KU", 2, {0x0B95, 0x0BC1}},
+    {"TAMIL SYLLABLE KUU", 2, {0x0B95, 0x0BC2}},
+    {"TAMIL SYLLABLE LAA", 2, {0x0BB2, 0x0BBE}},
+    {"TAMIL SYLLABLE LAI", 2, {0x0BB2, 0x0BC8}},
+    {"TAMIL SYLLABLE LAU", 2, {0x0BB2, 0x0BCC}},
+    {"TAMIL SYLLABLE LE", 2, {0x0BB2, 0x0BC6}},
+    {"TAMIL SYLLABLE LEE", 2, {0x0BB2, 0x0BC7}},
+    {"TAMIL SYLLABLE LI", 2, {0x0BB2, 0x0BBF}},
+    {"TAMIL SYLLABLE LII", 2, {0x0BB2, 0x0BC0}},
+    {"TAMIL SYLLABLE LLAA", 2, {0x0BB3, 0x0BBE}},
+    {"TAMIL SYLLABLE LLAI", 2, {0x0BB3, 0x0BC8}},
+    {"TAMIL SYLLABLE LLAU", 2, {0x0BB3, 0x0BCC}},
+    {"TAMIL SYLLABLE LLE", 2, {0x0BB3, 0x0BC6}},
+    {"TAMIL SYLLABLE LLEE", 2, {0x0BB3, 0x0BC7}},
+    {"TAMIL SYLLABLE LLI", 2, {0x0BB3, 0x0BBF}},
+    {"TAMIL SYLLABLE LLII", 2, {0x0BB3, 0x0BC0}},
+    {"TAMIL SYLLABLE LLLAA", 2, {0x0BB4, 0x0BBE}},
+    {"TAMIL SYLLABLE LLLAI", 2, {0x0BB4, 0x0BC8}},
+    {"TAMIL SYLLABLE LLLAU", 2, {0x0BB4, 0x0BCC}},
+    {"TAMIL SYLLABLE LLLE", 2, {0x0BB4, 0x0BC6}},
+    {"TAMIL SYLLABLE LLLEE", 2, {0x0BB4, 0x0BC7}},
+    {"TAMIL SYLLABLE LLLI", 2, {0x0BB4, 0x0BBF}},
+    {"TAMIL SYLLABLE LLLII", 2, {0x0BB4, 0x0BC0}},
+    {"TAMIL SYLLABLE LLLO", 2, {0x0BB4, 0x0BCA}},
+    {"TAMIL SYLLABLE LLLOO", 2, {0x0BB4, 0x0BCB}},
+    {"TAMIL SYLLABLE LLLU", 2, {0x0BB4, 0x0BC1}},
+    {"TAMIL SYLLABLE LLLUU", 2, {0x0BB4, 0x0BC2}},
+    {"TAMIL SYLLABLE LLO", 2, {0x0BB3, 0x0BCA}},
+    {"TAMIL SYLLABLE LLOO", 2, {0x0BB3, 0x0BCB}},
+    {"TAMIL SYLLABLE LLU", 2, {0x0BB3, 0x0BC1}},
+    {"TAMIL SYLLABLE LLUU", 2, {0x0BB3, 0x0BC2}},
+    {"TAMIL SYLLABLE LO", 2, {0x0BB2, 0x0BCA}},
+    {"TAMIL SYLLABLE LOO", 2, {0x0BB2, 0x0BCB}},
+    {"TAMIL SYLLABLE LU", 2, {0x0BB2, 0x0BC1}},
+    {"TAMIL SYLLABLE LUU", 2, {0x0BB2, 0x0BC2}},
+    {"TAMIL SYLLABLE MAA", 2, {0x0BAE, 0x0BBE}},
+    {"TAMIL SYLLABLE MAI", 2, {0x0BAE, 0x0BC8}},
+    {"TAMIL SYLLABLE MAU", 2, {0x0BAE, 0x0BCC}},
+    {"TAMIL SYLLABLE ME", 2, {0x0BAE, 0x0BC6}},
+    {"TAMIL SYLLABLE MEE", 2, {0x0BAE, 0x0BC7}},
+    {"TAMIL SYLLABLE MI", 2, {0x0BAE, 0x0BBF}},
+    {"TAMIL SYLLABLE MII", 2, {0x0BAE, 0x0BC0}},
+    {"TAMIL SYLLABLE MO", 2, {0x0BAE, 0x0BCA}},
+    {"TAMIL SYLLABLE MOO", 2, {0x0BAE, 0x0BCB}},
+    {"TAMIL SYLLABLE MU", 2, {0x0BAE, 0x0BC1}},
+    {"TAMIL SYLLABLE MUU", 2, {0x0BAE, 0x0BC2}},
+    {"TAMIL SYLLABLE NAA", 2, {0x0BA8, 0x0BBE}},
+    {"TAMIL SYLLABLE NAI", 2, {0x0BA8, 0x0BC8}},
+    {"TAMIL SYLLABLE NAU", 2, {0x0BA8, 0x0BCC}},
+    {"TAMIL SYLLABLE NE", 2, {0x0BA8, 0x0BC6}},
+    {"TAMIL SYLLABLE NEE", 2, {0x0BA8, 0x0BC7}},
+    {"TAMIL SYLLABLE NGAA", 2, {0x0B99, 0x0BBE}},
+    {"TAMIL SYLLABLE NGAI", 2, {0x0B99, 0x0BC8}},
+    {"TAMIL SYLLABLE NGAU", 2, {0x0B99, 0x0BCC}},
+    {"TAMIL SYLLABLE NGE", 2, {0x0B99, 0x0BC6}},
+    {"TAMIL SYLLABLE NGEE", 2, {0x0B99, 0x0BC7}},
+    {"TAMIL SYLLABLE NGI", 2, {0x0B99, 0x0BBF}},
+    {"TAMIL SYLLABLE NGII", 2, {0x0B99, 0x0BC0}},
+    {"TAMIL SYLLABLE NGO", 2, {0x0B99, 0x0BCA}},
+    {"TAMIL SYLLABLE NGOO", 2, {0x0B99, 0x0BCB}},
+    {"TAMIL SYLLABLE NGU", 2, {0x0B99, 0x0BC1}},
+    {"TAMIL SYLLABLE NGUU", 2, {0x0B99, 0x0BC2}},
+    {"TAMIL SYLLABLE NI", 2, {0x0BA8, 0x0BBF}},
+    {"TAMIL SYLLABLE NII", 2, {0x0BA8, 0x0BC0}},
+    {"TAMIL SYLLABLE NNAA", 2, {0x0BA3, 0x0BBE}},
+    {"TAMIL SYLLABLE NNAI", 2, {0x0BA3, 0x0BC8}},
+    {"TAMIL SYLLABLE NNAU", 2, {0x0BA3, 0x0BCC}},
+    {"TAMIL SYLLABLE NNE", 2, {0x0BA3, 0x0BC6}},
+    {"TAMIL SYLLABLE NNEE", 2, {0x0BA3, 0x0BC7}},
+    {"TAMIL SYLLABLE NNI", 2, {0x0BA3, 0x0BBF}},
+    {"TAMIL SYLLABLE NNII", 2, {0x0BA3, 0x0BC0}},
+    {"TAMIL SYLLABLE NNNAA", 2, {0x0BA9, 0x0BBE}},
+    {"TAMIL SYLLABLE NNNAI", 2, {0x0BA9, 0x0BC8}},
+    {"TAMIL SYLLABLE NNNAU", 2, {0x0BA9, 0x0BCC}},
+    {"TAMIL SYLLABLE NNNE", 2, {0x0BA9, 0x0BC6}},
+    {"TAMIL SYLLABLE NNNEE", 2, {0x0BA9, 0x0BC7}},
+    {"TAMIL SYLLABLE NNNI", 2, {0x0BA9, 0x0BBF}},
+    {"TAMIL SYLLABLE NNNII", 2, {0x0BA9, 0x0BC0}},
+    {"TAMIL SYLLABLE NNNO", 2, {0x0BA9, 0x0BCA}},
+    {"TAMIL SYLLABLE NNNOO", 2, {0x0BA9, 0x0BCB}},
+    {"TAMIL SYLLABLE NNNU", 2, {0x0BA9, 0x0BC1}},
+    {"TAMIL SYLLABLE NNNUU", 2, {0x0BA9, 0x0BC2}},
+    {"TAMIL SYLLABLE NNO", 2, {0x0BA3, 0x0BCA}},
+    {"TAMIL SYLLABLE NNOO", 2, {0x0BA3, 0x0BCB}},
+    {"TAMIL SYLLABLE NNU", 2, {0x0BA3, 0x0BC1}},
+    {"TAMIL SYLLABLE NNUU", 2, {0x0BA3, 0x0BC2}},
+    {"TAMIL SYLLABLE NO", 2, {0x0BA8, 0x0BCA}},
+    {"TAMIL SYLLABLE NOO", 2, {0x0BA8, 0x0BCB}},
+    {"TAMIL SYLLABLE NU", 2, {0x0BA8, 0x0BC1}},
+    {"TAMIL SYLLABLE NUU", 2, {0x0BA8, 0x0BC2}},
+    {"TAMIL SYLLABLE NYAA", 2, {0x0B9E, 0x0BBE}},
+    {"TAMIL SYLLABLE NYAI", 2, {0x0B9E, 0x0BC8}},
+    {"TAMIL SYLLABLE NYAU", 2, {0x0B9E, 0x0BCC}},
+    {"TAMIL SYLLABLE NYE", 2, {0x0B9E, 0x0BC6}},
+    {"TAMIL SYLLABLE NYEE", 2, {0x0B9E, 0x0BC7}},
+    {"TAMIL SYLLABLE NYI", 2, {0x0B9E, 0x0BBF}},
+    {"TAMIL SYLLABLE NYII", 2, {0x0B9E, 0x0BC0}},
+    {"TAMIL SYLLABLE NYO", 2, {0x0B9E, 0x0BCA}},
+    {"TAMIL SYLLABLE NYOO", 2, {0x0B9E, 0x0BCB}},
+    {"TAMIL SYLLABLE NYU", 2, {0x0B9E, 0x0BC1}},
+    {"TAMIL SYLLABLE NYUU", 2, {0x0B9E, 0x0BC2}},
+    {"TAMIL SYLLABLE PAA", 2, {0x0BAA, 0x0BBE}},
+    {"TAMIL SYLLABLE PAI", 2, {0x0BAA, 0x0BC8}},
+    {"TAMIL SYLLABLE PAU", 2, {0x0BAA, 0x0BCC}},
+    {"TAMIL SYLLABLE PE", 2, {0x0BAA, 0x0BC6}},
+    {"TAMIL SYLLABLE PEE", 2, {0x0BAA, 0x0BC7}},
+    {"TAMIL SYLLABLE PI", 2, {0x0BAA, 0x0BBF}},
+    {"TAMIL SYLLABLE PII", 2, {0x0BAA, 0x0BC0}},
+    {"TAMIL SYLLABLE PO", 2, {0x0BAA, 0x0BCA}},
+    {"TAMIL SYLLABLE POO", 2, {0x0BAA, 0x0BCB}},
+    {"TAMIL SYLLABLE PU", 2, {0x0BAA, 0x0BC1}},
+    {"TAMIL SYLLABLE PUU", 2, {0x0BAA, 0x0BC2}},
+    {"TAMIL SYLLABLE RAA", 2, {0x0BB0, 0x0BBE}},
+    {"TAMIL SYLLABLE RAI", 2, {0x0BB0, 0x0BC8}},
+    {"TAMIL SYLLABLE RAU", 2, {0x0BB0, 0x0BCC}},
+    {"TAMIL SYLLABLE RE", 2, {0x0BB0, 0x0BC6}},
+    {"TAMIL SYLLABLE REE", 2, {0x0BB0, 0x0BC7}},
+    {"TAMIL SYLLABLE RI", 2, {0x0BB0, 0x0BBF}},
+    {"TAMIL SYLLABLE RII", 2, {0x0BB0, 0x0BC0}},
+    {"TAMIL SYLLABLE RO", 2, {0x0BB0, 0x0BCA}},
+    {"TAMIL SYLLABLE ROO", 2, {0x0BB0, 0x0BCB}},
+    {"TAMIL SYLLABLE RRAA", 2, {0x0BB1, 0x0BBE}},
+    {"TAMIL SYLLABLE RRAI", 2, {0x0BB1, 0x0BC8}},
+    {"TAMIL SYLLABLE RRAU", 2, {0x0BB1, 0x0BCC}},
+    {"TAMIL SYLLABLE RRE", 2, {0x0BB1, 0x0BC6}},
+    {"TAMIL SYLLABLE RREE", 2, {0x0BB1, 0x0BC7}},
+    {"TAMIL SYLLABLE RRI", 2, {0x0BB1, 0x0BBF}},
+    {"TAMIL SYLLABLE RRII", 2, {0x0BB1, 0x0BC0}},
+    {"TAMIL SYLLABLE RRO", 2, {0x0BB1, 0x0BCA}},
+    {"TAMIL SYLLABLE RROO", 2, {0x0BB1, 0x0BCB}},
+    {"TAMIL SYLLABLE RRU", 2, {0x0BB1, 0x0BC1}},
+    {"TAMIL SYLLABLE RRUU", 2, {0x0BB1, 0x0BC2}},
+    {"TAMIL SYLLABLE RU", 2, {0x0BB0, 0x0BC1}},
+    {"TAMIL SYLLABLE RUU", 2, {0x0BB0, 0x0BC2}},
+    {"TAMIL SYLLABLE SAA", 2, {0x0BB8, 0x0BBE}},
+    {"TAMIL SYLLABLE SAI", 2, {0x0BB8, 0x0BC8}},
+    {"TAMIL SYLLABLE SAU", 2, {0x0BB8, 0x0BCC}},
+    {"TAMIL SYLLABLE SE", 2, {0x0BB8, 0x0BC6}},
+    {"TAMIL SYLLABLE SEE", 2, {0x0BB8, 0x0BC7}},
+    {"TAMIL SYLLABLE SHAA", 2, {0x0BB6, 0x0BBE}},
+    {"TAMIL SYLLABLE SHAI", 2, {0x0BB6, 0x0BC8}},
+    {"TAMIL SYLLABLE SHAU", 2, {0x0BB6, 0x0BCC}},
+    {"TAMIL SYLLABLE SHE", 2, {0x0BB6, 0x0BC6}},
+    {"TAMIL SYLLABLE SHEE", 2, {0x0BB6, 0x0BC7}},
+    {"TAMIL SYLLABLE SHI", 2, {0x0BB6, 0x0BBF}},
+    {"TAMIL SYLLABLE SHII", 2, {0x0BB6, 0x0BC0}},
+    {"TAMIL SYLLABLE SHO", 2, {0x0BB6, 0x0BCA}},
+    {"TAMIL SYLLABLE SHOO", 2, {0x0BB6, 0x0BCB}},
+    {"TAMIL SYLLABLE SHRII", 4, {0x0BB6, 0x0BCD, 0x0BB0, 0x0BC0}},
+    {"TAMIL SYLLABLE SHU", 2, {0x0BB6, 0x0BC1}},
+    {"TAMIL SYLLABLE SHUU", 2, {0x0BB6, 0x0BC2}},
+    {"TAMIL SYLLABLE SI", 2, {0x0BB8, 0x0BBF}},
+    {"TAMIL SYLLABLE SII", 2, {0x0BB8, 0x0BC0}},
+    {"TAMIL SYLLABLE SO", 2, {0x0BB8, 0x0BCA}},
+    {"TAMIL SYLLABLE SOO", 2, {0x0BB8, 0x0BCB}},
+    {"TAMIL SYLLABLE SSAA", 2, {0x0BB7, 0x0BBE}},
+    {"TAMIL SYLLABLE SSAI", 2, {0x0BB7, 0x0BC8}},
+    {"TAMIL SYLLABLE SSAU", 2, {0x0BB7, 0x0BCC}},
+    {"TAMIL SYLLABLE SSE", 2, {0x0BB7, 0x0BC6}},
+    {"TAMIL SYLLABLE SSEE", 2, {0x0BB7, 0x0BC7}},
+    {"TAMIL SYLLABLE SSI", 2, {0x0BB7, 0x0BBF}},
+    {"TAMIL SYLLABLE SSII", 2, {0x0BB7, 0x0BC0}},
+    {"TAMIL SYLLABLE SSO", 2, {0x0BB7, 0x0BCA}},
+    {"TAMIL SYLLABLE SSOO", 2, {0x0BB7, 0x0BCB}},
+    {"TAMIL SYLLABLE SSU", 2, {0x0BB7, 0x0BC1}},
+    {"TAMIL SYLLABLE SSUU", 2, {0x0BB7, 0x0BC2}},
+    {"TAMIL SYLLABLE SU", 2, {0x0BB8, 0x0BC1}},
+    {"TAMIL SYLLABLE SUU", 2, {0x0BB8, 0x0BC2}},
+    {"TAMIL SYLLABLE TAA", 2, {0x0BA4, 0x0BBE}},
+    {"TAMIL SYLLABLE TAI", 2, {0x0BA4, 0x0BC8}},
+    {"TAMIL SYLLABLE TAU", 2, {0x0BA4, 0x0BCC}},
+    {"TAMIL SYLLABLE TE", 2, {0x0BA4, 0x0BC6}},
+    {"TAMIL SYLLABLE TEE", 2, {0x0BA4, 0x0BC7}},
+    {"TAMIL SYLLABLE TI", 2, {0x0BA4, 0x0BBF}},
+    {"TAMIL SYLLABLE TII", 2, {0x0BA4, 0x0BC0}},
+    {"TAMIL SYLLABLE TO", 2, {0x0BA4, 0x0BCA}},
+    {"TAMIL SYLLABLE TOO", 2, {0x0BA4, 0x0BCB}},
+    {"TAMIL SYLLABLE TTAA", 2, {0x0B9F, 0x0BBE}},
+    {"TAMIL SYLLABLE TTAI", 2, {0x0B9F, 0x0BC8}},
+    {"TAMIL SYLLABLE TTAU", 2, {0x0B9F, 0x0BCC}},
+    {"TAMIL SYLLABLE TTE", 2, {0x0B9F, 0x0BC6}},
+    {"TAMIL SYLLABLE TTEE", 2, {0x0B9F, 0x0BC7}},
+    {"TAMIL SYLLABLE TTI", 2, {0x0B9F, 0x0BBF}},
+    {"TAMIL SYLLABLE TTII", 2, {0x0B9F, 0x0BC0}},
+    {"TAMIL SYLLABLE TTO", 2, {0x0B9F, 0x0BCA}},
+    {"TAMIL SYLLABLE TTOO", 2, {0x0B9F, 0x0BCB}},
+    {"TAMIL SYLLABLE TTU", 2, {0x0B9F, 0x0BC1}},
+    {"TAMIL SYLLABLE TTUU", 2, {0x0B9F, 0x0BC2}},
+    {"TAMIL SYLLABLE TU", 2, {0x0BA4, 0x0BC1}},
+    {"TAMIL SYLLABLE TUU", 2, {0x0BA4, 0x0BC2}},
+    {"TAMIL SYLLABLE VAA", 2, {0x0BB5, 0x0BBE}},
+    {"TAMIL SYLLABLE VAI", 2, {0x0BB5, 0x0BC8}},
+    {"TAMIL SYLLABLE VAU", 2, {0x0BB5, 0x0BCC}},
+    {"TAMIL SYLLABLE VE", 2, {0x0BB5, 0x0BC6}},
+    {"TAMIL SYLLABLE VEE", 2, {0x0BB5, 0x0BC7}},
+    {"TAMIL SYLLABLE VI", 2, {0x0BB5, 0x0BBF}},
+    {"TAMIL SYLLABLE VII", 2, {0x0BB5, 0x0BC0}},
+    {"TAMIL SYLLABLE VO", 2, {0x0BB5, 0x0BCA}},
+    {"TAMIL SYLLABLE VOO", 2, {0x0BB5, 0x0BCB}},
+    {"TAMIL SYLLABLE VU", 2, {0x0BB5, 0x0BC1}},
+    {"TAMIL SYLLABLE VUU", 2, {0x0BB5, 0x0BC2}},
+    {"TAMIL SYLLABLE YAA", 2, {0x0BAF, 0x0BBE}},
+    {"TAMIL SYLLABLE YAI", 2, {0x0BAF, 0x0BC8}},
+    {"TAMIL SYLLABLE YAU", 2, {0x0BAF, 0x0BCC}},
+    {"TAMIL SYLLABLE YE", 2, {0x0BAF, 0x0BC6}},
+    {"TAMIL SYLLABLE YEE", 2, {0x0BAF, 0x0BC7}},
+    {"TAMIL SYLLABLE YI", 2, {0x0BAF, 0x0BBF}},
+    {"TAMIL SYLLABLE YII", 2, {0x0BAF, 0x0BC0}},
+    {"TAMIL SYLLABLE YO", 2, {0x0BAF, 0x0BCA}},
+    {"TAMIL SYLLABLE YOO", 2, {0x0BAF, 0x0BCB}},
+    {"TAMIL SYLLABLE YU", 2, {0x0BAF, 0x0BC1}},
+    {"TAMIL SYLLABLE YUU", 2, {0x0BAF, 0x0BC2}},
+};
diff --git a/Tools/unicode/makeunicodedata.py b/Tools/unicode/makeunicodedata.py
--- a/Tools/unicode/makeunicodedata.py
+++ b/Tools/unicode/makeunicodedata.py
@@ -25,7 +25,12 @@
 # written by Fredrik Lundh (fredrik at pythonware.com)
 #
 
-import sys, os, zipfile
+import os
+import sys
+import zipfile
+
+from textwrap import dedent
+from operator import itemgetter
 
 SCRIPT = sys.argv[0]
 VERSION = "3.2"
@@ -39,6 +44,8 @@
 DERIVED_CORE_PROPERTIES = "DerivedCoreProperties%s.txt"
 DERIVEDNORMALIZATION_PROPS = "DerivedNormalizationProps%s.txt"
 LINE_BREAK = "LineBreak%s.txt"
+NAME_ALIASES = "NameAliases%s.txt"
+NAMED_SEQUENCES = "NamedSequences%s.txt"
 
 old_versions = ["3.2.0"]
 
@@ -692,6 +699,40 @@
     print("/* name->code dictionary */", file=fp)
     codehash.dump(fp, trace)
 
+    print(dedent("""
+        typedef struct Alias {
+            char *name;
+            int namelen;
+            int codepoint;
+        } alias;
+        """), file=fp)
+
+    print('static const int aliases_count = %d;' % len(unicode.aliases), file=fp)
+
+    print('static const alias name_aliases[] = {', file=fp)
+    for name, codepoint in unicode.aliases:
+        print('    {"%s", %d, 0x%04X},' % (name, len(name), codepoint), file=fp)
+    print('};', file=fp)
+
+    # the Py_UCS2 seq[4] should use Py_UCS4 if non-BMP chars are added to the
+    # sequences and have an higher number of elements if the sequences get longer
+    print(dedent("""
+        typedef struct NamedSequence {
+            char *name;
+            int seqlen;
+            Py_UCS2 seq[4];
+        } named_sequence;
+        """), file=fp)
+
+    print('static const int named_sequences_count = %d;' % len(unicode.named_sequences),
+          file=fp)
+
+    print('static const named_sequence named_sequences[] = {', file=fp)
+    for name, sequence in unicode.named_sequences:
+        seq_str = ', '.join('0x%04X' % cp for cp in sequence)
+        print('    {"%s", %d, {%s}},' % (name, len(sequence), seq_str), file=fp)
+    print('};', file=fp)
+
     fp.close()
 
 
@@ -855,6 +896,31 @@
         self.table = table
         self.chars = list(range(0x110000)) # unicode 3.2
 
+        self.aliases = []
+        with open_data(NAME_ALIASES, version) as file:
+            for s in file:
+                s = s.strip()
+                if not s or s.startswith('#'):
+                    continue
+                char, name = s.split(';')
+                char = int(char, 16)
+                self.aliases.append((name, char))
+
+        self.named_sequences = []
+        with open_data(NAMED_SEQUENCES, version) as file:
+            for s in file:
+                s = s.strip()
+                if not s or s.startswith('#'):
+                    continue
+                name, chars = s.split(';')
+                chars = tuple(int(char, 16) for char in chars.split())
+                # check that the structure defined in makeunicodename is OK
+                assert 2 <= len(chars) <= 4, "change the Py_UCS2 array size"
+                assert all(c <= 0xFFFF for c in chars), "use Py_UCS4 instead"
+                self.named_sequences.append((name, chars))
+        # sort names to enable binary search
+        self.named_sequences.sort(key=itemgetter(0))
+
         self.exclusions = {}
         with open_data(COMPOSITION_EXCLUSIONS, version) as file:
             for s in file:

From report at bugs.python.org  Thu Oct  6 12:50:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 06 Oct 2011 10:50:53 +0000
Subject: [issue2771] Test issue
In-Reply-To: <CACBhJdFmcQJb5BarQ26N_2k0DCKKk24+5JhOZc+A0yHVy_ky0w@mail.gmail.com>
Message-ID: <CACBhJdGkkCRVmzin3up7H59JPL=5ugjj2Di=k7pWzzRGpzAqKg@mail.gmail.com>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

test attachments

----------
Added file: http://bugs.python.org/file23325/unnamed
Added file: http://bugs.python.org/file23326/issue12753-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________
-------------- next part --------------
test attachments<br>
<br><br>
-------------- next part --------------
diff --git a/Doc/library/unicodedata.rst b/Doc/library/unicodedata.rst
--- a/Doc/library/unicodedata.rst
+++ b/Doc/library/unicodedata.rst
@@ -29,6 +29,9 @@
    Look up character by name.  If a character with the given name is found, return
    the corresponding character.  If not found, :exc:`KeyError` is raised.
 
+   .. versionchanged:: 3.3
+      Support for name aliases [#]_ and named sequences [#]_ has been added.
+
 
 .. function:: name(chr[, default])
 
@@ -160,3 +163,9 @@
    >>> unicodedata.bidirectional('\u0660') # 'A'rabic, 'N'umber
    'AN'
 
+
+.. rubric:: Footnotes
+
+.. [#] http://www.unicode.org/Public/6.0.0/ucd/NameAliases.txt
+
+.. [#] http://www.unicode.org/Public/6.0.0/ucd/NamedSequences.txt
diff --git a/Doc/reference/lexical_analysis.rst b/Doc/reference/lexical_analysis.rst
--- a/Doc/reference/lexical_analysis.rst
+++ b/Doc/reference/lexical_analysis.rst
@@ -492,13 +492,13 @@
 +-----------------+---------------------------------+-------+
 | Escape Sequence | Meaning                         | Notes |
 +=================+=================================+=======+
-| ``\N{name}``    | Character named *name* in the   |       |
+| ``\N{name}``    | Character named *name* in the   | \(4)  |
 |                 | Unicode database                |       |
 +-----------------+---------------------------------+-------+
-| ``\uxxxx``      | Character with 16-bit hex value | \(4)  |
+| ``\uxxxx``      | Character with 16-bit hex value | \(5)  |
 |                 | *xxxx*                          |       |
 +-----------------+---------------------------------+-------+
-| ``\Uxxxxxxxx``  | Character with 32-bit hex value | \(5)  |
+| ``\Uxxxxxxxx``  | Character with 32-bit hex value | \(6)  |
 |                 | *xxxxxxxx*                      |       |
 +-----------------+---------------------------------+-------+
 
@@ -516,10 +516,14 @@
    with the given value.
 
 (4)
+   .. versionchanged:: 3.3
+      Support for name aliases [#]_ has been added.
+
+(5)
    Individual code units which form parts of a surrogate pair can be encoded using
    this escape sequence.  Exactly four hex digits are required.
 
-(5)
+(6)
    Any Unicode character can be encoded this way, but characters outside the Basic
    Multilingual Plane (BMP) will be encoded using a surrogate pair if Python is
    compiled to use 16-bit code units (the default).  Exactly eight hex digits
@@ -706,3 +710,8 @@
 occurrence outside string literals and comments is an unconditional error::
 
    $       ?       `
+
+
+.. rubric:: Footnotes
+
+.. [#] http://www.unicode.org/Public/6.0.0/ucd/NameAliases.txt
diff --git a/Lib/test/test_ucn.py b/Lib/test/test_ucn.py
--- a/Lib/test/test_ucn.py
+++ b/Lib/test/test_ucn.py
@@ -8,8 +8,11 @@
 """#"
 
 import unittest
+import unicodedata
 
 from test import support
+from http.client import HTTPException
+from test.test_normalization import check_version
 
 class UnicodeNamesTest(unittest.TestCase):
 
@@ -59,8 +62,6 @@
         )
 
     def test_ascii_letters(self):
-        import unicodedata
-
         for char in "".join(map(chr, range(ord("a"), ord("z")))):
             name = "LATIN SMALL LETTER %s" % char.upper()
             code = unicodedata.lookup(name)
@@ -81,7 +82,6 @@
         self.checkletter("HANGUL SYLLABLE HWEOK", "\ud6f8")
         self.checkletter("HANGUL SYLLABLE HIH", "\ud7a3")
 
-        import unicodedata
         self.assertRaises(ValueError, unicodedata.name, "\ud7a4")
 
     def test_cjk_unified_ideographs(self):
@@ -97,14 +97,11 @@
         self.checkletter("CJK UNIFIED IDEOGRAPH-2B81D", "\U0002B81D")
 
     def test_bmp_characters(self):
-        import unicodedata
-        count = 0
         for code in range(0x10000):
             char = chr(code)
             name = unicodedata.name(char, None)
             if name is not None:
                 self.assertEqual(unicodedata.lookup(name), char)
-                count += 1
 
     def test_misc_symbols(self):
         self.checkletter("PILCROW SIGN", "\u00b6")
@@ -112,8 +109,65 @@
         self.checkletter("HALFWIDTH KATAKANA SEMI-VOICED SOUND MARK", "\uFF9F")
         self.checkletter("FULLWIDTH LATIN SMALL LETTER A", "\uFF41")
 
+    def test_aliases(self):
+        # Check that the aliases defined in the NameAliases.txt file work.
+        # This should be updated when new aliases are added or the file
+        # should be downloaded and parsed instead.  See #12753.
+        aliases = [
+            ('LATIN CAPITAL LETTER GHA', 0x01A2),
+            ('LATIN SMALL LETTER GHA', 0x01A3),
+            ('KANNADA LETTER LLLA', 0x0CDE),
+            ('LAO LETTER FO FON', 0x0E9D),
+            ('LAO LETTER FO FAY', 0x0E9F),
+            ('LAO LETTER RO', 0x0EA3),
+            ('LAO LETTER LO', 0x0EA5),
+            ('TIBETAN MARK BKA- SHOG GI MGO RGYAN', 0x0FD0),
+            ('YI SYLLABLE ITERATION MARK', 0xA015),
+            ('PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRACKET', 0xFE18),
+            ('BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS', 0x1D0C5)
+        ]
+        for alias, codepoint in aliases:
+            self.checkletter(alias, chr(codepoint))
+            name = unicodedata.name(chr(codepoint))
+            self.assertNotEqual(name, alias)
+            self.assertEqual(unicodedata.lookup(alias),
+                             unicodedata.lookup(name))
+
+    def test_named_sequences_sample(self):
+        # Check a few named sequences.  See #12753.
+        sequences = [
+            ('LATIN SMALL LETTER R WITH TILDE', '\u0072\u0303'),
+            ('TAMIL SYLLABLE SAI', '\u0BB8\u0BC8'),
+            ('TAMIL SYLLABLE MOO', '\u0BAE\u0BCB'),
+            ('TAMIL SYLLABLE NNOO', '\u0BA3\u0BCB'),
+            ('TAMIL CONSONANT KSS', '\u0B95\u0BCD\u0BB7\u0BCD'),
+        ]
+        for seqname, codepoints in sequences:
+            self.assertEqual(unicodedata.lookup(seqname), codepoints)
+            with self.assertRaises(SyntaxError):
+                self.checkletter(seqname, None)
+
+    def test_named_sequences_full(self):
+        # Check all the named sequences
+        url = ("http://www.unicode.org/Public/%s/ucd/NamedSequences.txt" %
+               unicodedata.unidata_version)
+        try:
+            testdata = support.open_urlresource(url, encoding="utf-8",
+                                                check=check_version)
+        except (IOError, HTTPException):
+            self.skipTest("Could not retrieve " + url)
+        self.addCleanup(testdata.close)
+        for line in testdata:
+            line = line.strip()
+            if not line or line.startswith('#'):
+                continue
+            seqname, codepoints = line.split(';')
+            codepoints = ''.join(chr(int(cp, 16)) for cp in codepoints.split())
+            self.assertEqual(unicodedata.lookup(seqname), codepoints)
+            with self.assertRaises(SyntaxError):
+                self.checkletter(seqname, None)
+
     def test_errors(self):
-        import unicodedata
         self.assertRaises(TypeError, unicodedata.name)
         self.assertRaises(TypeError, unicodedata.name, 'xx')
         self.assertRaises(TypeError, unicodedata.lookup)
diff --git a/Modules/unicodedata.c b/Modules/unicodedata.c
--- a/Modules/unicodedata.c
+++ b/Modules/unicodedata.c
@@ -1054,7 +1054,7 @@
 static int
 _getcode(PyObject* self, const char* name, int namelen, Py_UCS4* code)
 {
-    unsigned int h, v;
+    unsigned int h, v, k;
     unsigned int mask = code_size-1;
     unsigned int i, incr;
 
@@ -1100,6 +1100,17 @@
         return 1;
     }
 
+    /* check for aliases defined in NameAliases.txt */
+    for (k=0; k<aliases_count; k++) {
+        /* name might not be nul-terminated, so it's necessary to check
+           that the len of the two names is the same before comparing them */
+        if ((name_aliases[k].namelen == namelen) &&
+            (strncmp(name, name_aliases[k].name, namelen) == 0)) {
+            *code = name_aliases[k].codepoint;
+            return 1;
+        }
+    }
+
     /* the following is the same as python's dictionary lookup, with
        only minor changes.  see the makeunicodedata script for more
        details */
@@ -1176,6 +1187,26 @@
     return PyUnicode_FromString(name);
 }
 
+static PyObject *
+_lookup_named_sequences(char* name) {
+    int low, mid, high, cmp;
+    low = 0;
+    high = named_sequences_count;
+    while (low <= high) {
+        mid = (low+high) / 2;
+        cmp = strcmp(name, named_sequences[mid].name);
+        if (cmp < 0)
+            high = mid - 1;
+        else if (cmp > 0)
+            low = mid + 1;
+        else
+            return PyUnicode_FromKindAndData(PyUnicode_2BYTE_KIND,
+                                             named_sequences[mid].seq,
+                                             named_sequences[mid].seqlen);
+    }
+    return NULL;
+}
+
 PyDoc_STRVAR(unicodedata_lookup__doc__,
 "lookup(name)\n\
 \n\
@@ -1187,6 +1218,7 @@
 unicodedata_lookup(PyObject* self, PyObject* args)
 {
     Py_UCS4 code;
+    PyObject *codes; /* for named sequences */
 
     char* name;
     int namelen;
@@ -1194,9 +1226,13 @@
         return NULL;
 
     if (!_getcode(self, name, namelen, &code)) {
-        PyErr_Format(PyExc_KeyError, "undefined character name '%s'",
-                     name);
-        return NULL;
+        /* if the normal lookup fails try with named sequences */
+        codes = _lookup_named_sequences(name);
+        if (codes == NULL) {
+            PyErr_Format(PyExc_KeyError, "undefined character name '%s'", name);
+            return NULL;
+        }
+        return codes;
     }
 
     return PyUnicode_FromOrdinal(code);
diff --git a/Modules/unicodename_db.h b/Modules/unicodename_db.h
--- a/Modules/unicodename_db.h
+++ b/Modules/unicodename_db.h
@@ -18811,3 +18811,452 @@
 #define code_magic 47
 #define code_size 32768
 #define code_poly 32771
+
+typedef struct Alias {
+    char *name;
+    int namelen;
+    int codepoint;
+} alias;
+
+static const int aliases_count = 11;
+static const alias name_aliases[] = {
+    {"LATIN CAPITAL LETTER GHA", 24, 0x01A2},
+    {"LATIN SMALL LETTER GHA", 22, 0x01A3},
+    {"KANNADA LETTER LLLA", 19, 0x0CDE},
+    {"LAO LETTER FO FON", 17, 0x0E9D},
+    {"LAO LETTER FO FAY", 17, 0x0E9F},
+    {"LAO LETTER RO", 13, 0x0EA3},
+    {"LAO LETTER LO", 13, 0x0EA5},
+    {"TIBETAN MARK BKA- SHOG GI MGO RGYAN", 35, 0x0FD0},
+    {"YI SYLLABLE ITERATION MARK", 26, 0xA015},
+    {"PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRACKET", 61, 0xFE18},
+    {"BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS", 52, 0x1D0C5},
+};
+
+typedef struct NamedSequence {
+    char *name;
+    int seqlen;
+    Py_UCS2 seq[4];
+} named_sequence;
+
+static const int named_sequences_count = 418;
+static const named_sequence named_sequences[] = {
+    {"BENGALI LETTER KHINYA", 3, {0x0995, 0x09CD, 0x09B7}},
+    {"GEORGIAN LETTER U-BRJGU", 2, {0x10E3, 0x0302}},
+    {"HIRAGANA LETTER BIDAKUON NGA", 2, {0x304B, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGE", 2, {0x3051, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGI", 2, {0x304D, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGO", 2, {0x3053, 0x309A}},
+    {"HIRAGANA LETTER BIDAKUON NGU", 2, {0x304F, 0x309A}},
+    {"KATAKANA LETTER AINU CE", 2, {0x30BB, 0x309A}},
+    {"KATAKANA LETTER AINU P", 2, {0x31F7, 0x309A}},
+    {"KATAKANA LETTER AINU TO", 2, {0x30C8, 0x309A}},
+    {"KATAKANA LETTER AINU TU", 2, {0x30C4, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGA", 2, {0x30AB, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGE", 2, {0x30B1, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGI", 2, {0x30AD, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGO", 2, {0x30B3, 0x309A}},
+    {"KATAKANA LETTER BIDAKUON NGU", 2, {0x30AF, 0x309A}},
+    {"KHMER CONSONANT SIGN COENG BA", 2, {0x17D2, 0x1794}},
+    {"KHMER CONSONANT SIGN COENG CA", 2, {0x17D2, 0x1785}},
+    {"KHMER CONSONANT SIGN COENG CHA", 2, {0x17D2, 0x1786}},
+    {"KHMER CONSONANT SIGN COENG CHO", 2, {0x17D2, 0x1788}},
+    {"KHMER CONSONANT SIGN COENG CO", 2, {0x17D2, 0x1787}},
+    {"KHMER CONSONANT SIGN COENG DA", 2, {0x17D2, 0x178A}},
+    {"KHMER CONSONANT SIGN COENG DO", 2, {0x17D2, 0x178C}},
+    {"KHMER CONSONANT SIGN COENG HA", 2, {0x17D2, 0x17A0}},
+    {"KHMER CONSONANT SIGN COENG KA", 2, {0x17D2, 0x1780}},
+    {"KHMER CONSONANT SIGN COENG KHA", 2, {0x17D2, 0x1781}},
+    {"KHMER CONSONANT SIGN COENG KHO", 2, {0x17D2, 0x1783}},
+    {"KHMER CONSONANT SIGN COENG KO", 2, {0x17D2, 0x1782}},
+    {"KHMER CONSONANT SIGN COENG LA", 2, {0x17D2, 0x17A1}},
+    {"KHMER CONSONANT SIGN COENG LO", 2, {0x17D2, 0x179B}},
+    {"KHMER CONSONANT SIGN COENG MO", 2, {0x17D2, 0x1798}},
+    {"KHMER CONSONANT SIGN COENG NA", 2, {0x17D2, 0x178E}},
+    {"KHMER CONSONANT SIGN COENG NGO", 2, {0x17D2, 0x1784}},
+    {"KHMER CONSONANT SIGN COENG NO", 2, {0x17D2, 0x1793}},
+    {"KHMER CONSONANT SIGN COENG NYO", 2, {0x17D2, 0x1789}},
+    {"KHMER CONSONANT SIGN COENG PHA", 2, {0x17D2, 0x1795}},
+    {"KHMER CONSONANT SIGN COENG PHO", 2, {0x17D2, 0x1797}},
+    {"KHMER CONSONANT SIGN COENG PO", 2, {0x17D2, 0x1796}},
+    {"KHMER CONSONANT SIGN COENG RO", 2, {0x17D2, 0x179A}},
+    {"KHMER CONSONANT SIGN COENG SA", 2, {0x17D2, 0x179F}},
+    {"KHMER CONSONANT SIGN COENG SHA", 2, {0x17D2, 0x179D}},
+    {"KHMER CONSONANT SIGN COENG SSA", 2, {0x17D2, 0x179E}},
+    {"KHMER CONSONANT SIGN COENG TA", 2, {0x17D2, 0x178F}},
+    {"KHMER CONSONANT SIGN COENG THA", 2, {0x17D2, 0x1790}},
+    {"KHMER CONSONANT SIGN COENG THO", 2, {0x17D2, 0x1792}},
+    {"KHMER CONSONANT SIGN COENG TO", 2, {0x17D2, 0x1791}},
+    {"KHMER CONSONANT SIGN COENG TTHA", 2, {0x17D2, 0x178B}},
+    {"KHMER CONSONANT SIGN COENG TTHO", 2, {0x17D2, 0x178D}},
+    {"KHMER CONSONANT SIGN COENG VO", 2, {0x17D2, 0x179C}},
+    {"KHMER CONSONANT SIGN COENG YO", 2, {0x17D2, 0x1799}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG QE", 2, {0x17D2, 0x17AF}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG QU", 2, {0x17D2, 0x17A7}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG RY", 2, {0x17D2, 0x17AB}},
+    {"KHMER INDEPENDENT VOWEL SIGN COENG RYY", 2, {0x17D2, 0x17AC}},
+    {"KHMER VOWEL SIGN AAM", 2, {0x17B6, 0x17C6}},
+    {"KHMER VOWEL SIGN COENG QA", 2, {0x17D2, 0x17A2}},
+    {"KHMER VOWEL SIGN OM", 2, {0x17BB, 0x17C6}},
+    {"LATIN CAPITAL LETTER A WITH MACRON AND GRAVE", 2, {0x0100, 0x0300}},
+    {"LATIN CAPITAL LETTER A WITH OGONEK AND ACUTE", 2, {0x0104, 0x0301}},
+    {"LATIN CAPITAL LETTER A WITH OGONEK AND TILDE", 2, {0x0104, 0x0303}},
+    {"LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND CARON", 2, {0x00CA, 0x030C}},
+    {"LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND MACRON", 2, {0x00CA, 0x0304}},
+    {"LATIN CAPITAL LETTER E WITH DOT ABOVE AND ACUTE", 2, {0x0116, 0x0301}},
+    {"LATIN CAPITAL LETTER E WITH DOT ABOVE AND TILDE", 2, {0x0116, 0x0303}},
+    {"LATIN CAPITAL LETTER E WITH OGONEK AND ACUTE", 2, {0x0118, 0x0301}},
+    {"LATIN CAPITAL LETTER E WITH OGONEK AND TILDE", 2, {0x0118, 0x0303}},
+    {"LATIN CAPITAL LETTER E WITH VERTICAL LINE BELOW", 2, {0x0045, 0x0329}},
+    {"LATIN CAPITAL LETTER E WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00C9, 0x0329}},
+    {"LATIN CAPITAL LETTER E WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00C8, 0x0329}},
+    {"LATIN CAPITAL LETTER I WITH MACRON AND GRAVE", 2, {0x012A, 0x0300}},
+    {"LATIN CAPITAL LETTER I WITH OGONEK AND ACUTE", 2, {0x012E, 0x0301}},
+    {"LATIN CAPITAL LETTER I WITH OGONEK AND TILDE", 2, {0x012E, 0x0303}},
+    {"LATIN CAPITAL LETTER J WITH TILDE", 2, {0x004A, 0x0303}},
+    {"LATIN CAPITAL LETTER L WITH TILDE", 2, {0x004C, 0x0303}},
+    {"LATIN CAPITAL LETTER M WITH TILDE", 2, {0x004D, 0x0303}},
+    {"LATIN CAPITAL LETTER O WITH VERTICAL LINE BELOW", 2, {0x004F, 0x0329}},
+    {"LATIN CAPITAL LETTER O WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00D3, 0x0329}},
+    {"LATIN CAPITAL LETTER O WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00D2, 0x0329}},
+    {"LATIN CAPITAL LETTER R WITH TILDE", 2, {0x0052, 0x0303}},
+    {"LATIN CAPITAL LETTER S WITH VERTICAL LINE BELOW", 2, {0x0053, 0x0329}},
+    {"LATIN CAPITAL LETTER U WITH MACRON AND ACUTE", 2, {0x016A, 0x0301}},
+    {"LATIN CAPITAL LETTER U WITH MACRON AND GRAVE", 2, {0x016A, 0x0300}},
+    {"LATIN CAPITAL LETTER U WITH MACRON AND TILDE", 2, {0x016A, 0x0303}},
+    {"LATIN CAPITAL LETTER U WITH OGONEK AND ACUTE", 2, {0x0172, 0x0301}},
+    {"LATIN CAPITAL LETTER U WITH OGONEK AND TILDE", 2, {0x0172, 0x0303}},
+    {"LATIN SMALL LETTER A WITH MACRON AND GRAVE", 2, {0x0101, 0x0300}},
+    {"LATIN SMALL LETTER A WITH OGONEK AND ACUTE", 2, {0x0105, 0x0301}},
+    {"LATIN SMALL LETTER A WITH OGONEK AND TILDE", 2, {0x0105, 0x0303}},
+    {"LATIN SMALL LETTER AE WITH GRAVE", 2, {0x00E6, 0x0300}},
+    {"LATIN SMALL LETTER E WITH CIRCUMFLEX AND CARON", 2, {0x00EA, 0x030C}},
+    {"LATIN SMALL LETTER E WITH CIRCUMFLEX AND MACRON", 2, {0x00EA, 0x0304}},
+    {"LATIN SMALL LETTER E WITH DOT ABOVE AND ACUTE", 2, {0x0117, 0x0301}},
+    {"LATIN SMALL LETTER E WITH DOT ABOVE AND TILDE", 2, {0x0117, 0x0303}},
+    {"LATIN SMALL LETTER E WITH OGONEK AND ACUTE", 2, {0x0119, 0x0301}},
+    {"LATIN SMALL LETTER E WITH OGONEK AND TILDE", 2, {0x0119, 0x0303}},
+    {"LATIN SMALL LETTER E WITH VERTICAL LINE BELOW", 2, {0x0065, 0x0329}},
+    {"LATIN SMALL LETTER E WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00E9, 0x0329}},
+    {"LATIN SMALL LETTER E WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00E8, 0x0329}},
+    {"LATIN SMALL LETTER HOOKED SCHWA WITH ACUTE", 2, {0x025A, 0x0301}},
+    {"LATIN SMALL LETTER HOOKED SCHWA WITH GRAVE", 2, {0x025A, 0x0300}},
+    {"LATIN SMALL LETTER I WITH DOT ABOVE AND ACUTE", 3, {0x0069, 0x0307, 0x0301}},
+    {"LATIN SMALL LETTER I WITH DOT ABOVE AND GRAVE", 3, {0x0069, 0x0307, 0x0300}},
+    {"LATIN SMALL LETTER I WITH DOT ABOVE AND TILDE", 3, {0x0069, 0x0307, 0x0303}},
+    {"LATIN SMALL LETTER I WITH MACRON AND GRAVE", 2, {0x012B, 0x0300}},
+    {"LATIN SMALL LETTER I WITH OGONEK AND DOT ABOVE AND ACUTE", 3, {0x012F, 0x0307, 0x0301}},
+    {"LATIN SMALL LETTER I WITH OGONEK AND DOT ABOVE AND TILDE", 3, {0x012F, 0x0307, 0x0303}},
+    {"LATIN SMALL LETTER J WITH DOT ABOVE AND TILDE", 3, {0x006A, 0x0307, 0x0303}},
+    {"LATIN SMALL LETTER L WITH TILDE", 2, {0x006C, 0x0303}},
+    {"LATIN SMALL LETTER M WITH TILDE", 2, {0x006D, 0x0303}},
+    {"LATIN SMALL LETTER NG WITH TILDE ABOVE", 3, {0x006E, 0x0360, 0x0067}},
+    {"LATIN SMALL LETTER O WITH VERTICAL LINE BELOW", 2, {0x006F, 0x0329}},
+    {"LATIN SMALL LETTER O WITH VERTICAL LINE BELOW AND ACUTE", 2, {0x00F3, 0x0329}},
+    {"LATIN SMALL LETTER O WITH VERTICAL LINE BELOW AND GRAVE", 2, {0x00F2, 0x0329}},
+    {"LATIN SMALL LETTER OPEN O WITH ACUTE", 2, {0x0254, 0x0301}},
+    {"LATIN SMALL LETTER OPEN O WITH GRAVE", 2, {0x0254, 0x0300}},
+    {"LATIN SMALL LETTER R WITH TILDE", 2, {0x0072, 0x0303}},
+    {"LATIN SMALL LETTER S WITH VERTICAL LINE BELOW", 2, {0x0073, 0x0329}},
+    {"LATIN SMALL LETTER SCHWA WITH ACUTE", 2, {0x0259, 0x0301}},
+    {"LATIN SMALL LETTER SCHWA WITH GRAVE", 2, {0x0259, 0x0300}},
+    {"LATIN SMALL LETTER TURNED V WITH ACUTE", 2, {0x028C, 0x0301}},
+    {"LATIN SMALL LETTER TURNED V WITH GRAVE", 2, {0x028C, 0x0300}},
+    {"LATIN SMALL LETTER U WITH MACRON AND ACUTE", 2, {0x016B, 0x0301}},
+    {"LATIN SMALL LETTER U WITH MACRON AND GRAVE", 2, {0x016B, 0x0300}},
+    {"LATIN SMALL LETTER U WITH MACRON AND TILDE", 2, {0x016B, 0x0303}},
+    {"LATIN SMALL LETTER U WITH OGONEK AND ACUTE", 2, {0x0173, 0x0301}},
+    {"LATIN SMALL LETTER U WITH OGONEK AND TILDE", 2, {0x0173, 0x0303}},
+    {"MODIFIER LETTER EXTRA-HIGH EXTRA-LOW CONTOUR TONE BAR", 2, {0x02E5, 0x02E9}},
+    {"MODIFIER LETTER EXTRA-LOW EXTRA-HIGH CONTOUR TONE BAR", 2, {0x02E9, 0x02E5}},
+    {"TAMIL CONSONANT C", 2, {0x0B9A, 0x0BCD}},
+    {"TAMIL CONSONANT H", 2, {0x0BB9, 0x0BCD}},
+    {"TAMIL CONSONANT J", 2, {0x0B9C, 0x0BCD}},
+    {"TAMIL CONSONANT K", 2, {0x0B95, 0x0BCD}},
+    {"TAMIL CONSONANT KSS", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCD}},
+    {"TAMIL CONSONANT L", 2, {0x0BB2, 0x0BCD}},
+    {"TAMIL CONSONANT LL", 2, {0x0BB3, 0x0BCD}},
+    {"TAMIL CONSONANT LLL", 2, {0x0BB4, 0x0BCD}},
+    {"TAMIL CONSONANT M", 2, {0x0BAE, 0x0BCD}},
+    {"TAMIL CONSONANT N", 2, {0x0BA8, 0x0BCD}},
+    {"TAMIL CONSONANT NG", 2, {0x0B99, 0x0BCD}},
+    {"TAMIL CONSONANT NN", 2, {0x0BA3, 0x0BCD}},
+    {"TAMIL CONSONANT NNN", 2, {0x0BA9, 0x0BCD}},
+    {"TAMIL CONSONANT NY", 2, {0x0B9E, 0x0BCD}},
+    {"TAMIL CONSONANT P", 2, {0x0BAA, 0x0BCD}},
+    {"TAMIL CONSONANT R", 2, {0x0BB0, 0x0BCD}},
+    {"TAMIL CONSONANT RR", 2, {0x0BB1, 0x0BCD}},
+    {"TAMIL CONSONANT S", 2, {0x0BB8, 0x0BCD}},
+    {"TAMIL CONSONANT SH", 2, {0x0BB6, 0x0BCD}},
+    {"TAMIL CONSONANT SS", 2, {0x0BB7, 0x0BCD}},
+    {"TAMIL CONSONANT T", 2, {0x0BA4, 0x0BCD}},
+    {"TAMIL CONSONANT TT", 2, {0x0B9F, 0x0BCD}},
+    {"TAMIL CONSONANT V", 2, {0x0BB5, 0x0BCD}},
+    {"TAMIL CONSONANT Y", 2, {0x0BAF, 0x0BCD}},
+    {"TAMIL SYLLABLE CAA", 2, {0x0B9A, 0x0BBE}},
+    {"TAMIL SYLLABLE CAI", 2, {0x0B9A, 0x0BC8}},
+    {"TAMIL SYLLABLE CAU", 2, {0x0B9A, 0x0BCC}},
+    {"TAMIL SYLLABLE CE", 2, {0x0B9A, 0x0BC6}},
+    {"TAMIL SYLLABLE CEE", 2, {0x0B9A, 0x0BC7}},
+    {"TAMIL SYLLABLE CI", 2, {0x0B9A, 0x0BBF}},
+    {"TAMIL SYLLABLE CII", 2, {0x0B9A, 0x0BC0}},
+    {"TAMIL SYLLABLE CO", 2, {0x0B9A, 0x0BCA}},
+    {"TAMIL SYLLABLE COO", 2, {0x0B9A, 0x0BCB}},
+    {"TAMIL SYLLABLE CU", 2, {0x0B9A, 0x0BC1}},
+    {"TAMIL SYLLABLE CUU", 2, {0x0B9A, 0x0BC2}},
+    {"TAMIL SYLLABLE HAA", 2, {0x0BB9, 0x0BBE}},
+    {"TAMIL SYLLABLE HAI", 2, {0x0BB9, 0x0BC8}},
+    {"TAMIL SYLLABLE HAU", 2, {0x0BB9, 0x0BCC}},
+    {"TAMIL SYLLABLE HE", 2, {0x0BB9, 0x0BC6}},
+    {"TAMIL SYLLABLE HEE", 2, {0x0BB9, 0x0BC7}},
+    {"TAMIL SYLLABLE HI", 2, {0x0BB9, 0x0BBF}},
+    {"TAMIL SYLLABLE HII", 2, {0x0BB9, 0x0BC0}},
+    {"TAMIL SYLLABLE HO", 2, {0x0BB9, 0x0BCA}},
+    {"TAMIL SYLLABLE HOO", 2, {0x0BB9, 0x0BCB}},
+    {"TAMIL SYLLABLE HU", 2, {0x0BB9, 0x0BC1}},
+    {"TAMIL SYLLABLE HUU", 2, {0x0BB9, 0x0BC2}},
+    {"TAMIL SYLLABLE JAA", 2, {0x0B9C, 0x0BBE}},
+    {"TAMIL SYLLABLE JAI", 2, {0x0B9C, 0x0BC8}},
+    {"TAMIL SYLLABLE JAU", 2, {0x0B9C, 0x0BCC}},
+    {"TAMIL SYLLABLE JE", 2, {0x0B9C, 0x0BC6}},
+    {"TAMIL SYLLABLE JEE", 2, {0x0B9C, 0x0BC7}},
+    {"TAMIL SYLLABLE JI", 2, {0x0B9C, 0x0BBF}},
+    {"TAMIL SYLLABLE JII", 2, {0x0B9C, 0x0BC0}},
+    {"TAMIL SYLLABLE JO", 2, {0x0B9C, 0x0BCA}},
+    {"TAMIL SYLLABLE JOO", 2, {0x0B9C, 0x0BCB}},
+    {"TAMIL SYLLABLE JU", 2, {0x0B9C, 0x0BC1}},
+    {"TAMIL SYLLABLE JUU", 2, {0x0B9C, 0x0BC2}},
+    {"TAMIL SYLLABLE KAA", 2, {0x0B95, 0x0BBE}},
+    {"TAMIL SYLLABLE KAI", 2, {0x0B95, 0x0BC8}},
+    {"TAMIL SYLLABLE KAU", 2, {0x0B95, 0x0BCC}},
+    {"TAMIL SYLLABLE KE", 2, {0x0B95, 0x0BC6}},
+    {"TAMIL SYLLABLE KEE", 2, {0x0B95, 0x0BC7}},
+    {"TAMIL SYLLABLE KI", 2, {0x0B95, 0x0BBF}},
+    {"TAMIL SYLLABLE KII", 2, {0x0B95, 0x0BC0}},
+    {"TAMIL SYLLABLE KO", 2, {0x0B95, 0x0BCA}},
+    {"TAMIL SYLLABLE KOO", 2, {0x0B95, 0x0BCB}},
+    {"TAMIL SYLLABLE KSSA", 3, {0x0B95, 0x0BCD, 0x0BB7}},
+    {"TAMIL SYLLABLE KSSAA", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BBE}},
+    {"TAMIL SYLLABLE KSSAI", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC8}},
+    {"TAMIL SYLLABLE KSSAU", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCC}},
+    {"TAMIL SYLLABLE KSSE", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC6}},
+    {"TAMIL SYLLABLE KSSEE", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC7}},
+    {"TAMIL SYLLABLE KSSI", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BBF}},
+    {"TAMIL SYLLABLE KSSII", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC0}},
+    {"TAMIL SYLLABLE KSSO", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCA}},
+    {"TAMIL SYLLABLE KSSOO", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BCB}},
+    {"TAMIL SYLLABLE KSSU", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC1}},
+    {"TAMIL SYLLABLE KSSUU", 4, {0x0B95, 0x0BCD, 0x0BB7, 0x0BC2}},
+    {"TAMIL SYLLABLE KU", 2, {0x0B95, 0x0BC1}},
+    {"TAMIL SYLLABLE KUU", 2, {0x0B95, 0x0BC2}},
+    {"TAMIL SYLLABLE LAA", 2, {0x0BB2, 0x0BBE}},
+    {"TAMIL SYLLABLE LAI", 2, {0x0BB2, 0x0BC8}},
+    {"TAMIL SYLLABLE LAU", 2, {0x0BB2, 0x0BCC}},
+    {"TAMIL SYLLABLE LE", 2, {0x0BB2, 0x0BC6}},
+    {"TAMIL SYLLABLE LEE", 2, {0x0BB2, 0x0BC7}},
+    {"TAMIL SYLLABLE LI", 2, {0x0BB2, 0x0BBF}},
+    {"TAMIL SYLLABLE LII", 2, {0x0BB2, 0x0BC0}},
+    {"TAMIL SYLLABLE LLAA", 2, {0x0BB3, 0x0BBE}},
+    {"TAMIL SYLLABLE LLAI", 2, {0x0BB3, 0x0BC8}},
+    {"TAMIL SYLLABLE LLAU", 2, {0x0BB3, 0x0BCC}},
+    {"TAMIL SYLLABLE LLE", 2, {0x0BB3, 0x0BC6}},
+    {"TAMIL SYLLABLE LLEE", 2, {0x0BB3, 0x0BC7}},
+    {"TAMIL SYLLABLE LLI", 2, {0x0BB3, 0x0BBF}},
+    {"TAMIL SYLLABLE LLII", 2, {0x0BB3, 0x0BC0}},
+    {"TAMIL SYLLABLE LLLAA", 2, {0x0BB4, 0x0BBE}},
+    {"TAMIL SYLLABLE LLLAI", 2, {0x0BB4, 0x0BC8}},
+    {"TAMIL SYLLABLE LLLAU", 2, {0x0BB4, 0x0BCC}},
+    {"TAMIL SYLLABLE LLLE", 2, {0x0BB4, 0x0BC6}},
+    {"TAMIL SYLLABLE LLLEE", 2, {0x0BB4, 0x0BC7}},
+    {"TAMIL SYLLABLE LLLI", 2, {0x0BB4, 0x0BBF}},
+    {"TAMIL SYLLABLE LLLII", 2, {0x0BB4, 0x0BC0}},
+    {"TAMIL SYLLABLE LLLO", 2, {0x0BB4, 0x0BCA}},
+    {"TAMIL SYLLABLE LLLOO", 2, {0x0BB4, 0x0BCB}},
+    {"TAMIL SYLLABLE LLLU", 2, {0x0BB4, 0x0BC1}},
+    {"TAMIL SYLLABLE LLLUU", 2, {0x0BB4, 0x0BC2}},
+    {"TAMIL SYLLABLE LLO", 2, {0x0BB3, 0x0BCA}},
+    {"TAMIL SYLLABLE LLOO", 2, {0x0BB3, 0x0BCB}},
+    {"TAMIL SYLLABLE LLU", 2, {0x0BB3, 0x0BC1}},
+    {"TAMIL SYLLABLE LLUU", 2, {0x0BB3, 0x0BC2}},
+    {"TAMIL SYLLABLE LO", 2, {0x0BB2, 0x0BCA}},
+    {"TAMIL SYLLABLE LOO", 2, {0x0BB2, 0x0BCB}},
+    {"TAMIL SYLLABLE LU", 2, {0x0BB2, 0x0BC1}},
+    {"TAMIL SYLLABLE LUU", 2, {0x0BB2, 0x0BC2}},
+    {"TAMIL SYLLABLE MAA", 2, {0x0BAE, 0x0BBE}},
+    {"TAMIL SYLLABLE MAI", 2, {0x0BAE, 0x0BC8}},
+    {"TAMIL SYLLABLE MAU", 2, {0x0BAE, 0x0BCC}},
+    {"TAMIL SYLLABLE ME", 2, {0x0BAE, 0x0BC6}},
+    {"TAMIL SYLLABLE MEE", 2, {0x0BAE, 0x0BC7}},
+    {"TAMIL SYLLABLE MI", 2, {0x0BAE, 0x0BBF}},
+    {"TAMIL SYLLABLE MII", 2, {0x0BAE, 0x0BC0}},
+    {"TAMIL SYLLABLE MO", 2, {0x0BAE, 0x0BCA}},
+    {"TAMIL SYLLABLE MOO", 2, {0x0BAE, 0x0BCB}},
+    {"TAMIL SYLLABLE MU", 2, {0x0BAE, 0x0BC1}},
+    {"TAMIL SYLLABLE MUU", 2, {0x0BAE, 0x0BC2}},
+    {"TAMIL SYLLABLE NAA", 2, {0x0BA8, 0x0BBE}},
+    {"TAMIL SYLLABLE NAI", 2, {0x0BA8, 0x0BC8}},
+    {"TAMIL SYLLABLE NAU", 2, {0x0BA8, 0x0BCC}},
+    {"TAMIL SYLLABLE NE", 2, {0x0BA8, 0x0BC6}},
+    {"TAMIL SYLLABLE NEE", 2, {0x0BA8, 0x0BC7}},
+    {"TAMIL SYLLABLE NGAA", 2, {0x0B99, 0x0BBE}},
+    {"TAMIL SYLLABLE NGAI", 2, {0x0B99, 0x0BC8}},
+    {"TAMIL SYLLABLE NGAU", 2, {0x0B99, 0x0BCC}},
+    {"TAMIL SYLLABLE NGE", 2, {0x0B99, 0x0BC6}},
+    {"TAMIL SYLLABLE NGEE", 2, {0x0B99, 0x0BC7}},
+    {"TAMIL SYLLABLE NGI", 2, {0x0B99, 0x0BBF}},
+    {"TAMIL SYLLABLE NGII", 2, {0x0B99, 0x0BC0}},
+    {"TAMIL SYLLABLE NGO", 2, {0x0B99, 0x0BCA}},
+    {"TAMIL SYLLABLE NGOO", 2, {0x0B99, 0x0BCB}},
+    {"TAMIL SYLLABLE NGU", 2, {0x0B99, 0x0BC1}},
+    {"TAMIL SYLLABLE NGUU", 2, {0x0B99, 0x0BC2}},
+    {"TAMIL SYLLABLE NI", 2, {0x0BA8, 0x0BBF}},
+    {"TAMIL SYLLABLE NII", 2, {0x0BA8, 0x0BC0}},
+    {"TAMIL SYLLABLE NNAA", 2, {0x0BA3, 0x0BBE}},
+    {"TAMIL SYLLABLE NNAI", 2, {0x0BA3, 0x0BC8}},
+    {"TAMIL SYLLABLE NNAU", 2, {0x0BA3, 0x0BCC}},
+    {"TAMIL SYLLABLE NNE", 2, {0x0BA3, 0x0BC6}},
+    {"TAMIL SYLLABLE NNEE", 2, {0x0BA3, 0x0BC7}},
+    {"TAMIL SYLLABLE NNI", 2, {0x0BA3, 0x0BBF}},
+    {"TAMIL SYLLABLE NNII", 2, {0x0BA3, 0x0BC0}},
+    {"TAMIL SYLLABLE NNNAA", 2, {0x0BA9, 0x0BBE}},
+    {"TAMIL SYLLABLE NNNAI", 2, {0x0BA9, 0x0BC8}},
+    {"TAMIL SYLLABLE NNNAU", 2, {0x0BA9, 0x0BCC}},
+    {"TAMIL SYLLABLE NNNE", 2, {0x0BA9, 0x0BC6}},
+    {"TAMIL SYLLABLE NNNEE", 2, {0x0BA9, 0x0BC7}},
+    {"TAMIL SYLLABLE NNNI", 2, {0x0BA9, 0x0BBF}},
+    {"TAMIL SYLLABLE NNNII", 2, {0x0BA9, 0x0BC0}},
+    {"TAMIL SYLLABLE NNNO", 2, {0x0BA9, 0x0BCA}},
+    {"TAMIL SYLLABLE NNNOO", 2, {0x0BA9, 0x0BCB}},
+    {"TAMIL SYLLABLE NNNU", 2, {0x0BA9, 0x0BC1}},
+    {"TAMIL SYLLABLE NNNUU", 2, {0x0BA9, 0x0BC2}},
+    {"TAMIL SYLLABLE NNO", 2, {0x0BA3, 0x0BCA}},
+    {"TAMIL SYLLABLE NNOO", 2, {0x0BA3, 0x0BCB}},
+    {"TAMIL SYLLABLE NNU", 2, {0x0BA3, 0x0BC1}},
+    {"TAMIL SYLLABLE NNUU", 2, {0x0BA3, 0x0BC2}},
+    {"TAMIL SYLLABLE NO", 2, {0x0BA8, 0x0BCA}},
+    {"TAMIL SYLLABLE NOO", 2, {0x0BA8, 0x0BCB}},
+    {"TAMIL SYLLABLE NU", 2, {0x0BA8, 0x0BC1}},
+    {"TAMIL SYLLABLE NUU", 2, {0x0BA8, 0x0BC2}},
+    {"TAMIL SYLLABLE NYAA", 2, {0x0B9E, 0x0BBE}},
+    {"TAMIL SYLLABLE NYAI", 2, {0x0B9E, 0x0BC8}},
+    {"TAMIL SYLLABLE NYAU", 2, {0x0B9E, 0x0BCC}},
+    {"TAMIL SYLLABLE NYE", 2, {0x0B9E, 0x0BC6}},
+    {"TAMIL SYLLABLE NYEE", 2, {0x0B9E, 0x0BC7}},
+    {"TAMIL SYLLABLE NYI", 2, {0x0B9E, 0x0BBF}},
+    {"TAMIL SYLLABLE NYII", 2, {0x0B9E, 0x0BC0}},
+    {"TAMIL SYLLABLE NYO", 2, {0x0B9E, 0x0BCA}},
+    {"TAMIL SYLLABLE NYOO", 2, {0x0B9E, 0x0BCB}},
+    {"TAMIL SYLLABLE NYU", 2, {0x0B9E, 0x0BC1}},
+    {"TAMIL SYLLABLE NYUU", 2, {0x0B9E, 0x0BC2}},
+    {"TAMIL SYLLABLE PAA", 2, {0x0BAA, 0x0BBE}},
+    {"TAMIL SYLLABLE PAI", 2, {0x0BAA, 0x0BC8}},
+    {"TAMIL SYLLABLE PAU", 2, {0x0BAA, 0x0BCC}},
+    {"TAMIL SYLLABLE PE", 2, {0x0BAA, 0x0BC6}},
+    {"TAMIL SYLLABLE PEE", 2, {0x0BAA, 0x0BC7}},
+    {"TAMIL SYLLABLE PI", 2, {0x0BAA, 0x0BBF}},
+    {"TAMIL SYLLABLE PII", 2, {0x0BAA, 0x0BC0}},
+    {"TAMIL SYLLABLE PO", 2, {0x0BAA, 0x0BCA}},
+    {"TAMIL SYLLABLE POO", 2, {0x0BAA, 0x0BCB}},
+    {"TAMIL SYLLABLE PU", 2, {0x0BAA, 0x0BC1}},
+    {"TAMIL SYLLABLE PUU", 2, {0x0BAA, 0x0BC2}},
+    {"TAMIL SYLLABLE RAA", 2, {0x0BB0, 0x0BBE}},
+    {"TAMIL SYLLABLE RAI", 2, {0x0BB0, 0x0BC8}},
+    {"TAMIL SYLLABLE RAU", 2, {0x0BB0, 0x0BCC}},
+    {"TAMIL SYLLABLE RE", 2, {0x0BB0, 0x0BC6}},
+    {"TAMIL SYLLABLE REE", 2, {0x0BB0, 0x0BC7}},
+    {"TAMIL SYLLABLE RI", 2, {0x0BB0, 0x0BBF}},
+    {"TAMIL SYLLABLE RII", 2, {0x0BB0, 0x0BC0}},
+    {"TAMIL SYLLABLE RO", 2, {0x0BB0, 0x0BCA}},
+    {"TAMIL SYLLABLE ROO", 2, {0x0BB0, 0x0BCB}},
+    {"TAMIL SYLLABLE RRAA", 2, {0x0BB1, 0x0BBE}},
+    {"TAMIL SYLLABLE RRAI", 2, {0x0BB1, 0x0BC8}},
+    {"TAMIL SYLLABLE RRAU", 2, {0x0BB1, 0x0BCC}},
+    {"TAMIL SYLLABLE RRE", 2, {0x0BB1, 0x0BC6}},
+    {"TAMIL SYLLABLE RREE", 2, {0x0BB1, 0x0BC7}},
+    {"TAMIL SYLLABLE RRI", 2, {0x0BB1, 0x0BBF}},
+    {"TAMIL SYLLABLE RRII", 2, {0x0BB1, 0x0BC0}},
+    {"TAMIL SYLLABLE RRO", 2, {0x0BB1, 0x0BCA}},
+    {"TAMIL SYLLABLE RROO", 2, {0x0BB1, 0x0BCB}},
+    {"TAMIL SYLLABLE RRU", 2, {0x0BB1, 0x0BC1}},
+    {"TAMIL SYLLABLE RRUU", 2, {0x0BB1, 0x0BC2}},
+    {"TAMIL SYLLABLE RU", 2, {0x0BB0, 0x0BC1}},
+    {"TAMIL SYLLABLE RUU", 2, {0x0BB0, 0x0BC2}},
+    {"TAMIL SYLLABLE SAA", 2, {0x0BB8, 0x0BBE}},
+    {"TAMIL SYLLABLE SAI", 2, {0x0BB8, 0x0BC8}},
+    {"TAMIL SYLLABLE SAU", 2, {0x0BB8, 0x0BCC}},
+    {"TAMIL SYLLABLE SE", 2, {0x0BB8, 0x0BC6}},
+    {"TAMIL SYLLABLE SEE", 2, {0x0BB8, 0x0BC7}},
+    {"TAMIL SYLLABLE SHAA", 2, {0x0BB6, 0x0BBE}},
+    {"TAMIL SYLLABLE SHAI", 2, {0x0BB6, 0x0BC8}},
+    {"TAMIL SYLLABLE SHAU", 2, {0x0BB6, 0x0BCC}},
+    {"TAMIL SYLLABLE SHE", 2, {0x0BB6, 0x0BC6}},
+    {"TAMIL SYLLABLE SHEE", 2, {0x0BB6, 0x0BC7}},
+    {"TAMIL SYLLABLE SHI", 2, {0x0BB6, 0x0BBF}},
+    {"TAMIL SYLLABLE SHII", 2, {0x0BB6, 0x0BC0}},
+    {"TAMIL SYLLABLE SHO", 2, {0x0BB6, 0x0BCA}},
+    {"TAMIL SYLLABLE SHOO", 2, {0x0BB6, 0x0BCB}},
+    {"TAMIL SYLLABLE SHRII", 4, {0x0BB6, 0x0BCD, 0x0BB0, 0x0BC0}},
+    {"TAMIL SYLLABLE SHU", 2, {0x0BB6, 0x0BC1}},
+    {"TAMIL SYLLABLE SHUU", 2, {0x0BB6, 0x0BC2}},
+    {"TAMIL SYLLABLE SI", 2, {0x0BB8, 0x0BBF}},
+    {"TAMIL SYLLABLE SII", 2, {0x0BB8, 0x0BC0}},
+    {"TAMIL SYLLABLE SO", 2, {0x0BB8, 0x0BCA}},
+    {"TAMIL SYLLABLE SOO", 2, {0x0BB8, 0x0BCB}},
+    {"TAMIL SYLLABLE SSAA", 2, {0x0BB7, 0x0BBE}},
+    {"TAMIL SYLLABLE SSAI", 2, {0x0BB7, 0x0BC8}},
+    {"TAMIL SYLLABLE SSAU", 2, {0x0BB7, 0x0BCC}},
+    {"TAMIL SYLLABLE SSE", 2, {0x0BB7, 0x0BC6}},
+    {"TAMIL SYLLABLE SSEE", 2, {0x0BB7, 0x0BC7}},
+    {"TAMIL SYLLABLE SSI", 2, {0x0BB7, 0x0BBF}},
+    {"TAMIL SYLLABLE SSII", 2, {0x0BB7, 0x0BC0}},
+    {"TAMIL SYLLABLE SSO", 2, {0x0BB7, 0x0BCA}},
+    {"TAMIL SYLLABLE SSOO", 2, {0x0BB7, 0x0BCB}},
+    {"TAMIL SYLLABLE SSU", 2, {0x0BB7, 0x0BC1}},
+    {"TAMIL SYLLABLE SSUU", 2, {0x0BB7, 0x0BC2}},
+    {"TAMIL SYLLABLE SU", 2, {0x0BB8, 0x0BC1}},
+    {"TAMIL SYLLABLE SUU", 2, {0x0BB8, 0x0BC2}},
+    {"TAMIL SYLLABLE TAA", 2, {0x0BA4, 0x0BBE}},
+    {"TAMIL SYLLABLE TAI", 2, {0x0BA4, 0x0BC8}},
+    {"TAMIL SYLLABLE TAU", 2, {0x0BA4, 0x0BCC}},
+    {"TAMIL SYLLABLE TE", 2, {0x0BA4, 0x0BC6}},
+    {"TAMIL SYLLABLE TEE", 2, {0x0BA4, 0x0BC7}},
+    {"TAMIL SYLLABLE TI", 2, {0x0BA4, 0x0BBF}},
+    {"TAMIL SYLLABLE TII", 2, {0x0BA4, 0x0BC0}},
+    {"TAMIL SYLLABLE TO", 2, {0x0BA4, 0x0BCA}},
+    {"TAMIL SYLLABLE TOO", 2, {0x0BA4, 0x0BCB}},
+    {"TAMIL SYLLABLE TTAA", 2, {0x0B9F, 0x0BBE}},
+    {"TAMIL SYLLABLE TTAI", 2, {0x0B9F, 0x0BC8}},
+    {"TAMIL SYLLABLE TTAU", 2, {0x0B9F, 0x0BCC}},
+    {"TAMIL SYLLABLE TTE", 2, {0x0B9F, 0x0BC6}},
+    {"TAMIL SYLLABLE TTEE", 2, {0x0B9F, 0x0BC7}},
+    {"TAMIL SYLLABLE TTI", 2, {0x0B9F, 0x0BBF}},
+    {"TAMIL SYLLABLE TTII", 2, {0x0B9F, 0x0BC0}},
+    {"TAMIL SYLLABLE TTO", 2, {0x0B9F, 0x0BCA}},
+    {"TAMIL SYLLABLE TTOO", 2, {0x0B9F, 0x0BCB}},
+    {"TAMIL SYLLABLE TTU", 2, {0x0B9F, 0x0BC1}},
+    {"TAMIL SYLLABLE TTUU", 2, {0x0B9F, 0x0BC2}},
+    {"TAMIL SYLLABLE TU", 2, {0x0BA4, 0x0BC1}},
+    {"TAMIL SYLLABLE TUU", 2, {0x0BA4, 0x0BC2}},
+    {"TAMIL SYLLABLE VAA", 2, {0x0BB5, 0x0BBE}},
+    {"TAMIL SYLLABLE VAI", 2, {0x0BB5, 0x0BC8}},
+    {"TAMIL SYLLABLE VAU", 2, {0x0BB5, 0x0BCC}},
+    {"TAMIL SYLLABLE VE", 2, {0x0BB5, 0x0BC6}},
+    {"TAMIL SYLLABLE VEE", 2, {0x0BB5, 0x0BC7}},
+    {"TAMIL SYLLABLE VI", 2, {0x0BB5, 0x0BBF}},
+    {"TAMIL SYLLABLE VII", 2, {0x0BB5, 0x0BC0}},
+    {"TAMIL SYLLABLE VO", 2, {0x0BB5, 0x0BCA}},
+    {"TAMIL SYLLABLE VOO", 2, {0x0BB5, 0x0BCB}},
+    {"TAMIL SYLLABLE VU", 2, {0x0BB5, 0x0BC1}},
+    {"TAMIL SYLLABLE VUU", 2, {0x0BB5, 0x0BC2}},
+    {"TAMIL SYLLABLE YAA", 2, {0x0BAF, 0x0BBE}},
+    {"TAMIL SYLLABLE YAI", 2, {0x0BAF, 0x0BC8}},
+    {"TAMIL SYLLABLE YAU", 2, {0x0BAF, 0x0BCC}},
+    {"TAMIL SYLLABLE YE", 2, {0x0BAF, 0x0BC6}},
+    {"TAMIL SYLLABLE YEE", 2, {0x0BAF, 0x0BC7}},
+    {"TAMIL SYLLABLE YI", 2, {0x0BAF, 0x0BBF}},
+    {"TAMIL SYLLABLE YII", 2, {0x0BAF, 0x0BC0}},
+    {"TAMIL SYLLABLE YO", 2, {0x0BAF, 0x0BCA}},
+    {"TAMIL SYLLABLE YOO", 2, {0x0BAF, 0x0BCB}},
+    {"TAMIL SYLLABLE YU", 2, {0x0BAF, 0x0BC1}},
+    {"TAMIL SYLLABLE YUU", 2, {0x0BAF, 0x0BC2}},
+};
diff --git a/Tools/unicode/makeunicodedata.py b/Tools/unicode/makeunicodedata.py
--- a/Tools/unicode/makeunicodedata.py
+++ b/Tools/unicode/makeunicodedata.py
@@ -25,7 +25,12 @@
 # written by Fredrik Lundh (fredrik at pythonware.com)
 #
 
-import sys, os, zipfile
+import os
+import sys
+import zipfile
+
+from textwrap import dedent
+from operator import itemgetter
 
 SCRIPT = sys.argv[0]
 VERSION = "3.2"
@@ -39,6 +44,8 @@
 DERIVED_CORE_PROPERTIES = "DerivedCoreProperties%s.txt"
 DERIVEDNORMALIZATION_PROPS = "DerivedNormalizationProps%s.txt"
 LINE_BREAK = "LineBreak%s.txt"
+NAME_ALIASES = "NameAliases%s.txt"
+NAMED_SEQUENCES = "NamedSequences%s.txt"
 
 old_versions = ["3.2.0"]
 
@@ -692,6 +699,40 @@
     print("/* name->code dictionary */", file=fp)
     codehash.dump(fp, trace)
 
+    print(dedent("""
+        typedef struct Alias {
+            char *name;
+            int namelen;
+            int codepoint;
+        } alias;
+        """), file=fp)
+
+    print('static const int aliases_count = %d;' % len(unicode.aliases), file=fp)
+
+    print('static const alias name_aliases[] = {', file=fp)
+    for name, codepoint in unicode.aliases:
+        print('    {"%s", %d, 0x%04X},' % (name, len(name), codepoint), file=fp)
+    print('};', file=fp)
+
+    # the Py_UCS2 seq[4] should use Py_UCS4 if non-BMP chars are added to the
+    # sequences and have an higher number of elements if the sequences get longer
+    print(dedent("""
+        typedef struct NamedSequence {
+            char *name;
+            int seqlen;
+            Py_UCS2 seq[4];
+        } named_sequence;
+        """), file=fp)
+
+    print('static const int named_sequences_count = %d;' % len(unicode.named_sequences),
+          file=fp)
+
+    print('static const named_sequence named_sequences[] = {', file=fp)
+    for name, sequence in unicode.named_sequences:
+        seq_str = ', '.join('0x%04X' % cp for cp in sequence)
+        print('    {"%s", %d, {%s}},' % (name, len(sequence), seq_str), file=fp)
+    print('};', file=fp)
+
     fp.close()
 
 
@@ -855,6 +896,31 @@
         self.table = table
         self.chars = list(range(0x110000)) # unicode 3.2
 
+        self.aliases = []
+        with open_data(NAME_ALIASES, version) as file:
+            for s in file:
+                s = s.strip()
+                if not s or s.startswith('#'):
+                    continue
+                char, name = s.split(';')
+                char = int(char, 16)
+                self.aliases.append((name, char))
+
+        self.named_sequences = []
+        with open_data(NAMED_SEQUENCES, version) as file:
+            for s in file:
+                s = s.strip()
+                if not s or s.startswith('#'):
+                    continue
+                name, chars = s.split(';')
+                chars = tuple(int(char, 16) for char in chars.split())
+                # check that the structure defined in makeunicodename is OK
+                assert 2 <= len(chars) <= 4, "change the Py_UCS2 array size"
+                assert all(c <= 0xFFFF for c in chars), "use Py_UCS4 instead"
+                self.named_sequences.append((name, chars))
+        # sort names to enable binary search
+        self.named_sequences.sort(key=itemgetter(0))
+
         self.exclusions = {}
         with open_data(COMPOSITION_EXCLUSIONS, version) as file:
             for s in file:

From report at bugs.python.org  Thu Oct  6 12:55:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 06 Oct 2011 10:55:51 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1317898551.38.0.485566163143.issue2771@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Adding 

# ignore html part of multipart/alternative
ignore_alternatives = yes

to the config.ini seems to get rid of the "unnamed" attachments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:01:34 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 06 Oct 2011 11:01:34 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317898894.75.0.362794527014.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Wow, this discussion has gotten quite busy while I've been travelling...

Martin, could you explain what the problems are with bundling a precompiled DLL
for Windows? I am willing to do the work of getting liblzma to compile with VS
if necessary, but I don't know how receptive the upstream maintainer will be to
the changes. If I can explain how lack of VS support is a problem for us, the
request should carry more weight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:19:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 11:19:45 +0000
Subject: [issue9442] Update sys.version doc
In-Reply-To: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>
Message-ID: <E1RBlzL-0000af-QY@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9f6704da4abb by ?ric Araujo in branch '2.7':
Fix markup used in the documentation of sys.prefix and sys.exec_prefix.
http://hg.python.org/cpython/rev/9f6704da4abb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9442>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:24:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 11:24:05 +0000
Subject: [issue9442] Update sys.version doc
In-Reply-To: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>
Message-ID: <E1RBm3X-0000ym-MA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6ea47522f466 by ?ric Araujo in branch '3.2':
Fix markup used in the documentation of sys.prefix and sys.exec_prefix.
http://hg.python.org/cpython/rev/6ea47522f466

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9442>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:24:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 11:24:05 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <E1RBm3X-0000ym-Lq@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e76c6aaff135 by ?ric Araujo in branch 'default':
Add regrtest check for caches in packaging.database (see #12167)
http://hg.python.org/cpython/rev/e76c6aaff135

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:24:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 11:24:06 +0000
Subject: [issue12222] All pysetup commands should respect exit codes
In-Reply-To: <1306833373.02.0.231767797102.issue12222@psf.upfronthosting.co.za>
Message-ID: <E1RBm3X-0000ym-Ly@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ab125793243f by ?ric Araujo in branch 'default':
Fix return code of ?pysetup run COMMAND? (closes #12222)
http://hg.python.org/cpython/rev/ab125793243f

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12222>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:24:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 11:24:06 +0000
Subject: [issue11841] Bug in the verson comparison
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <E1RBm3X-0000ym-MH@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2105ab8553b7 by ?ric Araujo in branch 'default':
Add tests for comparing candidate and final versions in packaging (#11841).
http://hg.python.org/cpython/rev/2105ab8553b7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:24:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 11:24:46 +0000
Subject: [issue13105] Please elaborate on how 2.x and 3.x are different heads
In-Reply-To: <1317770656.72.0.880626385137.issue13105@psf.upfronthosting.co.za>
Message-ID: <1317900286.18.0.498876119995.issue13105@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you paste the email for a starting point?

----------
nosy: +eric.araujo, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13105>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:25:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 11:25:12 +0000
Subject: [issue13105] Please elaborate on how 2.x and 3.x are different heads
In-Reply-To: <1317770656.72.0.880626385137.issue13105@psf.upfronthosting.co.za>
Message-ID: <1317900312.69.0.938109305477.issue13105@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> eric.araujo
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13105>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:38:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 11:38:12 +0000
Subject: [issue13073] message_body argument of HTTPConnection.endheaders is
	undocumented
In-Reply-To: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>
Message-ID: <1317901092.1.0.246854308757.issue13073@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It is IMO a source of confusion that the doc talk about a string instead of ?a bytes object? (3.x) or ?a string (str)? (2.x, unless unicode is supported too).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13073>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:40:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 11:40:56 +0000
Subject: [issue11841] Bug in the verson comparison
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1317901256.29.0.168196143099.issue11841@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I couldn?t reproduce the bugs but added the tests.  Thanks!

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11841>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:44:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 11:44:28 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1317901468.42.0.106403165457.issue12167@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:45:57 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 06 Oct 2011 11:45:57 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317901557.39.0.918529521475.issue13070@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Your application does not segfault with 2.7 because buffered files and sockets use a very different implementation.
The io module is present in all versions, but only Python3 uses it for all file-like objects.
If the unit test (test_rwpair_cleared_before_textio) crashes 2.7, the fix should be applied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Thu Oct  6 13:55:00 2011
From: report at bugs.python.org (telmich)
Date: Thu, 06 Oct 2011 11:55:00 +0000
Subject: [issue13113] Wrong error message on class instance,
	when giving too little positional arguments
Message-ID: <1317902100.22.0.844321043638.issue13113@psf.upfronthosting.co.za>


New submission from telmich <nico-bugs.python.org at schottelius.org>:

I've this class:


class Path:
    """Class that handles path related configurations"""

    def __init__(self,
                target_host,
                remote_user,
                remote_prefix,
                initial_manifest=False,
                base_dir=None,
                debug=False):

That is falsely instantiated from a different class with these arguments:

        self.path = cdist.path.Path(self.target_host, 
                        initial_manifest=initial_manifest,
                        base_dir=home,
                        debug=debug)

Which results in the following traceback:


[13:40] kr:cdist% ./bin/cdist config -d localhost 
Traceback (most recent call last):
  File "./bin/cdist", line 119, in <module>
    commandline()
  File "./bin/cdist", line 102, in commandline
    args.func(args)
  File "/home/users/nico/oeffentlich/rechner/projekte/cdist/lib/cdist/config.py", line 296, in config
    c = Config(host, initial_manifest=args.manifest, home=args.cdist_home, debug=args.debug)
  File "/home/users/nico/oeffentlich/rechner/projekte/cdist/lib/cdist/config.py", line 52, in __init__
    debug=debug)
TypeError: __init__() takes at least 4 arguments (5 given)


Problem:

- there are 5 arguments, so an error message indicating there are at least 4 needed is not helpful

Proposal (pseudocode):

Change to "Only %d of %d required positional arguments given" required_positional, giving_positional

----------
components: Interpreter Core
messages: 145002
nosy: telmich
priority: normal
severity: normal
status: open
title: Wrong error message on class instance, when giving too little positional arguments
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13113>
_______________________________________

From report at bugs.python.org  Thu Oct  6 14:44:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 12:44:44 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1317905084.47.0.61944677483.issue12943@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I made a few last remarks on Rietveld; feel free to address or ignore them and commit right away.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12943>
_______________________________________

From report at bugs.python.org  Thu Oct  6 14:48:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 12:48:21 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1317905301.33.0.834326623825.issue7833@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can the patch include regression tests?

----------
components: +Distutils2
nosy: +alexis, eric.araujo
title: Bdist_wininst installers fail to load extensions built with Issue4120 patch -> bdist_wininst installers fail to load extensions built with Issue4120 patch
versions: +3rd party, Python 3.2 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Thu Oct  6 15:06:03 2011
From: report at bugs.python.org (xy zzy)
Date: Thu, 06 Oct 2011 13:06:03 +0000
Subject: [issue13109] telnetlib insensitive to connection loss
In-Reply-To: <1317848889.2.0.2461830982.issue13109@psf.upfronthosting.co.za>
Message-ID: <1317906363.83.0.512535489156.issue13109@psf.upfronthosting.co.za>


xy zzy <the.stuffduff at gmail.com> added the comment:

Cfrom class():

        # see if we can connect to pcPart
        try:
            self.pcPart = telnetlib.Telnet(IP, PORT)
            # clear the buffer 
            for i in range(10):
                self.pcPart.write('\n')
                r = self.pcPart.read_until('Prompt>', 1)

        except socket.error, e:
            logging.debug('socket.error: %d: %s' % (e.args[0], e.args[1]))
            self.pcPart.close()
            self.pcPart = None

from init():

    def talk(self,cmd,ret):

        """talk to the device"""

        read_chars = ""

        while (read_chars == ""):
            try:
                read_chars=""
                # get to the Prompt> prompt
                # logging.debug('seeking prompt')
                while (read_chars != 'Prompt>'):
                    self.pcPart.write("\n")
                    raw_data = self.pcPart.read_until('Prompt>', 1).split('\n')
                    # logging.debug('raw_data: %i %s' % (len(raw_data), raw_data))
                    read_chars = raw_data[2] 
                    # logging.debug('read_chars: %s' % (read_chars))
                    
                # send the command
                # logging.debug('found prompt')
                cmdx = (('xyzzy:%s\n') % cmd)
                self.pcPart.write(cmdx)
                # logging.debug('command %s, %s' % (cmd, cmdx))
                if (ret):
                    while ((len(raw_data) > 0) and ('{' not in read_chars)):
                        raw_data = self.pcPart.read_until('Prompt>', 1) 
                        # logging.debug('raw_data: %i %s' % (len(raw_data), raw_data))
                        try: 
                            read_chars = str(raw_data.split('\n\r')[1][1:-1])
                        except:
                            read_chars = ''
                            # logging.debug('read_chars: %s' % (read_chars))
                else:
                    raw_data = self.pcPart.read_until('Prompt>', 1)
                    # logging.debug('ret read: %s' % (raw_data))
                    read_chars = '@'
                    return read_chars

            except IndexError, e:
                logging.debug('IndexError: %d: %s' % (e.args[0], e.args[1]))
                traceback.print_exc(file=open(LOG_FILENAME, 'a'))
                read_chars = '@'
                time.sleep(1)

            except (IOError, socket.error), e:
                logging.debug('socket.error: %d: %s' % (e.args[0], e.args[1]))
                traceback.print_exc(file=open(LOG_FILENAME, 'a'))
                self.pcPart.close()
                self.pcPart = None
                logging.debug('reconnecting...')
                self.pcPart = telnetlib.Telnet(IP, PORT) 
                # clear the buffer 
                for i in range(10):
                    self.pcPart.write('\n')
                    r = self.pcPart.read_until('Prompt>', 1)
                read_chars = '@'
                logging.debug('reconnected')

        # clear the buffer 
        for i in range(2):
            self.pcPart.write('\n')
            r = self.pcPart.read_until('Prompt>', 1)
        # logging.debug('Data Read: ' + read_chars)
        return read_chars  

called from:

                DATA = self.talk('cmd', True)
                logging.debug('talk: %s' % (DATA))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13109>
_______________________________________

From report at bugs.python.org  Thu Oct  6 15:22:07 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 06 Oct 2011 13:22:07 +0000
Subject: [issue13113] Wrong error message on class instance,
	when giving too little positional arguments
In-Reply-To: <1317902100.22.0.844321043638.issue13113@psf.upfronthosting.co.za>
Message-ID: <1317907327.65.0.0350958487229.issue13113@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in 3.3

Traceback (most recent call last):
  File "x.py", line 16, in <module>
    debug=0)
TypeError: __init__() missing 2 required positional arguments: 'remote_user' and 'remote_prefix'

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13113>
_______________________________________

From report at bugs.python.org  Thu Oct  6 15:22:42 2011
From: report at bugs.python.org (=?utf-8?b?0JrQuNGA0LjQu9C7INCa0YPQt9GM0LzQuNC90YvRhQ==?=)
Date: Thu, 06 Oct 2011 13:22:42 +0000
Subject: [issue13114] UnicodeDecodeError in command `register` due to using
	not ASCII chars in long_description
Message-ID: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>


New submission from ?????? ????????? <saikuz at mail.ru>:

Command `register` (and `check -r` too) raises the exception UnicodeDecodeError if the long_description (stored as unicode) contains not ASCII chars.
This is because the Docutils, called from Distutils, accepts only ASCII or Unicode. But Distutils passes to Docutils text as a `str` (ASCII or UTF-8).

PS: sorry for my English

----------
assignee: tarek
components: Distutils
files: trace.log
messages: 145007
nosy: Cykooz, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: UnicodeDecodeError in command `register` due to using not ASCII chars in long_description
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file23327/trace.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Thu Oct  6 15:24:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 13:24:33 +0000
Subject: [issue13114] UnicodeDecodeError in command `register` due to using
	not ASCII chars in long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <1317907473.26.0.189005836353.issue13114@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the report.  Can you give us a short setup.py that reproduces the bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Thu Oct  6 15:31:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 13:31:23 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <E1RBo2k-0004nP-Cj@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset db3e15017172 by Antoine Pitrou in branch 'default':
Issue #3163: The struct module gets new format characters 'n' and 'N'
http://hg.python.org/cpython/rev/db3e15017172

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Thu Oct  6 15:31:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Oct 2011 13:31:55 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1317907915.8.0.021759576072.issue3163@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the reviews!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Thu Oct  6 15:33:16 2011
From: report at bugs.python.org (=?utf-8?b?0JrQuNGA0LjQu9C7INCa0YPQt9GM0LzQuNC90YvRhQ==?=)
Date: Thu, 06 Oct 2011 13:33:16 +0000
Subject: [issue13114] UnicodeDecodeError in command `register` due to using
	not ASCII chars in long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <1317907996.86.0.534698826845.issue13114@psf.upfronthosting.co.za>


?????? ????????? <saikuz at mail.ru> added the comment:

> Can you give us a short setup.py that reproduces the bug?

Ok.

Command that reproduces the bug:
python setup.py check -r

PS: 
I use:
Ubuntu 11.04
Python 2.7.1
Docutils 0.8.1

----------
Added file: http://bugs.python.org/file23328/setup.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Thu Oct  6 15:40:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 13:40:31 +0000
Subject: [issue13114] check -r fails with non-ASCII unicode long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <1317908431.04.0.885898253817.issue13114@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Your file uses setuptools, which is not part of Python, but I can reproduce the same bug with distutils.

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis
stage:  -> needs patch
title: UnicodeDecodeError in command `register` due to using not ASCII chars in long_description -> check -r fails with non-ASCII unicode long_description
type: crash -> behavior
versions: +3rd party, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Thu Oct  6 16:10:26 2011
From: report at bugs.python.org (Andrew Wilkins)
Date: Thu, 06 Oct 2011 14:10:26 +0000
Subject: [issue13115] tp_as_{number, sequence,
	mapping} can't be set using PyType_FromSpec
Message-ID: <1317910226.56.0.365091018544.issue13115@psf.upfronthosting.co.za>


New submission from Andrew Wilkins <axwalk at gmail.com>:

I've written an extension using Py_LIMITED_API, and I've created a type using PyType_FromSpec with the slot "Py_sq_length" defined. The slot is not being picked up, i.e. len(MyType()) fails. I can see that tp_as_sequence has not been set, which explains why. All is well if I set it manually (without Py_LIMITED_API defined), like so:
  MyType->tp_as_sequence = &((PyHeapTypeObject*)MyType)->as_sequence;

As far as I can see (docs are lacking), there's no way of setting tp_as_number, tp_as_sequence or tp_as_mapping in types created with PyType_FromSpec. I would expect the presence of any Py_sq_* slots to set tp_as_sequence (likewise for number and mapping).

----------
components: Interpreter Core
messages: 145013
nosy: awilkins
priority: normal
severity: normal
status: open
title: tp_as_{number,sequence,mapping} can't be set using PyType_FromSpec
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13115>
_______________________________________

From report at bugs.python.org  Thu Oct  6 16:24:54 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 06 Oct 2011 14:24:54 +0000
Subject: [issue13105] Please elaborate on how 2.x and 3.x are different heads
In-Reply-To: <1317770656.72.0.880626385137.issue13105@psf.upfronthosting.co.za>
Message-ID: <1317911094.61.0.837987804948.issue13105@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This was from memory, so don't take it as gospel as far as the current security-fix-only branches go, but here's what I sent to Larry:

-----------------
We maintain two independent heads in hg: 2.7 and default

3.2 is open for general bugfixes

2.5 (IIRC), 2.6 and 3.1 are open for security fixes

Security fixes (if applicable to both heads) go:
2.5 -> 2.6 -> 2.7
3.1 -> 3.2 -> default

General bug fixes (if applicable to both heads) go:
2.7
3.2 -> default

New features are added to default only

The relative ordering of 2.x and 3.x changes doesn't really matter -
the important thing is not to merge them in *either* direction. I
think you can theoretically do cherry-picking with Hg, but most people
seem to just do independent commits to the two streams.
-----------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13105>
_______________________________________

From report at bugs.python.org  Thu Oct  6 16:29:10 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 06 Oct 2011 14:29:10 +0000
Subject: [issue13109] telnetlib insensitive to connection loss
In-Reply-To: <1317848889.2.0.2461830982.issue13109@psf.upfronthosting.co.za>
Message-ID: <1317911350.21.0.879184331142.issue13109@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Assuming that you're unplugging the cable when the code is in the loop that occurs after the line "self.pcPart.write(cmdx)", and also assuming that you haven't turned on keepalives, then the behavior you see is expected.

You're just waiting to read some data, and there are no pending writes. Therefore the TCP stack will wait forever if there are no incoming packets. There could be no incoming packets due to no data being ready, of from the network being down. The TCP stack has no way of knowing, so it cannot notify your code.

I suggest turning on TCP keepalives, which would then allow the TCP stack to notify your code that the connection has been closed.

I'm going to close this issue. If you turn on keepalives and still see this problem, please reopen it.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13109>
_______________________________________

From report at bugs.python.org  Thu Oct  6 16:30:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Oct 2011 14:30:23 +0000
Subject: [issue13111] Error 2203 when installing Python/Perl?
In-Reply-To: <1317855327.52.0.585487977144.issue13111@psf.upfronthosting.co.za>
Message-ID: <1317911423.89.0.898785459658.issue13111@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13111>
_______________________________________

From report at bugs.python.org  Thu Oct  6 16:31:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Oct 2011 14:31:02 +0000
Subject: [issue13115] tp_as_{number, sequence,
	mapping} can't be set using PyType_FromSpec
In-Reply-To: <1317910226.56.0.365091018544.issue13115@psf.upfronthosting.co.za>
Message-ID: <1317911462.7.0.21006255411.issue13115@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc, loewis
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13115>
_______________________________________

From report at bugs.python.org  Thu Oct  6 16:35:26 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 06 Oct 2011 14:35:26 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1317898894.75.0.362794527014.issue6715@psf.upfronthosting.co.za>
Message-ID: <4E8DBCAD.9080404@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 06.10.11 13:01, schrieb Nadeem Vawda:
>
> Nadeem Vawda<nadeem.vawda at gmail.com>  added the comment:
>
> Wow, this discussion has gotten quite busy while I've been travelling...
>
> Martin, could you explain what the problems are with bundling a precompiled DLL
> for Windows?

Off-hand, it's only minor issues: e.g. when running Python out of its 
build directory, the DLL must be in the same directory. Now, since
the output directory differs depending on build option, getting the
DLL there might be tricky.

Things I wonder about and couldn't quickly answer from the web:
where exactly is the DLL that we would use?
is there a AMD64 version of it?
Does it come with import libraries usable by VS?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct  6 16:57:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 14:57:09 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1317913029.07.0.449401698063.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

higery, can you give us a status update?  Do you have the time to address current reviews or would you like me to make an updated patch?  I?d like to incorporate this command as soon as possible to let people play with it, and then we?ll see about integration with the install action.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Oct  6 16:57:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 14:57:28 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1317913048.01.0.0532728453592.issue12344@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Thu Oct  6 17:03:04 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 06 Oct 2011 15:03:04 +0000
Subject: [issue13073] message_body argument of HTTPConnection.endheaders is
	undocumented
In-Reply-To: <1317901092.1.0.246854308757.issue13073@psf.upfronthosting.co.za>
Message-ID: <20111006150255.GE1946@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Yes, I agree. I think, it can be clarified at that point too. Because.
in 2.7 the string is being checked and in 3.3 the message_body is
checked if it's instance of bytes.  But, I think, it should be
carefully worded (aligned with how other socket message args are
mentioned).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13073>
_______________________________________

From report at bugs.python.org  Thu Oct  6 17:26:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 15:26:51 +0000
Subject: [issue12416] packaging needs {pre,post}-{install,remove} hooks
In-Reply-To: <1309132247.11.0.698244418605.issue12416@psf.upfronthosting.co.za>
Message-ID: <1317914811.64.0.235212615734.issue12416@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Editing title to reflect the scope of the needed feature.

----------
title: packaging does not have hooks callable during distribution removal -> packaging needs {pre,post}-{install,remove} hooks
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12416>
_______________________________________

From report at bugs.python.org  Thu Oct  6 17:30:10 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 06 Oct 2011 15:30:10 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317915010.32.0.959786735075.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

On http://tukaani.org/xz, I downloaded the file named xz-5.0.3-windows.zip.
It contains precompiled dlls for both platforms: bin_i486/liblzma.dll and bin_x86_64/liblzma.dll
Unfortunately, there is no import library for VS. It should not be too difficult to make one, though: the provided headers are C89, so it's enough to write stubs for the functions used by the extension module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct  6 17:42:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 Oct 2011 15:42:42 +0000
Subject: [issue13116] setup.cfg in [sb]dists should be static
Message-ID: <1317915762.54.0.969795427533.issue13116@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Some people (hi Ronny :) want to use a setup hook to get the version from the VCS, but the setup.cfg file in sdists and bdists should be fully static, because getting the VCS info is not possible and maybe for other reasons too (not requiring development dependencies for example, the same argument that makes people include generated HTML docs in sdists).

The way to handle that seems simple: sdist runs setup hooks and writes back the modified config object to the setup.cfg file that?s included in sdists and bdists.  Command hooks are unaffected, as are post/pre install/remove hooks (to be added in #12416).

Another idea would be to split global hooks into two kinds.  The code would run the volatile hooks, write the modified config as setup.cfg for *dists, and then run regular hooks.  Users installing a *dist will execute the regular hooks.

----------
assignee: tarek
components: Distutils2
messages: 145021
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: setup.cfg in [sb]dists should be static
versions: 3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13116>
_______________________________________

From report at bugs.python.org  Thu Oct  6 17:43:14 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 06 Oct 2011 15:43:14 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317915794.42.0.865005174221.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Hmm... according to http://git.tukaani.org/?p=xz.git;a=blob;f=windows/README-Windows.txt;hb=HEAD#l80,
the MinGW-compiled static libs *can* be used with MSVC. Not sure how
reliable the information is, but it's worth a try at least.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct  6 17:51:50 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 06 Oct 2011 15:51:50 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317916310.56.0.389169148931.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Ah indeed, the zip archive contains a doc/liblzma.def which can be used to build a liblzma.lib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct  6 17:56:27 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 06 Oct 2011 15:56:27 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1317916587.86.0.26294371016.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Hey, today I learnt something about mingw!
"""Rename liblzma.a to e.g. liblzma_static.lib and tell MSVC to link against it."""
Apparently mingw can generate COFF libraries. This may simplify things *a lot*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct  6 19:07:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 17:07:41 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <E1RBrQ4-0002MC-4P@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 89b9e4bf6f1f by Charles-Fran?ois Natali in branch '2.7':
Issue #13070: Fix a crash when a TextIOWrapper caught in a reference cycle
http://hg.python.org/cpython/rev/89b9e4bf6f1f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13070>
_______________________________________

From report at bugs.python.org  Thu Oct  6 19:13:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 17:13:46 +0000
Subject: [issue12911] Expose a private accumulator C API
In-Reply-To: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za>
Message-ID: <E1RBrVx-0002vp-1t@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f9f782f2369e by Antoine Pitrou in branch '3.2':
Issue #12911: Fix memory consumption when calculating the repr() of huge tuples or lists.
http://hg.python.org/cpython/rev/f9f782f2369e

New changeset 656c13024ede by Antoine Pitrou in branch 'default':
Issue #12911: Fix memory consumption when calculating the repr() of huge tuples or lists.
http://hg.python.org/cpython/rev/656c13024ede

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12911>
_______________________________________

From report at bugs.python.org  Thu Oct  6 19:15:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Oct 2011 17:15:58 +0000
Subject: [issue12911] Expose a private accumulator C API
In-Reply-To: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za>
Message-ID: <1317921358.75.0.646419511346.issue12911@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I added a comment insisting that the API is private and can be changed at any moment.
StringIO can actually re-use that API, rather than the reverse. No need to instantiate a full-blown file object when all you want to do is to join a bunch of strings.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12911>
_______________________________________

From report at bugs.python.org  Thu Oct  6 19:45:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 17:45:32 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <E1RBs0h-0005wh-Hx@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e767318baccd by Charles-Fran?ois Natali in branch 'default':
Issue #10141: socket: add SocketCAN (PF_CAN) support. Initial patch by Matthias
http://hg.python.org/cpython/rev/e767318baccd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Thu Oct  6 20:28:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 18:28:02 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <E1RBsfp-0001BK-Iu@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a4af684bb54e by Victor Stinner in branch 'default':
Issue #10141: Don't use hardcoded frame size in example, use struct.calcsize()
http://hg.python.org/cpython/rev/a4af684bb54e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Thu Oct  6 20:32:39 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Thu, 06 Oct 2011 18:32:39 +0000
Subject: =?utf-8?q?=5Bissue13117=5D_Broken_links_in_the_=E2=80=9Ccompiler=E2=80=9D?=
	=?utf-8?q?_page=2C_section_=E2=80=9Creferences=E2=80=9D_from_the_devguide?=
	=?utf-8?q?=2E?=
Message-ID: <1317925959.0.0.308627128494.issue13117@psf.upfronthosting.co.za>


New submission from Francisco Mart?n Brugu? <francismb at email.de>:

Hi,
In the page http://docs.python.org/devguide/compiler.html the links in the references [1] (http://www.foretec.com/python/workshops/1998-11/proceedings/papers/montanaro/montanaro.html) and in [Wang97] (http://www.cs.princeton.edu/%7Edanwang/Papers/dsl97/dsl97.html) are broken.

Cheers,

francis

----------
components: Devguide
messages: 145030
nosy: francismb
priority: normal
severity: normal
status: open
title: Broken links in the ?compiler? page, section ?references? from the devguide.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13117>
_______________________________________

From report at bugs.python.org  Thu Oct  6 20:35:25 2011
From: report at bugs.python.org (=?utf-8?q?F=C3=A9lix-Antoine_Fortin?=)
Date: Thu, 06 Oct 2011 18:35:25 +0000
Subject: [issue13118] Py_BuildValue format f incorrect description.
Message-ID: <1317926125.15.0.437576148609.issue13118@psf.upfronthosting.co.za>


New submission from F?lix-Antoine Fortin <felixantoinefortin+python at gmail.com>:

Python/C API Reference Manual, section Utilities, Parsing arguments and building values, function Py_BuildValue.

The description for the format unit "f" is incorrect. It reads "Same as d.", as it should be "Convert a C float to a Python floating point number." since "f" is not the same as "d" when converting double to Python float. 

This was corrected in the documentation of Python 3, from which the proposed description comes.

----------
assignee: docs at python
components: Documentation
messages: 145031
nosy: docs at python, felixantoinefortin
priority: normal
severity: normal
status: open
title: Py_BuildValue format f incorrect description.
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13118>
_______________________________________

From report at bugs.python.org  Thu Oct  6 21:47:48 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 06 Oct 2011 19:47:48 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1317930468.15.0.516932374375.issue10141@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Committed.
Matthias, Tiago, thanks!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Thu Oct  6 21:52:53 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Thu, 06 Oct 2011 19:52:53 +0000
Subject: =?utf-8?q?=5Bissue13117=5D_Broken_links_in_the_=E2=80=9Ccompiler=E2=80=9D?=
	=?utf-8?q?_page=2C_section_=E2=80=9Creferences=E2=80=9D_from_the_devguide?=
	=?utf-8?q?=2E?=
In-Reply-To: <1317925959.0.0.308627128494.issue13117@psf.upfronthosting.co.za>
Message-ID: <1317930773.52.0.892810841415.issue13117@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

The reference for [1] could be changed to: http://www.python.org/workshops/1998-11/proceedings/papers/montanaro/montanaro.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13117>
_______________________________________

From report at bugs.python.org  Thu Oct  6 22:03:09 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Thu, 06 Oct 2011 20:03:09 +0000
Subject: =?utf-8?q?=5Bissue13117=5D_Broken_links_in_the_=E2=80=9Ccompiler=E2=80=9D?=
	=?utf-8?q?_page=2C_section_=E2=80=9Creferences=E2=80=9D_from_the_devguide?=
	=?utf-8?q?=2E?=
In-Reply-To: <1317925959.0.0.308627128494.issue13117@psf.upfronthosting.co.za>
Message-ID: <1317931389.7.0.835683026722.issue13117@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

The reference to [Wang97] could be changed to: http://www.cs.princeton.edu/research/techreps/TR-554-97

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13117>
_______________________________________

From report at bugs.python.org  Thu Oct  6 22:09:22 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Thu, 06 Oct 2011 20:09:22 +0000
Subject: =?utf-8?q?=5Bissue13117=5D_Broken_links_in_the_=E2=80=9Ccompiler=E2=80=9D?=
	=?utf-8?q?_page=2C_section_=E2=80=9Creferences=E2=80=9D_from_the_devguide?=
	=?utf-8?q?=2E?=
In-Reply-To: <1317925959.0.0.308627128494.issue13117@psf.upfronthosting.co.za>
Message-ID: <1317931762.24.0.382551069393.issue13117@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

A patch with the links mentioned above.

----------
keywords: +patch
Added file: http://bugs.python.org/file23329/issue13117.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13117>
_______________________________________

From report at bugs.python.org  Thu Oct  6 22:20:40 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 06 Oct 2011 20:20:40 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1317932440.44.0.44932267518.issue8037@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Modifying an object which is already on a traditional queue can also
> change what is received by the other thread (depending on timing). 
> So Queue.Queue's put() is not "atomic" either.  Therefore I do not
> believe this behaviour is a bug.

Agreed.

> However the solution proposed is a good one since it fixes Issue
> 10886.  In addition it prevents arbitrary code being run in the
> background thread by weakref callbacks or __del__ methods.  Such
> arbitrary code may cause inconsistent state in a forked process if
> the fork happens while the queue's thread is running -- see issue
> 6271.
[...]
> I would suggest closing this issue and letting Issue 10886 take it's
> place.

Makes sense.

----------
nosy: +neologix
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> Unhelpful backtrace for multiprocessing.Queue

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Thu Oct  6 22:33:53 2011
From: report at bugs.python.org (Aleksey Frolov)
Date: Thu, 06 Oct 2011 20:33:53 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1317933233.18.0.458946283419.issue3244@psf.upfronthosting.co.za>


Changes by Aleksey Frolov <atommixz at gmail.com>:


----------
nosy: +atommixz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Thu Oct  6 22:35:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 20:35:44 +0000
Subject: =?utf-8?q?=5Bissue13117=5D_Broken_links_in_the_=E2=80=9Ccompiler=E2=80=9D?=
	=?utf-8?q?_page=2C_section_=E2=80=9Creferences=E2=80=9D_from_the_devguide?=
	=?utf-8?q?=2E?=
In-Reply-To: <1317925959.0.0.308627128494.issue13117@psf.upfronthosting.co.za>
Message-ID: <E1RBufP-0005XW-CJ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 76159c6d265a by Ned Deily in branch 'default':
Issue #13117: Fix broken links in the compiler page of the Developer's Guide.
http://hg.python.org/devguide/rev/76159c6d265a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13117>
_______________________________________

From report at bugs.python.org  Thu Oct  6 22:39:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 06 Oct 2011 20:39:03 +0000
Subject: =?utf-8?q?=5Bissue13117=5D_Broken_links_in_the_=E2=80=9Ccompiler=E2=80=9D?=
	=?utf-8?q?_page=2C_section_=E2=80=9Creferences=E2=80=9D_from_the_devguide?=
	=?utf-8?q?=2E?=
In-Reply-To: <1317925959.0.0.308627128494.issue13117@psf.upfronthosting.co.za>
Message-ID: <1317933543.15.0.963849719555.issue13117@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the patch!

----------
nosy: +ned.deily
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13117>
_______________________________________

From report at bugs.python.org  Thu Oct  6 22:59:48 2011
From: report at bugs.python.org (M. Zilmer)
Date: Thu, 06 Oct 2011 20:59:48 +0000
Subject: [issue13119] Newline for print() is \n on Windows,
	and not \r\n as expected
Message-ID: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za>


New submission from M. Zilmer <mzdkmail at gmail.com>:

In 3.2.2 the newline for print() is \n on Windows, and not \r\n as expected.

In 3.1.4 the newline is \r\n.

OS is Win 7, and tried on both 32 and 64 bit.

Small example with output is attached.

----------
components: Windows
files: newline.py
messages: 145039
nosy: M..Z.
priority: normal
severity: normal
status: open
title: Newline for print() is \n on Windows, and not \r\n as expected
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file23330/newline.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13119>
_______________________________________

From report at bugs.python.org  Thu Oct  6 23:00:22 2011
From: report at bugs.python.org (M. Zilmer)
Date: Thu, 06 Oct 2011 21:00:22 +0000
Subject: [issue13119] Newline for print() is \n on Windows,
	and not \r\n as expected
In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za>
Message-ID: <1317934822.25.0.0556960967364.issue13119@psf.upfronthosting.co.za>


Changes by M. Zilmer <mzdkmail at gmail.com>:


Added file: http://bugs.python.org/file23331/newline_3.1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13119>
_______________________________________

From report at bugs.python.org  Thu Oct  6 23:00:38 2011
From: report at bugs.python.org (M. Zilmer)
Date: Thu, 06 Oct 2011 21:00:38 +0000
Subject: [issue13119] Newline for print() is \n on Windows,
	and not \r\n as expected
In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za>
Message-ID: <1317934838.62.0.823953502761.issue13119@psf.upfronthosting.co.za>


Changes by M. Zilmer <mzdkmail at gmail.com>:


Added file: http://bugs.python.org/file23332/newline_3.2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13119>
_______________________________________

From report at bugs.python.org  Thu Oct  6 23:17:28 2011
From: report at bugs.python.org (Ben Bass)
Date: Thu, 06 Oct 2011 21:17:28 +0000
Subject: [issue13120] Default nosigint optionto pdb.Pdb() prevents use in
	non-main thread
Message-ID: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za>


New submission from Ben Bass <benbass at codedstructure.net>:

The new SIGINT behaviour of pdb.Pdb prevents use of pdb within a non-main thread without explicitly setting nosigint=True. Specifically the 'continue' command causes a traceback as follows:

{{{
...
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/pdb.py", line 959, in do_continue
    signal.signal(signal.SIGINT, self.sigint_handler)
ValueError: signal only works in main thread
}}}

Since the new behaviour seems to be to gain an enhancement rather than anything fundamentally necessary to pdb, wouldn't it be better if the default was reversed, so the same code would work identically on Python 3.1 (and potentially earlier, i.e. Python2) and Python 3.2?

At the moment in my codebase (rpcpdb) I'm using inspect.getargspec sniffing for nosigint on pdb.Pdb.__init__ to determine whether to include a nosigint=True parameter, which clearly isn't ideal!

----------
components: Library (Lib)
messages: 145040
nosy: bpb
priority: normal
severity: normal
status: open
title: Default nosigint optionto pdb.Pdb() prevents use in non-main thread
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13120>
_______________________________________

From report at bugs.python.org  Thu Oct  6 23:19:19 2011
From: report at bugs.python.org (Ben Bass)
Date: Thu, 06 Oct 2011 21:19:19 +0000
Subject: [issue13120] Default nosigint option to pdb.Pdb() prevents use in
	non-main thread
In-Reply-To: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za>
Message-ID: <1317935959.32.0.169959724174.issue13120@psf.upfronthosting.co.za>


Changes by Ben Bass <benbass at codedstructure.net>:


----------
title: Default nosigint optionto pdb.Pdb() prevents use in non-main thread -> Default nosigint option to pdb.Pdb() prevents use in non-main thread

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13120>
_______________________________________

From report at bugs.python.org  Thu Oct  6 23:43:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 21:43:09 +0000
Subject: [issue7367] pkgutil.walk_packages fails on write-only directory in
	sys.path
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <E1RBvid-0002s6-3v@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 096b010ae90b by Ned Deily in branch '2.7':
Issue #7367: Add test case to test_pkgutil for walking path with
http://hg.python.org/cpython/rev/096b010ae90b

New changeset 1449095397ae by Ned Deily in branch '2.7':
Issue #7367: Fix pkgutil.walk_paths to skip directories whose
http://hg.python.org/cpython/rev/1449095397ae

New changeset a1e6633ef3f1 by Ned Deily in branch '3.2':
Issue #7367: Add test case to test_pkgutil for walking path with
http://hg.python.org/cpython/rev/a1e6633ef3f1

New changeset 77bac85f610a by Ned Deily in branch '3.2':
Issue #7367: Fix pkgutil.walk_paths to skip directories whose
http://hg.python.org/cpython/rev/77bac85f610a

New changeset 5a4018570a59 by Ned Deily in branch '3.2':
Issue #7367: add NEWS item.
http://hg.python.org/cpython/rev/5a4018570a59

New changeset 0408001e4765 by Ned Deily in branch 'default':
Issue #7367: merge from 3.2
http://hg.python.org/cpython/rev/0408001e4765

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________

From report at bugs.python.org  Thu Oct  6 23:43:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Oct 2011 21:43:09 +0000
Subject: [issue7425] Improve the robustness of "pydoc -k" in the face of
	broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <E1RBvid-0002s6-3o@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 45862f4ab1c5 by Ned Deily in branch '2.7':
Issue #7425: Refactor test_pydoc test case for '-k' behavior and add
http://hg.python.org/cpython/rev/45862f4ab1c5

New changeset 3acf90f71178 by Ned Deily in branch '2.7':
Issue #7425: Prevent pydoc -k failures due to module import errors.
http://hg.python.org/cpython/rev/3acf90f71178

New changeset 6a45f917f167 by Ned Deily in branch '3.2':
Issue #7425: Refactor test_pydoc test case for '-k' behavior and add
http://hg.python.org/cpython/rev/6a45f917f167

New changeset add444274c3d by Ned Deily in branch '2.7':
Issue #7425 and Issue #7367: add NEWS items.
http://hg.python.org/cpython/rev/add444274c3d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7425>
_______________________________________

From report at bugs.python.org  Fri Oct  7 00:00:32 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 06 Oct 2011 22:00:32 +0000
Subject: [issue7367] pkgutil.walk_packages fails on write-only directory in
	sys.path
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1317938432.61.0.579793043397.issue7367@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The applied changesets correct pkgutil's walk_packages for "classic" imports to ignore unreadable directories the same way that the interpreter's import does.  With this fix to pkgutil, pydoc -k also no longer fails in this case.  Applied in 2.7 (for 2.7.3), 3.2 (for 3.2.3), and default (for 3.3.0).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________

From report at bugs.python.org  Fri Oct  7 00:10:42 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 06 Oct 2011 22:10:42 +0000
Subject: [issue7425] Improve the robustness of "pydoc -k" in the face of
	broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <1317939042.25.0.67148792288.issue7425@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The applied changesets backport the "ignore exceptions" fix for pydoc -k from 3.x to 2.7 and also refactor test_pydoc to remove unneeded complexity and add test cases for importing bad packages and unreadable package directories (a problem addressed in Issue7367).  Applied to 2.7 (for 2.7.3), 3.2 (for 3.2.3), and default (for 3.3.0).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7425>
_______________________________________

From report at bugs.python.org  Fri Oct  7 00:11:02 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 06 Oct 2011 22:11:02 +0000
Subject: [issue7425] Improve the robustness of "pydoc -k" in the face of
	broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <1317939062.39.0.887518790824.issue7425@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7425>
_______________________________________

From report at bugs.python.org  Fri Oct  7 00:13:34 2011
From: report at bugs.python.org (Carl Robben)
Date: Thu, 06 Oct 2011 22:13:34 +0000
Subject: [issue2945] bdist_rpm does not list dist files (should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <1317939214.47.0.339777520205.issue2945@psf.upfronthosting.co.za>


Carl Robben <carl.robben at gmail.com> added the comment:

I found that bdist_rpm wasn't registering distributions with dist.dist_files at all.  The attached patch should be all that's needed to fix this.

----------
keywords: +patch
nosy: +crobben
Added file: http://bugs.python.org/file23333/bdist_rpm.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2945>
_______________________________________

From report at bugs.python.org  Fri Oct  7 00:28:07 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 06 Oct 2011 22:28:07 +0000
Subject: [issue11250] 2to3 truncates files at formfeed character
In-Reply-To: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>
Message-ID: <1317940087.32.0.485614173343.issue11250@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Was this patch ever folded into Python 3.2?  Looking at the hg repository, I think the answer is "no".  It does appear to have made it into Python 2.7 and trunk though (afaict).

In point of fact, this bug is hitting me now with 3.2.2.

----------
nosy: +barry
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11250>
_______________________________________

From report at bugs.python.org  Fri Oct  7 00:46:56 2011
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 06 Oct 2011 22:46:56 +0000
Subject: [issue13105] Please elaborate on how 2.x and 3.x are different heads
In-Reply-To: <1317770656.72.0.880626385137.issue13105@psf.upfronthosting.co.za>
Message-ID: <1317941216.64.0.449797500696.issue13105@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

What follows is the original email from Nick.

--

We maintain two independent heads in hg: 2.7 and default

3.2 is open for general bugfixes

2.5 (IIRC), 2.6 and 3.1 are open for security fixes

Security fixes (if applicable to both heads) go:
2.5 -> 2.6 -> 2.7
3.1 -> 3.2 -> default

General bug fixes (if applicable to both heads) go:
2.7
3.2 -> default

New features are added to default only

The relative ordering of 2.x and 3.x changes doesn't really matter -
the important thing is not to merge them in *either* direction. I
think you can theoretically do cherry-picking with Hg, but most people
seem to just do independent commits to the two streams.

If the devguide doesn't align with the above, then a tracker issue
pointing that out would be handy :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13105>
_______________________________________

From report at bugs.python.org  Fri Oct  7 00:50:38 2011
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 06 Oct 2011 22:50:38 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1317941438.63.0.617713356867.issue7833@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

I'm reluctant to commit to adding test infrastructure for the distutils build commands - if I've missed existing infrastructure and adding such tests would actually be relatively simple, please educate me!  Or if someone else would like to help with the infrastructure so I can test just this patch, that would be awesome.  But I don't think this fix should block on tests given it can easily be tested and verified manually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Fri Oct  7 00:59:50 2011
From: report at bugs.python.org (Mike Hoy)
Date: Thu, 06 Oct 2011 22:59:50 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1317941990.78.0.378605947804.issue12436@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

> - How to prepare a text editor
See: http://docs.python.org/dev/using/unix.html#editors

> - How to run Python code from a file (if the tutorial or using docs don?t already have it).

See: http://docs.python.org/dev/using/unix.html#miscellaneous

----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Fri Oct  7 01:05:48 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 06 Oct 2011 23:05:48 +0000
Subject: [issue13119] Newline for print() is \n on Windows,
	and not \r\n as expected
In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za>
Message-ID: <1317942348.25.0.126263062119.issue13119@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

To people who open the file in their browser: text files are very similar, but newline_3.1.txt has CRLF line endings and newline_3.2.txt has LF line endings.

M.Z, how did you obtain them? did you start a subprocess?

----------
nosy: +amaury.forgeotdarc, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13119>
_______________________________________

From report at bugs.python.org  Fri Oct  7 01:12:35 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 06 Oct 2011 23:12:35 +0000
Subject: [issue13118] Py_BuildValue format f incorrect description.
In-Reply-To: <1317926125.15.0.437576148609.issue13118@psf.upfronthosting.co.za>
Message-ID: <1317942755.22.0.884446222941.issue13118@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I've checked in the code: 'f' and 'd' are really the same (Python/modsupport.c).

And in http://en.wikipedia.org/wiki/Stdarg.h, you can read: """A float will automatically be promoted to a double."""

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13118>
_______________________________________

From report at bugs.python.org  Fri Oct  7 01:31:38 2011
From: report at bugs.python.org (Mike Hoy)
Date: Thu, 06 Oct 2011 23:31:38 +0000
Subject: [issue12823] Broken link in "SSL wrapper for socket objects" document
In-Reply-To: <1314086720.91.0.705244554246.issue12823@psf.upfronthosting.co.za>
Message-ID: <1317943898.08.0.537958291243.issue12823@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

Patch to remove broken link.

----------
keywords: +patch
nosy: +mikehoy
Added file: http://bugs.python.org/file23334/SSL-broken-link.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12823>
_______________________________________

From report at bugs.python.org  Fri Oct  7 06:34:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Oct 2011 04:34:10 +0000
Subject: [issue12602] Missing using docs cross-references
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1317962050.09.0.148104173773.issue12602@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is all a puzzle to me. "<script>" ??

Links from docs to tracker issue??

There is at least one other issue about bad links (from builtin functions entries).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Fri Oct  7 06:47:57 2011
From: report at bugs.python.org (M. Zilmer)
Date: Fri, 07 Oct 2011 04:47:57 +0000
Subject: [issue13119] Newline for print() is \n on Windows,
	and not \r\n as expected
In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za>
Message-ID: <1317962877.15.0.856523446021.issue13119@psf.upfronthosting.co.za>


M. Zilmer <mzdkmail at gmail.com> added the comment:

Hi Amaury,

The two text files were obtained through redirection in Windows, so I simply ran the newline.py file with:

    ...> C:\Python31\python.exe newline.py > newline_3.1.txt

    ...> C:\Python32\python.exe newline.py > newline_3.2.txt

Best regards,
Morten Zilmer

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13119>
_______________________________________

From report at bugs.python.org  Fri Oct  7 07:08:44 2011
From: report at bugs.python.org (=?utf-8?b?0JrQuNGA0LjQu9C7INCa0YPQt9GM0LzQuNC90YvRhQ==?=)
Date: Fri, 07 Oct 2011 05:08:44 +0000
Subject: [issue13114] check -r fails with non-ASCII unicode long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <1317964124.12.0.730480750516.issue13114@psf.upfronthosting.co.za>


?????? ????????? <saikuz at mail.ru> added the comment:

I created the patch (in attachment) for Distutils from Python 2.7.

PS:
Python 3.2 does not contain this error, because there the entire text is stored in unicode.

----------
components:  -Distutils2
keywords: +patch
type: behavior -> crash
versions:  -3rd party, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23335/check_rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Fri Oct  7 07:44:07 2011
From: report at bugs.python.org (=?utf-8?b?0JrQuNGA0LjQu9C7INCa0YPQt9GM0LzQuNC90YvRhQ==?=)
Date: Fri, 07 Oct 2011 05:44:07 +0000
Subject: [issue13114] check -r fails with non-ASCII unicode long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <1317966247.27.0.989538380171.issue13114@psf.upfronthosting.co.za>


Changes by ?????? ????????? <saikuz at mail.ru>:


----------
components: +Distutils2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Fri Oct  7 07:51:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 07 Oct 2011 05:51:55 +0000
Subject: [issue12602] Missing using docs cross-references
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1317966715.65.0.928756697675.issue12602@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Fri Oct  7 08:08:33 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 07 Oct 2011 06:08:33 +0000
Subject: [issue11914] pydoc modules/help('modules') crash in dirs with
	unreadable subdirs
In-Reply-To: <1303616093.87.0.65824226669.issue11914@psf.upfronthosting.co.za>
Message-ID: <1317967713.84.0.702051718802.issue11914@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for your suggested code and test. Somewhat different fixes to pkgutil have been added by the changes for Issue7367 and a necessary backport of a fix for pydoc from 3.x to 2.7 was made for Issue7425.  With these fixes in place, pydoc for 3.3.0, 3.2.3, and 2.7.3 should not exhibit these problems anymore.

----------
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> pkgutil.walk_packages fails on write-only directory in sys.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11914>
_______________________________________

From report at bugs.python.org  Fri Oct  7 08:20:32 2011
From: report at bugs.python.org (=?utf-8?b?0JrQuNGA0LjQu9C7INCa0YPQt9GM0LzQuNC90YvRhQ==?=)
Date: Fri, 07 Oct 2011 06:20:32 +0000
Subject: [issue13114] check -r fails with non-ASCII unicode long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <1317968432.22.0.95320912091.issue13114@psf.upfronthosting.co.za>


Changes by ?????? ????????? <saikuz at mail.ru>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Fri Oct  7 08:23:23 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 07 Oct 2011 06:23:23 +0000
Subject: [issue12696] pydoc error page due to lacking permissions on ./*
In-Reply-To: <1312551580.84.0.857436342215.issue12696@psf.upfronthosting.co.za>
Message-ID: <1317968603.69.0.812138186387.issue12696@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This problem has been fixed with the changes for Issue7367 and, for 2.7, Issue7425.  They should appear in 3.3.0, 3.2.3, and 2.7.3.

----------
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> pkgutil.walk_packages fails on write-only directory in sys.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12696>
_______________________________________

From report at bugs.python.org  Fri Oct  7 08:37:31 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 07 Oct 2011 06:37:31 +0000
Subject: [issue13078] Python Crashes When Saving Or Opening
In-Reply-To: <1317404515.12.0.258020695982.issue13078@psf.upfronthosting.co.za>
Message-ID: <1317969451.98.0.947434523546.issue13078@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13078>
_______________________________________

From report at bugs.python.org  Fri Oct  7 08:39:41 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 07 Oct 2011 06:39:41 +0000
Subject: [issue13078] Python Crashes When Saving Or Opening
In-Reply-To: <1317404515.12.0.258020695982.issue13078@psf.upfronthosting.co.za>
Message-ID: <1317969581.01.0.773028820611.issue13078@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

You are attempting to open or save .py files from what? IDLE?

What are the steps you would use to reproduce this issue? How was this error message obtained?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13078>
_______________________________________

From report at bugs.python.org  Fri Oct  7 09:10:21 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 07 Oct 2011 07:10:21 +0000
Subject: [issue7015] Getting call trace while executing "modules spam" at help
	prompt
In-Reply-To: <1254206290.75.0.617783726921.issue7015@psf.upfronthosting.co.za>
Message-ID: <1317971421.74.0.220716649442.issue7015@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The problem of pydoc apropos failing due to exceptions raised by pkgutil walk_packages is fixed in 2.7.3 by the changes for Issue7425; they were already fixed in 3.x.

----------
nosy: +ned.deily
resolution: invalid -> duplicate
superseder:  -> Improve the robustness of "pydoc -k" in the face of broken modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7015>
_______________________________________

From report at bugs.python.org  Fri Oct  7 09:55:06 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Oct 2011 07:55:06 +0000
Subject: [issue1164953] logging.basicConfig creates phantom handler
Message-ID: <1317974106.89.0.808377820093.issue1164953@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Can basicConfig() report its failure with DEBUG level when called twice?

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1164953>
_______________________________________

From report at bugs.python.org  Fri Oct  7 10:12:46 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Oct 2011 08:12:46 +0000
Subject: [issue13112] backreferences in comprehensions
In-Reply-To: <1317857494.55.0.915280284739.issue13112@psf.upfronthosting.co.za>
Message-ID: <1317975166.77.0.516199218561.issue13112@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hi,

You're proposing a change to the core language and syntax;  the bug-tracker's not really appropriate for this---it's better suited for small, focused changes (preferably with patches!).  I suggest that you start a thread on the python-ideas mailing list for wider discussion and consideration of possible alternative solutions to the problem you're trying to solve.  It's likely that a PEP and a working implementation would also be required to push this through.

I'm going to close this for now;  it can be reopened if the python-ideas discussion is positive.

----------
components: +Interpreter Core
nosy: +mark.dickinson
resolution:  -> rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13112>
_______________________________________

From report at bugs.python.org  Fri Oct  7 10:17:52 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Oct 2011 08:17:52 +0000
Subject: [issue13112] backreferences in comprehensions
In-Reply-To: <1317857494.55.0.915280284739.issue13112@psf.upfronthosting.co.za>
Message-ID: <1317975472.05.0.847847905152.issue13112@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I meant to include a link to the mailing list:

http://mail.python.org/mailman/listinfo/python-ideas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13112>
_______________________________________

From report at bugs.python.org  Fri Oct  7 10:50:34 2011
From: report at bugs.python.org (Lars Buitinck)
Date: Fri, 07 Oct 2011 08:50:34 +0000
Subject: [issue13121] collections.Counter's += copies the entire object
Message-ID: <1317977434.46.0.626100406816.issue13121@psf.upfronthosting.co.za>


New submission from Lars Buitinck <L.J.Buitinck at uva.nl>:

I've found some counterintuitive behavior in collections.Counter while hacking on the scikit-learn project [1]. I wanted to use a bunch of Counters to do some simple term counting in a set of documents, roughly as follows:

   count_total = Counter()
   for doc in documents:
       count_current = Counter(analyze(doc))
       count_total += count_current
       count_per_doc.append(count_current)

Performance was horrible. After some digging, I found out that Counter [2] does not have __iadd__ and += copies the entire left-hand side in __add__. I've attached a patch that fixes the issue (for += only, and I've not patched the testsuite.)

[1] https://github.com/scikit-learn/scikit-learn/commit/de6e93094499e4d81b8e3b15fc66b6b9252945af

----------
components: Library (Lib)
files: cpython-counter-iadd.diff
keywords: patch
messages: 145063
nosy: larsmans
priority: normal
severity: normal
status: open
title: collections.Counter's += copies the entire object
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file23336/cpython-counter-iadd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13121>
_______________________________________

From report at bugs.python.org  Fri Oct  7 10:52:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Oct 2011 08:52:33 +0000
Subject: [issue13119] Newline for print() is \n on Windows,
	and not \r\n as expected
In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za>
Message-ID: <1317977553.1.0.752667915145.issue13119@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I changed how newlines are handled on Windows to fix an issue with CGI: see the issue #10841.

changeset:   67431:0933c3753a71
user:        Victor Stinner <victor.stinner at haypocalc.com>
date:        Fri Jan 07 18:47:22 2011 +0000
files:       Misc/NEWS Modules/_io/fileio.c Modules/main.c Parser/tokenizer.c
description:
Issue #10841: set binary mode on files; the parser translates newlines

On Windows, set the binary mode on stdin, stdout, stderr and all
io.FileIO objects (to not translate newlines, \r\n <=> \n). The Python parser
translates newlines (\r\n => \n).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13119>
_______________________________________

From report at bugs.python.org  Fri Oct  7 10:58:13 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 07 Oct 2011 08:58:13 +0000
Subject: [issue13121] collections.Counter's += copies the entire object
In-Reply-To: <1317977434.46.0.626100406816.issue13121@psf.upfronthosting.co.za>
Message-ID: <1317977893.95.0.906253468798.issue13121@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

This is slightly backwards incompatible, as some people may depend on the old behavior. Otherwise sounds like a good idea to me.

----------
nosy: +petri.lehtinen, rhettinger
stage:  -> patch review
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13121>
_______________________________________

From report at bugs.python.org  Fri Oct  7 11:01:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Oct 2011 09:01:18 +0000
Subject: [issue13119] Newline for print() is \n on Windows,
	and not \r\n as expected
In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za>
Message-ID: <1317978078.78.0.686833741549.issue13119@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

print() uses PyFile_WriteString("\n", file) by default (if the end argument is not set) to write the newline. TextIOWrapper.write("\n") replaces "\n" by TextIOWrapper._writenl.

On Windows, stdin, stdout and stderr are creates using TextIOWrapper(..., newline=None). In this case, TextIOWrapper._writenl is os.linesep and so '\r\n'.

To sum up, print() writes '\n' into sys.stdout, but sys.stdout write b'\r\n' into the file descriptor 1 which is a binary file (ie. the underlying OS file doesn't translate newlines).

If the output is redirected (e.g. into a file), TextIOWrapper is created with line_buffering=False.

You may try to force line_buffering=True when the output is redirected.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13119>
_______________________________________

From report at bugs.python.org  Fri Oct  7 11:11:18 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Oct 2011 09:11:18 +0000
Subject: [issue13121] collections.Counter's += copies the entire object
In-Reply-To: <1317977434.46.0.626100406816.issue13121@psf.upfronthosting.co.za>
Message-ID: <1317978678.52.0.123473756539.issue13121@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13121>
_______________________________________

From report at bugs.python.org  Fri Oct  7 11:11:35 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Oct 2011 09:11:35 +0000
Subject: [issue13121] collections.Counter's += copies the entire object
In-Reply-To: <1317977434.46.0.626100406816.issue13121@psf.upfronthosting.co.za>
Message-ID: <1317978695.06.0.845615919918.issue13121@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13121>
_______________________________________

From report at bugs.python.org  Fri Oct  7 11:17:07 2011
From: report at bugs.python.org (Lars Buitinck)
Date: Fri, 07 Oct 2011 09:17:07 +0000
Subject: [issue13121] collections.Counter's += copies the entire object
In-Reply-To: <1317977434.46.0.626100406816.issue13121@psf.upfronthosting.co.za>
Message-ID: <1317979027.6.0.864510462497.issue13121@psf.upfronthosting.co.za>


Lars Buitinck <L.J.Buitinck at uva.nl> added the comment:

If this is not implemented because it is backwards incompat, then it might be useful to add a note to update's docstring explaining that it is much more efficient than +=. I was very surprised that it took *minutes* to add a few thousand moderate-sized Counters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13121>
_______________________________________

From report at bugs.python.org  Fri Oct  7 11:32:45 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 07 Oct 2011 09:32:45 +0000
Subject: [issue13119] Newline for print() is \n on Windows,
	and not \r\n as expected
In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za>
Message-ID: <1317979965.26.0.325627389195.issue13119@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> If the output is redirected (e.g. into a file),
> TextIOWrapper is created with line_buffering=False.
How does this affect the \r\n translation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13119>
_______________________________________

From report at bugs.python.org  Fri Oct  7 12:05:56 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 07 Oct 2011 10:05:56 +0000
Subject: [issue1164953] logging.basicConfig creates phantom handler
Message-ID: <1317981956.7.0.457037890113.issue1164953@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@anatoly: What failure do you mean? The behaviour that logistix described is not a failure, it's by design. See my closing comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1164953>
_______________________________________

From report at bugs.python.org  Fri Oct  7 13:07:29 2011
From: report at bugs.python.org (=?utf-8?b?0JrQuNGA0LjQu9C7INCa0YPQt9GM0LzQuNC90YvRhQ==?=)
Date: Fri, 07 Oct 2011 11:07:29 +0000
Subject: [issue13114] check -r fails with non-ASCII unicode long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <1317985649.26.0.118357474074.issue13114@psf.upfronthosting.co.za>


Changes by ?????? ????????? <saikuz at mail.ru>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Fri Oct  7 13:48:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 07 Oct 2011 11:48:42 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1317988122.52.0.734155159497.issue10141@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

>From python-dev:
"""
I work on Ubuntu Jaunty for my cpython development work - an old version, I
know, but still quite serviceable and has worked well for me over many months.
With the latest default cpython repository, however, I can't run the regression
suite because the socket module now fails to build:

gcc -pthread -fPIC -g -O0 -Wall -Wstrict-prototypes -IInclude -I.
  -I./Include -I/usr/local/include -I/home/vinay/projects/python/default -c
  /home/vinay/projects/python/default/Modules/socketmodule.c
  -o build/temp.linux-i686-3.3-pydebug/home/vinay/projects/python/default
  /Modules/socketmodule.o
.../Modules/socketmodule.c: In function
?makesockaddr?:
.../Modules/socketmodule.c:1224: error: ?AF_CAN? undeclared (first use in
this function)
.../Modules/socketmodule.c:1224: error: (Each undeclared identifier is
reported only once
.../Modules/socketmodule.c:1224: error: for each function it appears in.)
.../Modules/socketmodule.c: In function
?getsockaddrarg?:
.../Modules/socketmodule.c:1610: error: ?AF_CAN? undeclared (first use in
this function)
.../Modules/socketmodule.c: In function ?getsockaddrlen?:
.../Modules/socketmodule.c:1750: error: ?AF_CAN? undeclared (first use in
this function)

On this system, AF_CAN *is* defined, but in linux/socket.h, not in sys/socket.h.
>From what I can see, sys/socket.h includes bits/socket.h which includes
asm/socket.h, but apparently linux/socket.h isn't included.
"""

Vinay, what happens if you replace in Modules/socketmodule.h:
"""
#ifdef HAVE_LINUX_CAN_H
#include <linux/can.h>
#endif
"""

with

"""
#ifdef HAVE_LINUX_CAN_H
#include <linux/socket.h>
#include <linux/can.h>
#endif
"""

----------
nosy: +vinay.sajip
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Fri Oct  7 13:49:29 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Oct 2011 11:49:29 +0000
Subject: [issue13121] collections.Counter's += copies the entire object
In-Reply-To: <1317977434.46.0.626100406816.issue13121@psf.upfronthosting.co.za>
Message-ID: <1317988169.41.0.742473892198.issue13121@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'll add the in-place methods including __iadd__, __isub__, __iand__, and __ior__.

If speed is your issue, you should continue to use the update() method which will always be faster because it doesn't have a step to strip zeros and negative values from the existing Counter.  Also, update() has a fast-path written in C.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13121>
_______________________________________

From report at bugs.python.org  Fri Oct  7 14:41:42 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Oct 2011 12:41:42 +0000
Subject: [issue1164953] logging.basicConfig creates phantom handler
Message-ID: <1317991302.84.0.968515158077.issue1164953@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I know that it is by design, but from all logging users you may be the only one who keeps this behaviour in mind. The message why basicConfig() failed will be more user-friendly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1164953>
_______________________________________

From report at bugs.python.org  Fri Oct  7 14:58:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Oct 2011 12:58:08 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1317992288.51.0.530028379894.issue11085@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, this made unloaded interpreter startup quite a bit slower since importing one of the abcs now imports the whole collection package and its dependencies.
>From 3.2 to 3.3:

### normal_startup ###
Min: 0.842961 -> 1.091329: 1.29x slower
Avg: 0.851607 -> 1.106344: 1.30x slower
Significant (t=-37.61)
Stddev: 0.00623 -> 0.01381: 2.2162x larger
Timeline: http://tinyurl.com/3etyx44

### startup_nosite ###
Min: 0.247490 -> 0.378279: 1.53x slower
Avg: 0.255694 -> 0.382722: 1.50x slower
Significant (t=-39.46)
Stddev: 0.00865 -> 0.00536: 1.6141x smaller
Timeline: http://tinyurl.com/3vovjwb

It probably doesn't make much difference in practice, since collections is one of those modules everyone will use in their code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Fri Oct  7 15:51:56 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 07 Oct 2011 13:51:56 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1317995516.69.0.745379490275.issue12943@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

?ric, thanks.  I fixed most of your points.  And thanks to everyone that reviewed this.  Much appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12943>
_______________________________________

From report at bugs.python.org  Fri Oct  7 15:55:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Oct 2011 13:55:04 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <E1RCAtD-00027B-6k@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 85254bb6c1c6 by Meador Inge in branch 'default':
Issue #12943: python -m tokenize support has been added to tokenize.
http://hg.python.org/cpython/rev/85254bb6c1c6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12943>
_______________________________________

From report at bugs.python.org  Fri Oct  7 15:56:53 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 07 Oct 2011 13:56:53 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1317995813.92.0.146019420886.issue12943@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
assignee: docs at python -> meador.inge
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12943>
_______________________________________

From report at bugs.python.org  Fri Oct  7 16:04:57 2011
From: report at bugs.python.org (Mike Hoy)
Date: Fri, 07 Oct 2011 14:04:57 +0000
Subject: [issue12602] Missing using docs cross-references
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1317996297.62.0.175926354761.issue12602@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Fri Oct  7 16:06:15 2011
From: report at bugs.python.org (Mike Hoy)
Date: Fri, 07 Oct 2011 14:06:15 +0000
Subject: [issue12192] Doc that collection mutation methods return item or None
In-Reply-To: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>
Message-ID: <1317996375.04.0.296416474513.issue12192@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12192>
_______________________________________

From report at bugs.python.org  Fri Oct  7 16:20:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Oct 2011 14:20:00 +0000
Subject: [issue12602] Missing using docs cross-references
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1317997200.42.0.414757522772.issue12602@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The 'using docs' are, oddly enough, the part of the docs called 'using' :)

In particular, the part about the command line components (including the '<script>' argument):
http://docs.python.org/using/cmdline.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Fri Oct  7 16:22:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Oct 2011 14:22:08 +0000
Subject: [issue13063] test_concurrent_futures failures on Windows:
	IOError('[Errno 232] The pipe is being closed') on _send_bytes()
In-Reply-To: <1317323234.29.0.73593324718.issue13063@psf.upfronthosting.co.za>
Message-ID: <E1RCBJO-0004zQ-Fk@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d8d8374ddbcc by Antoine Pitrou in branch '3.2':
Issue #13063: the Windows error ERROR_NO_DATA (numbered 232 and described
http://hg.python.org/cpython/rev/d8d8374ddbcc

New changeset 3784b6000640 by Antoine Pitrou in branch 'default':
Issue #13063: the Windows error ERROR_NO_DATA (numbered 232 and described
http://hg.python.org/cpython/rev/3784b6000640

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13063>
_______________________________________

From report at bugs.python.org  Fri Oct  7 16:23:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Oct 2011 14:23:53 +0000
Subject: [issue13063] test_concurrent_futures failures on Windows:
	IOError('[Errno 232] The pipe is being closed') on _send_bytes()
In-Reply-To: <1317323234.29.0.73593324718.issue13063@psf.upfronthosting.co.za>
Message-ID: <1317997433.96.0.868599358374.issue13063@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hopefully this will fix the random failures (EPIPE is caught somewhere down in multiprocessing.Queue._feed).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13063>
_______________________________________

From report at bugs.python.org  Fri Oct  7 16:31:59 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 07 Oct 2011 14:31:59 +0000
Subject: [issue1164953] logging.basicConfig creates phantom handler
In-Reply-To: <1317991302.84.0.968515158077.issue1164953@psf.upfronthosting.co.za>
Message-ID: <1317997917.24301.YahooMailNeo@web25802.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> anatoly techtonik <techtonik at gmail.com> added the comment:
> 
> I know that it is by design, but from all logging users you may be the only one 
> who keeps this behaviour in mind. The message why basicConfig() failed will be 
> more user-friendly.

You're not likely to be aware of all the feedback I get from other users of the logging package, so I'm not sure what your inference "you may be the only one" is based on. Since basicConfig() didn't "fail" (behaviour is as designed), I'm not planning any changes in this area. Also note: this issue was raised and closed in March 2005, and there have been no requests since then to change the existing behaviour (nor would it be possible to accommodate such requests without compromising backward compatibility).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1164953>
_______________________________________

From report at bugs.python.org  Fri Oct  7 16:40:51 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Oct 2011 14:40:51 +0000
Subject: [issue1164953] logging.basicConfig creates phantom handler
Message-ID: <1317998451.45.0.349889272709.issue1164953@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

There were no request to change the behaviour, because there is already this closed issue where it is clearly said that this won't be fixed.

However, this doesn't cancel the fact that logging package needs enhancements to be more pythonic (i.e. intuitive and user-friendly). Even though they can not be included in Python, it can make sense to keep that in mind (or split a branch) for Python4.

http://code.google.com/p/rainforce/wiki/WartsOfPython#Logging_%282.x_tested,_3.x_unknown%29

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1164953>
_______________________________________

From report at bugs.python.org  Fri Oct  7 16:55:33 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 07 Oct 2011 14:55:33 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1317999333.3.0.767104636054.issue10141@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I added the line in the suggested place:

#ifdef HAVE_LINUX_TIPC_H
# include <linux/tipc.h>
#endif

#ifdef HAVE_LINUX_CAN_H
#include <linux/socket.h>  /* the line I added - line 76 */
#include <linux/can.h>
#endif

#ifdef HAVE_LINUX_CAN_RAW_H
#include <linux/can/raw.h>
#endif

Strangely, it seems to make no difference! I copied out the actual gcc line from the make file and ran it from the command line to just pre-process:

gcc -pthread -fPIC -g -O0 -Wall -Wstrict-prototypes -IInclude -I. -I./Include -I/usr/local/include -I/home/vinay/projects/python/default -E /home/vinay/projects/python/default/Modules/socketmodule.c >/tmp/tmp.c

(I assume /usr/include is always searched, as it's not explicitly named in a -I parameter.)

Looking at the tmp.c file produced, here's the relevant section:

# 182 "/usr/include/linux/tipc.h" 3 4
struct sockaddr_tipc {
 unsigned short family;
 unsigned char addrtype;
 signed char scope;
 union {
  struct tipc_portid id;
  struct tipc_name_seq nameseq;
  struct {
   struct tipc_name name;
   __u32 domain;
  } name;
 } addr;
};
# 73 "/home/vinay/projects/python/default/Modules/socketmodule.h" 2




# 1 "/usr/include/linux/can.h" 1 3 4

After the tipc.h include, the can.h include comes next, as if I hadn't added the linux/socket.h line at all! What is this I don't even ...

I pasted the whole socketmodule.h file to a gist here:

https://gist.github.com/1270436

Tell me I'm not going mad!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Fri Oct  7 16:57:20 2011
From: report at bugs.python.org (=?utf-8?q?F=C3=A9lix-Antoine_Fortin?=)
Date: Fri, 07 Oct 2011 14:57:20 +0000
Subject: [issue13118] Py_BuildValue format f incorrect description.
In-Reply-To: <1317926125.15.0.437576148609.issue13118@psf.upfronthosting.co.za>
Message-ID: <1317999440.38.0.226046727071.issue13118@psf.upfronthosting.co.za>


F?lix-Antoine Fortin <felixantoinefortin+python at gmail.com> added the comment:

I stand corrected.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13118>
_______________________________________

From report at bugs.python.org  Fri Oct  7 17:01:41 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 07 Oct 2011 15:01:41 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1317999701.77.0.851897885529.issue10141@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Just to test, I added the full absolute path name in socketmodule.h:

#ifdef HAVE_LINUX_CAN_H
#include "/usr/include/linux/socket.h"
#include <linux/can.h>
#endif

Now, the snippet from pre-processing is:

# 182 "/usr/include/linux/tipc.h" 3 4
struct sockaddr_tipc {
 unsigned short family;
 unsigned char addrtype;
 signed char scope;
 union {
  struct tipc_portid id;
  struct tipc_name_seq nameseq;
  struct {
   struct tipc_name name;
   __u32 domain;
  } name;
 } addr;
};
# 73 "/home/vinay/projects/python/default/Modules/socketmodule.h" 2



# 1 "/usr/include/linux/socket.h" 1
# 77 "/home/vinay/projects/python/default/Modules/socketmodule.h" 2
# 1 "/usr/include/linux/can.h" 1 3 4
# 41 "/usr/include/linux/can.h" 3 4

This implies that the linux/socket.h file is not being read at all. First part of linux/socket.h is:

#ifndef _LINUX_SOCKET_H
#define _LINUX_SOCKET_H

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Fri Oct  7 17:02:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Oct 2011 15:02:20 +0000
Subject: [issue12823] Broken link in "SSL wrapper for socket objects" document
In-Reply-To: <1314086720.91.0.705244554246.issue12823@psf.upfronthosting.co.za>
Message-ID: <E1RCBwI-0000dE-NX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 459f5e10cd4f by Antoine Pitrou in branch '3.2':
Issue #12823: remove broken link and replace it with another resource.
http://hg.python.org/cpython/rev/459f5e10cd4f

New changeset e80121fd12ba by Antoine Pitrou in branch 'default':
Issue #12823: remove broken link and replace it with another resource.
http://hg.python.org/cpython/rev/e80121fd12ba

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12823>
_______________________________________

From report at bugs.python.org  Fri Oct  7 17:02:20 2011
From: report at bugs.python.org (Sven Marnach)
Date: Fri, 07 Oct 2011 15:02:20 +0000
Subject: [issue13122] Out of date links in the sidebar of the documentation
	index of versions 3.1 and 3.2
Message-ID: <1317999740.46.0.922190010194.issue13122@psf.upfronthosting.co.za>


New submission from Sven Marnach <sven at marnach.net>:

The sidebar on http://docs.python.org/release/3.1.3/ names 3.2 as the development version of Python, while the link points to 3.3.  The sidebar on http://docs.python.org/py3k/ links to 3.1 as the "stable version" -- obviously a relict from the time when 3.2 was in development.  (This could be fixed in Doc/tools/sphinxext/indexsidebar.html of the respective branches.)

----------
assignee: docs at python
components: Documentation
messages: 145084
nosy: docs at python, smarnach
priority: normal
severity: normal
status: open
title: Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13122>
_______________________________________

From report at bugs.python.org  Fri Oct  7 17:08:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Oct 2011 15:08:26 +0000
Subject: [issue12823] Broken link in "SSL wrapper for socket objects" document
In-Reply-To: <1314086720.91.0.705244554246.issue12823@psf.upfronthosting.co.za>
Message-ID: <E1RCC2C-0001K1-VW@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 666e7e325795 by Antoine Pitrou in branch '2.7':
Issue #12823: remove broken link and replace it with another resource.
http://hg.python.org/cpython/rev/666e7e325795

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12823>
_______________________________________

From report at bugs.python.org  Fri Oct  7 17:09:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Oct 2011 15:09:34 +0000
Subject: [issue12823] Broken link in "SSL wrapper for socket objects" document
In-Reply-To: <1314086720.91.0.705244554246.issue12823@psf.upfronthosting.co.za>
Message-ID: <1318000174.85.0.714711684939.issue12823@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed now. Hopefully the replacement resource is good enough.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12823>
_______________________________________

From report at bugs.python.org  Fri Oct  7 17:10:45 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 07 Oct 2011 15:10:45 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1318000245.3.0.236200539311.issue10141@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Ok, I found that linux/socket.h *is* actually included earlier, from /usr/include/linux/netlink.h. However, the AF_CAN definition appears only under the condition

#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)

...
#define AF_CAN		29	/* Controller Area Network      */
...

#endif /* not kernel and not glibc */
#endif /* _LINUX_SOCKET_H */

which would imply that on this system at least, the AF_CAN definition is supposed to come from elsewhere. I did a recursive grep in /usr/include: the only place AF_CAN is defined is linux/socket.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Fri Oct  7 17:18:50 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 07 Oct 2011 15:18:50 +0000
Subject: [issue1164953] logging.basicConfig creates phantom handler
In-Reply-To: <1317998451.45.0.349889272709.issue1164953@psf.upfronthosting.co.za>
Message-ID: <1318000728.58453.YahooMailNeo@web25802.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> There were no request to change the behaviour, because there is already this 
> closed issue where it is clearly said that this won't be fixed.

Sure, but this issue seldom comes up as a point of confusion on comp.lang.python. If you think the documentation is confusing or not sufficiently explicit, you can propose a patch. Since configuration preferences and styles tend to be very much a matter of personal taste, I'm pretty sure that any change in this area which will be liked by some people won't be liked by others. So, it's best if people roll their own or publish on PyPI or elsewhere some code [to configure logging "optimally"] which others can use: if a widely-used pattern emerges as a no-brainer from actual usage out there, we can revisit this discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1164953>
_______________________________________

From report at bugs.python.org  Fri Oct  7 17:22:40 2011
From: report at bugs.python.org (Paul Moore)
Date: Fri, 07 Oct 2011 15:22:40 +0000
Subject: [issue13123] bdist_wininst uninstaller does not remove pycache
	directories
Message-ID: <1318000960.21.0.140069466315.issue13123@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

When uninstalling a package installed using a bdist_wininst installer, the uninstall reports "XXX files and directories could not be removed". The problem appears to be the __pycache__ directories introduced in Python 3.2, which are not removed properly.

----------
assignee: tarek
components: Distutils, Windows
messages: 145090
nosy: eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: bdist_wininst uninstaller does not remove pycache directories
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13123>
_______________________________________

From report at bugs.python.org  Fri Oct  7 17:44:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 15:44:46 +0000
Subject: [issue13114] check -r fails with non-ASCII unicode long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <1318002286.0.0.860114316866.issue13114@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the quick patch!  I feared it would be something more complicated :)  I will add a test and commit this.  (I added 3.2 and 3.3 to the versions because I will add the test there too, to make sure the code behaves right.)  Can you give me a Latin transliteration of your name so that I can credit you?

----------
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:03:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 16:03:18 +0000
Subject: [issue2945] bdist_rpm does not list dist files (should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <1318003398.23.0.744170146927.issue2945@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great!  Could you add a test for this?  By the way, do you have a machine with rpm installed?  I don?t, so I won?t be able to test the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2945>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:03:56 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 07 Oct 2011 16:03:56 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1318003436.08.0.590286657713.issue10141@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> which would imply that on this system at least, the AF_CAN definition is 
> supposed to come from elsewhere.

Yes, from <bits/socket.h>.
Looks like a crappy libc version: <linux/can.h> is present, but AF_CAN is not defined.
Just for fun, is PF_CAN defined?

You might try the following in configure.in:
"""
# On Linux, can.h and can/raw.h require sys/socket.h
AC_CHECK_HEADERS(linux/can.h linux/can/raw.h,,,[
#ifdef HAVE_SYS_SOCKET_H
#include <sys/socket.h>
#ifndef AF_CAN
# error "AF_CAN not defined"
#endif
#endif
])
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:13:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 16:13:45 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1318004025.15.0.877100771173.issue12436@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks Mike!  So the first item is covered (at least for UNIX, can you check the Windows docs too?), but not the second.  The item you linked to explains how to modify a script so that it?s possible to run ./script on Unix, but does not give an actual example of running it, nor does it explain ?python script? or ?python script.py? or ?python -m module?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:15:11 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Oct 2011 16:15:11 +0000
Subject: [issue11250] 2to3 truncates files at formfeed character
In-Reply-To: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>
Message-ID: <1318004111.2.0.0103068299163.issue11250@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I also noticed that test_parser.py isn't being run in either 3.2 or 3.3.  I'll fix that at the same time I port this patch to 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11250>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:15:21 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Oct 2011 16:15:21 +0000
Subject: [issue11250] 2to3 truncates files at formfeed character
In-Reply-To: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>
Message-ID: <1318004121.46.0.464472522598.issue11250@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee:  -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11250>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:16:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 16:16:17 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318004177.81.0.444589989915.issue12602@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Terry, might that other issue be #12298?

----------
title: Missing using docs cross-references -> Missing cross-references in Doc/using

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:21:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 16:21:29 +0000
Subject: [issue13123] bdist_wininst uninstaller does not remove pycache
	directories
In-Reply-To: <1318000960.21.0.140069466315.issue13123@psf.upfronthosting.co.za>
Message-ID: <1318004489.23.0.990476977779.issue13123@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Are you familiar with the bdist_wininst code?  I am not (yet), so if you could make a patch it would help a lot.

See also #11254 (which I will commit shortly).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13123>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:21:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 16:21:53 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <1318004513.16.0.846411192076.issue11254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I will commit this today or tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:29:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 07 Oct 2011 16:29:10 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1318004950.34.0.931160922838.issue10359@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

According to the latest patch updated by Victor, there are only 3 files left:
 * Lib/distutils/tests/test_config_cmd.py
 * Python/Python-ast.c
 * Modules/_ctypes/libffi/src/x86/ffi.c

The first is in a test and it's probably safe to fix (?ric, do you want to take care of that?) and the last should be reported upstream.
About the one in Python/Python-ast.c, either we fix it or if the proposed patch is not acceptable, we can close this issue as soon as the first file is fixed.

----------
nosy: +ezio.melotti
stage:  -> patch review
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:31:26 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 07 Oct 2011 16:31:26 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1318005086.05.0.139978156254.issue10141@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

PF_CAN is defined by

#define PF_CAN		AF_CAN

in linux/socket.h :-(

Making the change in configure.in didn't lead to any change: no error when I ran configure (which is ./configure --with-py-debug in my case), and when I build, the same error (AF_CAN undefined) occurs. Just to eliminate any extraneous variables and be absolutely sure, the program

#include <sys/socket.h>
#include <stdio.h>

int main(int argc, char ** argv)
{
    printf("AF_CAN is %d\n", AF_CAN);
}

also fails with the same error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:33:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Oct 2011 16:33:06 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1318005186.73.0.195750402442.issue10141@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Making the change in configure.in didn't lead to any change: no error
> when I ran configure

Did you run autoconf (or autoreconf) before?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:37:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 07 Oct 2011 16:37:49 +0000
Subject: [issue13078] Python Crashes When Saving Or Opening
In-Reply-To: <1317404515.12.0.258020695982.issue13078@psf.upfronthosting.co.za>
Message-ID: <1318005469.53.0.308388062485.issue13078@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Maybe #12988 is related.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13078>
_______________________________________

From report at bugs.python.org  Fri Oct  7 18:46:54 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 07 Oct 2011 16:46:54 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1318005186.73.0.195750402442.issue10141@psf.upfronthosting.co.za>
Message-ID: <1318006012.25273.YahooMailNeo@web25801.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Did you run autoconf (or autoreconf) before?

D'oh! I didn't realise I had to, though in retrospect it should have been obvious ... autoconf isn't even installed on my system, and I can't install it at the moment because of some problem with the Ubuntu repos for Jaunty.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:09:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 17:09:01 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1318007341.08.0.913592073586.issue10359@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I will commit this fix and push this week-end or Monday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:10:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 17:10:16 +0000
Subject: [issue9100] test_sysconfig fails (test_user_similar)
In-Reply-To: <1277731663.45.0.56366593786.issue9100@psf.upfronthosting.co.za>
Message-ID: <1318007416.79.0.103681667537.issue9100@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I will work on a patch.

----------
assignee: tarek -> eric.araujo
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9100>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:10:19 2011
From: report at bugs.python.org (Mike Hoy)
Date: Fri, 07 Oct 2011 17:10:19 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1318007419.76.0.0380576944804.issue12436@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

> Thanks Mike!  So the first item is covered (at least for UNIX, can you 
> check the Windows docs too?), but not the second.  

http://docs.python.org/dev/using/windows.html Makes no reference to preparing a text editor. This I could help with but...

> The item you linked 
> to explains how to modify a script so that it?s possible to run 
> ./script on Unix, but does not give an actual example of running it, 
> nor does it explain ?python script? or ?python script.py? or ?python -m 
> module?.

Some one else would have to write this part unless you can give me some info about how it should be worded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:12:37 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 07 Oct 2011 17:12:37 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1318007557.02.0.978996194608.issue10141@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a better patch.
It only touches socketmodule.c, so no need for autoconf, just use make.
If it works on your box, I'll test it on the custom buildbots before pushing it for good (if I learned one thing, it's to never underestimate the potential for broken headers/libc).

----------
Added file: http://bugs.python.org/file23337/af_can_undefined.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:14:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 17:14:44 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1318007684.0.0.16394259562.issue8087@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I do not understand what the proposed feature is.  I also think it should be discussed on the python-ideas mailing list first: http://mail.python.org/listinfo/python-ideas

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:23:28 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 07 Oct 2011 17:23:28 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1318008208.69.0.16994103599.issue10141@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

That did the trick - I can now build the socket module. Thanks!

I noticed that the module initialisation code uses #ifdef AF_CAN and #ifdef PF_CAN rather than #ifdef HAVE_LINUX_CAN_H :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:26:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 17:26:56 +0000
Subject: [issue12314] regrtest checks (os.environ, sys.path,
	etc.) are hard to use
In-Reply-To: <1307722749.85.0.48203387339.issue12314@psf.upfronthosting.co.za>
Message-ID: <1318008416.37.0.17432118494.issue12314@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Idea: when a regrtest check fails, the test is run again but a WatchfulMixin is injected into the test case?s bases, so that setUp and tearDown call the right methods.  This would be more efficient than always running with a watchful test runner.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12314>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:27:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 17:27:27 +0000
Subject: [issue13038] distutils windows installer
	STATUS_INVALID_CRUNTIME_PARAMETER (C0000417) exception when
	python dir is read only
In-Reply-To: <1316816072.59.0.865990615621.issue13038@psf.upfronthosting.co.za>
Message-ID: <1318008447.29.0.245722673848.issue13038@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Are these winsinst or MSI installers?

----------
components: +Distutils2 -Distutils
nosy: +alexis
versions: +3rd party, Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13038>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:30:52 2011
From: report at bugs.python.org (Mitch Frazier)
Date: Fri, 07 Oct 2011 17:30:52 +0000
Subject: [issue13038] distutils windows installer
	STATUS_INVALID_CRUNTIME_PARAMETER (C0000417) exception when
	python dir is read only
In-Reply-To: <1318008447.29.0.245722673848.issue13038@psf.upfronthosting.co.za>
Message-ID: <4E8F3749.1070108@comwestcr.com>


Mitch Frazier <mitch at comwestcr.com> added the comment:

On 10/7/2011 10:27 AM, ?ric Araujo wrote:
>
> ?ric Araujo<merwok at netwok.org>  added the comment:
>
> Are these winsinst or MSI installers?

They are windows installers (winsinst).

>
> ----------
> components: +Distutils2 -Distutils
> nosy: +alexis
> versions: +3rd party, Python 3.3 -Python 2.7
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue13038>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13038>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:35:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 17:35:40 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1318008940.09.0.903739508634.issue4489@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I made another review but my mail was rejected.

http://bugs.python.org/review/4489/diff/3383/10563#newcode319
Lib/test/test_shutil.py:319: @unittest.skipIf(threading == None,
'requires threading')
You can just say skipUnless(threading, 'msg')

http://bugs.python.org/review/4489/diff/3383/10563#newcode344
Lib/test/test_shutil.py:344: raise
Shouldn?t this use self.fail?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:38:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 17:38:24 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1318009104.26.0.680721561885.issue12436@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> http://docs.python.org/dev/using/windows.html Makes no reference to
> preparing a text editor. This I could help with but...
Cool, please follow the guidelines in the devguide to make a patch for 3.2.  It should be something short, like the unix docs, mostly to recommend Notepad++ I think.

For Windows users, added a section about how to use a terminal and possibly a link to PowerShell would be another good addition IMO.

> Some one else would have to write this part unless you can give me
> some info about how it should be worded.
I?ll propose a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:39:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 17:39:27 +0000
Subject: [issue13038] bdist_wininst installers should warn if target dir is
	read-only
In-Reply-To: <1316816072.59.0.865990615621.issue13038@psf.upfronthosting.co.za>
Message-ID: <1318009167.86.0.494161171712.issue13038@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

All right.  Reclassifying as a feature request for distutils2/packaging (in Python 3.3).

----------
stage:  -> needs patch
title: distutils windows installer STATUS_INVALID_CRUNTIME_PARAMETER (C0000417) exception when python dir is read only -> bdist_wininst installers should warn if target dir is read-only

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13038>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:43:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 17:43:37 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1318009417.02.0.688316810272.issue7833@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There is a already a test for manifest things in Lib/distutils/tests/test_msvc9compiler.py, and higher-level tests for building extension modules in Lib/distutils/tests/test_build_ext.py and Lib/distutils/tests/test_install.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Fri Oct  7 19:44:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Oct 2011 17:44:40 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1318009480.41.0.650233812502.issue7833@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let me add that I don?t know the MS toolchain at all, but if you tell me what a test should do (e.g. compile a C extension, open some compiled file and look for some bytes) I can write a test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Fri Oct  7 20:02:46 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Oct 2011 18:02:46 +0000
Subject: [issue11250] 2to3 truncates files at formfeed character
In-Reply-To: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>
Message-ID: <1318010566.84.0.0490959462372.issue11250@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Okay, re-enabling test_parser.py introduces a number of test failures in test_all_project_files().  Because I don't want to continue to shave the yak on this one, I'm going to wrap this test in @expectedFailure and open a separate bug for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11250>
_______________________________________

From report at bugs.python.org  Fri Oct  7 20:15:33 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Oct 2011 18:15:33 +0000
Subject: [issue12681] unittest expectedFailure could take a message argument
	like skip does
In-Reply-To: <1312285316.59.0.648531105022.issue12681@psf.upfronthosting.co.za>
Message-ID: <1318011333.65.0.216451621611.issue12681@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

It would be nice if expectedFailure took a bug number and printed a url to the tracker.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12681>
_______________________________________

From report at bugs.python.org  Fri Oct  7 20:18:38 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 07 Oct 2011 18:18:38 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
Message-ID: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Here's a patch to add a page to the devguide on running a build slave.  I copied pretty liberally from the wiki (http://wiki.python.org/moin/BuildBot).  That page may or may not be up to date (I don't know), so the bulk of this new page may also be out of date...

The current devguide buildbots page is oriented toward the use of buildbots in the dev process.  In contrast, this new page is all about running one.  I figured it is yet another easy way that people can contribute to Python.

I didn't stick in the windows-specific buildbot info (http://wiki.python.org/moin/BuildbotOnWindows), but did link to the wiki page.

I did include the info, as far as I understood it, from a recent python-dev thread (http://mail.python.org/pipermail/python-dev/2011-October/113935.html).

I added a link to the devguide index page, but it may need to be shifted to the right spot (maybe right after "Running & Writing Tests").  I also renamed buildbots.rst to continuous_integration.rst (and updated reference accordingly).

I want to be sure attribution is appropriate, regarding the text pulled from the wiki page and from the python-dev thread.  Is linking to the thread sufficient?

This is a rough stab (especially with the inclusion of the still-ongoing python-dev thread); but hopefully this gets a ball rolling and doesn't take much work to polish.  :)

----------
assignee: docs at python
components: Devguide, Documentation
files: buildslaves.diff
keywords: patch
messages: 145120
nosy: brett.cannon, docs at python, eric.snow
priority: normal
severity: normal
status: open
title: Add "Running a Build Slave" page to the devguide
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23338/buildslaves.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13124>
_______________________________________

From report at bugs.python.org  Fri Oct  7 20:30:03 2011
From: report at bugs.python.org (Mike Hoy)
Date: Fri, 07 Oct 2011 18:30:03 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1318012203.84.0.114627612943.issue12436@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

> mostly to recommend Notepad++ I think.

In addition to Notepad++ do you think it would be a good idea to at least mention Vim and Emacs with a disclaimer about the learning curve?

> For Windows users, added a section about how to use a terminal and 

Do you think it would be a good idea to add instructions on how to add Python to the Path in Windows? It could be 'borrowed' from the Boston Python Workshop Page I would think. It's pretty long but useful considering how much trouble I have had having to do this myself under Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Fri Oct  7 20:38:13 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Oct 2011 18:38:13 +0000
Subject: [issue13125] test_all_project_files() expected failure
Message-ID: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

In working on issue 11250, I noticed that lib2to3's test_parser.py tests were not enabled.  Fixing that was easy enough, but then test_all_project_files() in TestParserIdempotency began failing.  I've shaved enough yaks for the day so I am going to leave test_parser enabled but mark test_all_project_files() with @expectedFailure.

Note that there are a number of failures here. There are two ParseErrors, one in main.py and one in pytree_idempotency.py.  These both seem to fail on print(..., file=foo).  After that, bom.py fails idempotency because the BOM does not show up in the converted file.

----------
components: Tests
messages: 145122
nosy: barry, benjamin.peterson
priority: normal
severity: normal
status: open
title: test_all_project_files() expected failure
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13125>
_______________________________________

From report at bugs.python.org  Fri Oct  7 20:45:46 2011
From: report at bugs.python.org (Kirill Kuzminykh)
Date: Fri, 07 Oct 2011 18:45:46 +0000
Subject: [issue13114] check -r fails with non-ASCII unicode long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <1318013146.56.0.522238078565.issue13114@psf.upfronthosting.co.za>


Kirill Kuzminykh <saikuz at mail.ru> added the comment:

Latin transliteration of my name is Kirill Kuzminykh.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Fri Oct  7 20:55:35 2011
From: report at bugs.python.org (Paul Moore)
Date: Fri, 07 Oct 2011 18:55:35 +0000
Subject: [issue13123] bdist_wininst uninstaller does not remove pycache
	directories
In-Reply-To: <1318004489.23.0.990476977779.issue13123@psf.upfronthosting.co.za>
Message-ID: <CACac1F9KCeMSqzBBMm3E=+sVyPu8uYHKUV+AativQvB_7BFkvg@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

Not really (tbh, not at all). If I get some spare time, I can have a
look at producing a patch, but I have little time available for coding
at the moment (and I'm switching constantly between 3 PCs, so never
have a working development environment when I need one :-() If I get
anything workable before you do, I'll post it here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13123>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:01:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Oct 2011 19:01:55 +0000
Subject: [issue13063] test_concurrent_futures failures on Windows:
	IOError('[Errno 232] The pipe is being closed') on _send_bytes()
In-Reply-To: <1317323234.29.0.73593324718.issue13063@psf.upfronthosting.co.za>
Message-ID: <1318014115.94.0.232524990978.issue13063@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Mmh, for some reason it seems it was not enough:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5328/steps/test/logs/stdio

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13063>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:03:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Oct 2011 19:03:17 +0000
Subject: [issue7367] pkgutil.walk_packages fails on write-only directory in
	sys.path
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <E1RCFhU-0006Hj-68@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 17b5afd321a8 by Ned Deily in branch '2.7':
Issue #7367: Ensure test directory always gets removed.
http://hg.python.org/cpython/rev/17b5afd321a8

New changeset ff72f76dcf43 by Ned Deily in branch '3.2':
Issue #7367: Ensure test directory always gets removed.
http://hg.python.org/cpython/rev/ff72f76dcf43

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:10:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 07 Oct 2011 19:10:12 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1318014612.04.0.148264127407.issue13124@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

A few comments:
  * are you following some convention about the spelling of buildbot/Buildbot/BuildBot?
  * "+3. the standard development toolchain."
    Which is? I think a compiler is the only missing bit.
  * "(in which case you'll have to install Python and Twisted first)."
    I would say "you'll need" and not assume that they are not installed.
  * "a couple of third-party libraries (such as zlib and OpenSSL)."
    Actually these are not required, and it might even be good to have some buildbot without e.g. zlib.
  * "+   % su - buildbot"
    I think we use $ elsewhere in the doc.  You can also set the highlightlang to sh (iirc).
  * "/usr/local/bin", these should get some markup: either ``..`` or :file:`...` (is :file: ok for dirs too?).
  * "You'll need to get someone to create the slavename/slavepasswd on dinsdale.python.org before doing this."
    So maybe put it before?
  * "monitor the build results and solve any setup issues causing test failures"
    If running a buildbot implies some responsibilities, maybe they should be mentioned earlier.
  * "executing arbitrarily horrible and/or malicious code"
    This sounds bad and misleading.  At worst the test can use resources extensively and/or cause crashes, but that doesn't mean that the code is arbitrary, horrible, or malicious.
  * "for cutting of the builder"
    s/of/off/
  * "Therefore builders should be set up in both configurations"
    This might lead build masters to think they have to set up both.
  * "Some tests, as the start of `this thread "
    You already have a link to this at the end of the section
  * "+Running a build slave requires some network access."
    Isn't 9020 the only *required* one?  If the others are not available, test will (should) be skipped.

----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13124>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:25:27 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 07 Oct 2011 19:25:27 +0000
Subject: [issue13122] Out of date links in the sidebar of the documentation
	index of versions 3.1 and 3.2
In-Reply-To: <1317999740.46.0.922190010194.issue13122@psf.upfronthosting.co.za>
Message-ID: <1318015527.54.0.124551697856.issue13122@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13122>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:26:57 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 07 Oct 2011 19:26:57 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1318015617.49.0.046358771642.issue13124@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Great feedback!  Keep in mind that nearly all the content in my patch is pulled unedited from either the wiki page and the python-dev thread I mentioned.

I'll work on cleaning it up when I get a chance (probably after Wednesday's PyCon CFP closes :).  If anyone wants to do it before I get a chance, they are welcome to it.  Either way I think such a page will be helpful to have in the devguide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13124>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:27:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Oct 2011 19:27:05 +0000
Subject: [issue13125] test_all_project_files() expected failure
In-Reply-To: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>
Message-ID: <E1RCG4W-0000AP-B5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 914d3f035887 by Barry Warsaw in branch 'default':
- Re-enable lib2to3's test_parser.py tests, though with an expected failure
http://hg.python.org/cpython/rev/914d3f035887

New changeset ed0315b9da72 by Barry Warsaw in branch 'default':
- Re-enable lib2to3's test_parser.py tests, though with an expected failure
http://hg.python.org/cpython/rev/ed0315b9da72

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13125>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:27:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Oct 2011 19:27:06 +0000
Subject: [issue11250] 2to3 truncates files at formfeed character
In-Reply-To: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>
Message-ID: <E1RCG4W-0000AP-BC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6e0e9237d8e8 by Barry Warsaw in branch '3.2':
- Issue #11250: Back port fix from 3.3 branch, so that 2to3 can handle files
http://hg.python.org/cpython/rev/6e0e9237d8e8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11250>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:30:32 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 07 Oct 2011 19:30:32 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1318015832.26.0.319720984919.issue13124@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think the whole security paragraph should be deleted. The
discussion on python-dev has overstated the risks.

Anyone who is *that* security conscious and in effect does
not trust the Python committers should also audit the thousands
of lines of ./configure and any code that is executed by
`make install`, to name a few "security risks".


What I would like to see in the devguide is a cookbook shell
script with minimal comments that interested persons can
simply run.


The easiest way for me (I'm running two bots) was to install
Python-2.7 from source, then pip, then `pip install buildslave`.
(Yes, as root :). That automatically gets everything right and
you don't depend on stale packages from the distro.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13124>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:30:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 07 Oct 2011 19:30:55 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1318015855.2.0.291871518352.issue12436@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> In addition to Notepad++ do you think it would be a good idea to at
> least mention Vim and Emacs with a disclaimer about the learning curve?

I'm not sure how many windows user use Vim/Emacs.  Maybe PyScripter could be mentioned too, but I'm not sure how popular it is and if there are better alternatives.

> Do you think it would be a good idea to add instructions on how to add
> Python to the Path in Windows? 

Yes, but isn't there a script somewhere that does that already?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:34:37 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 07 Oct 2011 19:34:37 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1318016077.51.0.919401901316.issue4489@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

http://bugs.python.org/review/4489/diff/3383/10563#newcode319
Lib/test/test_shutil.py:319: @unittest.skipIf(threading == None, 'requires
threading')
On 2011/10/07 19:29:47, eric.araujo wrote:
> You can just say skipUnless(threading, 'msg')

Right.

http://bugs.python.org/review/4489/diff/3383/10563#newcode344
Lib/test/test_shutil.py:344: raise
On 2011/10/07 19:29:47, eric.araujo wrote:
> Shouldn?t this use self.fail?

I would have thought it's better if the original exception is passed through and
displayed rather than some sort of failure message that just says "OSError
occurred".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:37:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Oct 2011 19:37:29 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1318016249.49.0.753702364253.issue12436@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In addition to Notepad++ do you think it would be a good idea to at
> least mention Vim and Emacs with a disclaimer about the learning curve?

I'm a bit surprised. I would think the devguide is aimed are people who are *already* programmers, and have chosen their tools. Therefore I don't know how such material is useful, and the devguide is already hefty enough.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:38:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Oct 2011 19:38:48 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1318016328.47.0.350082174698.issue12436@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops. I just noticed this issue is not talking about the devguide, but the general docs. Please ignore the message above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:46:01 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Oct 2011 19:46:01 +0000
Subject: [issue11250] 2to3 truncates files at formfeed character
In-Reply-To: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>
Message-ID: <1318016761.56.0.42734950467.issue11250@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11250>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:46:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Oct 2011 19:46:36 +0000
Subject: [issue13126] find() slower than rfind()
Message-ID: <1318016796.03.0.16031959225.issue13126@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

With some gcc versions, str.find() is slower than str.rfind():

 - 	11.22	0.0	s="ABC"*33; ((s+"D")*500+s+"E").find(s+"E") (*100)
 - 	4.56	0.0	s="ABC"*33; ((s+"D")*500+"E"+s).find("E"+s) (*100)
 - 	6.71	0.0	s="ABC"*33; (s+"E") in ((s+"D")*300+s+"E") (*100)
 - 	11.22	0.0	s="ABC"*33; ((s+"D")*500+s+"E").index(s+"E") (*100)
 - 	11.52	0.0	s="ABC"*33; ((s+"D")*500+s+"E").partition(s+"E") (*100)
 - 	8.79	0.0	s="ABC"*33; ("E"+s+("D"+s)*500).rfind("E"+s) (*100)
 - 	3.86	0.0	s="ABC"*33; (s+"E"+("D"+s)*500).rfind(s+"E") (*100)
 - 	8.80	0.0	s="ABC"*33; ("E"+s+("D"+s)*500).rindex("E"+s) (*100)
 - 	9.80	0.0	s="ABC"*33; ("E"+s+("D"+s)*500).rpartition("E"+s) (*100)
 - 	9.83	0.0	s="ABC"*33; ("E"+s+("D"+s)*500).rsplit("E"+s, 1) (*100)
 - 	11.56	0.0	s="ABC"*33; ((s+"D")*500+s+"E").split(s+"E", 1) (*100)


Attached patch seems to fix it.

----------
components: Interpreter Core
files: findperf.patch
keywords: patch
messages: 145136
nosy: haypo, pitrou
priority: low
severity: normal
status: open
title: find() slower than rfind()
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file23339/findperf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13126>
_______________________________________

From report at bugs.python.org  Fri Oct  7 21:53:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Oct 2011 19:53:46 +0000
Subject: [issue13063] test_concurrent_futures failures on Windows:
	IOError('[Errno 232] The pipe is being closed') on _send_bytes()
In-Reply-To: <1317323234.29.0.73593324718.issue13063@psf.upfronthosting.co.za>
Message-ID: <1318017226.82.0.80677963781.issue13063@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, this is because IOError is raised because of WindowsError, thus there's no errno translation.
Ok, I'd like to wait for PEP 3151 to be merged, then, because it should solve this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13063>
_______________________________________

From report at bugs.python.org  Fri Oct  7 22:05:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Oct 2011 20:05:19 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1318017919.18.0.413442435836.issue11085@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> collections is one of those modules everyone will use in their code.

Simply untrue, and definitely not in every program. It is also irrelevant for bringing up the interactive interpreter, where there initially is no user code and which should happen as fast as possible. I also doubt IDLE uses collections to bring up its shell window.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Fri Oct  7 22:11:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Oct 2011 20:11:59 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1318017919.18.0.413442435836.issue11085@psf.upfronthosting.co.za>
Message-ID: <1318018101.3697.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > collections is one of those modules everyone will use in their code.
> 
> Simply untrue, and definitely not in every program. It is also
> irrelevant for bringing up the interactive interpreter, where there
> initially is no user code and which should happen as fast as possible.

I don't think a 50ms startup time is a problem for the interactive
interpreter. Of course, it will be more noticeable on very slow
machines.

> I also doubt IDLE uses collections to bring up its shell window.

The collections module appeared in 2.4; antiquated code might indeed not
know about it ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Fri Oct  7 22:22:46 2011
From: report at bugs.python.org (Aaron Robson)
Date: Fri, 07 Oct 2011 20:22:46 +0000
Subject: [issue13060] allow other rounding modes in round()
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1318018966.2.0.394454852021.issue13060@psf.upfronthosting.co.za>


Aaron Robson <shiny.magnum at googlemail.com> added the comment:

When i run into I have to bodge around it in ways like the below code.

I've only ever used round half up, has anyone here even used Bankers Rounding by choice before?

For reference here are the other options: http://en.wikipedia.org/wiki/Rounding#Tie-breaking

def RoundHalfUp(number):
  '''http://en.wikipedia.org/wiki/Rounding#Round_half_up
  0.5 and above round up else round down.
  '''
  trunc = int(number)
  fractionalPart = number - trunc
  if fractionalPart < 0.5:
    return trunc
  else:
    ceil = trunc + 1
    return ceil

----------
nosy: +AaronR

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13060>
_______________________________________

From report at bugs.python.org  Fri Oct  7 22:25:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 07 Oct 2011 20:25:05 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1318019105.32.0.409360495996.issue8087@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm not sure this is useful to have.  If you changed your code you know that you have to reload, so why would you want a warning that tells you that you changed the code?

For some reason I always had the opposite problem (i.e. after a reload the traceback was still showing the original code, and not the new one), while IIUC you are saying that it shows the new code even if the module is not reloaded.
I tried your code and indeed it does what you say, so either I am mistaken and I've been misreading the tracebacks, or this changed from 2.6 to 2.7, or in some cases even the behavior (I think) I observed might happen.
I'll have to verify this next time it happens.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Fri Oct  7 22:36:23 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Oct 2011 20:36:23 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1318019783.11.0.117537087156.issue11085@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You also have to think about command-line apps like Mercurial that need to be snappy.  For those guys, a lot of added startup time is a big deal -- one of the reasons Matt Mackall hates thinking about a Python 3 port is that Python 3(.2) startup time is already double that of Python 2.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Fri Oct  7 22:44:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Oct 2011 20:44:50 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <E1RCHHk-0006mv-RT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d4ce850b06b7 by Charles-Fran?ois Natali in branch 'default':
Issue #10141: fix socketmodule compilation on Linux systems with <linux/can.h>
http://hg.python.org/cpython/rev/d4ce850b06b7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Fri Oct  7 22:50:22 2011
From: report at bugs.python.org (Armin Ronacher)
Date: Fri, 07 Oct 2011 20:50:22 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1318020622.03.0.387106373633.issue11682@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

A little bit of input on this issue.  Considering that exceptions are now getting keyword arguments for things like import errors and other things for attributes I would find it much better if StopIteration would follow that as well (StopIteration(value=42) instead of StopIteration(42)).

----------
nosy: +aronacher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Fri Oct  7 23:13:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 07 Oct 2011 21:13:21 +0000
Subject: [issue13107] Text width in optparse.py can become negative
In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za>
Message-ID: <1318022001.33.0.0458586922962.issue13107@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

argparse has some similar code in Lib/argparse.py:489.  Can you reproduce the problem with argparse?
If you can't and argparse solved the problem already, we might adopt the same solution; if you can, it should be fixed there too.

----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13107>
_______________________________________

From report at bugs.python.org  Fri Oct  7 23:23:28 2011
From: report at bugs.python.org (Mike Hoy)
Date: Fri, 07 Oct 2011 21:23:28 +0000
Subject: [issue3902] Packages containing only extension modules have to
	contain __init__.py
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1318022608.28.0.699480403307.issue3902@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

> We?re working on a patch on the core-mentorship list.

?ric, I emailed the diff to the Core-Mentorship list, but since there was no reply I will just attach it here. Please review patch and let me know if you want any changes.

----------
keywords: +patch
nosy: +mikehoy
Added file: http://bugs.python.org/file23340/distutils-init.py-apiref-setup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Fri Oct  7 23:51:54 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 07 Oct 2011 21:51:54 +0000
Subject: [issue12681] unittest expectedFailure could take a message argument
	like skip does
In-Reply-To: <1312285316.59.0.648531105022.issue12681@psf.upfronthosting.co.za>
Message-ID: <1318024314.87.0.507605156763.issue12681@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Well, it would be nice for the Python test suite, maybe not so useful for external users of the api. Something for regrtest rather than unittest I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12681>
_______________________________________

From report at bugs.python.org  Fri Oct  7 23:53:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 07 Oct 2011 21:53:54 +0000
Subject: [issue13111] Error 2203 when installing Python/Perl?
In-Reply-To: <1317855327.52.0.585487977144.issue13111@psf.upfronthosting.co.za>
Message-ID: <1318024434.58.0.937792202246.issue13111@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13111>
_______________________________________

From report at bugs.python.org  Fri Oct  7 23:59:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 07 Oct 2011 21:59:35 +0000
Subject: [issue13122] Out of date links in the sidebar of the documentation
	index of versions 3.1 and 3.2
In-Reply-To: <1317999740.46.0.922190010194.issue13122@psf.upfronthosting.co.za>
Message-ID: <1318024775.25.0.593347511707.issue13122@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

AFAIK the doc for 3.1 is not rebuilt anymore, so even if it's fixed, the change won't have any visible effect -- unless someone manually triggers a rebuild.
Regarding the 3.1 link on the py3k page: I think 'stable' still applies, even if it only receives security fixes.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13122>
_______________________________________

From report at bugs.python.org  Sat Oct  8 00:16:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Oct 2011 22:16:13 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318025773.71.0.242689641188.issue12602@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As of 2.7/3.2, the doc is named "Python Setup and Usage" at
http://docs.python.org/index.html
http://docs.python.org/using/cmdline.html (and other chapters)
and in the contents list of the Windows help version.
For new doc editors, it would be nicer if the filename (directory name, actually) had been changed to 'py_setup' or even 'py_usage'.

Looking in the first chapter, which you finally referenced, I do see an entry for '<script>', with the brackets, that can be both a target and container of links. That usage, with a generic argument name in angle brackets, may be unique in the docs. (I looked at trace, profile, pydoc, timeit, test, and doctest docs.) So don't be so surprised that others are not familiar with it. 

Now that is cleared up:
+1 on the links suggested in the original message.

-1 on a link to the tracker issue. That is not a coherent document and cannot be edited and improved. If more doc is needed, there should have been and could be a PEP, addition to the <script> entry, or a new chapter section 1.3 Zipfiles.

---
>Terry, might that other issue be #12298?

Yes. I see you have applied a fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Sat Oct  8 00:52:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Oct 2011 22:52:58 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1318027978.4.0.21744225022.issue11085@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A couple of years ago, various people worked hard to remove unneeded imports from the interpreter startup routine. The result was both quite noticeable and much appreciated on my old xp machine. I hate to see much of that progress tossed away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Sat Oct  8 01:48:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Oct 2011 23:48:57 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1318031337.95.0.00443311619352.issue11085@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Sat Oct  8 02:25:09 2011
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 08 Oct 2011 00:25:09 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1318033509.33.0.531820397477.issue7833@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

My apologies Eric - I had completely overlooked those tests.  Attaching a new patch with a test.  Note the existing test doesn't actually perform a build so the new test also doesn't, but it does check the core logic (ie, that a manifest with only the msvcrt reference gets it scrubbed).

----------
Added file: http://bugs.python.org/file23341/bug-7833-overridable-manifest-settings-with-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Sat Oct  8 03:33:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Oct 2011 01:33:16 +0000
Subject: [issue13078] Python Crashes When Saving Or Opening
In-Reply-To: <1317404515.12.0.258020695982.issue13078@psf.upfronthosting.co.za>
Message-ID: <1318037596.32.0.984136161224.issue13078@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13078>
_______________________________________

From report at bugs.python.org  Sat Oct  8 03:41:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Oct 2011 01:41:18 +0000
Subject: [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1318038078.92.0.814408152609.issue13081@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If I understand the messages, this is more a program bug than a Python bug and the 'fix' for this tracker would be a doc patch. Adding one would be welcome.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13081>
_______________________________________

From report at bugs.python.org  Sat Oct  8 03:47:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Oct 2011 01:47:20 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about 3.x instead
	of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1318038440.71.0.362942383579.issue13086@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Yes, 'to Python 3'. Patch welcome. I would make it up to date as of 3.2. For 3.3, the Unicode api will change (grow) but that has not been finalized yet.

----------
nosy: +terry.reedy
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sat Oct  8 04:04:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Oct 2011 02:04:37 +0000
Subject: [issue13122] Out of date links in the sidebar of the documentation
	index of versions 3.1 and 3.2
In-Reply-To: <1317999740.46.0.922190010194.issue13122@psf.upfronthosting.co.za>
Message-ID: <1318039477.99.0.523585618964.issue13122@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I disagree about 3.2 not being 'stable'. With more bugs fixes, it should be more stable. People should be encouraged to download 3.2. 2.7 came out 8 months before, and that should be updated (and again when 3.3 comes out).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13122>
_______________________________________

From report at bugs.python.org  Sat Oct  8 06:18:12 2011
From: report at bugs.python.org (Dillon Amburgey)
Date: Sat, 08 Oct 2011 04:18:12 +0000
Subject: [issue13127] xml.dom.Attr.name is not labeled as read-only
Message-ID: <1318047492.07.0.217686953928.issue13127@psf.upfronthosting.co.za>


New submission from Dillon Amburgey <dillona at dillona.com>:

http://docs.python.org/library/xml.dom.html#dom-attr-objects does not label the name attribute as read-only (like localName) even though it is.

----------
assignee: docs at python
components: Documentation
messages: 145155
nosy: dillona, docs at python
priority: normal
severity: normal
status: open
title: xml.dom.Attr.name is not labeled as read-only

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13127>
_______________________________________

From report at bugs.python.org  Sat Oct  8 06:19:35 2011
From: report at bugs.python.org (Dillon Amburgey)
Date: Sat, 08 Oct 2011 04:19:35 +0000
Subject: [issue13127] xml.dom.Attr.name is not labeled as read-only
In-Reply-To: <1318047492.07.0.217686953928.issue13127@psf.upfronthosting.co.za>
Message-ID: <1318047575.12.0.0784977708118.issue13127@psf.upfronthosting.co.za>


Dillon Amburgey <dillona at dillona.com> added the comment:

The behavior can be verified as follows. Notice that despite changing the value, the output XML does not change

>>> from xml.dom import minidom, Node
>>> a = minidom.parseString("<a href=\"http://asd.com\">asd</a>")
>>> a
<xml.dom.minidom.Document instance at 0x22d7c68>
>>> a.childNodes
[<DOM Element: a at 0x22d7d88>]
>>> a.childNodes[0]
<DOM Element: a at 0x22d7d88>
>>> a.childNodes[0].attributes
<xml.dom.minidom.NamedNodeMap object at 0x21caa70>
>>> a.childNodes[0].attributes.item(0)
<xml.dom.minidom.Attr instance at 0x22d7f38>
>>> a.childNodes[0].attributes.item(0).name
u'href'
>>> attr = a.childNodes[0].attributes.item(0)
>>> attr.name = "ad"
>>> a.toxml()
u'<?xml version="1.0" ?><a href="http://asd.com">asd</a>'
>>> attr.value = "asd"
>>> a.toxml()
u'<?xml version="1.0" ?><a href="asd">asd</a>'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13127>
_______________________________________

From report at bugs.python.org  Sat Oct  8 07:11:45 2011
From: report at bugs.python.org (Matt Spear)
Date: Sat, 08 Oct 2011 05:11:45 +0000
Subject: [issue13128] httplib debuglevel on CONNECT doesn't print response
	headers
Message-ID: <1318050704.97.0.551622649018.issue13128@psf.upfronthosting.co.za>


New submission from Matt Spear <batman900 at gmail.com>:

httplib with a debuglevel prints out the response headers, but does not do so with CONNECT requests (when set_tunnel is used).  Attached is a small patch to print the reply when the CONNECT request returns something other than 200 OK.  I'm not sure if it is worth printing the headers when a 200 OK is given.  If it seems useful I can update the patch.

Thanks!!!

----------
components: Library (Lib)
files: httplib.py.patch
keywords: patch
messages: 145157
nosy: Matt.Spear
priority: normal
severity: normal
status: open
title: httplib debuglevel on CONNECT doesn't print response headers
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file23342/httplib.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13128>
_______________________________________

From report at bugs.python.org  Sat Oct  8 07:15:48 2011
From: report at bugs.python.org (rmtew)
Date: Sat, 08 Oct 2011 05:15:48 +0000
Subject: [issue13129] bad argument exceptions observed in AST
Message-ID: <1318050948.4.0.561383872922.issue13129@psf.upfronthosting.co.za>


New submission from rmtew <richard.m.tew at gmail.com>:

Platform Windows 7.
hg id: a3f2dba93743+ (3.2)

I do not know any reproduction steps for this bug outside as a side-effect within an incomplete and problematic Stackless merge.  This bug also seems to exist in cpython, and is not in Stackless specific code.

It seems to be bad exception handling, but maybe I do not understand all cases where this code is used.

1. ast_error_finish is called.
2. It calls PyErr_Fetch(&type, &value, &tback);
3. It them proceeds to treat 'value' as a tuple which results in PyErr_BadInternalCall being called and then being used in place of the original exception.

Reproduction steps:

1. Sync http://hg.python.org/stackless.
2. Update to 3.2-slp branch.
3. Merge in changes from v3.2.1 to v3.2.2.
4. Compile and run regression tests.
5. Several exceptions will happen along the lines of bad argument where ast exceptions have happened and hit the problem above.

----------
files: ast.diff
keywords: patch
messages: 145158
nosy: rmtew
priority: normal
severity: normal
status: open
title: bad argument exceptions observed in AST
versions: Python 3.2
Added file: http://bugs.python.org/file23343/ast.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13129>
_______________________________________

From report at bugs.python.org  Sat Oct  8 07:31:45 2011
From: report at bugs.python.org (rmtew)
Date: Sat, 08 Oct 2011 05:31:45 +0000
Subject: [issue13129] bad argument exceptions observed in AST
In-Reply-To: <1318050948.4.0.561383872922.issue13129@psf.upfronthosting.co.za>
Message-ID: <1318051905.45.0.633320639659.issue13129@psf.upfronthosting.co.za>


rmtew <richard.m.tew at gmail.com> added the comment:

False alarm, must have reproduced this in wrong source tree :-(  Purely Stackless-specific.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13129>
_______________________________________

From report at bugs.python.org  Sat Oct  8 08:20:20 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Sat, 08 Oct 2011 06:20:20 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1318054820.67.0.179272173621.issue10517@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Did anyone test this fix for case of fork() being called from Python sub interpreter?

Getting a report of fork() failing in sub interpreters under mod_wsgi that may be caused by this change. Still investigating.

Specifically throwing up error:

  Couldn't create autoTLSkey mapping

----------
nosy: +grahamd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Sat Oct  8 08:54:37 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Oct 2011 06:54:37 +0000
Subject: [issue13130] test_gdb: attempt to dereference a generic pointer
Message-ID: <1318056877.65.0.853767349869.issue13130@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The Fedora bot fails since yesterday:


Breakpoint 1, builtin_id (self=<module at remote 0x7ffff7f6fc90>, v=Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1329, in to_string
    return pyop.get_truncated_repr(MAX_OUTPUT_LEN)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 213, in get_truncated_repr
    self.write_repr(out, set())
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1199, in write_repr
    proxy = self.proxyval(visited)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1166, in proxyval
    Py_UNICODEs = [int(field_str[i]) for i in safe_range(field_length)]
RuntimeError: Attempt to dereference a generic pointer.
) at Python/bltinmodule.c:927
927	    return PyLong_FromVoidPtr(v);
#0  builtin_id (self=<module at remote 0x7ffff7f6fc90>, v=Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1329, in to_string
    return pyop.get_truncated_repr(MAX_OUTPUT_LEN)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 213, in get_truncated_repr
    self.write_repr(out, set())
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1199, in write_repr
    proxy = self.proxyval(visited)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1166, in proxyval
    Py_UNICODEs = [int(field_str[i]) for i in safe_range(field_length)]
RuntimeError: Attempt to dereference a generic pointer.
) at Python/bltinmodule.c:927
#1  0x00000000004b667f in call_function (pp_stack=0x7fffffffd6e8, oparg=1) at Python/ceval.c:3988
#2  0x00000000004b0787 in PyEval_EvalFrameEx (f=Frame 0x7ffff7f409c0, for file <string>, line 1, in <module> (), throwflag=0) at Python/ceval.c:2625
#3  0x00000000004b44ca in PyEval_EvalCodeEx (_co=<code at remote 0x7ffff7f3c880>, globals={'__builtins__': <module at remote 0x7ffff7f6fc90>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x7ffff7f6fc90>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3375
#4  0x00000000004a4668 in PyEval_EvalCode (co=<code at remote 0x7ffff7f3c880>, globals={'__builtins__': <module at remote 0x7ffff7f6fc90>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x7ffff7f6fc90>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:770
#5  0x00000000004edc20 in run_mod (mod=0x9b0560, filename=0x619622 "<string>", globals={'__builtins__': <module at remote 0x7ffff7f6fc90>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x7ffff7f6fc90>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x7fffffffe3c0, arena=0x92e070) at Python/pythonrun.c:1795
#6  0x00000000004ed91e in PyRun_StringFlags (str=0x7ffff10e1418 "id('\\U0001d121')\n", start=257, globals={'__builtins__': <module at remote 0x7ffff7f6fc90>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x7ffff7f6fc90>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x7fffffffe3c0) at Python/pythonrun.c:1729
#7  0x00000000004ebfb6 in PyRun_SimpleStringFlags (command=0x7ffff10e1418 "id('\\U0001d121')\n", flags=0x7fffffffe3c0) at Python/pythonrun.c:1302
#8  0x000000000050b41f in run_command (command=0x8e0500 L"id('\\U0001d121')\n", cf=0x7fffffffe3c0) at Modules/main.c:260
#9  0x000000000050bf70 in Py_Main (argc=4, argv=0x7ffff7faf040) at Modules/main.c:634
#10 0x0000000000416e97 in main (argc=4, argv=0x7fffffffe5a8) at ./Modules/python.c:59

----------
components: Tests
messages: 145161
nosy: haypo, loewis, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb: attempt to dereference a generic pointer
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13130>
_______________________________________

From report at bugs.python.org  Sat Oct  8 09:38:07 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Oct 2011 07:38:07 +0000
Subject: [issue13122] Out of date links in the sidebar of the documentation
	index of versions 3.1 and 3.2
In-Reply-To: <1317999740.46.0.922190010194.issue13122@psf.upfronthosting.co.za>
Message-ID: <1318059487.37.0.434394623243.issue13122@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Nobody said 3.2 was not stable...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13122>
_______________________________________

From report at bugs.python.org  Sat Oct  8 10:14:16 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 Oct 2011 08:14:16 +0000
Subject: [issue13060] allow other rounding modes in round()
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1318061656.14.0.681505704738.issue13060@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm warming to this idea.

We already have several round-to-integer functions (but not round-to-an-arbitrary-number-of-decimal-places) available in the math module (under the names floor, ceil and trunc).  This *does* seem to be a common need, and it's easy to get roll-your-own implementations wrong (e.g., check what the implementation in msg145140 does for negative numbers).  I suspect that once we get more people shifting to py3k we're going to get more complaints about round doing round-half-to-even.

Rather than expanding the signature of round, it might be worth considering a new math-module function (with name to be determined) that does round-half-up for floats.  We might later extend it to other types in the same way as is currently done for floor and ceil (with __floor__ and __ceil__ magic methods);  introduction of such magic methods would probably require a PEP though.

At issue: *which* round-half-up function do we want?  The one that rounds halfway cases away from zero (what Wikipedia calls "Round half away from zero"), or the one that rounds halfway cases towards +infinity?  I'm inclined towards the former.  I don't think it's worth implementing both.

I guess we should follow floor / ceil's lead of returning integer output for float input in the case where number of places to round to isn't given (though personally I would have been happier if floor / ceil had continued to return float output for float input, as in Python 2.x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13060>
_______________________________________

From report at bugs.python.org  Sat Oct  8 12:52:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 08 Oct 2011 10:52:21 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1318054820.67.0.179272173621.issue10517@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0MwWC6E4CqN4rYAFU9V-Lm9rYDGdKwdqyCFFadDOwrOw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Hello,

> Did anyone test this fix for case of fork() being called from Python sub interpreter?
>

Not specifically, unless it's part of the test suite.
Anyway, unless this problem is systematic - which I doubt - it
probably wouldn't have helped.

> Getting a report of fork() failing in sub interpreters under mod_wsgi that may be caused by this change. Still investigating.
>
> Specifically throwing up error:
>
> ?Couldn't create autoTLSkey mapping
>

Hmmm.
If you can, try strace or instrument the code (perror() should be
enough) to see why it's failing.
pthread_setspecific() can fail with:
- EINVAL, if the TLS key is invalid (which would be strange since we
call pthread_key_delete()/pthread_key_create() just before)
- or ENOMEM, if you run out of memory/address space

The later seems much more likely (e.g. if many child processes and
subinterpreters are created).
BTW, if this is a bug report from someone else, tell him to post here,
it'll be easier.
And we don't byte :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Sat Oct  8 12:56:56 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 08 Oct 2011 10:56:56 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1318071416.23.0.436233726362.issue10141@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Working fine on the buildbots and Vinay's box, closing!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Sat Oct  8 14:25:53 2011
From: report at bugs.python.org (Valery Khamenya)
Date: Sat, 08 Oct 2011 12:25:53 +0000
Subject: [issue13131] FD leak in urllib2
Message-ID: <1318076753.32.0.0530567720617.issue13131@psf.upfronthosting.co.za>


New submission from Valery Khamenya <khamenya at gmail.com>:

Explanation from dablitz's comment at https://bugs.pypy.org/issue867 :

<quote>
urllib2 in the stdlib leaks fd's if an exception is raised while opening a connection. The issue occurs due to a socket being opened then an exception being raised before an object with the socket is returned, leaving no way to explicitly close the object. On cpython this would not be an issue as the object would lose all references almost immediately however it lingers around with a proper GC causing FD's to build up if the same condition happens repeatedly (eg a loop/web crawling)

The file enclosed is a script to generate the leakage, to run invok it as follows <python> leak.py

pypy should start leaking FD's and can be see in /proc/<pid of leak.py>/fd

</quote>

Related issues:
http://bugs.python.org/issue3066
http://bugs.python.org/issue1208304
http://bugs.python.org/issue1601399

----------
components: IO, Library (Lib)
files: leak.py
messages: 145166
nosy: Valery.Khamenya
priority: normal
severity: normal
status: open
title: FD leak in urllib2
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file23344/leak.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13131>
_______________________________________

From report at bugs.python.org  Sat Oct  8 14:42:23 2011
From: report at bugs.python.org (Diego Mascialino)
Date: Sat, 08 Oct 2011 12:42:23 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1318019105.32.0.409360495996.issue8087@psf.upfronthosting.co.za>
Message-ID: <CAN+O6V3i0291yy59_QpvfHjwpas4O_-2vL1RSqhUHoCfGgQDwA@mail.gmail.com>


Diego Mascialino <dmascialino at gmail.com> added the comment:

On Fri, Oct 7, 2011 at 5:25 PM, Ezio Melotti <report at bugs.python.org> wrote:
>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> I'm not sure this is useful to have. ?If you changed your code you know that you have to reload, so why would you want a warning that tells you that you changed the code?

The source line showed in the traceback could not be the same line
executed.

Take a look to this example:

k.py:
def f():
    a,b,c = 1,2

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "k.py", line 2, in f
    a,b,c = 1,2
ValueError: need more than 2 values to unpack

k.py:
def f():
    # blah
    a,b = 1,2

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "k.py", line 2, in f
    # blah
ValueError: need more than 2 values to unpack

> For some reason I always had the opposite problem (i.e. after a reload the traceback was still showing the original code, and not the new one), while IIUC you are saying that it shows the new code even if the module is not reloaded.
> I tried your code and indeed it does what you say, so either I am mistaken and I've been misreading the tracebacks, or this changed from 2.6 to 2.7, or in some cases even the behavior (I think) I observed might happen.
> I'll have to verify this next time it happens.

That is strange, I think Python does not save the original code in any place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Sat Oct  8 15:03:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 08 Oct 2011 13:03:03 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1318078983.36.0.655456319723.issue8087@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> The source line showed in the traceback could not be the same line executed.

My point is that when I see an error and modify the source to fix it, then I know that I'll have to reload.  If for some reason I forget to reload, I'll get the wrong line in the traceback and then reload, but I don't think that ever happened to me.
So to me, your warning will only be useful in the case where I modified the source, forgot to reload and got the same error again with a wrong line displayed.  Also note that reloading is not so common; usually you just restart your application and that will give you the right traceback.

Also I'm not sure the warning you proposed is the best way to handle this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Sat Oct  8 15:23:21 2011
From: report at bugs.python.org (Valery Khamenya)
Date: Sat, 08 Oct 2011 13:23:21 +0000
Subject: [issue13131] FD leak in urllib2
In-Reply-To: <1318076753.32.0.0530567720617.issue13131@psf.upfronthosting.co.za>
Message-ID: <1318080201.65.0.813949394347.issue13131@psf.upfronthosting.co.za>


Valery Khamenya <khamenya at gmail.com> added the comment:

by the way, timeout parameter should be set to 0.2 as for my 13Mbit ADSL line. With 0.002 it is not reproducible for my environment

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13131>
_______________________________________

From report at bugs.python.org  Sat Oct  8 16:30:02 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 08 Oct 2011 14:30:02 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1318084202.09.0.634988790067.issue11812@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Attached patch reads the name of the server socket instead of using
> HOST or 'localhost'.

> By the way, why do we use 'localhost' instead of '127.0.0.1' for
> support.HOST? '127.0.0.1' doesn't depend on the DNS configuration of
> the host (especially its "hosts" file, even Windows has such file).

This might be a good idea.
Apparently, Windows 7 doesn't use its hosts file (yes, it does have one) to resolve 'localhost', but its DNS resolver, see http://serverfault.com/questions/4689/windows-7-localhost-name-resolution-is-handled-within-dns-itself-why

Depending on the DNS setup, it could lead to a latency which might explain such failures.

> Seems a clear race condition.

The code looks correct: a threading.Event is set by the server once it called listen(), point at which incoming connections should be queued (SYN/ACK is sent before accept()).
So I'd bet either on resolution delay (on Unix /etc/nsswitch.conf), or an overloaded machine.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Sat Oct  8 16:56:28 2011
From: report at bugs.python.org (Mitchell Hashimoto)
Date: Sat, 08 Oct 2011 14:56:28 +0000
Subject: [issue13132] distutils sends non-RFC compliant HTTP request
Message-ID: <1318085788.89.0.459164084672.issue13132@psf.upfronthosting.co.za>


New submission from Mitchell Hashimoto <xmitchx at gmail.com>:

In ``Lib/distutils/command/register.py`` as well as ``upload.py``, the following code exists to build the HTTP request body to send to the cheese shop server:

    body.write('\nContent-Disposition: form-data; name="%s"'%key)
    body.write("\n\n")

RFC2616 page 31 (http://tools.ietf.org/html/rfc2616#page-31) states that headers must be separated by CRLF. Specifically, the above "\n\n" for the header separator is causing issues with some minimal RFC-compliant web servers.

----------
assignee: tarek
components: Distutils
messages: 145171
nosy: eric.araujo, mitchellh, tarek
priority: normal
severity: normal
status: open
title: distutils sends non-RFC compliant HTTP request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13132>
_______________________________________

From report at bugs.python.org  Sat Oct  8 17:01:45 2011
From: report at bugs.python.org (Mitchell Hashimoto)
Date: Sat, 08 Oct 2011 15:01:45 +0000
Subject: [issue13132] distutils sends non-RFC compliant HTTP request
In-Reply-To: <1318085788.89.0.459164084672.issue13132@psf.upfronthosting.co.za>
Message-ID: <1318086105.0.0.81191605723.issue13132@psf.upfronthosting.co.za>


Mitchell Hashimoto <xmitchx at gmail.com> added the comment:

Patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file23345/issue13132.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13132>
_______________________________________

From report at bugs.python.org  Sat Oct  8 17:52:43 2011
From: report at bugs.python.org (Diego Mascialino)
Date: Sat, 08 Oct 2011 15:52:43 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1318078983.36.0.655456319723.issue8087@psf.upfronthosting.co.za>
Message-ID: <CAN+O6V0bwhCaY575E-wR5hd148t1uocG=ynG4O8y8o970Kj9Bw@mail.gmail.com>


Diego Mascialino <dmascialino at gmail.com> added the comment:

> So to me, your warning will only be useful in the case where I modified the source, forgot to reload and got the same error again with a wrong line displayed. Also note that reloading is not so common; usually you just restart your application and that will give you the right traceback.

I know the case when this happens is really unsusual, but the
interperter could be able to alert you than that line of the traceback
is wrong.

> Also I'm not sure the warning you proposed is the best way to handle this.

I agree that, another approach is to save a copy of the source file
associated to the compiled code (like a .pys).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Sat Oct  8 18:02:36 2011
From: report at bugs.python.org (Mike Hoy)
Date: Sat, 08 Oct 2011 16:02:36 +0000
Subject: [issue12192] Doc that collection mutation methods return item or None
In-Reply-To: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>
Message-ID: <1318089756.82.0.469510243259.issue12192@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

Created a patch based on suggestions here.

----------
keywords: +patch
Added file: http://bugs.python.org/file23346/return-none.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12192>
_______________________________________

From report at bugs.python.org  Sat Oct  8 18:21:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Oct 2011 16:21:04 +0000
Subject: [issue13130] test_gdb: attempt to dereference a generic pointer
In-Reply-To: <1318056877.65.0.853767349869.issue13130@psf.upfronthosting.co.za>
Message-ID: <1318090864.11.0.648493474468.issue13130@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Following patch seems to fix it:

diff --git a/Tools/gdb/libpython.py b/Tools/gdb/libpython.py
--- a/Tools/gdb/libpython.py
+++ b/Tools/gdb/libpython.py
@@ -1152,7 +1152,7 @@ class PyUnicodeObjectPtr(PyObjectPtr):
                     field_str = field_str.cast(_type_unsigned_char_ptr)
                 elif repr_kind == 2:
                     field_str = field_str.cast(_type_unsigned_short_ptr)
-                elif repr_kind == 3:
+                elif repr_kind == 4:
                     field_str = field_str.cast(_type_unsigned_int_ptr)
         else:
             # Python 3.2 and earlier

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13130>
_______________________________________

From report at bugs.python.org  Sat Oct  8 18:31:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 08 Oct 2011 16:31:05 +0000
Subject: [issue12192] Doc that collection mutation methods return item or None
In-Reply-To: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>
Message-ID: <E1RCZnj-0005ri-Kq@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 352d075839f7 by Georg Brandl in branch 'default':
Closes #12192: Document that mutating list methods do not return the instance (original patch by Mike Hoy).
http://hg.python.org/cpython/rev/352d075839f7

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12192>
_______________________________________

From report at bugs.python.org  Sat Oct  8 19:37:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 08 Oct 2011 17:37:05 +0000
Subject: [issue13130] test_gdb: attempt to dereference a generic pointer
In-Reply-To: <1318056877.65.0.853767349869.issue13130@psf.upfronthosting.co.za>
Message-ID: <E1RCapc-0001p4-4W@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ef1f0434c79c by Antoine Pitrou in branch 'default':
Fix test_gdb following the small unicode struct change in c25262e97304 (issue #13130)
http://hg.python.org/cpython/rev/ef1f0434c79c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13130>
_______________________________________

From report at bugs.python.org  Sat Oct  8 19:42:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Oct 2011 17:42:03 +0000
Subject: [issue13130] test_gdb: attempt to dereference a generic pointer
In-Reply-To: <1318056877.65.0.853767349869.issue13130@psf.upfronthosting.co.za>
Message-ID: <1318095723.96.0.219348403382.issue13130@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Let's wait for the buildbots.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13130>
_______________________________________

From report at bugs.python.org  Sat Oct  8 19:50:08 2011
From: report at bugs.python.org (yoch)
Date: Sat, 08 Oct 2011 17:50:08 +0000
Subject: [issue13112] backreferences in comprehensions
In-Reply-To: <1317857494.55.0.915280284739.issue13112@psf.upfronthosting.co.za>
Message-ID: <1318096208.3.0.362736648299.issue13112@psf.upfronthosting.co.za>


yoch <yoch.melka at gmail.com> added the comment:

Okay, thanks ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13112>
_______________________________________

From report at bugs.python.org  Sat Oct  8 20:21:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Oct 2011 18:21:33 +0000
Subject: [issue13130] test_gdb: attempt to dereference a generic pointer
In-Reply-To: <1318056877.65.0.853767349869.issue13130@psf.upfronthosting.co.za>
Message-ID: <1318098093.33.0.814689259965.issue13130@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Seems to have cleared the buildbot failures.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13130>
_______________________________________

From report at bugs.python.org  Sat Oct  8 20:35:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Oct 2011 18:35:55 +0000
Subject: [issue13125] test_all_project_files() expected failure
In-Reply-To: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>
Message-ID: <1318098955.58.0.484061905412.issue13125@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Could you arrange to silence stdout/stderr in non-verbose mode?

$ ./python -m test -uall test_lib2to3
[1/1] test_lib2to3
ParseError on file /home/antoine/cpython/default/Lib/lib2to3/main.py bad input: type=22, value='=', context=('', (81, 38))
ParseError on file /home/antoine/cpython/default/Lib/lib2to3/tests/pytree_idempotency.py bad input: type=22, value='=', context=('', (47, 33))
--- /home/antoine/cpython/default/Lib/lib2to3/tests/data/bom.py	2011-08-01 15:24:54.045209157 +0200
+++ @	2011-10-08 20:31:41.981242859 +0200
@@ -1,2 +1,2 @@
-?# coding: utf-8
+# coding: utf-8
 print "BOM BOOM!"
1 test OK.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13125>
_______________________________________

From report at bugs.python.org  Sat Oct  8 20:48:55 2011
From: report at bugs.python.org (Valery Khamenya)
Date: Sat, 08 Oct 2011 18:48:55 +0000
Subject: [issue13133] FD leaks in ZipFile.read(),
	ZipFile.extract() and also using explicit arc_member.close()
Message-ID: <1318099735.4.0.121973105523.issue13133@psf.upfronthosting.co.za>


New submission from Valery Khamenya <khamenya at gmail.com>:

The attached file reproduces 3 types of FD leaks and leads to the error like:

IOError: [Errno 24] Too many open files: '/tmp/1019'

For example if executed with pypy.

----------
components: IO, Library (Lib)
files: zipfiletest.py
messages: 145182
nosy: Valery.Khamenya
priority: normal
severity: normal
status: open
title: FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file23347/zipfiletest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13133>
_______________________________________

From report at bugs.python.org  Sat Oct  8 21:25:50 2011
From: report at bugs.python.org (Valery Khamenya)
Date: Sat, 08 Oct 2011 19:25:50 +0000
Subject: [issue13131] FD leak in urllib2
In-Reply-To: <1318076753.32.0.0530567720617.issue13131@psf.upfronthosting.co.za>
Message-ID: <1318101950.23.0.26550110419.issue13131@psf.upfronthosting.co.za>


Valery Khamenya <khamenya at gmail.com> added the comment:

the problem seems to be fixed with the patch attached. 
Thanks go to fijal at freenode

----------
keywords: +patch
Added file: http://bugs.python.org/file23348/urllib2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13131>
_______________________________________

From report at bugs.python.org  Sat Oct  8 21:45:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Oct 2011 19:45:18 +0000
Subject: [issue13131] FD leak in urllib2
In-Reply-To: <1318076753.32.0.0530567720617.issue13131@psf.upfronthosting.co.za>
Message-ID: <1318103118.52.0.874802744995.issue13131@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13131>
_______________________________________

From report at bugs.python.org  Sat Oct  8 21:50:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 08 Oct 2011 19:50:43 +0000
Subject: [issue13131] FD leak in urllib2
In-Reply-To: <1318076753.32.0.0530567720617.issue13131@psf.upfronthosting.co.za>
Message-ID: <1318103443.19.0.270233218229.issue13131@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Pay attention not to introduce regressions like the one in #12576 while fixing this.  I'm not sure there are similar tests for urllib2 -- if not they should be added.

----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13131>
_______________________________________

From report at bugs.python.org  Sat Oct  8 22:27:59 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 08 Oct 2011 20:27:59 +0000
Subject: [issue13133] FD leaks in ZipFile.read(),
	ZipFile.extract() and also using explicit arc_member.close()
In-Reply-To: <1318099735.4.0.121973105523.issue13133@psf.upfronthosting.co.za>
Message-ID: <1318105679.61.0.366902177897.issue13133@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I can't reproduce this problem in either 2.7.2 or 3.3.0a0.

> For example if executed with pypy.

Do you mean that this problem is only reproducible when the attached
script is run with pypy?

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13133>
_______________________________________

From report at bugs.python.org  Sat Oct  8 22:29:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Oct 2011 20:29:04 +0000
Subject: [issue13134] speed up finding of one-character strings
Message-ID: <1318105744.0.0.664183527644.issue13134@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In stringlib/fastsearch, instead of using our own loops, we can use memchr() (and, if available, memrchr()) when looking for one-character strings. memchr() is generally quite optimized; on this Linux/glibc machine, I get speedups of 5x-10x:

./python -m timeit -s "large='a'*10000+'b'" "large.find('b')"
-> before: 10.5 usec per loop
-> after: 0.889 usec per loop

./python -m timeit -s "large='b'+'a'*10000" "large.rfind('b')"
-> before: 7.06 usec per loop
-> after: 1.94 usec per loop

----------
components: Interpreter Core
messages: 145186
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: speed up finding of one-character strings
type: performance
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Sat Oct  8 22:29:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Oct 2011 20:29:12 +0000
Subject: [issue13134] speed up finding of one-character strings
In-Reply-To: <1318105744.0.0.664183527644.issue13134@psf.upfronthosting.co.za>
Message-ID: <1318105752.09.0.488375132644.issue13134@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23349/memchr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Sat Oct  8 22:39:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Oct 2011 20:39:46 +0000
Subject: [issue13134] speed up finding of one-character strings
In-Reply-To: <1318105744.0.0.664183527644.issue13134@psf.upfronthosting.co.za>
Message-ID: <1318106386.57.0.632909472053.issue13134@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

With MSVC there seems to be no difference, meaning Windows probably has a na?ve memchr() implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Sat Oct  8 22:44:28 2011
From: report at bugs.python.org (Valery Khamenya)
Date: Sat, 08 Oct 2011 20:44:28 +0000
Subject: [issue13133] FD leaks in ZipFile.read(),
	ZipFile.extract() and also using explicit arc_member.close()
In-Reply-To: <1318099735.4.0.121973105523.issue13133@psf.upfronthosting.co.za>
Message-ID: <1318106668.61.0.0566865542036.issue13133@psf.upfronthosting.co.za>


Valery Khamenya <khamenya at gmail.com> added the comment:

"I can't reproduce this problem in either 2.7.2 or 3.3.0a0."

You probably mean CPython implementation of Python. No, I didn't mean this implementation.

"Do you mean that this problem is only reproducible when the attached
script is run with pypy?"

I can't say "only". I just could say yes, it is reproducible with pypy. Perhaps, there are others Python implementations that will suffer from the bug in current implementation of ZipFile

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13133>
_______________________________________

From report at bugs.python.org  Sat Oct  8 22:55:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Oct 2011 20:55:11 +0000
Subject: [issue13134] speed up finding of one-character strings
In-Reply-To: <1318105744.0.0.664183527644.issue13134@psf.upfronthosting.co.za>
Message-ID: <1318107311.61.0.209878504681.issue13134@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch with a couple of tests.

----------
Added file: http://bugs.python.org/file23350/memchr2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Sat Oct  8 23:53:39 2011
From: report at bugs.python.org (Marty Alchin)
Date: Sat, 08 Oct 2011 21:53:39 +0000
Subject: [issue13135] Using type() as a constructor doesn't support new class
	keyword arguments
Message-ID: <1318110818.93.0.631665925826.issue13135@psf.upfronthosting.co.za>


New submission from Marty Alchin <marty at martyalchin.com>:

PEP 3115 introduced keyword arguments to class definitions and changed metaclasses to use them instead. Unfortunately, `type()` doesn't seem to have been updated to accept those keyword arguments as well. What this amounts to is that using `type()` as a constructor can no longer fully replicate the behavior of a class definition. Therefore, classes that use keyword arguments can't be created dynamically.

I would attempt a patch, but I don't have a development environment capable of compiling Python, so I wouldn't have any chance to test it.

----------
messages: 145190
nosy: gulopine
priority: normal
severity: normal
status: open
title: Using type() as a constructor doesn't support new class keyword arguments
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13135>
_______________________________________

From report at bugs.python.org  Sat Oct  8 23:58:43 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 08 Oct 2011 21:58:43 +0000
Subject: [issue13133] FD leaks in ZipFile.read(),
	ZipFile.extract() and also using explicit arc_member.close()
In-Reply-To: <1318099735.4.0.121973105523.issue13133@psf.upfronthosting.co.za>
Message-ID: <1318111123.36.0.0967907405063.issue13133@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, in 2.7 many parts of the stdlib relies on reference counting to close files.  But 3.2 introduced a ResourceWarning which is emitted (in debug mode) each time a __del__ closes a valuable resource like a file or a socket.  This was done exactly for this reason - help other implementations with a different garbage collector.

Now Lib/zipfile.py is probably much more gc-friendly: see how it uses a new member "close_fileobj", and the "with" statement in ZipFile.read().

PyPy will benefit of this when it migrates to 3.2; meanwhile, you could apply the same changes in pypy's own copy of zipfile.py.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13133>
_______________________________________

From report at bugs.python.org  Sun Oct  9 00:18:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Oct 2011 22:18:31 +0000
Subject: [issue13136] speed-up conversion between unicode widths
Message-ID: <1318112311.49.0.66949742663.issue13136@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop.

Example micro-benchmark:

./python -m timeit -s "a='x'*10000;b='\u0102'*1000;c='\U00100000'" "a+b+c"

-> before:
100000 loops, best of 3: 14.9 usec per loop
-> after:
100000 loops, best of 3: 9.19 usec per loop

----------
components: Interpreter Core
files: unroll_convert_bytes.patch
keywords: patch
messages: 145192
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: speed-up conversion between unicode widths
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file23351/unroll_convert_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13136>
_______________________________________

From report at bugs.python.org  Sun Oct  9 00:29:13 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 08 Oct 2011 22:29:13 +0000
Subject: [issue13136] speed-up conversion between unicode widths
In-Reply-To: <1318112311.49.0.66949742663.issue13136@psf.upfronthosting.co.za>
Message-ID: <4E90CEAE.9020702@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> New submission from Antoine Pitrou <pitrou at free.fr>:
> 
> This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop.
> 
> Example micro-benchmark:
> 
> ./python -m timeit -s "a='x'*10000;b='\u0102'*1000;c='\U00100000'" "a+b+c"
> 
> -> before:
> 100000 loops, best of 3: 14.9 usec per loop
> -> after:
> 100000 loops, best of 3: 9.19 usec per loop

Before going further with this, I'd suggest you have a look at your
compiler settings. Such optimizations are normally performed by the
compiler and don't need to be implemented in C, making maintenance
harder.

The fact that Windows doesn't exhibit the same performance difference
suggests that the optimizer is not using the same level or feature
set as on Linux. MSVC is at least as good at optimizing code as gcc,
often better.

I tested using memchr() when writing those "naive" loops. It turned
out that using memchr() was slower than using the direct loops. memchr()
is inlined by the compiler just like the direct loop and the generated
code for the direct version is often easier to optimize for the compiler
than the memchr() one, since it receives more knowledge about the used
data types.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13136>
_______________________________________

From report at bugs.python.org  Sun Oct  9 00:34:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Oct 2011 22:34:51 +0000
Subject: [issue13136] speed-up conversion between unicode widths
In-Reply-To: <4E90CEAE.9020702@egenix.com>
Message-ID: <1318113072.9190.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Before going further with this, I'd suggest you have a look at your
> compiler settings.

They are set by the configure script:

gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o
Objects/unicodeobject.o Objects/unicodeobject.c

> Such optimizations are normally performed by the
> compiler and don't need to be implemented in C, making maintenance
> harder.

The fact that the glibc includes such optimization (in much more
sophisticated form) suggests to me that many compilers don't perform
these optimizations automically.

> I tested using memchr() when writing those "naive" loops.

memchr() is mentioned in another issue, #13134.

> memchr()
> is inlined by the compiler just like the direct loop

I don't think so. If you look at the glibc's memchr() implementation,
it's a sophisticated routine, not a trivial loop. Perhaps you're
thinking about memcpy().

> and the generated
> code for the direct version is often easier to optimize for the compiler
> than the memchr() one, since it receives more knowledge about the used
> data types.

?? Data types are fixed in the memchr() definition, there's no knowledge
to be gained by inlining.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13136>
_______________________________________

From report at bugs.python.org  Sun Oct  9 00:58:37 2011
From: report at bugs.python.org (Blair)
Date: Sat, 08 Oct 2011 22:58:37 +0000
Subject: [issue13137] from __future__ import division breaks ad hoc numeric
	types
Message-ID: <1318114717.45.0.0615506676272.issue13137@psf.upfronthosting.co.za>


New submission from Blair <bidihall at gmail.com>:

I believe that the use of __future__.division may have unintended consequences with user types that define division.

The following fails:

	from __future__ import division

	class NumericType(object):
		def __init__(self,x):
			self.x = x

		def __div__(self,rhs):
			return self.x/rhs

	print NumericType(3.0) / 2.0

with the error message

  File "C:\proj_py\learning\future_bug\future.py", line 10, in <module>
    print NumericType(3.0) / 2.0
TypeError: unsupported operand type(s) for /: 'NumericType' and 'float'

Remove the line `from __future__ import division` and everything works fine.

I am using Python 2.7.2

----------
components: None
messages: 145195
nosy: gumtree
priority: normal
severity: normal
status: open
title: from __future__ import division breaks ad hoc numeric types
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13137>
_______________________________________

From report at bugs.python.org  Sun Oct  9 01:18:00 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 Oct 2011 23:18:00 +0000
Subject: [issue13137] from __future__ import division breaks ad hoc numeric
	types
In-Reply-To: <1318114717.45.0.0615506676272.issue13137@psf.upfronthosting.co.za>
Message-ID: <1318115880.73.0.563523378893.issue13137@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You have to implement __truediv__.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13137>
_______________________________________

From report at bugs.python.org  Sun Oct  9 01:37:02 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 Oct 2011 23:37:02 +0000
Subject: [issue13135] Using type() as a constructor doesn't support new class
	keyword arguments
In-Reply-To: <1318110818.93.0.631665925826.issue13135@psf.upfronthosting.co.za>
Message-ID: <1318117022.22.0.82717111279.issue13135@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

That's not true. You simply call the metaclass itself.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13135>
_______________________________________

From report at bugs.python.org  Sun Oct  9 01:57:28 2011
From: report at bugs.python.org (Marty Alchin)
Date: Sat, 08 Oct 2011 23:57:28 +0000
Subject: [issue13135] Using type() as a constructor doesn't support new class
	keyword arguments
In-Reply-To: <1318110818.93.0.631665925826.issue13135@psf.upfronthosting.co.za>
Message-ID: <1318118248.2.0.511579017523.issue13135@psf.upfronthosting.co.za>


Marty Alchin <marty at martyalchin.com> added the comment:

Hrm, that does seem to satisfy the case I was immediately concerned with, but I was thinking there was another issue with it, but now I'm having trouble pinning down an example. I'll just assume I was getting ahead of myself. Thanks for the sanity lesson.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13135>
_______________________________________

From report at bugs.python.org  Sun Oct  9 02:49:33 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 09 Oct 2011 00:49:33 +0000
Subject: [issue13138] ElementTree's Element.iter() lacks versionadded
Message-ID: <1318121372.98.0.459756814836.issue13138@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

See http://docs.python.org/whatsnew/2.7.html#updated-module-elementtree-1-3

----------
assignee: docs at python
components: Documentation
files: Element_iter_versionadded.patch
keywords: patch
messages: 145199
nosy: Trundle, docs at python
priority: normal
severity: normal
status: open
title: ElementTree's Element.iter() lacks versionadded
versions: Python 2.7
Added file: http://bugs.python.org/file23352/Element_iter_versionadded.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13138>
_______________________________________

From report at bugs.python.org  Sun Oct  9 02:49:52 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 09 Oct 2011 00:49:52 +0000
Subject: [issue13136] speed-up conversion between unicode widths
In-Reply-To: <1318113072.9190.14.camel@localhost.localdomain>
Message-ID: <CAK1QoooEzxnQhFdWnK0YHSNf9mzFTJok-vb4G2=NqHD4rbvhJQ@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Sat, Oct 8, 2011 at 5:34 PM, Antoine Pitrou <report at bugs.python.org> wrote:

> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> Before going further with this, I'd suggest you have a look at your
>> compiler settings.
>
> They are set by the configure script:
>
> gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall
> -Wstrict-prototypes ? ?-I. -I./Include ? ?-DPy_BUILD_CORE -o
> Objects/unicodeobject.o Objects/unicodeobject.c
>
>> Such optimizations are normally performed by the
>> compiler and don't need to be implemented in C, making maintenance
>> harder.
>
> The fact that the glibc includes such optimization (in much more
> sophisticated form) suggests to me that many compilers don't perform
> these optimizations automically.

I agree.  This is more of an optimized runtime library problem than
code optimization problem.

>> I tested using memchr() when writing those "naive" loops.
>
> memchr() is mentioned in another issue, #13134.

Yeah, this conversation is really more relevant to issue13134, but I will
reply to these here anyway ....

>> memchr()
>> is inlined by the compiler just like the direct loop
>
> I don't think so. If you look at the glibc's memchr() implementation,
> it's a sophisticated routine, not a trivial loop. Perhaps you're
> thinking about memcpy().

Without link-time optimization enabled, I doubt the toolchain can
"inline" 'memchr'
in the traditional sense (i.e. inserting the body of the routine
inline).  Even if it could,
the inline heuristics would most likely choose not to.  I don't think we use LTO
with GCC, but I think we might with VC++.

GCC does something else called builtin folding that is more likely.
For example,
'memchr ("bca", 'c', 3)' gets replace with instructions to compute a pointer
index into "bca".  This won't happen in this case because all of the 'memchr'
arguments are all variable.

>> and the generated
>> code for the direct version is often easier to optimize for the compiler
>> than the memchr() one, since it receives more knowledge about the used
>> data types.
>
> ?? Data types are fixed in the memchr() definition, there's no knowledge
> to be gained by inlining.

I think what Marc-Andre is alluding to is that the first parameter of
'memchr' is 'void *'
which could (in theory) limit optimization opportunities.  Where as if
it knew that
the data being searched is a 'char *' or something it could take
advantage of that.

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13136>
_______________________________________

From report at bugs.python.org  Sun Oct  9 03:54:44 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 09 Oct 2011 01:54:44 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1318125284.49.0.357892667962.issue10399@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Sun Oct  9 04:05:47 2011
From: report at bugs.python.org (Daniel Wagner-Hall)
Date: Sun, 09 Oct 2011 02:05:47 +0000
Subject: [issue13139] multiprocessing.map skips finally blocks
Message-ID: <1318125947.15.0.13973515193.issue13139@psf.upfronthosting.co.za>


New submission from Daniel Wagner-Hall <dawagner at gmail.com>:

import random

from multiprocessing import Pool
from time import sleep

def Process(x):
  try:
    print x
    sleep(random.random())
    raise Exception('Exception: ' + x)
  finally:
    print 'Finally: ' + x

Pool(3).map(Process, ['1','2','3'])

Expect all three Finally blocks to be called (or at least, one Finally per x printed by line 8)

Actually, only one (occasionally two) are printed.

Same behaviour exhibited on dual-core Mac running OSX 10.6 with Python 2.7, and single core Ubuntu running Python 2.6.

----------
components: None
messages: 145201
nosy: illicitonion
priority: normal
severity: normal
status: open
title: multiprocessing.map skips finally blocks
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13139>
_______________________________________

From report at bugs.python.org  Sun Oct  9 05:01:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 03:01:53 +0000
Subject: [issue13132] distutils sends non-RFC compliant HTTP request
In-Reply-To: <1318085788.89.0.459164084672.issue13132@psf.upfronthosting.co.za>
Message-ID: <1318129313.81.0.412913234361.issue13132@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Mitchell, thanks for your interest in Python.  Using CLRF was requested before (#10510) and rejected on the ground that the RFC (at least for HTTP 1.0) allows LF.  CRLF is preferred but not required.  Hence, we deem it is not a bug.

The register, upload and upload_docs commands in distutils2 do use CRLF.

BTW, I think your patch was incomplete: You stripped one newline, replaced one LF with CRLF, and left many other LFs.

----------
assignee: tarek -> eric.araujo
nosy: +orsenthil
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13132>
_______________________________________

From report at bugs.python.org  Sun Oct  9 05:03:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 03:03:10 +0000
Subject: [issue12533] python-celementtree prevents me from running python
	develop.py to compile Imprudence Viewer
In-Reply-To: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>
Message-ID: <1318129390.27.0.754411819376.issue12533@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Closing, please reopen if there is more info.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: pending -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12533>
_______________________________________

From report at bugs.python.org  Sun Oct  9 05:04:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 03:04:22 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1318129462.61.0.552227444823.issue12967@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I stand by my opinion that running setup.py from IDLE is not supported.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12967>
_______________________________________

From report at bugs.python.org  Sun Oct  9 05:06:10 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 09 Oct 2011 03:06:10 +0000
Subject: [issue13136] speed-up conversion between unicode widths
In-Reply-To: <1318112311.49.0.66949742663.issue13136@psf.upfronthosting.co.za>
Message-ID: <1318129570.86.0.821593112149.issue13136@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Marc-Andre: gcc will normally not unroll loops, unless -funroll-loops is given on the command line. Then, it will unroll many loops, and do so with 8 iterations per outer loop. This typically causes significant code bloat, which is why unrolling is normally disabled and left to the programmer.

For those who want to experiment with this, I attach a C file with just the code in question. Compile this with your favorite compiler settings, and see what the compile generates. clang, on an x64 system, compiles the original loop into


LBB0_2:                                 ## =>This Inner Loop Header: Depth=1
        movzbl  (%rdi), %eax
        movw    %ax, (%rdx)
        incq    %rdi
        addq    $2, %rdx
        decq    %rsi
        jne     LBB0_2

and the unrolled loop into

LBB1_2:                                 ## %.lr.ph6
                                        ## =>This Inner Loop Header: Depth=1
        movzbl  (%rdi,%rcx), %r8d
        movw    %r8w, (%rdx)
        movzbl  1(%rdi,%rcx), %r8d
        movw    %r8w, 2(%rdx)
        movzbl  2(%rdi,%rcx), %r8d
        movw    %r8w, 4(%rdx)
        movzbl  3(%rdi,%rcx), %r8d
        movw    %r8w, 6(%rdx)
        addq    $8, %rdx
        addq    $4, %rcx
        cmpq    %rax, %rcx
        jl      LBB1_2

----------
nosy: +loewis
Added file: http://bugs.python.org/file23353/unroll.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13136>
_______________________________________

From report at bugs.python.org  Sun Oct  9 05:15:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 03:15:32 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1318130132.42.0.0203529835432.issue7833@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Note the existing test doesn't actually perform a build so the new
> test also doesn't, but it does check the core logic
Sounds good to me.

+    def manifest_setup_ldargs
I?d make all new methods private ones (i.e. leading underscore).

> an embedded manifests
Typo: extra s

> return None if not temp_manifest else (temp_manifest, mfid)
Using a ternary expression runs afoul of PEP 291: distutils should remain compatible with 2.3.  (I?m not sure it is right now, we use modern unittest methods in tests and all, but it is no reason for making it worse in new code :)

Your patch will also need an entry in Misc/NEWS; at first glance, there is no documentation file to edit.

Will you port the patch to packaging in 3.3?  I can do it if you don?t have the time, but I?m not set up yet to test on Windows, so I can ask you to test a patch.  Also, for the distutils2 backport (which I can do too), we would need to run tests with all versions from 2.4 to 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Sun Oct  9 05:19:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 03:19:52 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1318130392.99.0.0037175845756.issue12436@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> In addition to Notepad++ do you think it would be a good idea to at
> least mention Vim and Emacs with a disclaimer about the learning
> curve?
No.  If someone is looking at this page and doesn?t already have a text editor they?re familiar with, I think Notepad++ is the right tool to suggest.

> Do you think it would be a good idea to add instructions on how to add Python
> to the Path in Windows?
The doc already has that somewhere, unless I misremember.

> Yes, but isn't there a script somewhere that does that already?
One or more in Tools/scripts and maybe in PC or PCbuild too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Sun Oct  9 05:21:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 03:21:21 +0000
Subject: [issue13123] bdist_wininst uninstaller does not remove pycache
	directories
In-Reply-To: <1318000960.21.0.140069466315.issue13123@psf.upfronthosting.co.za>
Message-ID: <1318130481.66.0.23398355336.issue13123@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t have a Windows VM set up yet, but I can try to write a patch in the coming weeks and ask you to test it.  Deal?

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13123>
_______________________________________

From report at bugs.python.org  Sun Oct  9 05:44:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 03:44:22 +0000
Subject: [issue3902] Packages containing only extension modules have to
	contain __init__.py
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1318131862.64.0.614529033789.issue3902@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> We?re working on a patch on the core-mentorship list.
> I emailed the diff to the Core-Mentorship list, but since there
> was no reply I will just attach it here.
I added that message here to avoid someone else working on the same bug.  I did not reply to the mailing list because it?s not easy to review emailed patches and I don?t have Internet access each day.

> Please review patch and let me know if you want any changes.
Done.  You should have received an email; if not, follow the link titled ?review? on the right of your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Sun Oct  9 06:12:06 2011
From: report at bugs.python.org (Mark Hammond)
Date: Sun, 09 Oct 2011 04:12:06 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1318133526.32.0.289857179665.issue7833@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

Thanks for the review.  One note:

| +    def manifest_setup_ldargs
| I?d make all new methods private ones (i.e. leading underscore).

They aren't strictly private and are designed to be overridden by subclasses (although in practice, subclassing the compiler is much harder than it should be, so pywin32 monkey-patches the instance.)  This is actually the entire point of my updated patch - to give setup.py authors some level of control over the manifest behaviour.

I do intend forward-porting to 3.3 and also to check it is is too late for 3.2 (a quick check before implied it might be OK, but I'm not sure)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Sun Oct  9 06:16:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 04:16:15 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1318133775.92.0.948664691464.issue7833@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> They aren't strictly private and are designed to be overridden by
> subclasses
OK.

> I do intend forward-porting to 3.3 and also to check it is is too late
> for 3.2 (a quick check before implied it might be OK, but I'm not sure)
2.7 and 3.2 are open for bug fixes, as indicated by the versions field of this bug (it?s actually a matrix: component distutils + versions 2.7, 3.2, 3.3, component distutils2 + version 3.3 == packaging and distutils2 + third-party == the distutils2 backport :)

----------
assignee: tarek -> mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Sun Oct  9 06:47:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 04:47:39 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1318135659.81.0.372304804625.issue6164@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This was fixed in 2.7 and 3.2; no luck for 3.1.

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Sun Oct  9 06:52:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 04:52:28 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1295450896.02.0.86964827296.issue10945@psf.upfronthosting.co.za>
Message-ID: <1318135948.23.0.822480008916.issue10945@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

haypo:
> Can't you only work with Unicode and avoid the MBCS encoding?
It is not code under the users? control (i.e. setup.py) that uses MBCS, but the bdist_wininst command itself.  It used to be runnable from linux, which is great to provide binary installers for Windows users who typically don?t have a compiler.  This is what the bug is about.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Sun Oct  9 06:55:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 04:55:44 +0000
Subject: [issue11638] pysetup un sdist crashes with weird trace if version is
	unicode by accident
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1318136144.93.0.397398258713.issue11638@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does someone want to write a test for this?  We have examples of creating tarball sdists in Lib/distutils/tests/test_sdist.py, one would just need to copy one example and use a version with a unicode version.

----------
keywords: +easy
resolution: remind -> 
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Sun Oct  9 07:06:54 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 09 Oct 2011 05:06:54 +0000
Subject: [issue12967] IDLE RPC Proxy for standard IO streams lacks 'errors'
	attribute
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1318136814.62.0.527647778006.issue12967@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I don't have a strong opinion about whether running setup.py in IDLE is supported.  But that's not the real issue here.  The problem is that the IDLE RPC proxy of the standard IO streams is incomplete, in particular, the 'errors' attribute of io.TextIOWrapper streams.  Looking back, it appears that the `errors` attribute was added to file objects and io streams in 2.6 but support for that was not added to IDLE.  I think that should be fixed.

----------
assignee: eric.araujo -> ned.deily
components: +IDLE -Distutils
resolution: wont fix -> 
stage: committed/rejected -> needs patch
status: closed -> open
title: AttributeError distutils\log.py -> IDLE RPC Proxy for standard IO streams lacks 'errors' attribute
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12967>
_______________________________________

From report at bugs.python.org  Sun Oct  9 07:08:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 05:08:10 +0000
Subject: [issue12967] IDLE RPC Proxy for standard IO streams lacks 'errors'
	attribute
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1318136890.58.0.368454569093.issue12967@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy:  -eric.araujo, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12967>
_______________________________________

From report at bugs.python.org  Sun Oct  9 08:59:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 06:59:47 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <E1RCnMQ-0001rR-2D@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fe0972e102cd by ?ric Araujo in branch '3.2':
Make C code in one distutils test comply with ISO C (#10359).
http://hg.python.org/cpython/rev/fe0972e102cd

New changeset 9ded1f21f0fd by ?ric Araujo in branch 'default':
Make C code in one packaging test comply with ISO C (#10359).
http://hg.python.org/cpython/rev/9ded1f21f0fd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Sun Oct  9 08:59:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 06:59:47 +0000
Subject: [issue10526] Minor typo in What's New in Python 2.7
In-Reply-To: <1290681942.88.0.460201126168.issue10526@psf.upfronthosting.co.za>
Message-ID: <E1RCnMQ-0001rR-1V@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c52bac35b498 by ?ric Araujo in branch 'default':
Merge fixes for #10526, #10359, #11254, #9100 and the bug without number
http://hg.python.org/cpython/rev/c52bac35b498

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10526>
_______________________________________

From report at bugs.python.org  Sun Oct  9 08:59:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 06:59:49 +0000
Subject: [issue11171] Python 2.7.1 does not start when "./configure" is used
	with "--prefix" != "--exec-prefix"
In-Reply-To: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>
Message-ID: <E1RCnMQ-0001rR-1d@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6542e4028ed2 by ?ric Araujo in branch '3.2':
As it turns out, this bug was already in the tracker: #11171
http://hg.python.org/cpython/rev/6542e4028ed2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11171>
_______________________________________

From report at bugs.python.org  Sun Oct  9 08:59:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 06:59:49 +0000
Subject: [issue10536] Enhancements to gettext docs
In-Reply-To: <1290730924.88.0.289473332428.issue10536@psf.upfronthosting.co.za>
Message-ID: <E1RCnMQ-0001rR-1z@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e48e6e9bdef6 by ?ric Araujo in branch '3.2':
Fix a typo and a broken link (part of #10536).
http://hg.python.org/cpython/rev/e48e6e9bdef6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10536>
_______________________________________

From report at bugs.python.org  Sun Oct  9 08:59:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 06:59:50 +0000
Subject: [issue13114] check -r fails with non-ASCII unicode long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <E1RCnMQ-0001rR-2T@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e16792003597 by ?ric Araujo in branch '3.2':
Add tests for Unicode handling in distutils? check and register (#13114)
http://hg.python.org/cpython/rev/e16792003597

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Sun Oct  9 08:59:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 06:59:50 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <E1RCnMQ-0001rR-25@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 27a36b05caed by ?ric Araujo in branch '3.2':
Fix distutils byte-compilation to comply with PEP 3147 (#11254).
http://hg.python.org/cpython/rev/27a36b05caed

New changeset 651e84363001 by ?ric Araujo in branch '3.2':
Fix docstring of distutils.util.byte_compile (followup for #11254)
http://hg.python.org/cpython/rev/651e84363001

New changeset 439f47fadffa by ?ric Araujo in branch 'default':
Fix packaging byte-compilation to comply with PEP 3147 (#11254).
http://hg.python.org/cpython/rev/439f47fadffa

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Sun Oct  9 08:59:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 06:59:51 +0000
Subject: [issue9100] test_sysconfig fails (test_user_similar)
In-Reply-To: <1277731663.45.0.56366593786.issue9100@psf.upfronthosting.co.za>
Message-ID: <E1RCnMQ-0001rR-2J@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1f8aef75558c by ?ric Araujo in branch '3.2':
Fix test_sysconfig when prefix != exec-prefix (#9100).
http://hg.python.org/cpython/rev/1f8aef75558c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9100>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:00:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 07:00:13 +0000
Subject: [issue9100] test_sysconfig fails (test_user_similar)
In-Reply-To: <1277731663.45.0.56366593786.issue9100@psf.upfronthosting.co.za>
Message-ID: <E1RCnMo-00024d-J3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 27045f93e4cb by ?ric Araujo in branch '2.7':
Fix test_sysconfig when prefix != exec-prefix (#9100).
http://hg.python.org/cpython/rev/27045f93e4cb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9100>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:00:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 07:00:13 +0000
Subject: [issue13114] check -r fails with non-ASCII unicode long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <E1RCnMo-00024d-Jg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8d837bd8148a by ?ric Araujo in branch '2.7':
Fix distutils? check and register Unicode handling (#13114).
http://hg.python.org/cpython/rev/8d837bd8148a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:00:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 07:00:17 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <E1RCnMo-00024d-JF@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 134b68cae802 by ?ric Araujo in branch '2.7':
Make C code in one distutils test comply with ISO C (#10359).
http://hg.python.org/cpython/rev/134b68cae802

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:00:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 07:00:17 +0000
Subject: [issue10536] Enhancements to gettext docs
In-Reply-To: <1290730924.88.0.289473332428.issue10536@psf.upfronthosting.co.za>
Message-ID: <E1RCnMo-00024d-JU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1e48a2b484a3 by ?ric Araujo in branch '2.7':
Fix a typo and a broken link (part of #10536).
http://hg.python.org/cpython/rev/1e48a2b484a3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10536>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:16:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 07:16:56 +0000
Subject: [issue11171] Python 2.7.1 does not start when "./configure" is used
	with "--prefix" != "--exec-prefix"
In-Reply-To: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>
Message-ID: <1318144616.76.0.90549306331.issue11171@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> My question was: does distutils.sysconfig._get_makefile_filename have
> the same bug as the one that was fixed in sysconfig._get_makefile_filename?

It does, I fixed it in 9afd3d54c3cb.

----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11171>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:19:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 07:19:55 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <1318144795.26.0.955286279274.issue11254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Finally fixed.  I fail at boolean logic; removing the ?dance around imp.cache_from_source that seemed unnecessary? as I called it was a mistake, we have to do it, so I restored that part of your original patch.  I?m sorry I took so long to fix this, it was straightforward.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:26:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 07:26:27 +0000
Subject: [issue9100] test_sysconfig fails (test_user_similar)
In-Reply-To: <1277731663.45.0.56366593786.issue9100@psf.upfronthosting.co.za>
Message-ID: <1318145187.47.0.318954146909.issue9100@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Now fixed.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9100>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:27:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 07:27:08 +0000
Subject: [issue13114] check -r fails with non-ASCII unicode long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <1318145228.16.0.741376324355.issue13114@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed, thanks again!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:30:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 07:30:29 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1318145429.63.0.65174237897.issue13086@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 ;)

----------
nosy: +eric.araujo
title: Update howto/cporting.rst so it talks about 3.x instead of 3.0 -> Update howto/cporting.rst so it talks about Python 3 instead of 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:36:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 07:36:32 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
Message-ID: <1318145792.23.0.158284776544.issue6983@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This patch was a short-term fix.  Distutils is closed to anything but bug fixes and distutils2 can get a better fix.  Objections if I close this?

----------
components: +Distutils -Distutils2, Library (Lib)
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:40:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 07:40:05 +0000
Subject: [issue12427] packaging register fails because "POST data should be
	bytes"
In-Reply-To: <1309252450.32.0.523517261738.issue12427@psf.upfronthosting.co.za>
Message-ID: <1318146005.11.0.772931070095.issue12427@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can?t reproduce.

----------
assignee: tarek -> eric.araujo
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12427>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:44:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 07:44:01 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318146241.94.0.204924395915.issue12405@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> IMO in this situation, a and b were created by the installation and so
> should be removed, unless they contain files not added during installation.

I share that opinion.  So, the first step would be to record created directories.  We could extend PEP 376 and write entries without hash nor length record for directories in RECORD, or use another file in the dist-info dir.

----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Sun Oct  9 09:44:59 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 09 Oct 2011 07:44:59 +0000
Subject: [issue13123] bdist_wininst uninstaller does not remove pycache
	directories
In-Reply-To: <1318130481.66.0.23398355336.issue13123@psf.upfronthosting.co.za>
Message-ID: <CACac1F9o9rijXb_VKPHyYdTq2--MyGDsfpzJHJN+U+RSBBTqXg@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

On 9 October 2011 04:21, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> I don?t have a Windows VM set up yet, but I can try to write a patch in the coming weeks and ask you to test it. ?Deal?

No problem there!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13123>
_______________________________________

From report at bugs.python.org  Sun Oct  9 10:00:01 2011
From: report at bugs.python.org (Stef Walter)
Date: Sun, 09 Oct 2011 08:00:01 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
Message-ID: <1318147201.09.0.445870614207.issue6983@psf.upfronthosting.co.za>


Stef Walter <stef at memberwebs.com> added the comment:

Shrug. I guess you can close it.

This is still a bothersome issue, but we've taken to patching every version of python downstream before deploying them. All for a simple three line patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Sun Oct  9 10:07:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 08:07:58 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1318147678.41.0.830824380963.issue12386@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d like to fix this.  How can I reproduce the bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Sun Oct  9 10:36:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 08:36:59 +0000
Subject: [issue1109658] distutils dry-run breaks when attempting to bytecompile
Message-ID: <1318149419.16.0.666096209463.issue1109658@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Martin]
> Looking at the code, I find it unfortunate that it uses os.path.exists,
> causing a stat call, and then does another stat call to find the time stamp.

Are you noting the inefficiency of doing two stat calls instead of one, or saying that it should make none at all in dry-run mode?  My opinion is that a dry-run mode should not create any file nor make any changes, but reading files and calling processes that give info is fair game.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1109658>
_______________________________________

From meadori at gmail.com  Sun Oct  9 02:49:48 2011
From: meadori at gmail.com (Meador Inge)
Date: Sat, 8 Oct 2011 19:49:48 -0500
Subject: [issue13136] speed-up conversion between unicode widths
In-Reply-To: <1318113072.9190.14.camel@localhost.localdomain>
References: <4E90CEAE.9020702@egenix.com>
	<1318113072.9190.14.camel@localhost.localdomain>
Message-ID: <CAK1QoooEzxnQhFdWnK0YHSNf9mzFTJok-vb4G2=NqHD4rbvhJQ@mail.gmail.com>

On Sat, Oct 8, 2011 at 5:34 PM, Antoine Pitrou <report at bugs.python.org> wrote:

> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> Before going further with this, I'd suggest you have a look at your
>> compiler settings.
>
> They are set by the configure script:
>
> gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall
> -Wstrict-prototypes ? ?-I. -I./Include ? ?-DPy_BUILD_CORE -o
> Objects/unicodeobject.o Objects/unicodeobject.c
>
>> Such optimizations are normally performed by the
>> compiler and don't need to be implemented in C, making maintenance
>> harder.
>
> The fact that the glibc includes such optimization (in much more
> sophisticated form) suggests to me that many compilers don't perform
> these optimizations automically.

I agree.  This is more of an optimized runtime library problem than
code optimization problem.

>> I tested using memchr() when writing those "naive" loops.
>
> memchr() is mentioned in another issue, #13134.

Yeah, this conversation is really more relevant to issue13134, but I will
reply to these here anyway ....

>> memchr()
>> is inlined by the compiler just like the direct loop
>
> I don't think so. If you look at the glibc's memchr() implementation,
> it's a sophisticated routine, not a trivial loop. Perhaps you're
> thinking about memcpy().

Without link-time optimization enabled, I doubt the toolchain can
"inline" 'memchr'
in the traditional sense (i.e. inserting the body of the routine
inline).  Even if it could,
the inline heuristics would most likely choose not to.  I don't think we use LTO
with GCC, but I think we might with VC++.

GCC does something else called builtin folding that is more likely.
For example,
'memchr ("bca", 'c', 3)' gets replace with instructions to compute a pointer
index into "bca".  This won't happen in this case because all of the 'memchr'
arguments are all variable.

>> and the generated
>> code for the direct version is often easier to optimize for the compiler
>> than the memchr() one, since it receives more knowledge about the used
>> data types.
>
> ?? Data types are fixed in the memchr() definition, there's no knowledge
> to be gained by inlining.

I think what Marc-Andre is alluding to is that the first parameter of
'memchr' is 'void *'
which could (in theory) limit optimization opportunities.  Where as if
it knew that
the data being searched is a 'char *' or something it could take
advantage of that.

From report at bugs.python.org  Sun Oct  9 10:48:07 2011
From: report at bugs.python.org (lekma)
Date: Sun, 09 Oct 2011 08:48:07 +0000
Subject: [issue7330] PyUnicode_FromFormat: implement width and precision for
	%s, %S, %R, %V, %U, %A
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1318150087.28.0.546899604078.issue7330@psf.upfronthosting.co.za>


Changes by lekma <lekmalek at gmail.com>:


----------
nosy: +lekma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:03:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 09:03:15 +0000
Subject: [issue13055] Distutils tries to handle null versions but fails
In-Reply-To: <1317238322.67.0.925527851228.issue13055@psf.upfronthosting.co.za>
Message-ID: <1318150995.21.0.52486667081.issue13055@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The fact that 1) StrictVersion and LooseVersion have None as default argument for vstring in __init__ 2) __init__ does not raise an exception if vstring is not given makes me think that the intended behavior is that the vstring argument is optional.  Making it required would be a behavior change which would run contrary to the distutils code freeze*.  I don?t feel that the workaround (set self.vstring to '') is okay; I?d rather fix the methods that fail when self.vstring is not defined, like __str__, or document the limitations.  What is your use case for these classes, and what methods need fixing?

* There is a lot of code out there that will break if we start to add and remove
  things, so a freeze was decided and we work on distutils2, a new version.
  distutils only gets fixes for real bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13055>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:03:25 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 09 Oct 2011 09:03:25 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1318151005.99.0.944869884326.issue6164@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

hmm, and commit that close issue is ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:04:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 09:04:29 +0000
Subject: [issue13074] Improve documentation of locale encoding functions
In-Reply-To: <1317370534.21.0.426762958064.issue13074@psf.upfronthosting.co.za>
Message-ID: <1318151069.25.0.700686801066.issue13074@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, haypo, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13074>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:05:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 09:05:45 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1318151145.46.0.233992109339.issue6164@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See above: ?done in r73490? and ?merged in 3.2 in r73647?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:10:25 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 09 Oct 2011 09:10:25 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1318151425.24.0.900121459123.issue6164@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

see above "and restore of distutils in trunk abandon it."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:12:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 09:12:49 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1318151569.57.0.351608521812.issue6164@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This was supposed to be added to 3.1 but we missed it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:14:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 09:14:26 +0000
Subject: [issue13030] Be more generic when identifying the Windows main dir in
	installation doc
In-Reply-To: <1316727111.41.0.373563358156.issue13030@psf.upfronthosting.co.za>
Message-ID: <1318151666.67.0.438185621626.issue13030@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The table headings 'Standard installation location' (of what?)
Of software projects using distutils.

> and 'Default value' (for what program?)
For a CPython without changes to the default build configuration.

> both seem a bit ambiguous, or rather they seem reversed to me. I
> would label the columns 'Default module directory' and 'Standard
> Python location'.
Well, no: the first column does not contain real paths, but templates with placeholders like prefix and X.Y.  The second column gives the path with the placeholders replaced by their default value.

> That said, I hope that the actual default module installation
> directory for install is the actual site-packages directory on
> my machine, based on where I actually put python,
Yes.

> and not the non-existent standard location, which I did not use
> but which is what the text seems to say (but which would be a
> behavior design bug to me).
?Default? means ?if you haven?t made any change to the build/install configuration of Python?.

Do these replies make sense?  If so, I can rephrase them as a doc patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13030>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:16:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 09:16:13 +0000
Subject: [issue13094] Need Programming FAQ entry for the behavior of closures
In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za>
Message-ID: <1318151773.49.0.086681588683.issue13094@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +eric.araujo
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13094>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:17:09 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 09 Oct 2011 09:17:09 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1318151829.27.0.168850366576.issue6164@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

For protocol blibpath is not in any release  - get download and check content . 
Did you apply a different fix ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:18:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 09:18:14 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1318151894.46.0.707445212283.issue7475@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

So.  This was reverted before 3.2 was out, right?  What is the status for 3.3?

----------
components:  -2to3 (2.x to 3.0 conversion tool), Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:21:19 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 09 Oct 2011 09:21:19 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1318152079.98.0.0634854631313.issue12386@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I got the problem when installing a package with resources using pysetup3. Here's the relevant part of the console session:

(venv) vinay at eta-natty:~/projects$ pysetup3 install nemo
Installing from source directory: /home/vinay/projects/nemo
running install_dist
running build
running build_py
running build_scripts
running install_lib
creating /tmp/venv/lib/python3.3/site-packages
creating /tmp/venv/lib/python3.3/site-packages/virtualenvwrapper
byte-compiling /tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/hook_loader.py to hook_loader.pyc
byte-compiling /tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/user_scripts.py to user_scripts.pyc
byte-compiling /tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/__init__.py to __init__.pyc
byte-compiling /tmp/venv/lib/python3.3/site-packages/nemo.py to nemo.pyc
running install_scripts
changing mode of /tmp/venv/bin/nemo to 755
running pre_hook hooks.pre_install_data for command install_data
running install_data
running install_distinfo
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/METADATA
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/INSTALLER
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/REQUESTED
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/RESOURCES
Traceback (most recent call last):
  File "/tmp/venv/bin/pysetup3", line 6, in <module>
    rc = packaging.run.main() # None interpreted as 0
  File "/usr/local/lib/python3.3/packaging/run.py", line 653, in main
    return dispatcher()
  File "/usr/local/lib/python3.3/packaging/run.py", line 642, in __call__
    return func(self, self.args)
  File "/usr/local/lib/python3.3/packaging/run.py", line 91, in wrapper
    return f(*args, **kwargs)
  File "/usr/local/lib/python3.3/packaging/run.py", line 164, in _install
    return not install_local_project(target)
  File "/usr/local/lib/python3.3/packaging/install.py", line 122, in install_local_project
    return _run_install_from_dir(path)
  File "/usr/local/lib/python3.3/packaging/install.py", line 160, in _run_install_from_dir
    func(source_dir)
  File "/usr/local/lib/python3.3/packaging/install.py", line 87, in _run_packaging_install
    dist.run_command('install_dist')
  File "/usr/local/lib/python3.3/packaging/dist.py", line 709, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.3/packaging/command/install_dist.py", line 508, in run
    self.run_command(cmd_name)
  File "/usr/local/lib/python3.3/packaging/command/cmd.py", line 330, in run_command
    self.distribution.run_command(command)
  File "/usr/local/lib/python3.3/packaging/dist.py", line 709, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.3/packaging/command/install_distinfo.py", line 113, in run
    writer.writerow(row)
TypeError: 'str' does not support the buffer interface

This is the relevant code in install_distinfo.run():

                resources_path = os.path.join(self.distinfo_dir,
                                              'RESOURCES')
                logger.info('creating %s', resources_path)
                if not self.dry_run:
                    #with open(resources_path, 'w', encoding='utf-8') as f:
                    with open(resources_path, 'wb') as f:
                        writer = csv.writer(f, delimiter=',',
                                            lineterminator='\n',
                                            quotechar='"')
                        for row in install_data.get_resources_out():
                            writer.writerow(row)

If I substitute the commented out line above which replaces 'wb' with 'w' and encoding, I get this result:

(venv) vinay at eta-natty:~/projects$ pysetup3 install nemo
Installing from source directory: /home/vinay/projects/nemo
running install_dist
running build
running build_py
running build_scripts
running install_lib
byte-compiling /tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/hook_loader.py to hook_loader.pyc
byte-compiling /tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/user_scripts.py to user_scripts.pyc
byte-compiling /tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/__init__.py to __init__.pyc
byte-compiling /tmp/venv/lib/python3.3/site-packages/nemo.py to nemo.pyc
running install_scripts
changing mode of /tmp/venv/bin/nemo to 755
running pre_hook hooks.pre_install_data for command install_data
running install_data
running install_distinfo
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/METADATA
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/INSTALLER
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/REQUESTED
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/RESOURCES
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/RECORD

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:25:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Oct 2011 09:25:54 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1318152354.9.0.168398645037.issue6164@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, I thought it was missing only in 3.1.  I will reapply the patch.

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open
versions: +3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Sun Oct  9 11:34:00 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 09 Oct 2011 09:34:00 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1318146241.94.0.204924395915.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318152670.53177.YahooMailNeo@web25803.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I share that opinion.? So, the first step would be to record created 

> directories.? We could extend PEP 376 and write entries without hash nor length 
> record for directories in RECORD, or use another file in the dist-info dir.

IMO using RECORD would be preferable to another file, otherwise RECORD is not a complete record :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Sun Oct  9 12:15:18 2011
From: report at bugs.python.org (Valery Khamenya)
Date: Sun, 09 Oct 2011 10:15:18 +0000
Subject: [issue13133] FD leaks in ZipFile.read(),
	ZipFile.extract() and also using explicit arc_member.close()
In-Reply-To: <1318099735.4.0.121973105523.issue13133@psf.upfronthosting.co.za>
Message-ID: <1318155318.4.0.661722670568.issue13133@psf.upfronthosting.co.za>


Valery Khamenya <khamenya at gmail.com> added the comment:

Amaury, I followed your advice. All relevant changes of 3.2 are backported via the patch attached.

P.S. now I can install Twisted using pypy too. "pypy setup.py install" works fine for me.

----------
keywords: +patch
status: pending -> open
Added file: http://bugs.python.org/file23354/zipfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13133>
_______________________________________

From report at bugs.python.org  Sun Oct  9 13:23:04 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 09 Oct 2011 11:23:04 +0000
Subject: [issue13134] speed up finding of one-character strings
In-Reply-To: <1318113072.9190.14.camel@localhost.localdomain>
Message-ID: <4E918414.9030605@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

[Posted the reply to the right ticket; see issue13136 for the original
 post to the wrong ticket]

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> Before going further with this, I'd suggest you have a look at your
>> compiler settings.
> 
> They are set by the configure script:
> 
> gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall
> -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o
> Objects/unicodeobject.o Objects/unicodeobject.c

Which gcc version are you using ?
Is it possible that you have -fno-builtin enabled ?

>> Such optimizations are normally performed by the
>> compiler and don't need to be implemented in C, making maintenance
>> harder.
> 
> The fact that the glibc includes such optimization (in much more
> sophisticated form) suggests to me that many compilers don't perform
> these optimizations automically.

When using gcc, the glibc functions are usually not used at all,
since gcc comes with a (rather large) set of builtins which are
inlined directly, if you have optimizations enabled and inlining
is found to be more efficient than calling the glibc function:

http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

glibc includes the optimized versions since it has to implement
C library (obviously) and for cases where inlining does not
happen.

>> I tested using memchr() when writing those "naive" loops.
> 
> memchr() is mentioned in another issue, #13134.
> 
>> memchr()
>> is inlined by the compiler just like the direct loop
> 
> I don't think so. If you look at the glibc's memchr() implementation,
> it's a sophisticated routine, not a trivial loop. Perhaps you're
> thinking about memcpy().

See http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html and the
assembler output. If it's not inlined, then something must be
preventing this and it would be good to find out why.

>> and the generated
>> code for the direct version is often easier to optimize for the compiler
>> than the memchr() one, since it receives more knowledge about the used
>> data types.
> 
> ?? Data types are fixed in the memchr() definition, there's no knowledge
> to be gained by inlining.

There is: the compiler will have alignement information available and
can also benefit from using registers instead of the stack, knowledge
about processor cache lines, etc. Such information is lost when calling
a function. The function call itself will also create some overhead.

BTW: You should not only test the optimization with long strings, but also
with short ones (e.g. 2-15 chars) - which is a much more common case
in practice.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Sun Oct  9 13:25:14 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 09 Oct 2011 11:25:14 +0000
Subject: [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1318159514.75.0.272083898464.issue12779@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
nosy: +pmoore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12779>
_______________________________________

From report at bugs.python.org  Sun Oct  9 13:33:31 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 09 Oct 2011 11:33:31 +0000
Subject: [issue13136] speed-up conversion between unicode widths
In-Reply-To: <1318113072.9190.14.camel@localhost.localdomain>
Message-ID: <4E918688.4030806@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
>> I tested using memchr() when writing those "naive" loops.
> 
> memchr() is mentioned in another issue, #13134.

Looks like I posted the comment to the wrong ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13136>
_______________________________________

From report at bugs.python.org  Sun Oct  9 14:07:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 12:07:46 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <E1RCsAS-0003cG-Tv@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d0af22b65889 by Larry Hastings in branch '2.7':
Issue #13053: Added section on migrating from CObject to Capsule
http://hg.python.org/cpython/rev/d0af22b65889

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13053>
_______________________________________

From report at bugs.python.org  Sun Oct  9 15:20:59 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Oct 2011 13:20:59 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences
	from	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1318166459.35.0.821972995683.issue12753@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is a new patch that stores the names of aliases and named sequences in the Private Use Area.

To summarize a bit, this is what we want:
        | 6.0.0 | 3.2.0 |
--------+-------+-------+
\N{...} |   A   |   -   |
.name   |   -   |   -   |
.lookup |  A,NS |   -   |

I.e., \N{...} should only support aliases, unicodedata.lookup should support aliases and named sequences, unicodedata.name doesn't support either, and when 3.2.0 is used nothing is supported.

The function calls involved for these 3 functions are:

\N{...} and .lookup:
  _getcode
    _cmpname
      _getucname
    _check_alias

.name:
  _getucname

My patch adds an extra arg to _getcode and _getucname (I hope that's fine -- or are they public?).

_getcode is called by \N{...} and .lookup; both support aliases, so _getcode now resolves aliases by default.  Since only .lookup wants named sequences, _getcode now accepts an extra 'with_named_seq' arg and looks up named sequences only when its value is 1.  .lookup passes 1, gets the codepoint, and converts it to a sequence.  \N{...} passes 0 and doesn't get named sequences.

_getucname is called by .name and indirectly (through _cmpname) by .lookup and \N{...}.  Since _getcode takes care of deciding who gets aliases and sequences, _getucname now accepts an extra 'with_alias_and_seq' arg and looks up aliases and named sequences only when its value is 1.  _cmpname passes 1, gets aliases and named sequences and then lets _getcode decide what to do with them.  .name passes 0 and doesn't get aliases and named sequences.

All this happens on 6.0.0 only, when self != NULL (i.e. we are using 3.2.0) named sequences and aliases are ignored.

The patch doesn't include the changes to unicodename_db.h -- run makeunicodedata.py to get them.
I also added more tests to make sure that the names added in the PUA don't leak, and that ucd_3_2_0 is not affected.

----------
Added file: http://bugs.python.org/file23355/issue12753-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sun Oct  9 15:51:12 2011
From: report at bugs.python.org (Ben Gamari)
Date: Sun, 09 Oct 2011 13:51:12 +0000
Subject: [issue13055] Distutils tries to handle null versions but fails
In-Reply-To: <1317238322.67.0.925527851228.issue13055@psf.upfronthosting.co.za>
Message-ID: <1318168272.03.0.0134766537166.issue13055@psf.upfronthosting.co.za>


Ben Gamari <bgamari at gmail.com> added the comment:

The bug was encountered while trying to install a package. As it turns out, a dependency was incorrectly installed, resulting in a null version being passed around which quickly caused a crash in setup.py. While this is definitely not a normal circumstance, the fact that this bug existed made finding the issue substantially more time consuming. If the constructor of the LooseVersion can accept None, then so should its other members.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13055>
_______________________________________

From report at bugs.python.org  Sun Oct  9 16:27:01 2011
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Oct 2011 14:27:01 +0000
Subject: [issue11457] os.stat(): add new fields to get timestamps as Decimal
	objects with nanosecond resolution
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1318170421.84.0.927407401001.issue11457@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Can I get some thoughts / votes on whether to
a) check in with the current performance regression, or
b) do the work to make it lazy-created?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Sun Oct  9 16:27:03 2011
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 09 Oct 2011 14:27:03 +0000
Subject: [issue13096] ctypes: segfault with large POINTER type names
In-Reply-To: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za>
Message-ID: <1318170423.11.0.382880481723.issue13096@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

The problem is around line 1734 of callproc.c in tip:

    } else if (PyType_Check(cls)) {
        typ = (PyTypeObject *)cls;
        buf = alloca(strlen(typ->tp_name) + 3 + 1);
        sprintf(buf, "LP_%s", typ->tp_name);   <-- segfault is here

Replacing the alloca with a malloc fixes it, so I presume it's hitting the stack size limit as 2^25 is 32MB (my stack limit is 8MB).

----------
nosy: +bbrazil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13096>
_______________________________________

From report at bugs.python.org  Sun Oct  9 16:36:03 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 09 Oct 2011 14:36:03 +0000
Subject: [issue13096] ctypes: segfault with large POINTER type names
In-Reply-To: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za>
Message-ID: <1318170963.7.0.284805819444.issue13096@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Yup, it is the 'alloca' call.  This issue and issue13097 are both 
'alloca' related as mentioned in issue12881.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13096>
_______________________________________

From report at bugs.python.org  Sun Oct  9 16:37:06 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 09 Oct 2011 14:37:06 +0000
Subject: [issue13097] ctypes: segfault with large number of callback arguments
In-Reply-To: <1317700637.71.0.186696346618.issue13097@psf.upfronthosting.co.za>
Message-ID: <1318171026.43.0.176899724395.issue13097@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

As mentioned in issue12881, this issue is a result of an unbounded 'alloca' call that trashes the stack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13097>
_______________________________________

From report at bugs.python.org  Sun Oct  9 17:05:15 2011
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 09 Oct 2011 15:05:15 +0000
Subject: [issue13050] RLock support the context manager protocol but this is
	not documented
Message-ID: <1318172715.77.0.360303466185.issue13050@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

This is already documented:

http://docs.python.org/library/threading.html#using-locks-conditions-and-semaphores-in-the-with-statement

----------
nosy: +bbrazil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13050>
_______________________________________

From report at bugs.python.org  Sun Oct  9 17:18:08 2011
From: report at bugs.python.org (higery)
Date: Sun, 09 Oct 2011 15:18:08 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1318173488.87.0.973876876637.issue8668@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>> higery, can you give us a status update?  Do you have the time to ...

Sorry to reply to you so late, I will read carefully these reviews asap and try to make an updated patch before 12th.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Sun Oct  9 17:20:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Oct 2011 15:20:07 +0000
Subject: [issue11457] os.stat(): add new fields to get timestamps as Decimal
	objects with nanosecond resolution
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1318173607.37.0.251760385091.issue11457@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

[Arfrever Frehtes Taifersar Arahesis]
> I suggest to have low-level, POSIX-compatible, 
> (int, int)-based interface in os module and add 
> high-level, decimal.Decimal-based interface in 
> shutil module.

I agree that this is the cleanest approach.
Ideally, the os module stays as close as possible
to the underlying structures.  Also, it is desirable
to keep it fast (not importing a pure python decimal
module as a side-effect of checking the a timestamp
-- making everyone pay the cost for a feature that
few people will want or need).

With respect to the options suggested by MvL,
I support adding new named fields and opposed
to using a flag to indicate a type change (that
would be error-prone).

If new fields as added, their names need to follow
the existing naming convention (st_variable).

-1 on the patch as currently proposed.  I don't
think the performance impact is acceptable.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Sun Oct  9 17:21:03 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 09 Oct 2011 15:21:03 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1318166459.35.0.821972995683.issue12753@psf.upfronthosting.co.za>
Message-ID: <23819.1318173654@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Ezio Melotti <report at bugs.python.org> wrote
   on Sun, 09 Oct 2011 13:21:00 -0000: 

> Here is a new patch that stores the names of aliases and named
> sequences in the Private Use Area.

Looks good!  Thanks!

--tom

----------
title: \N{...} neglects formal aliases and named sequences from	Unicode charnames namespace -> \N{...} neglects formal aliases and named sequences from Unicode charnames namespace

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sun Oct  9 17:29:16 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 09 Oct 2011 15:29:16 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1318174156.23.0.0866442638285.issue13062@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Here is an updated patch with error handling.  One other thought is that 
'getclosure' should be called something like 'getclosureenv' since 
technically a closure is a function plus its environment and our 
implementation only returns the environment.  But that may be converging 
on pedantic.

----------
Added file: http://bugs.python.org/file23356/issue13062-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13062>
_______________________________________

From report at bugs.python.org  Sun Oct  9 17:30:44 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Oct 2011 15:30:44 +0000
Subject: [issue11457] os.stat(): add new fields to get timestamps as Decimal
	objects with nanosecond resolution
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1318174244.26.0.818906820951.issue11457@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Sun Oct  9 17:43:51 2011
From: report at bugs.python.org (Mike Hoy)
Date: Sun, 09 Oct 2011 15:43:51 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1318175031.49.0.986539218473.issue12436@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

Here is what I have so far:

> For Windows users, added a section about how to use a terminal

How to use a terminal

Open a command prompt:

* On Windows Vista or Windows 7: click on the Start menu (the Windows logo in the lower left of the screen), type cmd into the Search field directly above the Start menu button, and click on "cmd" in the search results above the Search field.

* On Windows XP: click on the Start menu (the Windows logo in the lower left of the screen), click on "Run...", type cmd into the text box, and hit enter.

Commands used in terminal

* cd C:\ - Puts you in the root directory of the C drive.
* cd Python32 - Puts you in the directory where Python 3.2 is installed.
* dir - This command lists the contents of the Python32 directory.
* python - This command will invoke python.exe and bring up the interpreter.

> a link to PowerShell 

Windows PowerShell

Windows PowerShell is a task-based command-line shell and scripting language designed for system administration. It can be obtained here: http://technet.microsoft.com/en-us/library/bb978526.aspx.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Sun Oct  9 17:44:26 2011
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 09 Oct 2011 15:44:26 +0000
Subject: [issue12923] test_urllib fails in refleak mode
In-Reply-To: <1315352458.41.0.979039254957.issue12923@psf.upfronthosting.co.za>
Message-ID: <1318175066.81.0.471328347911.issue12923@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

This appears to fail every 9th, 19th, 29th, etc. repetition of the test. 

This seems to be something to do with the reference counting/close logic of the FakeSocket but I haven't managed to figure out what.

----------
nosy: +bbrazil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12923>
_______________________________________

From report at bugs.python.org  Sun Oct  9 17:51:10 2011
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Oct 2011 15:51:10 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1318175470.62.0.626449660123.issue13086@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Attached is my first revision patch.  I did some other editing for
clarity / 80 columns, though I can back those out from this patch (and put in another) if that's best.

Patch is against the 2.7 branch; once this goes in I'll port all my recent cporting.rst changes to 3.2 and trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file23357/larry.cporting.to.python.3.r1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sun Oct  9 17:51:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 09 Oct 2011 15:51:45 +0000
Subject: [issue13050] RLock support the context manager protocol but this is
	not documented
In-Reply-To: <1318172715.77.0.360303466185.issue13050@psf.upfronthosting.co.za>
Message-ID: <1318175505.58.0.000355739442967.issue13050@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  But what I did was look up the RLock section of the manual to answer the question "does this support the context manager protocol", and the answer appeared to be no.  In a reference manual I would expect all the important features of an object to be described in that object's documentation, or linked to therefrom.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13050>
_______________________________________

From report at bugs.python.org  Sun Oct  9 18:04:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Oct 2011 16:04:37 +0000
Subject: [issue13086] Update howto/cporting.rst so it talks about Python 3
	instead of 3.0
In-Reply-To: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za>
Message-ID: <1318176277.9.0.73886932181.issue13086@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Attached is my first revision patch.

LGTM

> I did some other editing for clarity / 80 columns, though I can back 
> those out from this patch (and put in another) if that's best.

That's fine with me, and while you are at it, you could fix this too when you commit:
+   the many Python level changes made leaving Python 2's API intact
s/Python level/Python-level/

> Patch is against the 2.7 branch; once this goes in I'll port all my 
> recent cporting.rst changes to 3.2 and trunk.

Remember to convert things like :cmacro: to :c:macro: when you port it.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13086>
_______________________________________

From report at bugs.python.org  Sun Oct  9 18:08:00 2011
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 09 Oct 2011 16:08:00 +0000
Subject: [issue12923] test_urllib fails in refleak mode
In-Reply-To: <1315352458.41.0.979039254957.issue12923@psf.upfronthosting.co.za>
Message-ID: <1318176480.81.0.758057254027.issue12923@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

The actual problem is that FancyURLOpener self.tries isn't being reset if the protocol is file://

I've attached a patch that'll help improve the test at least.

----------
keywords: +patch
Added file: http://bugs.python.org/file23358/12923-unittest-improvement.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12923>
_______________________________________

From report at bugs.python.org  Sun Oct  9 18:14:01 2011
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 09 Oct 2011 16:14:01 +0000
Subject: [issue12923] test_urllib fails in refleak mode
In-Reply-To: <1315352458.41.0.979039254957.issue12923@psf.upfronthosting.co.za>
Message-ID: <1318176841.6.0.351970727791.issue12923@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

Here's a path to fix the problem.

----------
Added file: http://bugs.python.org/file23359/12923-maxtries-reset.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12923>
_______________________________________

From report at bugs.python.org  Sun Oct  9 18:15:54 2011
From: report at bugs.python.org (Mike Hoy)
Date: Sun, 09 Oct 2011 16:15:54 +0000
Subject: [issue3902] Packages containing only extension modules have to
	contain __init__.py
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1318176954.48.0.668783243922.issue3902@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

Submitted v2 of my patch after reading ?ric's review of my first.

----------
Added file: http://bugs.python.org/file23360/apiref-setupscript-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Sun Oct  9 22:18:45 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 09 Oct 2011 20:18:45 +0000
Subject: [issue13140] ThreadingMixIn.daemon_threads is not honored when parent
	is daemon
Message-ID: <1318191525.3.0.322601594247.issue13140@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

I use the socketserver.ThreadingMixIn to create a TCPServer.

I set the server thread as daemon (t.daemon=True).
But I want the client threads to run as non-daemon.
According to the documentation, the "daemon_threads" class attribute should do the trick.

But it fails: if server is daemon, the clients are daemon too, even if daemon_threads=False.

Demo attached.

----------
components: Library (Lib)
files: test_socketserver.py
messages: 145273
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: ThreadingMixIn.daemon_threads is not honored when parent is daemon
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23361/test_socketserver.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13140>
_______________________________________

From report at bugs.python.org  Sun Oct  9 22:37:07 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 09 Oct 2011 20:37:07 +0000
Subject: [issue13141] get rid of old threading API in the examples
Message-ID: <1318192627.46.0.311858462486.issue13141@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

http://docs.python.org/dev/library/socketserver.html#asynchronous-mixins

Still there's getName or setDaemon in some example.

----------
assignee: docs at python
components: Documentation
messages: 145274
nosy: docs at python, flox
priority: low
severity: normal
stage: needs patch
status: open
title: get rid of old threading API in the examples
type: behavior
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13141>
_______________________________________

From report at bugs.python.org  Sun Oct  9 22:57:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 20:57:17 +0000
Subject: [issue13138] ElementTree's Element.iter() lacks versionadded
In-Reply-To: <1318121372.98.0.459756814836.issue13138@psf.upfronthosting.co.za>
Message-ID: <E1RD0Qu-00062C-5j@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0f0a5d1c7a93 by Ezio Melotti in branch '2.7':
#13138: add missing versionadded.  Patch by Andreas St?hrk.
http://hg.python.org/cpython/rev/0f0a5d1c7a93

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13138>
_______________________________________

From report at bugs.python.org  Sun Oct  9 22:58:33 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 09 Oct 2011 20:58:33 +0000
Subject: [issue13139] multiprocessing.map skips finally blocks
In-Reply-To: <1318125947.15.0.13973515193.issue13139@psf.upfronthosting.co.za>
Message-ID: <1318193913.31.0.675721368875.issue13139@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Same behavior on Python 3.2 with this code:


from multiprocessing import Pool
from time import sleep

def Process(x):
    try:
        print(x)
        sleep(.6-x/10.)
        raise Exception('Exception: %d' % x)
    finally:
        print('Finally: %d' % x)

Pool(3).map(Process, [1, 2, 3])

----------
components: +Library (Lib) -None
nosy: +flox
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13139>
_______________________________________

From report at bugs.python.org  Sun Oct  9 23:03:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Oct 2011 21:03:40 +0000
Subject: [issue13138] ElementTree's Element.iter() lacks versionadded
In-Reply-To: <1318121372.98.0.459756814836.issue13138@psf.upfronthosting.co.za>
Message-ID: <E1RD0X5-0006Pe-Gq@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 66d01b252b9a by Ezio Melotti in branch '3.2':
#13138: add missing versionadded.
http://hg.python.org/cpython/rev/66d01b252b9a

New changeset 2580e642e2ee by Ezio Melotti in branch 'default':
#13138: merge with 3.2.
http://hg.python.org/cpython/rev/2580e642e2ee

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13138>
_______________________________________

From report at bugs.python.org  Sun Oct  9 23:04:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Oct 2011 21:04:47 +0000
Subject: [issue13138] ElementTree's Element.iter() lacks versionadded
In-Reply-To: <1318121372.98.0.459756814836.issue13138@psf.upfronthosting.co.za>
Message-ID: <1318194287.41.0.15604214313.issue13138@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13138>
_______________________________________

From report at bugs.python.org  Sun Oct  9 23:09:13 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 09 Oct 2011 21:09:13 +0000
Subject: [issue13126] find() slower than rfind()
In-Reply-To: <1318016796.03.0.16031959225.issue13126@psf.upfronthosting.co.za>
Message-ID: <1318194553.01.0.27738612787.issue13126@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13126>
_______________________________________

From report at bugs.python.org  Sun Oct  9 23:13:38 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 09 Oct 2011 21:13:38 +0000
Subject: [issue13119] Newline for print() is \n on Windows,
	and not \r\n as expected
In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za>
Message-ID: <1318194818.53.0.0357380719162.issue13119@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13119>
_______________________________________

From report at bugs.python.org  Sun Oct  9 23:21:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Oct 2011 21:21:56 +0000
Subject: [issue13134] speed up finding of one-character strings
In-Reply-To: <4E918414.9030605@egenix.com>
Message-ID: <1318195095.9190.22.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> >> Before going further with this, I'd suggest you have a look at your
> >> compiler settings.
> > 
> > They are set by the configure script:
> > 
> > gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall
> > -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o
> > Objects/unicodeobject.o Objects/unicodeobject.c
> 
> Which gcc version are you using ?

$ gcc -v
Utilisation des specs internes.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-mageia-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-mageia-linux-gnu
Configur? avec: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib64 --with-bugurl=http://bugs.mageia.org/
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-checking=release --enable-languages=c,c
++,ada,fortran,objc,obj-c++,java --build=x86_64-mageia-linux-gnu
--host=x86_64-mageia-linux-gnu --with-cpu=generic --with-system-zlib
--enable-threads=posix --enable-shared --enable-objc-gc
--enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-gtk-cairo
--disable-libjava-multilib --enable-ssp --disable-libssp
--disable-werror --with-ppl --with-cloog
--with-python-dir=/lib/python2.7/site-packages --enable-lto
Mod?le de thread: posix
gcc version 4.5.2 (GCC) 

> Is it possible that you have -fno-builtin enabled ?

Why would it be enabled? It is not on the command line.

> >> Such optimizations are normally performed by the
> >> compiler and don't need to be implemented in C, making maintenance
> >> harder.
> > 
> > The fact that the glibc includes such optimization (in much more
> > sophisticated form) suggests to me that many compilers don't perform
> > these optimizations automically.
> 
> When using gcc, the glibc functions are usually not used at all,
> since gcc comes with a (rather large) set of builtins which are
> inlined directly, if you have optimizations enabled and inlining
> is found to be more efficient than calling the glibc function:

What would that change? Whether the optimized memchr() comes from gcc or
the glibc is not relevant here.

> There is: the compiler will have alignement information available and
> can also benefit from using registers instead of the stack, knowledge
> about processor cache lines, etc. Such information is lost when calling
> a function. The function call itself will also create some overhead.
> 
> BTW: You should not only test the optimization with long strings, but also
> with short ones (e.g. 2-15 chars) - which is a much more common case
> in practice.

With very short strings, the runtimes tend to be identical, which is
understandable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Sun Oct  9 23:37:39 2011
From: report at bugs.python.org (Daniel Wagner-Hall)
Date: Sun, 09 Oct 2011 21:37:39 +0000
Subject: [issue13139] multiprocessing.map skips finally blocks
In-Reply-To: <1318125947.15.0.13973515193.issue13139@psf.upfronthosting.co.za>
Message-ID: <1318196259.27.0.52814824383.issue13139@psf.upfronthosting.co.za>


Daniel Wagner-Hall <dawagner at gmail.com> added the comment:

Explanation of behaviour at http://stackoverflow.com/questions/7700929/python-multiprocessing-map-if-one-thread-raises-an-exception-why-arent-other

tl;dr SIGTERM kills subprocesses and finally blocks aren't called.

I still consider this a bug, though

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13139>
_______________________________________

From report at bugs.python.org  Sun Oct  9 23:40:12 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 09 Oct 2011 21:40:12 +0000
Subject: [issue10444] A mechanism is needed to override waiting for Python
	threads to finish
In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>
Message-ID: <1318196412.03.0.151483432477.issue10444@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Antoine wrote:
> You could instead enumerate() all threads and set their daemon flag
> to False, before shutting down the interpreter.

If it is intended to work this way, it should be mentioned in the documentation.

Currently the documentation for "Thread.daemon" says:
?This must be set before start() is called, otherwise RuntimeError is raised.?

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10444>
_______________________________________

From report at bugs.python.org  Sun Oct  9 23:48:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Oct 2011 21:48:42 +0000
Subject: [issue13127] xml.dom.Attr.name is not labeled as read-only
In-Reply-To: <1318047492.07.0.217686953928.issue13127@psf.upfronthosting.co.za>
Message-ID: <1318196922.06.0.722736384691.issue13127@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

localName is defined with defproperty() in Lib/xml/dom/minidom.py:464 and looking at the definition of defproperty() in  Lib/xml/dom/minicompat.py:97 I think this is supposed to raise an xml.dom.NoModificationAllowedErr exception when someone tries to write on the attribute.  This doesn't seem to happen though.
OTOH 'name' doesn't use defproperty(), so technically it's writable, expect that writing on it has no effect.
This should still be documented, and it would also be good to figure out what's going on with defproperty().

----------
components: +Library (Lib)
keywords: +easy
nosy: +ezio.melotti
stage:  -> test needed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13127>
_______________________________________

From report at bugs.python.org  Sun Oct  9 23:53:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Oct 2011 21:53:49 +0000
Subject: [issue11813] inspect.getattr_static doesn't get module attributes
In-Reply-To: <1302389059.87.0.554654770337.issue11813@psf.upfronthosting.co.za>
Message-ID: <1318197229.55.0.983582145816.issue11813@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11813>
_______________________________________

From report at bugs.python.org  Mon Oct 10 00:26:17 2011
From: report at bugs.python.org (Patrick Westerhoff)
Date: Sun, 09 Oct 2011 22:26:17 +0000
Subject: [issue13142] Add support for other HTTP methods in urllib.request
Message-ID: <1318199177.09.0.985752068879.issue13142@psf.upfronthosting.co.za>


New submission from Patrick Westerhoff <PatrickWesterhoff at gmail.com>:

Hey,

I would like to request the support of other HTTP methods (other than GET and POST) in urllib.request. While it?s actually simple enough to override the Request class to add such a possibility, I think it is far too simple to leave it out of the standard library.

I?ve attached a patch that adds the functionality with a simple `method` property. The `get_method` function then simply looks if a custom method was entered, and otherwise falls back to the default behaviour.

Thanks a lot!

Patrick Westerhoff

Btw. Being a Git user, I hope the patch is actually useful ;)

----------
components: Library (Lib)
files: urllib.patch
keywords: patch
messages: 145283
nosy: poke
priority: normal
severity: normal
status: open
title: Add support for other HTTP methods in urllib.request
type: feature request
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23362/urllib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13142>
_______________________________________

From report at bugs.python.org  Mon Oct 10 00:37:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Oct 2011 22:37:00 +0000
Subject: [issue13142] Add support for other HTTP methods in urllib.request
In-Reply-To: <1318199177.09.0.985752068879.issue13142@psf.upfronthosting.co.za>
Message-ID: <1318199820.02.0.353936620801.issue13142@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is a duplicate of #1673007, and it also has the same patch you wrote.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> urllib2 requests history + HEAD support
versions:  -Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13142>
_______________________________________

From report at bugs.python.org  Mon Oct 10 00:43:23 2011
From: report at bugs.python.org (Patrick Westerhoff)
Date: Sun, 09 Oct 2011 22:43:23 +0000
Subject: [issue13142] Add support for other HTTP methods in urllib.request
In-Reply-To: <1318199177.09.0.985752068879.issue13142@psf.upfronthosting.co.za>
Message-ID: <1318200203.06.0.739942044194.issue13142@psf.upfronthosting.co.za>


Patrick Westerhoff <PatrickWesterhoff at gmail.com> added the comment:

Oh sorry, I didn?t see that one. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13142>
_______________________________________

From report at bugs.python.org  Mon Oct 10 00:44:22 2011
From: report at bugs.python.org (Patrick Westerhoff)
Date: Sun, 09 Oct 2011 22:44:22 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1318200262.03.0.837767919434.issue1673007@psf.upfronthosting.co.za>


Changes by Patrick Westerhoff <PatrickWesterhoff at gmail.com>:


----------
nosy: +poke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Mon Oct 10 00:57:59 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Oct 2011 22:57:59 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1318201079.97.0.217028074088.issue12436@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Open a command prompt:
Another alternative is win+r -> type 'cmd' -> hit enter.  This should work on all the Windows versions.

> * cd C:\ - Puts you in the root directory of the C drive.
> * cd Python32 - Puts you in the directory where Python 3.2 is installed.

What if it's not installed there?  Maybe it's better to say something like "use the 'cd' command to move to the directory where Python is installed" possibly mentioning the default installation directory and  'cd ..'.

> * dir - This command lists the contents of the Python32 directory.
> * python - This command will invoke python.exe and bring up the 
interpreter.

If the dir is already added to the PATH 'python' will work already without having to navigate to the installation dir.
Also if the user installed Python there should be a "Python (command line)" entry in the start menu that brings up the interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Mon Oct 10 01:07:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Oct 2011 23:07:36 +0000
Subject: [issue13107] Text width in optparse.py can become negative
In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za>
Message-ID: <1318201656.78.0.829265919035.issue13107@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +aronacher, bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13107>
_______________________________________

From report at bugs.python.org  Mon Oct 10 01:15:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Oct 2011 23:15:26 +0000
Subject: [issue13075] PEP-0001 contains dead links
In-Reply-To: <1317374485.54.0.239839552518.issue13075@psf.upfronthosting.co.za>
Message-ID: <1318202126.06.0.423350899348.issue13075@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This has been fixed in http://hg.python.org/peps/rev/398596beeee3
Thanks for the report and the patch!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13075>
_______________________________________

From report at bugs.python.org  Mon Oct 10 01:20:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Oct 2011 23:20:43 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <1318202443.55.0.867275604112.issue11489@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +pitrou, tchrist
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11489>
_______________________________________

From report at bugs.python.org  Mon Oct 10 01:24:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Oct 2011 23:24:10 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <1318202650.32.0.981703106201.issue11489@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11489>
_______________________________________

From report at bugs.python.org  Mon Oct 10 01:49:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Oct 2011 23:49:57 +0000
Subject: [issue11457] os.stat(): add new fields to get timestamps as Decimal
	objects with nanosecond resolution
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1318204197.22.0.964917265195.issue11457@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

One other thought:  it would be useful to research how nanosecond-resolution timestamps are going to be supported in other languages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Mon Oct 10 01:59:57 2011
From: report at bugs.python.org (Mike Hoy)
Date: Sun, 09 Oct 2011 23:59:57 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318204797.54.0.922565501698.issue12602@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy:  -mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Mon Oct 10 02:03:54 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Oct 2011 00:03:54 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
	faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1318205034.78.0.237541170218.issue5322@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think it needs tests.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Mon Oct 10 06:35:03 2011
From: report at bugs.python.org (Garen)
Date: Mon, 10 Oct 2011 04:35:03 +0000
Subject: [issue13143] os.path.islink documentation is ambiguous
Message-ID: <1318221303.29.0.86938915547.issue13143@psf.upfronthosting.co.za>


New submission from Garen <garen.parham at gmail.com>:

The documentation for os.path.islink says:

"Return True if path refers to a directory entry that is a symbolic link. Always False if symbolic links are not supported."

But what does "supported" mean?  "Supported" by what?  Supported by the OS, or supported by the Python runtime?  Because clearly there is a difference, which surprised me:

PythonWin 2.7.2 (default, Jun 24 2011, 12:21:10) [MSC v.1500 32 bit (Intel)] on win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information.
>>> import os
>>> os.path.islink(r"C:\Users\Garen\dev\pypy.exe")
False
>>> os.path.islink(r"C:\Users\Garen\dev\abspypy.exe")
False

Whereas if I use 3.2.x, I get the right answers:
ActivePython 3.2.2.3 (ActiveState Software Inc.) based on
Python 3.2.2 (default, Sep  8 2011, 10:56:38) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import os
>>> os.path.islink(r"C:\Users\Garen\dev\pypy.exe")
True
>>> os.path.islink(r"C:\Users\Garen\dev\abspypy.exe")
True

An additional surprise is that in other places of the Python runtime, if functionality is not implemented for Windows, an exception of type NotImplementedError is raised--but not in this case with os.path.islink().

This all makes it a hairy mess to properly detect symlinks--from the client code perspective, now one has to check for specific versions of python, specific versions of Windows, and possibly which file-system is being used (FAT vs NTFS) just to be able to determine if islink() is silently failing or not.  After which the client side will want to add clarifying comments to compensate for what's missing from the official docs (as opposed to posting a link to the docs in a comment).

As a user from the client side, I would only expect os.path.islink() to return False if the underlying OS/filesystem didn't support symlinks; if the underlying OS/filesystem did suport symlinks but support was missing, I'd expect to see a NoteImplementedError raised.  

In any case, where behavior for os.path.islink() (and related routines) deviates from the above pattern, I'd expect documentation that indicates what those deviations are--in this case, that False means unsupported by the Python runtime regardless of whether the OS/filesystem provides that functionality.

----------
messages: 145290
nosy: Garen
priority: normal
severity: normal
status: open
title: os.path.islink documentation is ambiguous
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13143>
_______________________________________

From report at bugs.python.org  Mon Oct 10 09:52:54 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 10 Oct 2011 07:52:54 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1318233174.46.0.680055221994.issue8087@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(just reviewing the idea here, not the current patch)

The problem of "stale code" (i.e. what was executed doesn't match what is displayed in the traceback) is a tricky and subtle one. There are a few different cases:

1. Source displayed does not match source on disk
- these cases do happen, but they're almost always due to straight up bugs in the linecache or traceback modules.
2. Source has been changed, but module has not been reloaded
- this is the case for "edited source file but forgot to reload module". I've certainly forgotten to do this myself, and I'm far from the only one. This is the case Diego's RFE targets, and I think it has some merit.
3. Source has been changed, module has been reloaded, but object reference is from previous version of module
- the patch doesn't detect this. There are various ways we *could* detect it, but they all involve some fairly significant changes to the way compilation and module import work.

Aspect 3 is a much deeper (and bigger) problem relating to native introspection support in function and class objects. But that doesn't make Diego's idea to improve Aspect 2 invalid - there have certainly been times when playing at the interactive prompt that such a warning would have reminded me that I needed to reload the module I was working on.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Mon Oct 10 11:39:48 2011
From: report at bugs.python.org (Carl Robben)
Date: Mon, 10 Oct 2011 09:39:48 +0000
Subject: [issue2945] bdist_rpm does not list dist files (should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <1318239588.1.0.0383470674425.issue2945@psf.upfronthosting.co.za>


Carl Robben <carl.robben at gmail.com> added the comment:

Here's a patch for test_bdist_rpm.py and to check the contents of dist.dist_files

----------
Added file: http://bugs.python.org/file23363/test_bdist_rpm.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2945>
_______________________________________

From report at bugs.python.org  Mon Oct 10 11:42:10 2011
From: report at bugs.python.org (Carl Robben)
Date: Mon, 10 Oct 2011 09:42:10 +0000
Subject: [issue2945] bdist_rpm does not list dist files (should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <1318239730.93.0.00675316158455.issue2945@psf.upfronthosting.co.za>


Carl Robben <carl.robben at gmail.com> added the comment:

Adding a patch for 2.7

----------
Added file: http://bugs.python.org/file23364/bdist_rpm-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2945>
_______________________________________

From report at bugs.python.org  Mon Oct 10 11:50:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 10 Oct 2011 09:50:57 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1318240257.5.0.178930056655.issue12753@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file23355/issue12753-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Oct 10 11:51:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 10 Oct 2011 09:51:18 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1318240278.93.0.292034930798.issue12753@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file23365/issue12753-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Oct 10 12:00:23 2011
From: report at bugs.python.org (Guandalino)
Date: Mon, 10 Oct 2011 10:00:23 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1318240823.18.0.326131185218.issue11776@psf.upfronthosting.co.za>


Changes by Guandalino <guandalino at gmail.com>:


----------
nosy: +guandalino

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Mon Oct 10 12:15:48 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 10 Oct 2011 10:15:48 +0000
Subject: [issue13143] os.path.islink documentation is ambiguous
In-Reply-To: <1318221303.29.0.86938915547.issue13143@psf.upfronthosting.co.za>
Message-ID: <1318241748.99.0.119928134313.issue13143@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith, jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13143>
_______________________________________

From report at bugs.python.org  Mon Oct 10 13:20:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 10 Oct 2011 11:20:41 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1318245641.67.0.359478401119.issue1673007@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached an updated patch that addresses the comments of ?ric in the review and adds an entry to the whatsnew.

----------
assignee: orsenthil -> ezio.melotti
keywords: +needs review
nosy:  -BreamoreBoy
stage: patch review -> commit review
Added file: http://bugs.python.org/file23366/issue1673007.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Mon Oct 10 14:16:08 2011
From: report at bugs.python.org (Graeme Glass)
Date: Mon, 10 Oct 2011 12:16:08 +0000
Subject: [issue13144] Global Module Index link in the offline documentation is
	incorrect
Message-ID: <1318248968.6.0.0439422849007.issue13144@psf.upfronthosting.co.za>


New submission from Graeme Glass <graemeglass at gmail.com>:

On my machine (Ubuntu 11.04) the link to "Python Module Index" from the index page is incorrect in the "Indices and tables" section (it links to    
modindex.html instead of py-modindex.html).
It links to the correct place in the navigation bar at the top right of the page.

Navigation (Correct): 
<li class="right" >
    <a href="py-modindex.html" title="Python Module Index">modules</a> 
|</li>

In the body (Incorrect):
 <p><strong>Indices and tables:</strong></p>
  ...
  <p class="biglink"><a class="biglink" href="modindex.html">Global Module Index</a><br/
  ...

This seems to affect python2.6 and python2.7 documentation.

(Indices and tables) link for these files:
file:///usr/share/doc/python2.6/html/index.html
file:///usr/share/doc/python2.6-doc/html/index.html

Link to: 
file:///usr/share/doc/python2.6/html/modindex.html
file:///usr/share/doc/python2.6-doc/html/modindex.html

When they should link to:
file:///usr/share/doc/python2.6/html/py-modindex.html
file:///usr/share/doc/python2.6-doc/html/py-modindex.html

Likewise:
file:///usr/share/doc/python2.7/html/index.html
file:///usr/share/doc/python2.7-doc/html/index.html

Link to:
file:///usr/share/doc/python2.7/html/modindex.html
file:///usr/share/doc/python2.7-doc/html/modindex.html

When they should link to:
file:///usr/share/doc/python2.7/html/py-modindex.html
file:///usr/share/doc/python2.7-doc/html/py-modindex.html

I searched the python bug tracker for a similar issue and could not find one.
I do not know if this affects python3.x Documentation also as I do not have it installed so have not checked. 
I am not sure if this is an Ubuntu issue or Python Docs Issue.

----------
assignee: docs at python
components: Documentation
messages: 145295
nosy: docs at python, graemeglass
priority: normal
severity: normal
status: open
title: Global Module Index link in the offline documentation is incorrect
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13144>
_______________________________________

From report at bugs.python.org  Mon Oct 10 14:18:46 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 10 Oct 2011 12:18:46 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1318249126.07.0.0222640571596.issue13062@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No, the naming problem had occurred to me as well. Given the 'vars' builtin, perhaps 'getclosurevars' would do as the name?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13062>
_______________________________________

From report at bugs.python.org  Mon Oct 10 15:26:15 2011
From: report at bugs.python.org (Sven Marnach)
Date: Mon, 10 Oct 2011 13:26:15 +0000
Subject: [issue13145] Documentation of PyNumber_ToBase() wrong
Message-ID: <1318253175.42.0.981988907278.issue13145@psf.upfronthosting.co.za>


New submission from Sven Marnach <sven at marnach.net>:

The documentation of PyNumber_ToBase() [1] states

    When base is not 2, 8, 10, or 16, the format is 'x#num'
    where x is the base.

In reality, the function does not accept any bases different
from 2, 8, 10, or 16, as can be seen in the source code of 
_PyLong_Form() [2], which is called from PyNumber_ToBase() to
do the actual conversion.

The patch fixes the documentation.

[1]: http://docs.python.org/c-api/number.html#PyNumber_ToBase
[2]: http://hg.python.org/cpython/file/f924e0f62bcb/Objects/longobject.c#l1663

----------
assignee: docs at python
components: Documentation
files: pynumber-tobase-doc.patch
keywords: patch
messages: 145297
nosy: docs at python, smarnach
priority: normal
severity: normal
status: open
title: Documentation of PyNumber_ToBase() wrong
Added file: http://bugs.python.org/file23367/pynumber-tobase-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13145>
_______________________________________

From report at bugs.python.org  Mon Oct 10 15:42:37 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 10 Oct 2011 13:42:37 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
In-Reply-To: <1318245641.67.0.359478401119.issue1673007@psf.upfronthosting.co.za>
Message-ID: <CAPOVWORqK9gm0wkPNK-tgttWvcO_m9NFqJ7W9VojBb0CwOLH0Q@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Ezio, I had probably overlooked this one. But It's a very interesting one
for  me. Do you mind if I commit it ?
On Oct 10, 2011 7:20 PM, "Ezio Melotti" <report at bugs.python.org> wrote:

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> Attached an updated patch that addresses the comments of ?ric in the review
> and adds an entry to the whatsnew.
>
> ----------
> assignee: orsenthil -> ezio.melotti
> keywords: +needs review
> nosy:  -BreamoreBoy
> stage: patch review -> commit review
> Added file: http://bugs.python.org/file23366/issue1673007.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1673007>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe:
> http://mail.python.org/mailman/options/python-bugs-list/senthil%40uthcode.com
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Mon Oct 10 15:50:13 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 10 Oct 2011 13:50:13 +0000
Subject: [issue13143] os.path.islink documentation is ambiguous
In-Reply-To: <1318221303.29.0.86938915547.issue13143@psf.upfronthosting.co.za>
Message-ID: <1318254613.19.0.284459177103.issue13143@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks Garen for the detailed analysis and writeup. The short answer to your question is "supported by the Python runtime". Allow me to provide a bit of history.

Symlink awareness under Windows was added to Python in Python 3.2, so the behavior you see in Python 2.7 is somewhat historical - in particular, islink was implemented to always return False. In hindsight, this decision was probably a poor one, because it doesn't allow for forward compatibility.

Unfortunately, due to the compatibility rules of Python versions, this cannot change. The semantic meaning of ntpath.islink (and thus os.path.islink on Windows) cannot change.

The suggestion to update the documentation to reflect this behavior is  a good one. I will extend the Python 3.1 and earlier docs to clarify this detail.

One suggestion for the client: to accurately determine if the Python runtime supports symlinks, check hasattr(os, 'symlink'), whereafter you'll know if the runtime supports symlinks and whether os.link will return anything other than False.

----------
assignee:  -> jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13143>
_______________________________________

From report at bugs.python.org  Mon Oct 10 16:12:46 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 10 Oct 2011 14:12:46 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1318255966.1.0.385804614947.issue13062@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> perhaps 'getclosurevars' would do as the name?

I like vars.  Updated patch attached.

----------
Added file: http://bugs.python.org/file23368/issue13062-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13062>
_______________________________________

From report at bugs.python.org  Mon Oct 10 17:10:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 10 Oct 2011 15:10:39 +0000
Subject: [issue13143] os.path.islink documentation is ambiguous
In-Reply-To: <1318221303.29.0.86938915547.issue13143@psf.upfronthosting.co.za>
Message-ID: <1318259439.15.0.795626338793.issue13143@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Symlink awareness under Windows was added to Python in Python 3.2

If they are not available on Windows with 2.7, the doc should get an "availability: unix" or something similar (depending on where they are actually supported), or mention explicitly symlink for Windows are not supported.

> I will extend the Python 3.1 and earlier docs to clarify this detail.

3.1 only gets security fixes, so only 2.7/3.2/default should be updated.

----------
components: +Documentation
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13143>
_______________________________________

From report at bugs.python.org  Mon Oct 10 17:31:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Oct 2011 15:31:09 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1318260669.63.0.454888598815.issue1673007@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I made some more comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Mon Oct 10 17:31:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Oct 2011 15:31:56 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1318260716.48.0.925583127103.issue11776@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Mon Oct 10 17:35:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Oct 2011 15:35:19 +0000
Subject: [issue3902] Packages containing only extension modules have to
	contain __init__.py
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1318260919.66.0.32441872883.issue3902@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You did not reply to my first question on apiref.rst, and you did not rewrap your lines to 80 chars :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Mon Oct 10 17:38:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Oct 2011 15:38:14 +0000
Subject: [issue13055] Distutils tries to handle null versions but fails
In-Reply-To: <1317238322.67.0.925527851228.issue13055@psf.upfronthosting.co.za>
Message-ID: <1318261094.02.0.0749187178182.issue13055@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The bug was encountered while trying to install a package. As it turns
> out, a dependency was incorrectly installed, resulting in a null
> version being passed around which quickly caused a crash in setup.py.
> While this is definitely not a normal circumstance, the fact that this
> bug existed made finding the issue substantially more time consuming.
I agree.  You don?t happen to have the log available, do you?

> If the constructor of the LooseVersion can accept None, then so should
> its other members.
Sure.  From a quick glance, we need to fix __str__ and _cmp.

----------
keywords: +easy -patch
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13055>
_______________________________________

From report at bugs.python.org  Mon Oct 10 17:41:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Oct 2011 15:41:42 +0000
Subject: [issue2945] bdist_rpm does not list dist files (should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <1318261302.77.0.434623868097.issue2945@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.  Do you have rpm on your machine?  If yes, have you run the tests successfully?

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2945>
_______________________________________

From report at bugs.python.org  Mon Oct 10 17:42:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Oct 2011 15:42:58 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1318261378.2.0.28991135849.issue12436@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, I will take all contributions and suggestions and propose one patch.

----------
assignee: docs at python -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Mon Oct 10 17:50:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Oct 2011 15:50:03 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318261803.38.0.558368564129.issue12602@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> For new doc editors, it would be nicer if the filename (directory name, actually)
> had been changed to 'py_setup' or even 'py_usage'.
py_setup would conflict with pysetup, the installer part of distutils2/packaging.  py_ seems redundant to me, we are in the Python docs.

> Looking in the first chapter, which you finally referenced, I do see an entry for
> '<script>', with the brackets, that can be both a target and container of links. That
> usage, with a generic argument name in angle brackets, may be unique in the docs. (I
> looked at trace, profile, pydoc, timeit, test, and doctest docs.) So don't be so
> surprised that others are not familiar with it. 
I however am familiar with the use of <brackets>, $SHELL-LIKE-DOLLAR, OPTPARSE-LIKE-ALLCAPS or even {str-format-like-braces} to mark up metavariables.  ?Use python -m <module> or python -c "YOUR CODE HERE" or python path/to/script? is no problem; maybe it is because other documentation (man pages?) I?m familiar with use it.  (I even see them in email, like in ?$deity knows etc.?)

> +1 on the links suggested in the original message.
I?ll put up a patch for review.

> -1 on a link to the tracker issue.
I?ll see if I can add a few lines with the gist of the bug report, then.

----------
assignee:  -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Mon Oct 10 18:00:19 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 10 Oct 2011 16:00:19 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1318262419.42.0.246264413161.issue13062@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In reviewing Meador's patch (which otherwise looks pretty good), I had a thought about the functionality and signature of getclosurevars().

Currently, it equates "closure" to "nonlocal scope", which isn't really true - the function's closure is really the current binding of *all* of its free variables, and that includes globals and builtins in addition to the lexically scoped variables from outer scopes.

So what do people think about this signature:

  ClosureVars = namedtuple("ClosureVars", "nonlocals globals builtins unbound")
  def getclosurevars(func):
    """Returns a named tuple of dictionaries of the current nonlocal, global and builtin references as seen by the body of the function. A final set of unbound names is also provided."""
    # figure out nonlocal_vars (current impl)
    # figure out global_vars (try looking up names in f_globals)
    # figure out builtin_vars (try looking up names in builtins)
    # any leftover names go in unbound_vars
    return ClosureVars(nonlocal_vars, global_vars, builtin_vars, unbound_vars)

Also, something that just occurred to me is that getclosurevars() should work for already instantiated generator iterators as well as generator functions, so the current typecheck may need to be made a bit more flexible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13062>
_______________________________________

From report at bugs.python.org  Mon Oct 10 19:43:21 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 10 Oct 2011 17:43:21 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>
Message-ID: <1318268601.52.0.446959870111.issue12393@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Can you add tests?

https://bitbucket.org/vinay.sajip/pythonv/changeset/f7c5098e3c3b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Mon Oct 10 19:51:50 2011
From: report at bugs.python.org (M. Zilmer)
Date: Mon, 10 Oct 2011 17:51:50 +0000
Subject: [issue13119] Newline for print() is \n on Windows,
	and not \r\n as expected
In-Reply-To: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za>
Message-ID: <1318269110.56.0.0174887622039.issue13119@psf.upfronthosting.co.za>


M. Zilmer <mzdkmail at gmail.com> added the comment:

Just to make it clear: I have not observed any problems on the Windows terminal (cmd) with \n newline, but at least Notepad does not break lines correctly if only \n is used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13119>
_______________________________________

From report at bugs.python.org  Mon Oct 10 20:47:40 2011
From: report at bugs.python.org (Mike Hoy)
Date: Mon, 10 Oct 2011 18:47:40 +0000
Subject: [issue3902] Packages containing only extension modules have to
	contain __init__.py
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1318272460.29.0.0857532911323.issue3902@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

Responded to first question in apiref and uploaded a new patch that wraps lines at 80 characters.

----------
Added file: http://bugs.python.org/file23369/apiref-setupscript-v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Mon Oct 10 20:49:13 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 10 Oct 2011 18:49:13 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1318272553.39.0.786872969995.issue8087@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Mon Oct 10 21:13:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 10 Oct 2011 19:13:37 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318274017.29.0.0809827571081.issue12602@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I was not necessary suggesting that the filename actually be changed, just that the mapping between docs and filenames is not always obvious. I will somedays look at the dev docs doc page and see if I have any further suggestions to help.

Add 'in the Python doc context' after 'not familiar with it'. I *am* familiar with <text> in monofont ascii text and use it, for instance, in newsgroup posts. But unlike man pages, the Python docs are not so restricted and, except in this instance, use italics for parameter names. I suggest that it do so in this instance also, using *script* (in bold-faced italic) as the entry title.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Mon Oct 10 21:37:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 Oct 2011 19:37:55 +0000
Subject: [issue13146] Writing a pyc file is not atomic
Message-ID: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

One of the buildbots recently showed the following failure:

======================================================================
ERROR: test_rapid_restart (test.test_multiprocessing.WithProcessesTestManagerRestart)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_multiprocessing.py", line 1442, in test_rapid_restart
    queue = manager.get_queue()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/managers.py", line 670, in temp
    token, exp = self._create(typeid, *args, **kwds)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/managers.py", line 568, in _create
    conn = self._Client(self._address, authkey=self._authkey)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/connection.py", line 778, in XmlClient
    import xmlrpc.client as xmlrpclib
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/xmlrpc/client.py", line 137, in <module>
    import http.client
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/http/client.py", line 69, in <module>
    import email.parser
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/email/parser.py", line 12, in <module>
    from email.feedparser import FeedParser
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/email/feedparser.py", line 28, in <module>
    from email import policy
EOFError: EOF read where not expected

(http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/942/steps/test/logs/stdio)

"EOF read where not expected" comes from reading a pyc file in marshal.c. It is raised when the pyc file is somehow truncated or incomplete. Writing and reading the same pyc file is protected by the import lock when in a single interpreter, but not when running several Python processes at the same time (which test_multiprocessing obviously does).

Under POSIX, import.c could do the traditional write-then-rename dance which guarantees that the file contents appear atomically.
And so could importlib.

----------
components: Interpreter Core
messages: 145313
nosy: brett.cannon, ncoghlan, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: Writing a pyc file is not atomic
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Mon Oct 10 21:52:30 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 10 Oct 2011 19:52:30 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1318276350.5.0.661653133644.issue12659@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

The patch is updated. Let me know if I've understood your review.
Thanks !

----------
Added file: http://bugs.python.org/file23370/issue12659_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Mon Oct 10 22:20:02 2011
From: report at bugs.python.org (Ron Adam)
Date: Mon, 10 Oct 2011 20:20:02 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1318278002.29.0.666118834429.issue13062@psf.upfronthosting.co.za>


Changes by Ron Adam <ron3200 at gmail.com>:


----------
nosy: +ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13062>
_______________________________________

From report at bugs.python.org  Tue Oct 11 00:49:16 2011
From: report at bugs.python.org (Ben Gamari)
Date: Mon, 10 Oct 2011 22:49:16 +0000
Subject: [issue13055] Distutils tries to handle null versions but fails
In-Reply-To: <1317238322.67.0.925527851228.issue13055@psf.upfronthosting.co.za>
Message-ID: <1318286956.44.0.173322498135.issue13055@psf.upfronthosting.co.za>


Ben Gamari <bgamari at gmail.com> added the comment:

Sorry, no log is available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13055>
_______________________________________

From report at bugs.python.org  Tue Oct 11 01:37:50 2011
From: report at bugs.python.org (Jakub Gedeon)
Date: Mon, 10 Oct 2011 23:37:50 +0000
Subject: [issue13147] Multiprocessing Pool.map_async() does not have an
	error_callback parameter
Message-ID: <1318289870.89.0.681252830912.issue13147@psf.upfronthosting.co.za>


New submission from Jakub Gedeon <kazagistar at gmail.com>:

Multiprocessing Pool.map_async() does not have an error_callback paramter as described here http://docs.python.org/library/multiprocessing.html#multiprocessing.pool.multiprocessing.Pool.map_async

I assume this is an old configuration that no longer works... I tried to call that parameter by name and I got a Type Error, plus the actual documentation does not mention it at all (and it is missing from similar functions). Recommend it be removed from the documentation, or else better described and implemented.

----------
assignee: docs at python
components: Documentation
messages: 145316
nosy: Jakub.Gedeon, docs at python
priority: normal
severity: normal
status: open
title: Multiprocessing Pool.map_async() does not have an error_callback parameter
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13147>
_______________________________________

From report at bugs.python.org  Tue Oct 11 02:42:13 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 11 Oct 2011 00:42:13 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1318293733.8.0.842227755788.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

*Very* good news for lzma on windows: The precompiled static library liblzma.a works very well with MSVC (tested with VS2008 on Windows XP, 32bit).  This was a surprise for me...

Here is a patch for the win32 build files, to be applied after Nadeem's.
I did not update the svn "external" repository, for my local copy I simply extracted xz-5.0.3-windows.zip.
Tests pass in release and debug builds, and depends.exe shows no special requirements for _lzma.pyd.  I could not test win64.

Nadeem, in test.support precisionbigmemtest was recently renamed to bigmemtest, could you update your patch?

----------
Added file: http://bugs.python.org/file23371/lzma-win32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct 11 02:45:36 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Oct 2011 00:45:36 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318293936.12.0.82328975529.issue12602@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Don't feel bad about not recognising the context - this stuff wasn't documented at all for a long time, and it wasn't until Georg pointed me to the usage docs that I realised adding it there would be the right place. I should have remembered that and been less cryptic when creating this issue.

It may suggest a meta-issue though - perhaps 'Documenting Python' should grow a devguide-style description of the Docs layout in source control, with a pointer from the devguide's directory layout description [1]?

[1] http://docs.python.org/devguide/setup.html#directory-structure

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Tue Oct 11 02:45:48 2011
From: report at bugs.python.org (Maxim Yanchenko)
Date: Tue, 11 Oct 2011 00:45:48 +0000
Subject: [issue13148] simple bug in mmap size check
Message-ID: <1318293948.21.0.819256952944.issue13148@psf.upfronthosting.co.za>


New submission from Maxim Yanchenko <maxim.yanchenko at gs.com>:

The condition contradicts the exception text:
            if (offset >= st.st_size) {
                PyErr_SetString(PyExc_ValueError,
                                "mmap offset is greater than file size");
                return NULL;
            }
The condition should be changed to (offset > st.st_size), similar to the later condition which is correct:
        } else if (offset + (size_t)map_size > st.st_size) {
            PyErr_SetString(PyExc_ValueError,
                            "mmap length is greater than file size");
            return NULL;
        }

The patch is attached.

----------
components: Library (Lib)
files: mmap-greater.patch
keywords: patch
messages: 145319
nosy: jazzer
priority: normal
severity: normal
status: open
title: simple bug in mmap size check
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23372/mmap-greater.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13148>
_______________________________________

From report at bugs.python.org  Tue Oct 11 02:59:09 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 11 Oct 2011 00:59:09 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1267784862.24.0.455687340788.issue8065@psf.upfronthosting.co.za>
Message-ID: <1318294749.15.0.819967432741.issue8065@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

As a note for future reference, FreeBSD/NetBSD/OpenBSD doesn't use the term "bug", but instead uses the term "problem report" (the NetBSD website says "bug" though BTW).

The PR system for NetBSD can be accessed here: http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd .

----------
nosy: +yaneurabeya

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________

From report at bugs.python.org  Tue Oct 11 03:04:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 01:04:21 +0000
Subject: [issue13148] simple bug in mmap size check
In-Reply-To: <1318293948.21.0.819256952944.issue13148@psf.upfronthosting.co.za>
Message-ID: <1318295061.46.0.150042102739.issue13148@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, you have to understand what this code does: it tries to prevent non-meaningful offsets. If the offset is equal to the file size, mapping from that offset would not map anything in the file (and the system call may actually fail).

----------
nosy: +pitrou
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13148>
_______________________________________

From report at bugs.python.org  Tue Oct 11 03:17:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 01:17:34 +0000
Subject: [issue13149] optimization for append-only StringIO
Message-ID: <1318295854.61.0.959309073941.issue13149@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

io.StringIO is quite slower than ''.append() when used for mass concatenation (around 5x slower). This patch brings it to similar performance by deferring construction of the internal buffer until needed.

The problem is that it's very easy to disable the optimization by calling a method other than write() and getvalue().

----------
components: IO
files: stringio.patch
keywords: patch
messages: 145322
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: optimization for append-only StringIO
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file23373/stringio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13149>
_______________________________________

From report at bugs.python.org  Tue Oct 11 03:27:27 2011
From: report at bugs.python.org (Maxim Yanchenko)
Date: Tue, 11 Oct 2011 01:27:27 +0000
Subject: [issue13148] simple bug in mmap size check
In-Reply-To: <1318293948.21.0.819256952944.issue13148@psf.upfronthosting.co.za>
Message-ID: <1318296447.11.0.0581843901222.issue13148@psf.upfronthosting.co.za>


Maxim Yanchenko <maxim.yanchenko at gs.com> added the comment:

First of all, it doesn't fail (at least on Linux), I tested it before posting.

And the latest, it's not like I'm just stalking around and reading Python sources for fun. It's a real and pretty valid case, I hit it while upgrading our production code to python 2.7.
I'm using NumPy (linear algebra module) that uses Python's core mmap module under the hood.
In NumPy, it's pretty valid to have arrays of size 0.
I have a file with a fixed-size header that holds size of the array and some other meta-data. I mmap this file as a NumPy array using the offset equal to header size. Of course, if there is no data in the array then the file will be just header, and the offset will be equal to the size of the file - here is where this bug hits us as I can't load this file with Python 2.7.2 anymore (while I was able to with Python 2.5).
This patch fixes this and everything works as expected, giving an array with zero dimensions ('shape' in terms of NumPy):
>>> x.shape
(0,)
>>> x.size
0

Please kindly consider applying the patch.

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13148>
_______________________________________

From report at bugs.python.org  Tue Oct 11 03:31:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 01:31:41 +0000
Subject: [issue13148] simple bug in mmap size check
In-Reply-To: <1318293948.21.0.819256952944.issue13148@psf.upfronthosting.co.za>
Message-ID: <1318296701.4.0.329135724532.issue13148@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think it makes sense to accept mmap'ing empty contents when at offset "n" but not at offset "n + 1". Either we remove the check entirely and let people deal with the consequences, or we keep the check as-is.

----------
nosy: +neologix
stage: committed/rejected -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13148>
_______________________________________

From report at bugs.python.org  Tue Oct 11 03:52:13 2011
From: report at bugs.python.org (Maxim Yanchenko)
Date: Tue, 11 Oct 2011 01:52:13 +0000
Subject: [issue13148] simple bug in mmap size check
In-Reply-To: <1318293948.21.0.819256952944.issue13148@psf.upfronthosting.co.za>
Message-ID: <1318297933.7.0.158791258794.issue13148@psf.upfronthosting.co.za>


Maxim Yanchenko <maxim.yanchenko at gs.com> added the comment:

Well, "n+1" is clearly outside the file, wile "n" is within and therefore valid.

Also, if your position is to forbid zero-size mmapping completely, then the checks inside "if (map_size == 0) {" don't make any sense, especially as they may or may fail.
>From the existing code, zero-size mmapping is OK as long as offset is OK, so the question is whether we consider offset pointing to the end of the file OK. To me, it's fine and valid, and there are valid cases like NumPy's zero-size arrays, hence the proposed patch.

Removing the check completely is a viable option too, it was already requested for special files:
http://bugs.python.org/issue12556

I believe users should have an ability to enjoy whatever their OS provides, and "deal with the consequences" as you said.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13148>
_______________________________________

From report at bugs.python.org  Tue Oct 11 04:10:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 11 Oct 2011 02:10:05 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1318299005.59.0.379407487123.issue12753@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file23365/issue12753-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Tue Oct 11 04:11:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 11 Oct 2011 02:11:03 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1318299063.6.0.804003650389.issue12753@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file23374/issue12753-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Tue Oct 11 04:12:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 02:12:22 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za>
Message-ID: <1318299142.96.0.957625782504.issue13146@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch for import.c.

----------
keywords: +patch
Added file: http://bugs.python.org/file23375/importrename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Tue Oct 11 04:15:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 11 Oct 2011 02:15:23 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1318299323.1.0.654749335121.issue12753@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

(I had to re-upload the patch a couple of time to get the review button to work.  Apparently if there are some conflicts rietveld fails to apply the patch, whereas hg is able to merge files without problems here.  Sorry for the noise.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Tue Oct 11 04:38:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 11 Oct 2011 02:38:12 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1318300692.28.0.327499486008.issue1673007@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: ezio.melotti -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Tue Oct 11 05:02:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 03:02:58 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
Message-ID: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

sysconfig is imported and used by site.py.

$ time ./python -S -c ''

real	0m0.019s
user	0m0.013s
sys	0m0.005s

$ time ./python -S -c 'import sysconfig'

real	0m0.047s
user	0m0.046s
sys	0m0.002s

$ time ./python -S -c 'import sysconfig; sysconfig.get_path("purelib")'

real	0m0.053s
user	0m0.047s
sys	0m0.005s

$ time ./python -c ''

real	0m0.058s
user	0m0.054s
sys	0m0.003s

----------
messages: 145328
nosy: eric.araujo, ncoghlan, pitrou, tarek, terry.reedy
priority: normal
severity: normal
status: open
title: Most of Python's startup time is sysconfig
type: performance
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 11 05:04:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 11 Oct 2011 03:04:20 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318302260.79.0.272836046557.issue13150@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 11 05:56:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 11 Oct 2011 03:56:53 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1318305413.17.0.412047106446.issue1673007@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

We have discussed the API a bit on IRC and these are the outcomes:

1) should method always have priority or should 'POST' always be used whenever data is passed?
2) if the method is e.g. 'GET' and data is passed, should an error be raised?
3) should Request.method be private?
4) should the value of Request.method be initialized in the __init__ or can it also be None?
5) if the value of Request.method is always initialized, should we deprecate get_method?

IMHO

  r = Request(url, data, method=foo)

should behave like

  class FooRequest(Request):
      def get_method(self):
          return foo
  r = FooRequest(url, data)

when foo is not None and

  class FooRequest(Request): pass
  r = FooRequest(url, data)

when foo is None, so the answers to the 5 questions would be

1) method always has the highest priority, data is used to decide between GET and POST when method is None;
2) data is simply ignored if the method doesn't use it -- no errors are raised;
3) maybe, currently is not (see below);
4) method matches the value passed to the constructor, defaulting to None;
5) since it's not initialized, get_method shouldn't be deprecated;

This is also what the patch implements.

Regarding 3), one might look at Request.method and see None instead of GET/POST, and this might be confusing.  We could document that get_method() should be used instead to see what method will be actually used or make Request.method private and avoid the problem.  If we do so there won't be a way to change the method after instance creation (but that wasn't even supported before[0], so it's probably not a problem).  OTOH, the other args (e.g. data) are available and documented.  I'm fine with either documenting that get_method() should be used instead or making Request.method private.

Another approach is to move the get_method() logic in the __init__, set self.method to method (if specified) or either POST (if there are data) or GET.  Then have get_method() simply return self.method (and possibly deprecate it).

[0]: it's actually possible to replace the get_method() method, but if Request.method is public one could set it to a new value or to None to restore the normal behavior (GET or POST depending on data).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Tue Oct 11 06:11:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Oct 2011 04:11:55 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318306315.66.0.203566685451.issue12602@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

That was the page I said I would look at. My suggest is that one or more of the directory entries could have either a bit more information about the directory or a "More info" link to a separate page. As a remember, files for modules were named after the module and easy to find. Those could be disposed of in one sentence. But files for the manuals were less so and could use more info.

My memory of Objects is that most files were obvious but, again, a few were/are not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Tue Oct 11 07:42:18 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 11 Oct 2011 05:42:18 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1318311738.75.0.304320838032.issue1673007@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Our discussion stemmed from this point. If you look at the change proposed, Request class is taking a new parameter by name 'method' and it is initialized to None:

 class Request:

     def __init__(self, url, data=None, headers={},
-                 origin_req_host=None, unverifiable=False):
+                 origin_req_host=None, unverifiable=False,
+                 method=None):

But that actually defaults to GET method in terms of HTTP request for often used scenarios where the only required parameter (url) is sent.

This happens in the get_method call:

     def get_method(self):
-        if self.data is not None:
+        """Return a string indicating the HTTP request method."""
+        if self.method is not None:
+            return self.method
+        elif self.data is not None:
             return "POST"
         else:
             return "GET"

Since, it is understood that the default action of Request(url) is to do a GET, I proposed that we have Request's method parameter default to GET instead of None, so the change would look like:

 class Request:

     def __init__(self, url, data=None, headers={},
-                 origin_req_host=None, unverifiable=False):
+                 origin_req_host=None, unverifiable=False,
+                 method="GET"):

And it is more meaningful when someone is looking at the Request  signature. Specifying method=None and implicitly meaning it as "GET" for normal situations was not intuitive to me. (This is not case when we do not pass an explicit method arg).

At this point, Ezio's summary of API changes discussed becomes interesting.  I read again and it seems to me that, the assumption is get_method is an important method which determines what method should be used and method should be given preference over data.

My point is, get_method is an useful, helper function that is helpful is sending the correct method to the http.client code which does the actual task.  In the current situation, get_method "determines" based on data parameter should it send a "GET" or a "POST", but if we start using method=arg then, get_method should just return what was initialized by the method arg (defaulting to "GET").

2) The next problem comes when a user has specified both data and method="GET". This becomes an invalid scenario, but a decision has been to taken as what should be given preference? 

- As the user has sent "data", should the request be considered a POST?

- But user specified it as "GET" (intentionally or by mistake), so should the data not be used and Request should do only a GET?

- Or should we throw an error?

My personal on this is -1 on throwing an error and when data is sent, just do the POST (data overrides method).

BTW, this needs to discussed irrespective of point 1). But having method="GET" could give raise to his scenario more often. A person would just send data and forget about changing the method to "POST".

Coming to specific questions which Ezio pointed:

My take:

1) should method always have priority or should 'POST' always be used whenever data is passed?

If data is passed use POST.

2) if the method is e.g. 'GET' and data is passed, should an error be raised?

Nope, give data the priority and do POST. (As urllib is currently doing)

3) should Request.method be private?

Not necessarily, it should  be public.


4) should the value of Request.method be initialized in the __init__ or can it also be None?

My take - It should be initialized to default (GET), instead of None.

5) if the value of Request.method is always initialized, should we deprecate get_method?

This is an interesting question. get_method essentially becomes less useful or it could serve as an arbiter when data and GET is sent and may be used as reliable way to get the Request's method. It should not be deprecated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Tue Oct 11 08:02:53 2011
From: report at bugs.python.org (Maxim Yanchenko)
Date: Tue, 11 Oct 2011 06:02:53 +0000
Subject: [issue13148] simple bug in mmap size check
In-Reply-To: <1318293948.21.0.819256952944.issue13148@psf.upfronthosting.co.za>
Message-ID: <1318312973.05.0.648859122062.issue13148@psf.upfronthosting.co.za>


Maxim Yanchenko <maxim.yanchenko at gs.com> added the comment:

tried on newer Linux - crashes with my patch.
So I'll be thinking about a workaround, probably a fix for NumPy to avoid using mmap in such cases but still provide uniform interface to avoid making special conditional handling in all my scripts.
Therefore, I'm no longer pushing for this change, I will need another workaround anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13148>
_______________________________________

From report at bugs.python.org  Tue Oct 11 08:28:49 2011
From: report at bugs.python.org (Carl Robben)
Date: Tue, 11 Oct 2011 06:28:49 +0000
Subject: [issue2945] bdist_rpm does not list dist files (should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <1318314529.18.0.957535146363.issue2945@psf.upfronthosting.co.za>


Carl Robben <carl.robben at gmail.com> added the comment:

Yeah I installed rpm and have run the tests successfully.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2945>
_______________________________________

From report at bugs.python.org  Tue Oct 11 09:45:58 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 11 Oct 2011 07:45:58 +0000
Subject: [issue13148] simple bug in mmap size check
In-Reply-To: <1318293948.21.0.819256952944.issue13148@psf.upfronthosting.co.za>
Message-ID: <1318319158.35.0.502546091625.issue13148@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The condition contradicts the exception text:

Why?
The offset is zero-based, so 0 <= offset < size is a valid check.

> First of all, it doesn't fail (at least on Linux), I tested it before 
> posting.

Hmmm.
You got lucky, since the offset must be a multiple of the page size.

> tried on newer Linux - crashes with my patch.

That's exactly why we perform such checks. Here's what POSIX says:
"""
[EINVAL]
The addr argument (if MAP_FIXED was specified) or off is not a multiple of the page size as returned by sysconf(), or are considered invalid by the implementation.
[ENXIO]
Addresses in the range [off, off + len) are invalid for the object specified by fildes.
"""

Since we usually want to avoid implementation-defined behavior (and crashes), I think it's better to stick with the current checks (note that issue #12556 concerned a really corner case: /proc entries supporting mmap but reporting a zero-length).

> Therefore, I'm no longer pushing for this change, I will need another 
> workaround anyway.

Alright, closing then.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13148>
_______________________________________

From report at bugs.python.org  Tue Oct 11 11:01:27 2011
From: report at bugs.python.org (Patrick Westerhoff)
Date: Tue, 11 Oct 2011 09:01:27 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1318323687.64.0.970390633638.issue1673007@psf.upfronthosting.co.za>


Patrick Westerhoff <PatrickWesterhoff at gmail.com> added the comment:

Senthil, I highly disagree with what you said:

> The next problem comes when a user has specified both data and method="GET".
> This becomes an invalid scenario, but a decision has been to taken as what
> should be given preference?
That is incorrect, RFC2616 states that the server should ignore the message body when the request method does not define any semantics for it, but there is nothing that makes the inclusion of a message body along with the GET request method invalid.

> - As the user has sent "data", should the request be considered a POST?
No, absolutely not. Sending data via other request methods, like DELETE or PUT, is semantically correct and should be supported completely if we are going to include a way to set the request method. If I set the method to PUT, and include data, I don?t want the library to override that to POST just because I set data.

> - But user specified it as "GET" (intentionally or by mistake), so should the
> data not be used and Request should do only a GET?
If I data is included and the request method is explicitely set to GET, make a GET request and include the data in the request body. It might not be a semantically good decision to send data over GET, but it still is not disallowed and as such should be possible (for whatever reasons).

> - Or should we throw an error?
We especially should?t throw an error, as this is not invalid at all.

> A person would just send data and forget about changing the method to "POST".
I agree that the library should still default to POST if data is included and the request method was not explicitely set (see also below).
> 1) should method always have priority or should 'POST' always be used whenever
>    data is passed?
> If data is passed use POST.
No, if data is passed and no special method is set, use POST, otherwise use the method the user specified, because that is what he expects.

> 2) if the method is e.g. 'GET' and data is passed, should an error be raised?
> Nope, give data the priority and do POST. (As urllib is currently doing)
Don't give data any priority if the method was set explicitely. Otherwise the ability to set a custom method is totally useless, especially with request methods where a message body is semantically useful (i.e. all other than HEAD and GET).

> 3) should Request.method be private?
> Not necessarily, it should  be public.
Depends on the way the method will be set. Looking at the way, the other request parameters are set (especially with the accessors being ?deprecated?), it makes sense to leave this public.

> 4) should the value of Request.method be initialized in the __init__ or can it
>    also be None?
> My take - It should be initialized to default (GET), instead of None.
Initializing it to GET will make the implementation difficult, especially if we want to continue supporting the behaviour of setting the method to POST when data is changed (and the method was not explicitely set). Unless we override the built-in property accessors I don?t think this is possible.

> 5) if the value of Request.method is always initialized, should we deprecate
>    get_method?
> This is an interesting question. get_method essentially becomes less useful or
> it could serve as an arbiter when data and GET is sent and may be used as
> reliable way to get the Request's method. It should not be deprecated.
To my understanding, and this is also why I provided the same patch on the duplicate bug, `get_method` is used by the other libraries to get the used request method. Unless we change the other libraries to determine the method in a different way, deprecating `get_method` won?t get us anywhere.

What I tried to respect with the patch, and I think this was also Denver?s intention, is to add this functionality without breaking the current behaviour. That behaviour is that GET is default, and POST is set as default if there is any data. The functionality requires that the request method can be set (and the default behaviour can be overriden) without looking at the data (as explained above).

Ideally I would probably like to see the functionality of `get_method` done in another library, which performs the request. I.e. check `request.method` and use that if it?s set, otherwise check `request.data` and choose either POST or GET. But again this would require far too many changes in other libraries for this simple change.

And again on the `data` property: I think the name ?data? is a bit confusing. Request does not provide any encoding details on that ?data?, and it is actually just the request body in its original form. What I usually do in my subclass of Request is to provide a way to encode the data I pass to the constructor (often even with multipart encoding for file streams), while the `request.data` attribute to me still means ?request body?.


Regarding those questions on the implementation, I agree with Ezio, and as I said this is probably the only way to add this functionality without breaking previous usages. And if we break previous usages (or restrict its functionality with weird priority rules based on the data), we better not add this functionality at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Tue Oct 11 11:10:55 2011
From: report at bugs.python.org (Maxim Yanchenko)
Date: Tue, 11 Oct 2011 09:10:55 +0000
Subject: [issue13148] simple bug in mmap size check
In-Reply-To: <1318293948.21.0.819256952944.issue13148@psf.upfronthosting.co.za>
Message-ID: <1318324255.07.0.00919573279465.issue13148@psf.upfronthosting.co.za>


Maxim Yanchenko <maxim.yanchenko at gs.com> added the comment:

> You got lucky, since the offset must be a multiple of the page size.
That's why our header is exactly the page size :)

> Here's what POSIX says
Then it's just another discrepancy between POSIX and Linux, as I received ENOMEM instead of EINVAL (RHEL6 on 2.6.32).


Regarding the contradiction, it's probably still worth changing the exception message to "mmap offset is greater than _or equal to_ file size", to match the condition. Just 'greater than' means the '>' check, not the '>=' check from the code, mathematically.

----------
resolution: rejected -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13148>
_______________________________________

From report at bugs.python.org  Tue Oct 11 11:32:26 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 11 Oct 2011 09:32:26 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318325546.82.0.538707496049.issue13150@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 11 12:02:08 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 11 Oct 2011 10:02:08 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1318327328.9.0.464501410897.issue1673007@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Patrick, 

Lots of valid points. I had not looked at the RFC spec when I mentioned about data over request (GET) method, but was trying to derive the current functionality of module (so that users can have a seamless experience) with additional method="GET" as default.  Note, my intention was to be explicit when we give method arg.

But yeah, when user has specified the methods (PUT/DELETE etc) and given the data, correct rules should apply on how that method should deal with data.

As you pointed out to RFC, I realize RFC clearly points out the data (message-body) should be ignored and method should be given preference, whenever specification of method has nothing to with data.  I should take back my argument on giving data as preference even over GET.

Now, question arises- Can we in anyway default the method="GET" and maintain compatibility as well consistency with user expectations? At the moment, just by sending data over Request, the method is assumed to be POST. If that is not possible, then the way, current patch does seems to be a good way to acheive the purpose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Tue Oct 11 12:03:33 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 11 Oct 2011 10:03:33 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1318327413.31.0.63298674751.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Awesome stuff! I'll post an updated patch during the course of the day.

Martin: I've been having problems with Rietveld lately, so I'm posting
my replies to your comments here instead.

>> Modules/_lzmamodule.c:115: return _PyBytes_Resize(buf, size + BIGCHUNK);
> This has quadratic performance.

Correct. I copied the algorithm from _io.FileIO, under the assumption
that there was a reason for not using a simpler O(n log n) doubling
strategy. Do you know of any reason for this? Or is it safe to ignore it?

>> Modules/_lzmamodule.c:364: Py_BEGIN_ALLOW_THREADS
> It seems that the Windows version at least is not thread-safe. If so, you
> would need an LZMA lock when releasing the GIL.

Does the class need to be thread-safe, though? ISTM that there isn't any
sensible use case for having two threads feeding data through the same
compressor concurrently.

(If we *do* want thread-safety, then it doesn't matter whether the
underlying lib is internally thread-safe or not. We would still need to
guard against the possibility of the _lzmamodule.c code in one thread
modifying the lzma_stream's input or output pointer while lzma_code is
operating on the stream's data in another thread.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct 11 13:12:18 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 11 Oct 2011 11:12:18 +0000
Subject: [issue13151] pysetup3 run bdist_wininst fails
Message-ID: <1318331538.35.0.635641564623.issue13151@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

When you run

pysetup3 run bdist_wininst

in a project directory with a valid setup.cfg, it fails with

error: Invalid command install

after the build, build_py and build_scripts steps.

For info, pysetup3 run bdist_dumb runs without error.

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 145339
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: pysetup3 run bdist_wininst fails
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13151>
_______________________________________

From report at bugs.python.org  Tue Oct 11 13:39:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 11:39:03 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1318327413.31.0.63298674751.issue6715@psf.upfronthosting.co.za>
Message-ID: <1318332919.3277.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> >> Modules/_lzmamodule.c:115: return _PyBytes_Resize(buf, size + BIGCHUNK);
> > This has quadratic performance.
> 
> Correct. I copied the algorithm from _io.FileIO, under the assumption
> that there was a reason for not using a simpler O(n log n) doubling
> strategy. Do you know of any reason for this? Or is it safe to ignore it?

I don't know, but I'd say it's safe to ignore it.
Maybe open a separate bug about that.
Generally we use a less-than-doubling strategy, to conserve memory (see
e.g. bytearray.c).

(note: it is O(n), not O(n log n))

> >> Modules/_lzmamodule.c:364: Py_BEGIN_ALLOW_THREADS
> > It seems that the Windows version at least is not thread-safe. If so, you
> > would need an LZMA lock when releasing the GIL.
> 
> Does the class need to be thread-safe, though? ISTM that there isn't any
> sensible use case for having two threads feeding data through the same
> compressor concurrently.

We certainly want to avoid crashes so, if that's what one risks from
using lzma from several threads, we should protect against it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Oct 11 15:05:00 2011
From: report at bugs.python.org (John Feuerstein)
Date: Tue, 11 Oct 2011 13:05:00 +0000
Subject: [issue13152] textwrap: support custom tabsize
Message-ID: <1318338300.67.0.514985359705.issue13152@psf.upfronthosting.co.za>


New submission from John Feuerstein <john at feurix.com>:

The textwrap module calls .expandtabs() to expand tabs to spaces.

This patch adds support for a custom tabsize, so that .expandtabs(tabsize) is called instead.

Includes test case.

----------
components: Library (Lib)
files: textwrap_tabsize.diff
keywords: patch
messages: 145341
nosy: jfeuerstein
priority: normal
severity: normal
status: open
title: textwrap: support custom tabsize
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23376/textwrap_tabsize.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13152>
_______________________________________

From report at bugs.python.org  Tue Oct 11 15:13:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 11 Oct 2011 13:13:54 +0000
Subject: [issue13152] textwrap: support custom tabsize
In-Reply-To: <1318338300.67.0.514985359705.issue13152@psf.upfronthosting.co.za>
Message-ID: <1318338834.27.0.00296264298086.issue13152@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review
nosy: +georg.brandl
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13152>
_______________________________________

From report at bugs.python.org  Tue Oct 11 15:37:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 13:37:05 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318340225.12.0.50024554995.issue13150@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, a big part of that is compiling some regexes in the tokenize module. Just relying on the re module's internal caching shaves off 20% of total startup time.

Before:

$ time ./python -S -c 'import tokenize'

real	0m0.034s
user	0m0.030s
sys	0m0.003s
$ time ./python -c ''

real	0m0.055s
user	0m0.050s
sys	0m0.005s

After:

$ time ./python -S -c 'import tokenize'

real	0m0.021s
user	0m0.019s
sys	0m0.001s
$ time ./python -c ''

real	0m0.044s
user	0m0.038s
sys	0m0.006s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 11 15:44:48 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 11 Oct 2011 13:44:48 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1318340688.53.0.778980394001.issue10976@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'll just mention that the elimination of bytes handling is a bit unfortunate, since this idiom which works in Python 2 no longer works:

fp = urlopen(url)
json_data = json.load(fp)

/me sad

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Tue Oct 11 15:49:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Oct 2011 13:49:43 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <E1RDciD-0002qL-Kj@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset df950158dc33 by Antoine Pitrou in branch 'default':
Issue #13150: The tokenize module doesn't compile large regular expressions at startup anymore.
http://hg.python.org/cpython/rev/df950158dc33

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 11 15:51:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 13:51:37 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1318340688.53.0.778980394001.issue10976@psf.upfronthosting.co.za>
Message-ID: <1318340873.3277.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'll just mention that the elimination of bytes handling is a bit
> unfortunate, since this idiom which works in Python 2 no longer works:
> 
> fp = urlopen(url)
> json_data = json.load(fp)

What if the returned JSON uses a charset other than utf-8 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Tue Oct 11 16:07:34 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 11 Oct 2011 14:07:34 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318342054.83.0.949203108281.issue13150@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am curious: wouldn't be a way of keeping the compiled expressions in a static cache somewhere, so we would compile them just once and have both import time and runtime fast ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 11 16:11:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Oct 2011 14:11:16 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <E1RDd35-0005I3-6r@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ed0bc92fed68 by Antoine Pitrou in branch 'default':
Use a dict for faster sysconfig startup (issue #13150)
http://hg.python.org/cpython/rev/ed0bc92fed68

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 11 16:13:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 14:13:31 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318342054.83.0.949203108281.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318342188.3277.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I am curious: wouldn't be a way of keeping the compiled expressions in
> a static cache somewhere, so we would compile them just once and have
> both import time and runtime fast ?

Runtime shouldn't be affected. The re module has its own LRU caching.

That said, it seems regular expressions are pickleable:

b'\x80\x03cre\n_compile\nq\x00X\x00\x00\x00\x00q\x01K \x86q\x02Rq\x03.'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 11 16:13:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 14:13:57 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318342437.31.0.845319801893.issue13150@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Arg damn roundup e-mail gateway.
I wanted to paste:

>>> pickle.dumps(re.compile(''))
b'\x80\x03cre\n_compile\nq\x00X\x00\x00\x00\x00q\x01K \x86q\x02Rq\x03.'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 11 16:53:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 14:53:09 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318344789.2.0.273667856151.issue13150@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Pre-parsing and building a cached module of built-time variables (from Makefile and pyconfig.h) under POSIX also removes more than 15% of startup time. Patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file23377/sysconfigdata.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 11 19:06:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Oct 2011 17:06:49 +0000
Subject: [issue13145] Documentation of PyNumber_ToBase() wrong
In-Reply-To: <1318253175.42.0.981988907278.issue13145@psf.upfronthosting.co.za>
Message-ID: <E1RDfmy-00077K-Ef@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 61eb59516b55 by Mark Dickinson in branch '3.2':
Issue #13145. Fix incorrect documentation for PyNumber_ToBase.  Thanks Sven Marnach.
http://hg.python.org/cpython/rev/61eb59516b55

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13145>
_______________________________________

From report at bugs.python.org  Tue Oct 11 19:07:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Oct 2011 17:07:29 +0000
Subject: [issue13145] Documentation of PyNumber_ToBase() wrong
In-Reply-To: <1318253175.42.0.981988907278.issue13145@psf.upfronthosting.co.za>
Message-ID: <E1RDfnc-0007Af-0A@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a644e2c43c4b by Mark Dickinson in branch 'default':
Merge issue #13145 fix.
http://hg.python.org/cpython/rev/a644e2c43c4b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13145>
_______________________________________

From report at bugs.python.org  Tue Oct 11 19:12:23 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Oct 2011 17:12:23 +0000
Subject: [issue13145] Documentation of PyNumber_ToBase() wrong
In-Reply-To: <1318253175.42.0.981988907278.issue13145@psf.upfronthosting.co.za>
Message-ID: <1318353143.88.0.953401301481.issue13145@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed.  Thanks for the report!

----------
nosy: +mark.dickinson
resolution:  -> fixed
status: open -> closed
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13145>
_______________________________________

From report at bugs.python.org  Tue Oct 11 19:12:38 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Oct 2011 17:12:38 +0000
Subject: [issue13145] Documentation of PyNumber_ToBase() wrong
In-Reply-To: <1318253175.42.0.981988907278.issue13145@psf.upfronthosting.co.za>
Message-ID: <1318353158.98.0.387426876955.issue13145@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: docs at python -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13145>
_______________________________________

From report at bugs.python.org  Tue Oct 11 19:19:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 11 Oct 2011 17:19:00 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <CAH_1eM0MwWC6E4CqN4rYAFU9V-Lm9rYDGdKwdqyCFFadDOwrOw@mail.gmail.com>
Message-ID: <CAH_1eM0xAiU1+taNaGNissHvGC_y5Mwihx7pm=Vc6UP3Y0yLBg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I did a quick test (calling fork() from a subinterpreter), and as
expected, I couldn't reproduce the problem.
So I still favor an OOM condition making pthread_setspecific bail out
with ENOMEM, othe other option being a nasty libc bug.
If the problem persists, please open a new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Tue Oct 11 20:15:27 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Tue, 11 Oct 2011 18:15:27 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1318356927.97.0.261408087697.issue10881@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

I would like to help by reviewing the patch, however I'm unsure about how to do the framework aspect of this. Can someone send me instructions or a link on how I would set this up to test?

Thanks in advance,

----------
nosy: +louiscipher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Tue Oct 11 20:44:17 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 11 Oct 2011 18:44:17 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1318358657.01.0.095289120742.issue10881@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

IIRC what I did was clone the repo, configure and build, then

sudo make frameworkinstall

For me (on Leopard), this installed Python 3.3 in /Library/Frameworks/Python.framework, leaving my system Python (2.5.1) alone. Then you can just invoke the regression tests using

python3.3 Lib/test/regrtest.py test_site

from the appropriate directory. But note that this is a case where the test needs fixing, not the code being tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Tue Oct 11 20:44:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Oct 2011 18:44:28 +0000
Subject: [issue13134] speed up finding of one-character strings
In-Reply-To: <1318105744.0.0.664183527644.issue13134@psf.upfronthosting.co.za>
Message-ID: <E1RDhJT-0008N0-8E@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset af4a89f4f466 by Antoine Pitrou in branch 'default':
Issue #13134: optimize finding single-character strings using memchr
http://hg.python.org/cpython/rev/af4a89f4f466

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Tue Oct 11 20:44:57 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 11 Oct 2011 18:44:57 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318358697.18.0.129393102956.issue13150@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

#11454 is another case where pre-parsing and pickling the regular expressions in the email module may improve import time considerably.

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 11 20:45:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 18:45:51 +0000
Subject: [issue13134] speed up finding of one-character strings
In-Reply-To: <1318105744.0.0.664183527644.issue13134@psf.upfronthosting.co.za>
Message-ID: <1318358751.98.0.743235819835.issue13134@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I went ahead and committed.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Tue Oct 11 21:07:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Oct 2011 19:07:14 +0000
Subject: [issue13136] speed-up conversion between unicode widths
In-Reply-To: <1318112311.49.0.66949742663.issue13136@psf.upfronthosting.co.za>
Message-ID: <E1RDhfU-0002B7-Qb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5b077c962a16 by Antoine Pitrou in branch 'default':
Issue #13136: speed up conversion between different character widths.
http://hg.python.org/cpython/rev/5b077c962a16

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13136>
_______________________________________

From report at bugs.python.org  Tue Oct 11 21:08:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 19:08:08 +0000
Subject: [issue13136] speed-up conversion between unicode widths
In-Reply-To: <1318112311.49.0.66949742663.issue13136@psf.upfronthosting.co.za>
Message-ID: <1318360088.62.0.486433237121.issue13136@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed. It is of course still not as fast as memcpy, but it's a small step towards improving performance.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13136>
_______________________________________

From report at bugs.python.org  Tue Oct 11 21:55:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 19:55:34 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za>
Message-ID: <1318362934.74.0.915052981701.issue13146@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This new patch also fixes importlib.

----------
stage:  -> patch review
versions:  -Python 2.7
Added file: http://bugs.python.org/file23378/importrename2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Tue Oct 11 22:01:32 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Tue, 11 Oct 2011 20:01:32 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
Message-ID: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo <jbvsmo at gmail.com>:

I was playing with some unicode chars on Python 3.2 (x64 on Windows 7), but when pasted a char bigger than 0xFFFF, IDLE crashes without any error message.

Example (works fine):
>>> '\U000104a2'
'?'

But, if I try to paste the above char, the window will instantly close.

The interpreter uses 2-bytes per char (UTF-16) and I don't know if that's causing the problem (as side note, why don't the default Windows build uses 4-bytes char?).

I can't check now with my Ubuntu install (UTF-32) if the problem persists.

----------
components: IDLE, Unicode, Windows
messages: 145363
nosy: JBernardo
priority: normal
severity: normal
status: open
title: IDLE crash with unicode bigger than 0xFFFF
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Tue Oct 11 22:25:44 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Oct 2011 20:25:44 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1318364744.22.0.762285855906.issue10881@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

>   sudo make frameworkinstall

While that shouldn't affect the Apple-supplied system Pythons, be aware that with default ./configure settings this will overwrite any third-party Python installs (like from the python.org installers) of the version in question in /Library/Frameworks.  For unreleased versions, like from default that shouldn't be a big issue.  But it is safer and easy to pick some other location to install the framework.  I also usually use a different framework name to reduce the chances of accidentally dynamically linking to the wrong framework.  On a current 10.6 or 10.7 system, I'd recommend something like this:

./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk --with-universal-archs=intel '--prefix=/path/to/test/root' '--enable-framework=/path/to/test/Library' --with-framework-name=pytest_10_6 MACOSX_DEPLOYMENT_TARGET=10.6 CC=/usr/bin/gcc-4.2

On 10.4 or 10.5 systems, to simulate the 32-bit-only installer build:

./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk --with-universal-archs=32-bit '--prefix=/path/to/test/root' '--enable-framework=/path/to/test/Library' --with-framework-name=pytest_10_3 --with-pydebug MACOSX_DEPLOYMENT_TARGET=10.3 CC=/usr/bin/gcc-4.0

Bryce, are you interested in writing a patch for the test?

----------
assignee: ronaldoussoren -> ned.deily
nosy: +ned.deily
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Tue Oct 11 22:28:32 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Oct 2011 20:28:32 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1318364912.99.0.0504415836184.issue10881@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I forgot to mention that one advantage of using another framework and root location, say, under your home directory somewhere, is that it is unnecessary to use sudo.  And you don't need to use the special target in any case, simply "make install".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Tue Oct 11 23:06:15 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Oct 2011 21:06:15 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318367175.72.0.807551359372.issue13153@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This is related to Issue12342.  The problem is that Tcl/Tk 8.5 (and earlier) do not support Unicode code points outside the BMP range as in this example.  So IDLE will be unable to display such characters but it should not crash either.

----------
assignee:  -> ned.deily
nosy: +ned.deily
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Tue Oct 11 23:23:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Oct 2011 21:23:27 +0000
Subject: [issue13134] speed up finding of one-character strings
In-Reply-To: <1318105744.0.0.664183527644.issue13134@psf.upfronthosting.co.za>
Message-ID: <1318368207.51.0.482258691736.issue13134@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

changeset:   72874:bfd3fcfb02f3
user:        Victor Stinner <victor.stinner at haypocalc.com>
date:        Tue Oct 11 23:22:22 2011 +0200
files:       Objects/stringlib/asciilib.h Objects/stringlib/fastsearch.h Objects/stringlib/stringdefs.h Objects/stringlib/ucs1lib.h Objects/stri
description:
Fix fastsearch for UCS2 and UCS4

 * If needle is 0, try (p[0] >> 16) & 0xff for UCS4
 * Disable fastsearch_memchr_1char() if needle is zero for UCS2 and UCS4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Tue Oct 11 23:43:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Oct 2011 21:43:35 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za>
Message-ID: <1318369415.68.0.31169456192.issue13146@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

So if a process replaces the PYC file whereas another is reading the PYC, the reader may read corrupted data? The ideal fix is maybe to use a file lock?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Tue Oct 11 23:54:21 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Tue, 11 Oct 2011 21:54:21 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318370061.72.0.297058820556.issue13153@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

@Ned

That looks like a bit different case. IDLE *can* print the char after you entered the '\Uxxxxxxxx' version of it.

It doesn't accept you to paste those caracters...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Tue Oct 11 23:55:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 21:55:08 +0000
Subject: [issue13154] pep-0000.txt doesn't build anymore
Message-ID: <1318370108.79.0.613915208631.issue13154@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

$ make
make: D?pendance circulaire pep-0000.txt <- pep-0000.txt abandonn?e.
python genpepindex.py .
Traceback (most recent call last):
  File "genpepindex.py", line 67, in <module>
    main(sys.argv)
  File "genpepindex.py", line 64, in main
    write_pep0(peps, pep0_file)
  File "/home/antoine/cpython/peps/pep0/output.py", line 195, in write_pep0
    authors_dict = verify_email_addresses(peps)
  File "/home/antoine/cpython/peps/pep0/output.py", line 104, in verify_email_addresses
    "listed:\n" + '\n'.join(err_output))
ValueError: some authors have more than one email address listed:
    Gregory Ewing: [u'greg at cosc.canterbury.ac.nz', u'greg.ewing at canterbury.ac.nz']
make: *** [pep-0000.txt] Erreur 1

----------
assignee: docs at python
components: Documentation
messages: 145370
nosy: docs at python, pitrou
priority: normal
severity: normal
status: open
title: pep-0000.txt doesn't build anymore
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13154>
_______________________________________

From report at bugs.python.org  Tue Oct 11 23:55:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 21:55:43 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318369415.68.0.31169456192.issue13146@psf.upfronthosting.co.za>
Message-ID: <1318369919.3277.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So if a process replaces the PYC file whereas another is reading the
> PYC, the reader may read corrupted data?

No, this is the whole point of the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Wed Oct 12 01:14:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 23:14:19 +0000
Subject: [issue13155] Optimize finding the max character width
Message-ID: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch optimizes scanning for the max character width in an unicode buffer.

Micro-benchmarking some worst case situations:

$ ./python -m timeit -s "x='?'+'x'*100000" "x[1:]"
-> before:
10000 loops, best of 3: 74.9 usec per loop
-> after:
100000 loops, best of 3: 15.5 usec per loop

$ ./python -m timeit -s "x='\U00010000'+'x'*100000" "x[1:]"
-> before:
10000 loops, best of 3: 138 usec per loop
-> after:
10000 loops, best of 3: 71.3 usec per loop

----------
components: Interpreter Core
files: find_max_char.patch
keywords: patch
messages: 145372
nosy: pitrou
priority: normal
severity: normal
status: open
title: Optimize finding the max character width
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file23379/find_max_char.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Wed Oct 12 01:22:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 23:22:37 +0000
Subject: [issue13155] Optimize finding the max character width
In-Reply-To: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za>
Message-ID: <1318375357.32.0.520042885774.issue13155@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I hadn't noticed the STRINGLIB_SIZEOF_CHAR constant. Reuse it instead of adding STRINGLIB_CHAR_SIZE.

----------
Added file: http://bugs.python.org/file23380/find_max_char2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Wed Oct 12 01:32:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 23:32:19 +0000
Subject: [issue13155] Optimize finding the max character width
In-Reply-To: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za>
Message-ID: <1318375939.61.0.191429714122.issue13155@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Slightly cleaned up patch after Victor's comments in private.

----------
Added file: http://bugs.python.org/file23381/find_max_char3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Wed Oct 12 01:42:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Oct 2011 23:42:18 +0000
Subject: [issue13155] Optimize finding the max character width
In-Reply-To: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za>
Message-ID: <1318376538.12.0.399479516824.issue13155@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

find_max_char() returns 0x10000 instead of 0x10FFFF, which may be wrong (or at least, surprising). You may add a max_char variable using other macros like MAX_CHAR_ASCII, MAX_CHAR_UCS1, ..., which will be set at the same time than mask. Or restore your if (ret >= 0x10000) return 0x10ffff; else return ret;.

Constants look inconsistent:

+    const STRINGLIB_CHAR *unrolled_end = begin + (n & ~ (Py_ssize_t) 7);
+        p += 4;

You may use STRINGLIB_CHAR in:

+        Py_UCS4 bits = p[0] | p[1] | p[2] | p[3];

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Wed Oct 12 01:50:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Oct 2011 23:50:38 +0000
Subject: [issue13155] Optimize finding the max character width
In-Reply-To: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za>
Message-ID: <1318377038.92.0.257558447282.issue13155@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, updated patch.

----------
Added file: http://bugs.python.org/file23382/find_max_char4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Wed Oct 12 02:11:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 00:11:45 +0000
Subject: [issue13155] Optimize finding the max character width
In-Reply-To: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za>
Message-ID: <1318378305.18.0.54202768.issue13155@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Ok, updated patch.

"ret = ~mask + 1;" looks wrong: (~0xFFFFFF80+1) gives 128, not 127. I don't see why you need:

+    if (ret < 128)
+        return 127;
+    if (ret < 256)
+        return 255;

#undef ASCII_CHAR_MASK should be #undef UCS1_ASCII_CHAR_MASK


#error Invalid STRINGLIB_SIZEOF_CHAR (must be 1, 2 or 4)
should be
#error Invalid STRINGLIB_SIZEOF_CHAR (must be 2 or 4)

Why do you need these forward declarations? It's maybe related to another patch?

 static PyObject *
+unicode_fromascii(const unsigned char *s, Py_ssize_t size);
+static PyObject *
+_PyUnicode_FromUCS1(const unsigned char *s, Py_ssize_t size);
+static PyObject *
+_PyUnicode_FromUCS2(const Py_UCS2 *s, Py_ssize_t size);
+static PyObject *
+_PyUnicode_FromUCS4(const Py_UCS4 *s, Py_ssize_t size);

(You kept Py_UCS4 for "Py_UCS4 bits", but Py_UCS4 is maybe just fine.)

By the way, your function rocks :-) Use bit masks is a great idea, especially your "bits = p[0] | p[1] | p[2] | p[3]" "hack".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Wed Oct 12 02:24:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Oct 2011 00:24:32 +0000
Subject: [issue13155] Optimize finding the max character width
In-Reply-To: <1318378305.18.0.54202768.issue13155@psf.upfronthosting.co.za>
Message-ID: <1318378846.3277.19.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Ok, updated patch.
> 
> "ret = ~mask + 1;" looks wrong: (~0xFFFFFF80+1) gives 128, not 127.

That's on purpose, since the mask has just matched. If 0xFFFFFF80
matches, then the max char can't be 127, it has to be at least 128.

>  I don't see why you need:
> 
> +    if (ret < 128)
> +        return 127;
> +    if (ret < 256)
> +        return 255;

Because otherwise you're returning 0xFFFF in the following line:

    if (ret < 0x10000)
        return 0xFFFF;

> #undef ASCII_CHAR_MASK should be #undef UCS1_ASCII_CHAR_MASK

Ha, funny that gcc doesn't say anything.
I also forgot to #under MASK_*.

> #error Invalid STRINGLIB_SIZEOF_CHAR (must be 1, 2 or 4)
> should be
> #error Invalid STRINGLIB_SIZEOF_CHAR (must be 2 or 4)

Well, no. 1 is a legal value, even though it's handled elsewhere, so the
error message is right.

> Why do you need these forward declarations? It's maybe related to another patch?

It's because I'm moving the stringlib #includes up in unicodeobject.c,
and stringlib calls these functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Wed Oct 12 02:32:00 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 12 Oct 2011 00:32:00 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1318379520.22.0.0499530190822.issue12641@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Oct 12 02:39:00 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 12 Oct 2011 00:39:00 +0000
Subject: [issue12807] Optimization/refactoring for {bytearray, bytes,
	unicode}.strip()
In-Reply-To: <1313981941.49.0.99491814096.issue12807@psf.upfronthosting.co.za>
Message-ID: <1318379940.75.0.435670428348.issue12807@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

New patch.

Please double check the removal of _PyUnicode_XStrip.

----------
Added file: http://bugs.python.org/file23383/stringlib_strip2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12807>
_______________________________________

From report at bugs.python.org  Wed Oct 12 02:42:24 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 12 Oct 2011 00:42:24 +0000
Subject: [issue12807] Move strip() to stringlib
In-Reply-To: <1313981941.49.0.99491814096.issue12807@psf.upfronthosting.co.za>
Message-ID: <1318380144.39.0.347779578569.issue12807@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
title: Optimization/refactoring for {bytearray, bytes, unicode}.strip() -> Move strip() to stringlib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12807>
_______________________________________

From report at bugs.python.org  Wed Oct 12 03:00:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Oct 2011 01:00:51 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <E1RDnBh-0006ee-BL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 41a1de81ef2b by Antoine Pitrou in branch 'default':
PEP 3151 / issue #12555: reworking the OS and IO exception hierarchy.
http://hg.python.org/cpython/rev/41a1de81ef2b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Wed Oct 12 03:05:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Oct 2011 01:05:27 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1318381527.09.0.159547277792.issue12555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks everyone for the reviews!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Wed Oct 12 03:18:14 2011
From: report at bugs.python.org (Mike Hoy)
Date: Wed, 12 Oct 2011 01:18:14 +0000
Subject: [issue3902] Packages containing only extension modules have to
	contain __init__.py
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1318382294.32.0.288969865704.issue3902@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

setupscript did not have the changes that were made in apiref. v4 is now consistent and line wrapping at 80 chars.

----------
Added file: http://bugs.python.org/file23384/apiref-setupscript-v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Wed Oct 12 08:33:47 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 12 Oct 2011 06:33:47 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
Message-ID: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>


New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:

This is a followup bug report to fix wrong implementation of _PyGILState_Reinit() introduced by http://bugs.python.org/issue10517.

I don't have a standalone test case yet. Problem occurs under mod_wsgi with Python 2.7.2 and thus similarly 3.2 where _PyGILState_Reinit() was also added.

The Python code part which triggers the problem is:

    pid = os.fork()
    if pid:
       sys.stderr.write('Fork succeeded (PID=%s)\n' % pid)
    else:
       sys.stderr.write('Fork succeeded (child PID=%s)\n' % os.getpid())
       time.sleep(60.0)
       os._exit(0)

To trigger the problem requires this code be executed from a thread originally created outside of Python and then calling into a sub interpreter.

This thread would have created its own thread state object for the sub interpreter call since auto thread states don't work for sub interpreters. Further, it would never have called into the main interpreter so auto thread state simply doesn't exist for main interpreter.

When this thread has a fork() occur and _PyGILState_Reinit() is called, the call of PyGILState_GetThisThreadState() returns NULL because auto thread state for main interpreter was never initialised for this thread. When it then calls into PyThread_set_key_value() it is value of NULL and rather than set it, it thinks internally in find_key() you are doing a get which results in PyThread_set_key_value() returning -1 and so the fatal error.

So _PyGILState_Reinit() is broken because it assumes that an auto thread state will always exist for the thread for it to reinit, which will not always be the case.

The simple fix may be that if PyGILState_GetThisThreadState() returns NULL then don't do any reinit. Making that change does seem to fix the problem. Code that works then is:

void
_PyGILState_Reinit(void)
{
    PyThreadState *tstate = PyGILState_GetThisThreadState();

    if (tstate) {
        PyThread_delete_key(autoTLSkey);
        if ((autoTLSkey = PyThread_create_key()) == -1)
            Py_FatalError("Could not allocate TLS entry");

        /* re-associate the current thread state with the new key */
        if (PyThread_set_key_value(autoTLSkey, (void *)tstate) < 0)
            Py_FatalError("Couldn't create autoTLSkey mapping");
    }
}

Diff file also attached.

----------
components: Extension Modules
files: pystate.c.diff
keywords: patch
messages: 145383
nosy: grahamd, neologix
priority: normal
severity: normal
status: open
title: _PyGILState_Reinit assumes auto thread state will always exist which is not true.
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23385/pystate.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 08:37:31 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 12 Oct 2011 06:37:31 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <1318401451.91.0.0882547816325.issue13156@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Whoops. Missed the error. The fatal error that occurs is:

Fatal Python error: Couldn't create autoTLSkey mapping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 08:57:48 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 12 Oct 2011 06:57:48 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <1318402668.8.0.408704415613.issue13156@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 09:10:04 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 12 Oct 2011 07:10:04 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <1318403404.41.0.321628142654.issue13156@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Note that this doesn't apply to default: the problem is that 2.7 and 3.2 don't use native TLS, and with the ad-hoc TLS implementation, a NULL value isn't supported:
"""
 /* Internal helper.
  * If the current thread has a mapping for key, the appropriate struct key*
  * is returned.  NB:  value is ignored in this case!
  * If there is no mapping for key in the current thread, then:
  *     If value is NULL, NULL is returned.
  *     Else a mapping of key to value is created for the current thread,
  *     and a pointer to a new struct key* is returned; except that if
  *     malloc() can't find room for a new struct key*, NULL is returned.
  * So when value==NULL, this acts like a pure lookup routine, and when
  * value!=NULL, this acts like dict.setdefault(), returning an existing
  * mapping if one exists, else creating a new mapping.
"""

So PyThread_set_key_value() has different semantics between 2.7/3.2 and default...


> So _PyGILState_Reinit() is broken because it assumes that an auto 
> thread state will always exist for the thread for it to reinit, which 
> will not always be the case.

Hmm...
Please see http://docs.python.org/c-api/init.html#non-python-created-threads
"""
When threads are created using the dedicated Python APIs (such as the threading module), a thread state is automatically associated to them and the code showed above is therefore correct. However, when threads are created from C (for example by a third-party library with its own thread management), they don?t hold the GIL, nor is there a thread state structure for them.

If you need to call Python code from these threads (often this will be part of a callback API provided by the aforementioned third-party library), you must first register these threads with the interpreter by creating a thread state data structure, then acquiring the GIL, and finally storing their thread state pointer, before you can start using the Python/C API. When you are done, you should reset the thread state pointer, release the GIL, and finally free the thread state data structure.

The PyGILState_Ensure() and PyGILState_Release() functions do all of the above automatically. The typical idiom for calling into Python from a C thread is:
"""

I think you should be calling call PyGILState_Ensure() before (whoch does associate the thread state to the autoTLS key.
I let Antoine answer, he's got much more experience than me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 10:04:02 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 12 Oct 2011 08:04:02 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <1318406642.45.0.915206112957.issue13156@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

The PyGILState_Ensure() function is only for when working with the main interpreter. These external threads are not calling into the main interpreter.

Because they are external threads, calling PyGILState_Ensure() and then PyGILState_Release() will cause a thread state to be created for the main interpreter, but it will also be destroyed on the PyGILState_Release().

The only way to avoid that situation and ensure that the thread state for the main interpreter is therefore maintained would be to call PyGILState_Ensure() and then call PyThreadState_Swap() to change to thread state for the sub interpreter. Problem is that you aren't supposed to use PyThreadState_Swap() any more and recollect that newer Python 3.X even prohibits it in some way through some checks.

So, the documentation you quote is only to do with the main interpreter and is not how things work for sub interpreters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 10:32:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 12 Oct 2011 08:32:33 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318403404.41.0.321628142654.issue13156@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0kTE8B4ebAGCjBbwEmEnTKxhwSAcG5+KpRd9w-4SV_wA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> So, the documentation you quote is only to do with the main
> interpreter and is not how things work for sub interpreters.

You're right, my bad.
However, it would probably be better to destroy/reset the autoTLSkey
even if the current thread doesn't have an associated TLS key (to
avoid stumbling upon the original libc bug of issue #10517):

"""
void
_PyGILState_Reinit(void)
{
    PyThreadState *tstate = PyGILState_GetThisThreadState();

        PyThread_delete_key(autoTLSkey);
        if ((autoTLSkey = PyThread_create_key()) == -1)
            Py_FatalError("Could not allocate TLS entry");

        /* re-associate the current thread state with the new key */
        if (tstate && PyThread_set_key_value(autoTLSkey, (void *)tstate) < 0)
            Py_FatalError("Couldn't create autoTLSkey mapping");
}
"""

Now that i think about it, the problem is even simpler: this patch
shouldn't have been applied to 2.7 and 3.2, it was only relevant for
native pthread TLS implementation (which does allow NULL values).
So the solution would be simply to backout this patch on 2.7 and 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 10:33:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 08:33:07 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <1318408387.13.0.3945119768.issue13156@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 10:39:32 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 12 Oct 2011 08:39:32 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <1318408772.13.0.125356574248.issue13156@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> So the solution would be simply to backout this patch on 2.7 and 3.2.

Actually, I just checked, and the native TLS implementation is present in 3.2, so this problem shouldn't show up: did you test it with 3.2?
AFAICT, this should only affect 2.7 (for which this patch wasn't relevant).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 11:51:27 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 12 Oct 2011 09:51:27 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <1318413087.0.0.462207352748.issue13156@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

True. Doesn't appear to be an issue with Python 3.2.2. Only Python 2.7.2.

I was not aware that the TLS mechanism was changed in Python 3.X so assumed would also affect it.

So, looks like the change shouldn't have been applied to Python 2.7.

How many moons before Python 2.7.3 though?

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 11:56:35 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 12 Oct 2011 09:56:35 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1318413395.0.0.618119816308.issue4431@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I got this problem again this morning while compiling pywin32.

This problem is not specific to me, anyone using Visual Studio 2010 to compile Python is experiencing the same issue:

http://nukeit.org/compile-python-2-7-packages-with-visual-studio-2010-express/
https://bitbucket.org/jaraco/jaraco.develop/src/f6e937d98e7f/jaraco/develop/msvc.py

Could you please reopen the issue or should I open a new one?
Thanks in advance

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Wed Oct 12 13:51:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Oct 2011 11:51:17 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <1318420277.17.0.128441200993.issue13156@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> How many moons before Python 2.7.3 though?

If you convince python-dev that's it's a critical bug (is it?) I suppose it could happen soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 14:06:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 12:06:07 +0000
Subject: [issue13157] Build Python outside the source directory
Message-ID: <1318421167.12.0.301144955548.issue13157@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

It is no more possible to build Python outside its source directory. Try using:

cd <python sources directory>
mkdir release
cd release
../configure
make

Attached patch should fix this issue.

----------
files: build.patch
keywords: patch
messages: 145392
nosy: haypo, loewis, neologix, pitrou
priority: normal
severity: normal
status: open
title: Build Python outside the source directory
versions: Python 3.3
Added file: http://bugs.python.org/file23386/build.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13157>
_______________________________________

From report at bugs.python.org  Wed Oct 12 14:06:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 12:06:11 +0000
Subject: [issue13157] Build Python outside the source directory
In-Reply-To: <1318421167.12.0.301144955548.issue13157@psf.upfronthosting.co.za>
Message-ID: <1318421171.55.0.216577674076.issue13157@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Build

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13157>
_______________________________________

From report at bugs.python.org  Wed Oct 12 14:54:32 2011
From: report at bugs.python.org (Sebastien Binet)
Date: Wed, 12 Oct 2011 12:54:32 +0000
Subject: [issue13158] tarfile.TarFile.getmembers misses some entries
Message-ID: <1318424072.71.0.575626132028.issue13158@psf.upfronthosting.co.za>


New submission from Sebastien Binet <binet at cern.ch>:

hi there,

it seems tarfile in python 3.2.2 (as installed in archlinux, but I don't see any additional patch applied on top of the vanilla sources:
http://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python
) has troubles giving the complete content of a tar ball.

see:
$ wget http://downloads.sourceforge.net/sourceforge/boost/boost_1_44_0.tar.gz

$ md5sum boost_1_44_0.tar.gz 
085fce4ff2089375105d72475d730e15  boost_1_44_0.tar.gz

$ python --version
Python 3.2.2

$ python2 --version
Python 2.7.2

$ python ./foo.py
>>> 8145

$ python2 ./foo.py 
>>> 33635

where foo.py is:
##
import tarfile
o = tarfile.open("boost_1_44_0.tar.gz")
print(">>> %s" % len(o.getmembers()))
o.close()
## EOF ##


is it a known bug ?

(this of course prevents TarFile.extractall to be useful w/ python3...)

-s

----------
messages: 145393
nosy: bins
priority: normal
severity: normal
status: open
title: tarfile.TarFile.getmembers misses some entries
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13158>
_______________________________________

From report at bugs.python.org  Wed Oct 12 16:26:39 2011
From: report at bugs.python.org (David Schnur)
Date: Wed, 12 Oct 2011 14:26:39 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1318429599.46.0.437520591318.issue4431@psf.upfronthosting.co.za>


David Schnur <dnschnur at gmail.com> added the comment:

I haven't commented since opening this issue, but I've been following along.  Regarding Marc-Andre's latest comment, I think whether to embed a manifest or not is a separate issue.  The current behavior is to embed a manifest, and so it should ensure that the file is created.  As others have said, given that distutils expects /MANIFEST implicitly, there seems no harm in adding it explicitly.

I agree that this issue should be re-opened, since it's apparently not restricted just to my case of using /MT.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Wed Oct 12 17:02:20 2011
From: report at bugs.python.org (higery)
Date: Wed, 12 Oct 2011 15:02:20 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1318431740.0.0.711673517907.issue8668@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Added file: http://bugs.python.org/file23387/adb2cb19ca9b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Wed Oct 12 17:20:10 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 12 Oct 2011 15:20:10 +0000
Subject: [issue6807] No such file or directory: 'msisupport.dll' in msi.py
In-Reply-To: <1251629956.22.0.252677555531.issue6807@psf.upfronthosting.co.za>
Message-ID: <1318432810.08.0.324283267633.issue6807@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I had the same issue today. The patch solved the problem.
Thanks

----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6807>
_______________________________________

From report at bugs.python.org  Wed Oct 12 17:23:59 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 12 Oct 2011 15:23:59 +0000
Subject: [issue6807] No such file or directory: 'msisupport.dll' in msi.py
In-Reply-To: <1251629956.22.0.252677555531.issue6807@psf.upfronthosting.co.za>
Message-ID: <1318433039.17.0.554515349948.issue6807@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
components: +Windows
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6807>
_______________________________________

From report at bugs.python.org  Wed Oct 12 17:44:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 15:44:49 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1318434289.53.0.467338138101.issue12659@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes, you did.  There are a few minor edits I?ll make to the patch, but otherwise this is good to commit.

----------
assignee: tarek -> eric.araujo
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Wed Oct 12 17:47:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 15:47:33 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318434453.49.0.885157986341.issue13150@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

#9878 should also help with start-up time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Wed Oct 12 17:48:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 15:48:38 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318434518.8.0.216958543627.issue13150@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Wed Oct 12 17:50:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 15:50:02 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318434602.08.0.0333871435066.issue13150@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Actually, #9878 should supersede this bug: it proposes to generate a C module to avoid parsing Makefile and pyconfig.h, and your patch proposes to generate a Python module with the same goal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Wed Oct 12 17:56:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 15:56:43 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1318435003.27.0.321164786164.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the updated patch.  There are things that should be removed (for example functions like get_develop_method, given that we only support packaging-based projects), and there are a few things to clean up in the tests.  What?s more practical for you, a review or a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Wed Oct 12 17:57:50 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 Oct 2011 15:57:50 +0000
Subject: [issue13149] optimization for append-only StringIO
In-Reply-To: <1318295854.61.0.959309073941.issue13149@psf.upfronthosting.co.za>
Message-ID: <1318435070.57.0.879195525072.issue13149@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It would be interesting to see how often the "bad" case triggers, i.e. that a write-only stringio sees any of the other methods invoked at all.
As a special case, you may consider that .truncate(0) doesn't really need to realize the buffer first.

I also wonder how much StringIO will be used in praxis, as opposed to BytesIO.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13149>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:01:00 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 Oct 2011 16:01:00 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1318435260.33.0.249732039445.issue12753@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If you don't use git-style diffs, Rietveld will much better accommodate patches that don't apply to tip cleanly. Unfortunately, hg git-style diffs don't indicate the base revision, so Rietveld guesses that the base line is tip, and then fails if it doesn't apply exactly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:01:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Oct 2011 16:01:11 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318435271.6.0.698914286503.issue13150@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Actually, #9878 should supersede this bug: it proposes to generate a C 
> module to avoid parsing Makefile and pyconfig.h, and your patch
> proposes to generate a Python module with the same goal.

Well, #9878 doesn't have a patch, but perhaps Barry is willing to work on one. Also, if we have a pure Python solution, perhaps a C module isn't needed. The main advantage of the C solution, though, would be to avoid dubious parsing altogher, even at build time.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:02:00 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 12 Oct 2011 16:02:00 +0000
Subject: [issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
Message-ID: <1318435320.7.0.151419273993.issue13159@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

As mentioned in issue 6715, the buffer growth strategy used by _io.FileIO
has quadratic running time if each reallocation is O(n). The code in
question is new_buffersize() from Modules/_io/fileio.c:

    if (currentsize > SMALLCHUNK) {
        /* Keep doubling until we reach BIGCHUNK;
           then keep adding BIGCHUNK. */
        if (currentsize <= BIGCHUNK)
            return currentsize + currentsize;
        else
            return currentsize + BIGCHUNK;
    }
    return currentsize + SMALLCHUNK;

Is there a reason for this? One possible improvement would be to instead
use the same formula as list.resize() in Objects/listobject.c:

    new_allocated = (newsize >> 3) + (newsize < 9 ? 3 : 6);

which has amortized O(n) running time behaviour.

Your thoughts?

----------
components: IO
messages: 145403
nosy: benjamin.peterson, nadeem.vawda, pitrou, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: _io.FileIO uses a quadratic-time buffer growth algorithm
type: performance
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13159>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:06:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Oct 2011 16:06:53 +0000
Subject: [issue13149] optimization for append-only StringIO
In-Reply-To: <1318295854.61.0.959309073941.issue13149@psf.upfronthosting.co.za>
Message-ID: <1318435613.15.0.463264753559.issue13149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, these are things I've been wondering about. The use-case for an append-only StringIO is obviously overlapping with the use-case for using ''.join(). However, the implementation I'm proposing is better than ''.join() when writing very small strings, since there's a periodic consolidation.

> As a special case, you may consider that .truncate(0) doesn't really
> need to realize the buffer first.

True. Also, seek(0) then read() could use the same optimization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13149>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:11:27 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 Oct 2011 16:11:27 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1318327413.31.0.63298674751.issue6715@psf.upfronthosting.co.za>
Message-ID: <4E95BC2C.2040608@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>>> Modules/_lzmamodule.c:364: Py_BEGIN_ALLOW_THREADS
>> It seems that the Windows version at least is not thread-safe. If so, you
>> would need an LZMA lock when releasing the GIL.
>
> Does the class need to be thread-safe, though?

As a matter of principle, Python code must not be able to crash the
interpreter or corrupt memory. There are known bugs in this area,
but if it's known in advance that an issue exists, we should avoid
it.

> ISTM that there isn't any
> sensible use case for having two threads feeding data through the same
> compressor concurrently.

Right. So having a per-compressor mutex lock would be entirely
reasonable. I could also accept a per-module lock. I could even
accept the GIL, and if no other code is forth-coming, I would
prefer to keep holding the GIL during comprssion over risking
crashes.

> (If we *do* want thread-safety, then it doesn't matter whether the
> underlying lib is internally thread-safe or not. We would still need to
> guard against the possibility of the _lzmamodule.c code in one thread
> modifying the lzma_stream's input or output pointer while lzma_code is
> operating on the stream's data in another thread.)

I haven't reviewed the module in this respect. If you say that it
wouldn't be thread-safe even if LZMA was compiled as thread-safe,
then this definitely must be fixed.

To elaborate on the policy: giving bogus data in cases of race
conditions is ok; crashing the interpreter or corrupting memory
is not. If bogus data is given, it would be useful if the bogosity
can be specified (e.g. when multiple threads read from the same
POSIX file concurrently, they also get bogus data, but in a manner
where each input byte is given to exactly one thread).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:15:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 16:15:51 +0000
Subject: [issue13151] pysetup3 run bdist_wininst fails
In-Reply-To: <1318331538.35.0.635641564623.issue13151@psf.upfronthosting.co.za>
Message-ID: <1318436151.5.0.579487562341.issue13151@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

On line 118, replacing 'install' with 'install_dist' should fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13151>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:16:51 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 Oct 2011 16:16:51 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1318332919.3277.3.camel@localhost.localdomain>
Message-ID: <4E95BD71.6040609@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> Correct. I copied the algorithm from _io.FileIO, under the assumption
>> that there was a reason for not using a simpler O(n log n) doubling
>> strategy. Do you know of any reason for this? Or is it safe to ignore it?
>
> I don't know, but I'd say it's safe to ignore it.

To elaborate: ISTM that it's actually a bug in FileIO. I can imagine
where it's coming from (i.e. somebody feeling that overhead shouldn't
grow unbounded), but I think that's ill-advised - *if* somebody really
produces multi-gigabyte data (and some people eventually will), they
still deserve good performance, and they will be able to afford the
memory overhead (else they couldn't store the actual output, either).

> Generally we use a less-than-doubling strategy, to conserve memory (see
> e.g. bytearray.c).

Most definitely. In case it isn't clear (but it probably is here):
any constant factor > 1.0 will provide amortized linear complexity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:19:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 16:19:54 +0000
Subject: [issue13160] Rename install_dist to install
Message-ID: <1318436394.33.0.345868937694.issue13160@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When we first added actions to pysetup, the install command was renamed to install_dist to avoid a name conflict between the install command and the install action.  Later, the run action was introduced and now serves to namespace all commands.  Thus, we have no conflict anymore.  I would like to restore the original name of the install command, for distutils compat: people used to d1 build/install will get the same name, and the section in config files (which are currently compatible with d1 and d2, except for install_dist) will share the same name again (letting people give options in [install], not [install] and [install_dist]).

----------
assignee: eric.araujo
components: Distutils2
messages: 145408
nosy: alexis, eric.araujo
priority: normal
severity: normal
status: open
title: Rename install_dist to install
versions: 3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13160>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:20:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 16:20:02 +0000
Subject: [issue13160] Rename install_dist to install
In-Reply-To: <1318436394.33.0.345868937694.issue13160@psf.upfronthosting.co.za>
Message-ID: <1318436402.07.0.412818334788.issue13160@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13160>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:20:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 16:20:15 +0000
Subject: [issue13151] pysetup3 run bdist_wininst fails
In-Reply-To: <1318331538.35.0.635641564623.issue13151@psf.upfronthosting.co.za>
Message-ID: <1318436415.46.0.72106901289.issue13151@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +Rename install_dist to install

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13151>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:21:03 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 12 Oct 2011 16:21:03 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1318436463.59.0.327982100213.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> To elaborate on the policy: giving bogus data in cases of race
> conditions is ok; crashing the interpreter or corrupting memory
> is not. If bogus data is given, it would be useful if the bogosity
> can be specified (e.g. when multiple threads read from the same
> POSIX file concurrently, they also get bogus data, but in a manner
> where each input byte is given to exactly one thread).

OK, that makes sense. My next patch will include per-compressor locks for
LZMACompressor and LZMADecompressor.

> To elaborate: ISTM that it's actually a bug in FileIO.

I've filed issue 13159 proposing that FileIO be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:21:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 16:21:40 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318436500.9.0.724476267112.issue12602@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I suggest that it do so in this instance also, using *script* (in
> bold-faced italic) as the entry title.

What do you think about :file:`{script}`?  file+{} is what Sphinx uses for filenames with replaceable parts, which map to the HTML var element, which the stylesheets display as italics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:22:23 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 12 Oct 2011 16:22:23 +0000
Subject: [issue13161] problems with help() documentation of __i*__ operators
Message-ID: <1318436543.45.0.46958950416.issue13161@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Report from Joao Carneiro in the docs@ maillist:

----------------------------

I would like to report that I found a mistake in the document of "help(set)".

In the document all the __i*__ methods are described exactly like the same methods without i before the name.

Copied from the document:
__ixor__(...)

    x.__ixor__(y) <==> x^y


__xor__(...)

    x.__xor__(y) <==> x^y


I suppose that the __ixor__ would mean x^=y and not x^y like the __xor__ method right?

This problem also occurs for:
__iand__
__ior__
__isub__

----------------------------

The report is on Python 3.2, but the problem also exists in 2.7

It appears that the problem's source is in Objects/typeobject.c, where the __i*__ operators are defined with the IBSLOT macro. The documentation string is the operator, passed to IBSLOT - for __ixor__ it's "^", while it should probably be "^="

----------
assignee: docs at python
components: Documentation
messages: 145411
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: problems with help() documentation of __i*__ operators
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13161>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:32:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 16:32:06 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1318437126.83.0.270640476704.issue11751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I made a few edits and committed to distutils and packaging.  Then I ported the packaging patch to distutils2, which supports Python 2.4-2.7, and got this failure:

FAIL: test_glob_to_re (__main__.ManifestTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "distutils2/tests/test_manifest.py", line 88, in test_glob_to_re
    self.assertEqual(_glob_to_re('foo*'), 'foo[^/]*\\Z(?ms)')
AssertionError: 'foo[^/]*$' != 'foo[^/]*\\Z(?ms)'

I haven?t dug into it yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:37:58 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 12 Oct 2011 16:37:58 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za>
Message-ID: <1318437478.07.0.163853157813.issue13146@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Here is a patch for import.c.

Looks good to me.

> This new patch also fixes importlib.

"""
                path_tmp = path + '.tmp'
                with _io.FileIO(path_tmp, 'wb') as file:
                    file.write(data)
                _os.rename(path_tmp, path)
"""

I don't know exactly the context in which this code runs, but you can have a corruption if multiple processes try to write the bytecode file at the same time, since they'll all open the .tmp file: it should be opened with O_EXCL.

Also, as a side note, I'm wondering whether this type of check:
"""
            if not sys.platform.startswith('win'):
                # On POSIX-like platforms, renaming is atomic
"""

couldn't be rewritten as
"""
            if os.name == 'posix':
                # On POSIX-like platforms, renaming is atomic
"""

Fox example, does OS-X report as POSIX?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:44:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 12 Oct 2011 16:44:38 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318437878.33.0.064881556399.issue12602@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The italics parts are easier to recognize when they are within regular text (e.g. :file:`path/with/python{XY}/file`).  If the whole text is in italic people might not notice the difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:51:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Oct 2011 16:51:02 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318437478.07.0.163853157813.issue13146@psf.upfronthosting.co.za>
Message-ID: <1318438036.3235.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > This new patch also fixes importlib.
> 
> """
>                 path_tmp = path + '.tmp'
>                 with _io.FileIO(path_tmp, 'wb') as file:
>                     file.write(data)
>                 _os.rename(path_tmp, path)
> """
> 
> I don't know exactly the context in which this code runs, but you can
> have a corruption if multiple processes try to write the bytecode file
> at the same time, since they'll all open the .tmp file: it should be
> opened with O_EXCL.

Or perhaps append the PID to the name of the temp file ?
(easier done in Python than in C :-))

> Also, as a side note, I'm wondering whether this type of check:
> """
>             if not sys.platform.startswith('win'):
>                 # On POSIX-like platforms, renaming is atomic
> """
> 
> couldn't be rewritten as
> """
>             if os.name == 'posix':
>                 # On POSIX-like platforms, renaming is atomic
> """

No, because os.py is not available to importlib (which must be
bootstrappable early). See the _bootstrap.py header for information
about what is available; this is also why we use FileIO instead of
open().

> Fox example, does OS-X report as POSIX?

I think so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:54:12 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 12 Oct 2011 16:54:12 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1318438452.43.0.0329240190572.issue12344@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Added file: http://bugs.python.org/file23388/7db732ac6796.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Wed Oct 12 18:56:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 16:56:48 +0000
Subject: [issue3902] Packages containing only extension modules have to
	contain __init__.py
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1318438608.81.0.376565440167.issue3902@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good, will commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Wed Oct 12 19:00:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Oct 2011 17:00:47 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>
Message-ID: <1318438847.36.0.353546867796.issue12393@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great.  Do you want to update the docs (packaging/setupscript and maybe packaging/commandref too) or shall I do it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Wed Oct 12 19:19:16 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 12 Oct 2011 17:19:16 +0000
Subject: [issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
In-Reply-To: <1318435320.7.0.151419273993.issue13159@psf.upfronthosting.co.za>
Message-ID: <1318439956.15.0.157808011139.issue13159@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I've attached a patch that makes the suggested change to FileIO, and also
to _bz2.BZ2Compressor/Decompressor (which currently have the same issue).

----------
keywords: +patch
Added file: http://bugs.python.org/file23389/buffer-growth.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13159>
_______________________________________

From report at bugs.python.org  Wed Oct 12 19:20:01 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 12 Oct 2011 17:20:01 +0000
Subject: [issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
In-Reply-To: <1318435320.7.0.151419273993.issue13159@psf.upfronthosting.co.za>
Message-ID: <1318440001.06.0.382948937424.issue13159@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13159>
_______________________________________

From report at bugs.python.org  Wed Oct 12 19:24:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 17:24:31 +0000
Subject: [issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
In-Reply-To: <1318435320.7.0.151419273993.issue13159@psf.upfronthosting.co.za>
Message-ID: <1318440271.92.0.8852624139.issue13159@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13159>
_______________________________________

From report at bugs.python.org  Wed Oct 12 19:25:01 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 12 Oct 2011 17:25:01 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1318440301.82.0.814274843613.issue12344@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Added file: http://bugs.python.org/file23390/1bb1132840e6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Wed Oct 12 19:26:14 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 12 Oct 2011 17:26:14 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1318440374.02.0.006460618409.issue12344@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

Still working with ?ric to determine the proper behavior of get_reinitialized_commands. Latest patch is known incorrect but a step closer to our destination.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Wed Oct 12 21:01:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Oct 2011 19:01:03 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <E1RE434-0003k9-03@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8bbfb24d4824 by Victor Stinner in branch 'default':
Issue #12367: Add a test on error attribute of select.error
http://hg.python.org/cpython/rev/8bbfb24d4824

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Wed Oct 12 21:07:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Oct 2011 19:07:35 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <E1RE49N-0004KO-O6@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ee4fe16d9b48 by Charles-Fran?ois Natali in branch '2.7':
Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for native
http://hg.python.org/cpython/rev/ee4fe16d9b48

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 21:23:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 19:23:41 +0000
Subject: [issue13063] test_concurrent_futures failures on Windows:
	IOError('[Errno 232] The pipe is being closed') on _send_bytes()
In-Reply-To: <1317323234.29.0.73593324718.issue13063@psf.upfronthosting.co.za>
Message-ID: <1318447421.28.0.154465498156.issue13063@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The issue has been fixed by the merge of the PEP 3151: I now get a BrokenPipeError with errno=32 and winerror=232.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13063>
_______________________________________

From report at bugs.python.org  Wed Oct 12 21:52:06 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 12 Oct 2011 19:52:06 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318449126.96.0.620467932507.issue13150@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since #9878 proposes an *alternate* solution to *part* of the sysconfig problem, I disagree with 'supersede'. A Python solution would be more useful for other implementations if enough of the sysconfig info is not CPython specific.

A CPython design feature is that it parses and compiles Python code just once per run, and imported modules just once until the code changes (or might have). For functions, everything possible is put into a behind-the-scenes code object. So even inner functions are parsed and compiled just once.

The problem with sysconfig, it appears, is that lacks the equivalent design feature but instead does the equivalent of re-parsing and re-compiling inner functions with each outer function call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Wed Oct 12 22:14:08 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 12 Oct 2011 20:14:08 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <E1RE49N-0004KO-O6@dinsdale.python.org>
Message-ID: <CAH_1eM36mEdzRdbjF-eakgxLKJYjzE_kNWSUKm84Rt7K7fd38g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch for 3.2 and default which calls
PyThread_set_key_value() only if there was an auto thread state
previously associated (while the current code works with pthread TLS,
there are other implementations which may behave strangely, and
there's still the ad-hoc implementation in Python/thread.c).

----------
Added file: http://bugs.python.org/file23391/tstate_after_fork.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________
-------------- next part --------------
diff --git a/Python/pystate.c b/Python/pystate.c
--- a/Python/pystate.c
+++ b/Python/pystate.c
@@ -586,9 +586,9 @@
     autoInterpreterState = NULL;
 }
 
-/* Reset the TLS key - called by PyOS_AfterFork.
+/* Reset the TLS key - called by PyOS_AfterFork().
  * This should not be necessary, but some - buggy - pthread implementations
- * don't flush TLS on fork, see issue #10517.
+ * don't reset TLS upon fork(), see issue #10517.
  */
 void
 _PyGILState_Reinit(void)
@@ -598,8 +598,10 @@
     if ((autoTLSkey = PyThread_create_key()) == -1)
         Py_FatalError("Could not allocate TLS entry");
 
-    /* re-associate the current thread state with the new key */
-    if (PyThread_set_key_value(autoTLSkey, (void *)tstate) < 0)
+    /* If the thread had an associated auto thread state, reassociate it with
+     * the new key (this will not hold, for example, for a thread created
+     * outside of Python calling into a subinterpreter). */
+    if (tstate && PyThread_set_key_value(autoTLSkey, (void *)tstate) < 0)
         Py_FatalError("Couldn't create autoTLSkey mapping");
 }
 

From report at bugs.python.org  Wed Oct 12 22:14:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Oct 2011 20:14:18 +0000
Subject: [issue13157] Build Python outside the source directory
In-Reply-To: <1318421167.12.0.301144955548.issue13157@psf.upfronthosting.co.za>
Message-ID: <E1RE5Bw-0002UK-GR@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1811c4e5527f by Victor Stinner in branch 'default':
Issue #13157: Fix building Python outside its source tree
http://hg.python.org/cpython/rev/1811c4e5527f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13157>
_______________________________________

From report at bugs.python.org  Wed Oct 12 22:18:21 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 12 Oct 2011 20:18:21 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318450701.28.0.294207113227.issue12602@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since *script* is a file -- that is all variable -- that seems appropriate. 

Bold italic tends to be more notably different from bold italic than the normal pair. In any case, italic is the doc standard for function parameter names. It seems more sensible than introducing a unique occurrence of angle brackets. An alternative is to simply delete the angle brackets. 

If we consistently applied the "italicize non-literal symbolic parameter names" rule to command line examples, we would italicize 'command', 'module-name', 'script', and 'args' in

python [-BdEiOQsStuUvVWxX3?] [-c command | -m module-name | script | - ] [args]

just like in function signatures. I actually would like that as it would similarly diffentiate them from the literal constants meant to be entered as written. Has that ever been discussed by the doc group?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Wed Oct 12 22:21:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 20:21:31 +0000
Subject: [issue13155] Optimize finding the max character width
In-Reply-To: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za>
Message-ID: <1318450891.16.0.447171582212.issue13155@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Without the patch:

python3.2 -m timeit 'x="?"+"x"*10000' 'x[1:]'
100000 loops, best of 3: 2.18 usec per loop
                                                                                     
python3.3 -m timeit 'x="?"+"x"*10000' 'x[1:]'
100000 loops, best of 3: 6.68 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Wed Oct 12 22:22:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 20:22:36 +0000
Subject: [issue13155] Optimize finding the max character width
In-Reply-To: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za>
Message-ID: <1318450956.95.0.949095551995.issue13155@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

With find_max_char4.patch:

python3.3 -m timeit 'x="?"+"x"*10000' 'x[1:]'
100000 loops, best of 3: 1.96 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Wed Oct 12 22:26:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Oct 2011 20:26:28 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <E1RE5Ni-0003m1-Ra@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3313ce92cef7 by Charles-Fran?ois Natali in branch '2.7':
Issue #13156: Add an entry in Misc/NEWS.
http://hg.python.org/cpython/rev/3313ce92cef7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Wed Oct 12 22:42:20 2011
From: report at bugs.python.org (Mike Hoy)
Date: Wed, 12 Oct 2011 20:42:20 +0000
Subject: [issue13154] pep-0000.txt doesn't build anymore
In-Reply-To: <1318370108.79.0.613915208631.issue13154@psf.upfronthosting.co.za>
Message-ID: <1318452140.38.0.439306604156.issue13154@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13154>
_______________________________________

From report at bugs.python.org  Wed Oct 12 22:49:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 12 Oct 2011 20:49:34 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318438036.3235.2.camel@localhost.localdomain>
Message-ID: <CAH_1eM225T8jR3Z5fKbPuWLccEKTeFpCS+fycvhjtOS=7eVbdg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Or perhaps append the PID to the name of the temp file ?
> (easier done in Python than in C :-))

I don't really like appending PIDs to generate file names:
- if you have multiple processes at the same time, they'll all write
their own file which will end up being replaced by the last one to
perform the move, whereas with O_EXCL, they'll see immediately that
another instance is writing it (the overhead is negligible with such
small files, but maybe not so much when creating the file requires a
certain amout of work)
- if processes crash at the wrong time, you can end up with a flurry
of <filename>.<PID>
- the last one is even more insidious and unlikely, but here it goes:
the PID is unique only on a given machine: if you have, for example, a
network file system shared between multiple hosts, then you can have a
PID collision, whereas O_EXCL is safe (O_EXCL doesn't work on NFSv2,
but nowadays every OS implements it correctly on NFSv3)

O_EXCL is really what POSIX offers to solve this (and it's also what
import.c does).

>
>> Also, as a side note, I'm wondering whether this type of check:
>> """
>>             if not sys.platform.startswith('win'):
>>                 # On POSIX-like platforms, renaming is atomic
>> """
>>
>> couldn't be rewritten as
>> """
>>             if os.name == 'posix':
>>                 # On POSIX-like platforms, renaming is atomic
>> """
>
> No, because os.py is not available to importlib (which must be
> bootstrappable early). See the _bootstrap.py header for information
> about what is available; this is also why we use FileIO instead of
> open().

OK. So is the O_EXCL approach possible? Would something like
_io.open(_os.open(path, _os.O_CREATE|os.O_EXCL...), 'wb')

work?

Also, since this can be quite tricky and redundant, how about adding a
framework to do this kind of thing to the standard library?
Something like
with atomic_create(<final path>, 'b') as f:
    f.write(<data>)

where atomic_create would be a context manager that would make `f`
point to a temporary file (open with O_EXCL :-), and do the rename at
the end. It could also accept an option to ensure durability (i.e.
call fsync() on the file and on the parent directory). Note that it
probably wouldn't help here, since we only have access to a really
limited part of the library :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Wed Oct 12 23:06:55 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 12 Oct 2011 21:06:55 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1318438847.36.0.353546867796.issue12393@psf.upfronthosting.co.za>
Message-ID: <1318453613.56137.YahooMailNeo@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Great.? Do you want to update the docs (packaging/setupscript and maybe 

> packaging/commandref too) or shall I do it?

Feel free to do it, if that's OK with you. I've got a couple of other pythonv issues which are taking my time at the moment, plus I am also looking at Windows binary packaging as discussed recently on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12393>
_______________________________________

From report at bugs.python.org  Wed Oct 12 23:10:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 21:10:13 +0000
Subject: [issue13155] Optimize finding the max character width
In-Reply-To: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za>
Message-ID: <1318453813.51.0.799282041581.issue13155@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

find_max_char5.patch:
 - don't use adjusted ~mask+1: "precompute" the right max_char
 - rename findwidth.h to find_max_char.h
 - add some #undef

----------
Added file: http://bugs.python.org/file23392/find_max_char5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Wed Oct 12 23:10:17 2011
From: report at bugs.python.org (Mike Hoy)
Date: Wed, 12 Oct 2011 21:10:17 +0000
Subject: [issue13154] pep-0000.txt doesn't build anymore
In-Reply-To: <1318370108.79.0.613915208631.issue13154@psf.upfronthosting.co.za>
Message-ID: <1318453817.1.0.183738267313.issue13154@psf.upfronthosting.co.za>


Mike Hoy <mhoy09 at gmail.com> added the comment:

:~/peps$ find . -name "*.txt" | xargs grep "canterbury"
./pep-3152.txt:Author: Gregory Ewing <greg.ewing at canterbury.ac.nz>
./pep-0380.txt:Author: Gregory Ewing <greg.ewing at canterbury.ac.nz>
./pep-0284.txt:    Greg Ewing <greg.ewing at canterbury.ac.nz>
./pep-0335.txt:Author: Gregory Ewing <greg at cosc.canterbury.ac.nz>

Looks like pep-0335.txt has a "Gregory Ewing" with a different email address (greg at cosc.canterbury.ac.nz) that is normally associated with "Gregory Ewing" (greg.ewing at canterbury.ac.nz).

Which is an error according to:

pep0/output.py:

    if too_many_emails:
        err_output = []
        for author, emails in too_many_emails:
            err_output.append("    %s: %r" % (author, emails))
        raise ValueError("some authors have more than one email address "
                         "listed:\n" + '\n'.join(err_output))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13154>
_______________________________________

From report at bugs.python.org  Wed Oct 12 23:36:08 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 12 Oct 2011 21:36:08 +0000
Subject: [issue13157] Build Python outside the source directory
In-Reply-To: <1318421167.12.0.301144955548.issue13157@psf.upfronthosting.co.za>
Message-ID: <1318455368.04.0.850312460679.issue13157@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Which is platform with broken VPATH support and/or make ?

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13157>
_______________________________________

From report at bugs.python.org  Wed Oct 12 23:49:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 21:49:29 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za>
Message-ID: <1318456169.52.0.123762484726.issue13146@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> with atomic_create(<final path>, 'b') as f:

See issues #8604 and #8828.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Thu Oct 13 00:01:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Oct 2011 22:01:35 +0000
Subject: [issue13157] Build Python outside the source directory
In-Reply-To: <1318421167.12.0.301144955548.issue13157@psf.upfronthosting.co.za>
Message-ID: <1318456895.85.0.00406079048786.issue13157@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Which is platform with broken VPATH support and/or make ?

Well, my commit is maybe useless...

I tried to have two builds at the same time:

- debug in Python source code (e.g. ~/python)
- release in a subdirectory in the Python source code (e.g. ~/python/release)

If I compile in debug mode before building in release mode, the build of the release mode fails because make finds some objects in source tree (and so think that it doesn't need to build them).

I tried to avoid completly VPATH to support this use case, but I'm not sure that it is possible (at least, it doesn't work: it fails to build pgen in the release).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13157>
_______________________________________

From report at bugs.python.org  Thu Oct 13 00:08:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Oct 2011 22:08:07 +0000
Subject: [issue13155] Optimize finding the max character width
In-Reply-To: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za>
Message-ID: <E1RE6y5-0003w1-Ql@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9c7d3207fc15 by Antoine Pitrou in branch 'default':
Issue #13155: Optimize finding the optimal character width of an unicode string
http://hg.python.org/cpython/rev/9c7d3207fc15

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Thu Oct 13 00:08:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Oct 2011 22:08:59 +0000
Subject: [issue13155] Optimize finding the max character width
In-Reply-To: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za>
Message-ID: <1318457339.03.0.326020210271.issue13155@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> find_max_char5.patch:
> - don't use adjusted ~mask+1: "precompute" the right max_char
> - rename findwidth.h to find_max_char.h
> - add some #undef

Thank you, I've committed this version.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13155>
_______________________________________

From report at bugs.python.org  Thu Oct 13 00:17:32 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 12 Oct 2011 22:17:32 +0000
Subject: [issue13151] pysetup3 run bdist_wininst fails
In-Reply-To: <1318331538.35.0.635641564623.issue13151@psf.upfronthosting.co.za>
Message-ID: <1318457852.14.0.104685856372.issue13151@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> On line 118, replacing 'install' with 'install_dist' should fix it.

Sadly, it just defers the problem:

vinay at eta-natty:~/projects/dory$ pysetup3 run bdist_wininst
running bdist_wininst
running build
running build_py
running build_scripts
installing to build/bdist.linux-i686/wininst
running install_lib
creating build/bdist.linux-i686
creating build/bdist.linux-i686/wininst
creating build/bdist.linux-i686/wininst/PURELIB
creating build/bdist.linux-i686/wininst/PURELIB/apackage
running install_scripts
creating build/bdist.linux-i686/wininst/SCRIPTS
changing mode of build/bdist.linux-i686/wininst/SCRIPTS/dory to 755
running install_distinfo
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/METADATA
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/INSTALLER
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/REQUESTED
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/RECORD
Traceback (most recent call last):
  File "/usr/local/bin/pysetup3", line 4, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.3/packaging/run.py", line 653, in main
    return dispatcher()
  File "/usr/local/lib/python3.3/packaging/run.py", line 642, in __call__
    return func(self, self.args)
  File "/usr/local/lib/python3.3/packaging/run.py", line 91, in wrapper
    return f(*args, **kwargs)
  File "/usr/local/lib/python3.3/packaging/run.py", line 288, in _run
    dist.run_command(cmd, dispatcher.command_options[cmd])
  File "/usr/local/lib/python3.3/packaging/dist.py", line 709, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.3/packaging/command/bdist_wininst.py", line 175, in run
    self.create_exe(arcname, fullname, self.bitmap)
  File "/usr/local/lib/python3.3/packaging/command/bdist_wininst.py", line 243, in create_exe
    cfgdata = self.get_inidata()
  File "/usr/local/lib/python3.3/packaging/command/bdist_wininst.py", line 202, in get_inidata
    info = (metadata.long_description or '') + '\n'
AttributeError: 'Metadata' object has no attribute 'long_description'

It appears that there is some confusion as to whether to use attribute or item access. The failing code above needs to be replaced with something like

    if 'long_description' in metadata:
        info = metadata['long_description']
    else:
        info = metadata.get('description', '')
    info += '\n'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13151>
_______________________________________

From report at bugs.python.org  Thu Oct 13 00:33:40 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 12 Oct 2011 22:33:40 +0000
Subject: [issue13157] Build Python outside the source directory
In-Reply-To: <1318421167.12.0.301144955548.issue13157@psf.upfronthosting.co.za>
Message-ID: <1318458820.53.0.632421202118.issue13157@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I wonder why you are not stopped by:
configure: error: source directory already configured; run "make distclean" there first.
(for sure you remove some files but not all)

Applied patch is save but I cannot understand what actually is resolved.
Note that someone already report as bug(?) attempt to build outside when first project is compiled in source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13157>
_______________________________________

From report at bugs.python.org  Thu Oct 13 00:35:20 2011
From: report at bugs.python.org (Paul Moore)
Date: Wed, 12 Oct 2011 22:35:20 +0000
Subject: [issue13162] Trying to install a binary extension as a resource file
	causes pysetup to give a traceback
Message-ID: <1318458920.54.0.0914338083355.issue13162@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

I am trying to create a pysetup package that contains a precompiled binary extension, which can be installed without compiling, by using the resource file feature of setup.cfg. This may be incorrect usage of pysetup, but at a minimum, a proper error message should be given rather than a traceback.

With a directory containing an extension hello.pyd plus the following setup.cfg file:

[metadata]
name = hello
version = 0.1
author = Paul Moore
author-email = p.f.moore at gmail.com
summary = Test C extension

[files]
resources =
    hello.pyd = {platlib}

I get a traceback when I do pysetup install:

PS D:\Data\python-sample\bin> pysetup install
Installing from source directory: 'D:\\Data\\python-sample\\bin'
running install_dist
running build
running install_data
running install_distinfo
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RESOURCES
Traceback (most recent call last):
  File "D:\Data\cpython\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "D:\Data\cpython\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "D:\Data\cpython\lib\packaging\run.py", line 666, in <module>
    sys.exit(main())
  File "D:\Data\cpython\lib\packaging\run.py", line 653, in main
    return dispatcher()
  File "D:\Data\cpython\lib\packaging\run.py", line 642, in __call__
    return func(self, self.args)
  File "D:\Data\cpython\lib\packaging\run.py", line 91, in wrapper
    return f(*args, **kwargs)
  File "D:\Data\cpython\lib\packaging\run.py", line 164, in _install
    return not install_local_project(target)
  File "D:\Data\cpython\lib\packaging\install.py", line 122, in install_local_project
    return _run_install_from_dir(path)
  File "D:\Data\cpython\lib\packaging\install.py", line 160, in _run_install_from_dir
    func(source_dir)
  File "D:\Data\cpython\lib\packaging\install.py", line 87, in _run_packaging_install
    dist.run_command('install_dist')
  File "D:\Data\cpython\lib\packaging\dist.py", line 709, in run_command
    cmd_obj.run()
  File "D:\Data\cpython\lib\packaging\command\install_dist.py", line 506, in run
    self.run_command(cmd_name)
  File "D:\Data\cpython\lib\packaging\command\cmd.py", line 330, in run_command
    self.distribution.run_command(command)
  File "D:\Data\cpython\lib\packaging\dist.py", line 709, in run_command
    cmd_obj.run()
  File "D:\Data\cpython\lib\packaging\command\install_distinfo.py", line 112, in run
    writer.writerow(row)
TypeError: 'str' does not support the buffer interface

If this configuration is invalid a better error message should be given. However, I would also like to know what (if any) would be the correct way of writing a setup.cfg file to install a compiled extension like this.

For background on why I am trying to do things in this (odd) way, see the python-dev thread starting at http://mail.python.org/pipermail/python-dev/2011-October/113956.html

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 145441
nosy: alexis, eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: Trying to install a binary extension as a resource file causes pysetup to give a traceback
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13162>
_______________________________________

From report at bugs.python.org  Thu Oct 13 00:51:21 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 12 Oct 2011 22:51:21 +0000
Subject: [issue13163] `port` and `host` are confused in `_get_socket
Message-ID: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za>


New submission from Ram Rachum <ram at rachum.com>:

Look here:

http://hg.python.org/cpython/file/3313ce92cef7/Lib/smtplib.py#l279

`port` and `host` are confused.

I saw this is fixed on 3.2; possibly it should be fixed in the next 2.7 micro release too.

----------
components: Library (Lib)
messages: 145442
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `port` and `host` are confused in `_get_socket
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13163>
_______________________________________

From report at bugs.python.org  Thu Oct 13 01:38:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Oct 2011 23:38:22 +0000
Subject: [issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
In-Reply-To: <1318435320.7.0.151419273993.issue13159@psf.upfronthosting.co.za>
Message-ID: <1318462702.68.0.168377044232.issue13159@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks good to me, thanks.

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13159>
_______________________________________

From report at bugs.python.org  Thu Oct 13 02:03:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Oct 2011 00:03:03 +0000
Subject: [issue13154] pep-0000.txt doesn't build anymore
In-Reply-To: <1318370108.79.0.613915208631.issue13154@psf.upfronthosting.co.za>
Message-ID: <1318464183.49.0.0276173815627.issue13154@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13154>
_______________________________________

From report at bugs.python.org  Thu Oct 13 02:04:15 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 13 Oct 2011 00:04:15 +0000
Subject: [issue13154] pep-0000.txt doesn't build anymore
In-Reply-To: <1318370108.79.0.613915208631.issue13154@psf.upfronthosting.co.za>
Message-ID: <1318464255.34.0.253110920165.issue13154@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Fixed in 25ff1adf5f30

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13154>
_______________________________________

From report at bugs.python.org  Thu Oct 13 02:07:52 2011
From: report at bugs.python.org (John O'Connor)
Date: Thu, 13 Oct 2011 00:07:52 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318464472.94.0.204310824524.issue13150@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Thu Oct 13 02:20:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Oct 2011 00:20:04 +0000
Subject: [issue12807] Optimization/refactoring for {bytearray, bytes,
	unicode}.strip()
In-Reply-To: <1318379940.75.0.435670428348.issue12807@psf.upfronthosting.co.za>
Message-ID: <1318464976.3221.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Please double check the removal of _PyUnicode_XStrip.

I think it's ok. It is private, undocumented, and the only references
returned by Google Code Search are in Python itself.

I'll review the patch later, thank you.

----------
title: Move strip() to stringlib -> Optimization/refactoring for {bytearray, bytes, unicode}.strip()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12807>
_______________________________________

From report at bugs.python.org  Thu Oct 13 02:53:57 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 13 Oct 2011 00:53:57 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1318467237.34.0.687478022192.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


Added file: http://bugs.python.org/file23393/bdf0afbbbd80.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct 13 02:55:17 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 13 Oct 2011 00:55:17 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1318467317.03.0.0621896984011.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


Removed file: http://bugs.python.org/file23168/591277fe6b4a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct 13 03:01:22 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 13 Oct 2011 01:01:22 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1318467682.25.0.156908468123.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Patch update time! Noteworthy changes:
* Windows build support, thanks to Amaury
* Thread safety for LZMACompressor and LZMADecompressor, by means of per-instance locks
* O(n) buffer growth strategy

I've tried running the tests on Windows, but I've been getting failures
that don't look like they're related to the new code. I think they are
due to issue 7443. I'll try and tweak my Windows setup a bit over the
weekend to see if I can get things working smoothly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct 13 10:21:33 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 13 Oct 2011 08:21:33 +0000
Subject: [issue13158] tarfile.TarFile.getmembers misses some entries
In-Reply-To: <1318424072.71.0.575626132028.issue13158@psf.upfronthosting.co.za>
Message-ID: <1318494093.11.0.914685578467.issue13158@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13158>
_______________________________________

From report at bugs.python.org  Thu Oct 13 10:28:51 2011
From: report at bugs.python.org (Sebastien Binet)
Date: Thu, 13 Oct 2011 08:28:51 +0000
Subject: [issue13158] tarfile.TarFile.getmembers misses some entries
In-Reply-To: <1318424072.71.0.575626132028.issue13158@psf.upfronthosting.co.za>
Message-ID: <1318494531.94.0.0594489818801.issue13158@psf.upfronthosting.co.za>


Sebastien Binet <binet at cern.ch> added the comment:

one interesting additional piece of information is that if I un-tar that file and re-tar it w/o gzip compression, getmembers gets the right answer.

-s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13158>
_______________________________________

From report at bugs.python.org  Thu Oct 13 13:45:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 13 Oct 2011 11:45:45 +0000
Subject: [issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
In-Reply-To: <1318435320.7.0.151419273993.issue13159@psf.upfronthosting.co.za>
Message-ID: <E1REJjK-0001br-Qs@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d18c80a8c119 by Nadeem Vawda in branch '3.2':
Issue #13159: Replace FileIO's quadratic-time buffer growth algorithm with a linear-time one.
http://hg.python.org/cpython/rev/d18c80a8c119

New changeset 4a6709a071d0 by Nadeem Vawda in branch 'default':
Merge #13159: Replace FileIO's quadratic-time buffer growth algorithm with a linear-time one.
http://hg.python.org/cpython/rev/4a6709a071d0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13159>
_______________________________________

From report at bugs.python.org  Thu Oct 13 13:58:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 13 Oct 2011 11:58:32 +0000
Subject: [issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
In-Reply-To: <1318435320.7.0.151419273993.issue13159@psf.upfronthosting.co.za>
Message-ID: <E1REJvi-0002dy-Jt@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c1c434e30e06 by Nadeem Vawda in branch '2.7':
Issue #13159: Replace FileIO's quadratic-time buffer growth algorithm with a linear-time one.
http://hg.python.org/cpython/rev/c1c434e30e06

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13159>
_______________________________________

From report at bugs.python.org  Thu Oct 13 14:04:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Oct 2011 12:04:31 +0000
Subject: [issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
In-Reply-To: <1318435320.7.0.151419273993.issue13159@psf.upfronthosting.co.za>
Message-ID: <1318507471.8.0.653961278916.issue13159@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13159>
_______________________________________

From report at bugs.python.org  Thu Oct 13 14:22:59 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 13 Oct 2011 12:22:59 +0000
Subject: [issue13134] speed up finding of one-character strings
In-Reply-To: <1318105744.0.0.664183527644.issue13134@psf.upfronthosting.co.za>
Message-ID: <1318508579.99.0.189416123823.issue13134@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the >1 character sizes are overly complex in this patch, and still memchr isn't typically used for them. So I suggest to simplify the code and restrict it to 1-byte chars only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Thu Oct 13 14:35:21 2011
From: report at bugs.python.org (Valvanuz)
Date: Thu, 13 Oct 2011 12:35:21 +0000
Subject: [issue13164] importing rlcompleter module writes a control sequence
	in stdout
Message-ID: <1318509320.97.0.686046301557.issue13164@psf.upfronthosting.co.za>


New submission from Valvanuz <valvanuz.fernandez at gestion.unican.es>:

When you import the module rlcompleter in a python script in Centos 6 (x86_64), the control sequence \033[?1034h is printed in stdout. The problem is that these sequence is not visible by the user and cause a lot of confusion. 

In my case I compared the output of a python script (the integer 6) in bash and I got:

 test: 6: integer expression expected

How to reproduce:

 =============================
 BASH SCRIPT that calls test.py
 =============================
 id=$(./test.py)
 echo $id|sed -n l
 if test ${id} -eq 0;then
 fi

 =========
 test.py
 =========
 #!/usr/bin/python
 import rlcompleter
 a=2
 print a

========
OUTPUT
========
[valva at wn009 ~]$ bash p.sh 
\033[?1034h2$
p.sh: line 3: test: 2: integer expression expected


This only has happened to me in Centos 6 (python 2.6.5) I've tested in Centos 5, debian and Ubuntu and it does not happen.

----------
messages: 145452
nosy: valva
priority: normal
severity: normal
status: open
title: importing rlcompleter module writes a control sequence in stdout
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13164>
_______________________________________

From report at bugs.python.org  Thu Oct 13 16:02:00 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 13 Oct 2011 14:02:00 +0000
Subject: [issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
In-Reply-To: <1318435320.7.0.151419273993.issue13159@psf.upfronthosting.co.za>
Message-ID: <1318514520.55.0.335502732819.issue13159@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

No problem :)

----------
assignee:  -> nadeem.vawda
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13159>
_______________________________________

From report at bugs.python.org  Thu Oct 13 16:21:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Oct 2011 14:21:13 +0000
Subject: [issue13134] speed up finding of one-character strings
In-Reply-To: <1318508579.99.0.189416123823.issue13134@psf.upfronthosting.co.za>
Message-ID: <1318515446.3209.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think the >1 character sizes are overly complex in this patch, and
> still memchr isn't typically used for them. So I suggest to simplify
> the code and restrict it to 1-byte chars only.

I would rather propose to simplify the needle heuristic and only use it
when the lower byte is non-zero. A properly optimized memchr() (as in
the glibc / gcc) is definitely faster than our na?ve loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Thu Oct 13 17:21:47 2011
From: report at bugs.python.org (higery)
Date: Thu, 13 Oct 2011 15:21:47 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1318519307.07.0.144449434037.issue8668@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>> What?s more practical for you, a review or a patch?

I think a review is better(thanks for your time:) ), because some changes maybe needed after I have finished all the issues against the develop command.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Oct 13 17:29:15 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 13 Oct 2011 15:29:15 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1318519755.88.0.965002062598.issue6715@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have imported xz-5.0.3 into the externals repository now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct 13 17:29:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Oct 2011 15:29:16 +0000
Subject: [issue13163] `port` and `host` are confused in `_get_socket
In-Reply-To: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za>
Message-ID: <1318519756.09.0.920915698194.issue13163@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13163>
_______________________________________

From report at bugs.python.org  Thu Oct 13 17:37:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Oct 2011 15:37:26 +0000
Subject: [issue13165] Integrate stringbench in the Tools directory
Message-ID: <1318520246.46.0.148882944484.issue13165@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The stringbench suite of micro-benchmarks, currently available through SVN at http://svn.python.org/projects/sandbox/trunk/stringbench, would probably be a reasonable addition to the Tools directory.

----------
components: Demos and Tools
keywords: easy
messages: 145457
nosy: haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Integrate stringbench in the Tools directory
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13165>
_______________________________________

From report at bugs.python.org  Thu Oct 13 17:40:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Oct 2011 15:40:53 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318520453.17.0.0814758173461.issue13150@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Since #9878 proposes an *alternate* solution to *part* of the
> sysconfig problem, I disagree with 'supersede'.
It?s also an older issue.

> A Python solution would be more useful for other implementations
> if enough of the sysconfig info is not CPython specific.
That?s the point: the info currently parsed at runtime by sysconfig is specific to CPython (Makefile and pyconfig.h), so adding a CPython-specific C module was thought the way to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Thu Oct 13 17:42:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Oct 2011 15:42:06 +0000
Subject: [issue13162] Trying to install a binary extension as a resource file
	causes pysetup to give a traceback
In-Reply-To: <1318458920.54.0.0914338083355.issue13162@psf.upfronthosting.co.za>
Message-ID: <1318520526.91.0.759569550676.issue13162@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This does not look related to installing binary files at all, but rather an already known bug: #12386.

----------
assignee: tarek -> eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> packaging fails in install_distinfo when writing RESOURCES

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13162>
_______________________________________

From report at bugs.python.org  Thu Oct 13 17:43:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Oct 2011 15:43:30 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1318520610.48.0.986930595886.issue12386@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I started to look at this a few days ago and found out that there are no tests at all for writing RESOURCES.  I need to look again at the documentation and code and add many tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Thu Oct 13 17:45:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Oct 2011 15:45:57 +0000
Subject: [issue13151] pysetup3 run bdist_wininst fails
In-Reply-To: <1318331538.35.0.635641564623.issue13151@psf.upfronthosting.co.za>
Message-ID: <1318520757.56.0.821710801308.issue13151@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Metadata now only uses item access, and the names have changed: long_description is description, url is home_page, former description is summary, etc. (more in PEP 345).  I don?t have Windows yet, so either we wait or we iterate I make a patch - you report failures - I make a patch etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13151>
_______________________________________

From report at bugs.python.org  Thu Oct 13 17:50:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Oct 2011 15:50:29 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318520453.17.0.0814758173461.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318520803.3209.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > A Python solution would be more useful for other implementations
> > if enough of the sysconfig info is not CPython specific.
> That?s the point: the info currently parsed at runtime by sysconfig is
> specific to CPython (Makefile and pyconfig.h), so adding a
> CPython-specific C module was thought the way to go.

A module doesn't have to be written in C to be CPython-specific.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Thu Oct 13 17:52:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Oct 2011 15:52:11 +0000
Subject: [issue13166] Implement packaging.database.Distribution.__str__
Message-ID: <1318521131.43.0.0575328734451.issue13166@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

In code working with instances of packaging.database.Distribution, it?s bothersome to have to use '%r %s' % (dist.name, dist.version) all the time.  It is also not good-looking in 2.x, where we get u'name'.  I think it would be best to implement a __str__ method on the class and just use %s everywhere, for example in pysetup list and pysetup search.  More sophisticated clients that want to display projects in a GUI can still access dist.name, dist.version and other attributes.

I?ve insisted on using %r for project names and paths to avoid ambiguities with trailing spaces and such hard-to-catch things.  For logging output, we have to pass pure strings, but for direct console printing we could use ANSI escape sequences to display projects? names in bold for example.

----------
assignee: tarek
components: Distutils2
messages: 145463
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Implement packaging.database.Distribution.__str__
versions: 3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13166>
_______________________________________

From report at bugs.python.org  Thu Oct 13 17:58:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Oct 2011 15:58:18 +0000
Subject: [issue13165] Integrate stringbench in the Tools directory
In-Reply-To: <1318520246.46.0.148882944484.issue13165@psf.upfronthosting.co.za>
Message-ID: <1318521498.19.0.308476843284.issue13165@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Some ideas to improve stringbench:

 - test different Unicode range (stringbench tests only ASCII currently)
 - test mixing different Unicode range, e.g. ascii+latin1, UCS2.find(ascii), UCS2.replace(UCS2, UCS4), ...
 - add options to configure string lengths

Python 3.3 is now a little bit faster for pure ASCII strings. Python 3.2 is sometimes a little bit slower with non-BMP characters in narrow mode.

I expect different differents on Python 3.3 if we test different Unicode ranges.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13165>
_______________________________________

From report at bugs.python.org  Thu Oct 13 18:01:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Oct 2011 16:01:33 +0000
Subject: [issue13167] Add get_metadata to packaging
Message-ID: <1318521693.13.0.517549681601.issue13167@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The PEP 376 implementation in packaging.database has been called ugly and opaque.  When discussing PEP 396 for example (that?s why I?m adding Barry and Antoine to nosy, for their feedback), get_distribution(name).metadata['Version'] did not seem to agree with everyone.  (Note that there are shortcuts for two metadata fields: name and version also exist as get_distribution(name).name / .version.)

I?m not sure how we can make it less opaque, unless we force people to read documentation: PEP 376 proposes a database of installed distributions; packaging.database offers get_distribution, which returns an object with some attributes.  I can?t have an outside view on this, so maybe you can explain what?s opaque and ugly so that we can try to improve it.

I?ve found in distutils-sig archives from two or three years ago that people intended to offer a get_metadata function that would take a distribution name (i.e. pyOpenSSL, Babel, flufl.enum) and return a mapping object with the metadata read from the installed dist-info/METADATA file.  Does that look better to you?

----------
assignee: tarek
components: Distutils2
files: d2-get_metadata.diff
keywords: patch
messages: 145465
nosy: alexis, barry, eric.araujo, pitrou, tarek
priority: normal
severity: normal
status: open
title: Add get_metadata to packaging
versions: 3rd party, Python 3.3
Added file: http://bugs.python.org/file23394/d2-get_metadata.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13167>
_______________________________________

From report at bugs.python.org  Thu Oct 13 18:04:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Oct 2011 16:04:11 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1318521851.49.0.984177722765.issue12344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This patch has tests that look sensible and pass.

----------
Added file: http://bugs.python.org/file23395/d2-get_reinitialized_command-kwargs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Thu Oct 13 18:05:33 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 13 Oct 2011 16:05:33 +0000
Subject: [issue13134] speed up finding of one-character strings
In-Reply-To: <1318515446.3209.3.camel@localhost.localdomain>
Message-ID: <4E970C4B.3050307@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I would rather propose to simplify the needle heuristic and only use it
> when the lower byte is non-zero. A properly optimized memchr() (as in
> the glibc / gcc) is definitely faster than our na?ve loop.

That would be fine as well. Not sure if a heuristics would be needed in
this case at all: it's probably uncommon that you search for a single
character whose lower-half is 0 (most likely you are then searching for
the null character, and not, say, LATIN CAPITAL LETTER A WITH DOUBLE
GRAVE).

In any case, I still think that the heuristics (if any) needs to be
explained better, and needs some justification in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13134>
_______________________________________

From report at bugs.python.org  Thu Oct 13 18:08:54 2011
From: report at bugs.python.org (Randy Galbraith)
Date: Thu, 13 Oct 2011 16:08:54 +0000
Subject: [issue13168] Python 2.6 having trouble finding modules when invoked
	via a symlink
Message-ID: <1318522134.74.0.524944339938.issue13168@psf.upfronthosting.co.za>


New submission from Randy Galbraith <RandyGalbraith at cvty.com>:

Hi Python Developers,

Our install of Python 2.6.4 on AIX 5.3 seems to have problems finding modules
when invoked via a symlink.  A direct path to the binary will work.  One symlink
will work, but another will not.  I created a test harness to demonstrate this
issue and collect (hopefully) useful output.

Regards,
-Randy Galbraith
ps. Thanks for making such a great tool available!

--test script--
#!/bin/sh

ACTUAL_BINARY=/mypath/tool/Python-2.6.4/powerpc-AIX5.3/bin/python
FIRST_SYMLINK=/mypath/tool/bin/python
SECOND_SYMLINK=/mypath/tool/powerpc-AIX5.3/bin/python

set -x
echo
echo "Actual binary..."
ls -ld $ACTUAL_BINARY

echo
echo "First symlink..."
ls -ld $FIRST_SYMLINK

echo
echo "Second symlink..."
ls -ld $SECOND_SYMLINK

echo
echo "Run with actual binary is good..."
$ACTUAL_BINARY -m py_compile test.py

echo
echo "Run with first symlink is bad..."
$FIRST_SYMLINK -m py_compile test.py

echo
echo "Run with second symlink is good..."
$SECOND_SYMLINK  -m py_compile test.py

set +x
echo
echo "Analysis..."
truss $ACTUAL_BINARY -m py_compile test.py 2>truss_binary.log

truss $FIRST_SYMLINK -m py_compile test.py 2>truss_symlink1.log

truss $SECOND_SYMLINK  -m py_compile test.py 2>truss_symlink2.log

echo
echo "runpy is found..."
grep runpy truss_binary.log

echo
echo "runpy is not found..."
grep runpy truss_symlink1.log

echo
echo "runpy is found..."
grep runpy truss_symlink2.log
--end test script--

--terminal output--
$ ./test_script.sh
+ echo

+ echo Actual binary...
Actual binary...
+ ls -ld /mypath/tool/Python-2.6.4/powerpc-AIX5.3/bin/python
-rwxr-xr-x 2 myuserid mygroup1 9727885 2010-02-25 10:57 /mypath/tool/Python-2.6.4/powerpc-AIX5.3/bin/python
+ echo

+ echo First symlink...
First symlink...
+ ls -ld /mypath/tool/bin/python
lrwxrwxrwx 1 myuserid mygroup2 44 2010-06-02 17:16 /mypath/tool/bin/python -> ../../Python-2.6.4/powerpc-AIX5.3/bin/python
+ echo

+ echo Second symlink...
Second symlink...
+ ls -ld /mypath/tool/powerpc-AIX5.3/bin/python
lrwxrwxrwx 1 myuserid mygroup2 44 2010-06-02 17:16 /mypath/tool/powerpc-AIX5.3/bin/python -> ../../Python-2.6.4/powerpc-AIX5.3/bin/python
+ echo

+ echo Run with actual binary is good...
Run with actual binary is good...
+ /mypath/tool/Python-2.6.4/powerpc-AIX5.3/bin/python -m py_compile test.py
+ echo

+ echo Run with first symlink is bad...
Run with first symlink is bad...
+ /mypath/tool/bin/python -m py_compile test.py
Could not import runpy module
+ echo

+ echo Run with second symlink is good...
Run with second symlink is good...
+ /mypath/tool/powerpc-AIX5.3/bin/python -m py_compile test.py

Analysis...

runpy is found...
statx("runpy", 0x2FF21168, 76, 0)		Err#2  ENOENT
open("runpy.so", O_RDONLY)			Err#2  ENOENT
open("runpymodule.so", O_RDONLY)		Err#2  ENOENT
open("runpy.py", O_RDONLY)			Err#2  ENOENT
open("runpy.pyc", O_RDONLY)			Err#2  ENOENT
statx("/mypath/tool/Python-2.6.4/lib/python2.6/runpy", 0x2FF21168, 76, 0) Err#2  ENOENT
open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.so", O_RDONLY) Err#2  ENOENT
open("/mypath/tool/Python-2.6.4/lib/python2.6/runpymodule.so", O_RDONLY) Err#2  ENOENT
open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.py", O_RDONLY) = 3
open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.pyc", O_RDONLY) = 4

runpy is not found...
statx("runpy", 0x2FF21188, 76, 0)		Err#2  ENOENT
open("runpy.so", O_RDONLY)			Err#2  ENOENT
open("runpymodule.so", O_RDONLY)		Err#2  ENOENT
open("runpy.py", O_RDONLY)			Err#2  ENOENT
open("runpy.pyc", O_RDONLY)			Err#2  ENOENT
Could not import runpy module

runpy is found...
statx("runpy", 0x2FF21178, 76, 0)		Err#2  ENOENT
open("runpy.so", O_RDONLY)			Err#2  ENOENT
open("runpymodule.so", O_RDONLY)		Err#2  ENOENT
open("runpy.py", O_RDONLY)			Err#2  ENOENT
open("runpy.pyc", O_RDONLY)			Err#2  ENOENT
statx("/mypath/tool/Python-2.6.4/lib/python2.6/runpy", 0x2FF21178, 76, 0) Err#2  ENOENT
open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.so", O_RDONLY) Err#2  ENOENT
open("/mypath/tool/Python-2.6.4/lib/python2.6/runpymodule.so", O_RDONLY) Err#2  ENOENT
open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.py", O_RDONLY) = 3
open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.pyc", O_RDONLY) = 4

--end terminal output--

----------
components: Interpreter Core
messages: 145468
nosy: RandyGalbraith
priority: normal
severity: normal
status: open
title: Python 2.6 having trouble finding modules when invoked via a symlink
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13168>
_______________________________________

From report at bugs.python.org  Thu Oct 13 18:30:27 2011
From: report at bugs.python.org (Maurice de Rooij)
Date: Thu, 13 Oct 2011 16:30:27 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions and
	above makes Python crash
Message-ID: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>


New submission from Maurice de Rooij <mauder at gmail.com>:

Regular expressions with 0 to 65536 repetitions and above makes Python crash with a "OverflowError: regular expression code size limit exceeded" exception.
65535 repetitions do not raise this issue.

Tested and confirmed this with versions 2.7.1 and 3.2.2.

C:\Python27>python.exe
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.search('(?s)\A.{0,65535}test', 'test')
<_sre.SRE_Match object at 0x00B4E4B8>
>>> re.search('(?s)\A.{0,65536}test', 'test')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\re.py", line 142, in search
    return _compile(pattern, flags).search(string)
  File "C:\Python27\lib\re.py", line 243, in _compile
    p = sre_compile.compile(pattern, flags)
  File "C:\Python27\lib\sre_compile.py", line 523, in compile
    groupindex, indexgroup
OverflowError: regular expression code size limit exceeded
>>>

C:\Python32>python.exe
Python 3.2.2 (default, Sep  4 2011, 09:51:08) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.search('(?s)\A.{0,65535}test', 'test')
<_sre.SRE_Match object at 0x00A6F250>
>>> re.search('(?s)\A.{0,65536}test', 'test')
Traceback (most recent call last):
  File "C:\Python32\lib\functools.py", line 176, in wrapper
    result = cache[key]
KeyError: (<class 'str'>, '(?s)\\A.{0,65536}test', 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python32\lib\re.py", line 158, in search
    return _compile(pattern, flags).search(string)
  File "C:\Python32\lib\re.py", line 255, in _compile
    return _compile_typed(type(pattern), pattern, flags)
  File "C:\Python32\lib\functools.py", line 180, in wrapper
    result = user_function(*args, **kwds)
  File "C:\Python32\lib\re.py", line 267, in _compile_typed
    return sre_compile.compile(pattern, flags)
  File "C:\Python32\lib\sre_compile.py", line 514, in compile
    groupindex, indexgroup
OverflowError: regular expression code size limit exceeded
>>>

----------
components: Library (Lib)
messages: 145469
nosy: techmaurice
priority: normal
severity: normal
status: open
title: Regular expressions with 0 to 65536 repetitions and above makes Python crash
type: crash
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Thu Oct 13 18:32:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Oct 2011 16:32:29 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions and
	above makes Python crash
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1318523549.5.0.490386265583.issue13169@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Thu Oct 13 18:37:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Oct 2011 16:37:17 +0000
Subject: [issue13170] distutils2 test failures
Message-ID: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I get three errors/failures on linux3:

ERROR: test_simple_run (distutils2.tests.test_command_install_data.InstallDataTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "distutils2/tests/test_command_install_data.py", line 76, in test_simple_run
    cmd.run()
  File "distutils2/command/install_data.py", line 50, in run
    out = self.copy_file(_file[0], dir_dest)[0]
  File "distutils2/command/cmd.py", line 378, in copy_file
    copyfile(infile, outfile)
  File "distutils2/_backport/shutil.py", line 83, in copyfile
    raise Error("`%s` and `%s` are the same file" % (src, dst))
Error: `/tmp/user/1013/tmpEl9F8m/tmp91wrrV/foo/inst/three` and `/tmp/user/1013/tmpEl9F8m/tmp91wrrV/foo/inst/three` are the same file

======================================================================
FAIL: test_config (distutils2.tests.test_config.ConfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "distutils2/tests/test_config.py", line 291, in test_config
    self.assertEqual(dist.package_data, {'cheese': 'data/templates/*'})
AssertionError: {u'cheese': [u'data/templates/*']} != {'cheese': 'data/templates/*'}
- {u'cheese': [u'data/templates/*']}
?  -          --                  -

+ {'cheese': 'data/templates/*'}

======================================================================
FAIL: test_parse_extensions_in_config (distutils2.tests.test_config.ConfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "distutils2/tests/test_config.py", line 341, in test_parse_extensions_in_config
    self.assertEqual(ext.sources, ['c_src/speed_coconuts.c'])
AssertionError: Lists differ: ['c\x00\x00\x00_\x00\x00\x00s\... != ['c_src/speed_coconuts.c']

First differing element 0:
c_src/speed_coconuts.c
c_src/speed_coconuts.c

- ['c\x00\x00\x00_\x00\x00\x00s\x00\x00\x00r\x00\x00\x00c\x00\x00\x00/\x00\x00\x00s\x00\x00\x00p\x00\x00\x00e\x00\x00\x00e\x00\x00\x00d\x00\x00\x00_\x00\x00\x00c\x00\x00\x00o\x00\x00\x00c\x00\x00\x00o\x00\x00\x00n\x00\x00\x00u\x00\x00\x00t\x00\x00\x00s\x00\x00\x00.\x00\x00\x00c\x00\x00\x00']
+ ['c_src/speed_coconuts.c']

The last one looks like a codecs issue.

----------
assignee: tarek
components: Distutils2
messages: 145470
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils2 test failures
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Thu Oct 13 18:38:16 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 13 Oct 2011 16:38:16 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions and
	above makes Python crash
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1318523896.25.0.701113103617.issue13169@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I might be missing something, but what's the issue? 65535 is the limit, and doing 65536 gives a clear overflow exception (no crash).

----------
nosy: +brian.curtin
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Thu Oct 13 18:39:13 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 13 Oct 2011 16:39:13 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1318523953.13.0.52814308735.issue13169@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
title: Regular expressions with 0 to 65536 repetitions and above makes Python crash -> Regular expressions with 0 to 65536 repetitions raises OverflowError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Thu Oct 13 18:58:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Oct 2011 16:58:42 +0000
Subject: [issue13027] python 2.6.6 interpreter core dumps on modules command
	from help prompt
In-Reply-To: <1316699786.14.0.395194212825.issue13027@psf.upfronthosting.co.za>
Message-ID: <1318525122.29.0.811441877651.issue13027@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Unless I?m mistaken, this is another of the duplicate reports for the bug fixed by Ned in 2.7 recently.

----------
nosy: +eric.araujo, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13027>
_______________________________________

From report at bugs.python.org  Thu Oct 13 19:25:38 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 13 Oct 2011 17:25:38 +0000
Subject: [issue13151] pysetup3 run bdist_wininst fails
In-Reply-To: <1318331538.35.0.635641564623.issue13151@psf.upfronthosting.co.za>
Message-ID: <1318526738.12.0.999393107487.issue13151@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I don?t have Windows yet, so either we wait or we iterate I make a patch - you report failures - I make a patch etc.

Actually I'm finding these failures on Ubuntu :-)

Although there are MBCS encoding issues which will also need to be fixed before you can build a pure-Python .exe installer on Linux (which is possible with distutils, so should work in packaging too), these failures occur before you get to that point. That last part can be fixed on Linux by doing (in bdist_wininst.create_exe):

try:
    cfgdata = cfgdata.encode("mbcs")
except LookupError:
    cfgdata = cfgdata.encode("latin-1")

which is at least better than what we have now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13151>
_______________________________________

From report at bugs.python.org  Thu Oct 13 19:26:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 13 Oct 2011 17:26:34 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1318526794.18.0.960620058854.issue13169@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Thu Oct 13 19:34:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Oct 2011 17:34:57 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za>
Message-ID: <1318527297.66.0.226387804232.issue13146@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, here is a new patch using O_EXCL.
Also, since import.c is quite different in 3.2, I'm not sure I will bother backporting.

----------
versions:  -Python 3.2
Added file: http://bugs.python.org/file23396/importrename3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Thu Oct 13 19:46:28 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 13 Oct 2011 17:46:28 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1318527988.76.0.095026712804.issue13169@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The quantifiers use 65535 to represent no upper limit, so ".{0,65535}" is equivalent to ".*".

For example:

>>> re.match(".*", "x" * 100000).span()
(0, 100000)
>>> re.match(".{0,65535}", "x" * 100000).span()
(0, 100000)

but:

>>> re.match(".{0,65534}", "x" * 100000).span()
(0, 65534)

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Thu Oct 13 19:56:23 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 13 Oct 2011 17:56:23 +0000
Subject: [issue13167] Add get_metadata to packaging
In-Reply-To: <1318521693.13.0.517549681601.issue13167@psf.upfronthosting.co.za>
Message-ID: <20111013135619.18476be8@limelight.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Oct 13, 2011, at 04:01 PM, ?ric Araujo wrote:

>The PEP 376 implementation in packaging.database has been called ugly and
>opaque.  When discussing PEP 396 for example (that?s why I?m adding Barry and
>Antoine to nosy, for their feedback),
>get_distribution(name).metadata['Version'] did not seem to agree with
>everyone.  (Note that there are shortcuts for two metadata fields: name and
>version also exist as get_distribution(name).name / .version.)

I don't entirely remember my objections to the API, but I wonder if you
couldn't provide attribute access via properties on .metadata?  Or are there
keys that can't be mapped to identifiers (modulo typical dash-to-underscore
mappings)?

>I?m not sure how we can make it less opaque, unless we force people to read
>documentation: PEP 376 proposes a database of installed distributions;
>packaging.database offers get_distribution, which returns an object with some
>attributes.  I can?t have an outside view on this, so maybe you can explain
>what?s opaque and ugly so that we can try to improve it.
>
>I?ve found in distutils-sig archives from two or three years ago that people
>intended to offer a get_metadata function that would take a distribution name
>(i.e. pyOpenSSL, Babel, flufl.enum) and return a mapping object with the
>metadata read from the installed dist-info/METADATA file.  Does that look
>better to you?

So, that would mean instead of

get_distribution(name).metadata['Version']

you'd use

get_metadata(name)['Version']

?

I'm not sure that's really buys you much.

Maybe we just need to live with the current API for a while before we try to
improve it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13167>
_______________________________________

From report at bugs.python.org  Thu Oct 13 20:40:10 2011
From: report at bugs.python.org (Alexander Steppke)
Date: Thu, 13 Oct 2011 18:40:10 +0000
Subject: [issue13171] Bug in tempfile module
Message-ID: <1318531210.93.0.392401137226.issue13171@psf.upfronthosting.co.za>


New submission from Alexander Steppke <asteppke at gmail.com>:

The tempfile module shows strange behavior under certain conditions. This might lead to data leaking or other problems. 

The test session looks as follows:

Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tmp = tempfile.TemporaryFile()
>>> tmp.read()
''
>>> tmp.write('test')
>>> tmp.read()
'P\xf6D\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ [ommitted]'

or similar behavior in text mode: 

Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tmp = tempfile.TemporaryFile('w+t')
>>> tmp.read()
''
>>> tmp.write('test')
>>> tmp.read()
'\x00\xa5\x8b\x02int or long, hash(a) is used instead.\n    i\x10 [ommitted]'
>>> tmp.seek(0)
>>> tmp.readline()
'test\x00\xa5\x8b\x02int or long, hash(a) is used instead.\n'

This bug seems to be triggered by calling tmp.read() before tmp.seek(). I am running Python 2.7.2 on Windows 7 x64, other people have reproduced the problem on Windows XP but not under Linux or Cygwin (see also http://stackoverflow.com/questions/7757663/python-tempfile-broken-or-am-i-doing-it-wrong).

Thank you for looking into this.
Alexander

----------
components: Library (Lib), Windows
messages: 145477
nosy: Alexander.Steppke
priority: normal
severity: normal
status: open
title: Bug in tempfile module
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13171>
_______________________________________

From report at bugs.python.org  Thu Oct 13 20:47:51 2011
From: report at bugs.python.org (Paul Moore)
Date: Thu, 13 Oct 2011 18:47:51 +0000
Subject: [issue13172] pysetup run --list-commands fails with a traceback
Message-ID: <1318531671.43.0.795221927422.issue13172@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

In a directory with 2 files, setup.cfg and a single C file containing source for an extension module. The same happens with a pure-python module. This is on Windows.

PS D:\Data\python-sample> D:\Data\cpython\PCbuild\python.exe -m packaging.run run --list-commands
List of available commands:
  bdist: create a built (binary) distribution
  bdist_dumb: create a "dumb" built distribution
Traceback (most recent call last):
  File "D:\Data\cpython\lib\packaging\util.py", line 652, in resolve_name
    ret = getattr(ret, part)
AttributeError: 'module' object has no attribute 'bdist_msi'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\Data\cpython\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "D:\Data\cpython\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "D:\Data\cpython\lib\packaging\run.py", line 666, in <module>
    sys.exit(main())
  File "D:\Data\cpython\lib\packaging\run.py", line 653, in main
    return dispatcher()
  File "D:\Data\cpython\lib\packaging\run.py", line 642, in __call__
    return func(self, self.args)
  File "D:\Data\cpython\lib\packaging\run.py", line 91, in wrapper
    return f(*args, **kwargs)
  File "D:\Data\cpython\lib\packaging\run.py", line 264, in _run
    cls = dispatcher.cmdclass.get(cmd) or get_command_class(cmd)
  File "D:\Data\cpython\lib\packaging\command\__init__.py", line 61, in get_command_class
    cls = resolve_name(cls)
  File "D:\Data\cpython\lib\packaging\util.py", line 654, in resolve_name
    raise ImportError(exc)
ImportError: 'module' object has no attribute 'bdist_msi'

----------
assignee: tarek
components: Distutils2
messages: 145478
nosy: alexis, eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: pysetup run --list-commands fails with a traceback
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13172>
_______________________________________

From report at bugs.python.org  Thu Oct 13 20:51:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 13 Oct 2011 18:51:28 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1318531888.1.0.455689187789.issue6210@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Thu Oct 13 21:11:20 2011
From: report at bugs.python.org (vterron)
Date: Thu, 13 Oct 2011 19:11:20 +0000
Subject: [issue13163] `port` and `host` are confused in `_get_socket
In-Reply-To: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za>
Message-ID: <1318533080.86.0.741757105495.issue13163@psf.upfronthosting.co.za>


vterron <quintanar at gmail.com> added the comment:

Added a ridiculously simple patch, in case it is going to get fixed in 2.7.

----------
keywords: +patch
nosy: +vterron
Added file: http://bugs.python.org/file23397/smtplib.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13163>
_______________________________________

From report at bugs.python.org  Thu Oct 13 21:11:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Oct 2011 19:11:23 +0000
Subject: [issue13171] Bug in tempfile module
In-Reply-To: <1318531210.93.0.392401137226.issue13171@psf.upfronthosting.co.za>
Message-ID: <1318533083.4.0.748800804091.issue13171@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I wonder if it is a bug in Windows?  Have you tried similar experiments with regular files?  tempfile is really just about *where* the files are located (and what happens when they are closed), not about their fundamental nature as OS file objects.  (I could be wrong about that on Windows of course, I'm more familiar with Linux.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13171>
_______________________________________

From report at bugs.python.org  Thu Oct 13 21:32:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Oct 2011 19:32:00 +0000
Subject: [issue13163] `port` and `host` are confused in `_get_socket
In-Reply-To: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za>
Message-ID: <1318534320.75.0.460321679023.issue13163@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, your patch is a little *too* simple: it doesn't change the function prototype to match :)

This is a cosmetic issue rather than a bug, but it would still be nice to fix it.  Or maybe a documentation issue in the sense that Python code is (usually) self documenting :)

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13163>
_______________________________________

From report at bugs.python.org  Thu Oct 13 21:34:13 2011
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 13 Oct 2011 19:34:13 +0000
Subject: [issue13163] `port` and `host` are confused in `_get_socket
In-Reply-To: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za>
Message-ID: <1318534453.17.0.05502740246.issue13163@psf.upfronthosting.co.za>


Ram Rachum <ram at rachum.com> added the comment:

The reason this bug bothered me is because I was debugging a Django app, and in the stacktrace's local variables I suddenly saw that `host` was `25`, which seemed like a bug to me and wasted me 5 minutes. So it's not a critical bug but it wasted my time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13163>
_______________________________________

From report at bugs.python.org  Thu Oct 13 21:39:46 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Oct 2011 19:39:46 +0000
Subject: [issue13027] python 2.6.6 interpreter core dumps on modules command
	from help prompt
In-Reply-To: <1316699786.14.0.395194212825.issue13027@psf.upfronthosting.co.za>
Message-ID: <1318534786.32.0.0193922767368.issue13027@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The recent fixes do not address cases like here where importing a module causes a crash in the interpreter process, usually due to some faulty third-party extension module.  One way to handle it more gracefully might be to move the import scan to a separate interpreter subprocess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13027>
_______________________________________

From report at bugs.python.org  Thu Oct 13 21:46:33 2011
From: report at bugs.python.org (=?utf-8?b?VsOtY3RvciBUZXJyw7Nu?=)
Date: Thu, 13 Oct 2011 19:46:33 +0000
Subject: [issue13163] `port` and `host` are confused in `_get_socket
In-Reply-To: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za>
Message-ID: <1318535193.77.0.480858432794.issue13163@psf.upfronthosting.co.za>


V?ctor Terr?n <quintanar at gmail.com> added the comment:

It was strange it was *that* easy. My newbie apologies, David. Let me take a look at it -- hopefully it will be an adequate first task for a newcomer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13163>
_______________________________________

From report at bugs.python.org  Thu Oct 13 23:16:05 2011
From: report at bugs.python.org (Bfontaine)
Date: Thu, 13 Oct 2011 21:16:05 +0000
Subject: [issue13173] Default values for string.Template
Message-ID: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>


New submission from Bfontaine <batifon at yahoo.fr>:

This patch allows you to define default values for a string.Template, which is useful when you need to use a lot some values, but sometimes other values.

for example:

>>> from string import Template
>>> s = Template("${user} made me a ${flavor} cake.", default={"user":"Dennis"})
>>> s.substitute(flavor="vanilla")
'Dennis made me a vanilla cake.'
>>> s.substitute(user="Ken", flavor="chocolate")
'Ken made me chocolate cake.'

----------
components: Library (Lib)
files: string_template_default_values.tar
messages: 145485
nosy: nitupho
priority: normal
severity: normal
status: open
title: Default values for string.Template
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file23398/string_template_default_values.tar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13173>
_______________________________________

From report at bugs.python.org  Thu Oct 13 23:32:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Oct 2011 21:32:47 +0000
Subject: [issue13174] test_os failures on Fedora 15: listxattr() returns
	['security.selinux']
Message-ID: <1318541567.35.0.652639760355.issue13174@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

======================================================================
FAIL: test_fds (test.test_os.ExtendedAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1599, in test_fds
    self._check_xattrs(getxattr, setxattr, removexattr, listxattr)
  File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1574, in _check_xattrs
    self._check_xattrs_str(str, *args)
  File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1543, in _check_xattrs_str
    self.assertEqual(listxattr(fn), [])
AssertionError: Lists differ: ['security.selinux'] != []

First list contains 1 additional elements.
First extra element 0:
security.selinux

- ['security.selinux']
+ []

======================================================================
FAIL: test_lpath (test.test_os.ExtendedAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1584, in test_lpath
    os.llistxattr)
  File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1574, in _check_xattrs
    self._check_xattrs_str(str, *args)
  File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1543, in _check_xattrs_str
    self.assertEqual(listxattr(fn), [])
AssertionError: Lists differ: ['security.selinux'] != []

First list contains 1 additional elements.
First extra element 0:
security.selinux

- ['security.selinux']
+ []

======================================================================
FAIL: test_simple (test.test_os.ExtendedAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1580, in test_simple
    os.listxattr)
  File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1574, in _check_xattrs
    self._check_xattrs_str(str, *args)
  File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1543, in _check_xattrs_str
    self.assertEqual(listxattr(fn), [])
AssertionError: Lists differ: ['security.selinux'] != []

First list contains 1 additional elements.
First extra element 0:
security.selinux

- ['security.selinux']
+ []

----------
components: Extension Modules, Library (Lib)
messages: 145486
nosy: haypo
priority: normal
severity: normal
status: open
title: test_os failures on Fedora 15: listxattr() returns ['security.selinux']
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13174>
_______________________________________

From report at bugs.python.org  Fri Oct 14 00:11:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Oct 2011 22:11:02 +0000
Subject: [issue13174] test_os failures on Fedora 15: listxattr() returns
	['security.selinux']
In-Reply-To: <1318541567.35.0.652639760355.issue13174@psf.upfronthosting.co.za>
Message-ID: <1318543862.3.0.319245331735.issue13174@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch fixes test_os failures.

----------
keywords: +patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file23399/xattr_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13174>
_______________________________________

From report at bugs.python.org  Fri Oct 14 00:47:02 2011
From: report at bugs.python.org (Paul Moore)
Date: Thu, 13 Oct 2011 22:47:02 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
Message-ID: <1318546022.2.0.0477576720396.issue13175@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

On Windows, packaging seems to create RECORD files with an additional CR at the end of the line. (So the line end is CR CR LF). This does not seem to be consistent, but it is likely to be because a file is being opened in text mode rather than binary.

I am trying to develop a reproducible test case, but am having difficulty at the moment. I have opened this bug in any case as a place holder and in case someone else can reproduce the issue.

----------
assignee: tarek
components: Distutils2
messages: 145488
nosy: alexis, eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: packaging uses wrong line endings in RECORD files on Windows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Fri Oct 14 01:38:13 2011
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 13 Oct 2011 23:38:13 +0000
Subject: [issue11880] add a {dist-info} category to distutils2
In-Reply-To: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za>
Message-ID: <1318549093.41.0.740134435828.issue11880@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berkerpeksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11880>
_______________________________________

From report at bugs.python.org  Fri Oct 14 02:18:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Oct 2011 00:18:21 +0000
Subject: [issue13088] Add Py_hexdigits constant: use one unique constant to
	format a digit to hexadecimal
In-Reply-To: <1317511977.11.0.738521421258.issue13088@psf.upfronthosting.co.za>
Message-ID: <E1REVTd-0004b0-78@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d76338eacf7c by Victor Stinner in branch 'default':
Issue #13088: Add shared Py_hexdigits constant to format a number into base 16
http://hg.python.org/cpython/rev/d76338eacf7c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13088>
_______________________________________

From report at bugs.python.org  Fri Oct 14 02:38:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Oct 2011 00:38:23 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <E1REVn3-00061t-8j@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e3d9c5e690fc by Victor Stinner in branch '3.2':
Issue #10653: On Windows, use strftime() instead of wcsftime() because
http://hg.python.org/cpython/rev/e3d9c5e690fc

New changeset 79e60977fc04 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #10653: On Windows, use strftime() instead of wcsftime()
http://hg.python.org/cpython/rev/79e60977fc04

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Fri Oct 14 02:38:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Oct 2011 00:38:47 +0000
Subject: [issue13029] test_strptime fails on Windows 7 french
In-Reply-To: <1316725744.77.0.0655730808912.issue13029@psf.upfronthosting.co.za>
Message-ID: <1318552727.48.0.375560683522.issue13029@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Yes, this issue is a duplicate of #10653.

----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13029>
_______________________________________

From report at bugs.python.org  Fri Oct 14 02:41:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Oct 2011 00:41:20 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1318552880.13.0.771324686552.issue10653@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It's a bug in the Windows API: I used the workaround suggested by Hirokazu Yamamoto. Thanks Hirokazu!

Python 2.7 doesn't use wcsftime() and so it is not affected by this issue.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Fri Oct 14 02:41:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Oct 2011 00:41:32 +0000
Subject: [issue13029] test_strptime fails on Windows 7 french
In-Reply-To: <1316725744.77.0.0655730808912.issue13029@psf.upfronthosting.co.za>
Message-ID: <1318552892.89.0.0492423331853.issue13029@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13029>
_______________________________________

From report at bugs.python.org  Fri Oct 14 03:04:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Oct 2011 01:04:26 +0000
Subject: [issue13025] mimetypes should read the rule file using UTF-8,
	not the locale encoding
In-Reply-To: <1316560027.85.0.800562759244.issue13025@psf.upfronthosting.co.za>
Message-ID: <E1REWCG-0007ye-49@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8d8ab3e04363 by Victor Stinner in branch '3.2':
Issue #13025: mimetypes is now reading MIME types using the UTF-8 encoding,
http://hg.python.org/cpython/rev/8d8ab3e04363

New changeset 2c223d686feb by Victor Stinner in branch 'default':
(Merge 3.2) Issue #13025: mimetypes is now reading MIME types using the UTF-8
http://hg.python.org/cpython/rev/2c223d686feb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13025>
_______________________________________

From report at bugs.python.org  Fri Oct 14 03:04:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Oct 2011 01:04:47 +0000
Subject: [issue13025] mimetypes should read the rule file using UTF-8,
	not the locale encoding
In-Reply-To: <1316560027.85.0.800562759244.issue13025@psf.upfronthosting.co.za>
Message-ID: <1318554287.24.0.659517414933.issue13025@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Please use the file from Fedora in a test.

Done.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13025>
_______________________________________

From report at bugs.python.org  Fri Oct 14 03:09:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Oct 2011 01:09:43 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1313857395.98.0.181903928708.issue12795@psf.upfronthosting.co.za>
Message-ID: <1318554583.16.0.307072438042.issue12795@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

While working on #12326, it's realized that many modules and applications rely on sys.platform. Change this value should be decided for each platform because it breaks backward compatibility. Linux was a special case and now I don't think that we should drop the major version from sys.platform on all platforms. Let's close this issue as "wont fix".

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Fri Oct 14 03:12:28 2011
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 14 Oct 2011 01:12:28 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1318554748.3.0.442779573066.issue7833@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

New version of the patch with the small tweaks requested plus a NEWS entry.

----------
Added file: http://bugs.python.org/file23400/bug-7833-tweaks-plus-news.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Fri Oct 14 03:28:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Oct 2011 01:28:35 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1318555715.45.0.571457855494.issue12568@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> There might be something you can steal from  ...

I don't think that Python should reinvent the wheel. We should just reuse wcswidth().

Here is a simple patch exposing wcswidth() function as locale.width().

Example:

>>> import locale
>>> text = '\u3042\u3044\u3046\u3048\u304a'
>>> len(text)
5
>>> locale.width(text)
10
>>> locale.width(' ')
1
>>> locale.width('\U0010abcd')
1
>>> locale.width('\uDC80')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
locale.Error: the string is not printable
>>> locale.width('\U0010FFFF')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
locale.Error: the string is not printable

I don't think that we need locale.width() on Windows because its console has already bigger issues with Unicode: see issue #1602. If you want to display correctly non-ASCII characters on Windows, just avoid the Windows console and use a graphical widget.

----------
keywords: +patch
Added file: http://bugs.python.org/file23401/locale_width.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Fri Oct 14 03:32:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Oct 2011 01:32:57 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1318555977.71.0.0605434329374.issue12568@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, unicode_width.patch of issue #2382 implements the width on Windows using:

WideCharToMultiByte(CP_ACP, 0, buf, len, NULL, 0, NULL, NULL);

It computes the length of byte string encoded to the ANSI code page. I don't know if it can be seen as the "width" of a character string in the console...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Fri Oct 14 10:05:08 2011
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 14 Oct 2011 08:05:08 +0000
Subject: [issue13176] Broken link in bugs.rst
Message-ID: <1318579508.22.0.235286137503.issue13176@psf.upfronthosting.co.za>


New submission from Berker Peksag <berker.peksag at gmail.com>:

http://www.python.org/dev/workflow/ is missing in 3.2 documentation.

See: http://docs.python.org/py3k/bugs.html

It works with latest version of the documentation: http://docs.python.org/dev/bugs.html

----------
assignee: docs at python
components: Documentation
files: broken_link_v1.patch
keywords: patch
messages: 145499
nosy: berkerpeksag, docs at python
priority: normal
severity: normal
status: open
title: Broken link in bugs.rst
versions: Python 3.2
Added file: http://bugs.python.org/file23402/broken_link_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13176>
_______________________________________

From report at bugs.python.org  Fri Oct 14 10:46:02 2011
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 14 Oct 2011 08:46:02 +0000
Subject: [issue11880] add a {dist-info} category to distutils2
In-Reply-To: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za>
Message-ID: <1318581962.1.0.645947091905.issue11880@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I'd like to work on this issue. What is the correct location of the Distutils2 project?

I have found these links:
http://hg.python.org/distutils2/file/98e0d3c53a2f/distutils2/
http://hg.python.org/cpython/file/2c223d686feb/Lib/packaging

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11880>
_______________________________________

From report at bugs.python.org  Fri Oct 14 11:13:47 2011
From: report at bugs.python.org (Alexander Steppke)
Date: Fri, 14 Oct 2011 09:13:47 +0000
Subject: [issue13171] Bug in tempfile module
In-Reply-To: <1318531210.93.0.392401137226.issue13171@psf.upfronthosting.co.za>
Message-ID: <1318583627.87.0.573294170679.issue13171@psf.upfronthosting.co.za>


Alexander Steppke <asteppke at gmail.com> added the comment:

Hi David,

I followed your suggestion and tried to reproduce the problem without the tempfile module. It turns out that is indeed an underlying issue. I am not sure what the root cause is but now this is even a bigger problem: read() returns information from some file/memory that it was never intended to access. 

The session looks similar to the tempfile session:

>>> tmp = open('tmp', 'w+t')
>>> tmp.read()
''
>>> tmp.write('test')
>>> tmp.read()
'hp\'\x02\xe4\xb9>7\x80\x88\x81\x02\x01\x00\x00\x00\x00\x00\x00\x00\x12\x00\x00\
x00\xe86(\x02p\x11\x8d\x02\x01\x00\x00\x00@\xfd)\x02\xe7Y\x9aN\x01\x00\x00\x00\x
00\x00\x00\x00\x14\x00\x00\x00\x087(\x02\x00\x00\x00\x00\xe9Y\x0b\xa2\x00\x93+\x
02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x9b,\x02\x02\x00\x00\x00\xe06(\x02\xc0W5\

At the moment the bug could only be reproduced using CPython 2.7.1 on Windows XP and Windows 7. 

Alexander

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13171>
_______________________________________

From report at bugs.python.org  Fri Oct 14 11:15:11 2011
From: report at bugs.python.org (Alexander Steppke)
Date: Fri, 14 Oct 2011 09:15:11 +0000
Subject: [issue13171] Bug in file.read(), can access unknown data.
In-Reply-To: <1318531210.93.0.392401137226.issue13171@psf.upfronthosting.co.za>
Message-ID: <1318583711.22.0.616050409036.issue13171@psf.upfronthosting.co.za>


Changes by Alexander Steppke <asteppke at gmail.com>:


----------
components: +IO
title: Bug in tempfile module -> Bug in file.read(), can access unknown data.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13171>
_______________________________________

From report at bugs.python.org  Fri Oct 14 11:20:45 2011
From: report at bugs.python.org (Alexander Steppke)
Date: Fri, 14 Oct 2011 09:20:45 +0000
Subject: [issue13171] Bug in file.read(), can access unknown data.
In-Reply-To: <1318531210.93.0.392401137226.issue13171@psf.upfronthosting.co.za>
Message-ID: <1318584045.08.0.756417869518.issue13171@psf.upfronthosting.co.za>


Alexander Steppke <asteppke at gmail.com> added the comment:

Additionally after calling tmp.close() the file 'tmp' contains the string 'test', which is followed by about 4kB of binary data similar to the previous output of tmp.read().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13171>
_______________________________________

From report at bugs.python.org  Fri Oct 14 11:30:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Oct 2011 09:30:09 +0000
Subject: [issue13171] Bug in file.read(), can access unknown data.
In-Reply-To: <1318531210.93.0.392401137226.issue13171@psf.upfronthosting.co.za>
Message-ID: <1318584609.45.0.471310577291.issue13171@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13171>
_______________________________________

From report at bugs.python.org  Fri Oct 14 12:54:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Oct 2011 10:54:47 +0000
Subject: [issue13158] tarfile.TarFile.getmembers misses some entries
In-Reply-To: <1318424072.71.0.575626132028.issue13158@psf.upfronthosting.co.za>
Message-ID: <E1REfPZ-0001jK-Kz@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 341008eab87d by Lars Gust?bel in branch '3.2':
Issue #13158: Fix decoding and encoding of base-256 number fields in tarfile.
http://hg.python.org/cpython/rev/341008eab87d

New changeset 158430b2b552 by Lars Gust?bel in branch 'default':
Merge with 3.2: Issue #13158: Fix decoding and encoding of base-256 number fields in tarfile.
http://hg.python.org/cpython/rev/158430b2b552

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13158>
_______________________________________

From report at bugs.python.org  Fri Oct 14 12:58:22 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 14 Oct 2011 10:58:22 +0000
Subject: [issue13158] tarfile.TarFile.getmembers misses some entries
In-Reply-To: <1318424072.71.0.575626132028.issue13158@psf.upfronthosting.co.za>
Message-ID: <1318589902.71.0.597066053031.issue13158@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Thanks for the report. There was a problem decoding a special and rare kind of header field in the archive. The format of the archive is of very bad quality BTW ;-)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13158>
_______________________________________

From report at bugs.python.org  Fri Oct 14 13:05:31 2011
From: report at bugs.python.org (Sebastien Binet)
Date: Fri, 14 Oct 2011 11:05:31 +0000
Subject: [issue13158] tarfile.TarFile.getmembers misses some entries
In-Reply-To: <1318424072.71.0.575626132028.issue13158@psf.upfronthosting.co.za>
Message-ID: <1318590331.02.0.0685105460303.issue13158@psf.upfronthosting.co.za>


Sebastien Binet <binet at cern.ch> added the comment:

thanks!

> The format of the archive is of very bad quality BTW ;-)
well, that's C++ :P

-s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13158>
_______________________________________

From report at bugs.python.org  Fri Oct 14 13:07:28 2011
From: report at bugs.python.org (Maurice de Rooij)
Date: Fri, 14 Oct 2011 11:07:28 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1318590448.37.0.0633346195508.issue13169@psf.upfronthosting.co.za>


Maurice de Rooij <mauder at gmail.com> added the comment:

So if I understand correctly, the maximum of 65535 repetitions is by design?

Have tried a workaround by repeating the repetitions by placing it inside a capturing group, which is perfectly legal with Perl regular expressions:

$mystring = "test";
if($mystring =~ m/^(.{0,32766}){0,3}test/s) { print "Yes\n"; }
(32766 being the max repetitions in Perl)

Unfortunately, in Python this does not work and raises a "nothing to repeat" sre_constants error:
re.search('(?s)\A(.{0,65535}){0,3}test', 'test')

This, however works, which yields 65536 repetitions of DOTALL:
re.search('(?s)\A.{0,65535}.{0,1}test', 'test')

In the end this solves my problem sort or less, but requires extra logic in my script and complicates stuff unnecessary.

A suggestion might be to make repetitions of repeats possible?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Fri Oct 14 13:37:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Oct 2011 11:37:13 +0000
Subject: [issue13171] Bug in file.read(), can access unknown data.
In-Reply-To: <1318531210.93.0.392401137226.issue13171@psf.upfronthosting.co.za>
Message-ID: <1318592233.13.0.257944386627.issue13171@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is a duplicate of the issue #1394612 which has been closed as invalid. Read the following message:

http://bugs.python.org/issue1394612#msg27200

I suppose that Python 3 is not affected by this issue because it doesn't use fread/fwrite anymore, but directly read/write (the low level, unbuffered, API).

It looks like Python cannot do anything for this issue, except documenting this surprising behaviour. Would you like to write a patch for the documentation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13171>
_______________________________________

From report at bugs.python.org  Fri Oct 14 13:59:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Oct 2011 11:59:26 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1295450896.02.0.86964827296.issue10945@psf.upfronthosting.co.za>
Message-ID: <1318593566.18.0.828166300055.issue10945@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It is not code under the users? control (i.e. setup.py)
> that uses MBCS, but the bdist_wininst command itself.

bdist_command append configuration data to a wininst-xxx.exe binary. Where does this file come from? Can we modify wininst-xxx.exe binaries?


If we can modify the binaries, we can change the format to store the configuration data as UTF-8 instead of the ANSI code page.

It's surprising and "unsafe" (not portable) to use the ANSI code page for an installer: if you build your installer on a french setup (ANSI=cp1252), the configuration was be interpreted incorrectly on a japanese setup (ANSI=cp932). Example:

>>> 'H? ho'.encode('cp1252').decode('cp932')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'cp932' codec can't decode bytes in position 1-2: illegal multibyte sequence

So if the configuration data (package metadata) contains non-ASCII characters, you will not be able to use your installer on a computer using a different ANSI code page than the code page of the computer used to build the installer... In the best case, you will just get mojibake.

If we cannot modify wininst-xx.exe, an alternative to be able to generate installers on non-Windows platforms is to use the most common ANSI code page (cp1252?), or maybe ASCII.

Use the ASCII encoding is the safest solution because you will be able to use your installer on all Windows setup (all ANSI code pages are compatible with ASCII), but you will not be able to generate an installer if the package metadata contains at least one non-ASCII character...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Fri Oct 14 14:10:23 2011
From: report at bugs.python.org (Corey O'Brien)
Date: Fri, 14 Oct 2011 12:10:23 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1318594223.71.0.556455810485.issue4431@psf.upfronthosting.co.za>


Corey O'Brien <coreypobrien at gmail.com> added the comment:

Building py2exe with VS2010 I had this same issue and the /MANIFEST fix mentioned here fixed the problem.

I also think that this issue should be re-opened.

----------
nosy: +coreypobrien

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Fri Oct 14 14:11:44 2011
From: report at bugs.python.org (=?utf-8?b?VsOtY3RvciBUZXJyw7Nu?=)
Date: Fri, 14 Oct 2011 12:11:44 +0000
Subject: [issue13163] `port` and `host` are confused in `_get_socket
In-Reply-To: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za>
Message-ID: <1318594304.8.0.281564826074.issue13163@psf.upfronthosting.co.za>


Changes by V?ctor Terr?n <quintanar at gmail.com>:


Removed file: http://bugs.python.org/file23397/smtplib.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13163>
_______________________________________

From report at bugs.python.org  Fri Oct 14 14:19:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Oct 2011 12:19:11 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
Message-ID: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The attached patch changes lru_cache to use if/else instead of try/except.
This has 2 effects:
1) it avoids chained exceptions and makes the error messages clearer;
2) it probably makes lru_cache a bit faster since building and catching exceptions is expensive. It also gets rid of the KeyError=KeyError optimization/hack;

For a couple of examples of 1) see #12749 (msg142059, msg142063), or #13169 (msg145469).  See also related issue #6210.

----------
assignee: rhettinger
files: issue13177.diff
keywords: needs review, patch
messages: 145511
nosy: ezio.melotti, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid chained exceptions in lru_cache
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23403/issue13177.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Fri Oct 14 14:23:53 2011
From: report at bugs.python.org (=?utf-8?b?VsOtY3RvciBUZXJyw7Nu?=)
Date: Fri, 14 Oct 2011 12:23:53 +0000
Subject: [issue13163] `port` and `host` are confused in `_get_socket
In-Reply-To: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za>
Message-ID: <1318595033.93.0.682183717383.issue13163@psf.upfronthosting.co.za>


V?ctor Terr?n <quintanar at gmail.com> added the comment:

Patch updated. It is now a two-line patch. How impressive :-)
Anyway, I have verified that the entire test suite runs without failure.
Should Misc/NEWS be updated for such a trivial modification?

----------
Added file: http://bugs.python.org/file23404/smtplib.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13163>
_______________________________________

From report at bugs.python.org  Fri Oct 14 14:37:30 2011
From: report at bugs.python.org (Alexander Steppke)
Date: Fri, 14 Oct 2011 12:37:30 +0000
Subject: [issue13171] Bug in file.read(), can access unknown data.
In-Reply-To: <1318531210.93.0.392401137226.issue13171@psf.upfronthosting.co.za>
Message-ID: <1318595850.54.0.168885134496.issue13171@psf.upfronthosting.co.za>


Alexander Steppke <asteppke at gmail.com> added the comment:

Thank you for the update Victor. It seems to me that this is exactly the same issue.

At the moment the current documentation says (http://docs.python.org/library/stdtypes.html#bltin-file-objects):

"Note: This function is simply a wrapper for the underlying fread() C function, and will behave the same in corner cases, such as whether the EOF value is cached."

This is a hint to the current behavior but I would not expect from this that file.read() can return any kind of data, if used directly after file.write(). Maybe one could include a link or a snippet of the C standard which states that one shall not do this:

"When a file is opened with update mode ('+' as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an
intervening call to a file positioning function, unless the input operation encounters end-of-file." 
 
(from http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf, page 272)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13171>
_______________________________________

From report at bugs.python.org  Fri Oct 14 15:27:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Oct 2011 13:27:22 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
In-Reply-To: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>
Message-ID: <1318598842.26.0.635257036215.issue13177@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's an example (copied from msg142063) of what the traceback is without the patch:
>>> from functools import lru_cache
>>> @lru_cache()
... def func(arg): raise ValueError()
... 
>>> func(3)
Traceback (most recent call last):
  File "/home/wolf/dev/py/3.2/Lib/functools.py", line 176, in wrapper
    result = cache[key]
KeyError: (3,)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/wolf/dev/py/3.2/Lib/functools.py", line 180, in wrapper
    result = user_function(*args, **kwds)
  File "<stdin>", line 2, in func
ValueError

The patch gets rid of the first traceback (the one before "During handling...").
I should also mention that my second point might not be valid if the cache hits are mostly successful.  I haven't done any specific benchmark, and I don't know how fast is 'key in dict' compared to raising an exception.  If it's e.g. 10 times faster, it should make lru_cache faster when the hits:miss ratio is lower than 10:1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Fri Oct 14 15:41:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 13:41:34 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1318599694.13.0.335815806262.issue12386@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have a test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Fri Oct 14 16:00:40 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Oct 2011 14:00:40 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
In-Reply-To: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>
Message-ID: <1318600840.5.0.71026498354.issue13177@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This changes behavior so that hash() gets called twice for the key tuple, resulting in decreased performance.

In an earlier version of the lru_cache before the "with lock" was introduced, the try/except form was more atomic.  It also worked well with dict subclasses that use __missing__ (which is bypassed with the LBYL style of lookup).

I'll look at this more shortly -- thanks for the links to the other tracker items.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Fri Oct 14 16:03:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Oct 2011 14:03:01 +0000
Subject: [issue5252] 2to3 should detect and delete import of removed statvfs
	module
In-Reply-To: <1234549626.49.0.319241033357.issue5252@psf.upfronthosting.co.za>
Message-ID: <1318600981.59.0.980099803304.issue5252@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Benjamin, you seem to have rejected this feature request. Close it?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5252>
_______________________________________

From report at bugs.python.org  Fri Oct 14 16:25:35 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Oct 2011 14:25:35 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
In-Reply-To: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>
Message-ID: <1318602335.37.0.979736962902.issue13177@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Another issue is that I want to keep the related accesses to the OrderedDict inside the "with lock" in order to avoid a race condition between the testing-for-membership step and the retrieve-the-cached-value step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Fri Oct 14 16:26:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 14:26:05 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318602365.19.0.708182429039.issue12602@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Attached path adds these links:
> Missing incoming:
> - from "Invoking the Interpreter" in the tutorial
> - direct link from runpy.run_module to -m switch

> Missing outgoing:
> - direct link from <script> to runpy.run_path

I couldn?t add this one:
> - direct link from runpy.run_path to <script>
I tried adding a standard reST link target (.. _using-on-script:) but that didn?t seem to work with the describe item.  I added a link to the nearest heading instead, but maybe it is after all redundant: the seealso section of library/runpy already points to using/cmdline.

----------
keywords: +patch
Added file: http://bugs.python.org/file23405/using-links.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Fri Oct 14 16:30:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 14:30:08 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318602608.07.0.262513463295.issue12602@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Terry]
> It may suggest a meta-issue though - perhaps 'Documenting Python'
> should grow a devguide-style description of the Docs layout in source
> control

I would just describe the layout of the Doc subtree in the same devguide page.  Care to open another bug for that?

> If we consistently applied the "italicize non-literal symbolic parameter names"
> rule to command line examples, we would italicize 'command', 'module-name',
> 'script', and 'args' in
> 
> python [-BdEiOQsStuUvVWxX3?] [-c command | -m module-name | script | - ] [args]
> 
> just like in function signatures. I actually would like that as it would
> similarly diffentiate them from the literal constants meant to be entered as
> written. Has that ever been discussed by the doc group?

Not that I recall.  Currently the ?python [-Bd etc.]? line is currently a code block, and as such cannot gain inline markup (:file:), but this is not insurmountable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Fri Oct 14 16:31:32 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Oct 2011 14:31:32 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
In-Reply-To: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>
Message-ID: <1318602692.63.0.65428014746.issue13177@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

One possibility is to move the call to user_function() outside of the KeyError exception handler so that user exceptions won't be chained:

def wrapper(*args, **kwds):
    nonlocal hits, misses
    key = args
    if kwds:
        key += kwd_mark + tuple(sorted(kwds.items()))
    try:
        with lock:
            result = cache[key]
            cache_renew(key)        # record recent use of this key
            hits += 1
            return result
    except KeyError:
        pass
    result = user_function(*args, **kwds)
    with lock:
        cache[key] = result     # record recent use of this key
        misses += 1
        if len(cache) > maxsize:
            cache_popitem(0)    # purge least recently used cache entry
    return result

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Fri Oct 14 16:52:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 14:52:55 +0000
Subject: [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1318603975.08.0.876694820064.issue12602@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, I?ve done nothing about #1739468 because I don?t see why you wanted to add a link.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Fri Oct 14 16:56:59 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 14 Oct 2011 14:56:59 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1318604219.18.0.9022990154.issue12568@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the WideCharToMultibyte approach is just incorrect.

I'm -1 on using wcswidth, though. We already have unicodedata.east_asian_width, which implements http://unicode.org/reports/tr11/ 
The outcomes of this function are these:
- F: full-width, width 2, compatibility character for a narrow char
- H: half-width, width 1, compatibility character for a narrow char
- W: wide, width 2
- Na: narrow, width 1
- A: ambiguous; width 2 in Asian context, width 1 in non-Asian context
- N: neutral; not used in Asian text, so has no width. Practically, width can be considered as 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Fri Oct 14 16:57:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Oct 2011 14:57:12 +0000
Subject: [issue13114] check -r fails with non-ASCII unicode long_description
In-Reply-To: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za>
Message-ID: <E1REjCA-0008Mt-Ej@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d5fb646e7ce1 by ?ric Araujo in branch 'default':
Add tests for Unicode handling in packaging? check and register (#13114)
http://hg.python.org/cpython/rev/d5fb646e7ce1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13114>
_______________________________________

From report at bugs.python.org  Fri Oct 14 16:57:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Oct 2011 14:57:12 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <E1REjCA-0008Mt-Ec@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 866d098367c1 by ?ric Araujo in branch '3.2':
Increase test coverage for distutils.filelist (#11751).
http://hg.python.org/cpython/rev/866d098367c1

New changeset ba894d8a2a57 by ?ric Araujo in branch 'default':
Merge #11751 from 3.2
http://hg.python.org/cpython/rev/ba894d8a2a57

New changeset a30d4864a8e4 by ?ric Araujo in branch 'default':
Increase test coverage for packaging.manifest (#11751).
http://hg.python.org/cpython/rev/a30d4864a8e4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:01:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:01:23 +0000
Subject: [issue13178] Need tests for Unicode handling in install_distinfo and
	install_data
Message-ID: <1318604483.39.0.256027567702.issue13178@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Currently, packaging code opens dist-info files (RECORD, RESOURCES) for writing without giving an explicit encoding.  We need to add tests and probably to explicitly specify UTF-8 when writing an reading.

----------
assignee: tarek
components: Distutils2
keywords: easy
messages: 145526
nosy: alexis, eric.araujo, haypo, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Need tests for Unicode handling in install_distinfo and install_data
versions: 3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13178>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:06:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Oct 2011 15:06:10 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <E1REjKq-0000lu-Pm@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1f3459b08298 by ?ric Araujo in branch 'default':
Fix writing of the RESOURCES file by packaging (#12386)
http://hg.python.org/cpython/rev/1f3459b08298

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:10:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:10:44 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1318605044.78.0.683557435071.issue12386@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve reproduced the bug and fixed it by opening in text mode, following all other calls to open in the same file.  This should now work for ASCII paths and non-ASCII paths that use the same encoding as open?s default, but it?ll probably break with non-ASCII paths under a C locale, so I?ve opened #13178.

----------
nosy: +pmoore
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:15:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:15:27 +0000
Subject: [issue13157] Build Python outside the source directory
In-Reply-To: <1318421167.12.0.301144955548.issue13157@psf.upfronthosting.co.za>
Message-ID: <1318605327.7.0.780761900347.issue13157@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Building outside of the source directory was supported, if the source directory was clean.  In practice, the source directory could be unclean as long as a few files were not there (Parser/*.o, Modules/_testembed), so it was quite annoying.  If the patch allows people to build inside the source directory and in other directories without cleaning, I?m +1!

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13157>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:20:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:20:16 +0000
Subject: [issue13172] pysetup run --list-commands fails with a traceback
In-Reply-To: <1318531671.43.0.795221927422.issue13172@psf.upfronthosting.co.za>
Message-ID: <1318605616.25.0.375702609448.issue13172@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you tell me if this works:

>>> import _msi
>>> from packaging.command.bdist_msi import bdist_msi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13172>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:21:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:21:42 +0000
Subject: [issue13173] Default values for string.Template
In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>
Message-ID: <1318605702.59.0.584855673111.issue13173@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your interest in Python.  Can you repost your code as a diff?  (See the devguide for more info)

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13173>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:23:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:23:29 +0000
Subject: [issue13174] test_os failures on Fedora 15: listxattr() returns
	['security.selinux']
In-Reply-To: <1318541567.35.0.652639760355.issue13174@psf.upfronthosting.co.za>
Message-ID: <1318605809.14.0.949379990186.issue13174@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good, modulo one thing: the ?xattr? name is confusing, I?d like it better if it was found_xattr or expected_xattr or something clearer.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13174>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:27:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:27:31 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1318546022.2.0.0477576720396.issue13175@psf.upfronthosting.co.za>
Message-ID: <1318606051.68.0.877908758947.issue13175@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

packaging.util creates a RECORD file with OS-specific line endings and csv.writerow; packaging.command.install_distinfo uses LF everywhere and csv.writerow.  I?m not sure this is related to binary vs. text I/O; maybe it?s some other code like the RESOURCES system that?s giving lines with endings to install_distinfo, which then adds CRLF.  Do you have a RECORD file to upload for inspection?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:31:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:31:02 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1318606262.22.0.000180422039657.issue7833@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.

Style nit: I don?t put backslashes at end-of-lines in parens (in one re.compile call you have that).  Also, I use -- where I can?t use ?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:33:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:33:40 +0000
Subject: [issue13176] Broken link in bugs.rst
In-Reply-To: <1318579508.22.0.235286137503.issue13176@psf.upfronthosting.co.za>
Message-ID: <1318606420.59.0.50036179056.issue13176@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13176>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:33:44 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 14 Oct 2011 15:33:44 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1318604219.18.0.9022990154.issue12568@psf.upfronthosting.co.za>
Message-ID: <634.1318606411@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

> Martin v. L?wis <martin at v.loewis.de> added the comment:

> I think the WideCharToMultibyte approach is just incorrect.

> I'm -1 on using wcswidth, though. 

Like you, I too seriously question using wcswidth() for this at all:

    The wcswidth() function either shall return 0 (if pwcs points to a
    null wide-character code), or return the number of column positions
    to be occupied by the wide-character string pointed to by pwcs, or
    return -1 (if any of the first n wide-character codes in the wide-
    character string pointed to by pwcs is not a printable wide-
    character code).

I would be willing to bet (a small amount of) money it does not correctly
inplmented Unicode print widths, even though one would certainly *think* it
does according to this:

     The wcswidth() function determines the number of column positions
     required for the first n characters of pwcs, or until a null wide
     character (L'\0') is encountered.

There are a bunch of "interesting" cases I would want it tested against.

> We already have unicodedata.east_asian_width, which implements http://unicode.org/reports/tr11/ 

> The outcomes of this function are these:
> - F: full-width, width 2, compatibility character for a narrow char
> - H: half-width, width 1, compatibility character for a narrow char
> - W: wide, width 2
> - Na: narrow, width 1
> - A: ambiguous; width 2 in Asian context, width 1 in non-Asian context
> - N: neutral; not used in Asian text, so has no width. Practically, width can be considered as 1

Um, East_Asian_Width=Ambiguous (EA=A) isn't actually good enough for this.
And EA=N cannot be consider 1, either.

For example, some of the Marks are EA=A and some are EA=N, yet how may
print columns they take varies.  It is usually 0, but can be 1 at the start
of the file/string or immediately after a linebreak sequence.  Then there
are things like the variation selectors which are never anything.

Now consider the many \pC code points, like 

    U+0009  CHARACTER TABULATION
    U+00AD  SOFT HYPHEN 
    U+200C  ZERO WIDTH NON-JOINER
    U+FEFF  ZERO WIDTH NO-BREAK SPACE
    U+2062  INVISIBLE TIMES

A TAB is its own problem but SHY we know is only width=1 immediately
before a linebreak or EOF, and ZWNJ and ZWNBSP are both certainly
width=0.  So are the INVISIBLE * code points.

Context:

Imagine you're trying to format a string so that it takes up exactly 20
columns: you need to know how many spaces to pad it with based on the
print width.  That is what the #12568 is needing
to do, and you have to do much more than East Asian Width properties.

I really do think that what #12568 is asking for is to have the equivalent
of the Perl Unicode::GCString's columns() method, and that you aren't going
to be able to handle text alignment of Unicode with anything that is much
less of that.  After all, #12568's title is "Add functions to get the width
in columns of a character".  I would very much like to compare what
columns() thinks compared with what wcswidth() thinks.  I bet wcswidth() is
very simple-minded at best.

I may of course be wrong.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:38:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Oct 2011 15:38:50 +0000
Subject: [issue13176] Broken link in bugs.rst
In-Reply-To: <1318579508.22.0.235286137503.issue13176@psf.upfronthosting.co.za>
Message-ID: <E1REjqS-0003d4-GS@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9ef20fbd340f by ?ric Araujo in branch '3.2':
Update dead references from py.org/dev/faq to the devguide (#13176)
http://hg.python.org/cpython/rev/9ef20fbd340f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13176>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:47:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:47:04 +0000
Subject: [issue11880] add a {dist-info} category to distutils2
In-Reply-To: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za>
Message-ID: <1318607224.48.0.623698307153.issue11880@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Berker!  Welcome to Python core development.  Tips and guidelines for working on distutils are found here: http://wiki.python.org/moin/Distutils/Contributing

It?s best if you work on packaging from the cpython repo, but you can also use the distutils2 repo it that?s more convenient.

Feel free to ask any question!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11880>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:47:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:47:56 +0000
Subject: [issue13176] Broken link in bugs.rst
In-Reply-To: <1318579508.22.0.235286137503.issue13176@psf.upfronthosting.co.za>
Message-ID: <1318607276.95.0.724025303042.issue13176@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13176>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:52:28 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 14 Oct 2011 15:52:28 +0000
Subject: [issue13179] IDLE uses common tkinter variables across all editor
	windows
Message-ID: <1318607548.28.0.391563618977.issue13179@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

IDLE's EditorWindow.py relies on using FileList.py's "vars" dictionary to store Tkinter variables instead of using its own. As a consequence, 
toggling a checked menu item in one editor window toggles the menu item in ALL editor windows.

To reproduce this error, open two editor windows with Code Context initially disabled. Enable Code Context in one window and then click "Options" in the other. You'll see Code Context checked when it shouldn't be.

Attached is a patch to fix this problem. It causes EditorWindow to have its own dictionary for handling these Tkinter variables instead of using the flist's "vars". The comment in FileList.py suggests that this design is a relic from an old version of IDLE, since getrawvar is no longer a function.

    self.vars = {} # For EditorWindow.getrawvar (shared Tcl variables)

----------
components: IDLE
files: patch_EditorWindow.diff
keywords: patch
messages: 145539
nosy: serwy
priority: normal
severity: normal
status: open
title: IDLE uses common tkinter variables across all editor windows
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file23406/patch_EditorWindow.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13179>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:53:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:53:42 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1295450896.02.0.86964827296.issue10945@psf.upfronthosting.co.za>
Message-ID: <1318607622.56.0.190959131654.issue10945@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> It is not code under the users? control (i.e. setup.py)
>> that uses MBCS, but the bdist_wininst command itself.
> bdist_command append configuration data to a wininst-xxx.exe binary.
Are you sure?  The string that?s encoded with mbcs comes from the get_inidata method in bdist_wininst.py; get_inidata only works with strings (either string literals or str objects (in 3.x) given as attributes of the command object or in the DistributionMetadata object).

> Where does this file come from? Can we modify wininst-xxx.exe binaries?
If needed, we can: the code lives in PC/bdist_wininst.

> Use the ASCII encoding is the safest solution
I don?t think so.  Distutils supports author='?ric', so bdist_wininst should too :)

----------
nosy: +loewis
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:55:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Oct 2011 15:55:20 +0000
Subject: [issue13171] Bug in file.read(), can access unknown data.
In-Reply-To: <1318595850.54.0.168885134496.issue13171@psf.upfronthosting.co.za>
Message-ID: <4E985B63.4050008@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le 14/10/2011 14:37, Alexander Steppke a ?crit :
> "When a file is opened with update mode ('+' as the second or third character in the above list of mode argument values),

You can just say " '+' in the file mode ".

> the fflush function or to a file positioning function (fseek, fsetpos, or rewind),

You should translate these names into Python method names:
  fflush -> file.flush()
  fseek/fsetpos -> file.seek()
  rewind -> (not exposed in Python)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13171>
_______________________________________

From report at bugs.python.org  Fri Oct 14 17:55:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 15:55:58 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1318607758.71.0.788527956902.issue4431@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, mhammond
title: Distutils MSVC doesn't create manifest file (with fix) -> Distutils MSVC doesn't create manifest file
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Fri Oct 14 18:00:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 16:00:41 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318608041.77.0.540299877341.issue12405@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If one project creates a/b/thing and another project uses a/b/otherthing, then the directories would be recorded in the first project?s RECORD, but they should be removed only when both projects are removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Fri Oct 14 18:03:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 16:03:24 +0000
Subject: [issue13151] pysetup3 run bdist_wininst fails
In-Reply-To: <1318331538.35.0.635641564623.issue13151@psf.upfronthosting.co.za>
Message-ID: <1318608204.42.0.966313119461.issue13151@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +bdist_wininst depends on MBCS codec, unavailable on non-Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13151>
_______________________________________

From report at bugs.python.org  Fri Oct 14 18:04:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 16:04:07 +0000
Subject: [issue13151] pysetup3 run bdist_wininst fails
In-Reply-To: <1318331538.35.0.635641564623.issue13151@psf.upfronthosting.co.za>
Message-ID: <1318608247.93.0.667084490039.issue13151@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ll apply your hack and fix the other issues.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13151>
_______________________________________

From report at bugs.python.org  Fri Oct 14 18:06:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Oct 2011 16:06:07 +0000
Subject: [issue13176] Broken link in bugs.rst
In-Reply-To: <1318579508.22.0.235286137503.issue13176@psf.upfronthosting.co.za>
Message-ID: <E1REkGr-00069f-Hy@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ebf3f2a4c61a by ?ric Araujo in branch '2.7':
Update dead references from py.org/dev/faq to the devguide (#13176)
http://hg.python.org/cpython/rev/ebf3f2a4c61a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13176>
_______________________________________

From report at bugs.python.org  Fri Oct 14 18:11:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Oct 2011 16:11:22 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1318608682.17.0.695089273468.issue12344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, sorry I did not make a patch that could be applied on top of your repo; I intended to, but your patch did not apply cleanly, so when merging conflicts I also did other editions and then it was too late.

I hope you appreciate how I solved the issue of going twice through kwargs.items(): The code is here twice, but only one of these code paths will be followed in each call :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Fri Oct 14 18:15:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Oct 2011 16:15:40 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <E1REkQ6-0007D4-UO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 368134e10d09 by ?ric Araujo in branch '2.7':
Increase test coverage for distutils.filelist (#11751).
http://hg.python.org/cpython/rev/368134e10d09

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Fri Oct 14 18:28:25 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 14 Oct 2011 16:28:25 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1318609705.0.0.950902784764.issue13169@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The limit is an implementation detail. The pattern is compiled into codes which are then interpreted, and it just happens that the codes are (usually) 16 bits, giving a range of 0..65535, but it uses 65535 to represent no limit and doesn't warn if you actually write 65535.

There's an alternative regex implementation here:

http://pypi.python.org/pypi/regex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Fri Oct 14 18:30:23 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 14 Oct 2011 16:30:23 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1295450896.02.0.86964827296.issue10945@psf.upfronthosting.co.za>
Message-ID: <1318609823.9.0.1814972478.issue10945@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The problem is that the config file is parsed using GetPrivateProfileString, and the result is then passed to TextOut, SetDlgItemText, CreateWindow, etc. all of which are defined to accept MBCS strings. I agree that this can't work correctly in the general case.

Changing the GUI functions to operate on Unicode strings is certainly feasible and a good idea. The main challenge then is the format of the INI file. IIUC, GetPrivateProfileStringW is willing to process UTF-16 (with BOM) encoded INI files, but I never tested whether it actually does. If it does, I recommend to have the INI file encoded in UTF-16 (with BOM, using LE for safety).

In porting wininst.exe, it seems tempting to use the TEXT family of APIs. I'd advise against that, and recommend to explicitly use the *W functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Fri Oct 14 18:40:48 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 14 Oct 2011 16:40:48 +0000
Subject: [issue13039] IDLE editor: shell-like behaviour on line starting with
	">>>"
In-Reply-To: <1316816819.73.0.347712729805.issue13039@psf.upfronthosting.co.za>
Message-ID: <1318610448.61.0.27521842163.issue13039@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Here's a patch.

The smart_backspace_event code considers sys.ps1 even though it's not a PyShell instance. The "context_use_ps1" flag is already used to modify other behavior of the editor window when it is a PyShell instance, so it is appropriate to use it here as well.

----------
keywords: +patch
nosy: +serwy
Added file: http://bugs.python.org/file23407/patch13039.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13039>
_______________________________________

From report at bugs.python.org  Fri Oct 14 18:58:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Oct 2011 16:58:44 +0000
Subject: [issue13052] IDLE: replace ending with '\' causes crash
In-Reply-To: <1317177843.04.0.691154940707.issue13052@psf.upfronthosting.co.za>
Message-ID: <1318611524.08.0.239588671584.issue13052@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13052>
_______________________________________

From report at bugs.python.org  Fri Oct 14 19:21:30 2011
From: report at bugs.python.org (Bfontaine)
Date: Fri, 14 Oct 2011 17:21:30 +0000
Subject: [issue13173] Default values for string.Template
In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>
Message-ID: <1318612890.88.0.967733571712.issue13173@psf.upfronthosting.co.za>


Bfontaine <batifon at yahoo.fr> added the comment:

Here is my code as a diff

----------
keywords: +patch
Added file: http://bugs.python.org/file23408/string_template_default_values.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13173>
_______________________________________

From report at bugs.python.org  Fri Oct 14 19:32:55 2011
From: report at bugs.python.org (Paul Moore)
Date: Fri, 14 Oct 2011 17:32:55 +0000
Subject: [issue13172] pysetup run --list-commands fails with a traceback
In-Reply-To: <1318531671.43.0.795221927422.issue13172@psf.upfronthosting.co.za>
Message-ID: <1318613575.6.0.573935561105.issue13172@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

No it didn't - I had not built the _msi module when I built Python for some reason. I have built _msi now, and everything works. Sorry for the false alarm.

Arguably, the command shouldn't fail, it should simply omit the bdist_msi command from the listing. But as _msi is part of Python, the installation is broken if it isn't present so I guess that handling the issue gracefully isn't really important. (I assume the missing _msi extension isn't an issue on Unix).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13172>
_______________________________________

From report at bugs.python.org  Fri Oct 14 19:47:19 2011
From: report at bugs.python.org (Paul Moore)
Date: Fri, 14 Oct 2011 17:47:19 +0000
Subject: [issue13180] pysetup silently ignores invalid entries in setup.cfg
Message-ID: <1318614439.75.0.304667021355.issue13180@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

With a simple setup.cfg defining a distribution containing a single Python module, if you misspell the "modules" keyword (say, as "module") then pysetup does nothing without reporting the error.

This silent failure is very hard to debug, and even if pysetup is ignoring unknown items by design, it should at a minimum report ignored items and probably try to warn on common misspellings like this one.

PS D:\Data\python-sample\python> type .\setup.cfg
[metadata]
name = hello
version = 0.1
author = Paul Moore
author-email = p.f.moore at gmail.com
summary = Test Python module

[files]
module = hello
PS D:\Data\python-sample\python> pysetup run build
running build
PS D:\Data\python-sample\python> dir


    Directory: D:\Data\python-sample\python


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        13/10/2011     19:46         42 hello.py
-a---        14/10/2011     18:42        155 setup.cfg

(No build directory created!)

----------
assignee: tarek
components: Distutils2
messages: 145552
nosy: alexis, eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: pysetup silently ignores invalid entries in setup.cfg
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13180>
_______________________________________

From report at bugs.python.org  Fri Oct 14 19:54:57 2011
From: report at bugs.python.org (Paul Moore)
Date: Fri, 14 Oct 2011 17:54:57 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1318546022.2.0.0477576720396.issue13175@psf.upfronthosting.co.za>
Message-ID: <1318614897.3.0.417635772673.issue13175@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Unfortunately, no. I have been unable to get this in a reproducible form - but I have seen it a few times now. I will keep trying to reproduce.

The worst thing is that packaging fails to recognise the data in RECORD and won't uninstall the package. It would be helpful if packaging were a little more permissive in how it handles this sort of problem in RECORD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Fri Oct 14 20:11:07 2011
From: report at bugs.python.org (Paul Moore)
Date: Fri, 14 Oct 2011 18:11:07 +0000
Subject: [issue13181] pysetup install creates .pyc files but pysetup remove
	doesn't delete them
Message-ID: <1318615867.17.0.772590919076.issue13181@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

The title explains. Here is an example:

PS D:\Data\python-sample\python> pysetup install
Installing from source directory: 'D:\\Data\\python-sample\\python'
running install_dist
running build
running build_py
running install_lib
byte-compiling D:\Data\cpython\Lib\site-packages\hello.py to hello.cpython-33.pyc
running install_distinfo
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RECORD
PS D:\Data\python-sample\python> pysetup remove hello
Removing 'hello':
  D:\Data\cpython\Lib\site-packages\hello.py
  D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA
  D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER
  D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED
  D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RECORD
Proceed (y/n)? y
Success: removed 5 files and 1 dirs
PS D:\Data\python-sample> dir D:\Data\cpython\Lib\site-packages\__pycache__


    Directory: D:\Data\cpython\Lib\site-packages\__pycache__


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        14/10/2011     18:53        314 hello.cpython-33.pyc

The pyc file should have been removed. It's not critical (the pyc file gets ignored, see PEP 3147) but as pysetup created it, pysetup should remove it...

----------
assignee: tarek
components: Distutils2
messages: 145554
nosy: alexis, eric.araujo, pmoore, tarek
priority: low
severity: normal
status: open
title: pysetup install creates .pyc files but pysetup remove doesn't delete them
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13181>
_______________________________________

From report at bugs.python.org  Fri Oct 14 20:26:11 2011
From: report at bugs.python.org (Paul Moore)
Date: Fri, 14 Oct 2011 18:26:11 +0000
Subject: [issue13182] pysetup run bdist_wininst does not work (tries to use
	"install" command)
Message-ID: <1318616771.75.0.522951953738.issue13182@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

PS D:\Data\python-sample\python> pysetup run bdist_wininst
running bdist_wininst
running build
running build_py
Invalid command install
Traceback (most recent call last):
  File "D:\Data\cpython\lib\packaging\command\__init__.py", line 57, in get_command_class
    cls = _COMMANDS[name]
KeyError: 'install'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\Data\cpython\lib\packaging\run.py", line 653, in main
    return dispatcher()
  File "D:\Data\cpython\lib\packaging\run.py", line 642, in __call__
    return func(self, self.args)
  File "D:\Data\cpython\lib\packaging\run.py", line 91, in wrapper
    return f(*args, **kwargs)
  File "D:\Data\cpython\lib\packaging\run.py", line 288, in _run
    dist.run_command(cmd, dispatcher.command_options[cmd])
  File "D:\Data\cpython\lib\packaging\dist.py", line 709, in run_command
    cmd_obj.run()
  File "D:\Data\cpython\lib\packaging\command\bdist_wininst.py", line 119, in run
    reinit_subcommands=True)
  File "D:\Data\cpython\lib\packaging\command\cmd.py", line 323, in get_reinitialized_command
    command, reinit_subcommands)
  File "D:\Data\cpython\lib\packaging\dist.py", line 660, in get_reinitialized_command
    command = self.get_command_obj(command_name)
  File "D:\Data\cpython\lib\packaging\dist.py", line 583, in get_command_obj
    cls = get_command_class(command)
  File "D:\Data\cpython\lib\packaging\command\__init__.py", line 59, in get_command_class
    raise PackagingModuleError("Invalid command %s" % name)
packaging.errors.PackagingModuleError: Invalid command install

Looking at bdist_wininst.py (line 118) it is indeed trying to use an "install" command, which is not present in command\__init__.py

----------
assignee: tarek
components: Distutils2
messages: 145555
nosy: alexis, eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: pysetup run bdist_wininst does not work (tries to use "install" command)
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13182>
_______________________________________

From report at bugs.python.org  Fri Oct 14 20:54:47 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 14 Oct 2011 18:54:47 +0000
Subject: [issue13052] IDLE: replace ending with '\' causes crash
In-Reply-To: <1317177843.04.0.691154940707.issue13052@psf.upfronthosting.co.za>
Message-ID: <1318618487.62.0.753345758334.issue13052@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I see that Ezio added me to the nosy list.

Here's a patch that identifies bogus escape characters at the end of the replvar string and appends an extra \ to fix it.

----------
keywords: +patch
Added file: http://bugs.python.org/file23409/patch13052.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13052>
_______________________________________

From report at bugs.python.org  Fri Oct 14 20:56:31 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 14 Oct 2011 18:56:31 +0000
Subject: [issue13183] pdb skips frames after hitting a breakpoint and running
	step
Message-ID: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Pdb skips frames after hitting a breakpoint and running step commands
that walk back the frame stack.

Run the following two tests with the two files named foo.py and bar.py:

===   foo.py   ============================================
from bar import bar

def foo():
    bar()

def nope():
    pass

def foobar():
    foo()
    nope()

foobar()

===   bar.py   ============================================
def bar():
    print('1')

===   test_1   ============================================
$ python3 --version
Python 3.2

$ python3 -m pdb foo.py
> /path/to/foo.py(1)<module>()
-> from bar import bar
(Pdb) from bar import bar
(Pdb) break bar
Breakpoint 1 at /path/to/bar.py:1
(Pdb) continue
> /path/to/bar.py(2)bar()
-> print('1')
(Pdb) step
1
--Return--
> /path/to/bar.py(2)bar()->None
-> print('1')
(Pdb) step
--Call--
> /path/to/foo.py(6)nope()
-> def nope():
(Pdb)

===   test_2   ============================================
$ python3 -m pdb foo.py
> /path/to/foo.py(1)<module>()
-> from bar import bar
(Pdb) break nope
Breakpoint 1 at /path/to/foo.py:6
(Pdb) from bar import bar
(Pdb) break bar
Breakpoint 2 at /path/to/bar.py:1
(Pdb) continue
> /path/to/bar.py(2)bar()
-> print('1')
(Pdb) step
1
--Return--
> /path/to/bar.py(2)bar()->None
-> print('1')
(Pdb) step
--Return--
> /path/to/foo.py(4)foo()->None
-> bar()
(Pdb)

===========================================================

Note: stop_here, break_anywhere and dispatch_call are methods of the
Bdb class.

test_1 fails to stop in foo() after the second 'step' command because
the trace function is not set for all the frames being created in the
foo module, since stop_here() and break_anywhere() are both False
whenever dispatch_call() is invoked in this module. So after the
second 'step' command, trace_dispatch is not invoked by the
interpreter until a new frame is created, which happens when nope() is
called.

test_2 succeeds and stops in foo() after the second 'step' command.
After setting the dummy breakpoint 1 in the foo module in test_2,
break_anywhere() becomes True in the foo module and the trace function
is set for all the frames created in this module (with an associated
performance penalty).

The problem exists in all python versions.

The attached patch fixes this problem by restoring the trace function
on returning from a frame when the command is 'step'.

The patch includes a test case.

----------
components: Library (Lib)
files: restore_trace.patch
keywords: patch
messages: 145557
nosy: xdegaye
priority: normal
severity: normal
status: open
title: pdb skips frames after hitting a breakpoint and running step
versions: Python 3.2
Added file: http://bugs.python.org/file23410/restore_trace.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13183>
_______________________________________

From report at bugs.python.org  Fri Oct 14 20:57:13 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 14 Oct 2011 18:57:13 +0000
Subject: [issue13183] pdb skips frames after hitting a breakpoint and running
	step
In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za>
Message-ID: <1318618633.37.0.0431570715811.issue13183@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13183>
_______________________________________

From report at bugs.python.org  Fri Oct 14 21:14:15 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 14 Oct 2011 19:14:15 +0000
Subject: [issue9150] IDLE should not save trailing whitespace after strip
	trailing whitespace has been used
In-Reply-To: <1278179945.62.0.903425904075.issue9150@psf.upfronthosting.co.za>
Message-ID: <1318619655.45.0.357255301058.issue9150@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9150>
_______________________________________

From report at bugs.python.org  Fri Oct 14 21:20:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Oct 2011 19:20:27 +0000
Subject: [issue13052] IDLE: replace ending with '\' causes crash
In-Reply-To: <1317177843.04.0.691154940707.issue13052@psf.upfronthosting.co.za>
Message-ID: <1318620027.54.0.0710014329336.issue13052@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the patch.

This seems to fix the problem with the trailing \, but not the other issues.  As I mentioned in my previous message I think re.escape might be a better solution.
I also wonder if there are tests for this, and how difficult would be to add them if they are missing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13052>
_______________________________________

From report at bugs.python.org  Fri Oct 14 21:38:30 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 14 Oct 2011 19:38:30 +0000
Subject: [issue13052] IDLE: replace ending with '\' causes crash
In-Reply-To: <1317177843.04.0.691154940707.issue13052@psf.upfronthosting.co.za>
Message-ID: <1318621110.36.0.610066929384.issue13052@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I don't have the beep problem you describe under Linux using Python 3.2 (r32:88445, Mar 25 2011, 19:56:22). That may be a platform-specific bug.

Here's a patch to use re.escape instead. 

A minor side effect of using re.escape is that it is not possible to use \n itself in the replace string. It gets escaped as \\n.

----------
Added file: http://bugs.python.org/file23411/patch13052_re.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13052>
_______________________________________

From report at bugs.python.org  Fri Oct 14 22:05:14 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 14 Oct 2011 20:05:14 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
In-Reply-To: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>
Message-ID: <1318622714.39.0.261065297397.issue13177@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Could you just cancel the chained exception?

   >>> try: {}["asdf"]
   ... except KeyError:
   ...   try: raise Exception()
   ...   except Exception as x:
   ...     x.__cause__ = None
   ...     x.__context__ = None
   ...     x.__traceback__ = None
   ...     raise x
   ... 
   Traceback (most recent call last):
     File "<stdin>", line 8, in <module>
   Exception

in contrast to:

   >>> try: {}["asdf"]
   ... except KeyError:
   ...   try: raise e
   ...   except Exception as x: 
   ...     raise x
   ... 
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   KeyError: 'asdf'
   
   During handling of the above exception, another exception occurred:
   
   Traceback (most recent call last):
     File "<stdin>", line 5, in <module>
     File "<stdin>", line 3, in <module>
     File "<stdin>", line 8, in <module>
   Exception

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Fri Oct 14 22:10:42 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 14 Oct 2011 20:10:42 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1318623042.68.0.159265030123.issue11715@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

I see this requires dpkg-architecture which isn't always available. While it isn't hard to install it, it isn't very clear that this is the cause of the nis and crypt modules failing to build on a fresh install of 11.10.

What would be nice is if there were some way of determining this information without dpkg-architecture such as reading it from /etc/ld.so.conf.d/x86_64-linux-gnu.conf.

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11715>
_______________________________________

From report at bugs.python.org  Fri Oct 14 22:55:38 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 14 Oct 2011 20:55:38 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318625738.65.0.542402995914.issue12405@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> If one project creates a/b/thing and another project uses
> a/b/otherthing, then the directories would be recorded in the first
> project?s RECORD, but they should be removed only when both projects
> are removed.

I'm not sure what you mean by "using". AFAIK, each distribution's files (recorded in RECORD) would be unique to that distribution (else distros like Debian will have problems, since files are owned by one package and one package only).

I think all that is needed is as follows:

1. Record any directories that are created in RECORD, ideally bottom-up.

2. On uninstallation, remove all .pyc/.pyo files and __pycache__ directories, and remove all directories named in RECORD, unless they are non-empty (once .pyc/.pyo and __pycache__ are removed).

If you are talking about dependencies between dependencies, I still don't see what your point is. IIUC, if distA depends on distB, distA's RECORD will contain all files which were installed as part of the installation of distA, and likewise for distB.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Fri Oct 14 22:56:40 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 14 Oct 2011 20:56:40 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318625800.0.0.86292696171.issue12405@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

s/dependencies between dependencies/dependencies between distributions/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Fri Oct 14 23:55:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Oct 2011 21:55:48 +0000
Subject: [issue13052] IDLE: replace ending with '\' causes crash
In-Reply-To: <1317177843.04.0.691154940707.issue13052@psf.upfronthosting.co.za>
Message-ID: <1318629348.93.0.169938933062.issue13052@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

IDLE is sufficiently undocumented that I think we may, *if necessary*, treat the details of 'expected behavior' as undefined, or look to other programs for guidance. Certainly, 'crash' is unexpected and undesired ;-).

Without "[] Regular expression" checked, I expect a simple 'normal mode' "find the literal string and replace with literal string" behavior. This is how Notepad and Notepad++ work. Neither has any problem with trailing '\'. The main 'special chars' I noticed are those normally significant to dialogs: the [Tab] key advances focus, [Enter] key executes the currently highlighted command. (The other two programs start with [Find] rather than [Replace] selected, but that is a minor and visually noticeable detail.) ^C and ^V work as expected in the entry boxes, other control chars beep.

In this mode, it is an implementation detail that the re module is used, and it should be transparent that it is. So 'backreferences' are meaningless. But in regular expression mode, they should act as an experienced re user would expect. (What that is, I an not sure, as I am not such ;-).

Notepad++ separates 'Regular expression' from the other options and has a boxed three-button radio group

|-Search mode-------------------------| 
| () Normal                           |
| () Extended (\n, \r, \t, \0, \x...) |
| () Regular expression               |
|-------------------------------------|

These amount to treating the find/replace entries as uninterpreted string literals (as with input()*), cooked \-interpreted string literals, and as (raw literal) relational expressions. We could consider Extended mode as a new feature.

* While raw string literals do not allow training '\', the input function does (in the standard interpreter window)

>>> print(input())
abc\
abc\

However, this does *not* work in IDLE 3.2.2, Win 7:

>>> print(input())
abd\  [hit Enter here]
      [which IDLE echoes here]
      [must Enter again]
      [which IDLE echoes again]
>>>   [to get new prompt]
>>> x=input()
abc\
     

>>> x
''

Entering "a\bc" is also messed up:

>>> x=input()
a\bc

>>> x
''
>>> x=input()
a\bc
>>> x
'a\\bc'

The difference between the two above involves the IDLE history mechanism, which (wrongly, in my view) treats response to input() as part of the statement.

I wonder if this is related to the current bug. Does the replace dialog use input()? Or is input entirely handled by tk, and should I open another report?

Ezio's other point:
'''
m = prog.match(chars, col)
if not prog:
    return False
...
I think that "if not prog" in the snippet I pasted should be "if not m".  Pattern objects are always True (I assume prog is always a pattern object).'''

I would guess that you are correct and this should be fixed also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13052>
_______________________________________

From report at bugs.python.org  Sat Oct 15 00:19:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Oct 2011 22:19:28 +0000
Subject: [issue12967] IDLE RPC Proxy for standard IO streams lacks 'errors'
	attribute
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1318630768.49.0.730271584933.issue12967@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for redirecting this issue. The goal should be to make the proxies completely transparent. They mostly are, but occasional issues arise when they are not. Sometimes the source of a problem is not clear. I wonder, for instance, whether the non-function in IDLE of

>>> print(input())
abc\
abc\

has anything to do with the bidirectional communication or is entirely internal to IDLE.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12967>
_______________________________________

From report at bugs.python.org  Sat Oct 15 00:19:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Oct 2011 22:19:57 +0000
Subject: [issue13052] IDLE: replace ending with '\' causes crash
In-Reply-To: <1317177843.04.0.691154940707.issue13052@psf.upfronthosting.co.za>
Message-ID: <1318630797.18.0.40966758015.issue13052@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Defining the desired behavior is a good place where to start.  Next it would be good to have tests that reflect the desired behavior, and eventually make them pass with a proper patch.

Currently IDLE seems to understand \n, \t, etc. in the "Replace with" field, but not in the "Find" field.  That means that it's possible to easily replace e.g. 4 spaces with a \t, but not the other way around.
This works regardless of the "Regular expression" checkbox.

When "Regular expression" is checked, backreferences like \1 also work (if used correctly).

I think these behaviors are fine and should be preserved.  For the non-regex mode, re.escape() could be used if the \n, \t, etc. still work, but I think that for the regex mode the right way to go is to catch regex errors.  This will protect against wrong backreferences and trailing \, without altering the meaning of the regex.

We could also support \n, \t, etc. in the "Find" box, but that's a separate issue.

Regarding the print(input()) and the other example, they all seem to work fine here with 3.2/XP.

----------
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13052>
_______________________________________

From report at bugs.python.org  Sat Oct 15 00:27:25 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Oct 2011 22:27:25 +0000
Subject: [issue13127] xml.dom.Attr.name is not labeled as read-only
In-Reply-To: <1318047492.07.0.217686953928.issue13127@psf.upfronthosting.co.za>
Message-ID: <1318631245.46.0.631483950995.issue13127@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The docs are unchanged in 3.2. I presume the behavior is also.

----------
nosy: +terry.reedy
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13127>
_______________________________________

From report at bugs.python.org  Sat Oct 15 00:34:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Oct 2011 22:34:48 +0000
Subject: [issue13131] FD leak in urllib2
In-Reply-To: <1318076753.32.0.0530567720617.issue13131@psf.upfronthosting.co.za>
Message-ID: <1318631688.64.0.0551613828622.issue13131@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Can you test both the leak and fix (if needed) on 3.2? 
(I am on Win7).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13131>
_______________________________________

From report at bugs.python.org  Sat Oct 15 00:48:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Oct 2011 22:48:17 +0000
Subject: [issue13139] multiprocessing.map skips finally blocks
In-Reply-To: <1318125947.15.0.13973515193.issue13139@psf.upfronthosting.co.za>
Message-ID: <1318632497.85.0.348767239488.issue13139@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

One might ask why an Exception in one process kills all in the Pool. Perhaps multiprocessing emulates threading too closely.
Perhaps it is assumed that if one is bad, all are. Jesse?

----------
nosy: +jnoller, terry.reedy
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13139>
_______________________________________

From report at bugs.python.org  Sat Oct 15 00:55:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Oct 2011 22:55:20 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
In-Reply-To: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>
Message-ID: <1318632920.63.0.225615741794.issue13177@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Canceling the chained exception might work as a workaround, but it requires yet another try/except and it's not very elegant in my opinion.

Raymond, about __missing__ it shouldn't be a problem here, because we are using "in" to look in the cache, and the cache is either a dict or an OrderedDict and they don't use __missing__.

I also did some crude benchmark using strings (see attached file):
always hit
try: 0.3375518321990967
in : 0.43109583854675293
always miss
try: 2.7987680435180664
in : 0.3211240768432617
5 hit, 5 miss
try: 18.37925887107849
in : 5.305108070373535
9 hit, 1 miss
try: 8.38001799583435
in : 6.524656057357788

Of course this will change if the hash() function gets more expensive, or if the ratio hits:miss is different.

----------
Added file: http://bugs.python.org/file23412/issue13177-bench.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Sat Oct 15 01:20:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Oct 2011 23:20:29 +0000
Subject: [issue13149] optimization for append-only StringIO
In-Reply-To: <1318295854.61.0.959309073941.issue13149@psf.upfronthosting.co.za>
Message-ID: <1318634429.49.0.0853903541097.issue13149@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Like parts of the Python test suite, I use StringIO to capture print/write output for testing in an output...output/getvalue/reset(seek(0),truncate(0)) cycle. While this enhancement would not currently affect me (as I only do a few prints each cycle), I can easily imagine other cases where it would.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13149>
_______________________________________

From report at bugs.python.org  Sat Oct 15 01:39:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Oct 2011 23:39:46 +0000
Subject: [issue12967] IDLE RPC Proxy for standard IO streams lacks 'errors'
	attribute
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1318635586.53.0.861898290543.issue12967@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12967>
_______________________________________

From report at bugs.python.org  Sat Oct 15 01:40:12 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Oct 2011 23:40:12 +0000
Subject: [issue13152] textwrap: support custom tabsize
In-Reply-To: <1318338300.67.0.514985359705.issue13152@psf.upfronthosting.co.za>
Message-ID: <1318635612.17.0.0504440903398.issue13152@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am a bit surprised this was not part of the original design.
'Tabsize' make 'expand_tabs' redundant and tabsize==0 could be interpreted as expand_tabs==False. On the other hand, the meaning of 'expand_tabs' could be expanded to include the tabsize. I am almost tempted to suggest making expand_tabs > 1 be interpreted as tabsize and make expand_tabs==True(1, the current default) be interpreted as expand_tabs==8 (the new default) for back_compatibility.

Patch as is has new tests and looks good on first reading.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13152>
_______________________________________

From report at bugs.python.org  Sat Oct 15 01:40:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Oct 2011 23:40:41 +0000
Subject: [issue13144] Global Module Index link in the offline documentation is
	incorrect
In-Reply-To: <1318248968.6.0.0439422849007.issue13144@psf.upfronthosting.co.za>
Message-ID: <1318635641.91.0.737384407143.issue13144@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13144>
_______________________________________

From report at bugs.python.org  Sat Oct 15 01:42:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Oct 2011 23:42:20 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318635740.01.0.540929402114.issue13153@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sat Oct 15 01:43:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Oct 2011 23:43:17 +0000
Subject: [issue13178] Need tests for Unicode handling in install_distinfo and
	install_data
In-Reply-To: <1318604483.39.0.256027567702.issue13178@psf.upfronthosting.co.za>
Message-ID: <1318635797.83.0.806946242101.issue13178@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13178>
_______________________________________

From report at bugs.python.org  Sat Oct 15 02:02:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Oct 2011 00:02:00 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318636920.5.0.330616995177.issue13153@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The current Windows build used 2-byte unicode chars because that is what Windows does. In 3.3, all builds will use a new unicode implementation that uses 1,2,or4 bytes as needed. But I suspect we will still have the paste problem unless we can somehow bypass the tk limitation.

Printing a Python string to the screen does not seem to involve conversion to a tk string. Or else tk blindly copies surrogate pairs to Windows even though it cannot create them.

In any case, true window-closing crashes (as opposed to an error traceback) are obnoxious bugs that we try to fix if possible. I verified this on my 64-bit Win 7 system. Thanks for the report. Feel free to look into the code if you can.

----------
nosy: +terry.reedy
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sat Oct 15 02:13:22 2011
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 15 Oct 2011 00:13:22 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1318637602.01.0.544468168679.issue4431@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

My experience is that for VS2008 at least, the /MANIFESTFILE: option seems to be ignored if there is nothing to put in the manifest, and this tends to be true if you use a static CRT instead of the DLL based one (ie, if you use /MT)

Issue 7833 has a patch designed to both (a) remove the manifest entirely if the only assembly reference is to the CRT and (b) give the setup.py author finer control over this behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Sat Oct 15 02:28:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Oct 2011 00:28:57 +0000
Subject: [issue13163] `port` and `host` are confused in `_get_socket
In-Reply-To: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za>
Message-ID: <1318638537.8.0.106758522016.issue13163@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My understanding is that an undocumented internal methods has two bugs that cancel, so that correct calls work correctly -- but tracebacks do not. I think this should be fixed, especially given a working patch.

Optionally add a doc string, which is how we usually (often, when someone gets around to it) do doc internal functions. Perhaps include the current comment (which I do not understand).

If you, Victor, are not in the contributors file, add a one-line patch for that.

Optionally (but it would certainly be good learning practice) add NEWS item. Something like
"Issue 13163: fix smtplib.SMTP._get_socket so that tracebacks correctly identity host and port arguments.
However, this is best done when someone is ready to apply and push the patch, as frequent changes to NEWS make patches stale.

----------
nosy: +terry.reedy
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13163>
_______________________________________

From report at bugs.python.org  Sat Oct 15 02:34:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Oct 2011 00:34:31 +0000
Subject: [issue13168] Python 2.6 having trouble finding modules when invoked
	via a symlink
In-Reply-To: <1318522134.74.0.524944339938.issue13168@psf.upfronthosting.co.za>
Message-ID: <1318638871.07.0.643179534784.issue13168@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Try upgrading to 2.6.6, 2.6.7 or 2.7.2. 

In any case, 2.6 is in security-fix only mode, so unless you have a problem with the most recent releases (2.7.2 or 3.2.2) this issue should be closed as out-of-date.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13168>
_______________________________________

From report at bugs.python.org  Sat Oct 15 02:43:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Oct 2011 00:43:19 +0000
Subject: [issue13171] Bug in file.read(), can access unknown data.
In-Reply-To: <1318531210.93.0.392401137226.issue13171@psf.upfronthosting.co.za>
Message-ID: <1318639399.69.0.124076706868.issue13171@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This issue has come up enough (tracker and python-list) that I think adding a mild adaptation of the C standard paragraph might be a good idea. Changing to a doc issue.

----------
assignee:  -> docs at python
components: +Documentation -IO, Library (Lib), Windows
nosy: +docs at python, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13171>
_______________________________________

From report at bugs.python.org  Sat Oct 15 02:45:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Oct 2011 00:45:26 +0000
Subject: [issue13174] test_os failures on Fedora 15: listxattr() returns
	['security.selinux']
In-Reply-To: <1318541567.35.0.652639760355.issue13174@psf.upfronthosting.co.za>
Message-ID: <1318639526.38.0.867741475949.issue13174@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13174>
_______________________________________

From report at bugs.python.org  Sat Oct 15 03:12:38 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Oct 2011 01:12:38 +0000
Subject: [issue13179] IDLE uses common tkinter variables across all editor
	windows
In-Reply-To: <1318607548.28.0.391563618977.issue13179@psf.upfronthosting.co.za>
Message-ID: <1318641158.22.0.196333428254.issue13179@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is more of a feature request than a bug report, in that the behavior appear intentional. But that is a moot point in that new IDLE features do not have to wait for a new release. The proposed new behavior seems plausibly better. I just wonder if anything in flist.vars *should* carry over (maybe as a copy) to all edit windows, but I do not know its contents.

Also, I can imagine that someone who knows about (I did not before) and likes the 'code context' option (I might start using it) would want it to be always on once turned on. That suggests that it should be added to the configure dialog before being made local with this patch. I might feel the same about at least some of the other vars also.

----------
nosy: +terry.reedy
type: behavior -> feature request
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13179>
_______________________________________

From report at bugs.python.org  Sat Oct 15 03:44:24 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Sat, 15 Oct 2011 01:44:24 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1318643064.82.0.902440417489.issue12344@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

It's quite alright. Thanks for finishing it up. I realize I ended up a by out of my depth with regards to packaging's internals and the nuance involved in this fix. Thanks for all the help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Sat Oct 15 06:03:46 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Sat, 15 Oct 2011 04:03:46 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318651426.16.0.868533376294.issue13153@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

Just for comparison, on Python 2.7.1 (x32 on Windows 7) it's possible to paste the char (but can't use it) and a nice error is given. 

>>> u'?'
Unsupported characters in input

So the problem was partially solved but something might have happened with the 3.x port...

Searching on both source codes, I can see the following block was commented on Python3.2 but not on Python2.7 (Maybe someone removed someone else's bug fix?) and an `assert` was added.

#--- Lines 605 to 613 of PyShell.py

assert isinstance(source, str)
#                       v-- on Python2.7 it is types.UnicodeType instead
#if isinstance(source, str):
#    from idlelib import IOBinding
#    try:
#        source = source.encode(IOBinding.encoding)
#    except UnicodeError:
#        self.tkconsole.resetoutput()
#        self.write("Unsupported characters in input\n")
#        return

I uncommented those lines, removed the `assert` and deleted __pycache__ for fresh bytecode but the error keeps happening.

This function `runsource()` is only called after the return key is pressed so the bug was introduced on another part of the program.

I'll search further but it's hard to do that without traceback of the error.

(Maybe `runit()` is the problem because it seems to build the line and call `runsource(line)`)

------
PS: @Terry Reedy
That looks nice to have different lengths for chars but what will be the impact on performance? Indexing will still be in constant time?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sat Oct 15 06:33:11 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Sat, 15 Oct 2011 04:33:11 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318653191.8.0.291503882306.issue13153@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

Just to complete my monologue:
Here's the traceback from running IDLE in cmd line.


C:\Python32\Lib\idlelib>python -i idle.py
Traceback (most recent call last):
  File "idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "C:\Python32\Lib\idlelib\PyShell.py", line 1429, in main
    root.mainloop()
  File "C:\Python32\Lib\tkinter\__init__.py", line 1009, in mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-2: invalid continuation byte


Not much meaningful but is better than nothing... Looks like some traceback is missing, and this one points to tkinter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sat Oct 15 07:14:40 2011
From: report at bugs.python.org (Jason Howlett)
Date: Sat, 15 Oct 2011 05:14:40 +0000
Subject: [issue13184] Multi-layered symlinks cause runtime error. sys.path is
	malformed.
Message-ID: <1318655680.83.0.71543236392.issue13184@psf.upfronthosting.co.za>


New submission from Jason Howlett <jaguariv at gmail.com>:

This error is observed in Python 2.7.2.

Steps to recreate problem:

1) Create directory ~/pytest.
2) Untar Python 2.7.2 sources into ~/pytest
3) configure, build, and install with --prefix=~/pytest/pyinstall
4) mkdir -p ~/pytest/other/bin
5) cd ~/pytest/other/bin
6) ln -s ../../pyinstall/bin/python
7) cd ~/pytest
8) ln -s other/bin bin
9) bin/python

This will result in the following exception:
Traceback (most recent call last):
  File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 564, in <module>
    main()
  File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 546, in main
    known_paths = addusersitepackages(known_paths)
  File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 279, in addusersitepackages
    user_site = getusersitepackages()
  File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 254, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 243, in getuserbase
    from sysconfig import get_config_var
ImportError: No module named sysconfig

Placing 'print sys.path' on line 242 of site.py prints out something like this:

['/home/jason/pyinstall/lib/python27.zip', '/home/jason/pyinstall/lib/python2.7', '/home/jason/pyinstall/lib/python2.7/plat-linux2', '/home/jason/pyinstall/lib/python2.7/lib-tk', '/home/jason/pyinstall/lib/python2.7/lib-old', '/home/jason/pyinstall/lib/python2.7/lib-dynload']

Notice that the root directory is /home/jason/pyinstall instead of the correct value /home/jason/pytest/pyinstall.

Now, on line 65 of site.py, add import sysconfig. For some reason this works at this point in site.py, but not down on line 243.

In sysconfig.py, at line 94, add the following:
print 'SYSCONFIG:', sys.exec_prefix, _EXEC_PREFIX

This will print the following:
SYSCONFIG: /home/jason/pytest/bin/../../pyinstall /home/jason/pyinstall

Line 93 of sysconfig.py is a call to normpath that collapses the path. The root of this problem is that the value of sys.exec_prefix is not correct. The value it has will work fine if ls'ing it in a shell as it handles the symlink /home/jason/pytest/bin properly. Path calculations internal to python, however, do not end up with the correct results.

I believe the fix to this problem is to modify Modules/getpath.c, starting at line 488, and instead of looking only for a symlink in the python executable, also look for a link in any of the path elements leading up to the executable. Detecting and expanding these out should result, in this example, with sys.exec_prefix being /home/jason/pytest/pyinstall and the correct behavior in sysconfig, site, etc.

----------
components: Interpreter Core
messages: 145582
nosy: Jason.Howlett
priority: normal
severity: normal
status: open
title: Multi-layered symlinks cause runtime error.  sys.path is malformed.
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13184>
_______________________________________

From report at bugs.python.org  Sat Oct 15 07:18:25 2011
From: report at bugs.python.org (Phillip Feldman)
Date: Sat, 15 Oct 2011 05:18:25 +0000
Subject: [issue13185] Why does Python interpreter care about curvy quotes in
	comments?
Message-ID: <1318655905.33.0.141769881228.issue13185@psf.upfronthosting.co.za>


New submission from Phillip Feldman <phillip.m.feldman at gmail.com>:

When I try to run a Python script that contains curvy quotes inside comments, the interpreter gets upset:

SyntaxError: Non-ASCII character '\x92' in file ... on line 20198, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

Given that the quotes are appearing only in comments, why does the interpreter care about them?  Why should it be doing anything at all with comments other than stripping them off?

----------
messages: 145583
nosy: Phillip.M.Feldman
priority: normal
severity: normal
status: open
title: Why does Python interpreter care about curvy quotes in comments?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13185>
_______________________________________

From report at bugs.python.org  Sat Oct 15 07:18:45 2011
From: report at bugs.python.org (Phillip Feldman)
Date: Sat, 15 Oct 2011 05:18:45 +0000
Subject: [issue13185] Why does Python interpreter care about curvy quotes in
	comments?
In-Reply-To: <1318655905.33.0.141769881228.issue13185@psf.upfronthosting.co.za>
Message-ID: <1318655925.44.0.327150452576.issue13185@psf.upfronthosting.co.za>


Changes by Phillip Feldman <phillip.m.feldman at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13185>
_______________________________________

From report at bugs.python.org  Sat Oct 15 07:48:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Oct 2011 05:48:29 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318657709.18.0.48623635613.issue13153@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

[Yes, indexing will still be O(1), though I personally consider that less important than most make it to be. Consistency across platforms and total time and space performance of typical apps should be the concern. There is ongoing work on improving the new implementation. Some operations already take less space and run faster.]

The traceback may very well be helpful. It implies that copying a supplemental char does not produce proper utf-8 encoded bytes. Or if it does, tkinter (or tk underneath it) does not recognize them. But then the problem should be the initial byte, not the continuation bytes, which are the same for all chars and which all have 10 for their two high order bits. See
https://secure.wikimedia.org/wikipedia/en/wiki/Utf-8
for a fuller explanation.

Line 1009 is the definition of Misc.mainloop(). I believe self.tk represents the embedded tcl interpreter, which is a black box from Python's viewpoint. Perhaps we should wrap the call with

try:
  self.tk.mainloop(n)
except Exception as e:
  <print error message with all info attached to e before exiting>

This should catch any miscellaneous crashes which are not otherwise caught and maybe turn the crash issues into bug reports -- the same way that running from the command line did. (It will still be good to catch what we can at error sites and give better, more specific messages.) (What I am not familiar with is how the command line interpreter might turn a tcl error into a python exception and why IDLE does not.)

When I copy '?' and paste into the command line interpreter or Notepad++, I get '??'. I am guessing that ?? represent a surrogate pair and that Windows separately encodes each. The result would be 'illegal' utf-8 with an illegal continuation chars. An application can choose to decode the 'illegal' utf-8 -- or not. Python can when "errors='surrogate_escape" (or something like that) is specified. It might be possible to access the raw undecoded bytes of the clipboard with the third party pythonwin module. I do not know if there is anyway to do so with tk.

I wonder if tcl is calling back to Python for decoding and whether there was a change in the default for errors or the callback specification that would explain a change from 2.7 to 3.2.

Ezio, do you know anything about these speculations?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sat Oct 15 12:08:02 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Oct 2011 10:08:02 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318673282.25.0.800229147248.issue13153@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the additional investigation.  You don't see more in the traceback because the exception is occurring in the _tkinter C glue layer.  I am able to reproduce the problem on some other platforms as well (e.g. Python 3.x on OS X with Carbon Tk 8.4).  More later.

----------
components: +Tkinter -Unicode, Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sat Oct 15 13:05:44 2011
From: report at bugs.python.org (alon horev)
Date: Sat, 15 Oct 2011 11:05:44 +0000
Subject: [issue7317] Display full tracebacks when an error occurs
	asynchronously
In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>
Message-ID: <1318676744.4.0.642268850066.issue7317@psf.upfronthosting.co.za>


alon horev <alonho at gmail.com> added the comment:

Submitting a patch proposing this format:

-----BEGIN UNRAISABLE EXCEPTION-----
Class: AttributeError
Instance: "'NoneType' object has no attribute 'someattr'"
Function: <bound method A.__del__ of <__main__.A object at 0x1007671d0>>
Traceback (most recent call last):
  File "/tmp/bla.py", line 4, in __del__
    None.someattr
-----END UNRAISABLE EXCEPTION-----

I've wrapped the exception information with header/footer differentiating it from a user's error handling code that also prints tracebacks (is it too much?).

I've considered using the warnings module, But I dislike the suppression of already warned messages. (2 instances will raise exception in __del__ but only one message will be printed) 

This is my first patch submission so feel free giving me a hard time.

----------
keywords: +patch
nosy: +alonho
Added file: http://bugs.python.org/file23413/7317.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7317>
_______________________________________

From report at bugs.python.org  Sat Oct 15 13:20:08 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 15 Oct 2011 11:20:08 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1318677608.65.0.0414892818795.issue4431@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Corey, Sebastian: VS 2010 is not supported. So failure to work correctly is not a bug in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Sat Oct 15 13:26:02 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 15 Oct 2011 11:26:02 +0000
Subject: [issue13185] Why does Python interpreter care about curvy quotes in
	comments?
In-Reply-To: <1318655905.33.0.141769881228.issue13185@psf.upfronthosting.co.za>
Message-ID: <1318677962.38.0.0174023308327.issue13185@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The error message told you exactly what the problem is. Your source file does not conform to PEP 263. The PEP also explains why this applies to comments as well: because the entire file gets decoded according to the source encoding, and parsing (including determining what comments are) only starts afterwards.

Closing the report as invalid.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13185>
_______________________________________

From report at bugs.python.org  Sat Oct 15 14:28:18 2011
From: report at bugs.python.org (Julian)
Date: Sat, 15 Oct 2011 12:28:18 +0000
Subject: [issue7317] Display full tracebacks when an error occurs
	asynchronously
In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>
Message-ID: <1318681698.82.0.897227274292.issue7317@psf.upfronthosting.co.za>


Julian <python_org at somethinkodd.com> added the comment:

The formatting isn't very conventional for Python.

Why not use the normal format? i.e.
 
Traceback (most recent call last):
  File "/tmp/bla.py", line 4, in __del__
    None.someattr
AttributeError: 'NoneType' object has no attribute 'someattr'

Why is this more likely to get confused with user input than other unhandled exceptions?

If you ARE going to deviate, it may be helpful to have it explain why this exception wasn't caught through the normal channels. Maybe the last line could be: "Failed to raise this exception in __del__/finalizer method." or similar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7317>
_______________________________________

From report at bugs.python.org  Sat Oct 15 15:30:38 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 15 Oct 2011 13:30:38 +0000
Subject: [issue13186] instance_ass_item() broken in classobject.c (Py2.7)
Message-ID: <1318685438.52.0.865873705408.issue13186@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Starting at line 1223 in classobject.c, you can find this code:

    if (item == NULL)
        arg = PyInt_FromSsize_t(i);
    else
        arg = Py_BuildValue("(nO)", i, item);
    if (arg == NULL) {
        Py_DECREF(func);
        return -1;
    }
    res = PyEval_CallObject(func, arg);

If item is NULL, arg will be assigned an int object. Otherwise, it will receive a tuple. Only the second case works in the subsequent call to PyEval_CallObject(), i.e. arg must always be assigned an argument tuple.

A quick fix would be to call Py_BuildValue("(n)", i) in the first case. The code just did a getattr(), so this is not performance critical anymore.

I found this bug because the test_class.py test suite was failing in Cython.

----------
components: Interpreter Core
messages: 145590
nosy: scoder
priority: normal
severity: normal
status: open
title: instance_ass_item() broken in classobject.c (Py2.7)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13186>
_______________________________________

From report at bugs.python.org  Sat Oct 15 16:15:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Oct 2011 14:15:22 +0000
Subject: [issue13088] Add Py_hexdigits constant: use one unique constant to
	format a digit to hexadecimal
In-Reply-To: <1317511977.11.0.738521421258.issue13088@psf.upfronthosting.co.za>
Message-ID: <1318688122.25.0.819810453802.issue13088@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You broke compilation under Windows.

----------
assignee:  -> haypo
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13088>
_______________________________________

From report at bugs.python.org  Sat Oct 15 16:31:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Oct 2011 14:31:29 +0000
Subject: [issue13139] multiprocessing.map skips finally blocks
In-Reply-To: <1318125947.15.0.13973515193.issue13139@psf.upfronthosting.co.za>
Message-ID: <1318689089.73.0.125572241768.issue13139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As mentioned in http://docs.python.org/dev/library/multiprocessing#multiprocessing.pool.AsyncResult.get
?If the remote call raised an exception then that exception will be reraised by get().?

map() is just map_async() followed by a get() call on the result.
Also, worker processes are called in daemon mode, which explains that children get killed as soon as the parent exits.

If you rephrase your example as:

try:
    Pool(3).map(Process, ['1','2','3'])
finally:
    sleep(1)

then all the children's finally clauses get a chance to be executed before the parent exits.

I would therefore call it "not a bug", although you might add a sentence in the map() documentation stating that an exception is raised as soon as one of the worker fails.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13139>
_______________________________________

From report at bugs.python.org  Sat Oct 15 17:09:08 2011
From: report at bugs.python.org (alon horev)
Date: Sat, 15 Oct 2011 15:09:08 +0000
Subject: [issue7317] Display full tracebacks when an error occurs
	asynchronously
In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>
Message-ID: <1318691348.61.0.0877599543888.issue7317@psf.upfronthosting.co.za>


alon horev <alonho at gmail.com> added the comment:

Here's the next attempt (took your advice about the convention):

Exception ignored in: <bound method A.__del__ of <__main__.A object at 0x1007671d0>>
Traceback (most recent call last):
  File "/tmp/bla.py", line 4, in __del__
    None.someattr
AttributeError: 'NoneType' object has no attribute 'someattr'

reminder of the current format for comparison:

Exception AttributeError: "'NoneType' object has no attribute 'someattr'" in <bound method A.__del__ of <__main__.A object at 0x1007671d0>> ignored

I thought about a more elaborate explanation than "Exception ignored" but grepping this function through the code shows it can be called from various places making it too generic.

The reason I wanted to add a header/footer is for stating the message and the traceback go together (I print tracebacks to screen all the time), but it might be TMI..

----------
Added file: http://bugs.python.org/file23414/7317.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7317>
_______________________________________

From report at bugs.python.org  Sat Oct 15 17:36:16 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 15 Oct 2011 15:36:16 +0000
Subject: [issue13182] pysetup run bdist_wininst does not work (tries to use
	"install" command)
In-Reply-To: <1318616771.75.0.522951953738.issue13182@psf.upfronthosting.co.za>
Message-ID: <1318692976.38.0.334447874473.issue13182@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Closing as a duplicate of #13151, which also identifies other problems with this command.

----------
components: +Library (Lib)
nosy: +vinay.sajip
resolution:  -> duplicate
status: open -> closed
superseder:  -> pysetup3 run bdist_wininst fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13182>
_______________________________________

From report at bugs.python.org  Sat Oct 15 17:41:50 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 15 Oct 2011 15:41:50 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1318546022.2.0.0477576720396.issue13175@psf.upfronthosting.co.za>
Message-ID: <1318693310.69.0.948151007933.issue13175@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'm trying to reproduce this too, but have failed so far. Which version(s) of Windows did the problems appear on?

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Sat Oct 15 17:42:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Oct 2011 15:42:24 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1318693344.86.0.37143414929.issue10653@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Crashes on the Windows buildbots:

f:\dd\vctools\crt_bld\self_x86\crt\src\strftime.c(832) : Assertion failed: ( "Invalid format directive" , 0 )
f:\dd\vctools\crt_bld\self_x86\crt\src\strftime.c(484) : Assertion failed: FALSE

----------
assignee:  -> haypo
nosy: +pitrou
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Sat Oct 15 17:44:52 2011
From: report at bugs.python.org (Paul Moore)
Date: Sat, 15 Oct 2011 15:44:52 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1318693310.69.0.948151007933.issue13175@psf.upfronthosting.co.za>
Message-ID: <CACac1F8u-ZyaBPg8EbSTMCBVsFViJ_C2KEJ72q1OwF8PKWg3Mw@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

Windows 7, 32 bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Sat Oct 15 17:46:13 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 15 Oct 2011 15:46:13 +0000
Subject: [issue13172] pysetup run --list-commands fails with a traceback
In-Reply-To: <1318531671.43.0.795221927422.issue13172@psf.upfronthosting.co.za>
Message-ID: <1318693573.42.0.224560520394.issue13172@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> so I guess that handling the issue gracefully isn't really important.

Then should this issue be closed?

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13172>
_______________________________________

From report at bugs.python.org  Sat Oct 15 17:59:25 2011
From: report at bugs.python.org (Paul Moore)
Date: Sat, 15 Oct 2011 15:59:25 +0000
Subject: [issue13172] pysetup run --list-commands fails with a traceback
In-Reply-To: <1318693573.42.0.224560520394.issue13172@psf.upfronthosting.co.za>
Message-ID: <CACac1F8F-eRFbHKRVCCEx0VnSXhEr0E4-VY9MsY8EqD2tN-vjw@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

I suppose so, yes. But it feels symptomatic of a general lack of clean
error handling, which I think should be fixed :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13172>
_______________________________________

From report at bugs.python.org  Sat Oct 15 18:17:45 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 15 Oct 2011 16:17:45 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1318695465.41.0.802972571784.issue12406@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Another problem in creating the MSI is that Lib\test\keycert.passwd.pem and Lib\test\keycert.pem both lead to a short name of 'KEYCERT.PEM', which is causing an assertion failure in msilib.Directory.make_short(). The other clashing pair is Lib\test\ssl_key.passwd.pem and Lib\test\ssl_key.pem, at least at the moment, both of which map to 'SSL_KEY.PEM'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Sat Oct 15 19:03:44 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 15 Oct 2011 17:03:44 +0000
Subject: [issue13179] IDLE uses common tkinter variables across all editor
	windows
In-Reply-To: <1318641158.22.0.196333428254.issue13179@psf.upfronthosting.co.za>
Message-ID: <4E99BCE9.3040801@gmail.com>


Roger Serwy <roger.serwy at gmail.com> added the comment:

For Code Context, the behavior is a bug since the menu item check can be 
changed independently of the actual status of Code Context.

As far as I can tell, flist.vars mostly contains variables  created by 
EditorWindow.py's "get_var_obj". A quick grep for ".vars" in idlelib can 
confirm that.

It also contains variables created by PyShell.py, particularly 
'<<toggle-jit-stack-viewer>>' and '<<toggle-debugger>>'.  Since the 
shell can only have one instance, its tkinter variables can be held 
local to the EditorWindow instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13179>
_______________________________________

From report at bugs.python.org  Sat Oct 15 19:43:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 15 Oct 2011 17:43:33 +0000
Subject: [issue13186] instance_ass_item() broken in classobject.c (Py2.7)
In-Reply-To: <1318685438.52.0.865873705408.issue13186@psf.upfronthosting.co.za>
Message-ID: <E1RF8Gh-0001gA-4g@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 418fbf1af875 by Benjamin Peterson in branch '2.7':
PyEval_CallObject requires a tuple of args (closes #13186)
http://hg.python.org/cpython/rev/418fbf1af875

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13186>
_______________________________________

From report at bugs.python.org  Sat Oct 15 20:52:05 2011
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 15 Oct 2011 18:52:05 +0000
Subject: [issue13139] multiprocessing.map skips finally blocks
In-Reply-To: <1318125947.15.0.13973515193.issue13139@psf.upfronthosting.co.za>
Message-ID: <1318704725.79.0.365613884786.issue13139@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Antoine is correct, as he usually is. This is more of a documentation issue than bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13139>
_______________________________________

From report at bugs.python.org  Sat Oct 15 20:52:27 2011
From: report at bugs.python.org (Mark Bucciarelli)
Date: Sat, 15 Oct 2011 18:52:27 +0000
Subject: [issue12997] sqlite3: PRAGMA foreign_keys = ON doesn't work
In-Reply-To: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>
Message-ID: <1318704747.4.0.655580223219.issue12997@psf.upfronthosting.co.za>


Mark Bucciarelli <mark at crosscutmedia.com> added the comment:

Something strange is going on.

I just built pysql 2.6.3 from source, and now my unit test gives the expected "IntegrityError: foreign key constraint failed" message.

poq, what do you get when you run this script:

import sqlite3
print "sqlite3.version_info =", sqlite3.version_info
print "sqlite3.sqlite_version_info =", sqlite3.sqlite_version_info
from pysqlite2 import dbapi2 as sqlite3
print "pysqlite2.version_info =", sqlite3.version_info
print "pysqlite2.sqlite_version_info =", sqlite3.sqlite_version_info

I get the following:

sqlite3.version_info = (2, 6, 0)
sqlite3.sqlite_version_info = (3, 6, 12)
pysqlite2.version_info = (2, 6, 3)
pysqlite2.sqlite_version_info = (3, 7, 8)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12997>
_______________________________________

From report at bugs.python.org  Sat Oct 15 21:43:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 15 Oct 2011 19:43:41 +0000
Subject: [issue7317] Display full tracebacks when an error occurs
	asynchronously
In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>
Message-ID: <1318707821.17.0.676826590322.issue7317@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7317>
_______________________________________

From report at bugs.python.org  Sat Oct 15 22:25:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 15 Oct 2011 20:25:21 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318710321.15.0.780031092829.issue13153@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Ezio, do you know anything about these speculations?

Assuming that the non-BMP character is represented with two surrogates (\ud801\udca2) and that _tkinter tries to decode them independently, the error message ("invalid continuation byte") would be correct.

Python 2 UTF-8 codec is more permissive and allows encoding/decoding of surrogates (this might also explain why it works on Python 2): 
>>> u'\ud801'.encode('utf-8')
'\xed\xa0\x81'
>>> '\xed\xa0\x81'.decode('utf-8')
u'\ud801'

But on Python 3, trying to decode that results in an error:
>>> b'\xed\xa0\x81'.decode('utf-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: invalid continuation byte

> But then the problem should be the initial byte, not the continuation
> bytes, which are the same for all chars and which all have 10 for
> their two high order bits.

While it's true that all continuation bytes have the first two bits equal to '10', the opposite is not always true.  Some start bytes have additional restrictions on the continuation bytes.  For example, even if the first two bits of 0xA0 (0b10100000) are '10', the valid continuation bytes for a sequence starting with 0xED are restricted to the range 80..9F.

The fact that
>>> '\U000104a2'
'?'
works is because the input is all ASCII, so the decoding doesn't fail.


> [...]
> This should catch any miscellaneous crashes which are not otherwise
> caught and maybe turn the crash issues into bug reports -- the same
> way that running from the command line did.

Having some "safe net" to catch all the unhandled exceptions seems like a good idea.  This won't work in case of segfaults, but it's still better than nothing.  I'm not sure what you mean with "turn them into bug reports" though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sat Oct 15 22:28:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Oct 2011 20:28:45 +0000
Subject: [issue13187] relative imports don't work when circular
Message-ID: <1318710525.2.0.403840698833.issue13187@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is, to say the least, annoying.

$ mkdir mypackage
$ touch mypackage/__init__.py
$ echo "from . import b" > mypackage/a.py
$ echo "from . import a" > mypackage/b.py
$ ./python -c "import mypackage.a"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "mypackage/a.py", line 1, in <module>
    from . import b
  File "mypackage/b.py", line 1, in <module>
    from . import a
ImportError: cannot import name a

----------
components: Interpreter Core
messages: 145606
nosy: ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: relative imports don't work when circular
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13187>
_______________________________________

From report at bugs.python.org  Sat Oct 15 22:30:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Oct 2011 20:30:54 +0000
Subject: [issue13187] relative imports don't work when circular
In-Reply-To: <1318710525.2.0.403840698833.issue13187@psf.upfronthosting.co.za>
Message-ID: <1318710654.74.0.841070531947.issue13187@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13187>
_______________________________________

From report at bugs.python.org  Sat Oct 15 22:32:15 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 15 Oct 2011 20:32:15 +0000
Subject: [issue13187] relative imports don't work when circular
In-Reply-To: <1318710525.2.0.403840698833.issue13187@psf.upfronthosting.co.za>
Message-ID: <1318710735.4.0.141858531644.issue13187@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13187>
_______________________________________

From report at bugs.python.org  Sat Oct 15 22:48:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 15 Oct 2011 20:48:12 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318711692.18.0.216742140021.issue13153@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This can also be reproduced by doing:
>>> print('\U000104a2'[0])
?
and then copy/pasting the lone surrogate.
The traceback is:
  [...]
  File "C:\Programs\Python32\Lib\tkinter\__init__.py", line 1009, in mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: invalid continuation byte

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sat Oct 15 22:58:30 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 15 Oct 2011 20:58:30 +0000
Subject: [issue13187] relative imports don't work when circular
In-Reply-To: <1318710525.2.0.403840698833.issue13187@psf.upfronthosting.co.za>
Message-ID: <1318712310.02.0.660639148034.issue13187@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13187>
_______________________________________

From report at bugs.python.org  Sun Oct 16 00:05:40 2011
From: report at bugs.python.org (Jason Howlett)
Date: Sat, 15 Oct 2011 22:05:40 +0000
Subject: [issue13184] Multi-layered symlinks to python cause runtime error.
	sys.path is malformed.
In-Reply-To: <1318655680.83.0.71543236392.issue13184@psf.upfronthosting.co.za>
Message-ID: <1318716340.68.0.31327404504.issue13184@psf.upfronthosting.co.za>


Jason Howlett <jaguariv at gmail.com> added the comment:

Here is a proposed patch that solves the problem I described. Hopefully someone more familiar with Module/gethpath.c can make sure that it is ok and make improvements if needed.

----------
keywords: +patch
title: Multi-layered symlinks cause runtime error.  sys.path is malformed. -> Multi-layered symlinks to python cause runtime error.  sys.path is malformed.
Added file: http://bugs.python.org/file23415/symlink_path_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13184>
_______________________________________

From report at bugs.python.org  Sun Oct 16 00:20:47 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 15 Oct 2011 22:20:47 +0000
Subject: [issue13187] relative imports don't work when circular
In-Reply-To: <1318710525.2.0.403840698833.issue13187@psf.upfronthosting.co.za>
Message-ID: <1318717247.45.0.491238901035.issue13187@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13187>
_______________________________________

From report at bugs.python.org  Sun Oct 16 01:34:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Oct 2011 23:34:30 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
Message-ID: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In the following code, the original traceback attached to the exception thrown into the generator is ignored:

def gen():
    try:
        yield
    except:
        raise

g = gen()
try:
    1/0
except ZeroDivisionError as v:
    g.throw(v)


But if you replace the last line with:

    g.throw(type(v), v, v.__traceback__)

then the original traceback gets appended.
g.throw() should have fetched the __traceback__ attribute by itself.

----------
components: Interpreter Core
messages: 145609
nosy: ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: generator.throw() ignores __traceback__ of exception
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Sun Oct 16 02:50:10 2011
From: report at bugs.python.org (Eric G. Barron)
Date: Sun, 16 Oct 2011 00:50:10 +0000
Subject: [issue11457] os.stat(): add new fields to get timestamps as Decimal
	objects with nanosecond resolution
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1318726210.14.0.770569626875.issue11457@psf.upfronthosting.co.za>


Changes by Eric G. Barron <eric at ericography.com>:


----------
nosy: +ericography

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________

From report at bugs.python.org  Sun Oct 16 02:56:38 2011
From: report at bugs.python.org (Julian)
Date: Sun, 16 Oct 2011 00:56:38 +0000
Subject: [issue7317] Display full tracebacks when an error occurs
	asynchronously
In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>
Message-ID: <1318726598.81.0.559713517633.issue7317@psf.upfronthosting.co.za>


Julian <python_org at somethinkodd.com> added the comment:

I wish there was a less instrusive of saying "+1. I'm happy. Thanks." than posting a whole comment, but until then:

+1. I'm happy. Thanks.

(I haven't inspected the code - just based on the description.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7317>
_______________________________________

From report at bugs.python.org  Sun Oct 16 05:45:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 16 Oct 2011 03:45:05 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318736705.77.0.688266786228.issue13153@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> I'm not sure what you mean with "turn them into bug reports" though.

In about the last month, there have been, I think, 4 reports about IDLE crashing (quitting unexpectedly with no error traceback). I would consider it preferable if it quit with an error traceback that gave as much info as available, or if there is none, just said "IDLE has met an unexpected problem.", perhaps followed by something like "Pleaee note the circumstances and make a report of the tracker is there is none already."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sun Oct 16 08:23:25 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Oct 2011 06:23:25 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
In-Reply-To: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>
Message-ID: <1318746205.13.0.390683525693.issue13177@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Sorry, I'm not going to introduce a possible race condition because you find try/except to be less elegant than an if-contains test.  Also, I want to keep the current behavior of calling hash only once.  Your original complaint is valid though, so I'll go ahead and move the user_function call outside the exception block so as to avoid unnecessary exception chaining.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Sun Oct 16 08:44:55 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 Oct 2011 06:44:55 +0000
Subject: [issue13187] relative imports don't work when circular
In-Reply-To: <1318710525.2.0.403840698833.issue13187@psf.upfronthosting.co.za>
Message-ID: <1318747495.99.0.565559848538.issue13187@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This is the same problem that all "from x import y" circular imports have - it isn't specific to relative imports.

Closing as a duplicate of issue 992389

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> attribute error after non-from import

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13187>
_______________________________________

From report at bugs.python.org  Sun Oct 16 08:48:15 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 Oct 2011 06:48:15 +0000
Subject: [issue992389] attribute error due to circular import
Message-ID: <1318747695.29.0.72612354733.issue992389@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Changed the issue title to state clearly that the core issue is with circular imports that attempt to reference module contents at import time, regardless of the syntactic form used. All of the following module level code can fail due to this problem:

    from . import a

    from package import submodule

    from module import a

    import module
    module.a

----------
title: attribute error after non-from import -> attribute error due to circular import

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
_______________________________________

From report at bugs.python.org  Sun Oct 16 09:01:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 16 Oct 2011 07:01:30 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
In-Reply-To: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>
Message-ID: <E1RFKit-0001fe-MM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8365f82f8a13 by Raymond Hettinger in branch '3.2':
Issue 13177: Make tracebacks more readable by avoiding chained exceptions in the lru_cache.
http://hg.python.org/cpython/rev/8365f82f8a13

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Sun Oct 16 09:04:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Oct 2011 07:04:39 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
In-Reply-To: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>
Message-ID: <1318748679.42.0.269827089342.issue13177@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Sun Oct 16 09:18:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 16 Oct 2011 07:18:45 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318749525.21.0.911065268356.issue13153@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I would consider it preferable if it quit 

Note that if we catch the error there might be no reason for IDLE to quit (unless the error left IDLE in some invalid state).

> with an error traceback that gave as much info as available,

That might scare newbies away.

> or if there is none, just said "IDLE has met an unexpected problem.", 

So this might be better for all the cases.

> perhaps followed by something like "Pleaee note the circumstances and
> make a report of the tracker is there is none already."

The first message could offer a "Report the problem" option that links to the tracker.  In theory we could also have a way to auto-fill the tracker issue, but that might lead to duplicates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sun Oct 16 09:20:16 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 16 Oct 2011 07:20:16 +0000
Subject: [issue992389] attribute error due to circular import
Message-ID: <1318749616.16.0.554000581742.issue992389@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
_______________________________________

From report at bugs.python.org  Sun Oct 16 09:31:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 16 Oct 2011 07:31:10 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
In-Reply-To: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>
Message-ID: <1318750270.75.0.19800643355.issue13177@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

My comment was referring to double try/except suggested by Eric.  Indeed the if/else might lead to a race condition, and that's a good reason to avoid LBYL -- even if on average calling hash() twice might be faster.
I'm happy with the fix you committed, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Sun Oct 16 10:46:14 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Oct 2011 08:46:14 +0000
Subject: [issue13177] Avoid chained exceptions in lru_cache
In-Reply-To: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za>
Message-ID: <1318754774.31.0.712746426022.issue13177@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the bug report and for the test case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13177>
_______________________________________

From report at bugs.python.org  Sun Oct 16 15:50:31 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 16 Oct 2011 13:50:31 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <CACac1F8u-ZyaBPg8EbSTMCBVsFViJ_C2KEJ72q1OwF8PKWg3Mw@mail.gmail.com>
Message-ID: <CACac1F-TW-gUf29c3cvFqZxG9duoGysQVwfOW6yoSQN3MDwY7g@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

I found the problem - it's in packaging.util.write_record_file. The
file passed to csv.writer should be opened with newline=''.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Sun Oct 16 16:23:40 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 16 Oct 2011 14:23:40 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1318546022.2.0.0477576720396.issue13175@psf.upfronthosting.co.za>
Message-ID: <1318775020.9.0.372379295865.issue13175@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Here's a patch. It includes a test, but I don't expect the test will catch the issue except on Windows...

----------
keywords: +patch
Added file: http://bugs.python.org/file23416/recordfix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Sun Oct 16 16:29:53 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 16 Oct 2011 14:29:53 +0000
Subject: [issue13189] New bdist_simple binary distribution format for packaging
Message-ID: <1318775392.19.0.757483007173.issue13189@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

The attached patch is a first version of a bdist_simple binary distribution format for packaging. There is a bdist_simple command to build the distribution, and pysetup install has been updated to handle bdist_simple format distributions (only as local files, there is no support for discovering or downloading binary distributions at this point).

The patch still needs documentation and tests, but has been manually tested on Windows, for both Python and C distributions.

----------
assignee: tarek
components: Distutils2
files: bdist_simple.patch
keywords: patch
messages: 145621
nosy: alexis, eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: New bdist_simple binary distribution format for packaging
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23417/bdist_simple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13189>
_______________________________________

From report at bugs.python.org  Sun Oct 16 17:55:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 16 Oct 2011 15:55:00 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <E1RFT3B-0001BG-T7@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0a0aafaa9bf5 by Senthil Kumaran in branch 'default':
Fix closes issue 1673007 urllib.request to support HEAD requests with a new method arg.
http://hg.python.org/cpython/rev/0a0aafaa9bf5

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Sun Oct 16 17:56:59 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 16 Oct 2011 15:56:59 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1318780619.79.0.215874852902.issue1673007@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I have committed the patch accomodating the doc review comments which Ezio had mentioned. At the moment, the current way seems to be most backwards compatible one and did not want to delay it. Let's hope we get some feedback on this method arg. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Sun Oct 16 17:57:37 2011
From: report at bugs.python.org (poq)
Date: Sun, 16 Oct 2011 15:57:37 +0000
Subject: [issue12997] sqlite3: PRAGMA foreign_keys = ON doesn't work
In-Reply-To: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>
Message-ID: <1318780657.89.0.412033997343.issue12997@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

sqlite3.version_info = (2, 6, 0)
sqlite3.sqlite_version_info = (3, 7, 4)
pysqlite2.version_info = (2, 6, 0)
pysqlite2.sqlite_version_info = (3, 7, 4)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12997>
_______________________________________

From report at bugs.python.org  Sun Oct 16 18:30:30 2011
From: report at bugs.python.org (Mark Bucciarelli)
Date: Sun, 16 Oct 2011 16:30:30 +0000
Subject: [issue12997] sqlite3: PRAGMA foreign_keys = ON doesn't work
In-Reply-To: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>
Message-ID: <1318782630.3.0.806158400193.issue12997@psf.upfronthosting.co.za>


Mark Bucciarelli <mark at crosscutmedia.com> added the comment:

BAD : sqlite3.sqlite_version_info = (3, 6, 12)
GOOD: sqlite3.sqlite_version_info = (3, 7, 4)
GOOD: sqlite3.sqlite_version_info = (3, 7, 8)

I guess this is the cause of the different behavior.

sqlite_version_info is the version of the underlying sqlite3 database library.

So, the sqlite3 is loading an older dynamic lib on my OSX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12997>
_______________________________________

From report at bugs.python.org  Sun Oct 16 18:46:51 2011
From: report at bugs.python.org (Darren Dale)
Date: Sun, 16 Oct 2011 16:46:51 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1318783611.66.0.307329684783.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

It would be nice if this patch could be merged in time for python-3.3...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Oct 16 18:55:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Oct 2011 16:55:04 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1318609823.9.0.1814972478.issue10945@psf.upfronthosting.co.za>
Message-ID: <201110161855.59949.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The problem is that the config file is parsed using
> GetPrivateProfileString, and the result is then passed to TextOut,
> SetDlgItemText, CreateWindow, etc. all of which are defined to accept MBCS
> strings. I agree that this can't work correctly in the general case.

These functions are available with an Unicode API:

GetPrivateProfileStringW
TextOutW
SetDlgItemTextW
CreateWindowW
...

> Changing the GUI functions to operate on Unicode strings is certainly
> feasible and a good idea. The main challenge then is the format of the INI
> file. IIUC, GetPrivateProfileStringW is willing to process UTF-16 (with
> BOM) encoded INI files, but I never tested whether it actually does.

bdist_wininst creates a long Unicode string for the INI data, and then encode 
it explicitly:

        if isinstance(cfgdata, str):
            cfgdata = cfgdata.encode("mbcs")

So I suppose that replacing "mbcs" by "UTF-16-LE" and add the BOM should be 
enough.

> In porting wininst.exe, it seems tempting to use the TEXT family of APIs.
> I'd advise against that, and recommend to explicitly use the *W functions.

Do we need to keep backward compatibility if we change the format of the config 
data? Or wininst-xx.exe are only usable with trailing config data in the .exe 
file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Sun Oct 16 19:07:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 16 Oct 2011 17:07:37 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <E1RFUBT-0006Rj-3e@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e3c13a1d2595 by Victor Stinner in branch 'default':
Issue #10653: Fix time.strftime() on Windows, check for invalid format strings
http://hg.python.org/cpython/rev/e3c13a1d2595

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Sun Oct 16 19:09:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Oct 2011 17:09:11 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1318784951.79.0.62760573114.issue10653@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Crashes on the Windows buildbots:

Oops, it should be fixed by my last commits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Sun Oct 16 19:17:47 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 16 Oct 2011 17:17:47 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <201110161855.59949.victor.stinner@haypocalc.com>
Message-ID: <4E9B11B7.9090908@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Do we need to keep backward compatibility if we change the format of the config 
> data? Or wininst-xx.exe are only usable with trailing config data in the .exe 
> file?

The wininst.exe belongs to the version of distutils it is released with.
So if we change both consistently, no backwards-compatibility problems
arise.

----------
title: bdist_wininst depends on MBCS codec, unavailable on non-Windows -> bdist_wininst depends on MBCS codec,	unavailable on non-Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Sun Oct 16 19:39:20 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 16 Oct 2011 17:39:20 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1318786760.7.0.0498851651835.issue12406@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I also noticed that subdirectories in packaging/tests/ need to be added (e.g. fake_dists), otherwise packaging tests fail when run in an installed Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Sun Oct 16 19:47:52 2011
From: report at bugs.python.org (Noam Eliahu)
Date: Sun, 16 Oct 2011 17:47:52 +0000
Subject: [issue13190] ConfigParser uses wrong newline on Windows
Message-ID: <1318787272.4.0.221500033494.issue13190@psf.upfronthosting.co.za>


New submission from Noam Eliahu <noam.el at gmail.com>:

ConfigParser writes data to the config file using hard-coded newline: '\n'.
This newline is not suitable for Windows. Therefore, the config file isn't readable in Notepad.exe.

os.linesep should be used instead.

----------
components: None
messages: 145632
nosy: noam.el
priority: normal
severity: normal
status: open
title: ConfigParser uses wrong newline on Windows
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13190>
_______________________________________

From report at bugs.python.org  Sun Oct 16 21:23:11 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 16 Oct 2011 19:23:11 +0000
Subject: [issue13183] pdb skips frames after hitting a breakpoint and running
	step
In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za>
Message-ID: <1318792991.9.0.936151876658.issue13183@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Uploaded restore_trace_2.patch that improves the test case.

----------
Added file: http://bugs.python.org/file23418/restore_trace_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13183>
_______________________________________

From report at bugs.python.org  Sun Oct 16 21:24:30 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 16 Oct 2011 19:24:30 +0000
Subject: [issue13183] pdb skips frames after hitting a breakpoint and running
	step
In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za>
Message-ID: <1318793070.08.0.656814913136.issue13183@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Uploaded restore_trace.py27.patch with a fix and test case for python 2.7.

----------
Added file: http://bugs.python.org/file23419/restore_trace.py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13183>
_______________________________________

From report at bugs.python.org  Sun Oct 16 21:40:30 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 16 Oct 2011 19:40:30 +0000
Subject: [issue13153] IDLE crash with unicode bigger than 0xFFFF
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1318794030.19.0.867840883944.issue13153@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Just to be sure we're talking about the same thing here, my understanding is that the "missing traceback" issues referred to here are only an issue when IDLE is run as a stand-alone GUI program, such as can be done on Windows and with the OS X IDLE.app.  In that case, the standard Python tracebacks from the interpreter written to stderr are not readily visible to the user.  In the OS X IDLE.app case it does get captured in a system log. I'm not sure if that happens anywhere in the Windows cases.  If IDLE is started from a terminal window or console window where stderr is displayed, this is not an issue.

But I think further discussion about proposed improvements to IDLE diagnostics could be useful but it is not germane to the specific bug here.  It should be carried out elsewhere, possibly resulting in a feature request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sun Oct 16 22:07:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Oct 2011 20:07:05 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1318795625.93.0.787389937611.issue10653@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Sun Oct 16 22:09:04 2011
From: report at bugs.python.org (Mike Hoy)
Date: Sun, 16 Oct 2011 20:09:04 +0000
Subject: [issue13191] Typo in argparse documentation
Message-ID: <1318795744.19.0.406202573511.issue13191@psf.upfronthosting.co.za>


New submission from Mike Hoy <mhoy09 at gmail.com>:

In the Docs mailing list a typo was pointed out in argparse docs.

http://docs.python.org/dev/library/argparse.html#metavar

> "So, a single positional argument with dest='bar' will that argument 
> will be referred to as bar."

> "So, a single positional argument with dest='bar' WITH that argument 
> will be referred to as bar."

Eli Bendersky:

> I agree the original sentence makes little sense. But I'm not sure
> your correction fully fixes it either - "a single positional argument
> ... with that argument" doesn't sound right.

> Perhaps it should just say:

> "So, a single positional argument with dest='bar' will be referred to  > as bar" ?

Patch says "So,a single positional argument with dest='bar' will be referred to as bar"

----------
assignee: docs at python
components: Documentation
files: typo-argparse.diff
keywords: patch
messages: 145636
nosy: docs at python, mikehoy
priority: normal
severity: normal
status: open
title: Typo in argparse documentation
Added file: http://bugs.python.org/file23420/typo-argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13191>
_______________________________________

From report at bugs.python.org  Sun Oct 16 22:13:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Oct 2011 20:13:05 +0000
Subject: [issue13088] Add Py_hexdigits constant: use one unique constant to
	format a digit to hexadecimal
In-Reply-To: <1317511977.11.0.738521421258.issue13088@psf.upfronthosting.co.za>
Message-ID: <1318795985.19.0.406365615131.issue13088@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Antoine fixed the compilation issue.

http://hg.python.org/cpython/rev/c63087ac1f6c
changeset:   72941:c63087ac1f6c
user:        Antoine Pitrou <solipsis at pitrou.net>
date:        Sat Oct 15 16:38:20 2011 +0200

Fix build under Windows

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13088>
_______________________________________

From report at bugs.python.org  Sun Oct 16 22:14:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 16 Oct 2011 20:14:37 +0000
Subject: [issue13174] test_os failures on Fedora 15: listxattr() returns
	['security.selinux']
In-Reply-To: <1318541567.35.0.652639760355.issue13174@psf.upfronthosting.co.za>
Message-ID: <E1RFX6Q-00025u-T6@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 78c660a63960 by Victor Stinner in branch 'default':
Close #13174: Fix extended attributes tests in test_os for SELinux
http://hg.python.org/cpython/rev/78c660a63960

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13174>
_______________________________________

From report at bugs.python.org  Sun Oct 16 22:25:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Oct 2011 20:25:17 +0000
Subject: [issue13192] ImportError silences low-level OS errors
Message-ID: <1318796716.98.0.562997558521.issue13192@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Not sure this is by design or not, but I wanted to report this issue (it's rather hard to diagnose). Here the file descriptor limit is reached, and "import" raises an ImportError while it would be more helpful to let the original OS error slip through (which, here, is EMFILE):

>>> import resource
>>> resource.setrlimit(resource.RLIMIT_NOFILE, (2, 100))
>>> import encodings.idna
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'idna'
>>> resource.setrlimit(resource.RLIMIT_NOFILE, (100, 100))
>>> import encodings.idna
>>>

----------
components: Interpreter Core
messages: 145639
nosy: brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: ImportError silences low-level OS errors
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13192>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:09:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Oct 2011 21:09:26 +0000
Subject: [issue13192] ImportError silences low-level OS errors
In-Reply-To: <1318796716.98.0.562997558521.issue13192@psf.upfronthosting.co.za>
Message-ID: <1318799366.07.0.823683711487.issue13192@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

_Py_fopen() returns NULL without raising an exception if fopen() fails.

Attached patch raises a OSError if fopen() if errno is different than ENOENT. I don't know if ENOENT is the right error number on Windows. Should we ignore more error numbers, like EACCESS?

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file23421/fopen_err.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13192>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:16:05 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 16 Oct 2011 21:16:05 +0000
Subject: [issue13189] New bdist_simple binary distribution format for packaging
In-Reply-To: <1318775392.19.0.757483007173.issue13189@psf.upfronthosting.co.za>
Message-ID: <1318799765.72.0.0442733499231.issue13189@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

New patch including some basic tests.

----------
Added file: http://bugs.python.org/file23422/bdist_simple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13189>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:16:18 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 16 Oct 2011 21:16:18 +0000
Subject: [issue13189] New bdist_simple binary distribution format for packaging
In-Reply-To: <1318775392.19.0.757483007173.issue13189@psf.upfronthosting.co.za>
Message-ID: <1318799778.27.0.244852147686.issue13189@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


Removed file: http://bugs.python.org/file23417/bdist_simple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13189>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:19:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Oct 2011 21:19:14 +0000
Subject: [issue13192] ImportError silences low-level OS errors
In-Reply-To: <1318799366.07.0.823683711487.issue13192@psf.upfronthosting.co.za>
Message-ID: <1318799721.3242.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> _Py_fopen() returns NULL without raising an exception if fopen() fails.
> 
> Attached patch raises a OSError if fopen() if errno is different than
> ENOENT. I don't know if ENOENT is the right error number on Windows.

It seems so.

>  Should we ignore more error numbers, like EACCESS?

I suggest also ignoring ENOTDIR and EISDIR. Not sure about EACCES.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13192>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:24:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Oct 2011 21:24:53 +0000
Subject: [issue13193] test_packaging and test_distutils failures under Windows
Message-ID: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3593/steps/test/logs/stdio

----------
assignee: tarek
components: Distutils, Distutils2, Library (Lib), Tests
messages: 145643
nosy: alexis, eric.araujo, pitrou, tarek
priority: high
severity: normal
status: open
title: test_packaging and test_distutils failures under Windows
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:29:40 2011
From: report at bugs.python.org (=?utf-8?q?Simon_El=C3=A9n?=)
Date: Sun, 16 Oct 2011 21:29:40 +0000
Subject: [issue13194] zlib (de)compressobj copy() method missing on Windows
Message-ID: <1318800580.02.0.678946639591.issue13194@psf.upfronthosting.co.za>


New submission from Simon El?n <python at simon.user.lysator.liu.se>:

The zlib (de)compressobj copy() method is missing on Windows.

Tested on Python 2.7.2 and 3.2.2 Windows binaries. I have not tried to build from source.

(In the source code I can see a check for HAVE_ZLIB_COPY. Does the Windows binaries statically link the included zlib source? If so, it should be new enough to pass that check...)

----------
components: Library (Lib), Windows
messages: 145644
nosy: Simon.El?n
priority: normal
severity: normal
status: open
title: zlib (de)compressobj copy() method missing on Windows
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13194>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:34:17 2011
From: report at bugs.python.org (Mike Hoy)
Date: Sun, 16 Oct 2011 21:34:17 +0000
Subject: [issue11776] types.MethodType() params and usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1318800857.66.0.667946879917.issue11776@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:36:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Oct 2011 21:36:23 +0000
Subject: [issue13192] ImportError silences low-level OS errors
In-Reply-To: <1318796716.98.0.562997558521.issue13192@psf.upfronthosting.co.za>
Message-ID: <1318800983.89.0.916571298776.issue13192@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I suggest also ignoring ENOTDIR and EISDIR. Not sure about EACCES.

We should maybe mimick the io module:


>>> open('Lib')
IsADirectoryError: [Errno 21] Is a directory: 'Lib'

In the io module, opening a directory raises an exception. In the import machinery, an explicit check is done (stat+ISDIR) before opening the file. The file is ignored if it is a directory. We can maybe remove the test before opening the file, and handle IsADirectoryError exception instead.

--

I don't think that fopen() can fails with ENOTDIR. rmdir() can fail with ENOTDIR.

--

For EACCES: Python ignores currently these errors. I was already surprised by this behaviour. My use case: I have two users (haypo and fusil). I "installed" a module of haypo user into /usr/lib/python... using symlink, but fusil doesn't have access to /home/haypo. When fusil tries to load a module, import fails without any warning or error.

Fail with an error is maybe not a good idea because it's not because a directory of sys.path cannot be read, than the import will fail. The module can be found in another (accessible) directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13192>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:37:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Oct 2011 21:37:48 +0000
Subject: [issue13192] ImportError silences low-level OS errors
In-Reply-To: <1318800983.89.0.916571298776.issue13192@psf.upfronthosting.co.za>
Message-ID: <1318800834.3242.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't think that fopen() can fails with ENOTDIR.

According to POSIX:

[ENOTDIR]
    A component of the path prefix is not a directory, or the filename
argument contains at least one non- <slash> character and ends with one
or more trailing <slash> characters and the last pathname component
names an existing file that is neither a directory nor a symbolic link
to a directory.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13192>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:42:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Oct 2011 21:42:11 +0000
Subject: [issue13194] zlib (de)compressobj copy() method missing on Windows
In-Reply-To: <1318800580.02.0.678946639591.issue13194@psf.upfronthosting.co.za>
Message-ID: <1318801331.53.0.627606459244.issue13194@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis, nadeem.vawda
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13194>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:45:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 16 Oct 2011 21:45:15 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <E1RFYW8-0008IK-JG@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 977c5753ca32 by Victor Stinner in branch '3.2':
Issue #10653: Fix time.strftime() on Windows, check for invalid format strings
http://hg.python.org/cpython/rev/977c5753ca32

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Sun Oct 16 23:47:56 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 16 Oct 2011 21:47:56 +0000
Subject: [issue13194] zlib (de)compressobj copy() method missing on Windows
In-Reply-To: <1318800580.02.0.678946639591.issue13194@psf.upfronthosting.co.za>
Message-ID: <1318801676.62.0.238855507308.issue13194@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Confirmed for 3.3. I should be able to post a patch tomorrow.

----------
assignee:  -> nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13194>
_______________________________________

From report at bugs.python.org  Mon Oct 17 00:03:40 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 16 Oct 2011 22:03:40 +0000
Subject: [issue5875] test_distutils failing on OpenSUSE 10.3, Py3k
In-Reply-To: <1240991372.08.0.469372196929.issue5875@psf.upfronthosting.co.za>
Message-ID: <1318802620.36.0.23680736977.issue5875@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I temporarily changed the Fedora bot to run Fedora-14-i386. The
same failures can be observed:

======================================================================
ERROR: test_no_optimize_flag (distutils.tests.test_bdist_rpm.BuildRpmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/distutils/tests/test_bdist_rpm.py", line 121, in test_no_optimize_flag
    cmd.run()
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/distutils/command/bdist_rpm.py", line 365, in run
    self.spawn(rpm_cmd)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/distutils/cmd.py", line 366, in spawn
    spawn(cmd, search_path, dry_run=self.dry_run)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/distutils/spawn.py", line 32, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/distutils/spawn.py", line 163, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit status 1

======================================================================
ERROR: test_quiet (distutils.tests.test_bdist_rpm.BuildRpmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/distutils/tests/test_bdist_rpm.py", line 81, in test_quiet
    cmd.run()
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/distutils/command/bdist_rpm.py", line 365, in run
    self.spawn(rpm_cmd)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/distutils/cmd.py", line 366, in spawn
    spawn(cmd, search_path, dry_run=self.dry_run)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/distutils/spawn.py", line 32, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/distutils/spawn.py", line 163, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit status 1

----------------------------------------------------------------------
Ran 177 tests in 2.967s

----------
nosy: +skrah
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5875>
_______________________________________

From report at bugs.python.org  Mon Oct 17 01:01:05 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 Oct 2011 23:01:05 +0000
Subject: [issue415492] Compiler generates relative filenames
Message-ID: <1318806065.09.0.441157196829.issue415492@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's fairly easy to check this is still a problem:

$ ./python
Python 3.3.0a0 (default:a06ef7ab7321, Sep 22 2011, 13:41:29) 
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import setup
>>> setup.__file__
'setup.py'

That's a relative path rather than an absolute one. If you edit sys.path to use '.' instead of '', it becomes clear that the import machinery is just doing a blind join of the sys.path entry with the relative location of the file:

>>> del sys.modules['setup']
>>> sys.path[0] = '.'
>>> import setup
>>> setup.__file__
'./setup.py'

----------
nosy: +brett.cannon, ncoghlan
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue415492>
_______________________________________

From report at bugs.python.org  Mon Oct 17 01:29:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Oct 2011 23:29:46 +0000
Subject: [issue13032] h2py.py can fail with UnicodeDecodeError
In-Reply-To: <1316767061.34.0.367682305149.issue13032@psf.upfronthosting.co.za>
Message-ID: <1318807786.06.0.739508380718.issue13032@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using your patch, h2py.py skips all statements that cannot be decoded from UTF-8, whereas unpatched h2py.py accepts all statements that can be decoded from the locale encoding. I don't know if it is intentional to accept non-ASCII statements. It is maybe safer to ensure that a statement is encodable to ASCII using:

try:
    stmt.encode('ASCII')
    exec(stmt, env)
except:
    ...

Anyway, I would prefer to just drop this script with all Lib/plat-*/ directoes. I reopened this topic on python-dev (I already asked when I was working on the sys.platform=="linux3" issue: #12326).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13032>
_______________________________________

From report at bugs.python.org  Mon Oct 17 01:31:32 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 16 Oct 2011 23:31:32 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1318807892.06.0.0468471135423.issue12619@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Removed file: http://bugs.python.org/file22726/python-regenerate_platdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Mon Oct 17 01:32:33 2011
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 16 Oct 2011 23:32:33 +0000
Subject: [issue415492] Compiler generates relative filenames
Message-ID: <1318807953.05.0.64393363802.issue415492@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

The reason why this is a problem:

$ cat test.py
def foo():
    pass


>>> import test, os, inspect
>>> os.chdir('/')
>>> inspect.getsource(test)
'def foo():\n    pass\n'

But

>>> import test, os, inspect
>>> os.chdir('/')
>>> inspect.getsource(test)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: source code not available

----------
nosy: +aronacher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue415492>
_______________________________________

From report at bugs.python.org  Mon Oct 17 01:32:51 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 16 Oct 2011 23:32:51 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1318807971.5.0.975972290172.issue12619@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file23423/python-regenerate_platdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Mon Oct 17 02:08:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 00:08:00 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1318810080.99.0.644259095537.issue12619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> is auto-generation wanted?

For example, Lib/plat-linux/IN.py was regenerated at Nov 23 12:09:28 2002 (revision c2604d69aa5d) for the last time, and nobody complained. These modules are inconsistent. For example, the IN module contains constants of 64 bits platforms, whereas it can be used on 32 bits platforms.

In my opinion, we should just drop these modules with h2py.py, I (re)opened a thread on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Mon Oct 17 02:38:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Oct 2011 00:38:25 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <E1RFbDg-0001ny-NP@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fb886858024c by Mark Hammond in branch '2.7':
Issue #7833: Ext. modules built using distutils on Windows no longer get a manifest
http://hg.python.org/cpython/rev/fb886858024c

New changeset 9caeb7215344 by Mark Hammond in branch '3.2':
Issue #7833: Ext. modules built using distutils on Windows no longer get a manifest
http://hg.python.org/cpython/rev/9caeb7215344

New changeset 3073ef853647 by Mark Hammond in branch 'default':
Issue #7833: Ext. modules built using distutils on Windows no longer get a manifest
http://hg.python.org/cpython/rev/3073ef853647

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Mon Oct 17 02:41:21 2011
From: report at bugs.python.org (Mark Hammond)
Date: Mon, 17 Oct 2011 00:41:21 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1318812081.99.0.919800157665.issue7833@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

I pushed the changes to 2.7, 3.2 and 3.3.  I'm happy to help with distutils2/packaging but I'll need to do that later once I work out where to start :)  Therefore I'm not yet closing this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Mon Oct 17 02:53:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 00:53:29 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1318812809.87.0.402559707949.issue7475@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

What is the status of this issue?

rot13 codecs & friends were added back to Python 3.2 with {bytes,str}.(un)transform() methods: commit 7e4833764c88. Codecs were disabled because of surprising error messages before the release of Python 3.2 final: issue #10807, commit ff1261a14573. transform() and untransform() methods were also removed, I don't remember why/how exactly, maybe because new codecs were disabled.

So we have rot13 & friends in Python 3.2 and 3.3, but they cannot be used with the regular str.encode('rot13'), you have to write (for example):

>>> codecs.getdecoder('rot_13')('rot13')
('ebg13', 5)
>>> codecs.getencoder('rot_13')('ebg13')
('rot13', 5)

The major issue with {bytes,str}.(un)transform() is that we have only one registry for all codecs, and the registry was changed in Python 3 to ensure:
 * encode: str->bytes
 * decode: bytes->str

To implement str.transform(), we need another register. Marc-Andre suggested (msg96374) to add tags to codecs:
"""
.encode_input_types = (str,)
.encode_output_types = (bytes,)
.decode_input_types = (bytes,)
.decode_output_types = (str,)
"""

I'm still opposed to str->str (rot13) and bytes->bytes (hex, gzip, ...) operations using the codecs API. Developers have to use the right module. If the API of these modules is too complex, we should add helpers to these modules, but not to builtin types. Builtin types have to be and stay simple and well defined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Mon Oct 17 03:07:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 01:07:50 +0000
Subject: [issue8714] Delayed signals in the REPL on OpenBSD (possibly
	libpthread related)
In-Reply-To: <1273854364.73.0.120471958938.issue8714@psf.upfronthosting.co.za>
Message-ID: <1318813670.97.0.13010015923.issue8714@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8714>
_______________________________________

From report at bugs.python.org  Mon Oct 17 04:15:24 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 17 Oct 2011 02:15:24 +0000
Subject: [issue415492] Compiler generates relative filenames
Message-ID: <1318817724.57.0.998185505267.issue415492@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue415492>
_______________________________________

From report at bugs.python.org  Mon Oct 17 04:19:44 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 17 Oct 2011 02:19:44 +0000
Subject: [issue13192] ImportError silences low-level OS errors
In-Reply-To: <1318796716.98.0.562997558521.issue13192@psf.upfronthosting.co.za>
Message-ID: <1318817984.65.0.467424434361.issue13192@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13192>
_______________________________________

From report at bugs.python.org  Mon Oct 17 04:39:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Oct 2011 02:39:33 +0000
Subject: [issue415492] Compiler generates relative filenames
Message-ID: <1318819173.33.0.94083271908.issue415492@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue415492>
_______________________________________

From report at bugs.python.org  Mon Oct 17 06:22:14 2011
From: report at bugs.python.org (Phillip M. Feldman)
Date: Mon, 17 Oct 2011 04:22:14 +0000
Subject: [issue13185] Why does Python interpreter care about curvy quotes in
	comments?
In-Reply-To: <1318677962.38.0.0174023308327.issue13185@psf.upfronthosting.co.za>
Message-ID: <CAB2ViTZ2ZZnfueukZQ8yORQK7=nRJTFXZ3Hcju5QCT9TOfXPzg@mail.gmail.com>


Phillip M. Feldman <Phillip.M.Feldman at gmail.com> added the comment:

Hello Martin,

This is a fine example of the so-called "is-ought" controversy.  The error
message is indeed telling me exactly what the problem is, but the underlying
problem is that this scheme was poorly thought out.  Clearly, the stripping
of comments and the source decoding should both be done in a single pass,
and the source decoding should not be applied to the comments.

Phillip

On Sat, Oct 15, 2011 at 4:26 AM, Martin v. L?wis <report at bugs.python.org>wrote:

>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> The error message told you exactly what the problem is. Your source file
> does not conform to PEP 263. The PEP also explains why this applies to
> comments as well: because the entire file gets decoded according to the
> source encoding, and parsing (including determining what comments are) only
> starts afterwards.
>
> Closing the report as invalid.
>
> ----------
> nosy: +loewis
> resolution:  -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13185>
> _______________________________________
>

----------
nosy: +Phillip.M.Feldman at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13185>
_______________________________________

From report at bugs.python.org  Mon Oct 17 07:12:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 17 Oct 2011 05:12:18 +0000
Subject: [issue13185] Why does Python interpreter care about curvy quotes in
	comments?
In-Reply-To: <1318655905.33.0.141769881228.issue13185@psf.upfronthosting.co.za>
Message-ID: <1318828338.51.0.621616053229.issue13185@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In theory, with some encodings you can't even know where the line (and the comment) ends if you don't decode first.  Also it doesn't seem worth  to me changing the way files are parsed just for this use case.
Assuming you are using UTF-8 (and you should), you shouldn't have any problem with Python 3, since it opens files using UTF-8 by default.  It's anyway always better to be specific about the encoding you are using.

----------
nosy: +ezio.melotti
stage:  -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13185>
_______________________________________

From report at bugs.python.org  Mon Oct 17 07:28:33 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 17 Oct 2011 05:28:33 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1318829313.07.0.848603058907.issue12619@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1 on auto-building. The header needed may not be available on the build platform, if it is not normally needed to build Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Mon Oct 17 07:41:44 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 17 Oct 2011 05:41:44 +0000
Subject: [issue13185] Why does Python interpreter care about curvy quotes in
	comments?
In-Reply-To: <CAB2ViTZ2ZZnfueukZQ8yORQK7=nRJTFXZ3Hcju5QCT9TOfXPzg@mail.gmail.com>
Message-ID: <4E9BC014.80901@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 17.10.2011 06:22, schrieb Phillip Feldman:
> This is a fine example of the so-called "is-ought" controversy.

Wrong. This has nothing to do with desired and factual. A bug, by
definition, is a deviation from the specification. This is not a bug,
since it exactly follows the specification.

Now you may want to challenge the specification, which makes it a
feature request. However, given that the PEP was discussed in 2001,
you are about ten years late for that.

> underlying problem is that this scheme was poorly thought out.

I object this assessment. This very behavior was carefully considered
and deliberately chosen.

> Clearly, the stripping of comments and the source decoding should both be done in
> a single pass, and the source decoding should not be applied to the
> comments.

That's not clear at all. In general (i.e. for arbitrary encodings), it
is not possible to determine where the hash ("#") signs are in the input
without decoding. So you have to decode first.

In addition, it was a deliberate choice that the source encoding must be
consistent (i.e. all characters in the source must decode correctly),
even if that is not needed for parsing. This is like requiring colons
at the end of statements: they are not needed for parsing, but requiring
them improves the language.

Regards,
Martin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13185>
_______________________________________

From report at bugs.python.org  Mon Oct 17 07:44:42 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 17 Oct 2011 05:44:42 +0000
Subject: [issue13191] Typo in argparse documentation
In-Reply-To: <1318795744.19.0.406202573511.issue13191@psf.upfronthosting.co.za>
Message-ID: <1318830282.64.0.252662350581.issue13191@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13191>
_______________________________________

From report at bugs.python.org  Mon Oct 17 07:48:18 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 17 Oct 2011 05:48:18 +0000
Subject: [issue13183] pdb skips frames after hitting a breakpoint and running
	step
In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za>
Message-ID: <1318830498.17.0.0936825004579.issue13183@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13183>
_______________________________________

From report at bugs.python.org  Mon Oct 17 07:53:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Oct 2011 05:53:05 +0000
Subject: [issue13185] Why does Python interpreter care about curvy quotes in
	comments?
In-Reply-To: <1318655905.33.0.141769881228.issue13185@psf.upfronthosting.co.za>
Message-ID: <1318830785.64.0.218921536078.issue13185@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Martin and Ezio.
This report was correctly closed as invalid.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13185>
_______________________________________

From report at bugs.python.org  Mon Oct 17 08:19:11 2011
From: report at bugs.python.org (Mike Hoy)
Date: Mon, 17 Oct 2011 06:19:11 +0000
Subject: [issue11638] pysetup un sdist crashes with weird trace if version is
	unicode by accident
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1318832351.69.0.0524087788512.issue11638@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Oct 17 08:42:52 2011
From: report at bugs.python.org (Mike Hoy)
Date: Mon, 17 Oct 2011 06:42:52 +0000
Subject: [issue12944] Accept arbitrary files for packaging's upload command
In-Reply-To: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za>
Message-ID: <1318833772.52.0.77612011472.issue12944@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12944>
_______________________________________

From report at bugs.python.org  Mon Oct 17 09:36:17 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 17 Oct 2011 07:36:17 +0000
Subject: [issue8060] PEP 3101 string formatting missing engineering
	presentation type for floating point
In-Reply-To: <1267733568.91.0.590819765764.issue8060@psf.upfronthosting.co.za>
Message-ID: <1318836977.25.0.495599457987.issue8060@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8060>
_______________________________________

From report at bugs.python.org  Mon Oct 17 10:25:35 2011
From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 17 Oct 2011 08:25:35 +0000
Subject: [issue5289] ctypes.util.find_library does not work under Solaris
In-Reply-To: <1234858635.81.0.426092533899.issue5289@psf.upfronthosting.co.za>
Message-ID: <1318839935.75.0.334364525941.issue5289@psf.upfronthosting.co.za>


Changes by Maciej Blizi?ski <maciej.blizinski at gmail.com>:


----------
nosy: +automatthias

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5289>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:21:33 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Oct 2011 11:21:33 +0000
Subject: [issue13195] subprocess: args with shell=True is not documented on
	Windows
Message-ID: <1318850493.84.0.375275631996.issue13195@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

For UNIX, it is said that if shell=False then you need to pass `args` as a list (if you want to pass any parameters to executable). Is that true for Windows (and perhaps other platforms) as well?

Again, for UNIX it is said that with shell=True, and args is a list - every item except the first one is an argument to the shell itself. Is it the same on Windows?


It would be better to just give advice in `shell` parameter description to "pass args as a list with shell=False or else you'll lose params in Unix. If shell=True you need to pass args as a string, because list is needed only if you need to pass arguments to shell itself."

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 145662
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: subprocess: args with shell=True is not documented on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13195>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:24:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 11:24:20 +0000
Subject: [issue13195] subprocess: args with shell=True is not documented on
	Windows
In-Reply-To: <1318850493.84.0.375275631996.issue13195@psf.upfronthosting.co.za>
Message-ID: <1318850660.85.0.288673336677.issue13195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issues #7839, #8972 and #10197.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13195>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:27:21 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Oct 2011 11:27:21 +0000
Subject: [issue13196] subprocess: undocumented if shell=True is necessary to
	find executable in Windows PATH
Message-ID: <1318850841.68.0.83326141038.issue13196@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

The reason I ask is this changeset - http://code.google.com/p/spyderlib/source/detail?spec=svne5d86b685619a470d593aa5f9ee360ba60779bc1&r=323c6c697f045166e384cdc15803d40eebed0a2b - seems like without shell=True, subprocess.Popen is unable to find Mercurial executable in PATH.

----------
assignee: docs at python
components: Documentation
messages: 145664
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: subprocess: undocumented if shell=True is necessary to find executable in Windows PATH

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13196>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:30:51 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Oct 2011 11:30:51 +0000
Subject: [issue13196] subprocess: undocumented if shell=True is necessary to
	find executable in Windows PATH
In-Reply-To: <1318850841.68.0.83326141038.issue13196@psf.upfronthosting.co.za>
Message-ID: <1318851051.44.0.886757953068.issue13196@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Tracker is buggy - proper link to the changeset - http://bit.ly/qT1o4g

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13196>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:32:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 11:32:17 +0000
Subject: [issue13196] subprocess: undocumented if shell=True is necessary to
	find executable in Windows PATH
In-Reply-To: <1318850841.68.0.83326141038.issue13196@psf.upfronthosting.co.za>
Message-ID: <1318851137.59.0.458213447072.issue13196@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can't you merge this issue with #13195?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13196>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:40:23 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 17 Oct 2011 11:40:23 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1318851623.89.0.72266969787.issue12619@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Regeneration of platform-specific modules fixes concerns about their outdateness and architecture differences (32-bit vs 64-bit, big endian vs little endian).

Regeneration of given module could be performed only when corresponding header is available.

Eventually regeneration of platform-specific modules could be controlled by an option of `configure`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:41:11 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Oct 2011 11:41:11 +0000
Subject: [issue13197] subprocess: move shell arguments to a separate keyword
	param
Message-ID: <1318851671.68.0.276363356463.issue13197@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

subprocess.Popen(args, shell=shell) is implicitly inconsistent on Unix:
 1. when shell=False, the args should be a list or you'll lose program options
 2. when shell=True, the args should be a string or your program options will be passed to shell itself


I propose to make consistent behaviour - require args to be a list, and pass shell options in a separate shell_args keyword argument. If it not for python4, then perhaps it can be implemented in PopenShell() and PopenSystem() functions.

This will also require unification of behaviour across platforms.

----------
components: Library (Lib)
messages: 145669
nosy: techtonik
priority: normal
severity: normal
status: open
title: subprocess: move shell arguments to a separate keyword param

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13197>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:43:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 11:43:10 +0000
Subject: [issue13197] subprocess: move shell arguments to a separate keyword
	param
In-Reply-To: <1318851671.68.0.276363356463.issue13197@psf.upfronthosting.co.za>
Message-ID: <1318851790.21.0.150255341592.issue13197@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Did you read the issue #7839?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13197>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:46:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 11:46:48 +0000
Subject: [issue7317] Display full tracebacks when an error occurs
	asynchronously
In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>
Message-ID: <1318852008.76.0.570891719364.issue7317@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review
priority: high -> normal
stage: needs patch -> patch review
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7317>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:48:18 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Oct 2011 11:48:18 +0000
Subject: [issue13195] subprocess: args with shell=True is not documented on
	Windows
In-Reply-To: <1318850493.84.0.375275631996.issue13195@psf.upfronthosting.co.za>
Message-ID: <1318852098.08.0.171098744753.issue13195@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Looks like a can of worms. For now I'll be pretty fine if this stuff is at least properly documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13195>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:50:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 11:50:10 +0000
Subject: [issue13195] subprocess: args with shell=True is not documented on
	Windows
In-Reply-To: <1318850493.84.0.375275631996.issue13195@psf.upfronthosting.co.za>
Message-ID: <1318852210.99.0.414423218673.issue13195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> For now I'll be pretty fine if this stuff is at least
> properly documented.

Can you propose a document patch describing the current behaviour?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13195>
_______________________________________

From report at bugs.python.org  Mon Oct 17 13:50:46 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Oct 2011 11:50:46 +0000
Subject: [issue13196] subprocess: undocumented if shell=True is necessary to
	find executable in Windows PATH
In-Reply-To: <1318850841.68.0.83326141038.issue13196@psf.upfronthosting.co.za>
Message-ID: <1318852246.65.0.0134890582917.issue13196@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Although they both touch the same components, they are completely different user stories.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13196>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:01:58 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Oct 2011 12:01:58 +0000
Subject: [issue13195] subprocess: args with shell=True is not documented on
	Windows
In-Reply-To: <1318850493.84.0.375275631996.issue13195@psf.upfronthosting.co.za>
Message-ID: <1318852918.89.0.395085149566.issue13195@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Certainly not right now as I don't have development environment setup. Perhaps in a few days if somebody pings me. It could be a lot easier with online editor, of course - http://code.google.com/p/pydotorg/issues/detail?id=6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13195>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:12:15 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 17 Oct 2011 12:12:15 +0000
Subject: [issue13195] subprocess: args with shell=True is not documented on
	Windows
In-Reply-To: <1318850493.84.0.375275631996.issue13195@psf.upfronthosting.co.za>
Message-ID: <1318853535.01.0.495593493194.issue13195@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13195>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:12:30 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 17 Oct 2011 12:12:30 +0000
Subject: [issue13196] subprocess: undocumented if shell=True is necessary to
	find executable in Windows PATH
In-Reply-To: <1318850841.68.0.83326141038.issue13196@psf.upfronthosting.co.za>
Message-ID: <1318853550.93.0.517853951222.issue13196@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13196>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:12:36 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 17 Oct 2011 12:12:36 +0000
Subject: [issue13197] subprocess: move shell arguments to a separate keyword
	param
In-Reply-To: <1318851671.68.0.276363356463.issue13197@psf.upfronthosting.co.za>
Message-ID: <1318853556.28.0.337169657837.issue13197@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13197>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:18:02 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Oct 2011 12:18:02 +0000
Subject: [issue13197] subprocess: move shell arguments to a separate keyword
	param
In-Reply-To: <1318851671.68.0.276363356463.issue13197@psf.upfronthosting.co.za>
Message-ID: <1318853882.61.0.178372840153.issue13197@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

No. I won't be fixed in 2.7 anyway, and if it can not be fixed, it should be documented at least.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13197>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:21:59 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Oct 2011 12:21:59 +0000
Subject: [issue13197] subprocess: move shell arguments to a separate keyword
	param
In-Reply-To: <1318851671.68.0.276363356463.issue13197@psf.upfronthosting.co.za>
Message-ID: <1318854119.53.0.0914286038584.issue13197@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Oh, sorry - my attention span is limited under time pressure. #7839 is related, of course. There is a lot of comments, so I'll take a look at it later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13197>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:23:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 12:23:13 +0000
Subject: [issue13182] pysetup run bdist_wininst does not work (tries to use
	"install" command)
In-Reply-To: <1318616771.75.0.522951953738.issue13182@psf.upfronthosting.co.za>
Message-ID: <1318854193.86.0.0126127428317.issue13182@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13182>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:24:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 12:24:23 +0000
Subject: [issue13195] subprocess: args with shell=True is not documented on
	Windows
In-Reply-To: <1318850493.84.0.375275631996.issue13195@psf.upfronthosting.co.za>
Message-ID: <1318854263.1.0.735170960455.issue13195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Certainly not right now as I don't have development environment setup

See our development guide to get such environment:
http://docs.python.org/devguide/setup.html

> It could be a lot easier with online editor

Would like like to work on this project? (provide an online editor)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13195>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:29:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 12:29:54 +0000
Subject: [issue13151] pysetup3 run bdist_wininst fails
In-Reply-To: <1318331538.35.0.635641564623.issue13151@psf.upfronthosting.co.za>
Message-ID: <1318854594.84.0.658354069649.issue13151@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve patched most of bdist_wininst and started to work on a few tests which work under 2.7 and fail under 3.2 without the fixes so that I can assume I?ve not broken anything.

However, the mapping API of the Metadata class is quite unfriendly.  For example, if I try to replace metadata.long_description with metadata['description'], no exception will be raised if the metadata does not contain a description, it will return 'UNKNOWN'.  Code quickly becomes ugly.  I will open another report to ask Tarek to allow me to revamp the mapping API of Metadata so that code can be easier to write and read.

(I?m also removing the dependency on another bug that?s not really a blocker.)

----------
dependencies:  -Rename install_dist to install

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13151>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:31:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 12:31:49 +0000
Subject: [issue13151] pysetup3 run bdist_wininst fails
In-Reply-To: <1318331538.35.0.635641564623.issue13151@psf.upfronthosting.co.za>
Message-ID: <1318854709.0.0.825312699661.issue13151@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

To clarify: the part about the tests applies to distutils.  3.x fixes will then be ported to packaging.  Starting with successful tests in distutils 2.7 makes me feel more confident about editing distutils 3.x and packaging 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13151>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:33:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 12:33:11 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1295450896.02.0.86964827296.issue10945@psf.upfronthosting.co.za>
Message-ID: <1318854791.16.0.722905596814.issue10945@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Would the proposed change mean that a bdist_wininst built with 3.2.0 won?t work with a patched 3.2.3?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:35:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 12:35:22 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1318854922.85.0.755911692387.issue12703@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I would like to commit this.  Tests are needed.  Does someone want to write them?  Please ask any question you might have, we?re here to help :)

----------
stage: needs patch -> test needed
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:46:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 12:46:58 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318855618.45.0.634319941011.issue12405@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I'm not sure what you mean by "using". AFAIK, each distribution's files (recorded in RECORD)
> would be unique to that distribution (else distros like Debian will have problems, since
> files are owned by one package and one package only).
Files need to belong to one distribution only, but directories can be shared by more than one.  In my example, I meant that ProjectX can create the directories a and a/b and the file a/b/thing, then ProjectZ can create the file a/b/otherthing, and if we remove ProjectX and then ProjectZ, a and a/b won?t be in ProjectZ?s RECORD, because they were in ProjectX?s.

Carl: Can you tell us how pip removes directories?

> 1. Record any directories that are created in RECORD, ideally bottom-up.
To solve the problem I mentioned above (hopefully making sense this time :), we?d need to record all directories that would have been created.  It may be hard or even unfeasible to sort ?directory that existed before Python was installed?, e.g. /usr/lib/python2.7/site-packages, and ?directory created by one project?, e.g. /usr/lib/python2.7/site-packages/somelib.

----------
nosy: +carljm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:47:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 12:47:48 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318855668.21.0.494657082711.issue12405@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

s/directory that existed before Python was installed/directory that existed before any distribution was installed/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:48:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 12:48:25 +0000
Subject: [issue13181] pysetup install creates .pyc files but pysetup remove
	doesn't delete them
In-Reply-To: <1318615867.17.0.772590919076.issue13181@psf.upfronthosting.co.za>
Message-ID: <1318855705.92.0.676164071337.issue13181@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

That?s odd.  Are the pyc files in RECORD?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13181>
_______________________________________

From report at bugs.python.org  Mon Oct 17 14:57:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 12:57:07 +0000
Subject: [issue13193] test_packaging and test_distutils failures under Windows
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1318856227.83.0.472437571242.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The first failure looks like a bug in the manifest recursive-include code:

FAIL: test_process_template (distutils.tests.test_filelist.FileListTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "distutils\tests\test_filelist.py", line 181, in test_process_template
    self.assertEqual(file_list.files, ['d/b.py', 'd/d/e.py'])
AssertionError: Lists differ: [] != ['d/b.py', 'd/d/e.py']


The second one may be a sys.path issue:

ERROR: test_resources (packaging.tests.test_command_install_data.InstallDataTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "packaging\tests\test_command_install_data.py", line 129, in test_resources
    with packaging.database.get_file('Spamlib', 'spamd') as fp:
  File "packaging\database.py", line 649, in get_file
    return open(get_file_path(distribution_name, relative_path),
  File "packaging\database.py", line 644, in get_file_path
    raise LookupError('no distribution named %r found' % distribution_name)
LookupError: no distribution named 'Spamlib' found

The test creates a temporary directory which is inserted at the head of sys.path.  packaging.database.get_distribution should thus find Spamlib-0.1.dist-info.  Can someone with a Windows install help me with this?  Printing sys.path and os.listdir(sys.path[0]) would be a good start.

----------
nosy: +higery, jlove, pmoore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:07:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 13:07:28 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1318856848.26.0.123606545428.issue1673007@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Attached patch changes one occurrence of ugly whitespace, changes ?not x == y? to ?x != y? and ?not x in y? to ?x not in y?.  Senthil, feel free to apply none, some or all of these minor cleanups.

----------
Added file: http://bugs.python.org/file23424/urllib.request-cleanup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:12:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 13:12:34 +0000
Subject: [issue13198] Remove duplicate definition of write_record_file
Message-ID: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

We have duplicate code to write a PEP 376 RECORD file in packaging.util and packaging.command.install_distinfo.  The command should use the function from p7g.util.  Tests would also be good: Currently, one function uses LF as end of line (change made by Tarek, so authoritative) but the other uses os.linesep.

----------
assignee: eric.araujo
components: Distutils2
keywords: easy
messages: 145687
nosy: alexis, eric.araujo
priority: normal
severity: normal
stage: test needed
status: open
title: Remove duplicate definition of write_record_file
versions: 3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13198>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:15:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 13:15:12 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1318546022.2.0.0477576720396.issue13175@psf.upfronthosting.co.za>
Message-ID: <1318857312.51.0.756657160129.issue13175@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I found the problem - it's in packaging.util.write_record_file.
We have two functions that write RECORD files; I?ve opened a report to kill one.

> The file passed to csv.writer should be opened with newline=''.
How will we port this to 2.x?

> I don't expect the test will catch the issue except on Windows...
Do you mean that the test will fail or be a no-op on other OSes?  We can mark it as Windows-specific (@unittest.skipIf(sys.platform != 'win32', 'test only relevant on win32')) or just let it run if it?s harmless.  The important point is: does it fail before the fix, does it pass after?

----------
assignee: tarek -> eric.araujo
dependencies: +Remove duplicate definition of write_record_file
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:23:45 2011
From: report at bugs.python.org (Sven Marnach)
Date: Mon, 17 Oct 2011 13:23:45 +0000
Subject: [issue13199] slice_richcompare() might leak an object in rare cases
Message-ID: <1318857825.17.0.435087325593.issue13199@psf.upfronthosting.co.za>


New submission from Sven Marnach <sven at marnach.net>:

If exactly one of the two tuple allocations in [1] fails, the tuple that is successfully allocated won't be freed.  (This probably never happened.  Are you interested in this kind of bug report anyway?)

[1]: http://hg.python.org/cpython/file/f6b3ad301851/Objects/sliceobject.c#l349

----------
components: Interpreter Core
messages: 145689
nosy: smarnach
priority: normal
severity: normal
status: open
title: slice_richcompare() might leak an object in rare cases

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13199>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:26:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 13:26:20 +0000
Subject: [issue13172] Improve detection of availability of bdist_msi command
In-Reply-To: <1318531671.43.0.795221927422.issue13172@psf.upfronthosting.co.za>
Message-ID: <1318857980.75.0.521925834297.issue13172@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Arguably, the command shouldn't fail, it should simply omit the bdist_msi command from the listing.
> But as _msi is part of Python, the installation is broken if it isn't present so I guess that
> handling the issue gracefully isn't really important.
My first feeling was agreement with your request, but then you added that _msi is part of Python, so I?m not sure we should increase the code complexity for a non-issue.

> (I assume the missing _msi extension isn't an issue on Unix).
Yep, see Lib/packaging/command/__init__.py:

  # XXX this is crappy
  if os.name == 'nt':
      _COMMANDS['bdist_msi'] = 'packaging.command.bdist_msi.bdist_msi'

> it feels symptomatic of a general lack of clean error handling, which I think should be fixed :-(
I suppose the traceback would have been much more useful with #12703 fixed.  (There are a number of resolve_name-like functions out there, it?s sad to see it reimplemented with various degree in the quality of error reporting over and over again.)

Besides the problem with resolve_name, I think there?s a specific problem with bdist_msi.  As you can see with the comment I added in the code and quoted above, I?m not satisfied with the way we add bdist_msi to the set of available commands.  It?s the only command to be special-cased; I guess it can?t be helped, so maybe I should remove the comment.  I could change the conditional to register the command if _msi can be successfully imported; however, I fear this would hide bugs, as _msi is a part of a Python installation on Windows, so I?d rather continue to check os.name.  Would you be satisfied with a more helpful traceback that would point you immediately to missing msi?  Do you prefer that bdist_msi catch an ImportError for _msi and print a short error message instead of a traceback in all its glory?

----------
assignee: tarek -> eric.araujo
title: pysetup run --list-commands fails with a traceback -> Improve detection of availability of bdist_msi command
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13172>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:30:14 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 17 Oct 2011 13:30:14 +0000
Subject: [issue13199] slice_richcompare() might leak an object in rare cases
In-Reply-To: <1318857825.17.0.435087325593.issue13199@psf.upfronthosting.co.za>
Message-ID: <1318858214.85.0.337189814845.issue13199@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge
stage:  -> test needed
type:  -> resource usage
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13199>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:31:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 13:31:27 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1318858287.25.0.0275454263606.issue7833@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

To port the patch to packaging, go into your CPython 3.3 checkout and edit Lib/packaging/compiler/msvc9compiler.py (and its test :).

To port the patch to distutils2, clone http://hg.python.org/distutils2/ and edit distutils/compiler/msvc9compiler.py (same :).  Test with Python 2.4, 2.5, 2.6 and 2.7.  Then hg update python3, hg merge default, test with Python 3.1, 3.2 and 3.3.  Then you can push :)

If you don?t have the necessary Pythons or roundtuits, I?ll port the patch when I get a Windows VM.  There?s plenty of time before Python 3.3 is out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:31:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 13:31:54 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1318858314.51.0.180733778963.issue7833@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

s/distutils/distutils2/ !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:38:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 13:38:20 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1318858700.94.0.328838838557.issue7475@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> transform() and untransform() methods were also removed, I don't remember why/how exactly,
I don?t remember either; maybe it was too late in the release process, or we lacked enough consensus.

> So we have rot13 & friends in Python 3.2 and 3.3, but they cannot be used with the regular
> str.encode('rot13'), you have to write (for example): codecs.getdecoder('rot_13')
Ah, great, I thought they were not available at all!

> The major issue with {bytes,str}.(un)transform() is that we have only one registry for all
> codecs, and the registry was changed in Python 3 [...] To implement str.transform(), we need
> another register. Marc-Andre suggested (msg96374) to add tags to codecs
I?m confused: does the tags idea replace the idea of adding another registry?

> I'm still opposed to str->str (rot13) and bytes->bytes (hex, gzip, ...) operations using the
> codecs API. Developers have to use the right module.
Well, here I disagree with you and agree with MAL: str.encode and bytes.decode are strict, but the codec API in general is not restricted to str?bytes and bytes?str directions.  Using the zlib or base64 modules vs. the codecs is a matter of style; sometimes you think it looks hacky, sometimes you think it?s very handy.  And rot13 only exists as a codec!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:48:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 13:48:00 +0000
Subject: [issue11638] python setup.py sdist crashes if version is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1318859280.72.0.695005392684.issue11638@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I can?t reproduce with pysetup or distutils 3.x.

----------
components:  -Distutils2
title: pysetup un sdist crashes with weird trace if version is unicode by accident -> python setup.py sdist crashes if version is unicode
versions:  -3rd party, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:49:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 13:49:14 +0000
Subject: [issue11638] python setup.py sdist crashes if version is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1318859354.5.0.255862680344.issue11638@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Jens:
> Don't know it this is related to the usage of: from __future__ import
> unicode_literals ?
Yes.  This semi-magic import will turn your string literals into unicode literals, hence your name, version, etc. will be unicode objects.  It?s the same thing as writing version=u'1.0'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:54:42 2011
From: report at bugs.python.org (=?utf-8?q?R=C3=A9my_HUBSCHER?=)
Date: Mon, 17 Oct 2011 13:54:42 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1318859682.94.0.344033724229.issue12703@psf.upfronthosting.co.za>


R?my HUBSCHER <remy.hubscher at ionyse.com> added the comment:

Ok, I am working on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:58:17 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 17 Oct 2011 13:58:17 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1318859897.02.0.545815621637.issue7839@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Mon Oct 17 15:59:15 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 17 Oct 2011 13:59:15 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1318855668.21.0.494657082711.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318859951.81419.YahooMailNeo@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

>s/directory that existed before Python was installed/directory that existed before any distribution was installed/

IMO there is no need to remember any directory which isn't actually created by pysetup3. Deleting a __pycache__ in a directory created by pysetup3 would be implicit, and not need to be recorded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:00:59 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 17 Oct 2011 14:00:59 +0000
Subject: [issue13195] subprocess: args with shell=True is not documented on
	Windows
In-Reply-To: <1318850493.84.0.375275631996.issue13195@psf.upfronthosting.co.za>
Message-ID: <1318860059.57.0.0114269632897.issue13195@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13195>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:01:18 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 17 Oct 2011 14:01:18 +0000
Subject: [issue13196] subprocess: undocumented if shell=True is necessary to
	find executable in Windows PATH
In-Reply-To: <1318850841.68.0.83326141038.issue13196@psf.upfronthosting.co.za>
Message-ID: <1318860078.17.0.424567530309.issue13196@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13196>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:01:26 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 17 Oct 2011 14:01:26 +0000
Subject: [issue13197] subprocess: move shell arguments to a separate keyword
	param
In-Reply-To: <1318851671.68.0.276363356463.issue13197@psf.upfronthosting.co.za>
Message-ID: <1318860086.06.0.634644397776.issue13197@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13197>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:04:56 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 17 Oct 2011 14:04:56 +0000
Subject: [issue415492] Compiler generates relative filenames
Message-ID: <1318860296.49.0.99693174831.issue415492@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue415492>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:05:22 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 17 Oct 2011 14:05:22 +0000
Subject: [issue13192] ImportError silences low-level OS errors
In-Reply-To: <1318796716.98.0.562997558521.issue13192@psf.upfronthosting.co.za>
Message-ID: <1318860322.94.0.958196940964.issue13192@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13192>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:11:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 14:11:33 +0000
Subject: [issue13173] Default values for string.Template
In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>
Message-ID: <1318860693.4.0.119480702638.issue13173@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  It mostly looks good; a detailed review follow.
 
+   The constructor takes two arguments, the first is the template string and
+   the second (optional) is a dictionary object which specify which values
+   should be used as default values, if no provided.
Just say ?a dictionary?, or even ?a mapping?.  There?s also a grammar typo and a bit of redundancy, so I propose: ?is a mapping which gives default values?.  What do you think about adding a small example in the examples section later in the file?  It would probably be clearer than English.

       Like :meth:`substitute`, except that if placeholders are missing from
-      *mapping* and *kwds*, instead of raising a :exc:`KeyError` exception, the
-      original placeholder will appear in the resulting string intact.  Also,
-      unlike with :meth:`substitute`, any other appearances of the ``$`` will
-      simply return ``$`` instead of raising :exc:`ValueError`.
+      *mapping*, *kwds* and *default*, instead of raising a :exc:`KeyError`
default is not an argument, so *foo* markup is misleading.  Either use ?the default values given to the constructor? or just ?self.default?.

+      exception, the original placeholder will appear in the resulting string
+      intact.  Also, unlike with :meth:`substitute`, any other appearances of
+      the ``$`` will simply return ``$`` instead of raising :exc:`ValueError`.
If you don?t mind, I prefer if you have a few very short or too long lines if that helps reducing diff noise (i.e. lines that appear in the diff but are not changed, only rewrapped).

+   .. attribute:: default
+
+      This is the optional dictionary object passed to the constructor's
+      *template* argument.
I?m not a native English speaker, but ?passed to? seems wrong here (and in the other attribute?s doc).  I?d say ?passed as the *default* argument?.
 
-    def __init__(self, template):
+    def __init__(self, template, default={}):
Binding a mutable object to a local name at compile time is not good: All instances created without *default* argument will share the same dict, so editions to onetemplate.default will change anothertemplate.default too.  The common idiom is to use None as default value and add this:

        self.default = default if default is not None else {}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13173>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:12:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 14:12:20 +0000
Subject: [issue13173] Default values for string.Template
In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>
Message-ID: <1318860740.85.0.413872520149.issue13173@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adding Georg, maintainer of the string module, to the nosy list.  If he approves the idea, you can go ahead and complete your patch.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13173>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:28:59 2011
From: report at bugs.python.org (Paul Moore)
Date: Mon, 17 Oct 2011 14:28:59 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1318857312.51.0.756657160129.issue13175@psf.upfronthosting.co.za>
Message-ID: <CACac1F_oYSCgVhsY=v3r87x1A9jPaSYG1N9WEY7dPLY0gfNjJA@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

On 17 October 2011 14:15, ?ric Araujo <report at bugs.python.org> wrote:
>> The file passed to csv.writer should be opened with newline=''.
> How will we port this to 2.x?

No idea :-( The 2.7 documentation says use the 'b' flag, but that
probably doesn't allow an encoding parameter (it doesn't on 3.x).

>> I don't expect the test will catch the issue except on Windows...
> Do you mean that the test will fail or be a no-op on other OSes? ?We can mark it as Windows-specific (@unittest.skipIf(sys.platform != 'win32', 'test only relevant on win32')) or just let it run if it?s harmless. ?The important point is: does it fail before the fix, does it pass after?

The test fails before the fix, passes after. It's a no-op on platforms
where text and binary files are the same, (i.e., non-Windows systems).
So it's harmless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:29:00 2011
From: report at bugs.python.org (Sven Marnach)
Date: Mon, 17 Oct 2011 14:29:00 +0000
Subject: [issue13200] Add start, stop and step attributes to range objects
Message-ID: <1318861740.84.0.628710969686.issue13200@psf.upfronthosting.co.za>


New submission from Sven Marnach <sven at marnach.net>:

As discussed on python-ideas [1], range objects should expose their start, stop and step values as read-only data attributes.  I've attached a patch to this end.

I'll open a separate issue for range comparison.

[1]: http://mail.python.org/pipermail/python-ideas/2011-October/012356.html

----------
components: Interpreter Core
files: range-members
messages: 145701
nosy: smarnach
priority: normal
severity: normal
status: open
title: Add start, stop and step attributes to range objects
type: feature request
Added file: http://bugs.python.org/file23425/range-members

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13200>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:30:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 17 Oct 2011 14:30:11 +0000
Subject: [issue13200] Add start, stop and step attributes to range objects
In-Reply-To: <1318861740.84.0.628710969686.issue13200@psf.upfronthosting.co.za>
Message-ID: <1318861811.9.0.940362504276.issue13200@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review, patch
nosy: +ezio.melotti
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13200>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:39:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 14:39:42 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1318862382.04.0.961148503845.issue12344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No, thank you for contributing :)  I don?t know all internals by heart either, I just needed to step back from the patch and look hard at the tests to make them look good.

I didn?t say that the patch was finished by the way, I haven?t covered all combinations (getting a command already initialized or getting a never-created-before command, giving kwargs or not, what we discussed on IRC).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:44:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 14:44:42 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318862682.04.0.80174768618.issue12405@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> IMO there is no need to remember any directory which isn't actually
> created by pysetup3

I did not propose such a thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:47:48 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 17 Oct 2011 14:47:48 +0000
Subject: [issue13183] pdb skips frames after hitting a breakpoint and running
	step
In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za>
Message-ID: <1318862868.67.0.352110502914.issue13183@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13183>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:48:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 14:48:13 +0000
Subject: [issue13180] pysetup silently ignores invalid entries in setup.cfg
In-Reply-To: <1318614439.75.0.304667021355.issue13180@psf.upfronthosting.co.za>
Message-ID: <1318862893.44.0.669649797654.issue13180@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed.  Doc/packaging/setupcfg.rst defines that custom fields need to start with X-, so we can refuse everything that is not built-in and does not start with X-.  (I?m going toward error rather than warning.)

----------
assignee: tarek -> eric.araujo
keywords: +easy
nosy: +erik.bray
stage:  -> needs patch
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13180>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:52:54 2011
From: report at bugs.python.org (Sven Marnach)
Date: Mon, 17 Oct 2011 14:52:54 +0000
Subject: [issue13201] Implement comparison operators for range objects
Message-ID: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>


New submission from Sven Marnach <sven at marnach.net>:

It seems some sort of consensus on how to compare range objects has emerged from the python-ideas discussion on comparison of range objects [1].

The attached patch defines '==' and '!=' for range object equality based on the sequence of values they represent.  The other comparison operators are left NotImplemented.

[1]: http://mail.python.org/pipermail/python-ideas/2011-October/012376.html

----------
files: range-compare
messages: 145705
nosy: smarnach
priority: normal
severity: normal
status: open
title: Implement comparison operators for range objects
Added file: http://bugs.python.org/file23426/range-compare

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:54:02 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 17 Oct 2011 14:54:02 +0000
Subject: [issue13200] Add start, stop and step attributes to range objects
In-Reply-To: <1318861740.84.0.628710969686.issue13200@psf.upfronthosting.co.za>
Message-ID: <1318863242.88.0.953801826865.issue13200@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13200>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:54:40 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 17 Oct 2011 14:54:40 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1318863280.87.0.383929698526.issue13201@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
components: +Interpreter Core
nosy: +mark.dickinson
stage:  -> patch review
type:  -> feature request
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Mon Oct 17 16:58:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 14:58:39 +0000
Subject: [issue13200] Add start, stop and step attributes to range objects
In-Reply-To: <1318861740.84.0.628710969686.issue13200@psf.upfronthosting.co.za>
Message-ID: <1318863519.53.0.912423850561.issue13200@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I would add tests that check the read-only-ness.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13200>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:03:16 2011
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 17 Oct 2011 15:03:16 +0000
Subject: [issue13202] subprocess __exit__ attribute missing
Message-ID: <1318863796.84.0.712149290856.issue13202@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

There are a number of issues with subprocess and __exit__ , 12494 status fixed among them.

Program (which doesn't work as I had hoped, but that's not the issue):


'file p.py'

import subprocess as S

with S.Popen(('cat','-n',),shell=False,stdin=S.PIPE,stdout=S.PIPE,bufsize=1,universal_newlines=True) as p:
    p.stdin.write('these\n')
    print(p.stdout.readline())




Use:

$ python3 p.py

Traceback (most recent call last):
  File "p.py", line 5, in <module>
    print(p.stdout.readline())
KeyboardInterrupt
$
$ python p.py
Traceback (most recent call last):
  File "p.py", line 3, in <module>
    with S.Popen(('cat','-n',),shell=False,stdin=S.PIPE,stdout=S.PIPE,bufsize=1,universal_newlines=True) as p:
AttributeError: __exit__
$
$ python
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------
components: Interpreter Core, Library (Lib)
messages: 145707
nosy: LambertDW
priority: normal
severity: normal
status: open
title: subprocess __exit__ attribute missing
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13202>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:06:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 15:06:18 +0000
Subject: [issue13202] subprocess __exit__ attribute missing
In-Reply-To: <1318863796.84.0.712149290856.issue13202@psf.upfronthosting.co.za>
Message-ID: <1318863978.44.0.150535592603.issue13202@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Context management support was added in 3.2.  It is not supported in 2.7.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13202>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:12:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 15:12:15 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1318864335.71.0.0208292697793.issue11610@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I noticed this in an older message:

> test_abc.py prints deprecation warnings for abstractproperty. I'm not
> familiar with the protocol here, do we continue to include unit tests
> for deprecated features until they are removed?
We try to keep the test warning-free.  If your patch deprecates something, the tests should not use deprecated API, except in one method that tests the deprecation itself.  There are helpers in test.support and warnings to catch and inspect warnings.

3.3 is still months away; there?s time for your patch.  If nobody replies here, ping python-dev again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:14:22 2011
From: report at bugs.python.org (Sven Marnach)
Date: Mon, 17 Oct 2011 15:14:22 +0000
Subject: [issue13200] Add start, stop and step attributes to range objects
In-Reply-To: <1318861740.84.0.628710969686.issue13200@psf.upfronthosting.co.za>
Message-ID: <1318864462.89.0.583416671566.issue13200@psf.upfronthosting.co.za>


Sven Marnach <sven at marnach.net> added the comment:

Thanks, ?ric.  Added new version of the patch.  (Could I also edit the old one?)

----------
Added file: http://bugs.python.org/file23427/range-members.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13200>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:24:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 17 Oct 2011 15:24:43 +0000
Subject: [issue13200] Add start, stop and step attributes to range objects
In-Reply-To: <1318861740.84.0.628710969686.issue13200@psf.upfronthosting.co.za>
Message-ID: <1318865083.2.0.800237572509.issue13200@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

There's actually a similar proposal with a patch and a few comments in #9896.

----------
nosy: +durban, pitrou, rhettinger, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13200>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:27:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 17 Oct 2011 15:27:36 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1318865256.63.0.810688988465.issue9896@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #13200.

----------
nosy: +ezio.melotti -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:27:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 15:27:40 +0000
Subject: [issue11445] python.exe on OS X shared-llbrary build erroneously
	linked to MacPorts python library
In-Reply-To: <19830.44206.997189.286834@montanaro.dyndns.org>
Message-ID: <1318865260.7.0.187884949611.issue11445@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I'm not committing this yet though as this will affect all platforms
> that use Makefiles to build, and I'm not sure if this change save for
> all compilers we effectively support.
I can test with GCC on Debian (linux kernel); I don?t know if it would be easy to ask all buildbots to test your branch, if not you could call for volunteers on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11445>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:28:45 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 17 Oct 2011 15:28:45 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1318865325.58.0.912361256443.issue13201@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Nice patch!  I put some comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:31:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 17 Oct 2011 15:31:46 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1318865506.48.0.534919584906.issue13201@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review, patch
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:34:15 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 17 Oct 2011 15:34:15 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1318865655.08.0.14881025529.issue13201@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:36:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 15:36:51 +0000
Subject: [issue13190] ConfigParser uses wrong newline on Windows
In-Reply-To: <1318787272.4.0.221500033494.issue13190@psf.upfronthosting.co.za>
Message-ID: <1318865811.09.0.407534679298.issue13190@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> lukasz.langa
components: +Library (Lib) -None
nosy: +lukasz.langa
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13190>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:38:56 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 17 Oct 2011 15:38:56 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1318862682.04.0.80174768618.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318865933.41212.YahooMailNeo@web25804.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I did not propose such a thing.

Sorry, I misunderstood your reference to /usr/lib/python2.7/site-packages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:39:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 15:39:58 +0000
Subject: [issue13189] New bdist_simple binary distribution format for packaging
In-Reply-To: <1318775392.19.0.757483007173.issue13189@psf.upfronthosting.co.za>
Message-ID: <1318865998.68.0.841450910159.issue13189@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have to catch up with the discussion on python-dev.  I?ll also want the opinion from our Windows experts.  We still have time :)

----------
assignee: tarek -> 
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13189>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:41:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 15:41:46 +0000
Subject: [issue5875] test_distutils failing on OpenSUSE 10.3, Py3k
In-Reply-To: <1240991372.08.0.469372196929.issue5875@psf.upfronthosting.co.za>
Message-ID: <1318866106.42.0.19395280563.issue5875@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The patch from #11599 should let us get the full error message, for a start.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5875>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:43:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 15:43:35 +0000
Subject: [issue13191] Typo in argparse documentation
In-Reply-To: <1318795744.19.0.406202573511.issue13191@psf.upfronthosting.co.za>
Message-ID: <1318866215.34.0.726508979624.issue13191@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +bethard
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13191>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:50:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 15:50:24 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1318866624.24.0.292533607897.issue7839@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:53:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 15:53:36 +0000
Subject: [issue13011] Frozen programs require the original build directory in
	order to run.
In-Reply-To: <1316483091.36.0.96391936283.issue13011@psf.upfronthosting.co.za>
Message-ID: <1318866816.47.0.917739744611.issue13011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  In 2.7 and 3.2, Python initialization was changed to use the new sysconfig module, which depends on the sysconfig.cfg file.  freeze needs to special-case the sysconfig module in its detection code to include the cfg file.

Do you want to work on a patch?

----------
nosy: +eric.araujo
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13011>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:56:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 15:56:11 +0000
Subject: [issue13132] distutils sends non-RFC compliant HTTP request
In-Reply-To: <1318085788.89.0.459164084672.issue13132@psf.upfronthosting.co.za>
Message-ID: <1318866971.85.0.347543446931.issue13132@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

http://tools.ietf.org/html/rfc2616#section-3.7.1

> When in canonical form, media subtypes of the "text" type use CRLF as
> the text line break. HTTP relaxes this requirement and allows the
> transport of text media with plain CR or LF alone representing a line
> break when it is done consistently for an entire entity-body. HTTP
> applications MUST accept CRLF, bare CR, and bare LF as being
> representative of a line break in text media received via HTTP

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13132>
_______________________________________

From report at bugs.python.org  Mon Oct 17 17:58:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 15:58:40 +0000
Subject: [issue13144] Global Module Index link in the offline documentation is
	incorrect
In-Reply-To: <1318248968.6.0.0439422849007.issue13144@psf.upfronthosting.co.za>
Message-ID: <1318867120.9.0.40382907421.issue13144@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you clone the repository, build the doc with ?make html? as explained in http://docs.python.org/documenting/building and tell us if the bug is there?  If not, it?s specific to Debian or Ubuntu.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13144>
_______________________________________

From report at bugs.python.org  Mon Oct 17 18:03:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 16:03:31 +0000
Subject: [issue13202] subprocess __exit__ attribute missing
In-Reply-To: <1318863796.84.0.712149290856.issue13202@psf.upfronthosting.co.za>
Message-ID: <1318867411.47.0.797862773.issue13202@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

To clarify: Python 2.5 and higher support the with statement syntax, but not all classes that could benefit from it have the __enter__ and __exit__ methods.  So you don?t get a SyntaxError in Python 2.7 when you write ?with Popen(...)?, but you get an AttributeError because Popen in 2.7 does not do its part to support context management.  The built-in open function, on the contrary, supports with in 2.5 and higher.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13202>
_______________________________________

From report at bugs.python.org  Mon Oct 17 18:09:32 2011
From: report at bugs.python.org (=?utf-8?q?R=C3=A9my_HUBSCHER?=)
Date: Mon, 17 Oct 2011 16:09:32 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1318867772.2.0.182439926562.issue12703@psf.upfronthosting.co.za>


R?my HUBSCHER <remy.hubscher at ionyse.com> added the comment:

Here is the patch for the test case.

----------
hgrepos: +84
Added file: http://bugs.python.org/file23428/test_util.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Mon Oct 17 18:12:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 16:12:13 +0000
Subject: [issue13175] packaging uses wrong line endings in RECORD files on
	Windows
In-Reply-To: <1318546022.2.0.0477576720396.issue13175@psf.upfronthosting.co.za>
Message-ID: <1318867933.42.0.579952832378.issue13175@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>>> The file passed to csv.writer should be opened with newline=''.
>> How will we port this to 2.x?
> No idea :-( The 2.7 documentation says use the 'b' flag, but that
> probably doesn't allow an encoding parameter (it doesn't on 3.x).

Ah, I see that newline controls newline translation.  We use codecs.open in distutils2; I think it uses universal newlines mode.  We?ll figure it out, the important part is to have good tests.

> The test fails before the fix, passes after. It's a no-op on platforms
> where text and binary files are the same, (i.e., non-Windows systems).
> So it's harmless.

Great.  I?ll look at your patch and try to port it to distutils2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13175>
_______________________________________

From report at bugs.python.org  Mon Oct 17 18:14:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 16:14:42 +0000
Subject: [issue13200] Add start, stop and step attributes to range objects
In-Reply-To: <1318861740.84.0.628710969686.issue13200@psf.upfronthosting.co.za>
Message-ID: <1318868082.96.0.401894289894.issue13200@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> (Could I also edit the old one?)
If you want to remove the older version, follow the edit link on the right.  In case you don?t have the permissions, I?ll do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13200>
_______________________________________

From report at bugs.python.org  Mon Oct 17 18:14:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 16:14:58 +0000
Subject: [issue13200] Add start, stop and step attributes to range objects
In-Reply-To: <1318861740.84.0.628710969686.issue13200@psf.upfronthosting.co.za>
Message-ID: <1318868098.59.0.643423352662.issue13200@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23425/range-members.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13200>
_______________________________________

From report at bugs.python.org  Mon Oct 17 18:20:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Oct 2011 16:20:15 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318868415.98.0.346999516389.issue12405@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let me rephrase my example with real paths.

Python creates /usr/lib/python3.3/site-packages.  (I?ll call this $stdlib.)

pysetup3.3 install paste.script creates $stdlib/paste/script/ and files therein.  The paste and paste/script directories are recorded.

pysetup3.3 install PasteUtil creates $stdlib/paste/util/ and files therein.  Only the paste/script directory is recorded.

pysetup3.3 remove PasteScript deletes the $stdlib/paste/script dir, but not its parent, as it?s not empty after removing all files and dirs in PasteScript?s RECORD.

pysetup3.3 remove PasteUtil deletes the $stdlib/paste/util dir.

The $stdlib/paste directory is created by either distribution when it is installed, but if it?s recorded only by one of the distributions, then it can?t be removed when the other distribution is removed last.  This is the problem I?m seeing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Mon Oct 17 18:22:46 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 17 Oct 2011 16:22:46 +0000
Subject: [issue13195] subprocess: args with shell=True is not documented on
	Windows
In-Reply-To: <1318854263.1.0.735170960455.issue13195@psf.upfronthosting.co.za>
Message-ID: <CAPkN8xJOrfboM62NrSZ0st2UcfNsnCCFuATqmFz=fS_zO_8haA@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Mon, Oct 17, 2011 at 3:24 PM, STINNER Victor <report at bugs.python.org> wrote:
>
>> Certainly not right now as I don't have development environment setup
>
> See our development guide to get such environment:
> http://docs.python.org/devguide/setup.html

I know. There is better tool at
https://bitbucket.org/techtonik/devinabox but I have only 500Mb left
on my system drive and there are still more problems I need to handle.

>> It could be a lot easier with online editor
>
> Would like like to work on this project? (provide an online editor)

Do you mean would I like to work on it? Actually, I made a prototype
on AppEngine that waits for JS guru to tune CodeMirror interface. If
somebody is interested to help, I've just uploaded the code to
http://code.google.com/p/pydotorg/source/browse/?repo=doceditor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13195>
_______________________________________

From report at bugs.python.org  Mon Oct 17 18:55:28 2011
From: report at bugs.python.org (Sven Marnach)
Date: Mon, 17 Oct 2011 16:55:28 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1318870528.85.0.443289218516.issue13201@psf.upfronthosting.co.za>


Sven Marnach <sven at marnach.net> added the comment:

Mark, thanks for your comments.  Here's a new version of the patch, I answer on Rietveld.

----------
Added file: http://bugs.python.org/file23429/range-compare-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Mon Oct 17 18:57:59 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 17 Oct 2011 16:57:59 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1318868415.98.0.346999516389.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318870673.82885.YahooMailNeo@web25804.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Let me rephrase my example with real paths.

Okay, now I see what you're getting at.

> Python creates /usr/lib/python3.3/site-packages.? (I?ll call this $stdlib.)
> 
> pysetup3.3 install paste.script creates $stdlib/paste/script/ and files 
> therein.? The paste and paste/script directories are recorded.
> 
> pysetup3.3 install PasteUtil creates $stdlib/paste/util/ and files therein.? 
> Only the paste/script directory is recorded.

I think you mean "Only the paste/util directory is recorded."

> The $stdlib/paste directory is created by either distribution when it is 
> installed, but if it?s recorded only by one of the distributions, then it can?t 
> be removed when the other distribution is removed last.? This is the problem I?m 
> seeing.

Yes, it's a valid point. How about if you record all directories that you would create if they didn't exist, as well as those actually created? That way, you would record the paste directory under both distributions, but would only delete it when deleting the last distribution which uses it (paste/util in your example), because you're checking for emptiness (not including bytecode files and directories).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:02:26 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 17 Oct 2011 17:02:26 +0000
Subject: [issue13192] ImportError silences low-level OS errors
In-Reply-To: <1318796716.98.0.562997558521.issue13192@psf.upfronthosting.co.za>
Message-ID: <1318870946.5.0.55917483865.issue13192@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Are you suggesting raising the OSError (or something else) rather than an ImportError?  If so, would it make sense to chain the exception instead.  That way the existing code that expects ImportError continues to work, while still allowing access to the original error through __cause__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13192>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:10:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Oct 2011 17:10:38 +0000
Subject: [issue13199] slice_richcompare() might leak an object in rare cases
In-Reply-To: <1318857825.17.0.435087325593.issue13199@psf.upfronthosting.co.za>
Message-ID: <E1RFqhu-00039X-Qd@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 53c87a0275ab by Benjamin Peterson in branch '3.2':
plug possible refleak (closes #13199)
http://hg.python.org/cpython/rev/53c87a0275ab

New changeset 7bf70519795c by Benjamin Peterson in branch 'default':
merge 3.2 (#13199)
http://hg.python.org/cpython/rev/7bf70519795c

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13199>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:13:49 2011
From: report at bugs.python.org (Paul Moore)
Date: Mon, 17 Oct 2011 17:13:49 +0000
Subject: [issue13181] pysetup install creates .pyc files but pysetup remove
	doesn't delete them
In-Reply-To: <1318855705.92.0.676164071337.issue13181@psf.upfronthosting.co.za>
Message-ID: <CACac1F_h7wTH6PauGUCMP-MzPLZd9Y8cB9ur56KE_tPFhHG9QQ@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> That?s odd. ?Are the pyc files in RECORD?

Yes, but not in __pycache__ where they should be.

PS D:\Data\python-sample\python> type
D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RECORD
D:\Data\cpython\Lib\site-packages\hello.py,798c341fba13dcecba260e25d2b976b6,42
D:\Data\cpython\Lib\site-packages\hello.pyc,,
D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA,bcae83fd032d0c33cea5dc14a1ca1bc5,206
D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER,44e3fde05f3f537ed85831969acf396d,9
D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED,d41d8cd98f00b204e9800998ecf8427e,0
D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RECORD,,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13181>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:17:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Oct 2011 17:17:40 +0000
Subject: [issue13192] ImportError silences low-level OS errors
In-Reply-To: <1318870946.5.0.55917483865.issue13192@psf.upfronthosting.co.za>
Message-ID: <1318871626.3237.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Are you suggesting raising the OSError (or something else) rather than
> an ImportError?  If so, would it make sense to chain the exception
> instead.  That way the existing code that expects ImportError
> continues to work

Does any existing code rely on ImportError being raised when there's a
rare OS error of some sort?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13192>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:18:59 2011
From: report at bugs.python.org (Paul Moore)
Date: Mon, 17 Oct 2011 17:18:59 +0000
Subject: [issue13172] Improve detection of availability of bdist_msi command
In-Reply-To: <1318857980.75.0.521925834297.issue13172@psf.upfronthosting.co.za>
Message-ID: <CACac1F8Wp5S-wq=cMrOwj0tvSfifk9Q6=-iDxqJkxYbWfR=3YA@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> Would you be satisfied with a more helpful traceback that would point you immediately to missing msi? ?Do you prefer that bdist_msi
> catch an ImportError for _msi and print a short error message instead of a traceback in all its glory?

I'd be happy with a more explicit error. As you say, it's a broken
build so not worth worrying too much about, but it did take me quite a
while to work out what the problem was, including having to raise this
bug report. (The existing traceback doesn't even mention _msi).

So yes, a simple error would be ideal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13172>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:19:40 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 17 Oct 2011 17:19:40 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
In-Reply-To: <1318856848.26.0.123606545428.issue1673007@psf.upfronthosting.co.za>
Message-ID: <20111017171930.GA15434@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Eric, 

The changes suggested in the patch are good for readability, I
shall include them all. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:22:49 2011
From: report at bugs.python.org (bpoaugust)
Date: Mon, 17 Oct 2011 17:22:49 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1318872169.89.0.853680110481.issue10197@psf.upfronthosting.co.za>


bpoaugust <sebbaz+bpo at gmail.com> added the comment:

subprocess.getoutput does not currently work at all on Windows.
So it's not necessary to maintain backwards compatibility.

The following fix works for me on WinXP/Python 3.2.2.

Replace

    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') # line 613 of subprocess.py

with

    if mswindows:
        pipe = os.popen(cmd + ' 2>&1', 'r') # Windows does not support { }
    else:
        pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')

----------
nosy: +bpoaugust
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:27:37 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 17 Oct 2011 17:27:37 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <1318872457.93.0.227116715128.issue12367@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

test_errno fails quite often on FreeBSD:

======================================================================
FAIL: test_errno (test.test_select.SelectTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_select.py", line 35, in test_errno
    self.fail("exception not raised")
AssertionError: exception not raised

----------------------------------------------------------------------
Ran 4 tests in 11.132s

----------
nosy: +skrah
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:32:07 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 17 Oct 2011 17:32:07 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1318872727.96.0.712258373297.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

After disabling a bunch of services and skipping the tests that are
failing on the Windows buildbots, it seems that the failures I was
getting last week have disappeared. It looks like they were due to the
Windows search indexer preventing temp directories from being deleted... >_>

> I have imported xz-5.0.3 into the externals repository now.

I tried to test this out, but it looks like liblzma.a is missing from the
SVN repo. There should be files with that name in the bin_i486 and
bin_x86-64 directories.

Apart from this, is there anything else that needs to be done before this
change can be committed to the main repo?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:34:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Oct 2011 17:34:22 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za>
Message-ID: <E1RFr4s-0005LZ-Qp@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c16063765d3a by Antoine Pitrou in branch 'default':
Issue #13146: Writing a pyc file is now atomic under POSIX.
http://hg.python.org/cpython/rev/c16063765d3a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:35:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Oct 2011 17:35:03 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za>
Message-ID: <1318872903.5.0.343979094367.issue13146@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed now. Thanks for the reviews!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:39:38 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 17 Oct 2011 17:39:38 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <1318873178.85.0.0298560519452.issue12367@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Hmm, maybe this is a FreeBSD bug:

http://osdir.com/ml/freebsd-bugs/2011-03/msg00201.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:40:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Oct 2011 17:40:30 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1318873230.08.0.876439237143.issue12797@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Attached is a patch which adds dirfd= as a keyword argument.

Thanks. Although, on second thought, I'm not sure whether Amaury's idea (allowing a custom opener) is not better... Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:41:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Oct 2011 17:41:22 +0000
Subject: [issue13194] zlib (de)compressobj copy() method missing on Windows
In-Reply-To: <1318800580.02.0.678946639591.issue13194@psf.upfronthosting.co.za>
Message-ID: <E1RFrBe-0005zF-QZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 80f07777accd by Nadeem Vawda in branch '2.7':
Issue #13194: zlib.compressobj().copy() and zlib.decompressobj().copy() are now available on Windows.
http://hg.python.org/cpython/rev/80f07777accd

New changeset fc7ee478ed3b by Nadeem Vawda in branch '3.2':
Issue #13194: zlib.compressobj().copy() and zlib.decompressobj().copy() are now available on Windows.
http://hg.python.org/cpython/rev/fc7ee478ed3b

New changeset 80de33021488 by Nadeem Vawda in branch 'default':
Merge #13194: zlib.compressobj().copy() and zlib.decompressobj().copy() are now available on Windows.
http://hg.python.org/cpython/rev/80de33021488

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13194>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:50:35 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Oct 2011 17:50:35 +0000
Subject: [issue13203] Doc: say id() is only useful for existing objects
Message-ID: <1318873835.36.0.466865504792.issue13203@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Newbies too often do something like (3.2.2, )

>>> id(getattr(x, 'pop')) == id(x.pop)
True

and get confused by the (invalid) result, whereas

>>> a,b=getattr(x, 'pop'),x.pop
>>> id(a)==id(b)
False

works properly. I think we should add a sentence or two or three to the id() doc, such as

Since a newly created argument object is either destroyed or becomes inaccessible before the function returns, *id(obj)* is only useful and valid if *obj* exists prior to the call and therefore after its return.
The value of an expression such as *id(666)== id(667)* is arbitrary and meaningless. The id of the first int object might or might not be reused for the second one.

----------
assignee: docs at python
components: Documentation
messages: 145743
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Doc: say id() is only useful for existing objects
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13203>
_______________________________________

From report at bugs.python.org  Mon Oct 17 19:54:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Oct 2011 17:54:44 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <E1RFrOb-0007JJ-Qu@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f6b8e4226260 by Victor Stinner in branch 'default':
Issue #12367: Test test_select.test_errno() on FreeBSD
http://hg.python.org/cpython/rev/f6b8e4226260

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Mon Oct 17 20:13:10 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 17 Oct 2011 18:13:10 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <1318875190.39.0.882678649819.issue12367@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I'm not sure it's exactly the same FreeBSD bug as in kern/155606,
since I can also reproduce the test_errno failure --without-threads.

Seems good to skip the test though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Mon Oct 17 20:23:41 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 17 Oct 2011 18:23:41 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1318875821.58.0.166106227933.issue13201@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The new patch looks fine;  I'd still like to have the more explicit reference counting in range_hash (see replies on Rietveld).

A few more things:

- The patch needs a Misc/NEWS entry before committing;  it probably deserves a line in Doc/whatsnew/3.3.rst, too.

- The doc update should have a ".. versionchanged:: 3.3" note.

- Maybe the range_compare function could be renamed to something that makes it clearer it's just doing an equality comparison rather than a generalized comparison.  'range_equality_check'?  Or just 'range_equal' or 'range_equality'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Mon Oct 17 20:36:17 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 17 Oct 2011 18:36:17 +0000
Subject: [issue13203] Doc: say id() is only useful for existing objects
In-Reply-To: <1318873835.36.0.466865504792.issue13203@psf.upfronthosting.co.za>
Message-ID: <1318876577.62.0.553369339157.issue13203@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If we add something at all, it should be much shorter. After all, the current doc already states "unique during its lifetime".

----------
nosy: +georg.brandl, rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13203>
_______________________________________

From report at bugs.python.org  Mon Oct 17 20:37:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 18:37:02 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1318876622.45.0.601866463809.issue12568@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm -1 on using wcswidth, though.

When you write text into a console on Linux (e.g. displayed by gnome-terminal or konsole), I suppose that wcswidth() can be used to compute the width of a line. It would help to fix #2382.

Or do you think that wcswidth() gives the wrong result for this use case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Mon Oct 17 20:39:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 18:39:19 +0000
Subject: [issue12517] Large file support on Windows: sizeof(off_t) is 32 bits
In-Reply-To: <1310079250.24.0.0290880980981.issue12517@psf.upfronthosting.co.za>
Message-ID: <1318876759.59.0.851530530843.issue12517@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

changeset:   72869:32b1999410de
user:        Victor Stinner <victor.stinner at haypocalc.com>
date:        Tue Oct 11 22:45:02 2011 +0200
files:       Modules/_io/fileio.c
description:
Fix io.FileIO.readall() on Windows 64 bits

Use Py_off_t type (64 bits) instead of off_t (32 bits).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12517>
_______________________________________

From report at bugs.python.org  Mon Oct 17 20:44:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Oct 2011 18:44:01 +0000
Subject: [issue12454] mailbox: use ASCII to read/write .mh_sequences files
In-Reply-To: <1309451753.0.0.932089944066.issue12454@psf.upfronthosting.co.za>
Message-ID: <E1RFsAI-00044a-Bg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5ea81e4c58a7 by Victor Stinner in branch 'default':
Close #12454: The mailbox module is now using ASCII, instead of the locale
http://hg.python.org/cpython/rev/5ea81e4c58a7

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12454>
_______________________________________

From report at bugs.python.org  Mon Oct 17 20:44:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 18:44:44 +0000
Subject: [issue12454] mailbox: use ASCII to read/write .mh_sequences files
In-Reply-To: <1309451753.0.0.932089944066.issue12454@psf.upfronthosting.co.za>
Message-ID: <1318877084.38.0.954848202624.issue12454@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I kept Python 2.7 and 3.2 unchanged because I'm not completly sure that the fix is correct :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12454>
_______________________________________

From report at bugs.python.org  Mon Oct 17 20:44:49 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Oct 2011 18:44:49 +0000
Subject: [issue13203] Doc: say id() is only useful for existing objects
In-Reply-To: <1318873835.36.0.466865504792.issue13203@psf.upfronthosting.co.za>
Message-ID: <1318877089.48.0.380690767494.issue13203@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I gave a maximum addition. The first sentence may be enough (or even just the second half of it). What people do not get is that the lifetime of new arg objects is the duration of the function call -- and that the output of id for departed objects is uniquely useless and invalid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13203>
_______________________________________

From report at bugs.python.org  Mon Oct 17 20:45:17 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 17 Oct 2011 18:45:17 +0000
Subject: [issue13144] Global Module Index link in the offline documentation is
	incorrect
In-Reply-To: <1318248968.6.0.0439422849007.issue13144@psf.upfronthosting.co.za>
Message-ID: <1318877117.03.0.596913719534.issue13144@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

2.x docs are supposed to be built with Sphinx 0.6.x -- there the link is correct.

If Ubuntu chooses to ignore this and build with 1.0.x, they will have to include a patch fixing the link.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13144>
_______________________________________

From report at bugs.python.org  Mon Oct 17 20:45:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 18:45:19 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <1318877119.77.0.99673169112.issue12451@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, it should be enough :-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12451>
_______________________________________

From report at bugs.python.org  Mon Oct 17 20:45:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 18:45:48 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <1318877148.11.0.661583714924.issue12367@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: rejected -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Mon Oct 17 21:35:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 19:35:45 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1318880145.84.0.689400927183.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

mbcs6.patch: update patch to tip.

----------
Added file: http://bugs.python.org/file23430/mbcs6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Mon Oct 17 21:36:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 19:36:01 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1318880161.23.0.833247886819.issue12281@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22374/mbcs4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Mon Oct 17 21:36:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 19:36:03 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1318880163.66.0.423928995365.issue12281@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22389/mbcs5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Mon Oct 17 22:07:53 2011
From: report at bugs.python.org (Paul Moore)
Date: Mon, 17 Oct 2011 20:07:53 +0000
Subject: [issue13193] test_packaging and test_distutils failures under Windows
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1318882073.39.0.859532996802.issue13193@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

First one - the problem is in packaging.manifest._translate_pattern, which uses os.path.join on regex parts. That won't work on Windows where os.sep is a backslash, as the backslash is a RE metacharacter.

Actually, the file list seems to only use '/' as a path separator, so you can just use

    pattern_re = "^" + prefix_re + '/' + ".*" + pattern_re

Whether this is right or not depends on whether the test is correctly supplying the expected file list as always /-separated. I don't know enough to be certain on that. An alternative would be to use '[/\\]' in the above, to catch both / and \ separators. Technically wrong, but robust enough to do for now if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Oct 17 22:10:20 2011
From: report at bugs.python.org (Paul Moore)
Date: Mon, 17 Oct 2011 20:10:20 +0000
Subject: [issue13193] test_packaging and test_distutils failures under Windows
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1318882220.74.0.328416056177.issue13193@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

I'm not getting the second error on my home PC. As the failing buildbot is mine, I'll have a look on there to see if I can reproduce when I get the chance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Oct 17 22:43:00 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 17 Oct 2011 20:43:00 +0000
Subject: [issue5875] test_distutils failing on OpenSUSE 10.3, Py3k
In-Reply-To: <1240991372.08.0.469372196929.issue5875@psf.upfronthosting.co.za>
Message-ID: <1318884180.41.0.57068315332.issue5875@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

May be last report is not related to initial two years old . It seems to me it is introduced recently after some optimization related to creation of pyc files and this is not OpenSUSE related.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5875>
_______________________________________

From report at bugs.python.org  Mon Oct 17 23:14:45 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 17 Oct 2011 21:14:45 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1318886085.49.0.840377873957.issue12619@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Related :  #1565071 and #3990  . There is no reason to keep plat-xxx files if cannot be managed properly.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Mon Oct 17 23:31:22 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 17 Oct 2011 21:31:22 +0000
Subject: [issue12997] sqlite3: PRAGMA foreign_keys = ON doesn't work
In-Reply-To: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>
Message-ID: <1318887082.85.0.66590847928.issue12997@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Mark, you don't say what version of OS X or which Python you are using but, if you are using an Apple-supplied Python on 10.6 or 10.7 or if you are using python.org 64-bit/32-bit installers for 2.7 or 3.2, the Python standard library sqlite3 modules dynamically links to the system-supplied /usr/lib/libsqlite3.dylib.  On 10.6.8 Snow Leopard that is 3.6.12.  On Lion (10.7.2) that has been updated by Apple to 3.7.5.  (BTW, the most recent 32-bit-only python.org installers for 3.2.x and 2.7.x statically link a version of 3.7.4 sqlite3 in order to work on older versions of OS X which have much older or even no system versions of sqlite3.)

Can this issue be closed?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12997>
_______________________________________

From report at bugs.python.org  Mon Oct 17 23:46:08 2011
From: report at bugs.python.org (Carl Meyer)
Date: Mon, 17 Oct 2011 21:46:08 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318887968.4.0.601833274366.issue12405@psf.upfronthosting.co.za>


Carl Meyer <carl at dirtcircle.com> added the comment:

> Carl: Can you tell us how pip removes directories?

In short - pip would _love_ to have directories recorded as well as files, exactly as Vinay has proposed. We don't have that info (even the distutils --record option currently doesn't record directories, thus installed-files.txt doesn't contain directories), so we are reduced to some nasty things like referring to top-level.txt in order to avoid lots of empty directories hanging about, which in itself was the subject of recent controversy re Twisted's custom namespace packages implementation.

Please, let's have directories recorded in RECORD, and yes, if a directory would have been created but already existed, it should also be recorded (so that shared directories are in the RECORD file for both/all of the sharing distributions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Tue Oct 18 00:02:10 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 17 Oct 2011 22:02:10 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1318888930.95.0.114302398963.issue12619@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

What do you do for platforms like OS X where we support one set of binary files that contain multi-architecture C-files that can run as Intel-64, Intel-32 or PPC-32 on the same machine at user option at run time?  For example, the Apple-suppled system Python on OS X 10.6 has all three and you can use `arch` to specify which to run (PPC is emulated on the Intel machines supported by 10.6):

$ file /usr/bin/python2.6
/usr/bin/python2.6: Mach-O universal binary with 3 architectures
/usr/bin/python2.6 (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/python2.6 (for architecture i386):	Mach-O executable i386
/usr/bin/python2.6 (for architecture ppc7400):	Mach-O executable ppc

The static IN.py currently shipped in plat-darwin is misleading at best. And you can't improve the situation by regenerating at installation time.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Tue Oct 18 00:14:25 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 17 Oct 2011 22:14:25 +0000
Subject: [issue13204] sys.flags.__new__ crashes
Message-ID: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

It's not possible (by intention) to instantiate a new instance of sys.flags. This is achieved by setting the "tp_new" slot to NULL (in `_PySys_Init()`), after `PyType_Ready()` is called, which means that a slot wrapper is added to the type dict for the "tp_new" slot (because the slot != NULL at that time). The problem is now that if one calls `sys.flags.__new__` directly, a null pointer dereference occurs in `tp_new_wrapper()`.

Attached is a patch that fixes the crash and adds a test.

----------
files: sys_flags__new__crash.patch
keywords: patch
messages: 145763
nosy: Trundle
priority: normal
severity: normal
status: open
title: sys.flags.__new__ crashes
type: crash
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23431/sys_flags__new__crash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13204>
_______________________________________

From report at bugs.python.org  Tue Oct 18 00:15:01 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 17 Oct 2011 22:15:01 +0000
Subject: [issue13204] sys.flags.__new__ crashes
In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za>
Message-ID: <1318889701.63.0.561608698169.issue13204@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


Added file: http://bugs.python.org/file23432/sys_flags__new__crash_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13204>
_______________________________________

From report at bugs.python.org  Tue Oct 18 00:26:33 2011
From: report at bugs.python.org (Mark Bucciarelli)
Date: Mon, 17 Oct 2011 22:26:33 +0000
Subject: [issue12997] sqlite3: PRAGMA foreign_keys = ON doesn't work
In-Reply-To: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>
Message-ID: <1318890393.44.0.184735520478.issue12997@psf.upfronthosting.co.za>


Changes by Mark Bucciarelli <mark at crosscutmedia.com>:


----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12997>
_______________________________________

From report at bugs.python.org  Tue Oct 18 00:30:04 2011
From: report at bugs.python.org (bpoaugust)
Date: Mon, 17 Oct 2011 22:30:04 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1318890604.47.0.432666191633.issue10197@psf.upfronthosting.co.za>


bpoaugust <sebbaz+bpo at gmail.com> added the comment:

A better fix, which supports multiple windows commands:

    if mswindows:
        pipe = os.popen('( ' + cmd + ' ) 2>&1', 'r') # Windows uses () rather than { }
    else:
        pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')

This works with the command

subprocess.getoutput("echo before & python -V & echo after")

Note that python -V writes to stderr, so without the enclosing ( ) the version information is not captured.

----------
Added file: http://bugs.python.org/file23433/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Tue Oct 18 00:37:10 2011
From: report at bugs.python.org (bpoaugust)
Date: Mon, 17 Oct 2011 22:37:10 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1318891030.65.0.590820898103.issue10197@psf.upfronthosting.co.za>


Changes by bpoaugust <sebbaz+bpo at gmail.com>:


----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Tue Oct 18 00:41:28 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 17 Oct 2011 22:41:28 +0000
Subject: [issue13194] zlib (de)compressobj copy() method missing on Windows
In-Reply-To: <1318800580.02.0.678946639591.issue13194@psf.upfronthosting.co.za>
Message-ID: <1318891288.42.0.0399634547864.issue13194@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Fixed for 2.7, 3.2 and 3.3. Thanks for the bug report!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13194>
_______________________________________

From report at bugs.python.org  Tue Oct 18 00:48:01 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 17 Oct 2011 22:48:01 +0000
Subject: [issue12997] sqlite3: PRAGMA foreign_keys = ON doesn't work
In-Reply-To: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>
Message-ID: <1318891681.43.0.451930735591.issue12997@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12997>
_______________________________________

From report at bugs.python.org  Tue Oct 18 01:16:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 23:16:00 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1318893360.08.0.0875881822872.issue10197@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Tue Oct 18 01:50:06 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Oct 2011 23:50:06 +0000
Subject: [issue13203] Doc: say id() is only useful for existing objects
In-Reply-To: <1318873835.36.0.466865504792.issue13203@psf.upfronthosting.co.za>
Message-ID: <1318895406.18.0.0538633457055.issue13203@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think this is over-explaining an implementation detail and it makes the docs for id() harder to understand.

Possibly there can be a FAQ entry about identity but the id() function itself is no place to go into the quirks of when new objects are created or destroyed.

Also, "getting confused" is often a step in the learning process -- it can't be taken out entirely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13203>
_______________________________________

From report at bugs.python.org  Tue Oct 18 01:55:24 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Oct 2011 23:55:24 +0000
Subject: [issue13203] Doc: say id() is only useful for existing objects
In-Reply-To: <1318873835.36.0.466865504792.issue13203@psf.upfronthosting.co.za>
Message-ID: <1318895724.55.0.606115173331.issue13203@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13203>
_______________________________________

From report at bugs.python.org  Tue Oct 18 01:55:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Oct 2011 23:55:56 +0000
Subject: [issue13204] sys.flags.__new__ crashes
In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za>
Message-ID: <1318895756.85.0.714999260111.issue13204@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13204>
_______________________________________

From report at bugs.python.org  Tue Oct 18 02:15:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Oct 2011 00:15:43 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1318896943.24.0.1432955931.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 7 of my patch. This patch is ready for a review: I implemented all TODO.

Summary of the patch (of this issue):

 - fix mbcs encoding to handle correctly ignore & replace error handlers on all Windows version
 - the mbcs encoding now supports any error handler (not only ignore and/or replace to encode/decode)
 - Add codecs.code_page_encode() and codecs.code_page_decode()

With the patch, Python 3.3 will give different results than Python 3.2 with replace and ignore error handlers (which was required to fix bugs). I consider that the new behaviour is more correct than the previous behaviour. It doesn't use Windows "replace" mode which is different than Python "replace" mode.

codecs.code_page_encode() and codecs.code_page_decode() are currently used for unit tests, but they can be used to implement the cp65001 encoding in Python (or any other Windows code page). This encoding is regulary asked for: see issues #6058, #7441 and #10920.

Changes between since the patch version 6:

 - handle multibyte encodings (cp932 and CP_UTF8)
 - the "replace" error handler doesn't use Windows replace and ignore modes. Use Windows strict mode and replace undecodable bytes by '?'. This change removes some differencies between Windows versions (in some corner cases).
 - add more checks for integer overflow
 - add more tests

I only tried my patch on Windows Seven.

--

The codec works byte per byte / character per character if the stringcannot be decoded/encoded in strict mode, so handling errors (with an error handler different than strict) can be slow. I didn't implement optimizations suggested by Martin. Since the patch has a long test suite, it may be possible to implement it later.

--

The patch doesn't expose custom options (MB_COMPOSITE, MB_PRECOMPOSED, MB_USEGLYPHCHARS, ...). I consider that Python builtin error handlers (strict, ignore, replace, backslashreplace, ...) are enough.

--

I deferred my idea of decoding bytes filenames from the ANSI code page in posixmodule.c (and patch Python os.fsencode/fsdecode functions). I should be discussed in another issue.

----------
Added file: http://bugs.python.org/file23434/mbcs7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Tue Oct 18 02:21:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Oct 2011 00:21:50 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1318897310.74.0.405735020807.issue12281@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file23430/mbcs6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Tue Oct 18 03:03:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 18 Oct 2011 01:03:15 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1318899795.74.0.542218559632.issue12281@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Tue Oct 18 03:41:31 2011
From: report at bugs.python.org (David Barnett)
Date: Tue, 18 Oct 2011 01:41:31 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1318902091.43.0.733163867562.issue8668@psf.upfronthosting.co.za>


Changes by David Barnett <davidbarnett2 at gmail.com>:


----------
nosy: +mu_mind

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Oct 18 03:53:53 2011
From: report at bugs.python.org (David Barnett)
Date: Tue, 18 Oct 2011 01:53:53 +0000
Subject: [issue13205] NameErrors in generated setup.py (codecs,
	split_multiline)
Message-ID: <1318902833.17.0.0898413636747.issue13205@psf.upfronthosting.co.za>


New submission from David Barnett <davidbarnett2 at gmail.com>:

The setup.py file currently generated by "pysetup generate-setup" fails to import the "codecs" module, and also uses a split_multiline function from distutils2/utils.py that's undefined in the setup script.

----------
assignee: tarek
components: Distutils2
files: fix_nameerrors.patch
keywords: patch
messages: 145768
nosy: alexis, eric.araujo, mu_mind, tarek
priority: normal
severity: normal
status: open
title: NameErrors in generated setup.py (codecs, split_multiline)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23435/fix_nameerrors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13205>
_______________________________________

From report at bugs.python.org  Tue Oct 18 04:11:10 2011
From: report at bugs.python.org (antitree)
Date: Tue, 18 Oct 2011 02:11:10 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1318903870.0.0.585362623288.issue1757072@psf.upfronthosting.co.za>


antitree <antitree at gmail.com> added the comment:

I'm still affected by this issue. A workaround or patch would be appreciated.

----------
nosy: +antitree

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_______________________________________

From report at bugs.python.org  Tue Oct 18 04:41:58 2011
From: report at bugs.python.org (David Barnett)
Date: Tue, 18 Oct 2011 02:41:58 +0000
Subject: [issue11638] python setup.py sdist crashes if version is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1318905718.09.0.830154508546.issue11638@psf.upfronthosting.co.za>


David Barnett <davidbarnett2 at gmail.com> added the comment:

I'm getting this exact error when I run "python setup.py sdist", no matter what I do. Even if I just create a new project, type "1.0.0" for version, type "a" in all the other fields, and say "no" to every question; then run "pysetup generate-setup" and "python setup.py sdist".

----------
nosy: +mu_mind

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Tue Oct 18 06:57:34 2011
From: report at bugs.python.org (David Barnett)
Date: Tue, 18 Oct 2011 04:57:34 +0000
Subject: [issue13170] distutils2 test failures
In-Reply-To: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>
Message-ID: <1318913854.95.0.0137442598483.issue13170@psf.upfronthosting.co.za>


David Barnett <davidbarnett2 at gmail.com> added the comment:

I looked into the ConfigTestCase.test_config failure, and it looks like it just needs the righthand edited to match the left. "package_data" lines are supposed to allow comma-separated lists of paths on the righthand.

----------
nosy: +mu_mind

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Tue Oct 18 07:35:28 2011
From: report at bugs.python.org (David Barnett)
Date: Tue, 18 Oct 2011 05:35:28 +0000
Subject: [issue13170] distutils2 test failures
In-Reply-To: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>
Message-ID: <1318916128.28.0.807192892767.issue13170@psf.upfronthosting.co.za>


David Barnett <davidbarnett2 at gmail.com> added the comment:

The ConfigTestCase.test_parse_extensions_in_config failure is a manifestation of http://bugs.python.org/issue6988.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Tue Oct 18 07:58:12 2011
From: report at bugs.python.org (bugs-python@vendor.thewrittenword.com)
Date: Tue, 18 Oct 2011 05:58:12 +0000
Subject: [issue10320] printf %qd is nonstandard
In-Reply-To: <1288946289.37.0.37131892978.issue10320@psf.upfronthosting.co.za>
Message-ID: <1318917492.82.0.181265433627.issue10320@psf.upfronthosting.co.za>


bugs-python at vendor.thewrittenword.com <bugs-python at vendor.thewrittenword.com> added the comment:

Objects/stringobject.c already does something similar:
                else if (longlongflag)
                    sprintf(s, "%" PY_FORMAT_LONG_LONG "d",
                        va_arg(vargs, PY_LONG_LONG));
so it makes sense to do the same in Modules/_ctypes/callproc.c.

----------
nosy: +bugs-python at vendor.thewrittenword.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10320>
_______________________________________

From report at bugs.python.org  Tue Oct 18 08:01:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 18 Oct 2011 06:01:04 +0000
Subject: [issue10320] printf %qd is nonstandard
In-Reply-To: <1288946289.37.0.37131892978.issue10320@psf.upfronthosting.co.za>
Message-ID: <1318917664.7.0.13024797628.issue10320@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10320>
_______________________________________

From report at bugs.python.org  Tue Oct 18 08:23:09 2011
From: report at bugs.python.org (Phillip M. Feldman)
Date: Tue, 18 Oct 2011 06:23:09 +0000
Subject: [issue13185] Why does Python interpreter care about curvy quotes in
	comments?
In-Reply-To: <1318830785.64.0.218921536078.issue13185@psf.upfronthosting.co.za>
Message-ID: <CAB2ViTYr79Ss7WgrDiLeMKP4wwp8Pm2t7WftpScxh2sO8e1TYw@mail.gmail.com>


Phillip M. Feldman <Phillip.M.Feldman at gmail.com> added the comment:

I'm beginning to understand the reasoning.  This is quite a bit more complex
than I initially thought, and I appreciate the explanations.

Phillip

On Sun, Oct 16, 2011 at 10:53 PM, Raymond Hettinger
<report at bugs.python.org>wrote:

>
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
>
> I concur with Martin and Ezio.
> This report was correctly closed as invalid.
>
> ----------
> nosy: +rhettinger
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13185>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13185>
_______________________________________

From report at bugs.python.org  Tue Oct 18 08:31:14 2011
From: report at bugs.python.org (R Blackmore)
Date: Tue, 18 Oct 2011 06:31:14 +0000
Subject: [issue13206] while loop vs for loop test
Message-ID: <1318919474.2.0.667717683099.issue13206@psf.upfronthosting.co.za>


New submission from R Blackmore <squank77 at yahoo.com>:

Using Python 3.2.2 on Windows 7

See attached file
Was having problem with a program I was doing... couldn't get around issue unless I changed from "while" loop to "for" loop... WTF???
 
So restarted computer and then Python Shell and IDLE I wrote a very simple loop file... The 1st loop is a while loop that hangs and only prints divisor 1 and divisor 2 (Should also print divisor 5)

For loop works as expected printing
divisor 1
divisor 2
divisor 3

Unless I'm missing something both loops should return (i.e. print) same!

Cheers

----------
components: IO
files: LOOP_Test1.py
messages: 145775
nosy: JavaJunkie
priority: normal
severity: normal
status: open
title: while loop vs for loop test
versions: Python 3.2
Added file: http://bugs.python.org/file23436/LOOP_Test1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13206>
_______________________________________

From report at bugs.python.org  Tue Oct 18 08:36:26 2011
From: report at bugs.python.org (R Blackmore)
Date: Tue, 18 Oct 2011 06:36:26 +0000
Subject: [issue13206] while loop vs for loop test
In-Reply-To: <1318919474.2.0.667717683099.issue13206@psf.upfronthosting.co.za>
Message-ID: <1318919786.44.0.786646241763.issue13206@psf.upfronthosting.co.za>


R Blackmore <squank77 at yahoo.com> added the comment:

for loop works correctly

prints

divisor 1
divisor 2
divisor 5 (original post incorrectly listed divisor 3,)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13206>
_______________________________________

From report at bugs.python.org  Tue Oct 18 09:13:33 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 18 Oct 2011 07:13:33 +0000
Subject: [issue13206] while loop vs for loop test
In-Reply-To: <1318919474.2.0.667717683099.issue13206@psf.upfronthosting.co.za>
Message-ID: <1318922013.03.0.657593710264.issue13206@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Your 'i = i + 1' is at the wrong indentation level.

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13206>
_______________________________________

From report at bugs.python.org  Tue Oct 18 09:49:16 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 18 Oct 2011 07:49:16 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1318876622.45.0.601866463809.issue12568@psf.upfronthosting.co.za>
Message-ID: <4E9D2F78.20807@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> I'm -1 on using wcswidth, though.
> 
> When you write text into a console on Linux (e.g. displayed by
> gnome-terminal or konsole), I suppose that wcswidth() can be used to
> compute the width of a line. It would help to fix #2382.
> 
> Or do you think that wcswidth() gives the wrong result for this use
> case?

No, I think that using it is not necessary. If you want to compute the
width of a line, use unicodedata.east_asian_width. And yes, wcswidth
may sometimes produce "incorrect" results (although it's probably
correct most of the time).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Tue Oct 18 10:17:58 2011
From: report at bugs.python.org (R Blackmore)
Date: Tue, 18 Oct 2011 08:17:58 +0000
Subject: [issue13206] while loop vs for loop test
In-Reply-To: <1318922013.03.0.657593710264.issue13206@psf.upfronthosting.co.za>
Message-ID: <1318925874.83272.YahooMailClassic@web39409.mail.mud.yahoo.com>


R Blackmore <squank77 at yahoo.com> added the comment:

I knew it was late...

Should have slept on it

Thanks

--- On Tue, 10/18/11, Mark Dickinson <report at bugs.python.org> wrote:

> From: Mark Dickinson <report at bugs.python.org>
> Subject: [issue13206] while loop vs for loop test
> To: squank77 at yahoo.com
> Date: Tuesday, October 18, 2011, 12:13 AM
> 
> Mark Dickinson <dickinsm at gmail.com>
> added the comment:
> 
> Your 'i = i + 1' is at the wrong indentation level.
> 
> ----------
> nosy: +mark.dickinson
> resolution:? -> invalid
> status: open -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13206>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13206>
_______________________________________

From report at bugs.python.org  Tue Oct 18 10:25:57 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 18 Oct 2011 08:25:57 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1318926357.56.0.330697503707.issue12174@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Should there be another issue opened to do something about the extra logging levels?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Tue Oct 18 10:29:08 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 18 Oct 2011 08:29:08 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1318926548.31.0.411930882891.issue4431@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I need Python compiled with Visual Studio 2010 because I use it embedded in an application compiled with Visual Studio 2010.

I am pretty sure there are quite a lot of people who would like to compile Python with this compiler.

I have compiled Python 2.7.2 with this version of the compiler as well as many extensions, but this required to patch quite a few things. I also intend to setup a buildbot running Python tests using this compiler.

If I can provide the patch to support Visual Studio 2010 and setup a builtbot that will pass most of the tests, could we get Python supported on this platform?

I intended to announce all of that on python-dev soon, but the buildbot is not quite ready yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Tue Oct 18 10:32:11 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 18 Oct 2011 08:32:11 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1318926731.27.0.357242047922.issue12277@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

?ric: It's been 3 months now. Have you already committed the big documentation issues change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Tue Oct 18 10:40:33 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 18 Oct 2011 08:40:33 +0000
Subject: [issue868845] Need unit tests for <...> reprs
Message-ID: <1318927233.38.0.998351744049.issue868845@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Ping? I wonder whether closing an issue from 2004 would result in "Achievement unlocked: archaeological issue management"

----------
keywords: +patch
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue868845>
_______________________________________

From report at bugs.python.org  Tue Oct 18 10:43:54 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 18 Oct 2011 08:43:54 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1318927434.92.0.651521607811.issue4431@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> If I can provide the patch to support Visual Studio 2010 and setup a
> builtbot that will pass most of the tests, could we get Python
> supported on this platform?

Yes. Even if VS2008 remains the preferred compiler to build Python, and the only one used for official binary distributions, there are already project files for VS8 and even VC6 (in PC/VS8.0 and PC/VC6).  They are not guaranteed to always work, but are updated from time to time by volunteers.
Please open another issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Tue Oct 18 10:48:20 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 18 Oct 2011 08:48:20 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1318927700.2.0.994512381388.issue12277@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Yes, Eric, please fix this already. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Tue Oct 18 10:50:46 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Tue, 18 Oct 2011 08:50:46 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1318927846.26.0.0864886348961.issue12296@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

Updated the existing patch with the new wording

----------
nosy: +Jyrki.Pulliainen
Added file: http://bugs.python.org/file23437/clarify-bwcompat-devguide_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Tue Oct 18 10:54:36 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 18 Oct 2011 08:54:36 +0000
Subject: [issue12448] smtplib's __main__ doesn't flush when prompting
In-Reply-To: <1309414826.92.0.939740795599.issue12448@psf.upfronthosting.co.za>
Message-ID: <1318928076.89.0.706692709211.issue12448@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Raymond: Would you also like to commit the patch? :)

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12448>
_______________________________________

From report at bugs.python.org  Tue Oct 18 11:21:35 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 18 Oct 2011 09:21:35 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1318929695.33.0.678730975083.issue10197@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Tue Oct 18 11:26:32 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 18 Oct 2011 09:26:32 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1318364912.99.0.0504415836184.issue10881@psf.upfronthosting.co.za>
Message-ID: <79645432-E8A8-4B7C-9B5C-71563D50BFA5@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 11 Oct, 2011, at 22:28, Ned Deily wrote:

> 
> Ned Deily <nad at acm.org> added the comment:
> 
> I forgot to mention that one advantage of using another framework and root location, say, under your home directory somewhere, is that it is unnecessary to use sudo.  And you don't need to use the special target in any case, simply "make install".

Make install always works, the frameworkinstall target is a leftover from a time when you couldn't use "make install".

----------
Added file: http://bugs.python.org/file23438/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4788 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20111018/1a5ae9b4/attachment-0001.bin>

From report at bugs.python.org  Tue Oct 18 11:27:49 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 18 Oct 2011 09:27:49 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1318930069.24.0.787724968849.issue1757072@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_______________________________________

From report at bugs.python.org  Tue Oct 18 11:44:45 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Tue, 18 Oct 2011 09:44:45 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1318931085.63.0.286627314543.issue3067@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

Added a patch that implements two things:

setlocale now raises locale.Error('Locale must be None, a string, or an iterable of two strings -- language code, encoding.'). I decided to remove the proposed .format(locale), as it wasa a bit confusing when passing a tuple containing invalid items.

I also added two tests, one for bytes and another for a tuple of two bytes.

----------
keywords: +patch
nosy: +nailor
Added file: http://bugs.python.org/file23439/issue3067.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Tue Oct 18 12:02:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Oct 2011 10:02:25 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <E1RG6V4-0008UR-4L@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b41def1851b6 by Ezio Melotti in branch '3.2':
#12277: add missing comma.
http://hg.python.org/cpython/rev/b41def1851b6

New changeset 7e57c95898d3 by Ezio Melotti in branch 'default':
#12277: merge with 3.2.
http://hg.python.org/cpython/rev/7e57c95898d3

New changeset 09a1bd44d96f by Ezio Melotti in branch '2.7':
#12277: add missing comma.
http://hg.python.org/cpython/rev/09a1bd44d96f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Tue Oct 18 12:05:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 18 Oct 2011 10:05:13 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1318932313.47.0.381790466158.issue12277@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Done.

----------
assignee: eric.araujo -> ezio.melotti
nosy: +ezio.melotti
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Tue Oct 18 12:21:24 2011
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 18 Oct 2011 10:21:24 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1318933284.89.0.309689494746.issue4431@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

I don't think a buildbot will be necessary - like the earlier compilers, they may have basic support but they don't all get buildbot support.  The "problem" isn't the lack of ability/will to get things working with VS2010 - it is more the lack of incentive to add another compiler to the mix.  OTOH, seeing it is nearly 2012, a case could certainly be made to move 3.3 to that compiler :)

I'm interested to see the patch required to get it working - almost every other upgrade has been almost handled completely by the VS upgrade process so it would be good to see how different this one is - so please CC me on any new issue you create.

I'm also interested to know how mixing the CRTs is causing problems - are you using the very few Python APIs impacted by such mixing, or is the issue more about needing to redistribute both, or something else entirely?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Tue Oct 18 12:27:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Oct 2011 10:27:02 +0000
Subject: [issue12448] smtplib's __main__ doesn't flush when prompting
In-Reply-To: <1309414826.92.0.939740795599.issue12448@psf.upfronthosting.co.za>
Message-ID: <E1RG6st-0002Ni-6l@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2c50343d0500 by Ezio Melotti in branch '3.2':
#12448: smtplib now flushes stdout while running ``python -m smtplib``
http://hg.python.org/cpython/rev/2c50343d0500

New changeset e08397a5537a by Ezio Melotti in branch 'default':
#12448: merge with 3.2.
http://hg.python.org/cpython/rev/e08397a5537a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12448>
_______________________________________

From report at bugs.python.org  Tue Oct 18 12:29:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 18 Oct 2011 10:29:30 +0000
Subject: [issue12448] smtplib's __main__ doesn't flush when prompting
In-Reply-To: <1309414826.92.0.939740795599.issue12448@psf.upfronthosting.co.za>
Message-ID: <1318933770.23.0.821852213392.issue12448@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch!

----------
assignee: rhettinger -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12448>
_______________________________________

From report at bugs.python.org  Tue Oct 18 12:55:35 2011
From: report at bugs.python.org (Mikhail Novikov)
Date: Tue, 18 Oct 2011 10:55:35 +0000
Subject: [issue13125] test_all_project_files() expected failure
In-Reply-To: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>
Message-ID: <1318935335.49.0.140530110371.issue13125@psf.upfronthosting.co.za>


Mikhail Novikov <freiksenet at gmail.com> added the comment:

I modified the tests so that they don't do prints to stdout. For that I replaced print with warnings in the "ParseError" exception except and replaced os.system with subprocess.getoutput.

----------
keywords: +patch
nosy: +freiksenet
Added file: http://bugs.python.org/file23440/i13125.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13125>
_______________________________________

From report at bugs.python.org  Tue Oct 18 13:31:47 2011
From: report at bugs.python.org (Sven Marnach)
Date: Tue, 18 Oct 2011 11:31:47 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1318937507.74.0.560781771714.issue13201@psf.upfronthosting.co.za>


Sven Marnach <sven at marnach.net> added the comment:

Mark, thanks again for your comments.  (I never looked at the Python source code before, so tey are highly appreciated.)  I uploaded a new version of the patch hopefully.

----------
Added file: http://bugs.python.org/file23441/range-compare-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Tue Oct 18 13:32:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Oct 2011 11:32:08 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1318937528.1.0.21960336978.issue12170@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I made the
> decision to raise a ValueError decision because __contains__ of both
> bytes and bytearray raise a ValueError when passed an integer not in
> range(0, 256).

That sounds reasonable. OverflowError would have been another choice, but I agree that consistency with __contains__ is sensible.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Tue Oct 18 13:34:29 2011
From: report at bugs.python.org (Manuel de la Pena)
Date: Tue, 18 Oct 2011 11:34:29 +0000
Subject: [issue13207] os.path.expanduser brakes when using unicode character
	in the username
Message-ID: <1318937669.16.0.167083698894.issue13207@psf.upfronthosting.co.za>


New submission from Manuel de la Pena <manuel at canonical.com>:

During our development we have experience the following:

If you have a user in your Windows machine with a name hat uses Japanese characters like ???????? you will have the following in your system:

* The Windows Shell will show the path correctly, that is: ?C:\Users\???????
* cmd.exe will show: ?C:\Users\???????
* All the env variables will be wrong, which means they will be similar to the info shown in cmd.exe

The above is a problem because the implementation of expanduser in ntpath.py uses the env variables to get expand the path which means that in this case the returned path will be wrong. 

I have attached a small example of how to get the user profile path (~) on Windows using SHGetFolderPathW or SHGetKnownFolderPathW to fix the issue. 

PS: I don't know if this issue also occurs on python 3.

----------
components: Windows
files: expanduser.py
messages: 145798
nosy: mandel
priority: normal
severity: normal
status: open
title: os.path.expanduser brakes when using unicode character in the username
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23442/expanduser.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13207>
_______________________________________

From report at bugs.python.org  Tue Oct 18 13:35:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Oct 2011 11:35:28 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1318937728.78.0.186866014445.issue12170@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Doc/library/stdtypes.rst needs a "versionadded" tag for the additional semantics.

Also, the patch doesn't compile fine on current default:

In file included from Objects/unicodeobject.c:487:0:
Objects/stringlib/find.h: In function ?stringlib_parse_args_finds_byte?:
Objects/stringlib/find.h:158:5: attention : implicit declaration of function ?stringlib_parse_args_finds?
In file included from Objects/unicodeobject.c:497:0:
Objects/stringlib/find.h: Hors de toute fonction :
Objects/stringlib/find.h:151:1: erreur: redefinition of ?stringlib_parse_args_finds_byte?
Objects/stringlib/find.h:151:1: note: previous definition of ?stringlib_parse_args_finds_byte? was here

I'd say you need to either define your function as STRINGLIB(parse_args_finds_byte) (to avoid name collisions), or avoid defining it if STRINGLIB_IS_UNICODE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Tue Oct 18 13:49:50 2011
From: report at bugs.python.org (Deepak Dodo)
Date: Tue, 18 Oct 2011 11:49:50 +0000
Subject: [issue13208] Problems with urllib on windows
Message-ID: <1318938589.99.0.598751159325.issue13208@psf.upfronthosting.co.za>


New submission from Deepak Dodo <deepakdodo at gmail.com>:

When I try to read the contents of the webpage: 
http://www.ai-class.com/course/json/filter/QuizQuestion
using urllib.read, it doesn't read the entire content. 
This behavior is only seen on windows and the same operation works fine on linux machines.

----------
components: Windows
messages: 145800
nosy: Deepak.Dodo
priority: normal
severity: normal
status: open
title: Problems with urllib on windows
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13208>
_______________________________________

From report at bugs.python.org  Tue Oct 18 13:50:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Oct 2011 11:50:11 +0000
Subject: [issue13209] Refactor code using unicode_encode_call_errorhandler()
	in unicodeobject.c
Message-ID: <1318938611.14.0.651217726677.issue13209@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

It's difficult to use unicode_encode_call_errorhandler() because the caller has to:

 - resize the output buffer (and check for integer overflow on the new size)
 - handle bytes and str for the replacement string: PyUnicode_EncodeDecimal() doesn't support bytes for example
 - encode replacement str: some encoders uses ASCII, unicode_encode_ucs1() uses Latin1, PyUnicode_EncodeCharmap() uses a recursive call (without check for infinite loop!), ... ; and raise a UnicodeEncodeError if the encoding fails

It would be nice to factorize this code.

I plan this implement this refactoring, it's just a reminder for me :-)

----------
components: Unicode
messages: 145801
nosy: haypo
priority: normal
severity: normal
status: open
title: Refactor code using unicode_encode_call_errorhandler() in unicodeobject.c
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13209>
_______________________________________

From report at bugs.python.org  Tue Oct 18 14:05:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 18 Oct 2011 12:05:48 +0000
Subject: [issue13209] Refactor code using unicode_encode_call_errorhandler()
	in unicodeobject.c
In-Reply-To: <1318938611.14.0.651217726677.issue13209@psf.upfronthosting.co.za>
Message-ID: <1318939548.82.0.802279704873.issue13209@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+1

----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13209>
_______________________________________

From report at bugs.python.org  Tue Oct 18 14:16:31 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 18 Oct 2011 12:16:31 +0000
Subject: [issue13207] os.path.expanduser breaks when using unicode character
	in the username
In-Reply-To: <1318937669.16.0.167083698894.issue13207@psf.upfronthosting.co.za>
Message-ID: <1318940191.4.0.81703898164.issue13207@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
title: os.path.expanduser brakes when using unicode character in the username -> os.path.expanduser breaks when using unicode character in the username

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13207>
_______________________________________

From report at bugs.python.org  Tue Oct 18 14:20:14 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 18 Oct 2011 12:20:14 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1318940414.35.0.206193104613.issue12170@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Tue Oct 18 14:55:21 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 18 Oct 2011 12:55:21 +0000
Subject: [issue13210] Support Visual Studio 2010
Message-ID: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

Python for Windows is currently compiled with Visual Studio 2008.
It is not possible to use Visual Studio 2010.

It would be great to be able to compile Python with Visual Studio 2010:

* some people may only have access to this compiler which is more recent

* when embedding Python in an application compiled with Visual Studio 2010, you mix 2 C Runtime Libraries (msvcr90.dll and msvcr100.dll) which will generally result in a crash

This is the parent issue. I have various patches to achieve that and I will try to open one issue by patch. I may also run a builtbot using that compiler.

----------
assignee: tarek
components: Build, Distutils, Distutils2, Installation, Windows
messages: 145803
nosy: alexis, eric.araujo, mhammond, sable, tarek
priority: normal
severity: normal
status: open
title: Support Visual Studio 2010
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:01:05 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 18 Oct 2011 13:01:05 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1318942865.5.0.394332355707.issue4431@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Amaury:
Great! I have opened issue 13210 to achieve that.

Mark:
Mixing the 2 CRTs results in plenty of crashes in our application. The application also uses a lot of Qt. It is not an option to use a prebuilt Python binary generated with VS2008.

I added you to issue 13210 and I will post the patches there soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:02:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Oct 2011 13:02:37 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1318942957.58.0.105616319965.issue13210@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:02:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Oct 2011 13:02:59 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1318942979.26.0.451269590504.issue13210@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:03:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Oct 2011 13:03:07 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1318942987.71.0.944460854025.issue13210@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:06:08 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 18 Oct 2011 13:06:08 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
Message-ID: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

The urllib2 docs indicate that HTTPError is a subclass of URLError and that URLError has an attribute of 'reason', but HTTPError does not have this attribute. The docs should be updated to reflect this deviance.

It appears the Python 3.2 docs no longer include documentation for URLError

Python 2.7.2
>>> try:urllib2.urlopen('http://api.wordnik.com/v4/word.json/foo/examples')
... except urllib2.HTTPError as exc:
...   print(dir(exc))
...
['_HTTPError__super_init', '__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__getitem__', '__getslice__', '__hash__', '__init__', '__iter__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setstate__', '__sizeof__', '__str__', '__subclasshook__', '__unicode__', '__weakref__', 'args', 'close', 'code', 'errno', 'filename', 'fileno', 'fp', 'getcode', 'geturl', 'hdrs', 'headers', 'info', 'message', 'msg', 'next', 'read', 'readline', 'readlines', 'strerror', 'url']

The same issue exists in Python 3.2.2.

Here's what I propose:
  - For Python 3.2 and 3.3, update HTTPError to supply a @property, aliasing .msg (will .msg always be a suitable .reason?).
  - For Python 2.7, document the deviance, such as by adding the following wording to the HTTPError docs: "Unlike URLError, HTTPError does not supply a reason attribute. The reason can be retrieved through the msg attribute."

----------
assignee: docs at python
components: Documentation
messages: 145805
nosy: docs at python, jason.coombs
priority: normal
severity: normal
status: open
title: urllib2.HTTPError does not have 'reason' attribute.
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:12:08 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 18 Oct 2011 13:12:08 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1318943528.66.0.989376460089.issue11085@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:17:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 18 Oct 2011 13:17:37 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1318943857.4.0.451693320399.issue13188@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch that fixes this. The test case is a bit ugly, as it only checks that the traceback's depth is correct.

----------
keywords: +patch
nosy: +ezio.melotti, petri.lehtinen
stage:  -> patch review
Added file: http://bugs.python.org/file23443/issue13188.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:23:43 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 18 Oct 2011 13:23:43 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining
	marks	inappropriately
In-Reply-To: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>
Message-ID: <1318944223.4.0.107593238835.issue12737@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12737>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:27:00 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Tue, 18 Oct 2011 13:27:00 +0000
Subject: [issue10817] urllib.request.urlretrieve never raises
	ContentTooShortError if no reporthook
In-Reply-To: <1294069804.34.0.860239284714.issue10817@psf.upfronthosting.co.za>
Message-ID: <1318944420.22.0.303188551603.issue10817@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

Changed the code so that the content length is set as size if reporthook is not set and wrote two tests for it.

Note: I moved fakehttp behavior to a mixin, so that it's more reusable.

----------
keywords: +patch
nosy: +nailor
Added file: http://bugs.python.org/file23444/issue10817.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10817>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:28:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Oct 2011 13:28:13 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1318944493.92.0.419659767572.issue13188@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you! There is a memory leak somewhere:

$ ./python -m test -R 3:2 test_generators
[1/1] test_generators
beginning 5 repetitions
12345
.....
test_generators leaked [1945, 1945] references, sum=3890
1 test failed:
    test_generators


Also, since the patch is so short, a stylistic nit:

+            if(tb == NULL) {

There should be a space after the "if".
(see PEP 7: http://www.python.org/dev/peps/pep-0007/)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:29:15 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 18 Oct 2011 13:29:15 +0000
Subject: [issue12458] Tracebacks should contain the first line of continuation
	lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1318944555.87.0.756015144166.issue12458@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12458>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:39:26 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Tue, 18 Oct 2011 13:39:26 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1318945166.04.0.202046639857.issue13188@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

It leaks because `PyException_GetTraceback()` already returns a new reference, hence the "Py_XINCREF(tb)" is wrong.

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:44:00 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 18 Oct 2011 13:44:00 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1318945440.25.0.281263349875.issue13210@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

We can make Python compile with Visual Studio 2010, but it will not be the platform Python is released on, it would be optional while 2008 stays the release target, at least through Python 3.3. In Python 3.4, we may re-evaluate this, and it's likely we would jump over 2010 and move to Visual Studio 2012 at that point (per discussions on python-dev).

As for your first point, Visual Studio 2008 is still available on the Microsoft site, it's just not the first thing you usually find. If you look here - http://msdn.microsoft.com/en-us/express/future/bb421473 - you can find it.


Anyway, I've done this port internally at my company, but I'm not able to release that patch. I am, however, willing to do it personally so it could be included here. If anyone else is interested in working on it, it should follow the same format as other VS version support, going in the PC/VS{version} folder.

Also, reclassified this to the proper version, 3.3, since it's a feature request.

----------
assignee: tarek -> 
components:  -Distutils, Distutils2, Installation
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Tue Oct 18 15:46:35 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 18 Oct 2011 13:46:35 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1318945595.1.0.766844091905.issue13188@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached an updated patch.

I incref'd the return value of PyErr_GetTraceback() because PyErr_Restore() steals the reference. The documentation of PyErr_GetTraceback() doesn't tell whether it returns a new or borrowed reference, but apparently a new reference then?

----------
Added file: http://bugs.python.org/file23445/issue13188_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Tue Oct 18 16:24:43 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 18 Oct 2011 14:24:43 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1318947883.21.0.391656967351.issue13210@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is a quick and dirty draft of the modifications I had to do in order to get Python 2.7.2 to compile with VS2010 on the wiki:

http://wiki.python.org/moin/VS2010

I will improve/complete it as I progress.
I will also do a 64 bits version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Tue Oct 18 16:44:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Oct 2011 14:44:18 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1318949058.44.0.201269205801.issue13188@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, it is documented:
?Return the traceback associated with the exception as a new reference (...)?
http://docs.python.org/dev/c-api/exceptions.html#PyException_GetTraceback

Thanks for the patch, will apply!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Tue Oct 18 16:47:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Oct 2011 14:47:04 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <E1RGAwW-0004TD-VM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset dcf5cc88d5c9 by Antoine Pitrou in branch '3.2':
Issue #13188: When called without an explicit traceback argument,
http://hg.python.org/cpython/rev/dcf5cc88d5c9

New changeset f4e3db1194e4 by Antoine Pitrou in branch 'default':
Issue #13188: When called without an explicit traceback argument,
http://hg.python.org/cpython/rev/f4e3db1194e4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Tue Oct 18 16:47:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Oct 2011 14:47:33 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1318949253.06.0.0999326280593.issue13188@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Tue Oct 18 16:48:03 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 18 Oct 2011 14:48:03 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1318949283.61.0.628395023113.issue12568@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Tue Oct 18 17:17:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Oct 2011 15:17:46 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <E1RGBQE-0007ai-Ve@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a3e48273dce3 by ?ukasz Langa in branch '2.7':
Fixes #10860: Handle empty port after port delimiter in httplib
http://hg.python.org/cpython/rev/a3e48273dce3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Tue Oct 18 17:35:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 15:35:44 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318952144.32.0.950055064206.issue12405@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Vinay]
> I think you mean "Only the paste/util directory is recorded."
Obviously :)

> How about if you record all directories that you would create if they didn't exist, as well
> as those actually created? That way, you would record the paste directory under both
> distributions, but would only delete it when deleting the last distribution which uses it
This is what I proposed earlier: we?d need to record all directories that would have been created, but I?m not sure if it will be possible.  For example, if one uses --prefix /tmp/usr and pysetup install creates /tmp/usr, /tmp/usr/lib, /tmp/usr/lib/python2.7, /tmp/usr/lib/python2.7/site-packages, /tmp/usr/lib/python2.7/site-packages/spam and /tmp/usr/lib/python2.7/site-packages/Spam-0.1.dist-info, then we pysetup should Spam, should packaging remove only the package and dist-info directories or also the site-packages, python2.7, lib and usr directories?

[Carl]
> In short - pip would _love_ to have directories recorded as well as files, exactly as Vinay
> has proposed. We don't have that info (even the distutils --record option currently doesn't
> record directories, thus installed-files.txt doesn't contain directories), so we are reduced
> to some nasty things like referring to top-level.txt in order to avoid lots of empty
> directories hanging about,
Oh.  Ouch.

> which in itself was the subject of recent controversy re Twisted's custom namespace
> packages implementation.
Ah, I understand that better now.  Maybe now would be a good time to start an alpha pip-on-distutils2 branch, to see if the API we offer is good enough and to work out possible bugs in new features offered to pip by d2 (removing directories, installing setup.cfg-based projects, supporting bdists).

> Please, let's have directories recorded in RECORD,
Okay, so I will champion a patch to PEP 376.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Tue Oct 18 17:45:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 15:45:16 +0000
Subject: [issue868845] Need unit tests for <...> reprs
Message-ID: <1318952716.72.0.610759532243.issue868845@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Original report:
> Samuele Pedroni points out in python-dev that the <...> style reprs of Python objects are
> not documented, standardized or even consistent (e.g. compare old-style and new-style
> classes).
>
> Yet there is plenty of code out there that for various reasons parses these things or a
> least depends on what they look like (the parrot benchmark being only the latest example).

<...>-style reprs have been documented by Georg; for the consistency part, I just run the snippet from Nick on 3.2:

<class 'array.array'>
<class 'dict'>
<class '__main__.foo'>
<__main__.foo object at 0x13fa810>
<function x at 0x1399050>
<bound method foo.x of <__main__.foo object at 0x13fa850>>
<function func at 0x132cf30>

I would call that consistent.  (FWIW I like that the dict repr contains ?dict? and not ?builtins.dict?, as the common form for using it does not need the module part.)

For the standardization part, Alexander proposed this:
> For 3.0, I think it is feasible to standardize on the
> <{type} object ['{name}'] ... at 0x{addr}> pattern.

If there are tools out there that parse reprs, I think a change that would break them should have been in 3.0, now we?re bound by b/w compat.

To sum up: <...>-style reprs are documented and consistent enough, so let?s close this.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue868845>
_______________________________________

From report at bugs.python.org  Tue Oct 18 17:48:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 15:48:59 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1318952939.25.0.561783592973.issue3067@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  Exception messages are considered implementation details, so I would not test them.  Testing that an exception is raised is good enough IMO.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Tue Oct 18 17:53:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 15:53:37 +0000
Subject: [issue13207] os.path.expanduser breaks when using unicode character
	in the username
In-Reply-To: <1318937669.16.0.167083698894.issue13207@psf.upfronthosting.co.za>
Message-ID: <1318953217.13.0.855207252786.issue13207@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

On POSIX, Python 3 works correctly if my home dir is /tmp/?ric, and Python 2.7 returns a UTF-8-encoded (not locale-encoded!) bytes string.

For Windows, a patch would probably need to add a private function to the _nt module (in C): ctypes is too dangerous to be used in the standard library.

----------
nosy: +eric.araujo, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13207>
_______________________________________

From report at bugs.python.org  Tue Oct 18 17:55:17 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 18 Oct 2011 15:55:17 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1318953317.22.0.456277771739.issue13210@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Tue Oct 18 17:57:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 15:57:24 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1318953444.1.0.804534017291.issue13210@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The wiki page contains change to distutils, which I believe would not be allowed by the feature freeze.  New features (such as support for a new compiler) need to target packaging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Tue Oct 18 17:58:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 15:58:16 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1318953496.06.0.663364409203.issue12277@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry, I was too busy with real bugs to fix this minor one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Tue Oct 18 17:59:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Oct 2011 15:59:34 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <E1RGC4g-0003kY-Qd@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 70160b53117f by Antoine Pitrou in branch 'default':
Issue #13150: sysconfig no longer parses the Makefile and config.h files
http://hg.python.org/cpython/rev/70160b53117f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:00:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Oct 2011 16:00:30 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318953630.77.0.217426385416.issue13150@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Done! If someone wants to give life to the C approach, they are welcome :)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:01:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:01:11 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1318953671.97.0.663178960798.issue10197@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If Windows shell syntax is similar to POSIX one, then () will run in a sub-shell, which would be a different behavior than using {} (which merely group statements and their streams).

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:02:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:02:06 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1318953726.53.0.22280775103.issue12296@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I like it.  Terry, objections?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:02:24 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Tue, 18 Oct 2011 16:02:24 +0000
Subject: [issue10817] urllib.request.urlretrieve never raises
	ContentTooShortError if no reporthook
In-Reply-To: <1294069804.34.0.860239284714.issue10817@psf.upfronthosting.co.za>
Message-ID: <1318953744.09.0.0969077912366.issue10817@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

I had a bad patch, containing changes to locale.py, so I've uploaded a new patch for this.

----------
Added file: http://bugs.python.org/file23446/issue10817.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10817>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:02:39 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Tue, 18 Oct 2011 16:02:39 +0000
Subject: [issue10817] urllib.request.urlretrieve never raises
	ContentTooShortError if no reporthook
In-Reply-To: <1294069804.34.0.860239284714.issue10817@psf.upfronthosting.co.za>
Message-ID: <1318953759.32.0.0399691942881.issue10817@psf.upfronthosting.co.za>


Changes by Jyrki Pulliainen <jyrki at dywypi.org>:


Removed file: http://bugs.python.org/file23444/issue10817.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10817>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:07:15 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Tue, 18 Oct 2011 16:07:15 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1318954035.65.0.397012797001.issue3067@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

I modified the patch not to contain the tests against exception messages

----------
Added file: http://bugs.python.org/file23447/issue3067_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:07:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 18 Oct 2011 16:07:52 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1318954072.65.0.0696327048545.issue12296@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

LGTM.

(Actually you can still break someone's code by introducing new functions/classes, in case they get imported with 'from mod import *' and override some local function/class with the same name -- but this is such an obscure case that doesn't deserve to be mentioned (and 'import *' is bad practice anyway).)

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:09:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:09:25 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1318954165.06.0.50990768853.issue12703@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks.  I?ll add more tests and commit.  (I also prefer to create modules in test methods instead of using another file, so that I can see right here what the module contains.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:10:55 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 18 Oct 2011 16:10:55 +0000
Subject: [issue868845] Need unit tests for <...> reprs
Message-ID: <1318954255.54.0.183776739299.issue868845@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think there's nothing to be done for a bug this general.

If you find a specific object whose repr() is awkward, go ahead and file a specific bug.

In most cases I think people who parse repr() output know they are on thin ice, and would prefer that the object whose repr() they are parsing had a method or attribute that returned what they were after.  Example: in 3.2, parsing repr(range(...)) is the only way to access the start/stop/step attributes; but we're fixing this for 3.3.  Exception: unittests that specifically verify the form of a repr().

Off-topic: I sometimes wish that the str() of a class would return the class name rather than its repr(); that way "print(str)" would print "str" instead of <class 'str'>.  (Use case: printing an exception and its message: I wish I could print("%s: %s" % (err.__class__, err)) instead of having to use err.__class__.__name__.)  One could even claim that the repr() of a class could be the same, since one of the guiding principles for repr() is that it should, if possible, return an expression that (perhaps given a suitable environment) could reconstruct the value exactly (and otherwise it should have the <...> form discussed in this issue).  But both of these wishes are debatable, and if anyone cares, they should open a new bug to discuss it.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue868845>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:15:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:15:53 +0000
Subject: [issue11638] python setup.py sdist crashes if version is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1318954553.29.0.606814498463.issue11638@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

David:
I don?t think packaging and pysetup generate-setup have anything to do with this bug.  You can create a setup.py file manually and see the error with distutils in 2.7.

As I said before, I agree this is a bug.  I?m working on many things right now, so if someone volunteers to write a test and possibly a fix for this, it would help.  We have examples of creating tarball sdists in Lib/distutils/tests/test_sdist.py, one would just need to copy an example and pass version=u'1.0'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:16:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Oct 2011 16:16:43 +0000
Subject: [issue13170] distutils2 test failures
In-Reply-To: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>
Message-ID: <E1RGCLI-0005QB-3P@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5d858149df06 by ?ric Araujo in branch 'default':
Synchronize config with packaging (fixes #13170)
http://hg.python.org/distutils2/rev/5d858149df06

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:19:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:19:13 +0000
Subject: [issue13205] NameErrors in generated setup.py (codecs,
	split_multiline)
In-Reply-To: <1318902833.17.0.0898413636747.issue13205@psf.upfronthosting.co.za>
Message-ID: <1318954753.83.0.604747755827.issue13205@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks!  I haven?t tested generate-setup for some time.  It would be great to add a regression test for this.  Would you like to do it?  To mock user input, just copy the Inputs class from test_command_register.  If not, I will do it.

----------
assignee: tarek -> eric.araujo
stage:  -> test needed
versions: +3rd party, Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13205>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:19:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Oct 2011 16:19:46 +0000
Subject: [issue13193] test_packaging and test_distutils failures under Windows
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1318954786.48.0.0688840727818.issue13193@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Similar test failure under x86 OpenIndiana:

======================================================================
ERROR: test_resources (packaging.tests.test_command_install_data.InstallDataTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_command_install_data.py", line 129, in test_resources
    with packaging.database.get_file('Spamlib', 'spamd') as fp:
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/database.py", line 649, in get_file
    return open(get_file_path(distribution_name, relative_path),
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/database.py", line 644, in get_file_path
    raise LookupError('no distribution named %r found' % distribution_name)
LookupError: no distribution named 'Spamlib' found

http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/2153/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:20:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:20:55 +0000
Subject: [issue1565071] update Lib/plat-linux2/IN.py
Message-ID: <1318954855.94.0.962769603039.issue1565071@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +Automatically regenerate platform-specific modules
stage: test needed -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565071>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:22:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:22:07 +0000
Subject: [issue3990] The Linux2 platform definition is incorrect for alpha,
	hppa, mips, sparc
In-Reply-To: <1222622636.83.0.91904211749.issue3990@psf.upfronthosting.co.za>
Message-ID: <1318954927.96.0.353982381782.issue3990@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.2, Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3990>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:22:40 2011
From: report at bugs.python.org (bpoaugust)
Date: Tue, 18 Oct 2011 16:22:40 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1318954960.18.0.0493059372011.issue10197@psf.upfronthosting.co.za>


bpoaugust <sebbaz+bpo at gmail.com> added the comment:

I got the () syntax from:

http://technet.microsoft.com/en-us/library/cc737438%28WS.10%29.aspx

which refers to grouping, not subshell.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:25:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:25:00 +0000
Subject: [issue3990] The Linux2 platform definition is incorrect for alpha,
	hppa, mips, sparc
In-Reply-To: <1222622636.83.0.91904211749.issue3990@psf.upfronthosting.co.za>
Message-ID: <1318955100.63.0.656392058489.issue3990@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If we keep the plat-* directories, I think too that introducing new sys.platform values seems a bit heavy-handed.

----------
dependencies: +Automatically regenerate platform-specific modules
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3990>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:26:32 2011
From: report at bugs.python.org (David Barnett)
Date: Tue, 18 Oct 2011 16:26:32 +0000
Subject: [issue13205] NameErrors in generated setup.py (codecs,
	split_multiline)
In-Reply-To: <1318902833.17.0.0898413636747.issue13205@psf.upfronthosting.co.za>
Message-ID: <1318955192.5.0.20367347028.issue13205@psf.upfronthosting.co.za>


David Barnett <davidbarnett2 at gmail.com> added the comment:

Sure, I can give it a go. I'll probably have a chance sometime today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13205>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:35:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:35:46 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318955746.76.0.510153616763.issue13150@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, distutils2 backports the sysconfig module and cfg file from 3.3, so now the two versions will diverge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:40:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:40:40 +0000
Subject: [issue868845] Need unit tests for <...> reprs
Message-ID: <1318956040.48.0.616870464826.issue868845@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I sometimes wish that the str() of a class would return the class name
> rather than its repr(); that way "print(str)" would print "str"
> instead of <class 'str'>.  (Use case: printing an exception and its
> message: I wish I could print("%s: %s" % (err.__class__, err)) instead
> of having to use err.__class__.__name__.)
Me too.  I have a small metaclass to do that :)  Given your tentative support, I?ll open a feature request for 3.3.

> One could even claim that the repr() of a class could be the same
I think of repr first as ?string form for debugging?, so I like the angle brackets.

----------
stage: test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue868845>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:42:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:42:26 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1318956146.4.0.592099603016.issue1673007@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Doc patch to fix a reST error and tweak a few things.

----------
Added file: http://bugs.python.org/file23448/urllib.request-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Tue Oct 18 18:44:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Oct 2011 16:44:25 +0000
Subject: [issue13172] Improve detection of availability of bdist_msi command
In-Reply-To: <1318531671.43.0.795221927422.issue13172@psf.upfronthosting.co.za>
Message-ID: <1318956265.27.0.457738398874.issue13172@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The existing traceback doesn't even mention _msi.

Looks like #12703, which I?m going to fix shortly.

----------
dependencies: +Improve error reporting for packaging.util.resolve_name

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13172>
_______________________________________

From report at bugs.python.org  Tue Oct 18 19:32:50 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 18 Oct 2011 17:32:50 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318959170.48.0.858612748283.issue13150@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Tue Oct 18 19:33:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 Oct 2011 17:33:05 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1318959185.08.0.330819147705.issue12296@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To be more exact, "optional arguments" should be more extended to "optional arguments whose default maintains the existing behavior"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Tue Oct 18 19:39:27 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 18 Oct 2011 17:39:27 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318949058.44.0.201269205801.issue13188@psf.upfronthosting.co.za>
Message-ID: <20111018173921.GA1826@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

Antoine Pitrou wrote:
> Actually, it is documented:
> ?Return the traceback associated with the exception as a new reference (...)?

Ah, you're right. It just doesn't have the green "Return value: New
reference" note.

Thanks for committing!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Tue Oct 18 19:42:18 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 18 Oct 2011 17:42:18 +0000
Subject: [issue13208] Problems with urllib on windows
In-Reply-To: <1318938589.99.0.598751159325.issue13208@psf.upfronthosting.co.za>
Message-ID: <1318959738.56.0.436956613412.issue13208@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please provide a test case? What exact source code you are using, and what exact result are you getting? Attach those pieces as files.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13208>
_______________________________________

From report at bugs.python.org  Tue Oct 18 19:50:35 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 18 Oct 2011 17:50:35 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1318960235.49.0.455656718602.issue13188@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

BTW, shouldn't this be applied to 2.7 too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Tue Oct 18 19:50:38 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 18 Oct 2011 17:50:38 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1318960238.33.0.00727356213596.issue13210@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think this issue urgently needs a scope defined. What *exactly* is it that you want to achieve? If it's merely being able to compile Python with VS 2010, many of the proposed changes are unnecessary.

If you propose that the patch should be used to replace VS 2008 with VS 2010, I suggest that instead of developing it as a patch, you create a hg clone that you maintain on your own.

If you propose that Python 3.3 be built and released with VS 2010, then we need to re-evaluate this question again. Wrt. VS 2012, my hope is that this will be available for 3.3 already. If that's not going to happen, I'd be open to switch to 2010 for 3.3 only (and to 2012 for 3.4).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Tue Oct 18 20:00:32 2011
From: report at bugs.python.org (Tomasz Buchert)
Date: Tue, 18 Oct 2011 18:00:32 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
Message-ID: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>


New submission from Tomasz Buchert <thinred at gmail.com>:

Hi there!
According to http://www.ietf.org/rfc/rfc4627.txt . The JSON object is either a list or a dictionary with other elements in it. However Python's implementation took liberty to parse also basic types, like integers, strings, floats, etc. For example:

>>> import json
>>> json.loads('42')
42
>>> json.dumps(3.141592)
'3.141592'

It wouldn't be a problem if other implementations would adhere to this behavior, but this is not true. Take Ruby for example:

irb(main):007:0> require 'rubygems';
irb(main):008:0* require 'json';
irb(main):009:0* JSON.parse '42'
JSON::ParserError: 743: unexpected token at '42'
	from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:148:in `parse'
	from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:148:in `parse'
	from (irb):9
	from :0
irb(main):010:0> JSON.generate(3.141592)
JSON::GeneratorError: only generation of JSON objects or arrays allowed
	from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:216:in `generate'
	from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:216:in `generate'
	from (irb):10
	from :0

Also http://jsonlint.com/ considers it an error.

I know this is not very important, but I've ran into this today when trying to parse JSON in Ruby which was produced in Python.

I've made a patch for that, but I still need to fix tests and there are many of them. I first would like to know if it is going to be fixed, then I will complete the patch.

Thanks for Python, anyway!

Tomek

----------
components: Library (Lib)
messages: 145847
nosy: thinred
priority: normal
severity: normal
status: open
title: json library is decoding/encoding when it should not
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Tue Oct 18 20:16:43 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 18 Oct 2011 18:16:43 +0000
Subject: [issue13213] generator.throw() behavior
Message-ID: <1318961803.9.0.966531589594.issue13213@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

The documentation of generator.throw() gives this signature:

    generator.throw(type[, value[, traceback]])

Looking at the code, it accepts the following arguments:

  g.throw(ExcType)  --> raise ExcType()

  g.throw(ExcType, None)  --> raise ExcType()

  g.throw(ExcType, None, tb)  --> raise ExcType().with_traceback(tb)

  g.throw(ExcType, instace_of_ExcType)  --> raise instance_of_ExcType

  g.throw(ExcType, instace_of_ExcType, tb)  --> raise instance_of_ExcType.with_traceback(tb)

  g.throw(ExcType, other_value)  --> raise ExcType(other_value)

  g.throw(ExcType, other_value, tb)  --> raise ExcType(other_value).with_traceback(tb)

Up to this point, I think everything is in line with the documentation. But it also accepts the following (now that issue 13188 is fixed):

  g.throw(exc_instance) --> raise exc_instance (preserving the traceback of exc_instance)

  g.throw(exc_instance, None) --> raise exc_instance (preserving the traceback of exc_instance)

  g.throw(exc_instance, None, tb) --> raise exc_instance.with_traceback(tb)

It does not accept these, throwing a TypeError:

  g.throw(exc_instance, some_value_other_than_None)
  g.throw(exc_instance, some_value_other_than_None, tb)
  g.throw(exc_instance, tb)

The documentation is really unclear on throwing existing exception instances with (exc_instance) or (exc_instance, None), and that calling with (type, value) or (type, value, tb) will create a new exception if not isinstance(value, type).

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 145848
nosy: docs at python, ezio.melotti, ncoghlan, petri.lehtinen, pitrou
priority: normal
severity: normal
status: open
title: generator.throw() behavior
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13213>
_______________________________________

From report at bugs.python.org  Tue Oct 18 20:16:55 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 18 Oct 2011 18:16:55 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1318961815.06.0.756109872751.issue12797@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

I guess that would make it more general...

I'll play around with it for a bit. It mustn't become too hard to use though since the original point was to simplify the opening of files :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Tue Oct 18 20:18:24 2011
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 18 Oct 2011 18:18:24 +0000
Subject: [issue12405] packaging does not record/remove directories it creates
In-Reply-To: <1308995305.23.0.132392157923.issue12405@psf.upfronthosting.co.za>
Message-ID: <1318961904.77.0.737981596678.issue12405@psf.upfronthosting.co.za>


Carl Meyer <carl at dirtcircle.com> added the comment:

> This is what I proposed earlier: we?d need to record all directories that would have been created, but I?m not sure if it will be possible.  For example, if one uses --prefix /tmp/usr and pysetup install creates /tmp/usr, /tmp/usr/lib, /tmp/usr/lib/python2.7, /tmp/usr/lib/python2.7/site-packages, /tmp/usr/lib/python2.7/site-packages/spam and /tmp/usr/lib/python2.7/site-packages/Spam-0.1.dist-info, then we pysetup should Spam, should packaging remove only the package and dist-info directories or also the site-packages, python2.7, lib and usr directories?

I think it would make sense to draw a distinction between "creating the prefix directories (including site-packages)" and "creating the distribution-specific directories within the prefix directories." And only record the latter in RECORD for the given installed distribution.

If I use --prefix and install some things, and then uninstall them, I would not consider it a bug to find the empty site-packages directory still remaining under that prefix. (In fact, I'd be surprised if it were removed).

> Okay, so I will champion a patch to PEP 376.

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12405>
_______________________________________

From report at bugs.python.org  Tue Oct 18 20:25:52 2011
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 18 Oct 2011 18:25:52 +0000
Subject: [issue1053687] PyOS_InputHook not called in IDLE subprocess
Message-ID: <1318962352.03.0.370713344219.issue1053687@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This is related to http://bugs.python.org/issue989712

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1053687>
_______________________________________

From report at bugs.python.org  Tue Oct 18 20:47:49 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 18 Oct 2011 18:47:49 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1318963669.55.0.134029390764.issue13212@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
stage:  -> needs patch
type:  -> behavior
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Tue Oct 18 20:48:57 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 18 Oct 2011 18:48:57 +0000
Subject: [issue13213] generator.throw() behavior
In-Reply-To: <1318961803.9.0.966531589594.issue13213@psf.upfronthosting.co.za>
Message-ID: <1318963737.34.0.407285312964.issue13213@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13213>
_______________________________________

From report at bugs.python.org  Tue Oct 18 20:49:58 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 18 Oct 2011 18:49:58 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1318963798.27.0.8815841259.issue3067@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the reported exception type is incorrect. Given that the error message is 'Locale must be None, a string, or an iterable of two strings -- language code, encoding.', it very much sounds like a TypeError is being reported here.

So I think all that's needed is that the ValueError is converted into a TypeError.

Also notice that the tuple unpacking may actually succeed:

py> locale.setlocale(locale.LC_ALL,u"en")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/locale.py", line 513, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Tue Oct 18 20:51:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Oct 2011 18:51:19 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1318963879.03.0.151372587763.issue13212@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't see any way of changing this without breaking lots of code that currently works fine.  It may be possible to add a strict-mode (off by default) or to add warnings.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Tue Oct 18 20:54:03 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 18 Oct 2011 18:54:03 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1318964043.81.0.0313447124791.issue7723@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:03:44 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 18 Oct 2011 19:03:44 +0000
Subject: [issue1294] Management of KeyboardInterrupt in cmd.py
In-Reply-To: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za>
Message-ID: <1318964624.38.0.193403859184.issue1294@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

I realize that this bug is closed, but I just had a comment to make.

Handling EOF is simple:

def do_EOF(self, arg):
    pass

For my purposes I want to raise an EOFError so I can trickle up the chain to the appropriate caller because I'm coding a CLI where I have a nested set of commands, e.g.

command subcommand_0
command subcommand_1

I'd like the behavior to match what's done in Cisco IOS or IronPort's CLI (to some degree).

The only part that's annoying is that I have to hide do_EOF in the help and completion output, otherwise the user will see the handler when completing or running help, but I'll bring that up in another issue.

----------
nosy: +yaneurabeya

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:08:11 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Tue, 18 Oct 2011 19:08:11 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1318964891.88.0.453653705051.issue3067@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

Maybe we should return TypeError with the same message then? That would require some modification of documentation though, as it states: "If the modification of the locale fails, the exception Error is raised.".

I don't really understand the "locale unpacking may actually succeed". Isn't that what supposed to happen, to my knowledge "en" is not a valid locale and that's a totally different issue? If I'm wrong, please correct, I've just started wandering in to Python Core development :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:16:06 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 18 Oct 2011 19:16:06 +0000
Subject: [issue13214] Cmd: list available completions from the cmd.Cmd
	subclass and filter out EOF handler(s)
Message-ID: <1318965366.62.0.48247525728.issue13214@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

1. The current code in cmd.get_names does a dir on the derived class for
   cmd.Cmd object instead, which means that if I do something similar to
   the following:

class CLI(cmd.Cmd):
   def register_subcommand(self, cmd, cli_class):
       def call_cli(self):
           cli = cli_class()
           cli.cmdloop()
       setattr(self, 'do_%s' % (cmd, ), call_cli)

   it won't register the command in the completion list or help list.

2. Registering a do_EOF handler is a bit of a hack to work around
   the fact that entering in ^D on the command line prints out:

   (Cmd) *** Unknown syntax: EOF

   I can't speak to the fact that my desired behavior should be 
   enforced (basically trickle up the EOFError like so):

   def do_EOF(self, arg):
       raise EOFError

   so what I'm proposing instead is that it be filtered out by default.

Given that there's some value in allowing developers to build custom filter rules for the completions (example: certain commands can be undocumented, hidden to lower privilege users, etc), I figured it would be wise to create a custom mechanism for filtering out commands.

This could be cleaned up to use better python idioms like a generator, cache the data and have a refresh method, etc, but this is a good first start.

----------
components: Library (Lib)
files: python-cmd-better-filtering.patch
keywords: patch
messages: 145856
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)
type: feature request
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file23449/python-cmd-better-filtering.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13214>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:16:57 2011
From: report at bugs.python.org (Benjamin Gilbert)
Date: Tue, 18 Oct 2011 19:16:57 +0000
Subject: [issue13215] multiprocessing Manager.connect() aggressively retries
	refused connections
Message-ID: <1318965417.81.0.122561387998.issue13215@psf.upfronthosting.co.za>


New submission from Benjamin Gilbert <bgilbert at backtick.net>:

multiprocessing.managers.BaseManager.connect() takes 20 seconds to return on failure, even if the server refuses the connection.  This is because the function that creates the connection, multiprocessing.connection.SocketClient(), handles ECONNREFUSED by retrying the connection attempt every 10 ms for 20 seconds.

While a 20 second timeout may make sense for *unresponsive* servers, ECONNREFUSED probably indicates that the server is not listening on this port, so hammering it with 1,999 more connection attempts isn't going to help.  In this case, SocketClient() should fail immediately, or -- at most -- retry a small number of times with exponential backoff.

----------
components: Library (Lib)
messages: 145857
nosy: bgilbert
priority: normal
severity: normal
status: open
title: multiprocessing Manager.connect() aggressively retries refused connections
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13215>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:20:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Oct 2011 19:20:07 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <E1RGFCl-0001mC-VV@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset af0800b986b7 by Victor Stinner in branch 'default':
Issue #12281: Rewrite the MBCS codec to handle correctly replace and ignore
http://hg.python.org/cpython/rev/af0800b986b7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:30:38 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 18 Oct 2011 19:30:38 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1318964891.88.0.453653705051.issue3067@psf.upfronthosting.co.za>
Message-ID: <4E9DD3DA.8050109@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Maybe we should return TypeError with the same message then? That
> would require some modification of documentation though, as it
> states: "If the modification of the locale fails, the exception Error
> is raised.".

No, any operation can report TypeError and ValueError without explicit
mentioning in the documentation. Saying that the parameters should be
this and that implies that if they are different, you get a TypeError
or ValueError.

> I don't really understand the "locale unpacking may actually
> succeed". Isn't that what supposed to happen, to my knowledge "en" is
> not a valid locale and that's a totally different issue?

See my example again:

py> locale.setlocale(locale.LC_ALL,u"en")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/locale.py", line 513, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
py> locale.setlocale(locale.LC_ALL,u"eng")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/locale.py", line 512, in setlocale
    locale = normalize(_build_localename(locale))
  File "/usr/lib/python2.6/locale.py", line 420, in _build_localename
    language, encoding = localetuple
ValueError: too many values to unpack

So for u"eng" you get the ValueError. For u"en", you get past that
point, and then get a locale.Error. These are both Unicode strings,
but the outcome is quite different (and still would be different
under your patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:31:02 2011
From: report at bugs.python.org (Deepak Dodo)
Date: Tue, 18 Oct 2011 19:31:02 +0000
Subject: [issue13208] Problems with urllib on windows
In-Reply-To: <1318938589.99.0.598751159325.issue13208@psf.upfronthosting.co.za>
Message-ID: <1318966262.14.0.491341156802.issue13208@psf.upfronthosting.co.za>


Deepak Dodo <deepakdodo at gmail.com> added the comment:

This is the source code I am using. Even if I use any module other than urllib to read the contents, its not reading the entire contents of the webpage. This happens only on Windows.

----------
Added file: http://bugs.python.org/file23450/tester.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13208>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:32:38 2011
From: report at bugs.python.org (Deepak Dodo)
Date: Tue, 18 Oct 2011 19:32:38 +0000
Subject: [issue13208] Problems with urllib on windows
In-Reply-To: <1318938589.99.0.598751159325.issue13208@psf.upfronthosting.co.za>
Message-ID: <1318966358.47.0.920729232412.issue13208@psf.upfronthosting.co.za>


Deepak Dodo <deepakdodo at gmail.com> added the comment:

The log file is also attached. This error is because the entire content of the webpage has not been read.

----------
Added file: http://bugs.python.org/file23451/error.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13208>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:42:25 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Tue, 18 Oct 2011 19:42:25 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1318966945.61.0.169373275917.issue3067@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

Thanks for clarification! I see the problem now. So if I get this correctly we should change the _build_localename to raise TypeError? If the given locale is in wrong format, we'll get TypeError, but if it's valid type but otherwise invalid locale (like 'en'), we'll get ValueError (or more specifically locale.Error).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:45:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Oct 2011 19:45:57 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <E1RGFbl-00045U-Kf@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5841920d1ef6 by Victor Stinner in branch 'default':
Issue #12281: Skip code page tests on non-Windows platforms
http://hg.python.org/cpython/rev/5841920d1ef6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:53:14 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 18 Oct 2011 19:53:14 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1318966945.61.0.169373275917.issue3067@psf.upfronthosting.co.za>
Message-ID: <4E9DD926.5080800@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Thanks for clarification! I see the problem now. So if I get this
> correctly we should change the _build_localename to raise TypeError?

Yes, that's what I'm proposing.

> If the given locale is in wrong format, we'll get TypeError, but if
> it's valid type but otherwise invalid locale (like 'en'), we'll get
> ValueError (or more specifically locale.Error).

Ideally, yes. Notice that it will be difficult to produce a TypeError
for u"en", unless you explicitly test for Unicode objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Tue Oct 18 21:54:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Oct 2011 19:54:29 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <E1RGFk1-0004mL-UJ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 413b89242766 by Victor Stinner in branch 'default':
Issue #12281: Fix test_codecs.test_cp932() on Windows XP
http://hg.python.org/cpython/rev/413b89242766

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Tue Oct 18 22:04:34 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Tue, 18 Oct 2011 20:04:34 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1318968274.13.0.0508306798982.issue3067@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

Uploaded a new patch that raises TypeError

----------
Added file: http://bugs.python.org/file23452/issue3067_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3067>
_______________________________________

From report at bugs.python.org  Tue Oct 18 22:05:23 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 18 Oct 2011 20:05:23 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1318926357.56.0.330697503707.issue12174@psf.upfronthosting.co.za>
Message-ID: <1318968319.2616.YahooMailNeo@web25806.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Should there be another issue opened to do something about the extra logging 

> levels?

IMO they shouldn't have been added in the first place, but I'm not sure if they're part of the public API and hence subject to backward-compatibility constraints. It would be nice to hear a justification for them from Jesse (or someone else). Of course levels are a bit subjective and logging supports user-defined levels for special cases, but using multiple libs with different added levels would be a headache. I think at least the stdlib should stick to the standard levels.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Tue Oct 18 23:15:21 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Oct 2011 21:15:21 +0000
Subject: [issue13214] Cmd: list available completions from the cmd.Cmd
	subclass and filter out EOF handler(s)
In-Reply-To: <1318965366.62.0.48247525728.issue13214@psf.upfronthosting.co.za>
Message-ID: <1318972521.54.0.732330973527.issue13214@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This looks to be a reasonable request.

I think the patch would be better if the filtering were done directly in get_names().  A subclass can override or extend that method if it wants to customize the filter.

----------
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 3.3 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13214>
_______________________________________

From report at bugs.python.org  Tue Oct 18 23:36:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Oct 2011 21:36:00 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1318973760.23.0.824835900647.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_codecs pass on Windows XP and Windows Seven buildbots.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Tue Oct 18 23:39:19 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 18 Oct 2011 21:39:19 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <1318973959.77.0.475482535316.issue13150@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

10x for solution, 10x  for commit . 
Good bye cross compilation!
Any attempt  to improve python build system to support cross-build,  multilib build, build outside source tree with different options is useless.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Wed Oct 19 00:44:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Oct 2011 22:44:31 +0000
Subject: [issue13216] Add cp65001 codec
Message-ID: <1318977871.28.0.0371088882056.issue13216@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Thanks to #12281, it is now trivial to implement any Windows code page in Python. I don't know if existing code pages (e.g. cp932) should use codecs.code_page_encode/.code_page_decode on Windows, or continue to use the (portable) Python code.

Users want the code page 65001, even if I consider that it is useless to set the ANSI code page to 65001 in a console (see issue #1602), but that's a different story. Attached patch implements this code page.

----------
components: Unicode
files: cp65001.py
messages: 145871
nosy: amaury.forgeotdarc, haypo, loewis
priority: normal
severity: normal
status: open
title: Add cp65001 codec
versions: Python 3.3
Added file: http://bugs.python.org/file23453/cp65001.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13216>
_______________________________________

From report at bugs.python.org  Wed Oct 19 00:46:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Oct 2011 22:46:07 +0000
Subject: [issue13216] Add cp65001 codec
In-Reply-To: <1318977871.28.0.0371088882056.issue13216@psf.upfronthosting.co.za>
Message-ID: <1318977967.97.0.614608626903.issue13216@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Users want the code page 65001

See issues #6058, #7441 and #10920.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13216>
_______________________________________

From report at bugs.python.org  Wed Oct 19 00:51:36 2011
From: report at bugs.python.org (Bfontaine)
Date: Tue, 18 Oct 2011 22:51:36 +0000
Subject: [issue13173] Default values for string.Template
In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>
Message-ID: <1318978296.53.0.902231549689.issue13173@psf.upfronthosting.co.za>


Bfontaine <batifon at yahoo.fr> added the comment:

diff updated

----------
Added file: http://bugs.python.org/file23454/string_template_default_values2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13173>
_______________________________________

From report at bugs.python.org  Wed Oct 19 00:53:22 2011
From: report at bugs.python.org (Bfontaine)
Date: Tue, 18 Oct 2011 22:53:22 +0000
Subject: [issue13173] Default values for string.Template
In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>
Message-ID: <1318978402.44.0.581645480667.issue13173@psf.upfronthosting.co.za>


Bfontaine <batifon at yahoo.fr> added the comment:

A "light" version of diff added (rewrapped content is replaced by "[rewrapping]")

----------
Added file: http://bugs.python.org/file23455/string_template_default_values2-light.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13173>
_______________________________________

From report at bugs.python.org  Wed Oct 19 00:56:15 2011
From: report at bugs.python.org (=?utf-8?q?Kristoffer_Grundstr=C3=B6m?=)
Date: Tue, 18 Oct 2011 22:56:15 +0000
Subject: [issue12533] python-celementtree prevents me from running python
	develop.py to compile Imprudence Viewer
In-Reply-To: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>
Message-ID: <1318978575.48.0.315160166752.issue12533@psf.upfronthosting.co.za>


Kristoffer Grundstr?m <kristoffer.grundstrom1983 at gmail.com> added the comment:

Uhhhm. You could bypass the python-celementtree issue when compiling by editing fastest_celementree.py & uncommenting some lines so you compile using other instructions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12533>
_______________________________________

From report at bugs.python.org  Wed Oct 19 01:41:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Oct 2011 23:41:56 +0000
Subject: [issue13173] Default values for string.Template
In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>
Message-ID: <1318981316.78.0.322710249861.issue13173@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This looks like a reasonable use case.  That being said, I question whether the defaults should be attached directly to the template instance or whether they should be part of the substitution method.

FWIW, there already have a couple of other ways to do it:

>>> from string import Template
>>> s = Template("${user} made me a ${flavor} cake.")
>>> default = {"user":"Dennis"}
>>> s.substitute(default, flavor='vanilla')
'Dennis made me a vanilla cake.'
>>> s.substitute(default, user='Ken', flavor='vanilla')
'Ken made me a vanilla cake.'
 

>>> from collections import ChainMap
>>> s.substitute(ChainMap(dict(flavor='vanilla'), default))
'Dennis made me a vanilla cake.'

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13173>
_______________________________________

From report at bugs.python.org  Wed Oct 19 01:52:26 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Oct 2011 23:52:26 +0000
Subject: [issue13197] subprocess: move shell arguments to a separate keyword
	param
In-Reply-To: <1318851671.68.0.276363356463.issue13197@psf.upfronthosting.co.za>
Message-ID: <1318981946.12.0.478248964389.issue13197@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't think you can tighten the API at this point.  We could however make Popen complain when options are going to be thrown away.  Or it could be made more liberal about what is accepts (running shlex on string input or join on list input as needed).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13197>
_______________________________________

From report at bugs.python.org  Wed Oct 19 01:53:59 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Oct 2011 23:53:59 +0000
Subject: [issue13152] textwrap: support custom tabsize
In-Reply-To: <1318338300.67.0.514985359705.issue13152@psf.upfronthosting.co.za>
Message-ID: <1318982039.12.0.865863485275.issue13152@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13152>
_______________________________________

From report at bugs.python.org  Wed Oct 19 02:07:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 00:07:18 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <E1RGJgg-00008N-F2@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6ac59218c049 by ?ukasz Langa in branch '3.2':
Fixes #10860: Handle empty port after port delimiter in httplib
http://hg.python.org/cpython/rev/6ac59218c049

New changeset 18dc3811f2b8 by ?ukasz Langa in branch 'default':
Merged fix for #10860 from 3.2
http://hg.python.org/cpython/rev/18dc3811f2b8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Wed Oct 19 02:09:35 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 19 Oct 2011 00:09:35 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <1318982975.76.0.14560515242.issue10860@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Patch merged. Thanks, Shawn.

----------
nosy: +lukasz.langa
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Wed Oct 19 02:14:18 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 19 Oct 2011 00:14:18 +0000
Subject: [issue13217] Missing header dependencies in Makefile
Message-ID: <1318983258.55.0.960297108265.issue13217@psf.upfronthosting.co.za>


New submission from John O'Connor <tehjcon at gmail.com>:

I think ucs{1,2,4}lib.h, asciilib.h and a few other files should be in the Makefile deps list for unicodeobject.c. 

Patch included.

----------
components: Build
files: makefile.patch
keywords: patch
messages: 145881
nosy: haypo, jcon, pitrou
priority: normal
severity: normal
status: open
title: Missing header dependencies in Makefile
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23456/makefile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13217>
_______________________________________

From report at bugs.python.org  Wed Oct 19 02:15:28 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 19 Oct 2011 00:15:28 +0000
Subject: [issue13217] Missing header dependencies in Makefile
In-Reply-To: <1318983258.55.0.960297108265.issue13217@psf.upfronthosting.co.za>
Message-ID: <1318983328.24.0.971247361876.issue13217@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13217>
_______________________________________

From report at bugs.python.org  Wed Oct 19 02:21:41 2011
From: report at bugs.python.org (Justin Love)
Date: Wed, 19 Oct 2011 00:21:41 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1318983701.98.0.310171765686.issue11751@psf.upfronthosting.co.za>


Justin Love <python at JustinLove.name> added the comment:

re: test_glob_to_re

Could not reproduce (OS X 10.6)

I built branch 2.7, and also tried the expressions from glob_to_re on my system 2.7 and 3.2, all returned the (?ms) version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Wed Oct 19 02:41:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 00:41:28 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <E1RGKDk-0002Qw-Vy@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5c5c6a28b349 by ?ukasz Langa in branch 'default':
A ricochet from fixing #10680: http://http://example.com/ no longer reports
http://hg.python.org/cpython/rev/5c5c6a28b349

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Wed Oct 19 02:42:18 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 19 Oct 2011 00:42:18 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1318984938.89.0.165598823854.issue10680@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
Removed message: http://bugs.python.org/msg145883

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Wed Oct 19 03:19:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Oct 2011 01:19:15 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1318987155.2.0.313605520049.issue1757072@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

"This issue" is currently a collection point for specific "allow this in lax mode" issues.  Do you have one or more specific cases in point that you'd like to talk about?  (Note that the 'garbage after end of file' bug has already been fixed.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_______________________________________

From report at bugs.python.org  Wed Oct 19 04:06:07 2011
From: report at bugs.python.org (Shawn Ligocki)
Date: Wed, 19 Oct 2011 02:06:07 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <1318989967.32.0.859145953693.issue10860@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

Great! Glad it landed :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Wed Oct 19 07:06:59 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Oct 2011 05:06:59 +0000
Subject: [issue13121] collections.Counter's += copies the entire object
In-Reply-To: <1317977434.46.0.626100406816.issue13121@psf.upfronthosting.co.za>
Message-ID: <1319000819.12.0.528444315796.issue13121@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file23457/counter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13121>
_______________________________________

From report at bugs.python.org  Wed Oct 19 07:35:01 2011
From: report at bugs.python.org (David Barnett)
Date: Wed, 19 Oct 2011 05:35:01 +0000
Subject: [issue13205] NameErrors in generated setup.py (codecs,
	split_multiline)
In-Reply-To: <1318902833.17.0.0898413636747.issue13205@psf.upfronthosting.co.za>
Message-ID: <1319002501.37.0.296452776183.issue13205@psf.upfronthosting.co.za>


David Barnett <davidbarnett2 at gmail.com> added the comment:

Regression tests. Not positive that subprocess is the best approach for running these, but it seems to work.

In the process of writing tests, I discovered another missing import for PackagingFileError when there's no setup.cfg.

----------
Added file: http://bugs.python.org/file23458/test_command_generate_setup.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13205>
_______________________________________

From report at bugs.python.org  Wed Oct 19 08:13:36 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 19 Oct 2011 06:13:36 +0000
Subject: [issue13197] subprocess: move shell arguments to a separate keyword
	param
In-Reply-To: <1318851671.68.0.276363356463.issue13197@psf.upfronthosting.co.za>
Message-ID: <1319004816.24.0.924278643723.issue13197@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

List not only needs to be joined, it should be quoted as well. But the biggest problem will be the change of behavior between Python versions which may confuse users even more.

Perhaps it's a good time to start embedding 'best practice' recipes in manual.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13197>
_______________________________________

From report at bugs.python.org  Wed Oct 19 09:05:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Oct 2011 07:05:17 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1319007917.9.0.359988542163.issue13212@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I wonder if there are concrete use cases for loading/dumping basic types.
I see two options here:
1) we decide that load/dump should accept and produce only complete json object and go through a deprecation process, raising warnings first and errors then;
2) we decide that the correct behavior (loading/dumping basic types) is fine and that should be up to the user to check if the document has an array/object at the top level and then just document it (if it's not documented already).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Wed Oct 19 09:44:14 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 19 Oct 2011 07:44:14 +0000
Subject: [issue13141] get rid of old threading API in the examples
In-Reply-To: <1318192627.46.0.311858462486.issue13141@psf.upfronthosting.co.za>
Message-ID: <1319010254.58.0.924689496834.issue13141@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Proposed patch to refresh the socketserver examples.

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.2
Added file: http://bugs.python.org/file23459/issue13141.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13141>
_______________________________________

From report at bugs.python.org  Wed Oct 19 09:51:30 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 19 Oct 2011 07:51:30 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1319010690.17.0.873462065274.issue13210@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Martin, what I want to achieve is to ensure that someone can download Python sources and compile them without any modification using a standard install of Windows + Visual Studio 2010 SP1.

I don't really care what is the default compiler used to generate the official binaries, this is a decision that should be taken according to what most people use. But a least the compilation should work easily with the recent and popular VS2010 compiler.

As I said the patch is for the moment a quick and dirty draft: it breaks compilation with VS2008 and assume VS2010. Of course this is not my goal: the final patch should work with existing compilers as well as VS2010.

Which part of the changes do you consider unnecessary?

Concerning the target version: I need to use Python 2.7 internally because our application has not been migrated to Python 3.
I think other people may be in the same case.

I understand there is a feature freeze on this branch (event though the changes in this case are well localized and not intrusive), so I will target primarily Python trunk for the inclusion of patches, but I will also maintain internally my own set of patches for Python 2.7 (and in the wiki for those who are interested).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Wed Oct 19 09:53:44 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 Oct 2011 07:53:44 +0000
Subject: [issue13216] Add cp65001 codec
In-Reply-To: <1318977871.28.0.0371088882056.issue13216@psf.upfronthosting.co.za>
Message-ID: <1319010824.1.0.189730635035.issue13216@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

We shouldn't use the MS codec if we have our own, as they may differ.

As for the 65001 bug: is that actually solved by this codec?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13216>
_______________________________________

From report at bugs.python.org  Wed Oct 19 10:00:04 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 Oct 2011 08:00:04 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1319010690.17.0.873462065274.issue13210@psf.upfronthosting.co.za>
Message-ID: <4E9E8380.9090908@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Which part of the changes do you consider unnecessary?

All the parts dealing with packaging, in particular Tools/msi.

> I understand there is a feature freeze on this branch (event though
> the changes in this case are well localized and not intrusive), so I
> will target primarily Python trunk for the inclusion of patches, but
> I will also maintain internally my own set of patches for Python 2.7
> (and in the wiki for those who are interested).

Instead of doing so internally, I really suggest to maintain a public
hg clone, either on hg.python.org (by your name), or on, say, bitbucket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Wed Oct 19 10:09:19 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 19 Oct 2011 08:09:19 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1319011759.88.0.533789465022.issue13210@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Packaging makes it easier to distribute Python among my colleagues and customers, so I think it is a nice addition.

OK for the hg clone, I will set up that (I actually already use mercurial internally to handle those modifications).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Wed Oct 19 10:15:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 08:15:56 +0000
Subject: [issue13216] Add cp65001 codec
In-Reply-To: <1319010824.1.0.189730635035.issue13216@psf.upfronthosting.co.za>
Message-ID: <2373475.cDgd2V1OPN@dsk000552>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> We shouldn't use the MS codec if we have our own, as they may differ.

Ok, I agree. MS codec has a nice replacement behaviour (search for a similar 
glyph): cp1252 encodes ? to b'L' for example. Our codec raises a 
UnicodeEncodeError on u'\u0141'.encode('cp1252').

> As for the 65001 bug: is that actually solved by this codec?

Sorry, which bug?

See tests using CP_UTF8 in test_codecs. Depending on the Windows version, you 
don't get the same behaviour on surrogates. Before Windows Vista, surrogates 
were always encoded, whereas you can now choose the behaviour using the Python 
error handler:

        if self.vista_or_later():
            tests.append(('\udc80', 'strict', None)) # None=UnicodeEncodeError
            tests.append(('\udc80', 'ignore', b''))
            tests.append(('\udc80', 'replace', b'?'))
        else:
            tests.append(('\udc80', 'strict', b'\xed\xb2\x80'))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13216>
_______________________________________

From report at bugs.python.org  Wed Oct 19 10:29:37 2011
From: report at bugs.python.org (Tomasz Buchert)
Date: Wed, 19 Oct 2011 08:29:37 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1319012977.76.0.308255178283.issue13212@psf.upfronthosting.co.za>


Tomasz Buchert <thinred at gmail.com> added the comment:

It wouldn't be a problem if 'json' library would be a thing specific to Python. But JSON is used to gule together different technologies and programming languages. I'm afraid that the default behavior should be 1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Wed Oct 19 10:48:52 2011
From: report at bugs.python.org (=?utf-8?b?VsOtY3RvciBUZXJyw7Nu?=)
Date: Wed, 19 Oct 2011 08:48:52 +0000
Subject: [issue13163] `port` and `host` are confused in `_get_socket
In-Reply-To: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za>
Message-ID: <1319014132.96.0.154618289177.issue13163@psf.upfronthosting.co.za>


V?ctor Terr?n <quintanar at gmail.com> added the comment:

I have added a docstring to _get_socket.

My proposed news entry is almost exactly what you suggested (I have just replaced 'identity' with 'identify'): 
"Issue #13163: Fix smtplib.SMTP._get_socket so that tracebacks correctly identify host and port arguments."

----------
Added file: http://bugs.python.org/file23460/issue13163.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13163>
_______________________________________

From report at bugs.python.org  Wed Oct 19 10:49:43 2011
From: report at bugs.python.org (=?utf-8?b?VsOtY3RvciBUZXJyw7Nu?=)
Date: Wed, 19 Oct 2011 08:49:43 +0000
Subject: [issue13163] `port` and `host` are confused in `_get_socket
In-Reply-To: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za>
Message-ID: <1319014183.5.0.101778416166.issue13163@psf.upfronthosting.co.za>


Changes by V?ctor Terr?n <quintanar at gmail.com>:


Removed file: http://bugs.python.org/file23404/smtplib.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13163>
_______________________________________

From report at bugs.python.org  Wed Oct 19 13:35:38 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Oct 2011 11:35:38 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1319024138.9.0.738938345561.issue7475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

They were removed because adding new methods to builtin types violated the language moratorium.

Now that the language moratorium is over, the transform/untransform convenience APIs should be added again for 3.3. It's an approved change, the original timing was just wrong.

----------
assignee: lemburg -> 
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Wed Oct 19 13:52:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 11:52:58 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1319025178.07.0.357866658184.issue1602@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I done more tests on the Windows console. I focused my tests on output.

To sum up, if we implement sys.stdout using WriteConsoleW() and sys.stdout.buffer.raw using WriteConsoleA():

 - print() will not fail anymore on unencodable characters, because the string is no longer encoded to the console code page
 - if you set the console font to a TrueType font, most characters will be displayed correctly
 - you don't need to change the (console) code page to CP_UTF8 (65001) anymore if you just use print()
 - you still need cp65001 if the output (stdout and/or stderr) is redirected or if you use directly sys.stdout.buffer or sys.stderr.buffer

Other facts:

 - locale.getpreferredencoding() returns the ANSI code page
 - sys.stdin.encoding is the console encoding (GetConsoleCP())
 - sys.stdout.encoding and sys.stderr.encoding are the console output code page (GetConsoleOutputCP())
 - sys.stdout is not a TTY if the output is redirect, e.g. "python script.py|more"
 - sys.stderr is not a TTY if the output is redirect, e.g. "python script.py 2>&1|more" (this example redirects stdout and stderr, I don't know how to redirect only stderr)
 - WriteConsoleW() is not affected by the console output code page (GetConsoleOutputCP)
 - WriteConsoleA() is indirectly affected by the console output code page: if a string cannot be encoded to the console output code page (e.g. sys.stdout.encoding), you cannot call WriteConsoleA with the result...
 - If the console font is a raster font and and the font doesn't contain a character, the console tries to find a similar glyph, or it falls back to the character '?'
 - If the console font is a TrueType font, it is able to display most Unicode characters

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Wed Oct 19 13:55:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 11:55:13 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1319025313.95.0.7117973436.issue1602@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

unicode3.py replaces sys.stdout, sys.stdout.buffer, sys.stderr and sys.stderr.buffer to use WriteConsoleW() and WriteConsoleA(). It displays also a lot of information about encodings and displays some characters (I wrote my tests for cp850, cp1252 and cp65001).

----------
Added file: http://bugs.python.org/file23461/unicode3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Wed Oct 19 13:58:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Oct 2011 11:58:39 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1319025519.16.0.777347620106.issue7475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Sorry, I meant to state my rationale for the unassignment - I'm assuming this issue is covered by MAL's recent decision to step away from Unicode and codec maintenance issues. If that's incorrect, MAL can reclaim the issue, otherwise unassigning leaves it open for whoever wants to move it forward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Wed Oct 19 13:58:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 11:58:42 +0000
Subject: [issue13216] Add cp65001 codec
In-Reply-To: <1318977871.28.0.0371088882056.issue13216@psf.upfronthosting.co.za>
Message-ID: <1319025522.47.0.796194637014.issue13216@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I consider that it is useless to set the ANSI code page to 65001 in a console

I did more tests on the Windows console, focused on output, see:
http://bugs.python.org/issue1602#msg145898

I was wrong, it *is* useful to change the code page to 65001. Even if we have fully Unicode compliant sys.stdout and sys.stderr, setting the code page to CP_UTF8 (65001) does still improve Unicode support in some cases:

 - if the output (stdout and/or stderr) is redirected
 - if you encode Unicode to the console code page to use directly sys.stdout.buffer and sys.stderr.buffer

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13216>
_______________________________________

From report at bugs.python.org  Wed Oct 19 14:30:50 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 19 Oct 2011 12:30:50 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
Message-ID: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

Since upgrading to Ubuntu 11.10, I've been getting the following failures in test_ssl:

    ======================================================================
    FAIL: test_protocol_sslv3 (test.test_ssl.ThreadedTests)
    Connecting to an SSLv3 server with various client options
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/def/Lib/test/test_ssl.py", line 1415, in test_protocol_sslv3
        try_protocol_combo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv23, False)
      File "/home/nadeem/code/src/cpython/def/Lib/test/test_ssl.py", line 1232, in try_protocol_combo
        ssl.get_protocol_name(server_protocol)))
    AssertionError: Client protocol SSLv23 succeeded with server protocol SSLv3!

    ======================================================================
    FAIL: test_protocol_tlsv1 (test.test_ssl.ThreadedTests)
    Connecting to a TLSv1 server with various client options
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/def/Lib/test/test_ssl.py", line 1433, in test_protocol_tlsv1
        try_protocol_combo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv23, False)
      File "/home/nadeem/code/src/cpython/def/Lib/test/test_ssl.py", line 1232, in try_protocol_combo
        ssl.get_protocol_name(server_protocol)))
    AssertionError: Client protocol SSLv23 succeeded with server protocol TLSv1!

    ----------------------------------------------------------------------

and this (presumably related) failure in test_nntplib:

    ======================================================================
    ERROR: setUpClass (test.test_nntplib.NetworkedNNTP_SSLTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/def/Lib/test/test_nntplib.py", line 291, in setUpClass
        cls.server = cls.NNTP_CLASS(cls.NNTP_HOST, timeout=TIMEOUT, usenetrc=False)
      File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 1052, in __init__
        readermode=readermode, timeout=timeout)
      File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 344, in __init__
        self.getcapabilities()
      File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 380, in getcapabilities
        resp, caps = self.capabilities()
      File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 546, in capabilities
        resp, lines = self._longcmdstring("CAPABILITIES")
      File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 513, in _longcmdstring
        resp, list = self._getlongresp(file)
      File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 464, in _getlongresp
        resp = self._getresp()
      File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 437, in _getresp
        resp = self._getline()
      File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 425, in _getline
        if not line: raise EOFError
    EOFError

3.2 gives a different set of failures in test_ssl (with the same failure in test_nntplib):

    ======================================================================
    ERROR: test_constructor (test.test_ssl.ContextTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f
        return func(*args, **kwargs)
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 345, in test_constructor
        ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv2)
      File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__
        return _SSLContext.__new__(cls, protocol)
    ssl.SSLError: failed to allocate SSL context

    ======================================================================
    ERROR: test_protocol (test.test_ssl.ContextTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f
        return func(*args, **kwargs)
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 356, in test_protocol
        ctx = ssl.SSLContext(proto)
      File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__
        return _SSLContext.__new__(cls, protocol)
    ssl.SSLError: failed to allocate SSL context

    ======================================================================
    ERROR: test_session_stats (test.test_ssl.ContextTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f
        return func(*args, **kwargs)
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 453, in test_session_stats
        ctx = ssl.SSLContext(proto)
      File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__
        return _SSLContext.__new__(cls, protocol)
    ssl.SSLError: failed to allocate SSL context

    ======================================================================
    ERROR: test_echo (test.test_ssl.ThreadedTests)
    Basic test of an SSL client connecting to a server
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f
        return func(*args, **kwargs)
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1147, in test_echo
        context = ssl.SSLContext(protocol)
      File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__
        return _SSLContext.__new__(cls, protocol)
    ssl.SSLError: failed to allocate SSL context

    ======================================================================
    ERROR: test_protocol_sslv2 (test.test_ssl.ThreadedTests)
    Connecting to an SSLv2 server with various client options
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f
        return func(*args, **kwargs)
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1256, in test_protocol_sslv2
        try_protocol_combo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv2, True)
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1108, in try_protocol_combo
        client_context = ssl.SSLContext(client_protocol)
      File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__
        return _SSLContext.__new__(cls, protocol)
    ssl.SSLError: failed to allocate SSL context

    ======================================================================
    ERROR: test_protocol_sslv3 (test.test_ssl.ThreadedTests)
    Connecting to an SSLv3 server with various client options
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f
        return func(*args, **kwargs)
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1317, in test_protocol_sslv3
        try_protocol_combo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv2, False)
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1108, in try_protocol_combo
        client_context = ssl.SSLContext(client_protocol)
      File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__
        return _SSLContext.__new__(cls, protocol)
    ssl.SSLError: failed to allocate SSL context

    ======================================================================
    ERROR: test_protocol_tlsv1 (test.test_ssl.ThreadedTests)
    Connecting to a TLSv1 server with various client options
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f
        return func(*args, **kwargs)
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1334, in test_protocol_tlsv1
        try_protocol_combo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv2, False)
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1108, in try_protocol_combo
        client_context = ssl.SSLContext(client_protocol)
      File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__
        return _SSLContext.__new__(cls, protocol)
    ssl.SSLError: failed to allocate SSL context

    ======================================================================
    FAIL: test_options (test.test_ssl.ContextTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f
        return func(*args, **kwargs)
      File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 370, in test_options
        self.assertEqual(ssl.OP_ALL, ctx.options)
    AssertionError: 4095 != 16781311

    ----------------------------------------------------------------------

On 2.7, the failures are again different:

    ======================================================================
    ERROR: test_protocol_sslv2 (test.test_ssl.ThreadedTests)
    Connecting to an SSLv2 server with various client options
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 75, in f
        return func(*args, **kwargs)
      File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 986, in test_protocol_sslv2
        try_protocol_combo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv2, True)
      File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 856, in try_protocol_combo
        ciphers="ALL", chatty=False)
      File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 808, in server_params_test
        s.connect((HOST, server.port))
      File "/home/nadeem/code/src/cpython/2.7/Lib/ssl.py", line 322, in connect
        self._real_connect(addr, False)
      File "/home/nadeem/code/src/cpython/2.7/Lib/ssl.py", line 305, in _real_connect
        self.ca_certs, self.ciphers)
    SSLError: _ssl.c:316: Invalid SSL protocol variant specified.

    ======================================================================
    FAIL: test_protocol_sslv3 (test.test_ssl.ThreadedTests)
    Connecting to an SSLv3 server with various client options
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 75, in f
        return func(*args, **kwargs)
      File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 1028, in test_protocol_sslv3
        try_protocol_combo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv23, False)
      File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 870, in try_protocol_combo
        ssl.get_protocol_name(server_protocol)))
    AssertionError: Client protocol SSLv23 succeeded with server protocol SSLv3!

    ======================================================================
    FAIL: test_protocol_tlsv1 (test.test_ssl.ThreadedTests)
    Connecting to a TLSv1 server with various client options
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 75, in f
        return func(*args, **kwargs)
      File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 1042, in test_protocol_tlsv1
        try_protocol_combo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv23, False)
      File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 870, in try_protocol_combo
        ssl.get_protocol_name(server_protocol)))
    AssertionError: Client protocol SSLv23 succeeded with server protocol TLSv1!

    ----------------------------------------------------------------------

The failures were probably caused by Ubuntu upgrading from openssl-0.9.8 to
openssl-1.0.0 in 11.10 -- I've reproduced the failures on three different
Ubuntu 11.10 machines, and none of the buildbots are having this problem.

For reference, the list of changes between 0.9.8 and 1.0.0 (look for the section
"Changes between 0.9.8n and 1.0.0 [29 Mar 2010]"):

    http://www.openssl.org/news/changelog.html

----------
components: Extension Modules
messages: 145902
nosy: giampaolo.rodola, janssen, nadeem.vawda, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl failures on Ubuntu 11.10
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 14:33:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Oct 2011 12:33:58 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319027638.09.0.588118579484.issue13218@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

All the tests work fine with OpenSSL 1.0.0d under Mageia. Could you look into Ubuntu-specific patches to OpenSSL? They have known to add disruptive changes (we already have some Ubuntu-specific code in test_ssl).

Also, how about the system Python? Does it show the same test failures?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 14:41:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Oct 2011 12:41:25 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319028085.52.0.485201095732.issue13218@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, I think you may just have to fix skip_if_broken_ubuntu_ssl() in test_ssl.py. Could you give it a try?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 15:02:24 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 19 Oct 2011 13:02:24 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319029344.33.0.839701161333.issue13218@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Also, how about the system Python? Does it show the same test failures?

Unfortunately, it seems that the system Python package doesn't install the
test suite; if you try to run "python -m test.regrtest", it complains that
it can't find the test modules.

> Actually, I think you may just have to fix skip_if_broken_ubuntu_ssl() in test_ssl.py. Could you give it a try?

I'll take a look over the weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 15:45:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 13:45:41 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319031941.61.0.887744609657.issue13218@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch updates skip_if_broken_ubuntu_ssl(): OpenSSL in Ubuntu is still broken :-( OpenSSL package version is 1.0.0e-2ubuntu4 but in Python, ssl.OPENSSL_VERSION_INFO is still (0, 9, 8, 15, 15) !?

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file23462/test_ssl_broken_ubuntu.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 15:47:10 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 19 Oct 2011 13:47:10 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319032030.75.0.830958372093.issue13218@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy:  -giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 16:00:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Oct 2011 14:00:12 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319031941.61.0.887744609657.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319032575.3230.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Attached patch updates skip_if_broken_ubuntu_ssl(): OpenSSL in Ubuntu
> is still broken :-( OpenSSL package version is 1.0.0e-2ubuntu4 but in
> Python, ssl.OPENSSL_VERSION_INFO is still (0, 9, 8, 15, 15) !?

Are you sure? Did you rebuild?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 16:05:40 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 19 Oct 2011 14:05:40 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319033140.03.0.341496324442.issue13218@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I get (1, 0, 0, 5, 15) for ssl.OPENSSL_VERSION_INFO. A trivial modification
of Victor's patch doesn't seem to fix the failures for me, though :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 16:08:11 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 19 Oct 2011 14:08:11 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319033291.35.0.0968834273462.issue13218@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Sorry, that wasn't very coherent. What I meant to say is that I tried this:

    if ((ssl.OPENSSL_VERSION_INFO, platform.linux_distribution()) in
        [((0, 9, 8, 15, 15), ('debian', 'squeeze/sid', '')),
         ((1, 0, 0,  5, 15), ('debian',  'wheezy/sid', ''))]):
        raise unittest.SkipTest("Patched Ubuntu OpenSSL breaks behaviour")

on the default branch, and I'm still getting the same failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 16:09:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 14:09:32 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319033372.52.0.0383148427627.issue13218@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> ssl.OPENSSL_VERSION_INFO is still (0, 9, 8, 15, 15)

After a recompilation, I get (1, 0, 0, 5, 15) and ssl doesn't has PROTOCOL_SSLv2. test_ssl is failing with:


======================================================================
FAIL: test_protocol_sslv3 (test.test_ssl.ThreadedTests)
Connecting to an SSLv3 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/prog/python/default/Lib/test/test_ssl.py", line 1415, in test_protocol_sslv3
    try_protocol_combo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv23, False)
  File "/home/vstinner/prog/python/default/Lib/test/test_ssl.py", line 1232, in try_protocol_combo
    ssl.get_protocol_name(server_protocol)))
AssertionError: Client protocol SSLv23 succeeded with server protocol SSLv3!

======================================================================
FAIL: test_protocol_tlsv1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/prog/python/default/Lib/test/test_ssl.py", line 1433, in test_protocol_tlsv1
    try_protocol_combo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv23, False)
  File "/home/vstinner/prog/python/default/Lib/test/test_ssl.py", line 1232, in try_protocol_combo
    ssl.get_protocol_name(server_protocol)))
AssertionError: Client protocol SSLv23 succeeded with server protocol TLSv1!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 16:14:40 2011
From: report at bugs.python.org (becky lewis)
Date: Wed, 19 Oct 2011 14:14:40 +0000
Subject: [issue13219] re module doc has minor inaccuracy in character sets
Message-ID: <1319033680.8.0.92268984905.issue13219@psf.upfronthosting.co.za>


New submission from becky lewis <bex.lewis at gmail.com>:

The documentation for the re module  (specifically the section for []) states that:

"If you want to include a ']' or a '-' inside a set, precede it with a backslash, or place it as the first character."

However, after finding a typo in a regex I wrote it turns out to be false.

Using the following regex finds a match:
>>> regex = re.compile(r'[123ab-f-]+')
>>> regex.match('-')
<_sre.SRE_Match object at 0x8dd1b10>

I am not sure if this is an issue with the documentation or if the re module itself should not allow this behaviour. It would be nice if the documentation warned that hyphens (and other 'special' characters such as [) that are not escaped may still be matched, even though they are not the first character.

----------
assignee: docs at python
components: Documentation
messages: 145911
nosy: becky.lewis, docs at python
priority: normal
severity: normal
status: open
title: re module doc has minor inaccuracy in character sets
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13219>
_______________________________________

From report at bugs.python.org  Wed Oct 19 16:22:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Oct 2011 14:22:57 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319033372.52.0.0383148427627.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319033940.3230.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> AssertionError: Client protocol SSLv23 succeeded with server protocol SSLv3!
> AssertionError: Client protocol SSLv23 succeeded with server protocol TLSv1!

Hmm... I guess Ubuntu may have aliased SSLv23 to SSLv3. Can someone take
a look at Ubuntu patches to OpenSSL?
I also think we could relax these tests. After all, they're testing
OpenSSL's functionality, not really our own code.

Regardless, I really don't like the way Ubuntu change semantics of a
*library* they're packaging...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 17:28:02 2011
From: report at bugs.python.org (ben)
Date: Wed, 19 Oct 2011 15:28:02 +0000
Subject: [issue13220] print function unable while multiprocessing.Process is
	being run
Message-ID: <1319038082.58.0.169311394229.issue13220@psf.upfronthosting.co.za>


New submission from ben <thelen_ben at yahoo.com>:

print function unable while multiprocessing.Process is being run

Not sure if this really is a bug, but the multiprocessing.Process (or Pool) does not allow to print during multiprocessing tasks.

I've copied the example from The Python V3.2.2 documentation, library reference, multiprocessing (3rd example).

My systems details are: MS windows xp or Windows 7, IDLE, Python 3.2.2 [MSC v.1500 32 bit (Intel)] on win32

from multiprocessing import Process
import os

def info(title):
    print(title)
    print('module name:', __name__)
    print('parent process:', os.getppid())
    print('process id:', os.getpid())

def f(name):
    info('function f')
    print('hello', name)

if __name__ == '__main__':
    info('main line')
    p = Process(target=f, args=('bob',))
    p.start()
    p.join()


#return

#main line
#module name: __main__
#parent process: 1588
#process id: 3700

#but function f doesn't get printed.

----------
components: Library (Lib)
files: mp.py
messages: 145913
nosy: Ben.thelen
priority: normal
severity: normal
status: open
title: print function unable while multiprocessing.Process is being run
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file23463/mp.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13220>
_______________________________________

From report at bugs.python.org  Wed Oct 19 17:31:17 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 19 Oct 2011 15:31:17 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319038277.34.0.792706206825.issue13218@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Hmm... I guess Ubuntu may have aliased SSLv23 to SSLv3. Can someone take
> a look at Ubuntu patches to OpenSSL?

I don't know enough about OpenSSL to make sense of the actual headers on my
system without spending more time on it, but it seems like Debian have disabled
SSLv2 altogether <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706>.
Could this be the source of the problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 17:44:51 2011
From: report at bugs.python.org (Bfontaine)
Date: Wed, 19 Oct 2011 15:44:51 +0000
Subject: [issue13173] Default values for string.Template
In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>
Message-ID: <1319039091.27.0.51184860319.issue13173@psf.upfronthosting.co.za>


Bfontaine <batifon at yahoo.fr> added the comment:

When you are using a lot of string templates like I am doing, I think it's better if the defaults is attached directly to the template instance.

This:
[<Template0>, <Template1>, <Template2>, <Template3>, ...]
is easier to use than:
[(<Template0>, <defaults0>), (<Template1>, <defaults>1), ...]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13173>
_______________________________________

From report at bugs.python.org  Wed Oct 19 17:57:32 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Oct 2011 15:57:32 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1319039852.15.0.591931535787.issue13212@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm thinking that we should offer a strict-option (off by default) and leave it at that.  No need to break existing code.   AFAICT, the OP is the only one to have had problems with this in-practice (the JSON module or its ancestor simplejson has been around for a long time).

Am marking this as a high priority but want to leave it open for a good while to get more comments before taking any action.

----------
assignee:  -> rhettinger
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Wed Oct 19 17:58:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 15:58:46 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1319039926.74.0.962313076635.issue13212@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Wed Oct 19 18:05:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Oct 2011 16:05:24 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1319040324.57.0.892332728755.issue13212@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed that a strict parameter would be a good idea to implement this.
Since it's technically a new feature (and not that important), I think only 3.3 should receive it.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Wed Oct 19 18:09:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Oct 2011 16:09:20 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1319040560.43.0.211073620036.issue6715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Apart from this, is there anything else that needs to be done before this
> change can be committed to the main repo?

Things look fine to me, apart from a couple of minor comments I've made on the review tool.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct 19 18:23:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 16:23:49 +0000
Subject: [issue12989] Consistently handle path separator in Py_GetPath on
	Windows
In-Reply-To: <1316131696.55.0.834479609561.issue12989@psf.upfronthosting.co.za>
Message-ID: <1319041429.76.0.213084956324.issue12989@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12989>
_______________________________________

From report at bugs.python.org  Wed Oct 19 18:53:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 16:53:10 +0000
Subject: [issue12529] cgi.parse_header fails on double quotes and semicolons
In-Reply-To: <1310331365.35.0.0304262740475.issue12529@psf.upfronthosting.co.za>
Message-ID: <E1RGZO6-0002DG-HV@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 489237756488 by Senthil Kumaran in branch '2.7':
Fix closes Issue12529 - cgi.parse_header failure on double quotes and
http://hg.python.org/cpython/rev/489237756488

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12529>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:07:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 17:07:16 +0000
Subject: [issue12529] cgi.parse_header fails on double quotes and semicolons
In-Reply-To: <1310331365.35.0.0304262740475.issue12529@psf.upfronthosting.co.za>
Message-ID: <E1RGZbk-0003x9-FB@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f5bd78b11275 by Senthil Kumaran in branch '3.2':
3.2 - Fix closes Issue12529 - cgi.parse_header failure on double quotes and
http://hg.python.org/cpython/rev/f5bd78b11275

New changeset 8564d2b240b6 by Senthil Kumaran in branch 'default':
default - Fix closes Issue12529 - cgi.parse_header failure on double quotes and
http://hg.python.org/cpython/rev/8564d2b240b6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12529>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:08:21 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 19 Oct 2011 17:08:21 +0000
Subject: [issue12529] cgi.parse_header fails on double quotes and semicolons
In-Reply-To: <1310331365.35.0.0304262740475.issue12529@psf.upfronthosting.co.za>
Message-ID: <1319044101.49.0.219621945036.issue12529@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for the patch, Petri and Ben.Darnell.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12529>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:11:15 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 Oct 2011 17:11:15 +0000
Subject: [issue13216] Add cp65001 codec
In-Reply-To: <2373475.cDgd2V1OPN@dsk000552>
Message-ID: <4E9F04AA.7070509@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> As for the 65001 bug: is that actually solved by this codec?
> 
> Sorry, which bug?

#6501 and friends (isn't it interesting that the issue of code page
65001 is reported as bug 6501?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13216>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:21:47 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 19 Oct 2011 17:21:47 +0000
Subject: [issue13193] test_packaging and test_distutils failures under Windows
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1319044907.41.0.954998883671.issue13193@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> The test creates a temporary directory which is inserted at the head of sys.path.
> packaging.database.get_distribution should thus find Spamlib-0.1.dist-info.
> Can someone with a Windows install help me with this?  Printing sys.path and
> os.listdir(sys.path[0]) would be a good start.

    test_resources (packaging.tests.test_command_install_data.InstallDataTestCase) ...
    sys.path: ['c:\\users\\nadeem\\appdata\\local\\temp\\tmpi7pf1f\\tmp4gdwnp',
               '',
               'C:\\Users\\Nadeem\\Code\\python3\\python\\PCbuild\\python33_d.zip',
               'C:\\Users\\Nadeem\\Code\\python3\\python\\DLLs',
               'C:\\Users\\Nadeem\\Code\\python3\\python\\lib',
               'C:\\Users\\Nadeem\\Code\\python3\\python\\PCbuild',
               'C:\\Users\\Nadeem\\AppData\\Roaming\\Python\\Python33\\site-packages',
               'C:\\Users\\Nadeem\\Code\\python3\\python',
               'C:\\Users\\Nadeem\\Code\\python3\\python\\lib\\site-packages']
    os.listdir(sys.path[0]): ['Spamlib-0.1.dist-info']
    ERROR

I noticed that the test succeeds if you run only the InstallDataTestCase (with
"... -v -m InstallDataTestCase test_packaging"), but the sys.path info for this
case is the same as before (modulo the name of the temp directory):

    test_resources (packaging.tests.test_command_install_data.InstallDataTestCase) ...
    sys.path: ['c:\\users\\nadeem\\appdata\\local\\temp\\tmpddi17y\\tmp1mnv9z',
               '',
               'C:\\Users\\Nadeem\\Code\\python3\\python\\PCbuild\\python33_d.zip',
               'C:\\Users\\Nadeem\\Code\\python3\\python\\DLLs',
               'C:\\Users\\Nadeem\\Code\\python3\\python\\lib',
               'C:\\Users\\Nadeem\\Code\\python3\\python\\PCbuild',
               'C:\\Users\\Nadeem\\AppData\\Roaming\\Python\\Python33\\site-packages',
               'C:\\Users\\Nadeem\\Code\\python3\\python',
               'C:\\Users\\Nadeem\\Code\\python3\\python\\lib\\site-packages']
    os.listdir(sys.path[0]): ['Spamlib-0.1.dist-info']
    ok

Additionally, I've been getting a similar failure on my Ubuntu machine:

    ======================================================================
    ERROR: test_resources (packaging.tests.test_command_install_data.InstallDataTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/def/Lib/packaging/tests/test_command_install_data.py", line 129, in test_resources
        with packaging.database.get_file('Spamlib', 'spamd') as fp:
      File "/home/nadeem/code/src/cpython/def/Lib/packaging/database.py", line 649, in get_file
        return open(get_file_path(distribution_name, relative_path),
      File "/home/nadeem/code/src/cpython/def/Lib/packaging/database.py", line 644, in get_file_path
        raise LookupError('no distribution named %r found' % distribution_name)
    LookupError: no distribution named 'Spamlib' found

Output from Ubuntu machine:

    test_resources (packaging.tests.test_command_install_data.InstallDataTestCase) ...
    sys.path: ['/tmp/tmpubkdye/tmpdmdybx',
               '',
               '/usr/local/lib/python33.zip',
               '/home/nadeem/code/src/cpython/def/Lib',
               '/home/nadeem/code/src/cpython/def/Lib/plat-linux',
               '/home/nadeem/code/src/cpython/def/build/lib.linux-x86_64-3.3',
               '/home/nadeem/.local/lib/python3.3/site-packages',
               '/usr/local/lib/python3.3/site-packages']
    os.listdir(sys.path[0]): ['Spamlib-0.1.dist-info']
    ERROR

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:22:45 2011
From: report at bugs.python.org (Matthias Schreiber)
Date: Wed, 19 Oct 2011 17:22:45 +0000
Subject: [issue13221] No "edit with IDLE" in right click context menu
Message-ID: <1319044965.54.0.660981699643.issue13221@psf.upfronthosting.co.za>


New submission from Matthias Schreiber <antextides at googlemail.com>:

I dont have the context menu "edit with IDLE" anymore.
I installed Python 3.2 first and then 2.7
I tried to open a .py file that's written with 3.2, but it were opened with the 2.7 IDLE.
So I uninstalled 2.7 and tried to open it again.
Now the context menu were missed.
I tried to open it over "Open with..." with other applications.
I re-installed 3.2 and also repaired it, but the "edit with IDLE" is still not there.

----------
components: IDLE
messages: 145924
nosy: Matthias.Schreiber
priority: normal
severity: normal
status: open
title: No "edit with IDLE" in right click context menu
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13221>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:36:40 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 19 Oct 2011 17:36:40 +0000
Subject: [issue13193] test_packaging and test_distutils failures under Windows
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1319045800.59.0.24649736795.issue13193@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:37:03 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 19 Oct 2011 17:37:03 +0000
Subject: [issue12989] Consistently handle path separator in Py_GetPath on
	Windows
In-Reply-To: <1316131696.55.0.834479609561.issue12989@psf.upfronthosting.co.za>
Message-ID: <1319045823.36.0.426025026907.issue12989@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12989>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:44:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 17:44:23 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319046263.37.0.963399044358.issue13218@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:44:27 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 19 Oct 2011 17:44:27 +0000
Subject: [issue992389] attribute error due to circular import
Message-ID: <1319046267.23.0.30520315407.issue992389@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:53:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 17:53:02 +0000
Subject: [issue6090] zipfile: Bad error message when zipping a file with
	timestamp before 1980
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <E1RGaK2-0008Nh-45@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 649ac338203f by Senthil Kumaran in branch '2.7':
Fix closes Issue6090 - Raise a ValueError, instead of failing with unrelated
http://hg.python.org/cpython/rev/649ac338203f

New changeset 12f3e86e9041 by Senthil Kumaran in branch '3.2':
3.2 - Fix closes Issue6090 - Raise a ValueError, instead of failing with unrelated
http://hg.python.org/cpython/rev/12f3e86e9041

New changeset 55318658e1be by Senthil Kumaran in branch 'default':
default - Fix closes Issue6090 - Raise a ValueError, instead of failing with unrelated
http://hg.python.org/cpython/rev/55318658e1be

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6090>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:54:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 17:54:19 +0000
Subject: [issue13205] NameErrors in generated setup.py (codecs,
	split_multiline)
In-Reply-To: <1318902833.17.0.0898413636747.issue13205@psf.upfronthosting.co.za>
Message-ID: <1319046859.86.0.0616297749319.issue13205@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Excellent, thanks!  I?ll move the tests into the existing test_run.py file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13205>
_______________________________________

From report at bugs.python.org  Wed Oct 19 19:54:47 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 19 Oct 2011 17:54:47 +0000
Subject: [issue6090] zipfile: Bad error message when zipping a file with
	timestamp before 1980
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <1319046887.44.0.928019150706.issue6090@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Fixed in all active branches. Thanks for the patch, Petri. 
Mark, for this issue, raising ValueError from zipfile was seemingly a  right thing to do, the previous error from struct for a side effect of sending a value lower than 1980.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6090>
_______________________________________

From report at bugs.python.org  Wed Oct 19 20:15:32 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 19 Oct 2011 18:15:32 +0000
Subject: [issue5788] datetime.timedelta is inconvenient to use...
In-Reply-To: <1240079860.62.0.329216013715.issue5788@psf.upfronthosting.co.za>
Message-ID: <1319048132.21.0.11918040215.issue5788@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Sorry for commenting on a closed issue but I just bumped into a problem requiring a total_minute() method I ended up implementing by doing some raw math by hand.
Would it be a reasonable addition?
If so I'll open a separate issue.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5788>
_______________________________________

From report at bugs.python.org  Wed Oct 19 20:15:50 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 19 Oct 2011 18:15:50 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1319048150.0.0.9646204183.issue12170@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Thanks for the review, Antoine. Attached an updated the patch:

- The function definition now uses STRINGLIB(...) and the function is only defined when !STRINGLIB_IS_UNICODE (so I took both approaches)

- Added a "versionadded:: 3.3" to the documentation.

----------
Added file: http://bugs.python.org/file23464/issue12170_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Wed Oct 19 20:17:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 18:17:19 +0000
Subject: [issue12604] VTRACE macro in _sre.c should use do {} while (0)
In-Reply-To: <1311280694.44.0.358463373739.issue12604@psf.upfronthosting.co.za>
Message-ID: <E1RGahX-00029V-TL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f35514dfadf8 by Senthil Kumaran in branch '2.7':
Fix Issue 12604 - Use a proper no-op macro expansion for VTRACE macro in _sre.c
http://hg.python.org/cpython/rev/f35514dfadf8

New changeset ab028084f704 by Senthil Kumaran in branch '3.2':
3.2 - Fix Issue 12604 - Use a proper no-op macro expansion for VTRACE macro in _sre.c
http://hg.python.org/cpython/rev/ab028084f704

New changeset 847afc310190 by Senthil Kumaran in branch 'default':
default - Fix closes Issue 12604 - Use a proper no-op macro expansion for VTRACE macro in _sre.c
http://hg.python.org/cpython/rev/847afc310190

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12604>
_______________________________________

From report at bugs.python.org  Wed Oct 19 20:17:33 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 19 Oct 2011 18:17:33 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1319048253.22.0.510624583418.issue12170@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


Removed file: http://bugs.python.org/file23464/issue12170_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Wed Oct 19 20:18:26 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 19 Oct 2011 18:18:26 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1319048306.03.0.945533869393.issue12170@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Fixed a minor inconsistency.

----------
Added file: http://bugs.python.org/file23465/issue12170_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Wed Oct 19 20:25:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 18:25:33 +0000
Subject: [issue13216] Add cp65001 codec
In-Reply-To: <1318977871.28.0.0371088882056.issue13216@psf.upfronthosting.co.za>
Message-ID: <1319048733.47.0.680537139866.issue13216@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > Sorry, which bug?

> #6501 and friends

Hum, this particular issue, #6501, doesn't concern the code page 65001. The typical usecase (issues #7441 and #10920) is:
------------
C:\victor\cpython>chcp 65001
Page de codes active?: 65001

C:\victor\cpython>pcbuild\python_d.exe
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp65001
------------

The console and console output code pages may be changed by something else.

The current workaround is to set PYTHONIOENCODING environment variable to utf-8, but as explained in msg132831, the workaround is not applicable if Python is embeded or if the program has been frozen by cx-freeze ("cx-freeze deliberately sets Py_IgnoreEnvironmentFlag").

--

The issue #6501 was a bug in io.device_encoding(). I fixed it in Python 3.3 and I'm waiting... since 5 months... for Graham Dumpleton before backporting the fix. The issue suggests also to not fail if the encoding cannot be found (I dislike this idea).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13216>
_______________________________________

From report at bugs.python.org  Wed Oct 19 20:29:12 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 19 Oct 2011 18:29:12 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <1319048952.34.0.71990014196.issue12367@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

The AMD64 FreeBSD 8.2 3.x buildbot has been experiencing sporadic
lockups since changeset 8bbfb24d4824 was committed:

    http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1174/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1180/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1185/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1190/steps/test/logs/stdio

The tracebacks say that the lockups are happening in test_errno,
which is weird because the test is supposed to be skipped on
FreeBSD. Is it possible that sys.platform is returning something
that doesn't start with "freebsd" on this buildbot?

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Wed Oct 19 20:34:06 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 19 Oct 2011 18:34:06 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <1319049246.7.0.948504622545.issue12367@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Sorry, please disregard my last message - I confused the commit times for
8bbfb24d4824 and f6b8e4226260. There haven't been any further lockups
since f6b8e4226260 was committed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Wed Oct 19 20:34:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 18:34:16 +0000
Subject: [issue12367] select.error has no errno attribute
In-Reply-To: <1308514938.77.0.387292853061.issue12367@psf.upfronthosting.co.za>
Message-ID: <1319049256.94.0.581220916489.issue12367@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The tracebacks say that the lockups are happening in test_errno

The test was added by f6b8e4226260 the 17th october, the last lockup occurred the 16th (19:08:15).

Before, I added a workaround to see the failure but avoid the lockup: 60fecfbea397 (Oct 16 20:48:52, just after the last failure).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12367>
_______________________________________

From report at bugs.python.org  Wed Oct 19 20:53:48 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 19 Oct 2011 18:53:48 +0000
Subject: [issue13222] Erroneous unclosed file warning
Message-ID: <1319050428.96.0.600308451611.issue13222@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

/opt/python3.2/lib/python3.2/site-packages/psutil/_pslinux.py:389: ResourceWarning: unclosed file <_io.FileIO name=7 mode='rb'>
  return [x for x in f.read().split('\x00') if x]

I get this while running tests.
The method in question is defined as such:

    @wrap_exceptions
    def get_process_cmdline(self):
        f = open("/proc/%s/cmdline" % self.pid)
        try:
            # return the args as a list
            return [x for x in f.read().split('\x00') if x]
        finally:
            f.close()

...therefore, I'm closing the file object (in the finally block).

----------
messages: 145936
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: Erroneous unclosed file warning
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13222>
_______________________________________

From report at bugs.python.org  Wed Oct 19 20:59:42 2011
From: report at bugs.python.org (Cameron Hayne)
Date: Wed, 19 Oct 2011 18:59:42 +0000
Subject: [issue13223] pydoc removes 'self' in HTML for method docstrings with
	example code
Message-ID: <1319050782.47.0.924539258184.issue13223@psf.upfronthosting.co.za>


New submission from Cameron Hayne <cameron.hayne at gmail.com>:

If the docstring for a method has example code that uses 'self',
the 'self' will not appear in the HTML generated by pydoc.writedoc

Example:
#---------------------------------
def getAnswer(self):
    """
    Return the answer.
    Example of use:
        answer = self.getAnswer()
    """
    return 42
#---------------------------------

The generated HTML will have:

getAnswer(self)
    Return the answer.
    Example of use:
        answer = getAnswer()

where the final "getAnswer" is an HTML link.
--------------------------------------------

I believe the problem arises on line 553 of the Python 2.7 version of pydoc.py which is as follows:
    results.append(self.namelink(name, methods, funcs, classes))
The appended text is the same whether or not the method call in the docstring was prefaced with 'self' or not. The 'self' has been eaten up by the regex and is in the 'selfdot' variable which is ignored by the above line.

----------
components: Library (Lib)
messages: 145937
nosy: Cameron.Hayne
priority: normal
severity: normal
status: open
title: pydoc removes 'self' in HTML for method docstrings with example code
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13223>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:05:09 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 19 Oct 2011 19:05:09 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1319051109.25.0.771191085886.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


Added file: http://bugs.python.org/file23466/371a133b770a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:05:55 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 19 Oct 2011 19:05:55 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1319051155.13.0.964457569613.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


Removed file: http://bugs.python.org/file23393/bdf0afbbbd80.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:06:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Oct 2011 19:06:39 +0000
Subject: [issue13222] Erroneous unclosed file warning
In-Reply-To: <1319050428.96.0.600308451611.issue13222@psf.upfronthosting.co.za>
Message-ID: <1319051199.5.0.122066041247.issue13222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Since the "name" is 7, it's certainly another file than the one opened in:
        f = open("/proc/%s/cmdline" % self.pid)

It could be that you called open on the result of os.pipe(), or perhaps you used a subprocess and didn't call communicate() or close() on it.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13222>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:08:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 19:08:04 +0000
Subject: [issue13170] distutils2 test failures
In-Reply-To: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>
Message-ID: <E1RGbUe-0007Ci-H4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cda119958db3 by ?ric Araujo in branch 'default':
Kludge around shlex not supporting unicode in 2.x (#13170).
http://hg.python.org/distutils2/rev/cda119958db3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:10:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 19:10:53 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1319051453.96.0.146916336412.issue11751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Python 2.7 contains distutils, not distutils2.  You?d have to clone hg.python.org/distutils2 and apply the patch I?m attaching.  Thanks for the help!

----------
Added file: http://bugs.python.org/file23467/distutils2-manifest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:32:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 19:32:56 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <E1RGbsh-0001Lb-Pg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1405df4a1535 by ?ric Araujo in branch 'default':
Expand tests and fix bugs in packaging.util.resolve_name.
http://hg.python.org/cpython/rev/1405df4a1535

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:32:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 19:32:56 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <E1RGbsh-0001Lb-Hc@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1cc4d822123b by ?ric Araujo in branch 'default':
More fixes for PEP 3147 compliance in packaging (#11254)
http://hg.python.org/cpython/rev/1cc4d822123b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:38:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 19:38:19 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <1319053099.33.0.724616630565.issue11254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Installation was not completely fixed.  Distutils delegates to each command?s get_outputs method to make the list of all files to install or package in an sdist, and the previous patch missed edits to these get_outputs methods.  I should have fixed it in packaging, I?ll port to distutils soon.

----------
resolution: fixed -> 
stage: committed/rejected -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:39:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 19:39:12 +0000
Subject: [issue13181] pysetup install creates .pyc files but pysetup remove
	doesn't delete them
In-Reply-To: <1318615867.17.0.772590919076.issue13181@psf.upfronthosting.co.za>
Message-ID: <1319053152.58.0.761504439487.issue13181@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think this is #11254, for which I?ve just pushed a fix.  Can you update your 3.3 clone and try to reproduce?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13181>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:41:48 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 19 Oct 2011 19:41:48 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1319053308.89.0.867390300447.issue12915@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:44:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 19:44:55 +0000
Subject: [issue13224] Change str(class) to return only the class name
Message-ID: <1319053495.26.0.624132637793.issue13224@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Suggestion by Guido on #868845:

Off-topic: I sometimes wish that the str() of a class would return the class name rather than its repr(); that way "print(str)" would print "str" instead of <class 'str'>.  (Use case: printing an exception and its message: I wish I could print("%s: %s" % (err.__class__, err)) instead of having to use err.__class__.__name__.)  One could even claim that the repr() of a class could be the same, since one of the guiding principles for repr() is that it should, if possible, return an expression that (perhaps given a suitable environment) could reconstruct the value exactly (and otherwise it should have the <...> form discussed in this issue).  But both of these wishes are debatable, and if anyone cares, they should open a new bug to discuss it.

> I sometimes wish that the str() of a class would return the class name
> rather than its repr(); that way "print(str)" would print "str"
> instead of <class 'str'>.  (Use case: printing an exception and its
> message: I wish I could print("%s: %s" % (err.__class__, err)) instead
> of having to use err.__class__.__name__.)

I wrote a simple patch for that.  I just copied the definition of type_repr to a new type_str function, edited the format strings and updated the member mapping (I checked in another file than casting to reprfunc is okay for a str func).  It compiles and runs just fine, but I?m still learning C, so there may be things I?ve missed: I don?t know if I have to declare the new function or something like that.  The test suite passes with very few edits.


Guido added this:
> One could even claim that the repr() of a class could be the same
I for one think of repr first as ?string form for debugging?, so I like the angle brackets.  My patch leaves __repr__ alone.


If this get approved, I?ll update my patch with doc changes.  If there is no feedback I?ll go to python-ideas.

----------
assignee: eric.araujo
components: Interpreter Core
messages: 145945
nosy: eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Change str(class) to return only the class name
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:45:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 19:45:03 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053495.26.0.624132637793.issue13224@psf.upfronthosting.co.za>
Message-ID: <1319053503.51.0.204394736003.issue13224@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23468/change-class-__str__.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:45:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 19:45:32 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053495.26.0.624132637793.issue13224@psf.upfronthosting.co.za>
Message-ID: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Suggestion by Guido on #868845:

> I sometimes wish that the str() of a class would return the class name
> rather than its repr(); that way "print(str)" would print "str"
> instead of <class 'str'>.  (Use case: printing an exception and its
> message: I wish I could print("%s: %s" % (err.__class__, err)) instead
> of having to use err.__class__.__name__.)

I wrote a simple patch for that.  I just copied the definition of type_repr to a new type_str function, edited the format strings and updated the member mapping (I checked in another file than casting to reprfunc is okay for a str func).  It compiles and runs just fine, but I?m still learning C, so there may be things I?ve missed: I don?t know if I have to declare the new function or something like that.  The test suite passes with very few edits.


Guido added this:
> One could even claim that the repr() of a class could be the same
I for one think of repr first as ?string form for debugging?, so I like the angle brackets.  My patch leaves __repr__ alone.


If this get approved, I?ll update my patch with doc changes.  If there is no feedback I?ll go to python-ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:45:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 19:45:43 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1319053543.62.0.21330480875.issue13224@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg145945

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:46:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 19:46:19 +0000
Subject: [issue868845] Need unit tests for <...> reprs
Message-ID: <1319053579.18.0.697626606492.issue868845@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I opened #13224 with a patch to change str(class).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue868845>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:50:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 19 Oct 2011 19:50:27 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1318888930.95.0.114302398963.issue12619@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1+mRGxP7Tt7rv9yYpP8WBZpY1XNcQn8uCxipBshEULeQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Related :  #1565071 and #3990  . There is no reason to keep plat-xxx files if cannot be managed properly.

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Wed Oct 19 21:53:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 19:53:04 +0000
Subject: [issue11637] Add cwd to sys.path for hooks
In-Reply-To: <1300828230.79.0.355779213126.issue11637@psf.upfronthosting.co.za>
Message-ID: <1319053984.82.0.966757308756.issue11637@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This was fixed for setup hooks but not command hooks; I have a patch for that.

----------
resolution: fixed -> 
stage: committed/rejected -> commit review
status: closed -> open
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11637>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:05:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 20:05:37 +0000
Subject: [issue13225] Failing packaging hooks should not stop operation
Message-ID: <1319054737.41.0.295237299107.issue13225@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

As discussed in #11637, failing hooks should not stop operation.  I see different issues:

a) a hook is not found
b) a hook is not callable
c) a hook raises an exception

Current code will raise a Packaging exception for a) and b), and let the exception propagate in case of c).  I have a patch that makes Packaging ignore all three kinds and issue warning or error logging messages.

An option (--strict) would be needed to switch from logging messages to exceptions; I wonder if an elegant way to do that would be a custom logging handler.

----------
assignee: eric.araujo
components: Distutils2
messages: 145950
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: Failing packaging hooks should not stop operation
versions: 3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13225>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:06:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 20:06:24 +0000
Subject: [issue12375] Add packages_root to sys.path for hooks
In-Reply-To: <1308587015.96.0.883651483706.issue12375@psf.upfronthosting.co.za>
Message-ID: <1319054784.32.0.824210058963.issue12375@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have a patch for this.

----------
assignee: tarek -> eric.araujo
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12375>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:07:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 20:07:22 +0000
Subject: [issue12416] packaging needs {pre,post}-{install,remove} hooks
In-Reply-To: <1309132247.11.0.698244418605.issue12416@psf.upfronthosting.co.za>
Message-ID: <1319054842.95.0.35100251993.issue12416@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve opened #13225 about the error handling.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12416>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:17:42 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 19 Oct 2011 20:17:42 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <CAH_1eM1+mRGxP7Tt7rv9yYpP8WBZpY1XNcQn8uCxipBshEULeQ@mail.gmail.com>
Message-ID: <4E9F3056.1030603@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I don't see why these modules should be auto-generated. The constants
in the modules hardly ever change and are also not affected by architecture
differences (e.g. Mac OS X, Solaris, etc.) AFAICT.

If you think they need to be auto-generated, you should make a case by
example.

Note that we cannot simply drop the modules. Some of the constants are
needed for e.g. socket, ctypes or ldd programming.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:18:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 20:18:43 +0000
Subject: [issue11552] Confusing error message when hook module cannot be loaded
In-Reply-To: <1300167883.89.0.288687435402.issue11552@psf.upfronthosting.co.za>
Message-ID: <1319055523.18.0.78520481621.issue11552@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Maybe your bug was #11637, or one of the other bugs that I fixed in 1405df4a1535.  Your simple example now works.

----------
assignee: tarek -> eric.araujo
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11552>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:25:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 20:25:10 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1319055910.39.0.192342823648.issue12703@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have added tests and fixed one or two bugs in 1405df4a1535.  I have another patch that checks that error messages are useful, with one exception: if you try to import a.b and b raises an ImportError, then the calling code will see an Attribute error.  Right now I don?t see how we can avoid that; checking the existence of files like your patch proposes is not possible, as Python modules do not come from files.

----------
Added file: http://bugs.python.org/file23469/resolve-name-errors.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:32:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 20:32:10 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1319056330.82.0.222869816924.issue12619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> you should make a case by example

Did you read comments of this issue and my email thread on python-dev? There are differents examples:

 - LONG_MAX is 9223372036854775807 even on 32 bits system
 - On Mac OS X, FAT programs contains 32 and 64 binaries, whereas constants are changed for 32 or 64 bits

> we cannot simply drop the modules. Some of the constants
> are needed for e.g. socket, ctypes or ldd programming.

Ah? I removed all plat-* directories and ran the full test suite: no failure. The Python socket modules contain many constants (SOCK_*, AF_*,  SO_*, ...):
http://docs.python.org/library/socket.html#socket.AF_UNIX

Which constants are used by the ctypes modules or can be used by modules using ctypes? Can you give examples? I listed usages of plat-* modules in the first message of my thread on python-dev.

By "ldd", you mean "ld.so" (dlopen)? Yes, I agree that we need to expose  dl constants. But the other constants are not used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:40:16 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 19 Oct 2011 20:40:16 +0000
Subject: [issue13225] Failing packaging hooks should not stop operation
In-Reply-To: <1319054737.41.0.295237299107.issue13225@psf.upfronthosting.co.za>
Message-ID: <1319056811.46803.YahooMailNeo@web25803.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> An option (--strict) would be needed to switch from logging messages to 

> exceptions; I wonder if an elegant way to do that would be a custom logging 
> handler.

I'm not sure a custom logging handler is the way to go. I think it would be better to log the exception condition in all cases, raising it if --strict is specified, and swallowing it otherwise. An application developer can configure loggers/handlers appropriately if they want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13225>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:40:20 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 Oct 2011 20:40:20 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1319056820.49.0.875573896735.issue12619@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Victor, please accept that this entire infrastructure was originally added because there was a need for it, and the need did not go away. It's probably relevant only for a minority of applications, but you would make this minority's lifes much more complicated by removing the modules. If they don't hurt, why remove them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:40:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 20:40:50 +0000
Subject: [issue13121] collections.Counter's += copies the entire object
In-Reply-To: <1317977434.46.0.626100406816.issue13121@psf.upfronthosting.co.za>
Message-ID: <E1RGcwQ-0007zy-4j@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5cced40374df by Raymond Hettinger in branch 'default':
Issue #13121: Support in-place math operators for collections.Counter().
http://hg.python.org/cpython/rev/5cced40374df

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13121>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:41:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Oct 2011 20:41:05 +0000
Subject: [issue13164] importing rlcompleter module writes a control sequence
	in stdout
In-Reply-To: <1318509320.97.0.686046301557.issue13164@psf.upfronthosting.co.za>
Message-ID: <1319056865.32.0.948608615988.issue13164@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you give a simpler script (maybe in Python :) to reproduce this?  Also, 2.6 only gets security fixes now, so please use 2.7, 3.2 or 3.3.

----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13164>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:41:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Oct 2011 20:41:15 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1319056820.49.0.875573896735.issue12619@psf.upfronthosting.co.za>
Message-ID: <1319056638.3230.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If they don't hurt, why remove them?

Bogus constants don't hurt?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:41:20 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Oct 2011 20:41:20 +0000
Subject: [issue13121] collections.Counter's += copies the entire object
In-Reply-To: <1317977434.46.0.626100406816.issue13121@psf.upfronthosting.co.za>
Message-ID: <1319056880.66.0.20297570706.issue13121@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13121>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:42:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Oct 2011 20:42:02 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1319056922.76.0.613074392193.issue1602@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:49:01 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Oct 2011 20:49:01 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1319057341.48.0.0274203786654.issue12185@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Sorry, I'm going to reject this one.  I applied the patch and looked at the generated docs, finding them to be less readable than before.  AFAICT, we've had no issues with people mis-reading the text as currently presented.   Also, I looked back at the underlying spec, http://speleotrove.com/decimal/daops.html , and found that it tended to refer to first and second operand.  I would like to keep our docs as close to that as possible.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12185>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:57:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 20:57:39 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1319057859.21.0.80601460291.issue1602@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

win_console.patch: a more complete prototype

 * patch the site module to replace sys.stdout and sys.stderr by UnicodeConsole and BytesConsole classes which use WriteConsoleW and WriteConsoleA
 * UnicodeConsole inherits from io.TextIOBase and BytesConsole inherits from io.RawIOBase
 * Revert the workaround for WriteConsoleA bug from io.FileIO

sys.stdout and/or sys.stderr are only replaced if there are not redirected.

----------
Added file: http://bugs.python.org/file23470/win_console.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Wed Oct 19 22:58:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 20:58:45 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1319057925.83.0.12506823903.issue1602@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_win_console.py: Small script to test win_console.patch. Write some characters into sys.stdout.buffer (WriteConsoleA) and sys.stdout (WriteConsoleW). The test is written for cp850, cp1252 and cp65001 code pages.

----------
Added file: http://bugs.python.org/file23471/test_win_console.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:02:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 21:02:18 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1319058138.34.0.512698377964.issue13224@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It looks like your change breaks backward compatibility (e.g. tests written using doctests). I don't know if it's a problem or not.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:11:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 21:11:01 +0000
Subject: [issue11931] Regular expression documentation patch
In-Reply-To: <1303855586.52.0.604026571441.issue11931@psf.upfronthosting.co.za>
Message-ID: <E1RGdPc-0002ns-RJ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 068d89194ffd by Raymond Hettinger in branch '3.2':
Issue 11931: Minor punctuation/grammar/wording fixups to the regex docs
http://hg.python.org/cpython/rev/068d89194ffd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11931>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:11:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Oct 2011 21:11:57 +0000
Subject: [issue11931] Regular expression documentation patch
In-Reply-To: <1303855586.52.0.604026571441.issue11931@psf.upfronthosting.co.za>
Message-ID: <1319058717.42.0.549635507412.issue11931@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Applied many of these changes to 3.2 and 3.3.
If someone is interested, feel free to backport them to 2.7.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11931>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:17:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 21:17:00 +0000
Subject: [issue12668] 3.2 What's New: it's integer->string, not the opposite
In-Reply-To: <1312147179.72.0.252519921224.issue12668@psf.upfronthosting.co.za>
Message-ID: <E1RGdVR-0003IB-0S@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 48e0db1cf7e4 by Raymond Hettinger in branch '3.2':
Issue 12668: Fix wording in Whatsnew3.2
http://hg.python.org/cpython/rev/48e0db1cf7e4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12668>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:17:38 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Oct 2011 21:17:38 +0000
Subject: [issue12668] 3.2 What's New: it's integer->string, not the opposite
In-Reply-To: <1312147179.72.0.252519921224.issue12668@psf.upfronthosting.co.za>
Message-ID: <1319059058.36.0.502350794315.issue12668@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the report.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12668>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:34:25 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 19 Oct 2011 21:34:25 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1319060065.5.0.639159819851.issue12619@psf.upfronthosting.co.za>


Jakub Wilk <jwilk at jwilk.net> added the comment:

FYI, in Debian we have at least:
one package using the CDROM module,
3 packages using the IN module,
14 packages using the DLFCN module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:40:24 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 19 Oct 2011 21:40:24 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1319056330.82.0.222869816924.issue12619@psf.upfronthosting.co.za>
Message-ID: <4E9F43B8.9010000@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> you should make a case by example
> 
> Did you read comments of this issue and my email thread on python-dev?

No.

> There are differents examples:
> 
>  - LONG_MAX is 9223372036854775807 even on 32 bits system
>  - On Mac OS X, FAT programs contains 32 and 64 binaries, whereas constants are changed for 32 or 64 bits

That's because the h2py.py script doesn't know anything about conditional
definitions, e.g.

PTRDIFF_MIN = (-9223372036854775807-1)
PTRDIFF_MAX = (9223372036854775807)
PTRDIFF_MIN = (-2147483647-1)
PTRDIFF_MAX = (2147483647)

Not all constants are really useful because of this, but some are, e.g.
INT16_MAX, INT32_MAX, etc.

>> we cannot simply drop the modules. Some of the constants
>> are needed for e.g. socket, ctypes or ldd programming.
> 
> Ah? I removed all plat-* directories and ran the full test suite: no failure. 

Right, the modules are not tested at all, AFAIK.

> The Python socket modules contain many constants (SOCK_*, AF_*,  SO_*, ...):
> http://docs.python.org/library/socket.html#socket.AF_UNIX

True, but you probably agree that it's easier to parse a header file
into a Python module than to add each and every socket option on
the planet to the C socket module, don't you ? :-)

> Which constants are used by the ctypes modules or can be used by modules using ctypes? Can you give examples? I listed usages of plat-* modules in the first message of my thread on python-dev.

Not constants used by the ctypes, but constants which can be used
with the ctypes module.

> By "ldd", you mean "ld.so" (dlopen)?

Yes.

> Yes, I agree that we need to expose  dl constants. But the other constants are not used.

Not in the standard lib, that's true.

Also note that the plat-* directories can contain platform specific code,
e.g. the OS2 dirs have replacements for the pwd and grp modules.

Finally, the list of standard files to include in those directories
could be extended to cover more system level constants such as
the ioctl or fcntl constants (not only the few defined in the C
code, but all platform specific ones).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:40:42 2011
From: report at bugs.python.org (Paul Moore)
Date: Wed, 19 Oct 2011 21:40:42 +0000
Subject: [issue13181] pysetup install creates .pyc files but pysetup remove
	doesn't delete them
In-Reply-To: <1319053152.58.0.761504439487.issue13181@psf.upfronthosting.co.za>
Message-ID: <CACac1F_1xifpij1xWA=TgnvrTkTQXQK1krGJqo4DGjW97EPutw@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

Yes, working correctly now

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13181>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:46:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Oct 2011 21:46:15 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1319060775.02.0.596645171665.issue13224@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:49:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Oct 2011 21:49:44 +0000
Subject: [issue13223] pydoc removes 'self' in HTML for method docstrings with
	example code
In-Reply-To: <1319050782.47.0.924539258184.issue13223@psf.upfronthosting.co.za>
Message-ID: <1319060984.3.0.55292239825.issue13223@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13223>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:54:50 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 19 Oct 2011 21:54:50 +0000
Subject: [issue13221] No "edit with IDLE" in right click context menu
In-Reply-To: <1319044965.54.0.660981699643.issue13221@psf.upfronthosting.co.za>
Message-ID: <1319061290.78.0.491715572352.issue13221@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This sounds like an issue with Windows installation rather than an IDLE issue.

----------
components: +Installation, Windows -IDLE
nosy: +brian.curtin, loewis, ned.deily, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13221>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:57:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Oct 2011 21:57:06 +0000
Subject: [issue13221] No "edit with IDLE" in right click context menu
In-Reply-To: <1319044965.54.0.660981699643.issue13221@psf.upfronthosting.co.za>
Message-ID: <1319061426.86.0.662417850926.issue13221@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I installed Python 3.2 first and then 2.7
This probably made 2.7 the default Python.

> I tried to open a .py file that's written with 3.2,
> but it were opened with the 2.7 IDLE.
So this is normal.

> So I uninstalled 2.7 and tried to open it again.
> Now the context menu were missed.
The uninstallation process probably removed the context menu.  If the 2.7 entry overrode the 3.2 one, once it's remove there are no entries left.

> I tried to open it over "Open with..." with other applications.
> I re-installed 3.2 and also repaired it, but the "edit with IDLE" is still not there.
If the installation process adds the "Open with IDLE" entry, it should do it again when you reinstall -- unless something got corrupted somehow during when 2.7 got installed on removed.

----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13221>
_______________________________________

From report at bugs.python.org  Wed Oct 19 23:58:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Oct 2011 21:58:16 +0000
Subject: [issue13220] print function unable while multiprocessing.Process is
	being run
In-Reply-To: <1319038082.58.0.169311394229.issue13220@psf.upfronthosting.co.za>
Message-ID: <1319061496.03.0.825830854425.issue13220@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +jnoller
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13220>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:05:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 22:05:44 +0000
Subject: [issue13226] Expose RTLD_* constants in the posix module
Message-ID: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

We have a sys.setdlopenflags() function, but required constants are not available on all platforms. The DLFCN is only available on Linux and sunos5 (is plat-sunos5 available for all Solaris and OpenIndiana versions?), but not on OpenBSD, FreBSD, Mac OS X, ... whereas these platforms have the sys.setdlopenflags() function.

My patch contains 7 constants: 

 - RTLD_LAZY
 - RTLD_NOW
 - RTLD_GLOBAL
 - RTLD_LOCAL
 - RTLD_NODELETE
 - RTLD_NOLOAD
 - RTLD_DEEPBIND (glibc >= 2.3)

The ctypes has two RTDL constants: RTLD_LOCAL and RTLD_GLOBAL. The 2 constants are always available, even if the platform doesn't support them! Extract of _ctypes.c:
----------------------------------------
/* If RTLD_LOCAL is not defined (Windows!), set it to zero. */
#ifndef RTLD_LOCAL
#define RTLD_LOCAL 0
#endif

/* If RTLD_GLOBAL is not defined (cygwin), set it to the same value as
   RTLD_LOCAL.
*/
#ifndef RTLD_GLOBAL
#define RTLD_GLOBAL RTLD_LOCAL
#endif
----------------------------------------

Lib/plat-sunos5/DLFCN.py contains 25 constants, only 6 are available in my patch. I don't think that we should expose all constants.

Using Google Codesearch, I only found one user of RTLD constants (of the DLFCN module). It's PyKDE4 who calls:

   sys.setdlopenflags(DLFCN.RTLD_NOW|DLFCN.RTLD_GLOBAL)

I guess that the 7 constants should be enough for everyone :-) We may add more later on demand. You can add your own constant to your program if you really need a special option on a specific platform.

----------
components: Library (Lib)
files: posix_rtld.patch
keywords: patch
messages: 145975
nosy: haypo
priority: normal
severity: normal
status: open
title: Expose RTLD_* constants in the posix module
versions: Python 3.3
Added file: http://bugs.python.org/file23472/posix_rtld.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13226>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:06:36 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Oct 2011 22:06:36 +0000
Subject: [issue13227] Option to make the lru_cache type specific
Message-ID: <1319061996.92.0.980251015091.issue13227@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Based on a comment from Andrew Koenig, it is suggested that the lru_cache() offer an option to become type specific so that equal objects of different typed don't get cached to the same entry.

Here's an example:

@lru_cache(typed=True)
def square(x):
    print('squaring', x)
    return x * x

for x in [3, 3.0, 3, 3.0]:
    print(square(x))

Without type specificity, all four calls will return 9 rather than 9. 9.0, 9, 9.0.

First-pass patch attached.

----------
assignee: rhettinger
components: Library (Lib)
files: typed_lru.diff
keywords: patch
messages: 145976
nosy: rhettinger
priority: low
severity: normal
status: open
title: Option to make the lru_cache type specific
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23473/typed_lru.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13227>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:06:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 22:06:46 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1319062006.32.0.739742777136.issue12619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I created the issue #13226 to provide RTLD_* constants on all platforms (not only on Linux and sunos5).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:08:34 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Oct 2011 22:08:34 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318872903.5.0.343979094367.issue13146@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W7_nOzamd-Qnb6fqw_AscoSgu23o54fuj9fv8GCm9oP5Q@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

And thanks for doing this, Antoine! One less thing on my never-ending
todo list. =)

On Mon, Oct 17, 2011 at 10:35, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Should be fixed now. Thanks for the reviews!
>
> ----------
> resolution: ?-> fixed
> stage: patch review -> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13146>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:09:43 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Oct 2011 22:09:43 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1319062183.68.0.0151270752774.issue7475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Some further comments after getting back up to speed with the actual status of this problem (i.e. that we had issues with the error checking and reporting in the original 3.2 commit).

1. I agree with the position that the codecs module itself is intended to be a type neutral codec registry. It encodes and decodes things, but shouldn't actually care about the types involved. If that is currently not the case in 3.x, it needs to be fixed.

This type neutrality was blurred in 2.x by the fact that it only implemented str->str translations, and even further obscured by the coupling to the .encode() and .decode() convenience APIs. The fact that the type neutrality of the registry itself is currently broken in 3.x is a *regression*, not an improvement. (The convenience APIs, on the other hand, are definitely *not* type neutral, and aren't intended to be)

2. To assist in producing nice error messages, and to allow restrictions to be enforced on type-specific convenience APIs, the CodecInfo objects should grow additional state as MAL suggests. To avoid redundancy (and inaccurate overspecification), my suggested colour for that particular bikeshed is:

Character encoding codec:
  .decoded_format = 'text'
  .encoded_format = 'binary'

Binary transform codec:
  .decoded_format = 'binary'
  .encoded_format = 'binary'

Text transform codec:
  .decoded_format = 'text'
  .encoded_format = 'text'

I suggest using the fuzzy format labels mainly due to the existence of the buffer API - most codec operations that consume binary data will accept anything that implements the buffer API, so referring specifically to 'bytes' in error messages would be inaccurate.

The convenience APIs can then emit errors like:

  'a'.encode('rot_13') ==>
  CodecLookupError: text <-> binary codec expected ('rot_13' is text <-> text)

  'a'.decode('rot_13') ==>
  CodecLookupError: text <-> binary codec expected ('rot_13' is text <-> text)

  'a'.transform('bz2') ==>
  CodecLookupError: text <-> text codec expected ('bz2' is binary <-> binary)

  'a'.transform('ascii') ==>
  CodecLookupError: text <-> text codec expected ('ascii' is text <-> binary)

  b'a'.transform('ascii') ==>
  CodecLookupError: binary <-> binary codec expected ('ascii' is text <-> binary)

For backwards compatibility with 3.2, codecs that do not specify their formats should be treated as character encoding codecs (i.e. decoded format is 'text', encoded format is 'binary')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:12:38 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Oct 2011 22:12:38 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1319062358.1.0.369080587808.issue7475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oops, typo in my second error example. The command should be:

  b'a'.decode('rot_13')

(Since str objects don't offer a decode() method any more)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:14:17 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 19 Oct 2011 22:14:17 +0000
Subject: [issue13226] Expose RTLD_* constants in the posix module
In-Reply-To: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za>
Message-ID: <1319062457.56.0.747417403225.issue13226@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13226>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:24:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 22:24:56 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <4E9F43B8.9010000@egenix.com>
Message-ID: <201110200025.59548.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > There are differents examples:
> >  - LONG_MAX is 9223372036854775807 even on 32 bits system
> >  - On Mac OS X, FAT programs contains 32 and 64 binaries, whereas
> >  constants are changed for 32 or 64 bits
> 
> That's because the h2py.py script doesn't know anything about conditional
> definitions, e.g.
> 
> PTRDIFF_MIN = (-9223372036854775807-1)
> PTRDIFF_MAX = (9223372036854775807)
> PTRDIFF_MIN = (-2147483647-1)
> PTRDIFF_MAX = (2147483647)

Why may fix h2py.py, but regenerating plat-*/*.py files on build is not an 
option according to Martin (msg145659).

And it doesn't solve the Mac OS X issue.

> Not all constants are really useful because of this, but some are, e.g.
> INT16_MAX, INT32_MAX, etc.

INT16_MAX and INT32_MAX are not platform dependent. I'm not sure that Python 
should provide such constants.

> Right, the modules are not tested at all, AFAIK.

One more reason to remove them. By the way, there are not documented.

> > The Python socket modules contain many constants (SOCK_*, AF_*,  SO_*,
> > ...): http://docs.python.org/library/socket.html#socket.AF_UNIX
> 
> True, but you probably agree that it's easier to parse a header file
> into a Python module than to add each and every socket option on
> the planet to the C socket module, don't you ? :-)

It's not exactly the purpose of this issue. We are first trying to get correct 
constants.

I don't think that it's really useful to expose all constants. I prefer to 
expose more constants on demand. When we add new constants, we try to use it, 
test it and document it (e.g. O_CLOEXEC).

> > Which constants are used by the ctypes modules or can be used by modules
> > using ctypes? Can you give examples? I listed usages of plat-* modules
> > in the first message of my thread on python-dev.
> 
> Not constants used by the ctypes, but constants which can be used
> with the ctypes module.

Sorry, I don't see which constants are useful with the ctypes module?

> > By "ldd", you mean "ld.so" (dlopen)?
> 
> Yes.

See my issue #13226 for these constants.

> Also note that the plat-* directories can contain platform specific code,
> e.g. the OS2 dirs have replacements for the pwd and grp modules.

(OS/2 has been deprecated in Python 3.3, see the PEP 11.)

Except plat-os2emx, I don't see other platform specific code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:34:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 22:34:48 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1319063688.95.0.0614650932312.issue7475@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> *.encode('rot_13') ==> CodecLookupError

I like the idea of raising a lookup error on .encode/.decode if the codec is not a classic text codec (like ASCII or UTF-8).

> *.transform('ascii') ==> CodecLookupError

Same comment.

> str.transform('bz2') ==> CodecLookupError

A lookup error is surprising here. It may be a TypeError instead. The bz2 can be used with .transform, but not on str. So:

 - Lookup error if the codec cannot be used with encode/decode or transform/untransform
 - Type error if the value type is invalid

(CodecLookupError doesn't exist, you propose to define a new exception who inherits from LookupError?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:40:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Oct 2011 22:40:57 +0000
Subject: [issue13150] Most of Python's startup time is sysconfig
In-Reply-To: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za>
Message-ID: <E1RGeof-0002Do-I0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 677e625e2ef1 by Victor Stinner in branch 'default':
Issue #13150: Add a comment in _sysconfigdata to explain the origin of this file
http://hg.python.org/cpython/rev/677e625e2ef1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:43:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Oct 2011 22:43:32 +0000
Subject: [issue13219] re module doc has minor inaccuracy in character sets
In-Reply-To: <1319033680.8.0.92268984905.issue13219@psf.upfronthosting.co.za>
Message-ID: <1319064212.67.0.0794454247538.issue13219@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a patch against 2.7.  I rephrased the section a bit.  If it's more understandable I'll commit it.

----------
assignee: docs at python -> ezio.melotti
keywords: +patch
nosy: +ezio.melotti
stage:  -> commit review
versions: +Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23474/issue13219.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13219>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:54:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Oct 2011 22:54:30 +0000
Subject: [issue13227] Option to make the lru_cache type specific
In-Reply-To: <1319061996.92.0.980251015091.issue13227@psf.upfronthosting.co.za>
Message-ID: <1319064870.16.0.399733502284.issue13227@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Updated patch to include tests and an application to the re module.

----------
Added file: http://bugs.python.org/file23475/typed_lru2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13227>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:54:41 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Oct 2011 22:54:41 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1319063688.95.0.0614650932312.issue7475@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fZnur9+7jW9AH_zRbcmua2OUnrqAV+RsDp1ryfxjFsuA@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Thu, Oct 20, 2011 at 8:34 AM, STINNER Victor <report at bugs.python.org> wrote:
>> str.transform('bz2') ==> CodecLookupError
>
> A lookup error is surprising here. It may be a TypeError instead. The bz2 can be used with .transform, but not on str. So:

No, it's the same concept as the other cases - we found a codec with
the requested name, but it's not the kind of codec we wanted in the
current context (i.e. str.transform). It may be that the problem is
the user has a str when they expected to have a bytearray or a bytes
object, but there's no way for the codec lookup process to know that.

> ?- Lookup error if the codec cannot be used with encode/decode or transform/untransform
> ?- Type error if the value type is invalid

There's no way for str.transform to tell the difference between "I
asked for the wrong codec" and "I expected to have a bytes object
here, not a str object". That's why I think we need to think in terms
of format checks rather than type checks.

> (CodecLookupError doesn't exist, you propose to define a new exception who inherits from LookupError?)

Yeah, and I'd get that to handle the process of creating the nice
error messages. I think it may even make sense to build the filtering
options into codecs.lookup() itself:

  def lookup(encoding, decoded_format=None,  encoded_format=None):
      info = _lookup(encoding) # The existing codec lookup algorithm
      if ((decoded_format is not None and decoded_format !=
info.decoded_format) or
          (encoded_format is not None and encoded_format !=
info.encoded_format)):
          raise CodecLookupError(info, decoded_format, encoded_format)

Then the various encode, decode and transform methods can just pass
the appropriate arguments to 'codecs.lookup' without all having to
reimplement the format checking logic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:55:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 22:55:13 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1319064913.6.0.244395371268.issue12619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> FYI, in Debian we have at least:
> one package using the CDROM module,

Is it cdsuite? (http://offog.org/code/cdsuite.html)

> 3 packages using the IN module,

I found policykit (it uses IN.INT_MAX). What are the 2 others? Which constants are used?

> 14 packages using the DLFCN module.

Oh, so many? Which projects? Which constants are used?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Thu Oct 20 00:59:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Oct 2011 22:59:06 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1319065146.88.0.56003774308.issue12296@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I don't think we need to mention that.  Actually the tone of the whole paragraph could be relaxed a bit, because it first says that "any change **will** break code" (which is not true), except "new semantic, obviously" (which is not true either).

The whole sentence could also be dropped altogether IMHO.
"""
Basically just put yourself in the shoes of someone whose code will be broken by a change to pre-existing semantics.
"""
is already clear enough, and it could be rephrased to
"""
Basically just put yourself in the shoes of someone whose code will be broken by the change(s) introduced by the patch.
"""
to avoid talking about 'semantics'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Thu Oct 20 01:01:14 2011
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 19 Oct 2011 23:01:14 +0000
Subject: [issue12989] Consistently handle path separator in Py_GetPath on
	Windows
In-Reply-To: <1316131696.55.0.834479609561.issue12989@psf.upfronthosting.co.za>
Message-ID: <1319065274.15.0.581980418777.issue12989@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

The first chunk of that patch is for when pythonhome==NULL.  There is also a similar block just under it when MS_WINDOWS is not defined.  While I don't know in which cases this will be built without that define, it looks as though the *buf++ = DELIM; should also be added to that block?

Also, there is an existing conditional:
     if (argv0_path) {

which can never be false (as argv0_path is a char array).  It could be changed to if (argv0_path[0]) but ISTM that it could also be removed completely - ie, the 2 lines left in that block should have no effect in the case where the buffer is empty.

I haven't actually tested it though, but apart from the first comment above, it *looks* like it does the right thing :)

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12989>
_______________________________________

From report at bugs.python.org  Thu Oct 20 01:04:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 23:04:12 +0000
Subject: [issue13227] Option to make the lru_cache type specific
In-Reply-To: <1319061996.92.0.980251015091.issue13227@psf.upfronthosting.co.za>
Message-ID: <1319065452.61.0.117288945207.issue13227@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The patch doesn't update the doc. You may also test type(square(3)). Except of these nits, the patch looks good.

The typed option is an important feature, and your patch contains a good example of its usage (the re module).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13227>
_______________________________________

From report at bugs.python.org  Thu Oct 20 01:10:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Oct 2011 23:10:53 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <CADiSq7fZnur9+7jW9AH_zRbcmua2OUnrqAV+RsDp1ryfxjFsuA@mail.gmail.com>
Message-ID: <201110200111.56344.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think it may even make sense to build the filtering
> options into codecs.lookup() itself:
> 
>   def lookup(encoding, decoded_format=None,  encoded_format=None):
>       info = _lookup(encoding) # The existing codec lookup algorithm
>       if ((decoded_format is not None and decoded_format !=
> info.decoded_format) or
>           (encoded_format is not None and encoded_format !=
> info.encoded_format)):
>           raise CodecLookupError(info, decoded_format, encoded_format)

lookup('rot13') should fail with a lookup error to keep backward 
compatibility. You can just change the default values to:

def lookup(encoding, decoded_format='text',  encoded_format='binary'): ...

If you patch lookup, what about the following functions?

- getencoder()
- getdecoder()
- getincrementalencoder()
- getincrementaldecoder()
- getread()
- getwriter()
- itereencode()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Thu Oct 20 01:20:06 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 19 Oct 2011 23:20:06 +0000
Subject: [issue13226] Expose RTLD_* constants in the posix module
In-Reply-To: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za>
Message-ID: <1319066406.91.0.855843829421.issue13226@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13226>
_______________________________________

From report at bugs.python.org  Thu Oct 20 01:31:53 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 19 Oct 2011 23:31:53 +0000
Subject: [issue13222] Erroneous unclosed file warning
In-Reply-To: <1319050428.96.0.600308451611.issue13222@psf.upfronthosting.co.za>
Message-ID: <1319067113.01.0.819103683037.issue13222@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Indeed you were right.
Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13222>
_______________________________________

From report at bugs.python.org  Thu Oct 20 01:37:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Oct 2011 23:37:03 +0000
Subject: [issue13228] Add "Quick Start" section to the devguide index
Message-ID: <1319067423.48.0.288389971536.issue13228@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Attached patch adds to the index page a list of 5 steps necessary to set up Python and make a patch.  These informations are currently scattered around a few pages and many contributors are already familiar with Mercurial and the process of creating patches, so they just need to know the address where to clone and the commands to compile Python and run the tests.
The list also includes links to the other sections, so users can find more detailed information if they need them (this is also valid for the second point: the "configure" command is specific to Unix, but the link has information about Windows too).
All this should make the devguide a bit more usable.

(A bit of background: during the sprints at PyCon FI I wrote the steps 1-3 on the whiteboard, and they worked well for everyone.  Most of them managed to get something done with no further assistance, even if a few people were not so familiar with Mercurial.)

----------
assignee: ezio.melotti
components: Devguide
files: quickstart.diff
keywords: patch
messages: 145993
nosy: eric.araujo, ezio.melotti, terry.reedy
priority: normal
severity: normal
stage: commit review
status: open
title: Add "Quick Start" section to the devguide index
Added file: http://bugs.python.org/file23476/quickstart.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13228>
_______________________________________

From report at bugs.python.org  Thu Oct 20 01:51:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Oct 2011 23:51:16 +0000
Subject: [issue13125] test_all_project_files() expected failure
In-Reply-To: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>
Message-ID: <1319068276.95.0.492303253024.issue13125@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13125>
_______________________________________

From report at bugs.python.org  Thu Oct 20 01:56:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Oct 2011 23:56:33 +0000
Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to
	urllib
In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za>
Message-ID: <1319068593.69.0.0307041976413.issue4733@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4733>
_______________________________________

From report at bugs.python.org  Thu Oct 20 02:36:05 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Oct 2011 00:36:05 +0000
Subject: [issue13227] Option to make the lru_cache type specific
In-Reply-To: <1319061996.92.0.980251015091.issue13227@psf.upfronthosting.co.za>
Message-ID: <1319070965.09.0.815037695034.issue13227@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Features looks good, but the current patch doesn't handle keyword arguments correctly (more details in the Reitveld review).

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13227>
_______________________________________

From report at bugs.python.org  Thu Oct 20 02:43:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 00:43:45 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1319071425.58.0.266646391131.issue13212@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm not sure adding a strict option is a good idea.  HTMLParser got a strict argument and it's causing more problems than it solves.  If another problem comes up later we would either have to change the behavior for strict and break code that by then is using strict=True or add yet another really_strict argument.

----------
assignee: rhettinger -> 
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Thu Oct 20 02:58:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 00:58:17 +0000
Subject: [issue13227] Option to make the lru_cache type specific
In-Reply-To: <1319061996.92.0.980251015091.issue13227@psf.upfronthosting.co.za>
Message-ID: <1319072297.68.0.727306934472.issue13227@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13227>
_______________________________________

From report at bugs.python.org  Thu Oct 20 03:09:43 2011
From: report at bugs.python.org (=?utf-8?b?VsOtY3RvciBUZXJyw7Nu?=)
Date: Thu, 20 Oct 2011 01:09:43 +0000
Subject: [issue13223] pydoc removes 'self' in HTML for method docstrings with
	example code
In-Reply-To: <1319050782.47.0.924539258184.issue13223@psf.upfronthosting.co.za>
Message-ID: <1319072983.69.0.12362458665.issue13223@psf.upfronthosting.co.za>


V?ctor Terr?n <quintanar at gmail.com> added the comment:

FWIU, only the name of the method, getAnswer, would be a HTML link in the "self.getAnswer()" line that pydoc should generate, while strong (highlighted) text would be used for instance attributes.

I have written a patch for that, by checking for "self." matches (and differentiating between methods and instance attributes) *before* trying to match functions or class instantiations.

It seems to work, but I will test it thoroughly tomorrow.

----------
keywords: +patch
nosy: +vterron
Added file: http://bugs.python.org/file23477/issue13223.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13223>
_______________________________________

From report at bugs.python.org  Thu Oct 20 03:47:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 01:47:46 +0000
Subject: [issue12527] assertRaisesRegex doc'd with 'msg' arg,
	but it's not implemented?
In-Reply-To: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>
Message-ID: <1319075266.96.0.802669337503.issue12527@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Brian, can you still reproduce this?

I tried now with "Python 3.3.0a0 (default:bfbe144986d7, Oct 20 2011, 04:35:19)" and I can see the message (same output posted by Benjamin).

If I run the test with python3.2 (i.e. "Python 3.2 (r32:88445, Mar 25 2011, 19:28:28)"), I don't get the message (same output you posted), because msg is not implemented in 3.2.  Your sys.version_info output suggests you are running 3.3, but maybe you had an older version of the code (i.e. still 3.3 but before 8fc801ca9ea1)?  Have you updated after the pull?

----------
resolution:  -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12527>
_______________________________________

From report at bugs.python.org  Thu Oct 20 03:53:08 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Oct 2011 01:53:08 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1319075588.9.0.343117960561.issue7475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm fine with people needing to drop down to the lower level lookup() API if they want the filtering functionality in Python code. For most purposes, constraining the expected codec input and output formats really isn't a major issue - we just need it in the core in order to emit sane error messages when people misuse the convenience APIs based on things that used to work in 2.x (like 'a'.encode('base64')).

At the C level, I'd adjust _PyCodec_Lookup to accept the two extra arguments and add _PyCodec_EncodeText, _PyCodec_DecodeBinary, _PyCodec_TransformText and _PyCodec_TransformBinary to support the convenience APIs (rather than needing the individual objects to know about the details of the codec tagging mechanism).

Making new codecs available isn't a backwards compatibility problem - anyone relying on a particular key being absent from an extensible registry is clearly doing the wrong thing.

Regarding the particular formats, I'd suggest that hex, base64, quopri, uu, bz2 and zlib all be flagged as binary transforms, but rot13 be implemented as a text transform (Florent's patch has rot13 as another binary transform, but it makes more sense in the text domain - this should just be a matter of adjusting some of the data types in the implementation from bytes to str)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Thu Oct 20 04:05:30 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Oct 2011 02:05:30 +0000
Subject: [issue13229] Add shutil.filter_walk
Message-ID: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I needed a depth-limited, filtered search of a directory tree recently and came up with the following wrapper around os.walk that brings in a few niceties like glob-style filtering, depth limiting and symlink traversal that is safe from infinite loops. It also emits a named tuple rather than the bare tuple emitted by os.walk:

http://code.activestate.com/recipes/577913-selective-directory-walking/

I think this would make a nice addition to 3.3 as shutil.filter_walk, but it need tests, documentation and reformatting as a patch before it can go anywhere.

----------
components: Library (Lib)
messages: 145999
nosy: ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Add shutil.filter_walk
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13229>
_______________________________________

From report at bugs.python.org  Thu Oct 20 04:12:15 2011
From: report at bugs.python.org (Brian Jones)
Date: Thu, 20 Oct 2011 02:12:15 +0000
Subject: [issue12527] assertRaisesRegex doc'd with 'msg' arg,
	but it's not implemented?
In-Reply-To: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>
Message-ID: <1319076735.6.0.588444437282.issue12527@psf.upfronthosting.co.za>


Brian Jones <bkjones at gmail.com> added the comment:

I've just done a fresh hg pull and new build, and I can no longer reproduce the problem. Yay!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12527>
_______________________________________

From report at bugs.python.org  Thu Oct 20 04:20:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 02:20:40 +0000
Subject: [issue12527] assertRaisesRegex doc'd with 'msg' arg,
	but it's not implemented?
In-Reply-To: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>
Message-ID: <1319077240.54.0.338275804015.issue12527@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

OK, I will close the issue then.
Thanks for the quick reply!

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12527>
_______________________________________

From report at bugs.python.org  Thu Oct 20 04:58:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 02:58:32 +0000
Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to
	urllib
In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za>
Message-ID: <1319079512.28.0.741957623214.issue4733@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Christian Heimes wrote:
>   There is no generic and simple way to detect the encoding of a
>   remote site. Sometimes the encoding is mentioned in the HTTP header,
>   sometimes it's embedded in the <head> section of the HTML document.

FWIW for HTML pages the encoding can be specified in at least 3 places:
* the HTTP headers: e.g. "content-type: text/html; charset=utf-8";
* the XML declaration: e.g. "<?xml version="1.0" encoding="utf-8" ?>";
* the <meta> tag: e.g. "<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Browsers usually follow this order while searching the encoding, meaning that HTTP headers have the highest priority.  The XML declaration is sometimes (mis)used in (X)HTML pages.

Anyway, since urlopen() is a generic function that can download anything, it shouldn't look at XML declarations and meta tags -- that's something parsers should take care of.

Regarding the implementation, wouldn't having a new method on the file-like object returned by urlopen better?
Maybe something like:
>>> page = urlopen(some_url)
>>> page.encoding  # get the encoding from the HTTP headers
'utf-8'
>>> page.decode()  # same as page.read().decode(page.encoding)
'...'

The advantage of having these as new methods/attribute is that you can pass the 'page' around and other functions can get back the decoded content if/when they need to.  OTOH other file-like objects don't have similar methods, so it might get a bit confusing.

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4733>
_______________________________________

From report at bugs.python.org  Thu Oct 20 05:40:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 03:40:26 +0000
Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to
	urllib
In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za>
Message-ID: <1319082026.58.0.366393293513.issue4733@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

page.decode_content() might be a better name, and would avoid confusion with the bytes.decode() method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4733>
_______________________________________

From report at bugs.python.org  Thu Oct 20 05:41:59 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 20 Oct 2011 03:41:59 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1319082119.46.0.936539106731.issue13124@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Per Ezio's and Stefan's feedback I cleaned things up a little:

* consolidated on "Buildbot"
* clarified the meaning of the "standard development toolchain"
* % changed to $
* cleaned up the network ports section
* removed a bunch of outdated/unnecessary info

I did not do anything about syntax highlighting for lack of know-how.  I also did not add anything about the responsibilities of running a build slave, mostly because I have no idea what those are.  :)

Much of the section on installation needs double-checking as I am not sure how much of it is necessary and how much not.

This is about as far as I think I will be able to take this tracker issue.  Unfortunately I don't have a lot of time to get up to speed on how Buildbot works, and I know nearly nothing about it currently.

I'm hoping that finishing this won't be much work for someone with a working knowledge of our buildbots.  I've tried to get it close.  It's a gap in the devguide that I think would be worth filling.

Incidently, I pulled the section on security (which motivated me here in the first place) and stuck it into the wiki page.  If any of that is worth pulling back in, there it is.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13124>
_______________________________________

From report at bugs.python.org  Thu Oct 20 05:52:04 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 20 Oct 2011 03:52:04 +0000
Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to
	urllib
In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za>
Message-ID: <1319082724.72.0.689740401568.issue4733@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

- page.encoding is a good idea.

- page.decode_content sounds definitely better than page.decode which can be confusing as page is not a bytes object, but a file-like object.

I am thinking if an attribute to urlopen would be better? Not exactly the mode like attribute of the builtin open, but something like decoded=False

The downside is that the attr is now for the implementation detail of the method in py3k and upside is it gives an idea to users as what return value they can/should expect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4733>
_______________________________________

From report at bugs.python.org  Thu Oct 20 05:56:09 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Thu, 20 Oct 2011 03:56:09 +0000
Subject: [issue13230] test_resources fails
Message-ID: <1319082969.57.0.123711393145.issue13230@psf.upfronthosting.co.za>


New submission from Westley Mart?nez <anikom15 at gmail.com>:

After running the uber test on the latest build of python (./python -bb -E -Wd -m test -r -w -uall) I get one error:
======================================================================
ERROR: test_resources (packaging.tests.test_command_install_data.InstallDataTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/westley/Projects/cpython/Lib/packaging/tests/test_command_install_data.py", line 134, in test_resources
    with packaging.database.get_file('Spamlib', 'spamd') as fp:
  File "/home/westley/Projects/cpython/Lib/packaging/database.py", line 649, in get_file
    return open(get_file_path(distribution_name, relative_path),
  File "/home/westley/Projects/cpython/Lib/packaging/database.py", line 644, in get_file_path
    raise LookupError('no distribution named %r found' % distribution_name)
LookupError: no distribution named 'Spamlib' found

----------------------------------------------------------------------

I also pasted the entire test output (verbose) to the testout file

----------
components: Library (Lib)
files: testout.txt
messages: 146006
nosy: anikom15
priority: normal
severity: normal
status: open
title: test_resources fails
type: behavior
Added file: http://bugs.python.org/file23478/testout.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13230>
_______________________________________

From report at bugs.python.org  Thu Oct 20 05:57:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 03:57:45 +0000
Subject: [issue13230] test_resources fails
In-Reply-To: <1319082969.57.0.123711393145.issue13230@psf.upfronthosting.co.za>
Message-ID: <1319083065.72.0.26045353617.issue13230@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Tests
nosy: +alexis, eric.araujo, tarek
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13230>
_______________________________________

From report at bugs.python.org  Thu Oct 20 06:22:56 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 20 Oct 2011 04:22:56 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1319084576.35.0.321619404291.issue13124@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Added file: http://bugs.python.org/file23479/devguide-buildbots-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13124>
_______________________________________

From report at bugs.python.org  Thu Oct 20 06:30:02 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Oct 2011 04:30:02 +0000
Subject: [issue13227] Option to make the lru_cache type specific
In-Reply-To: <1319061996.92.0.980251015091.issue13227@psf.upfronthosting.co.za>
Message-ID: <1319085002.05.0.531012322636.issue13227@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Nick, Ezio, and Victor, thanks for looking at the code.  
Here's an updated the patch:
* optimization for fast globals() are now keyword-only arguments
* now types the keyword values, not the key/values tuples
* expanded tests
* added the doc update

----------
Added file: http://bugs.python.org/file23480/typed_lru3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13227>
_______________________________________

From report at bugs.python.org  Thu Oct 20 06:45:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Oct 2011 04:45:50 +0000
Subject: [issue13227] Option to make the lru_cache type specific
In-Reply-To: <1319061996.92.0.980251015091.issue13227@psf.upfronthosting.co.za>
Message-ID: <1319085950.78.0.586121865271.issue13227@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Looks good to me (although it took me longer than it should have to figure out why you didn't need to store the keyword argument names a second time)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13227>
_______________________________________

From report at bugs.python.org  Thu Oct 20 09:10:01 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 20 Oct 2011 07:10:01 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1319094601.38.0.497104801603.issue12619@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy:  -petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Thu Oct 20 09:40:21 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 20 Oct 2011 07:40:21 +0000
Subject: [issue13231] sys.settrace - document 'some other code blocks' for
	'call' event type
Message-ID: <1319096421.5.0.420840017987.issue13231@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/sys.html#sys.settrace

While writing settrace function you need to know what kind of data is expected and how to get more information about it. Current documentation for sys.settrace doesn't give too much answers. To improve that situation at least with 'call' event:

 1. Link 'frame' to the middle of table on inspect module page [1]
 2. List all possible 'code blocks' for 'call' event (I know there is module in addition to function)
 3. Provide example how to extract popular data for corresponding 'code block' (name for functions, name for modules, name for classes/methods, relative file path, line no, how to detect labmbda function) in a safe manner (inspect page contains some FUD about memory usage)


1. http://docs.python.org/library/inspect#types-and-members

----------
assignee: docs at python
components: Documentation
messages: 146009
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: sys.settrace - document 'some other code blocks' for 'call' event type

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13231>
_______________________________________

From report at bugs.python.org  Thu Oct 20 10:33:56 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 20 Oct 2011 08:33:56 +0000
Subject: [issue13230] test_resources fails
In-Reply-To: <1319082969.57.0.123711393145.issue13230@psf.upfronthosting.co.za>
Message-ID: <1319099636.81.0.0633004464814.issue13230@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

This seems to be a duplicate of issue 13193.

----------
nosy: +nadeem.vawda
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13230>
_______________________________________

From report at bugs.python.org  Thu Oct 20 10:34:06 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 20 Oct 2011 08:34:06 +0000
Subject: [issue13193] test_packaging and test_distutils failures under Windows
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1319099646.37.0.556254928987.issue13193@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Issue 13230 (closed as duplicate) reports another Linux failure in test_resources.

Changing the title, since it isn't Windows-specific.

----------
nosy: +anikom15
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Thu Oct 20 10:34:38 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 20 Oct 2011 08:34:38 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1319099678.88.0.737633105768.issue13193@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
title: test_packaging and test_distutils failures under Windows -> test_packaging and test_distutils failures

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Thu Oct 20 10:59:56 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 20 Oct 2011 08:59:56 +0000
Subject: [issue9168] setuid in smtp.py sheds privileges before binding port
In-Reply-To: <1278346841.06.0.147409219565.issue9168@psf.upfronthosting.co.za>
Message-ID: <1319101196.19.0.226739689772.issue9168@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The patch looks good to me and fixes the problem. To reproduce, try this:

    sudo python -m smtpd 127.0.0.1:25

It raises a "socket.error: [Errno 13] Permission denied" when trying to bind to the privileged port.

Attached a refreshed the patch that applies cleanly on top of current 2.7 branch.

----------
nosy: +petri.lehtinen
versions:  -Python 3.1
Added file: http://bugs.python.org/file23481/smtpd.py-0.2-setuid-fix_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9168>
_______________________________________

From report at bugs.python.org  Thu Oct 20 11:35:42 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 20 Oct 2011 09:35:42 +0000
Subject: [issue8503] smtpd SMTPServer does not allow domain filtering
In-Reply-To: <1272009372.5.0.274856265398.issue8503@psf.upfronthosting.co.za>
Message-ID: <1319103342.0.0.0242870725799.issue8503@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8503>
_______________________________________

From report at bugs.python.org  Thu Oct 20 11:41:53 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 20 Oct 2011 09:41:53 +0000
Subject: [issue3802] smtpd.py __getaddr insufficient handling
In-Reply-To: <1220849998.55.0.777734204126.issue3802@psf.upfronthosting.co.za>
Message-ID: <1319103713.87.0.100716548587.issue3802@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

AFAIK, the extra MAIL FROM and RCPT TO parameters are only valid for ESMTP. smtpd doesn't currently handle ESMTP, so this should not be a problem.

----------
nosy: +petri.lehtinen
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3802>
_______________________________________

From report at bugs.python.org  Thu Oct 20 11:53:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 20 Oct 2011 09:53:37 +0000
Subject: [issue8503] smtpd SMTPServer does not allow domain filtering
In-Reply-To: <1272009372.5.0.274856265398.issue8503@psf.upfronthosting.co.za>
Message-ID: <1319104417.04.0.801890847843.issue8503@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

This sounds like an important feature to me.

A few points:

- I'd rename the function name from accept_domain to e.g. validate_domain for clarity

- There could also be a function to validate the loca part of each recipient addresses. Or maybe the function should be changed to validate the whole recipient address, not only the domain part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8503>
_______________________________________

From report at bugs.python.org  Thu Oct 20 12:20:40 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 20 Oct 2011 10:20:40 +0000
Subject: [issue12816] smtpd uses library outside of the standard libraries
In-Reply-To: <1314002733.23.0.776557128792.issue12816@psf.upfronthosting.co.za>
Message-ID: <1319106040.88.0.0195143201178.issue12816@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12816>
_______________________________________

From report at bugs.python.org  Thu Oct 20 15:19:51 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 Oct 2011 13:19:51 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1319116791.0.0.493310149863.issue13201@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I get a test failure in test_hash (which is checking exactly that the hash(range) uses the default object hash, so that test is clearly out of date now).  Apart from that, the latest patch looks good to me.

I'm going to give this a couple of days in case anyone else has any comments, then I'll aim to commit it (with the extra test_hash fix) this weekend.

Thanks for all the work on this!

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Thu Oct 20 15:23:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Oct 2011 13:23:09 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1319116989.98.0.243280546654.issue13201@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+    one = PyLong_FromLong(1);
+    if (!one)
+        return -1;
+    cmp_result = PyObject_RichCompareBool(r0->length, one, Py_EQ);
+    Py_DECREF(one);

If would be nice to have a PyLong_CompareLong() function.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Thu Oct 20 15:41:36 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 20 Oct 2011 13:41:36 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319118096.82.0.361957273484.issue13218@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> none of the buildbots are having this problem.

Actually, it turns out the Ubuntu ARM builder is hitting the same failures.
First failure for each branch was on 14 October (the day after 11.10 came out):

    http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/16
    http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.2/builds/9
    http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%202.7/builds/8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Thu Oct 20 15:44:12 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 Oct 2011 13:44:12 +0000
Subject: [issue9574] allow whitespace around central '+' in complex constructor
In-Reply-To: <1281597162.74.0.823446392009.issue9574@psf.upfronthosting.co.za>
Message-ID: <1319118252.77.0.565960346606.issue9574@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9574>
_______________________________________

From report at bugs.python.org  Thu Oct 20 16:43:20 2011
From: report at bugs.python.org (Thomas Guettler)
Date: Thu, 20 Oct 2011 14:43:20 +0000
Subject: [issue13232] Logging: Unicode Error
Message-ID: <1319121800.04.0.366773580653.issue13232@psf.upfronthosting.co.za>


New submission from Thomas Guettler <guettli at thomas-guettler.de>:

In changeset fe6be0426e0d the format() method was changed. Unfortunately it does not catch all unicode decode errors. 

I think line 482 of logging/__init__.py should be modified:
to this (add 'replace'):

s = s + record.exc_text.decode(sys.getfilesystemencoding(), 'replace')

http://hg.python.org/cpython/file/f35514dfadf8/Lib/logging/__init__.py#l482


Here is the stacktrace we get:
{{{
Traceback (most recent call last):
  File "/usr/lib64/python2.7/logging/__init__.py", line 838, in emit
    msg = self.format(record)
  File "/usr/lib64/python2.7/logging/__init__.py", line 715, in format
    return fmt.format(record)
  File "/home/modbau_esg_p/djangotools/utils/logutils.py", line 32, in format
    msg=logging.Formatter.format(self, record)
  File "/usr/lib64/python2.7/logging/__init__.py", line 482, in format
    s = s + record.exc_text.decode(sys.getfilesystemencoding())
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 662: ordinal not in range(128)
Logged from file base.py, line 209
}}}

----------
components: Library (Lib)
messages: 146018
nosy: guettli
priority: normal
severity: normal
status: open
title: Logging: Unicode Error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13232>
_______________________________________

From report at bugs.python.org  Thu Oct 20 17:00:15 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 20 Oct 2011 15:00:15 +0000
Subject: [issue13232] Logging: Unicode Error
In-Reply-To: <1319121800.04.0.366773580653.issue13232@psf.upfronthosting.co.za>
Message-ID: <1319122815.94.0.964331169726.issue13232@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Can you tell me what the actual data was which failed to be decoded? Is there more than one encoding in effect (e.g. one for the filesystem, and another for the other data in the exception being logged)?

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13232>
_______________________________________

From report at bugs.python.org  Thu Oct 20 17:10:17 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 20 Oct 2011 15:10:17 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1319123417.12.0.473380673552.issue12915@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The version in logging.config appears to be doing the same job, but is shorter:

def _resolve(name):
    """Resolve a dotted name to a global object."""
    name = name.split('.')
    used = name.pop(0)
    found = __import__(used)
    for n in name:
        used = used + '.' + n
        try:
            found = getattr(found, n)
        except AttributeError:
            __import__(used)
            found = getattr(found, n)
    return found

The line "used = used + '.' + n" could of course be improved.

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Thu Oct 20 17:44:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 15:44:06 +0000
Subject: [issue13232] Logging: Unicode Error
In-Reply-To: <1319121800.04.0.366773580653.issue13232@psf.upfronthosting.co.za>
Message-ID: <1319125446.31.0.623584525698.issue13232@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13232>
_______________________________________

From report at bugs.python.org  Thu Oct 20 17:48:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Oct 2011 15:48:22 +0000
Subject: [issue13232] Logging: Unicode Error
In-Reply-To: <1319121800.04.0.366773580653.issue13232@psf.upfronthosting.co.za>
Message-ID: <1319125702.79.0.0195423880401.issue13232@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13232>
_______________________________________

From report at bugs.python.org  Thu Oct 20 17:56:00 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Thu, 20 Oct 2011 15:56:00 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1319064913.6.0.244395371268.issue12619@psf.upfronthosting.co.za>
Message-ID: <20111020155553.GA5937@jwilk.net>


Jakub Wilk <jwilk at jwilk.net> added the comment:

* STINNER Victor <report at bugs.python.org>, 2011-10-19, 22:55:
>>FYI, in Debian we have at least:
>>one package using the CDROM module,
>Is it cdsuite? (http://offog.org/code/cdsuite.html)

No, Freevo <http://freevo.sourceforge.net/>.

>>3 packages using the IN module,
>I found policykit (it uses IN.INT_MAX).

Not in Debian, apparently...

>What are the 2 others? Which constants are used?

* Ganeti <http://code.google.com/p/ganeti/>: SO_PEERCRED;
* Mandos <http://www.recompile.se/mandos>: SO_BINDTODEVICE;
* Pydhcplib <http://pydhcplib.tuxfamily.org/>: SO_BINDTODEVICE.

>> 14 packages using the DLFCN module.
>
>Oh, so many? Which projects? Which constants are used?

* Boost <http://www.boost.org/>: RTLD_NOW, RTLD_GLOBAL;
* Ecasound <http://www.eca.cx/ecasound/>: RTLD_LAZY, RTLD_GLOBAL;
* GDCM <http://gdcm.sourceforge.net/>: RTLD_LAZY, RTLD_GLOBAL;
* GNU Radio <http://gnuradio.org/>: RTLD_GLOBAL;
* GStreamer <http://gstreamer.freedesktop.org/>: RTLD_GLOBAL, RTLD_LAZY;
* MPI for Python <http://code.google.com/p/mpi4py/>: RTLD_NOW, RTLD_GLOBAL;
* Open Babel <http://openbabel.org>: RTLD_GLOBAL;
* PyTrilinos <http://trilinos.sandia.gov/>: RTLD_NOW, RTLD_GLOBAL;
* SALOME <http://www.salome-platform.org/>: RTLD_NOW, RTLD_GLOBAL;
* VTK <http://www.vtk.org/>: RTLD_NOW, RTLD_GLOBAL;
* Yade <https://launchpad.net/yade>: RTLD_NOW, RTLD_GLOBAL;
* pyOpenSSL <http://launchpad.net/pyopenssl>: RTLD_NOW, RTLD_GLOBAL.

(That's only 12; we have two versions of Ecasound in the archive, and 
two binary packages with DLFCN-using code are produced from GDCM 
sources.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Thu Oct 20 17:58:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Oct 2011 15:58:05 +0000
Subject: [issue13227] Option to make the lru_cache type specific
In-Reply-To: <1319061996.92.0.980251015091.issue13227@psf.upfronthosting.co.za>
Message-ID: <E1RGv0E-0002LS-Vv@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cba503a2c468 by Raymond Hettinger in branch 'default':
Issue 13227: Option to make the lru_cache() type specific (suggested by Andrew Koenig).
http://hg.python.org/cpython/rev/cba503a2c468

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13227>
_______________________________________

From report at bugs.python.org  Thu Oct 20 17:59:29 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Oct 2011 15:59:29 +0000
Subject: [issue13227] Option to make the lru_cache type specific
In-Reply-To: <1319061996.92.0.980251015091.issue13227@psf.upfronthosting.co.za>
Message-ID: <1319126369.39.0.00449458714298.issue13227@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Victor, Ezio, and Nick, thanks for the review.
Andrew, thanks for the feature request.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13227>
_______________________________________

From report at bugs.python.org  Thu Oct 20 18:20:41 2011
From: report at bugs.python.org (Guilherme Moro)
Date: Thu, 20 Oct 2011 16:20:41 +0000
Subject: [issue13233] os.acces documentation error
Message-ID: <1319127640.96.0.83884717457.issue13233@psf.upfronthosting.co.za>


New submission from Guilherme Moro <guilherme.moro at gmail.com>:

http://docs.python.org/library/os.html#os.access

points out that I should use
try:
    fp = open("myfile")
except IOError as e:
    if e.errno == errno.EACCESS:
        return "some default data"
    # Not a permission error.
    raise
else:
    with fp:
        return fp.read()

but theres a typo the correct is errno.EACCES: not errno.EACCESS:

----------
assignee: docs at python
components: Documentation
messages: 146024
nosy: Guilherme.Moro, docs at python
priority: normal
severity: normal
status: open
title: os.acces documentation error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13233>
_______________________________________

From report at bugs.python.org  Thu Oct 20 18:27:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Oct 2011 16:27:47 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1319128067.77.0.16070234893.issue7322@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This patch has caused a non-trivial regression between 3.2 and 3.2.1.  The scenario in which I observed it is poplib.  I create a POP3 connection with a timeout.  At one point in its processing, poplib is reading lines until it gets a line '.\r\n', at which point the transaction is complete and it returns data to the caller.  If the pop server fails to terminate the transaction, we get a timeout on the read.  However, the POP server may still be alive, it may just have failed to close the transaction (servers have been observed in the wild that do this[*]).  Before this patch, one could catch the socket.timeout and recover from the failed transaction (loosing the transaction data, but that's OK because the transaction was incomplete...it would be better to get the partial transaction, but that's a poplib issue, not a socket issue).  One could then continue processing, sending new transactions to the POP server and getting responses.  After the patch, once the socket error is raised there is no way to continue poplib processing short of tearing down the connection and rebuilding it, and restarting the POP processing from the beginning.

Now, this is clearly an abnormal situation (a POP server randomly not completing its transactions), but it was observed in the wild, and does represent a regression.  I think that Antoine's idea of making readline functional despite timeouts was the better approach.

Also note that Antoine's change to the makefile documentation is wrong with this patch in place, since a timeout invalidates the makefile rather than just "leaving the internal buffers in an inconsistent state".

Backing out this patch would probably be better than leaving it in place, if a better fix can't be found.

[*] The regression was detected testing against a test POP server designed to exhibit defective behaviors that have been observed over the years by the maintainers of the test server.  I can't point to specific existing servers that exhibit the broken behavior, but it did happen in the past and no doubt someone will write a buggy POP server that has the same broken behavior some time in the future as well.

----------
nosy: +r.david.murray
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Oct 20 18:34:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Oct 2011 16:34:55 +0000
Subject: [issue12529] cgi.parse_header fails on double quotes and semicolons
In-Reply-To: <1310331365.35.0.0304262740475.issue12529@psf.upfronthosting.co.za>
Message-ID: <E1RGvZz-0005qP-En@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cfc545e028e0 by Senthil Kumaran in branch '3.2':
News entry for Issue12529 and Issue12604
http://hg.python.org/cpython/rev/cfc545e028e0

New changeset 52a4e899966c by Senthil Kumaran in branch 'default':
News entry for Issue12529 and Issue12604
http://hg.python.org/cpython/rev/52a4e899966c

New changeset 6f7ddbfafbb0 by Senthil Kumaran in branch '2.7':
News entry for Issue12529 and Issue12604
http://hg.python.org/cpython/rev/6f7ddbfafbb0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12529>
_______________________________________

From report at bugs.python.org  Thu Oct 20 18:46:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Oct 2011 16:46:02 +0000
Subject: [issue13219] re module doc has minor inaccuracy in character sets
In-Reply-To: <1319033680.8.0.92268984905.issue13219@psf.upfronthosting.co.za>
Message-ID: <E1RGvkk-0006to-8Y@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 07eca800cdb4 by Ezio Melotti in branch '2.7':
#13219: clarify section about character sets in the re documentation.
http://hg.python.org/cpython/rev/07eca800cdb4

New changeset dc96a89ac192 by Ezio Melotti in branch '3.2':
#13219: clarify section about character sets in the re documentation.
http://hg.python.org/cpython/rev/dc96a89ac192

New changeset 78540d1264d9 by Ezio Melotti in branch 'default':
#13219: merge with 3.2.
http://hg.python.org/cpython/rev/78540d1264d9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13219>
_______________________________________

From report at bugs.python.org  Thu Oct 20 18:47:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 16:47:01 +0000
Subject: [issue13219] re module doc has minor inaccuracy in character sets
In-Reply-To: <1319033680.8.0.92268984905.issue13219@psf.upfronthosting.co.za>
Message-ID: <1319129221.75.0.159374345723.issue13219@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Done, thanks for the report!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13219>
_______________________________________

From report at bugs.python.org  Thu Oct 20 18:43:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Oct 2011 16:43:39 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1319129019.86.0.614119292137.issue12619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

For Freevo: yes, it uses the CDROM module. But this module doesn't look to be perfect because Freevo has a fallback for FreeBSD and another for... Linux (because of missing CDROM.CDROM_DRIVE_STATUS?):
-----------------------------
try:
    from CDROM import *
    # test if CDROM_DRIVE_STATUS is there
    # (for some strange reason, this is missing sometimes)
    CDROM_DRIVE_STATUS
except:
    if os.uname()[0] == 'FreeBSD':
        # FreeBSD ioctls - there is no CDROM.py...
        CDIOCEJECT = 0x20006318
        CDIOCCLOSE = 0x2000631c
        CDIOREADTOCENTRYS = 0xc0086305
        CD_LBA_FORMAT = 1
        CD_MSF_FORMAT = 2
        CDS_NO_DISC = 1
        CDS_DISC_OK = 4
    else:
        # see linux/cdrom.h and Documentation/ioctl/cdrom.txt
        CDROMEJECT           = 0x5309
        CDROM_GET_CAPABILITY = 0x5331
        CDROMCLOSETRAY       = 0x5319  # pendant of CDROMEJECT
        CDROM_SET_OPTIONS    = 0x5320  # Set behavior options
        CDROM_CLEAR_OPTIONS  = 0x5321  # Clear behavior options
        CDROM_SELECT_SPEED   = 0x5322  # Set the CD-ROM speed
        CDROM_SELECT_DISC    = 0x5323  # Select disc (for juke-boxes)
        CDROM_MEDIA_CHANGED  = 0x5325  # Check is media changed
        CDROM_DRIVE_STATUS   = 0x5326  # Get tray position, etc.
        CDROM_DISC_STATUS    = 0x5327  # Get disc type, etc.
        CDROM_CHANGER_NSLOTS = 0x5328  # Get number of slots
        CDROM_LOCKDOOR       = 0x5329  # lock or unlock door
        CDROM_DEBUG          = 0x5330  # Turn debug messages on/off
        CDROM_GET_CAPABILITY = 0x5331  # get capabilities
        # CDROM_DRIVE_STATUS
        CDS_NO_INFO = 0
        CDS_NO_DISC = 1
        CDS_TRAY_OPEN = 2
        CDS_DRIVE_NOT_READY = 3
        CDS_DISC_OK = 4
        # capability flags
        CDC_CLOSE_TRAY       = 0x1     # caddy systems _can't_ close
        CDC_OPEN_TRAY        = 0x2     # but _can_ eject.
        CDC_LOCK             = 0x4     # disable manual eject
        CDC_SELECT_SPEED     = 0x8     # programmable speed
        CDC_SELECT_DISC      = 0x10    # select disc from juke-box
CDC_MO_DRIVE         = 0x40000
CDC_MRW              = 0x80000
CDC_MRW_W            = 0x100000
CDC_RAM              = 0x200000
# CDROM_DISC_STATUS
CDS_AUDIO = 100
CDS_DATA_1 = 101
CDS_DATA_2 = 102
CDS_XA_2_1 = 103
CDS_XA_2_2 = 104
CDS_MIXED = 105
-----------------------------

So Freevo does stil work if we remove the CDROM module. I still think that the Python standard library is not the right place for such constants. A third party module providing an API would be a better idea.

socket.SO_PEERCRED has been added to Python 3.3 by c64216addd7f:

"Add support for the send/recvmsg API to the socket module. Patch by David Watson and Heiko Wundram. (Closes #6560)"

socket.SO_PEERCRED is not listed in socket documentation.

socket has no SO_BINDTODEVICE constant yet.

RTLD_NOW, RTLD_GLOBAL and RTLD_LAZY will added to the posix module if my issue #13226 is accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Thu Oct 20 18:53:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Oct 2011 16:53:59 +0000
Subject: [issue13233] os.acces documentation error
In-Reply-To: <1319127640.96.0.83884717457.issue13233@psf.upfronthosting.co.za>
Message-ID: <E1RGvsR-0007Zd-2F@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1d8fad82c32d by Ezio Melotti in branch '3.2':
#13233: fix typo.
http://hg.python.org/cpython/rev/1d8fad82c32d

New changeset 99c8b93c57cd by Ezio Melotti in branch 'default':
#13233: null merge with 3.2.
http://hg.python.org/cpython/rev/99c8b93c57cd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13233>
_______________________________________

From report at bugs.python.org  Thu Oct 20 18:54:46 2011
From: report at bugs.python.org (Manuel de la Pena)
Date: Thu, 20 Oct 2011 16:54:46 +0000
Subject: [issue13234] os.listdir breaks with literal paths
Message-ID: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>


New submission from Manuel de la Pena <manuel at canonical.com>:

During the development of an application that needed to write paths longer than 260 chars we opted to use \\?\ as per http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath.

When working with literal paths the following the os.listdir funtion would return the following trace:

>>> import os
>>> test = r'\\?\C:\Python27'
>>> os.listdir(test)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: '\\\\?\\C:\\Python27/*.*'

The reason for this is that the implementation of listdir appends '/' at the end of the path if os.path.sep is not present at the end of it which FindFirstFile does not like. This is a inconsistency from the OS but it can be easily fixed (see attached patch).

----------
components: Library (Lib)
files: listdir.patch
keywords: patch
messages: 146031
nosy: mandel
priority: normal
severity: normal
status: open
title: os.listdir breaks with literal paths
versions: Python 2.7
Added file: http://bugs.python.org/file23482/listdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Thu Oct 20 18:54:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Oct 2011 16:54:54 +0000
Subject: [issue13233] os.acces documentation error
In-Reply-To: <1319127640.96.0.83884717457.issue13233@psf.upfronthosting.co.za>
Message-ID: <E1RGvtJ-0007eZ-M1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8bf9724dcd49 by Ezio Melotti in branch '2.7':
#13233: fix typo.
http://hg.python.org/cpython/rev/8bf9724dcd49

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13233>
_______________________________________

From report at bugs.python.org  Thu Oct 20 18:55:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 16:55:40 +0000
Subject: [issue13233] os.acces documentation error
In-Reply-To: <1319127640.96.0.83884717457.issue13233@psf.upfronthosting.co.za>
Message-ID: <1319129740.0.0.403389137443.issue13233@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13233>
_______________________________________

From report at bugs.python.org  Thu Oct 20 19:08:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 17:08:38 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1319130518.24.0.310773229344.issue12753@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If the latest patch is fine I'll commit it shortly.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Thu Oct 20 19:10:50 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 20 Oct 2011 17:10:50 +0000
Subject: [issue13219] re module doc has minor inaccuracy in character sets
In-Reply-To: <1319033680.8.0.92268984905.issue13219@psf.upfronthosting.co.za>
Message-ID: <1319130650.1.0.43682111564.issue13219@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Well, the actual behavior is a little bit more complex to describe.

>>> re.match('[.-_a-z]', '-')
>>> re.match('[._-a-z]', '-')
<_sre.SRE_Match object at 0x100418e80>


>>> re.match('[.-_a-z]', 'b')
<_sre.SRE_Match object at 0x100418b88>
>>> re.match('[._-a-z]', 'b')

However, I don't think it is worth changing again the documentation.

----------
nosy: +flox
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13219>
_______________________________________

From report at bugs.python.org  Thu Oct 20 19:11:06 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 20 Oct 2011 17:11:06 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1319130518.24.0.310773229344.issue12753@psf.upfronthosting.co.za>
Message-ID: <12656.1319130657@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Yes, it looks good.  Thank you very much.

-tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Thu Oct 20 19:17:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 17:17:23 +0000
Subject: [issue13219] re module doc has minor inaccuracy in character sets
In-Reply-To: <1319033680.8.0.92268984905.issue13219@psf.upfronthosting.co.za>
Message-ID: <1319131043.66.0.101947767997.issue13219@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Indeed.
The "tricks" of putting '-' at the beginning/end and ']' at the beginning are well known and works with most of the implementations afaik, but I would consider the behavior of [._-a-z] as an implementation detail and don't expect it to work elsewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13219>
_______________________________________

From report at bugs.python.org  Thu Oct 20 19:38:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Oct 2011 17:38:34 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1319132314.64.0.947914769551.issue7322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> One could then continue processing, sending new transactions to the POP 
> server and getting responses. 

That's optimistic. You don't know how much data has been lost in readline(). Sure, again your test server, it happens to work :) But again other kinds of failing servers, your protocol session would end up confused.
So the only robust option is the following:

> tearing down the
> connection and rebuilding it, and restarting the POP processing from
> the beginning

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Oct 20 19:43:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Oct 2011 17:43:49 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319132629.89.0.192128926778.issue13234@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, pitrou, tim.golden
stage:  -> patch review
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Thu Oct 20 19:43:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Oct 2011 17:43:59 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319132639.83.0.394626034007.issue13234@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Thu Oct 20 19:48:50 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 20 Oct 2011 17:48:50 +0000
Subject: [issue13235] logging.warn() is not documented
Message-ID: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

No docs for logging.warn() alias.

----------
assignee: docs at python
components: Documentation
messages: 146039
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: logging.warn() is not documented
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Thu Oct 20 19:49:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 17:49:26 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319132966.07.0.395143355712.issue13235@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Thu Oct 20 20:01:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Oct 2011 18:01:15 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1319133675.3.0.709660908857.issue7322@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't think it is optimistic.  The poplib transaction pattern is: send a command, get a response.  If the response is not properly terminated, throw it away.  Send a new command, get a response.  There's no ambiguity there.  In addition, this is a common tcp client-server model, so I think it applies more widely than just poplib.

Please note that the timeout is *not* because the socket data transmission has timed out and data was lost in transit.  There are no partially filled readline buffers in this scenario.  The timeout is because the client is waiting for a *line* of data that the server never sends.  Again, this is likely to be a common failure mode in tcp client/server applications, and to my mind is exactly what the timeout parameter to the constructor is most useful for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Oct 20 20:13:18 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 20 Oct 2011 18:13:18 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319134398.15.0.848474796766.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I want to move this forward.

Apparently, "/dev/poll" could be actually used transparently in python "select.poll()" implementation. The semantics seems to be the same, so we could use the "poll" syscall or "/dev/poll" statically at compiling time, or dinamically at poll object creation time (try to open /dev/poll and go to "poll" syscall if that fails).

Some details:

http://developers.sun.com/solaris/articles/using_devpoll.html
http://developers.sun.com/solaris/articles/polling_efficient.html

I agree that Solaris 10 event framework would be nice to support too, but that would be another feature request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Thu Oct 20 20:13:26 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 20 Oct 2011 18:13:26 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319134406.86.0.20103290987.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Thu Oct 20 20:43:38 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 20 Oct 2011 18:43:38 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319136218.71.0.2573971309.issue13235@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

That's deliberate. The original code (before incorporation into Python) had warn(), which was kept for backward compatibility. The docs refer to warning() because that's what everyone is supposed to use. The method names map to the lower case of the appropriate logging level name.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Thu Oct 20 21:02:04 2011
From: report at bugs.python.org (Peter Eisentraut)
Date: Thu, 20 Oct 2011 19:02:04 +0000
Subject: [issue13236] unittest needs more flush calls
Message-ID: <1319137324.16.0.266090134048.issue13236@psf.upfronthosting.co.za>


New submission from Peter Eisentraut <peter_e at gmx.net>:

I'm using the TextTestRunner class in unittest/runner.py with a special file-like object passed in as stream.  Doing this loses some output, because the run() method (and some lower-level methods) don't always call flush() on the stream.  There is also no obvious cleanup method in the runner class that might do this, so I assume run() should do that itself.

Right now, it looks like it assumes that either the stream is effectively unbuffered, like stderr, or that the end of the program might flush things, but that doesn't always apply.

It looks like the best fix would be a self.stream.flush() call at the end of run().  Another flush() call at the end of printErrorList() would also help.

(In the meantime, I have fixed up my special file-like class to flush its internal buffers when a newline is seen, which kind of works, but a proper cleanup of this matter would still be nice.)

----------
components: Library (Lib)
messages: 146043
nosy: petere
priority: normal
severity: normal
status: open
title: unittest needs more flush calls
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13236>
_______________________________________

From report at bugs.python.org  Thu Oct 20 21:20:11 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Oct 2011 19:20:11 +0000
Subject: [issue13236] unittest needs more flush calls
In-Reply-To: <1319137324.16.0.266090134048.issue13236@psf.upfronthosting.co.za>
Message-ID: <1319138411.94.0.790252404409.issue13236@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

How can a lack of flushes lose output?  Delay it maybe, but unless your file class is broken I don't see how data would be lost.

----------
nosy: +r.david.murray
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13236>
_______________________________________

From report at bugs.python.org  Thu Oct 20 21:32:50 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 20 Oct 2011 19:32:50 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319139170.51.0.777564314772.issue13235@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I've got a traceback, because forgot to implement this method in logging wrapper. It should be either deprecated and removed or documented.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Thu Oct 20 21:40:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Oct 2011 19:40:45 +0000
Subject: [issue13226] Expose RTLD_* constants in the posix module
In-Reply-To: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za>
Message-ID: <1319139645.8.0.722198028889.issue13226@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated patch: remove "either" in the documentation. Thanks neologix par the review.

----------
Added file: http://bugs.python.org/file23483/posix_rtld-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13226>
_______________________________________

From report at bugs.python.org  Thu Oct 20 21:49:47 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 20 Oct 2011 19:49:47 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1319140187.76.0.0938372698867.issue12753@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Thu Oct 20 22:03:47 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 20 Oct 2011 20:03:47 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1319141027.77.0.0573064752426.issue7322@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Oct 20 22:26:04 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 20 Oct 2011 20:26:04 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319139170.51.0.777564314772.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319142359.42055.YahooMailNeo@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It is deprecated by not being documented. It certainly isn't going to have documentation added for it.

Which code was calling the warn() method? Is it not possible to change this to call warning()?

----- Original Message -----
> From: anatoly techtonik <report at bugs.python.org>
> To: vinay_sajip at yahoo.co.uk
> Cc: 
> Sent: Thursday, 20 October 2011, 20:32
> Subject: [issue13235] logging.warn() is not documented
> 
> 
> anatoly techtonik <techtonik at gmail.com> added the comment:
> 
> I've got a traceback, because forgot to implement this method in logging 
> wrapper. It should be either deprecated and removed or documented.
> 
> ----------
> status: closed -> open
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13235>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Thu Oct 20 22:33:32 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 20 Oct 2011 20:33:32 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1319133675.3.0.709660908857.issue7322@psf.upfronthosting.co.za>
Message-ID: <CAGE7PNJcVL9uHnCYbY9Ybx1VJrhk-T5D8A4-PZAniNeo9rAnvg@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

If the server failed to close a transaction the protocol stream is over
unless you mime relying on hope and luck. Poplib has a nasty set of server
implementation bugs to work around here.

Readline as defined today no longer suits its needs but I still strongly
believe the behavior of shutting reading down after a timeout is a good one.

One thing that would solve your common case: don't shut down reading on a
readline timeout if zero data was received into the internal line buffer.
Readline could indicate this by modifying the timeout exception being raised
to indicate if it can recover or not. The flag should only be set if it was
unrecoverable.
On Oct 20, 2011 11:01 AM, "R. David Murray" <report at bugs.python.org> wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> I don't think it is optimistic.  The poplib transaction pattern is: send a
> command, get a response.  If the response is not properly terminated, throw
> it away.  Send a new command, get a response.  There's no ambiguity there.
>  In addition, this is a common tcp client-server model, so I think it
> applies more widely than just poplib.
>
> Please note that the timeout is *not* because the socket data transmission
> has timed out and data was lost in transit.  There are no partially filled
> readline buffers in this scenario.  The timeout is because the client is
> waiting for a *line* of data that the server never sends.  Again, this is
> likely to be a common failure mode in tcp client/server applications, and to
> my mind is exactly what the timeout parameter to the constructor is most
> useful for.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7322>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Oct 20 22:40:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Oct 2011 20:40:43 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1319143243.87.0.73842122466.issue7322@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Your suggestion sounds good to me.

I still think that it is a common failure mode in a client server transaction for the server to fail to send a (complete) line that the client is expecting, and vice versa, requiring a timeout, but not necessarily a "restart from scratch".  Often the client/server protocol has a useful checkpoint to restart from short of start from scratch.  In the case of many protocols, that would be "client issues a new command".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Oct 20 22:51:51 2011
From: report at bugs.python.org (Mikhail Novikov)
Date: Thu, 20 Oct 2011 20:51:51 +0000
Subject: [issue13125] test_all_project_files() expected failure
In-Reply-To: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>
Message-ID: <1319143911.46.0.531951296675.issue13125@psf.upfronthosting.co.za>


Mikhail Novikov <freiksenet at gmail.com> added the comment:

Updated patch to work properly with verbosity.

----------
Added file: http://bugs.python.org/file23484/i13125-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13125>
_______________________________________

From report at bugs.python.org  Thu Oct 20 23:00:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Oct 2011 21:00:48 +0000
Subject: [issue13236] unittest needs more flush calls
In-Reply-To: <1319137324.16.0.266090134048.issue13236@psf.upfronthosting.co.za>
Message-ID: <1319144448.16.0.334306434912.issue13236@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you provide a minimal test case to reproduce the issue?

----------
nosy: +ezio.melotti
stage:  -> test needed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13236>
_______________________________________

From report at bugs.python.org  Thu Oct 20 23:15:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Oct 2011 21:15:44 +0000
Subject: [issue9168] setuid in smtp.py sheds privileges before binding port
In-Reply-To: <1278346841.06.0.147409219565.issue9168@psf.upfronthosting.co.za>
Message-ID: <E1RGzxj-0006SV-RR@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7d92b94b0eec by Florent Xicluna in branch '3.2':
Issue #9168: now smtpd is able to bind privileged port.
http://hg.python.org/cpython/rev/7d92b94b0eec

New changeset bbd92b42508e by Florent Xicluna in branch 'default':
Issue #9168: now smtpd is able to bind privileged port.
http://hg.python.org/cpython/rev/bbd92b42508e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9168>
_______________________________________

From report at bugs.python.org  Thu Oct 20 23:22:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Oct 2011 21:22:26 +0000
Subject: [issue9168] setuid in smtp.py sheds privileges before binding port
In-Reply-To: <1278346841.06.0.147409219565.issue9168@psf.upfronthosting.co.za>
Message-ID: <E1RH04E-00072q-0J@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d2f303861c98 by Florent Xicluna in branch '2.7':
Issue #9168: now smtpd is able to bind privileged port.
http://hg.python.org/cpython/rev/d2f303861c98

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9168>
_______________________________________

From report at bugs.python.org  Thu Oct 20 23:30:33 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 20 Oct 2011 21:30:33 +0000
Subject: [issue9168] setuid in smtp.py sheds privileges before binding port
In-Reply-To: <1278346841.06.0.147409219565.issue9168@psf.upfronthosting.co.za>
Message-ID: <1319146233.42.0.986802957558.issue9168@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed. Thank you for the patch.

----------
nosy: +flox
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9168>
_______________________________________

From report at bugs.python.org  Thu Oct 20 23:58:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Oct 2011 21:58:21 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <E1RH0cz-0001G5-0M@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c1effa2cdd20 by Antoine Pitrou in branch 'default':
Issue #12170: The count(), find(), rfind(), index() and rindex() methods
http://hg.python.org/cpython/rev/c1effa2cdd20

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Thu Oct 20 23:58:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Oct 2011 21:58:47 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1319147927.02.0.221744197295.issue12170@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed, thank you!

----------
assignee: rhettinger -> 
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Fri Oct 21 02:43:18 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 21 Oct 2011 00:43:18 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319157798.22.0.992439823252.issue13235@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

./trac/env.py:                self.log.warn('base_url option not set in configuration, '
./trac/env.py:            self.log.warn('Couldn\'t write sample configuration file (%s)', e,
./trac/web/main.py:            ##    env.log.warn("%d uncollectable objects found.", uncollectable)
./trac/web/main.py:            env.log.warn(exception_to_unicode(e))
./trac/web/.svn/text-base/main.py.svn-base:            ##    env.log.warn("%d uncollectable objects found.", uncollectable)
./trac/web/.svn/text-base/main.py.svn-base:            env.log.warn(exception_to_unicode(e))
./trac/wiki/formatter.py:            self.env.log.warn(e)
./trac/wiki/.svn/text-base/formatter.py.svn-base:            self.env.log.warn(e)
./trac/versioncontrol/api.py:                        self.log.warn("Discarding duplicate repository '%s'",
./trac/versioncontrol/api.py:            self.log.warn("Found no repositories matching '%s' base.",
./trac/versioncontrol/svn_prop.py:                    self.log.warn("svn:externals entry %s doesn't contain "
./trac/versioncontrol/.svn/text-base/api.py.svn-base:                        self.log.warn("Discarding duplicate repository '%s'",
./trac/versioncontrol/.svn/text-base/api.py.svn-base:            self.log.warn("Found no repositories matching '%s' base.",
./trac/versioncontrol/.svn/text-base/svn_prop.py.svn-base:                    self.log.warn("svn:externals entry %s doesn't contain "
./trac/ticket/roadmap.py:        def warn(msg):
./trac/ticket/roadmap.py:                warn(_('Milestone "%(name)s" already exists, please '
./trac/ticket/roadmap.py:                warn(_('You must provide a name for the milestone.'))
./trac/ticket/roadmap.py:                warn(_('Completion date may not be in the future'))
./trac/ticket/.svn/text-base/roadmap.py.svn-base:        def warn(msg):
./trac/ticket/.svn/text-base/roadmap.py.svn-base:                warn(_('Milestone "%(name)s" already exists, please '
./trac/ticket/.svn/text-base/roadmap.py.svn-base:                warn(_('You must provide a name for the milestone.'))
./trac/ticket/.svn/text-base/roadmap.py.svn-base:                warn(_('Completion date may not be in the future'))
./trac/admin/web_ui.py:                        self.env.log.warn("Adding %s to group %s: " \
./trac/admin/.svn/text-base/web_ui.py.svn-base:                        self.env.log.warn("Adding %s to group %s: " \
./trac/prefs/web_ui.py:            self.log.warn('Unknown preference panel %r', panel_id)
./trac/prefs/.svn/text-base/web_ui.py.svn-base:            self.log.warn('Unknown preference panel %r', panel_id)
./trac/.svn/text-base/env.py.svn-base:                self.log.warn('base_url option not set in configuration, '
./trac/.svn/text-base/env.py.svn-base:            self.log.warn('Couldn\'t write sample configuration file (%s)', e,


quite a lot + probably trac plugins. So it's better to go through deprecation cycle and show appropriate message (but frankly - I don't mind against convenience alias - we already have some in testing modules).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Fri Oct 21 04:28:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 02:28:27 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319164107.53.0.281640993772.issue13235@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think it's better to avoid "deprecations by missing documentation" and document explicitly if something is deprecated.
What happens is that people working on some old code find the deprecated method, check the doc to see what it does, don't find anything, get puzzled for a while until they figure out how it works, and then use it.
If they find it and see that is deprecated they will stop using it and start using the right method.
While it's true that new users don't need to know that there's a deprecated method, it's unlikely that they will start using it, so documenting deprecated methods makes more good than harm.
If you want to remove it eventually you'll also have to go through an actual deprecation process with warnings.

----------
nosy: +ezio.melotti
resolution: invalid -> 
stage:  -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Fri Oct 21 07:25:02 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Oct 2011 05:25:02 +0000
Subject: [issue13237] subprocess docs should use emphasise convenience
	functions
Message-ID: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Many typical subprocess use cases can now be handled simply via the convenience functions:

  subprocess.call()
  subprocess.check_call()
  subprocess.check_output()

However, readers of the documentation could be forgiven for not realising that, since the docs dive right in with Popen() and will scare most readers away in search of more user friendly APIs (or even other languages).

The module documentation should be reordered to introduce the helper function first, then Popen afterwards.

The "subprocess replacements" [1] section would ideally help address this, but it hasn't been updated to use the convenience function, instead using confusing direct calls to Popen.

[1] http://docs.python.org/library/subprocess.html#subprocess-replacements

----------
assignee: docs at python
components: Documentation
messages: 146059
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: subprocess docs should use emphasise convenience functions
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Fri Oct 21 07:29:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 05:29:37 +0000
Subject: [issue13237] subprocess docs should use emphasise convenience
	functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319174977.49.0.149280913098.issue13237@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Fri Oct 21 07:43:17 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Fri, 21 Oct 2011 05:43:17 +0000
Subject: [issue13214] Cmd: list available completions from the cmd.Cmd
	subclass and filter out EOF handler(s)
In-Reply-To: <1318965366.62.0.48247525728.issue13214@psf.upfronthosting.co.za>
Message-ID: <1319175797.72.0.144772812854.issue13214@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Here's a version incorporating your suggestion and better documenting the choices and the method for overriding purposes. I have a few reservations with the current implementation:

1. As noted, the information for the class really could be and should be cached as the attributes of a given cmd.Cmd derived class don't change all that frequently.
2. One has to override the entire function in order to get what I consider standard functionality (filtering).. so I don't know if that's a good idea.
3. I've thought about the do_EOF handler stuff, and it would be nice if that was shoved into the completer method(s) as a keyword argument, defaulting to False -- that way one could avoid having to explicitly install an EOF handler when dealing with ^D, etc, but this can be hashed out better in a different issue, over IRC, email, etc.

This module could be better cleaned up (isn't PEP8 compliant, overrides built-ins, is pythonic but not super pythonic, etc), but I'll see what other modules exist out there that could be used in its place, because they could have resolved some of these issues. There is some value that can be obtained from pexpect, some of the other cmd module variants, etc .. I just like this module because it's nice, simple, and standard -- it just needs a little love and it will be awesome.

Anyhow -- thanks again for the work :).

----------
Added file: http://bugs.python.org/file23485/python-cmd-better-filtering.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13214>
_______________________________________

From report at bugs.python.org  Fri Oct 21 08:00:13 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Oct 2011 06:00:13 +0000
Subject: [issue13238] Add shell command helpers to shutil module
Message-ID: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I've been doing a few systems administration tasks with Python recently, and shell command invocation directly via the subprocess module is annoyingly clunky (even with the new convenience APIs).

Since subprocess needs to avoid the shell by default for security reasons, I suggest we add the following simple helper functions to shutil:

    def call(cmd, *args, **kwds):
        if args or kwds:
            cmd = cmd.format(*args, **kwds)
        return subprocess.call(cmd, shell=True)

    def check_call(cmd, *args, **kwds):
        if args or kwds:
            cmd = cmd.format(*args, **kwds)
        return subprocess.check_call(cmd, shell=True)

    def check_output(cmd, *args, **kwds):
        if args or kwds:
            cmd = cmd.format(*args, **kwds)
        return subprocess.check_output(cmd, shell=True)


Initially posted at:
http://code.activestate.com/recipes/577891-simple-invocation-of-shell-commands/

Of course, even if others agree in principle, documentation and tests are still needed before this change can go anywhere.

----------
components: Library (Lib)
messages: 146061
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add shell command helpers to shutil module
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Fri Oct 21 08:01:40 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 21 Oct 2011 06:01:40 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319176900.77.0.0648521424045.issue13238@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

These feel like a shell injection waiting to happen to me.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Fri Oct 21 08:06:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Oct 2011 06:06:21 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319177181.24.0.79982053454.issue13237@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: subprocess docs should use emphasise convenience functions -> subprocess docs should emphasise convenience functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Fri Oct 21 08:33:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Oct 2011 06:33:53 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za>
Message-ID: <E1RH8fs-0005tR-Mv@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 37479f0f68bc by Vinay Sajip in branch 'default':
Closes #13235: Added deprecation for warn() methods and function in logging.
http://hg.python.org/cpython/rev/37479f0f68bc

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Fri Oct 21 08:36:37 2011
From: report at bugs.python.org (Thomas Guettler)
Date: Fri, 21 Oct 2011 06:36:37 +0000
Subject: [issue13232] Logging: Unicode Error
In-Reply-To: <1319121800.04.0.366773580653.issue13232@psf.upfronthosting.co.za>
Message-ID: <1319178998.0.0.280332822316.issue13232@psf.upfronthosting.co.za>


Changes by Thomas Guettler <guettli at thomas-guettler.de>:


Added file: http://bugs.python.org/file23486/unicodedecodeerror-in-logging.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13232>
_______________________________________

From report at bugs.python.org  Fri Oct 21 08:36:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Oct 2011 06:36:58 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319179018.59.0.387333173739.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

And that's exactly the problem - a web developer's or security auditor's "shell injection" is a system administrator's "this language sucks".

These wrappers are the kind of thing you want for shell invocations when using Python as a replacement for a shell script or rewriting something that was originally written in Perl, but they're a terrible idea if anything you're interpolating came from an untrusted data source.

Currently, requiring "shell=True" in the arguments to the subprocess calls is considered a sufficient deterrent against people doing the wrong thing. I'm suggesting that requiring "import shutil" instead of "import subprocess" may be a similarly acceptable compromise that better serves the system administrators that choose to use Python for system automation tasks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Fri Oct 21 08:41:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Oct 2011 06:41:58 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319179318.53.0.205854726663.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Perhaps a better idea would be to use different names, so it's clearer at the point of invocation that the shell is being invoked (and hence shell injection attacks are a potential concern). For example:

  shell_call
  check_shell_call
  check_shell_output

That would make large applications easier to audit (just search for 'shell_') while still making life easier for sysadmins.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Fri Oct 21 08:42:24 2011
From: report at bugs.python.org (Thomas Guettler)
Date: Fri, 21 Oct 2011 06:42:24 +0000
Subject: [issue13232] Logging: Unicode Error
In-Reply-To: <1319121800.04.0.366773580653.issue13232@psf.upfronthosting.co.za>
Message-ID: <1319179344.11.0.251756700497.issue13232@psf.upfronthosting.co.za>


Thomas Guettler <guettli at thomas-guettler.de> added the comment:

I attached a testcase (unicodedecodeerror-in-logging.py). If the filesystemencoding is UTF-8 and the source code is encoded in latin1, then the logging fails. It happens because there is a German umlaut in the comment behind 1/0.

I added 'replace' to the decode() in __init__.py and the it works. The German umlaut gets displayed as inverted question mark. But this is better than no logging message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13232>
_______________________________________

From report at bugs.python.org  Fri Oct 21 09:19:48 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 21 Oct 2011 07:19:48 +0000
Subject: [issue13226] Expose RTLD_* constants in the posix module
In-Reply-To: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za>
Message-ID: <1319181588.78.0.75785874247.issue13226@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Note that I'm really +10 on this issue: such constants belong to individual modules rather than to the unmanageable Lib/plat-XXX/.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13226>
_______________________________________

From report at bugs.python.org  Fri Oct 21 09:27:38 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Oct 2011 07:27:38 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319182058.79.0.270416948125.issue13237@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Fri Oct 21 09:44:26 2011
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 21 Oct 2011 07:44:26 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319183066.73.0.783254060684.issue13238@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Is format() really the best choice here, considering that {}s already have a meaning in the shell?

----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Fri Oct 21 10:01:07 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 21 Oct 2011 08:01:07 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319184067.1.0.441904692077.issue13237@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Fri Oct 21 11:11:31 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 21 Oct 2011 09:11:31 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
Message-ID: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Operator <> was removed in Python 3, but still appears in Grammar/Grammar (and hence in Doc/reference/grammar.rst)

Reported by Alexander Ivanyuta on the docs mailing list

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 146070
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: Remove <> operator from Grammar/Grammar
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Oct 21 11:20:21 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 21 Oct 2011 09:20:21 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <1319188821.69.0.880362595614.issue13239@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

The relevant code in Parser/parsetok.c is:

#ifdef PY_PARSER_REQUIRES_FUTURE_KEYWORD
        if (type == NOTEQUAL) {
            if (!(ps->p_flags & CO_FUTURE_BARRY_AS_BDFL) &&
                            strcmp(str, "!=")) {
                err_ret->error = E_SYNTAX;
                break;
            }
            else if ((ps->p_flags & CO_FUTURE_BARRY_AS_BDFL) &&
                            strcmp(str, "<>")) {
                err_ret->text = "with Barry as BDFL, use '<>' "
                                "instead of '!='";
                err_ret->error = E_SYNTAX;
                break;
            }
        }
#endif


Hmm... I'm too new to remember this joke, but here it presents a practical problem - since Grammar/Grammar is being directly reflected into the documentation (.. literalinclude:: ../../Grammar/Grammar) and thus can confuse.

Is it safe to just remove the whole thing from Grammar/Grammar and correspondingly Parser/parsetok.c ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Oct 21 11:23:26 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 21 Oct 2011 09:23:26 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <1319189006.8.0.258517451664.issue13239@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +barry, brett.cannon, fdrake, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Oct 21 11:28:25 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 21 Oct 2011 09:28:25 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <1319189305.06.0.387718012831.issue13239@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This is PEP 401.

"[Because] the != inequality operator ... was a horrible, finger pain inducing mistake, the FLUFL reinstates the <> diamond operator as the sole spelling. This change is important enough to be implemented for, and released in Python 3.1. To help transition to this feature, a new future statement, from __future__ import barry_as_FLUFL has been added."

----------
nosy: +flox
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Oct 21 11:38:54 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Oct 2011 09:38:54 +0000
Subject: [issue13221] No "edit with IDLE" in right click context menu
In-Reply-To: <1319061426.86.0.662417850926.issue13221@psf.upfronthosting.co.za>
Message-ID: <4EA13DA9.10803@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> If the installation process adds the "Open with IDLE" entry, it should do it again when you reinstall

Rather than going through reinstallation, go to "Add and Remove
Programs", find Python 3.2, and select "Repair installation."

Closing the report as invalid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13221>
_______________________________________

From report at bugs.python.org  Fri Oct 21 11:39:07 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Oct 2011 09:39:07 +0000
Subject: [issue13221] No "edit with IDLE" in right click context menu
In-Reply-To: <1319044965.54.0.660981699643.issue13221@psf.upfronthosting.co.za>
Message-ID: <1319189947.25.0.451213799117.issue13221@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13221>
_______________________________________

From report at bugs.python.org  Fri Oct 21 11:42:22 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Oct 2011 09:42:22 +0000
Subject: [issue13226] Expose RTLD_* constants in the posix module
In-Reply-To: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za>
Message-ID: <1319190142.42.0.189262904467.issue13226@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks fine to me. However, I don't think it meets Charles-Fran?ois' requirement of moving the constants into an individual module. Rather than living in the unmanageable plat-XXX, they now live in the unmanageable posixmodule.c...

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13226>
_______________________________________

From report at bugs.python.org  Fri Oct 21 11:55:47 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Oct 2011 09:55:47 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1319190947.82.0.868722041275.issue12753@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Fri Oct 21 12:02:37 2011
From: report at bugs.python.org (Falk Nisius)
Date: Fri, 21 Oct 2011 10:02:37 +0000
Subject: [issue5289] ctypes.util.find_library does not work under Solaris
In-Reply-To: <1234858635.81.0.426092533899.issue5289@psf.upfronthosting.co.za>
Message-ID: <1319191357.0.0.645310398381.issue5289@psf.upfronthosting.co.za>


Falk Nisius <falknisius at gmx.de> added the comment:

Under Ubuntu 11.04 is the _findLib_gcc used and not a ldconfig method.

Why should I install a gcc only to find a dynamic library ? It seems not a well design. The usage of ldconfig, what is more natural at a server in the net than a c compiler. Perhaps it can be changed in the next version, because I can see that on other os th ldconfig method would be preferred.

I'm not an python programmer and have not the possibilities to make a regeression test, thats why I can not help.

----------
nosy: +FalkNisius

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5289>
_______________________________________

From report at bugs.python.org  Fri Oct 21 13:40:52 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Oct 2011 11:40:52 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319197252.39.0.600898485437.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Of the 3 available options (mod style, string.Template and str.format), yes, str.format is the best choice.

If people want the shell meaning of the braces, they can escape them by doubling them up in the command string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Fri Oct 21 15:26:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 13:26:34 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1319203594.68.0.201700318136.issue12296@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is the wording I committed:

(This obviously does not apply to new classes or functions; new arguments should be optional and have default values which maintain the existing behavior.)

Should I push or should I delete the changeset?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Fri Oct 21 15:27:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 13:27:15 +0000
Subject: [issue13181] pysetup install creates .pyc files but pysetup remove
	doesn't delete them
In-Reply-To: <1318615867.17.0.772590919076.issue13181@psf.upfronthosting.co.za>
Message-ID: <1319203635.5.0.669551889676.issue13181@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

\o/

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> distutils doesn't byte-compile .py files to __pycache__ during installation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13181>
_______________________________________

From report at bugs.python.org  Fri Oct 21 15:29:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 13:29:41 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1319203781.45.0.381658936399.issue13224@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I would argue that the previous behavior of str(class) was undefined, or an implementation detail; as a new feature, my patch can break some code that relied on the previous behavior, but we may judge think it?s worth the cost.

BTW, doctest is inherently fragile and broken by many changes, so I?m not too concerned about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Fri Oct 21 15:33:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 13:33:20 +0000
Subject: [issue13228] Add "Quick Start" section to the devguide index
In-Reply-To: <1319067423.48.0.288389971536.issue13228@psf.upfronthosting.co.za>
Message-ID: <1319204000.1.0.0339746301852.issue13228@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+   ``hg clone http://hg.python.org/cpython``;
I use http://hg.python.org/cpython#default to avoid cloning the 2.x branches, that?s an optimization that can save some time and space.

+2. run ``./configure --with-pydebug && make -j2``
Is make -j2 harmless on single-CPU systems?  Doesn?t our make default to -j0 anyway, to use all CPUs?

+3. :doc:`run the tests <runtests>` with ``./python -m test``;
Is that cross-platform?  Mac OS X has python.exe for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13228>
_______________________________________

From report at bugs.python.org  Fri Oct 21 15:52:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Oct 2011 13:52:29 +0000
Subject: [issue3902] Packages containing only extension modules have to
	contain __init__.py
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <E1RHFWJ-0007Fv-6r@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f84040b11211 by ?ric Araujo in branch 'default':
Document that packaging doesn?t create __init__.py files (#3902).
http://hg.python.org/cpython/rev/f84040b11211

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Fri Oct 21 15:52:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Oct 2011 13:52:29 +0000
Subject: [issue13205] NameErrors in generated setup.py (codecs,
	split_multiline)
In-Reply-To: <1318902833.17.0.0898413636747.issue13205@psf.upfronthosting.co.za>
Message-ID: <E1RHFWJ-0007Fv-6d@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 21c33aa2178b by ?ric Araujo in branch 'default':
Fix missing imports in setup scripts generated by packaging (#13205).
http://hg.python.org/cpython/rev/21c33aa2178b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13205>
_______________________________________

From report at bugs.python.org  Fri Oct 21 15:52:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Oct 2011 13:52:30 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <E1RHFWJ-0007Fv-6l@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0aad55c8ff26 by ?ric Araujo in branch 'default':
Add tests for packaging.tests.support (#12659).
http://hg.python.org/cpython/rev/0aad55c8ff26

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Fri Oct 21 15:52:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 13:52:40 +0000
Subject: [issue13229] Add shutil.filter_walk
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1319205160.99.0.448995663947.issue13229@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13229>
_______________________________________

From report at bugs.python.org  Fri Oct 21 15:54:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 13:54:16 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319205256.71.0.12121370158.issue13238@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Why not keeping these helpers in subprocess?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Fri Oct 21 15:58:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Oct 2011 13:58:01 +0000
Subject: [issue13205] NameErrors in generated setup.py (codecs,
	split_multiline)
In-Reply-To: <1318902833.17.0.0898413636747.issue13205@psf.upfronthosting.co.za>
Message-ID: <E1RHFbg-0007lf-TA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5949563b9f1c by ?ric Araujo in branch 'default':
Fix missing imports in generated setup scripts (#13205).
http://hg.python.org/distutils2/rev/5949563b9f1c

New changeset eb845a9a00b7 by ?ric Araujo in branch 'python3':
Merge fix for #13205 and other changes from default.
http://hg.python.org/distutils2/rev/eb845a9a00b7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13205>
_______________________________________

From report at bugs.python.org  Fri Oct 21 16:01:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 14:01:39 +0000
Subject: [issue13205] NameErrors in generated setup.py (codecs,
	split_multiline)
In-Reply-To: <1318902833.17.0.0898413636747.issue13205@psf.upfronthosting.co.za>
Message-ID: <1319205699.26.0.746805925449.issue13205@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

As you can see in my commit, I made more changes to the code and simplified the tests.  subprocess is definitely the way to test script functionality, it?s much cleaner than monkey-patching sys.argv; we even have higher-level helpers to do that in test.script_helper.

(BTW, the comment I made about mocking user input in my first reply makes no sense: I was confusing pysetup create and pysetup generate-setup :)  I also mistakenly talked about test_run when the correct file was test_util.)

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13205>
_______________________________________

From report at bugs.python.org  Fri Oct 21 16:02:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 14:02:51 +0000
Subject: [issue3902] Packages containing only extension modules have to
	contain __init__.py
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1319205771.63.0.579010713934.issue3902@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I thought about the wording again and committed a different version.  I also decided not to backport to distutils; see the commit message for a rationale.  Thanks for the help!

----------
components:  -Distutils, Distutils2
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -3rd party, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Fri Oct 21 16:14:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 14:14:31 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1319206471.34.0.725279255187.issue12659@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This first patch is committed!  If you have any question about the changes I made to your patch, feel free to ask them.  The most important change I did was running setUp and tearDown before and after each test method, as real unittest would do.

If you want to you write more tests, know that there are some things I want to remove or merge.  TestDistribution and create_distribution will probably be removed when I manage to work on my config module rewrite.

On the contrary, LoggingCatcher and EnvironRestorer won?t go away, so someone interested can work on testing them (LoggingCatcher: medium to hard, EnvironRestorer: piece of cake).

Finally, I?m not sure it?s useful to test two specific functions.  copy_xxmodule_c is tested by running the tests in different ways (via python -m test, python Lib/packaging/tests/test_thing.py, ../../../python test_thing.py); that?s how I made sure it worked in different situations, and tests wouldn?t have helped.  For fixup_build_ext, we know it works because we have buildbots compiling Python with various options (shared on Unix, debug on Windows) and our tests pass, so fixup_build_ext is doing its job.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Fri Oct 21 16:41:26 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 21 Oct 2011 14:41:26 +0000
Subject: [issue13240] computed gotos not enabled?
Message-ID: <1319208086.31.0.00990210804778.issue13240@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

According to issue 9203 the computed gotos should be enabled by default since 3.2.
However, it is not visible from the interpreter.

Python 3.2.2 (default, Sep  7 2011, 10:55:43) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
>>> from sysconfig import get_config_var
>>> get_config_var('HAVE_COMPUTED_GOTOS')
1
>>> get_config_var('USE_COMPUTED_GOTOS')
0

----------
components: Build
messages: 146090
nosy: flox, pitrou
priority: normal
severity: normal
status: open
title: computed gotos not enabled?
type: performance
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Fri Oct 21 16:55:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 14:55:55 +0000
Subject: [issue12913] Add a debugging howto
In-Reply-To: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za>
Message-ID: <1319208955.52.0.952666076947.issue12913@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Terry]
> Binary search with print is done manually. If error not obvious from quick read, in a 20 line
> function, add print around line 10. If ok there, look down and add print later in function. [...]
Okay, so it?s what I thought only I didn?t had the name :)

> More time: read outline, good start.
Thanks!  I?ll publish a repo when I start writing.

[Ezio]
> Hadn?t though about coverage.  Will mention it and add a link
> to the devguide part that talks about it.

> Is devguide/coverage.html#using-coverage-py generic enough?
I had a quick look and it looks good.

> We don't have to duplicate the coverage documentation though, mentioning the tool and what it
> does, provide a couple of simple example and a link to the coverage doc should be enough.
Yep, I was thinking about mentioning, nothing more.

>> - running Python in gdb
> This is somewhat orthogonal, but the devguide/gdb page doesn't say how to start running Python
> in gdb (it might be obvious to people used to use gdb, but it should still be mentioned).
If the devguide is updated, I will be content with just one line containing one link in my howto.  Currently we have this wiki page: http://wiki.python.org/moin/DebuggingWithGdb  I also remember a ubuntu wiki page with more useful info but can?t find the bookmark.


FTR, I will use these resources: https://pythonconquerstheuniverse.wordpress.com/2009/09/10/debugging-in-python/ and http://www.jeetworks.org/node/99

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12913>
_______________________________________

From report at bugs.python.org  Fri Oct 21 16:57:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 14:57:54 +0000
Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to
	urllib
In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za>
Message-ID: <1319209074.81.0.0315569887775.issue4733@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure real HTML (i.e. sent as text/html) should have an XML prolog honored.  For XML, there?s http://tools.ietf.org/html/rfc3023

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4733>
_______________________________________

From report at bugs.python.org  Fri Oct 21 17:03:08 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 21 Oct 2011 15:03:08 +0000
Subject: [issue12913] Add a debugging howto
In-Reply-To: <1319208955.52.0.952666076947.issue12913@psf.upfronthosting.co.za>
Message-ID: <1319209365.29003.74.camel@surprise>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> >> - running Python in gdb
> > This is somewhat orthogonal, but the devguide/gdb page doesn't say how to start running Python
> > in gdb (it might be obvious to people used to use gdb, but it should still be mentioned).
> If the devguide is updated, I will be content with just one line containing one link in my howto.  Currently we have this wiki page: http://wiki.python.org/moin/DebuggingWithGdb  I also remember a ubuntu wiki page with more useful info but can?t find the bookmark.
> 
> 
> FTR, I will use these resources: https://pythonconquerstheuniverse.wordpress.com/2009/09/10/debugging-in-python/ and http://www.jeetworks.org/node/99

There's also:
http://docs.python.org/devguide/gdb.html

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12913>
_______________________________________

From report at bugs.python.org  Fri Oct 21 17:12:49 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 21 Oct 2011 15:12:49 +0000
Subject: [issue13125] test_all_project_files() expected failure
In-Reply-To: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>
Message-ID: <1319209969.63.0.941322122699.issue13125@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Note that I think it's best to fix the underlying failures rather than silence them. ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13125>
_______________________________________

From report at bugs.python.org  Fri Oct 21 17:23:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 15:23:02 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319210582.34.0.519230865524.issue13237@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

>From a quick look it seems to me that only 
-   output = Popen(["mycmd", "myarg"], stdout=PIPE).communicate()[0]
+   output = check_output(["mycmd", "myarg"])

can be changed.
Most of the other example access attributes of the Popen objects, such as stdin/stdout. subprocess.call is already used in a few places.

Another thing that I wanted to fix for a while is the syntax highlight in these examples.  Using '# becomes' instead of '==>' solves the problem for most of the examples, except for the first two that use `...`.  Using two separate blocks is another option.  A table with two columns (before/after) might also work, but it's difficult to get it wide enough to contain both the examples side by side.

About moving the convenience functions first, I'm not sure it works too well.
"This module defines one class called Popen:"
could be replaced by
"This module defines a class called Popen, and the convenience functions call(), check_call(), and check_output():"
where the three functions and possibly 'convenience functions' link to to the part of the page where they are defined.

----------
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Fri Oct 21 17:39:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 15:39:57 +0000
Subject: [issue13228] Add "Quick Start" section to the devguide index
In-Reply-To: <1319067423.48.0.288389971536.issue13228@psf.upfronthosting.co.za>
Message-ID: <1319211597.39.0.736570107019.issue13228@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> +   ``hg clone http://hg.python.org/cpython``;
> I use http://hg.python.org/cpython#default to avoid cloning the 2.x 
> branches, that?s an optimization that can save some time and space.

I think in the default case it's easier to get'em all.

> +2. run ``./configure --with-pydebug && make -j2``
> Is make -j2 harmless on single-CPU systems?  Doesn?t our make default 
> to -j0 anyway, to use all CPUs?

As far as I know, -j2 is harmless on single-CPU systems, but I don't think we use all the CPUs by default with a plain `make`.

> +3. :doc:`run the tests <runtests>` with ``./python -m test``;
> Is that cross-platform?  Mac OS X has python.exe for example.

These instructions are a bit UNIX/Linux-centric, because that's what most developers seems to use.  On Mac OS it would indeed be ./python.exe, but it shouldn't take long for the developers to figure that out or click on the link and see how it works for their OS.

If you think it's worth to expand a bit, I guess we could still do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13228>
_______________________________________

From report at bugs.python.org  Fri Oct 21 17:51:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 15:51:46 +0000
Subject: [issue13240] computed gotos not enabled?
In-Reply-To: <1319208086.31.0.00990210804778.issue13240@psf.upfronthosting.co.za>
Message-ID: <1319212064.3382.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> According to issue 9203 the computed gotos should be enabled by default since 3.2.
> However, it is not visible from the interpreter.
> 
> Python 3.2.2 (default, Sep  7 2011, 10:55:43) 
> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
> >>> from sysconfig import get_config_var
> >>> get_config_var('HAVE_COMPUTED_GOTOS')
> 1
> >>> get_config_var('USE_COMPUTED_GOTOS')
> 0

This looks like the system Python compiled by Apple. What about a
hand-compiled Python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Fri Oct 21 17:58:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 15:58:12 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1319212692.59.0.41860825704.issue12618@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sjoerd, can you paste the code that produces the bug?  It would help create a test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Fri Oct 21 17:58:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 15:58:58 +0000
Subject: [issue13240] computed gotos not enabled?
In-Reply-To: <1319208086.31.0.00990210804778.issue13240@psf.upfronthosting.co.za>
Message-ID: <1319212738.01.0.0720915270052.issue13240@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Just compiled 3.2 on Debian:

>>> sysconfig.get_config_var('USE_COMPUTED_GOTOS')
0

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Fri Oct 21 18:02:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 16:02:15 +0000
Subject: [issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
In-Reply-To: <1319208086.31.0.00990210804778.issue13240@psf.upfronthosting.co.za>
Message-ID: <1319212935.45.0.123246024235.issue13240@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This looks like the system Python compiled by Apple. What about a
> hand-compiled Python?

Forget this. I get the same results here.

However, if you add a "#error" at the right place in ceval.c, you'll see that computed gotos are enabled. It seems more of a sysconfig bug or limitation. In pyconfig.h, I have the following:

$ \grep GOTO pyconfig.h
#define HAVE_COMPUTED_GOTOS 1
/* #undef USE_COMPUTED_GOTOS */

Which apparently sysconfig translates as USE_COMPUTED_GOTOS being equal to 0, which I think is wrong.

----------
components: +Library (Lib) -Build
title: computed gotos not enabled? -> sysconfig gives misleading results for USE_COMPUTED_GOTOS
type: performance -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Fri Oct 21 18:16:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 16:16:02 +0000
Subject: [issue13228] Add "Quick Start" section to the devguide index
In-Reply-To: <1319067423.48.0.288389971536.issue13228@psf.upfronthosting.co.za>
Message-ID: <1319213762.96.0.512761629472.issue13228@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You could replace "python -m test" with "make test", although it only does the right thing in 3.3.
Otherwise, "python -m test -j3" would be friendlier to the reader I think :)

+1 on the principle, by the way!

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13228>
_______________________________________

From report at bugs.python.org  Fri Oct 21 18:22:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 16:22:25 +0000
Subject: [issue13228] Add "Quick Start" section to the devguide index
In-Reply-To: <1319067423.48.0.288389971536.issue13228@psf.upfronthosting.co.za>
Message-ID: <1319214145.17.0.0489756908708.issue13228@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

New patch that adds a few more instructions for Windows/Mac OS.  `make test` is UNIX-specific, so I left `./python -m test`.
I also moved the section before the quick links, since it seems to me more interesting that those links (you don't usually want to start from the PEPs or the buildbot page).

----------
Added file: http://bugs.python.org/file23487/issue13228.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13228>
_______________________________________

From report at bugs.python.org  Fri Oct 21 18:26:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 16:26:31 +0000
Subject: [issue13228] Add "Quick Start" section to the devguide index
In-Reply-To: <1319214145.17.0.0489756908708.issue13228@psf.upfronthosting.co.za>
Message-ID: <1319214150.3382.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> New patch that adds a few more instructions for Windows/Mac OS.  `make
> test` is UNIX-specific, so I left `./python -m test`.
> I also moved the section before the quick links, since it seems to me
> more interesting that those links (you don't usually want to start
> from the PEPs or the buildbot page).

You want at the minimum "python -m test -j3", I think (many tests don't
really use the CPU).
Your Windows instructions could be improved a bit:
- not "the project files from the PCbuild" directory, but
"PCbuild/pcbuild.sln" (there are many project files)
- not "python.exe", but "PCbuild\python_d.exe"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13228>
_______________________________________

From report at bugs.python.org  Fri Oct 21 18:28:25 2011
From: report at bugs.python.org (Mike Hoy)
Date: Fri, 21 Oct 2011 16:28:25 +0000
Subject: [issue13198] Remove duplicate definition of write_record_file
In-Reply-To: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za>
Message-ID: <1319214505.29.0.0380357563441.issue13198@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13198>
_______________________________________

From report at bugs.python.org  Fri Oct 21 18:54:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 16:54:25 +0000
Subject: [issue13228] Add "Quick Start" section to the devguide index
In-Reply-To: <1319067423.48.0.288389971536.issue13228@psf.upfronthosting.co.za>
Message-ID: <1319216065.93.0.611842817731.issue13228@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the feedback, here's an updated patch.

----------
nosy: +brian.curtin
Added file: http://bugs.python.org/file23488/issue13228-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13228>
_______________________________________

From report at bugs.python.org  Fri Oct 21 19:03:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Oct 2011 17:03:47 +0000
Subject: [issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
In-Reply-To: <1319208086.31.0.00990210804778.issue13240@psf.upfronthosting.co.za>
Message-ID: <1319216627.81.0.706045843467.issue13240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Extract of configure.in:
-------------------------------------
# Check for --with-computed-gotos
AC_MSG_CHECKING(for --with-computed-gotos)
AC_ARG_WITH(computed-gotos,
            AS_HELP_STRING([--with(out)-computed-gotos],
                           [Use computed gotos in evaluation loop (enabled by default on supported compilers)]),
[
if test "$withval" = yes
then 
  AC_DEFINE(USE_COMPUTED_GOTOS, 1,
  [Define if you want to use computed gotos in ceval.c.]) 
  AC_MSG_RESULT(yes)
fi
if test "$withval" = no
then 
  AC_DEFINE(USE_COMPUTED_GOTOS, 0,
  [Define if you want to use computed gotos in ceval.c.]) 
  AC_MSG_RESULT(no)
fi
],
[AC_MSG_RESULT(no value specified)])
-------------------------------------

Extract of my config.log:
-------------------------------------
configure:13788: checking whether gcc -pthread supports computed gotos
configure:13811: gcc -pthread -o conftest    conftest.c -lpthread -ldl  -lutil >&5
configure:13811: $? = 0
configure:13811: ./conftest
configure:13811: $? = 0
configure:13822: result: yes
configure:13832: checking for --with-computed-gotos
configure:13856: result: no value specified
-------------------------------------

Extract of my pyconfig.h
-------------------------------------
/* Define if you want to use computed gotos in ceval.c. */
/* #undef USE_COMPUTED_GOTOS */
-------------------------------------

Computed goto are disabled (in my Python 3.3 on Linux with GCC), I checked by adding #error to ceval.c.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Fri Oct 21 19:13:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 17:13:47 +0000
Subject: [issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
In-Reply-To: <1319216627.81.0.706045843467.issue13240@psf.upfronthosting.co.za>
Message-ID: <1319216984.3382.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Extract of my pyconfig.h
> -------------------------------------
> /* Define if you want to use computed gotos in ceval.c. */
> /* #undef USE_COMPUTED_GOTOS */
> -------------------------------------

Ok, now read ceval.c:

#ifdef HAVE_COMPUTED_GOTOS
    #ifndef USE_COMPUTED_GOTOS
    #define USE_COMPUTED_GOTOS 1
    #endif
#else
    #if defined(USE_COMPUTED_GOTOS) && USE_COMPUTED_GOTOS
    #error "Computed gotos are not supported on this compiler."
    #endif
    #undef USE_COMPUTED_GOTOS
    #define USE_COMPUTED_GOTOS 0
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Fri Oct 21 19:17:11 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 21 Oct 2011 17:17:11 +0000
Subject: [issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
In-Reply-To: <1319208086.31.0.00990210804778.issue13240@psf.upfronthosting.co.za>
Message-ID: <1319217431.05.0.353149642978.issue13240@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

With the #error, I can confirm that computed gotos are enabled on OS X.

About sysconfig, we may change the code to set None if the value is "undef". I don't know the impact.


--- a/Lib/sysconfig.py
+++ b/Lib/sysconfig.py
@@ -404,7 +404,7 @@
         else:
             m = undef_rx.match(line)
             if m:
-                vars[m.group(1)] = 0
+                vars[m.group(1)] = None
     return vars

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Fri Oct 21 19:19:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 17:19:14 +0000
Subject: [issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
In-Reply-To: <1319217431.05.0.353149642978.issue13240@psf.upfronthosting.co.za>
Message-ID: <1319217313.3382.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> With the #error, I can confirm that computed gotos are enabled on OS X.
> 
> About sysconfig, we may change the code to set None if the value is "undef". I don't know the impact.

Actually, I think sysconfig does the right thing when it comes to all
the configure-generated HAVE_XXX variables (due to the peculiar way the
configure/pyconfig.h couple works).

It's just that USE_COMPUTED_GOTOS is a ternary variable (0/1/undefined),
so maybe we should accept as a limitation that sysconfig returns a
misleading result here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Fri Oct 21 19:20:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Oct 2011 17:20:49 +0000
Subject: [issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
In-Reply-To: <1319208086.31.0.00990210804778.issue13240@psf.upfronthosting.co.za>
Message-ID: <1319217649.21.0.0643173807982.issue13240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Computed goto are disabled (in my Python 3.3 on Linux with GCC),
> I checked by adding #error to ceval.c.

Hum, I don't understand how, but I missed the #error failure. Computed goto *are enabled* by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Fri Oct 21 20:34:47 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Oct 2011 18:34:47 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319189305.06.0.387718012831.issue13239@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W5_ri-UBTDxvK+t8BN071oFTJJfJvvYi8ACo1ZtHW4M_g@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

Probably need a comment in the Grammar file so people know why an
unused operator is in there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Oct 21 20:35:49 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Oct 2011 18:35:49 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <1319222149.64.0.847135952688.issue13239@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Or perhaps we don't need joke backward compatibility? (That's nearly 3 years old.)

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Oct 21 20:42:32 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Fri, 21 Oct 2011 18:42:32 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1319222552.53.0.934672517772.issue12930@psf.upfronthosting.co.za>


Caio Rom?o <caioromao at gmail.com> added the comment:

It's been a while since this got any activity. Was the provided testfile not enough or any issue found? Just let me know and I'll make adjustments asap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12930>
_______________________________________

From report at bugs.python.org  Fri Oct 21 20:43:00 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Oct 2011 18:43:00 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319222149.64.0.847135952688.issue13239@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W58wX+MnJE19ji2ZVX0B+WYo9ezL7icFza_C_2MCCPQCw@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Fri, Oct 21, 2011 at 11:35, Benjamin Peterson <report at bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> Or perhaps we don't need joke backward compatibility? (That's nearly 3 years old.)

Then you tell the FLUFL that you want to take his precious operator away. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Oct 21 20:57:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Oct 2011 18:57:56 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <E1RHKHw-0001Id-GI@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a985d733b3a3 by Ezio Melotti in branch 'default':
#12753: Add support for Unicode name aliases and named sequences.
http://hg.python.org/cpython/rev/a985d733b3a3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:28:01 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 21 Oct 2011 19:28:01 +0000
Subject: [issue5788] datetime.timedelta is inconvenient to use...
In-Reply-To: <1240079860.62.0.329216013715.issue5788@psf.upfronthosting.co.za>
Message-ID: <1319225281.0.0.249219474154.issue5788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

What about

def total_minutes(td):
    return td / datetime.timedelta(minutes=1)

?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5788>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:30:20 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 21 Oct 2011 19:30:20 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319222149.64.0.847135952688.issue13239@psf.upfronthosting.co.za>
Message-ID: <20111021153010.63a4451d@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Oct 21, 2011, at 06:35 PM, Benjamin Peterson wrote:

>Benjamin Peterson <benjamin at python.org> added the comment:
>
>Or perhaps we don't need joke backward compatibility? (That's nearly 3 years
>old.)

OTOH, __future__ imports (even jokes) should never be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:33:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 19:33:04 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <1319225584.49.0.651128725242.issue13239@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> OTOH, __future__ imports (even jokes) should never be removed.

But their meaning can be altered?
(as part of another joke if you want :)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:35:11 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 21 Oct 2011 19:35:11 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319225584.49.0.651128725242.issue13239@psf.upfronthosting.co.za>
Message-ID: <20111021153503.7602a3a7@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Oct 21, 2011, at 07:33 PM, Antoine Pitrou wrote:

>Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> OTOH, __future__ imports (even jokes) should never be removed.
>
>But their meaning can be altered?
>(as part of another joke if you want :)

Well, you have 6 months to work that out then. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:46:58 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 21 Oct 2011 19:46:58 +0000
Subject: [issue10332] Multiprocessing maxtasksperchild results in hang
In-Reply-To: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>
Message-ID: <1319226418.07.0.887424823822.issue10332@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's an updated patch.
I'll open a separate issue for the thread-safety.

----------
keywords: +needs review
nosy: +pitrou
stage:  -> patch review
Added file: http://bugs.python.org/file23489/pool_lifetime_close-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10332>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:47:20 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 21 Oct 2011 19:47:20 +0000
Subject: [issue10332] Multiprocessing maxtasksperchild results in hang
In-Reply-To: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>
Message-ID: <1319226440.36.0.652394743771.issue10332@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file21644/pool_lifetime_close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10332>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:49:20 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Fri, 21 Oct 2011 19:49:20 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
Message-ID: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

Trying to build latest development revision:

localhost:repo family$ hg summary
parent: 73044:a985d733b3a3 tip
 #12753: Add support for Unicode name aliases and named sequences.
branch: default
commit: (clean)
update: (current)

Constantly getting this error:

./python.exe -SE -m sysconfig --generate-posix-vars
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Assertion failed: (compact->utf8_length == 0), function _PyUnicode_CheckConsistency, file Objects/unicodeobject.c, line 399.
make: *** [sysconfig] Abort trap

However, tag v3.2.2 seems to build successfully.

OS: Mac OS X 10.6.8
GCC: 4.2.1

If you have troubles reproducing this issue, feel free to ask any information I can provide that can help.

Thank you in advance!

----------
messages: 146120
nosy: Oleg.Plakhotnyuk
priority: normal
severity: normal
status: open
title: Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:52:37 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Fri, 21 Oct 2011 19:52:37 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319226757.26.0.380622933994.issue13241@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Oh yes.
I am building with this command line:
./configure --with-pydebug && make -j2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:53:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Oct 2011 19:53:20 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319226800.14.0.264732238507.issue13241@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It is a compiler bug in GCC 4.2.1 with -O3. Try to compile attached unicode.c program with gcc -O3. The correct result is:

$ gcc -O3 unicode.c -o unicode && ./unicode
is ascii? 0
is compact? 1
is compact ascii? 0
_PyUnicode_COMPACT_DATA: 88 vs 88
PyUnicode_DATA: 88 vs 88
explicit cast: 88 vs 88

With gcc 4.2.1 and -O3, you get "is compact ascii? 1".

----------
nosy: +haypo
Added file: http://bugs.python.org/file23490/unicode.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:53:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Oct 2011 19:53:31 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319226811.4.0.439796785706.issue13241@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Build
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:55:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Oct 2011 19:55:00 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319226900.4.0.957693973675.issue13241@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The bug has been fixed in GCC, try a more recent version using ./configure CC=gccX.Y.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:55:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 19:55:51 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319226951.62.0.388528579925.issue13241@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It should also work without --with-pydebug, or with a different compiler.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Fri Oct 21 21:56:46 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Oct 2011 19:56:46 +0000
Subject: [issue13228] Add "Quick Start" section to the devguide index
In-Reply-To: <1319067423.48.0.288389971536.issue13228@psf.upfronthosting.co.za>
Message-ID: <1319227006.77.0.824117254632.issue13228@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

"./python.exe" is not a given on Mac OS X; that's only true if the file system you are building in is case-insensitive, otherwise it is "./python".  Suggest rewording to:

   "(you may need to use :file:`./python.exe` on Mac OS X" ...

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13228>
_______________________________________

From report at bugs.python.org  Fri Oct 21 22:12:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 20:12:20 +0000
Subject: [issue1548891] shlex (or perhaps cStringIO) and unicode strings
Message-ID: <1319227940.1.0.847357528447.issue1548891@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Still happens on latest 2.7:

>>> from cStringIO import StringIO
>>> sio = StringIO(u"abc")
>>> sio.getvalue()
'a\x00b\x00c\x00'

----------
nosy: +pitrou
resolution: fixed -> 
stage:  -> needs patch
status: closed -> open
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1548891>
_______________________________________

From report at bugs.python.org  Fri Oct 21 22:15:13 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 21 Oct 2011 20:15:13 +0000
Subject: [issue13140] ThreadingMixIn.daemon_threads is not honored when parent
	is daemon
In-Reply-To: <1318191525.3.0.322601594247.issue13140@psf.upfronthosting.co.za>
Message-ID: <1319228113.01.0.876364876801.issue13140@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

"""
        """Start a new thread to process the request."""
        t = threading.Thread(target = self.process_request_thread,
                             args = (request, client_address))
        if self.daemon_threads:
            t.daemon = True
"""

If daemon_threads is false, t.daemon is not set, and the daemonic property is inherited from the creating thread, i.e. the server thread.
Patch attached (I don't think a test is necessary for such a trivial change).

----------
keywords: +needs review, patch
nosy: +haypo, neologix
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23491/socketserver_daemon.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13140>
_______________________________________

From report at bugs.python.org  Fri Oct 21 22:17:32 2011
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Fri, 21 Oct 2011 20:17:32 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1319228252.85.0.138225933418.issue3244@psf.upfronthosting.co.za>


Changes by Ugra D?niel <daniel.ugra at gmail.com>:


----------
nosy: +daniel.ugra

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Fri Oct 21 22:22:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 20:22:05 +0000
Subject: [issue1548891] shlex (or perhaps cStringIO) and unicode strings
Message-ID: <1319228525.72.0.020971197521.issue1548891@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

And unsurprisingly so, since the fix was reverted in r56830 by Georg.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1548891>
_______________________________________

From report at bugs.python.org  Fri Oct 21 22:22:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 20:22:14 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1319228534.28.0.993518473311.issue12753@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I committed the patch and the buildbots seem happy.  Thanks for the report and the feedback!

Tom, about the problems you mentioned in msg144836, can you report it in a new issue or, if there are already issues about them, add a message there?

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Fri Oct 21 22:26:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Oct 2011 20:26:10 +0000
Subject: [issue1730114] cStringIO no longer accepts array.array objects
Message-ID: <E1RHLfK-0000ed-4v@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c91661e0d714 by Antoine Pitrou in branch '2.7':
Add test for fix of issue #1730114.
http://hg.python.org/cpython/rev/c91661e0d714

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1730114>
_______________________________________

From report at bugs.python.org  Fri Oct 21 22:34:14 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Fri, 21 Oct 2011 20:34:14 +0000
Subject: [issue5788] datetime.timedelta is inconvenient to use...
In-Reply-To: <1240079860.62.0.329216013715.issue5788@psf.upfronthosting.co.za>
Message-ID: <1319229254.19.0.247929194254.issue5788@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

You'll probably get more traction if you file a new bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5788>
_______________________________________

From report at bugs.python.org  Fri Oct 21 22:35:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 20:35:28 +0000
Subject: [issue1548891] shlex (or perhaps cStringIO) and unicode strings
Message-ID: <1319229328.66.0.0715352380274.issue1548891@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Georg, is this patch ok to you?

----------
assignee: georg.brandl -> 
keywords: +patch
Added file: http://bugs.python.org/file23492/cio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1548891>
_______________________________________

From report at bugs.python.org  Fri Oct 21 22:57:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 20:57:30 +0000
Subject: [issue13242] Crash in test_pydoc
Message-ID: <1319230650.87.0.570503030256.issue13242@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

On 2.7, I get the following crashes in test_pydoc:

======================================================================
FAIL: test_apropos_with_bad_package (test.test_pydoc.PydocImportTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/27/Lib/test/test_pydoc.py", line 316, in test_apropos_with_bad_package
    result = run_pydoc('nothing', '-k', PYTHONPATH=TESTFN)
  File "/home/antoine/cpython/27/Lib/test/test_pydoc.py", line 185, in run_pydoc
    rc, out, err = assert_python_ok('-B', pydoc.__file__, *args, **env)
  File "/home/antoine/cpython/27/Lib/test/script_helper.py", line 49, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/home/antoine/cpython/27/Lib/test/script_helper.py", line 41, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is -6, stderr follows:
python: Objects/object.c:65: _Py_AddToAllObjects: Assertion `(op->_ob_prev == ((void *)0)) == (op->_ob_next == ((void *)0))' failed.

======================================================================
FAIL: test_apropos_with_unreadable_dir (test.test_pydoc.PydocImportTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/27/Lib/test/test_pydoc.py", line 326, in test_apropos_with_unreadable_dir
    result = run_pydoc('nothing', '-k', PYTHONPATH=TESTFN)
  File "/home/antoine/cpython/27/Lib/test/test_pydoc.py", line 185, in run_pydoc
    rc, out, err = assert_python_ok('-B', pydoc.__file__, *args, **env)
  File "/home/antoine/cpython/27/Lib/test/script_helper.py", line 49, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/home/antoine/cpython/27/Lib/test/script_helper.py", line 41, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is -6, stderr follows:
python: Objects/object.c:65: _Py_AddToAllObjects: Assertion `(op->_ob_prev == ((void *)0)) == (op->_ob_next == ((void *)0))' failed.


"hg bisect" tells me the first offending revision is 45862f4ab1c5, but that doesn't tell much, since it's just the revision which introduced the tests.

----------
components: Interpreter Core, Tests
messages: 146133
nosy: ned.deily, pitrou
priority: high
severity: normal
status: open
title: Crash in test_pydoc
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13242>
_______________________________________

From report at bugs.python.org  Fri Oct 21 23:02:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 21:02:57 +0000
Subject: [issue13242] Crash in test_pydoc
In-Reply-To: <1319230650.87.0.570503030256.issue13242@psf.upfronthosting.co.za>
Message-ID: <1319230977.59.0.0141780525319.issue13242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, it seems it's due to a 3rd party C extension:

$ ./python -c "import sqlalchemy.cprocessors"
python: Objects/object.c:65: _Py_AddToAllObjects: Assertion `(op->_ob_prev == ((void *)0)) == (op->_ob_next == ((void *)0))' failed.

Closing as not a Python bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13242>
_______________________________________

From report at bugs.python.org  Fri Oct 21 23:03:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 21:03:12 +0000
Subject: [issue13242] Crash in test_pydoc
In-Reply-To: <1319230650.87.0.570503030256.issue13242@psf.upfronthosting.co.za>
Message-ID: <1319230992.32.0.151399911573.issue13242@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13242>
_______________________________________

From report at bugs.python.org  Fri Oct 21 23:24:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Oct 2011 21:24:31 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <E1RHMZl-00053F-B9@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 329b96fe4472 by Ezio Melotti in branch 'default':
#12753: fix compilation on Windows.
http://hg.python.org/cpython/rev/329b96fe4472

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Fri Oct 21 23:33:22 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Oct 2011 21:33:22 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319232802.89.0.611180235034.issue13241@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I believe this was a bug specific to the llvm-gcc compiler shipped with Xcode 4.1 and possibly Xcode 4.0.  I do not have Xcode 4 on OS X 10.6 but haypo's test does fail with the llvm-gcc 4.2.1 that comes with Xcode 4.1 on 10.7.  Can you confirm exactly which compiler you are using, i.e. the complete --version output from the compiler used in your python build?  If you have not installed Xcode 4.2, one solution is to use CC=gcc-4.2 which uses the plain gcc-4.2, not llvm-gcc-4.2.  For 10.6, I recommend sticking with Xcode 3 if at all possible for the time being.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Fri Oct 21 23:35:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 21:35:20 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319232920.26.0.150330804393.issue13241@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also http://mail.python.org/pipermail/python-dev/2011-September/113731.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Fri Oct 21 23:38:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Oct 2011 21:38:52 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1319233132.53.0.190564413224.issue12296@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ezio's comment got me to reread the entire paragraph. I do not like it. 'Having you think' is wrong; 'Basically just' is unneeded; 'guaranteed' is hyperbole; and the paragraph is otherwise repetitive, vague, and pretty useless. For most issues "the core developer who eventually handles your patch will make the final call on whether something is acceptable" is not exactly true and misses the point that we have clearly defined policies that all core developers follow. Here is a suggested replacement that says what is actually acceptable for what versions.

"Second, follow our backwards-compatibility and upgrade policies. New parameters (whose default is the current behavior), functions, and methods may be accepted, but only for a future x.y version. New classes, modules, and syntax (including keywords) get increasingly severe scrutiny and require discussion on the python-dev list. Bug fixes that make behavior better match the documented intention are nearly always accepted for current releases. So are fixes for mistakes and sufficiently bad wording in the documents. Changes away from the current documented behavior are only occasionally accepted and only for future releases. Since they nearly always require at least a few people to update their code, they require special consideration, including a python-dev discussion, and a deprecation process."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Fri Oct 21 23:46:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 21:46:21 +0000
Subject: [issue415492] Compiler generates relative filenames
Message-ID: <1319233581.27.0.371886093372.issue415492@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue415492>
_______________________________________

From report at bugs.python.org  Fri Oct 21 23:47:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 21:47:03 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <1319233623.45.0.289824956615.issue13239@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Oct 21 23:47:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Oct 2011 21:47:05 +0000
Subject: [issue13184] Multi-layered symlinks to python cause runtime error.
	sys.path is malformed.
In-Reply-To: <1318655680.83.0.71543236392.issue13184@psf.upfronthosting.co.za>
Message-ID: <1319233625.85.0.482509835756.issue13184@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For the tracker, 'crash' == seqfault or equivalent, with no traceback.
Unwanted traceback is bad behavior.
Please test with 3.2 also if you can.

----------
nosy: +brett.cannon, ncoghlan, terry.reedy
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13184>
_______________________________________

From report at bugs.python.org  Fri Oct 21 23:50:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Oct 2011 21:50:36 +0000
Subject: [issue13197] subprocess: move shell arguments to a separate keyword
	param
In-Reply-To: <1318851671.68.0.276363356463.issue13197@psf.upfronthosting.co.za>
Message-ID: <1319233836.9.0.36754834155.issue13197@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
type:  -> feature request
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13197>
_______________________________________

From report at bugs.python.org  Fri Oct 21 23:54:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 21:54:58 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1319234098.35.0.7439841106.issue12296@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That's a bit heavy in my opinion.  I don't think it's necessary to define in detail what "backward-compatibile" means, it's probably enough to say that whatever code might be running before the patch should keep running fine even after.  Bug fixes can change the behavior -- but only if the current behavior is clearly wrong.

In addition you might want to define the meaning of "features", "bug fixes", and "security fixes", mention what releases accept what, say that doc fixes are usually fine in bug fix releases too, and possibly document the deprecation process.  But maybe this is getting out of the initial scope of the issue :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Sat Oct 22 00:00:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Oct 2011 22:00:37 +0000
Subject: [issue13220] print function unable while multiprocessing.Process is
	being run
In-Reply-To: <1319038082.58.0.169311394229.issue13220@psf.upfronthosting.co.za>
Message-ID: <1319234437.69.0.826128670725.issue13220@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Try running without IDLE (double click, right-click run, Command Prompt window, or paste into interpreter window). IDLE runs code in a subprocess with stdout directed back to the IDLE process, so it occasionally affects otherwise legal and correct Python code.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13220>
_______________________________________

From report at bugs.python.org  Sat Oct 22 00:05:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 22:05:32 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1319234732.93.0.643224912803.issue13212@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> HTMLParser got a strict argument and it's causing more problems than it solves.
Funny, I used the strict mode to solve a parsing bug in a personal project.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Sat Oct 22 00:05:52 2011
From: report at bugs.python.org (Justin Love)
Date: Fri, 21 Oct 2011 22:05:52 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1319234752.79.0.893936427025.issue11751@psf.upfronthosting.co.za>


Justin Love <python at JustinLove.name> added the comment:

Still can't reproduce (though I got one failure and three other errors)

$ patch -p 1 <distutils2-manifest.diff
$ ../devinabox/cpython/python.exe runtests.py
...
test_glob_to_re (distutils2.tests.test_manifest.ManifestTestCase) ... ok
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Sat Oct 22 00:07:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 22:07:18 +0000
Subject: [issue13203] Doc: say id() is only useful for existing objects
In-Reply-To: <1318873835.36.0.466865504792.issue13203@psf.upfronthosting.co.za>
Message-ID: <1319234838.13.0.657073611474.issue13203@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13203>
_______________________________________

From report at bugs.python.org  Sat Oct 22 00:09:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 22:09:45 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1319234985.81.0.408206069751.issue13212@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

>> HTMLParser got a strict argument and it's causing more problems than it solves.
> Funny, I used the strict mode to solve a parsing bug in a personal project.
See http://bugs.python.org/issue7311#msg133075 and following messages.r

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Sat Oct 22 00:16:34 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Oct 2011 22:16:34 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319235394.49.0.532176319048.issue13234@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Sat Oct 22 00:27:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 22:27:53 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1319236073.56.0.612268362141.issue9968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I read somewhere that the fact that TemporaryFile does not expose its name is a security feature :/

> On this topic, I was wondering if the changes I propose have any chance of 
> landing some day in 2.7 land - dunno Python workflow precisely enough.
Only bug fixes and doc fixes go into 2.7.  This report is about a new feature, which has to target 3.3.

----------
title: cgi.FieldStorage: Give control about the directory used for uploads -> Let cgi.FieldStorage have named uploaded file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Sat Oct 22 00:36:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Oct 2011 22:36:09 +0000
Subject: [issue13132] distutils sends non-RFC compliant HTTP request
In-Reply-To: <1318085788.89.0.459164084672.issue13132@psf.upfronthosting.co.za>
Message-ID: <1319236569.71.0.623174886187.issue13132@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Will close if no further input.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13132>
_______________________________________

From report at bugs.python.org  Sat Oct 22 00:56:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Oct 2011 22:56:57 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1319237817.61.0.0176403717546.issue13212@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Assigning back to me (the current maintainer of the module).

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Sat Oct 22 01:02:54 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Oct 2011 23:02:54 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319238174.2.0.638946122219.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Initially, because I was suggesting the names shadow the subprocess convenience functions so they *had* to live in a different namespace.

However, even after changing the names to explicitly include "shell", I'd like to keep them away from the general subprocess functionality - these wrappers are more convenient for shell operations than the subprocess ones, but it's that very convenience that makes them potentially dangerous in larger applications that may be interpolating data that untrusted users can manipulate.

Since the intended audience is system administrators working on shell-like operations, the shell utility module seems like an appropriate place for them. Both the "import shutil" and the "shell" in the names would then serve as red flags on a code review or security audit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sat Oct 22 01:07:29 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Oct 2011 23:07:29 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319238449.6.0.88225478088.issue13237@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

You couldn't just move them - you'd need to change the wording of how they cross-link to each other, since the explanations of the convenience function currently assume you understand how Popen works. I'd like us to get to the point where you only need to understand the whole Popen swiss army knife if you actually want that level of flexibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Sat Oct 22 01:13:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 23:13:23 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319238803.66.0.0206882441393.issue13238@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hum, in:

return_code = shellcmd.shell_call('ls -l {}', dirname)
listing = shellcmd.check_shell_output('ls -l {}', dirname)

...how do you know that dirname doesn't need some kind of escaping?
This is not only a security issue, but a bug. Even if security doesn't matter on your system, your script will still break and/or do unexpected things.

Also, I don't really understand how your recipe improves things. You're just saving one call to .format(). You would probably have the same saving by using the % operator.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sat Oct 22 01:18:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 23:18:58 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319239138.56.0.707807650379.issue13237@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Yep, what I was suggesting was an easier approach, but if someone is willing to reorganize the document, I agree that is better to start with an example that shows the most common use cases with the convenience functions and then gradually explain the convenience functions used in the example before moving to Popen and its intricacies.
The unittest doc for example follows the same approach, example first and then explanation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Sat Oct 22 01:47:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Oct 2011 23:47:28 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1319240848.76.0.0583913584531.issue13212@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Sat Oct 22 01:56:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Oct 2011 23:56:02 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1319241362.46.0.57512823919.issue13212@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> HTMLParser got a strict argument and it's causing more problems than it 
> solves.

Well, HTML is a big can of worms while JSON is a rather clean format. We can hope that adding a strict argument to json wouldn't cause such problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Sat Oct 22 02:02:56 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 22 Oct 2011 00:02:56 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319241776.11.0.985517266332.issue13234@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Sat Oct 22 02:03:07 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 22 Oct 2011 00:03:07 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319241787.42.0.550318540166.issue13234@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
components: +Windows
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Sat Oct 22 02:20:35 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 22 Oct 2011 00:20:35 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319242835.59.0.0284187860493.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's a flow thing. This idea was kicked off by the process of translating a large Perl script to Python and paying attention to what the translation made *worse*.

One of the big things it made worse was the translation of "qx" (quoted executable) strings. In Perl, those are almost as neat and tidy as if you were writing directly in the shell:

    qx|ls -l $dirname|

The thought process isn't "build this command and then execute it", it's "run this shell command".

Yes, you have to be careful that "dirname" is legal in the shell, but that usually isn't a big problem in practice, because dirname came from a previous listdir call, or you otherwise know that it's valid to interpolate it into the command (and if it isn't, then the bug lies in the way 'dirname' was populated, not in this operation).

Now, Python's never going to have implicit string interpolation, and that's fine - we have explicit interpolation instead. A direct translation of the above to idiomatic Python 2.7 code looks like the following:

    subprocess.check_output("ls -l {}".format(dirname), shell=True)

Now, if I'm doing system administration tasks (like the script I was translating), then I'm going to be doing that kind of thing a *lot*. I'm also likely to be a sysadmin rather than a programmer, so rather than going "Oh, I can write a helper function for this", my natural reaction is going to be "I'm going to use a language that doesn't get in my way so much".

This proposal is aimed directly at making Python a better language for systems administration by making shell invocation almost as easy as it is in Perl:

    shutil.check_shell_output("ls -l {}", dirname)

Heck, if someone really wanted to, they could even do:

    qx = shutil.check_shell_output
    qx("ls -l {}", dirname)

However, this is also why I *don't* want these methods in subprocess - they put the burden on the user to think about their data as if they were writing shell scripts, because that data is going to get passed straight to the shell for execution without any additional escaping. That's a reasonable idea for a shell utility in shutil, it's not reasonable for a general purpose subprocess manipulation utility in subprocess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sat Oct 22 02:41:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Oct 2011 00:41:41 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319242835.59.0.0284187860493.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319243833.3382.19.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, you have to be careful that "dirname" is legal in the shell, but
> that usually isn't a big problem in practice, because dirname came
> from a previous listdir call, or you otherwise know that it's valid to
> interpolate it into the command

I don't understand. os.listdir() doesn't escape filenames for you.

Having been bitten several times by almost-working shell commands which
would crash when one of the 10000 files being processed had a space in
it (ironically, I think that was in the Python source tree with some of
the old Mac directories), I think we really don't want to publish a
function which encourages people to pass unescaped arguments to the
shell.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sat Oct 22 03:10:22 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 22 Oct 2011 01:10:22 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319245822.94.0.219383408739.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

That's a fair point, but I think it actually *improves* the argument for better helper functions, since we can have them automatically invoke shlex.quote() on all of the arguments:

    def _shell_format(cmd, args, kwds):
        args = map(shlex.quote, args)
        kwds = {k:shlex.quote(v) for k, v in kwds}
        return cmd.format(*args, **kwds)

    def _invoke_shell(func, cmd, args, kwds):
        return func(_shell_format(cmd, args, kwds), shell=True)

    def format_shell_call(cmd, *args, kwds):
        return _shell_format(cmd, args, kwds)

    def shell_call(cmd, *args, **kwds):
        return _invoke_shell(subprocess.call, cmds, args, kwds)

    def check_shell_call(cmd, *args, **kwds):
        return _invoke_shell(subprocess.check_call, cmds, args, kwds)

    def check_shell_output(cmd, *args, **kwds):
        return _invoke_shell(subprocess.check_output, cmds, args, kwds)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sat Oct 22 03:23:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Oct 2011 01:23:19 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319245822.94.0.219383408739.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319246357.3382.20.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That's a fair point, but I think it actually *improves* the argument
> for better helper functions

Agreed :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sat Oct 22 04:35:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 22 Oct 2011 02:35:44 +0000
Subject: [issue13203] Doc: say id() is only useful for existing objects
In-Reply-To: <1318873835.36.0.466865504792.issue13203@psf.upfronthosting.co.za>
Message-ID: <1319250944.48.0.0309154995593.issue13203@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

A FAQ entry sounds good to me.

----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13203>
_______________________________________

From report at bugs.python.org  Sat Oct 22 05:36:08 2011
From: report at bugs.python.org (Jason Howlett)
Date: Sat, 22 Oct 2011 03:36:08 +0000
Subject: [issue13184] Multi-layered symlinks to python cause runtime error.
	sys.path is malformed.
In-Reply-To: <1318655680.83.0.71543236392.issue13184@psf.upfronthosting.co.za>
Message-ID: <1319254568.74.0.924214672021.issue13184@psf.upfronthosting.co.za>


Jason Howlett <jaguariv at gmail.com> added the comment:

Confirmed. The problem exists in 3.2.2 also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13184>
_______________________________________

From report at bugs.python.org  Sat Oct 22 08:38:20 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 22 Oct 2011 06:38:20 +0000
Subject: [issue13243] _Py_identifier should be _Py_IDENTIFER
Message-ID: <1319265500.1.0.820067486138.issue13243@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Looks like Parser/asdl_c.py did not get all the way updated when _Py_identifier switched over to _Py_IDENTIFER.  I've included a patch that fixes it (though it's relatively trivial).  With this fix I did not notice any further problems.

----------
components: Interpreter Core
files: asdl.diff
keywords: patch
messages: 146159
nosy: eric.snow, loewis
priority: normal
severity: normal
status: open
title: _Py_identifier should be _Py_IDENTIFER
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file23493/asdl.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13243>
_______________________________________

From report at bugs.python.org  Sat Oct 22 11:18:33 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 22 Oct 2011 09:18:33 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319275113.05.0.175878615547.issue13235@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Just to me it clear - why do you want warn() to be removed aside from code duplication?

My argument to leave it and document is that it is convenient and makes lines shorter (and won't break existing code). From logging module I also see that there are also logging.WARN aliases that you'll need to deprecate also.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Sat Oct 22 11:29:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 22 Oct 2011 09:29:30 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319275770.51.0.899332971161.issue13235@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Because there should be only one way to do things.

BTW, you could have used a DeprecationWarning instead of a PendingDeprecationWarning, especially if it was already deprecated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Sat Oct 22 12:17:31 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Oct 2011 10:17:31 +0000
Subject: [issue1548891] shlex (or perhaps cStringIO) and unicode strings
Message-ID: <1319278651.76.0.62074420276.issue1548891@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If you think it's fine to change this behavior, then yes :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1548891>
_______________________________________

From report at bugs.python.org  Sat Oct 22 12:23:02 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sat, 22 Oct 2011 10:23:02 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1319206471.34.0.725279255187.issue12659@psf.upfronthosting.co.za>
Message-ID: <4EA299CD.4030405@email.de>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Hi ?ric,
Nice! and thanks for the info: I was just waiting to the check-in to 
compare and try further with the tests. Now I can just commit another 
patch by synching against the actual tip.

Cheers,

francis

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Sat Oct 22 13:00:19 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 22 Oct 2011 11:00:19 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319275113.05.0.175878615547.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319281214.29104.YahooMailNeo@web25802.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Just to me it clear - why do you want warn() to be removed aside from code 

> duplication?
> 
> My argument to leave it and document is that it is convenient and makes lines 
> shorter (and won't break existing code). From logging module I also see that 
> there are also logging.WARN aliases that you'll need to deprecate also.

Sorry, I don't agree. I was happy to leave it as is until you raised this issue, but now I think the right thing to do is deprecate and remove warn(). I'm not too fussed about the WARN level, and I can't easily issue a deprecation warning for it as it's a module attribute, so I'll leave it in as an internal implementation detail, for which the usual caveats apply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Sat Oct 22 13:01:23 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 22 Oct 2011 11:01:23 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319275770.51.0.899332971161.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319281277.19997.YahooMailNeo@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> BTW, you could have used a DeprecationWarning instead of a 

> PendingDeprecationWarning, especially if it was already deprecated.

It wasn't officially deprecated, just "deprecation via obscurity";-) which is why I made it a PendingDeprecationWarning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Sat Oct 22 13:03:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 22 Oct 2011 11:03:18 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319281398.21.0.186084316846.issue13235@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

PendingDeprecations are not so useful now that warnings are silenced by default. Since it wasn't documented, you could deprecate it in 3.3 and remove it in 3.4 IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Sat Oct 22 13:07:43 2011
From: report at bugs.python.org (Tobias Oberstein)
Date: Sat, 22 Oct 2011 11:07:43 +0000
Subject: [issue13244] WebSocket schemes in urlparse
Message-ID: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>


New submission from Tobias Oberstein <tobias.oberstein at tavendo.de>:

The urlparse module currently does not support the new "ws" and "wss" schemes used for the WebSocket protocol.

As a workaround, we currently use the following code (which is a hack of course):

import urlparse
wsschemes = ["ws", "wss"]
urlparse.uses_relative.extend(wsschemes)
urlparse.uses_netloc.extend(wsschemes)
urlparse.uses_params.extend(wsschemes)
urlparse.uses_query.extend(wsschemes)
urlparse.uses_fragment.extend(wsschemes)

===

A WebSocket URL has scheme "ws" or "wss", MUST have a network location and MAY have a resource part with path and query components, but MUST NOT have a fragment component.

----------
components: Library (Lib)
messages: 146167
nosy: oberstet
priority: normal
severity: normal
status: open
title: WebSocket schemes in urlparse
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sat Oct 22 13:10:33 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 22 Oct 2011 11:10:33 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319281398.21.0.186084316846.issue13235@psf.upfronthosting.co.za>
Message-ID: <1319281827.53874.YahooMailNeo@web25802.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> PendingDeprecations are not so useful now that warnings are silenced by default. 

> Since it wasn't documented, you could deprecate it in 3.3 and remove it in 
> 3.4 IMHO.

Hmmm, you're probably right. I'll change it to a DeprecationWarning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Sat Oct 22 13:15:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 22 Oct 2011 11:15:46 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319282146.72.0.323787469833.issue13244@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti, orsenthil
stage:  -> test needed
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sat Oct 22 14:05:33 2011
From: report at bugs.python.org (Dima Tisnek)
Date: Sat, 22 Oct 2011 12:05:33 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1319285133.82.0.4578875475.issue12930@psf.upfronthosting.co.za>


Dima Tisnek <dimaqq at gmail.com> added the comment:

good enough for me :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12930>
_______________________________________

From report at bugs.python.org  Sat Oct 22 14:34:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 22 Oct 2011 12:34:59 +0000
Subject: [issue13235] logging.warn() is not documented
In-Reply-To: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za>
Message-ID: <E1RHams-00013c-3e@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4a90d1ed115d by Vinay Sajip in branch 'default':
Closes #13235: Changed PendingDeprecationWarning to DeprecationWarning.
http://hg.python.org/cpython/rev/4a90d1ed115d

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13235>
_______________________________________

From report at bugs.python.org  Sat Oct 22 15:39:25 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 22 Oct 2011 13:39:25 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1319290765.44.0.820087974454.issue12406@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Adding Antoine for the short-name conflicts caused by the *.passwd.pem files.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Sat Oct 22 17:38:37 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 Oct 2011 15:38:37 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1319297917.24.0.20331859969.issue13201@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've taken the liberty of updating the patch, with a few minor changes:

range_equality -> range_equals (like range_contains)
move identity check into range_equals
move comments before the code they describe (PEP7)
add whatsnew entry
remove check that range.__hash__ matches object.__hash__ in test_hash
change assertEqual into assertIs where appropriate (as suggested by Ezio)
additional comments and tests in Lib/test/test_range (ditto)

Sven, Ezio:  okay to apply this?

----------
Added file: http://bugs.python.org/file23494/range-compare-v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Sat Oct 22 17:40:19 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 Oct 2011 15:40:19 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1319298019.96.0.24971678228.issue13201@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  Why does my patch not get a 'review' button?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Sat Oct 22 17:40:46 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 Oct 2011 15:40:46 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1319298046.49.0.710064697647.issue13201@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, there it is. Never mind. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Sat Oct 22 19:29:14 2011
From: report at bugs.python.org (Yevgen Yampolskiy)
Date: Sat, 22 Oct 2011 17:29:14 +0000
Subject: [issue10131] deepcopying an xml.dom.minidom.Document generates an
	invalid XML document
In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za>
Message-ID: <1319304554.62.0.143866395789.issue10131@psf.upfronthosting.co.za>


Yevgen Yampolskiy <genij.math at gmail.com> added the comment:

You can create object copy using both copy and pickle modules. 
I assume that identical results should be produced.

pickle handles minidom.Document correctly, however copy does not. 
Even if patch to NodeList will be applied, copy or pickle modules need to be adjusted to produce identical results.

>From this view point copy module needs to be adjusted.

Here is the test code:

import copy, pickle
from xml.dom.minidom import NodeList

obj = NodeList()
obj.append('a')

obj2 = copy.deepcopy(obj)
print(obj2)

obj2 = pickle.loads(pickle.dumps(obj))
print(obj2)

Output (python 2.7-3.2):
['a', 'a']
['a']

----------
nosy: +genij.math

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10131>
_______________________________________

From report at bugs.python.org  Sat Oct 22 20:08:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Oct 2011 18:08:04 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <1319306884.32.0.582077358002.issue12406@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can't you use the normal algorithm for short names? I.e. KEYCER~1.PEM etc. Or doesn't it exist anymore?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12406>
_______________________________________

From report at bugs.python.org  Sat Oct 22 20:55:07 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 Oct 2011 18:55:07 +0000
Subject: [issue10925] Document pure Python version of integer-to-float
	correctly-rounded conversion
In-Reply-To: <1295269244.12.0.126728941356.issue10925@psf.upfronthosting.co.za>
Message-ID: <1319309707.82.0.511308478649.issue10925@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the comments.  Here's an updated patch, that actually makes use of the pure Python version to test the built-in int-to-float conversion.

----------
versions:  -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23495/pure_python_long_to_float_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10925>
_______________________________________

From report at bugs.python.org  Sat Oct 22 20:58:53 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 22 Oct 2011 18:58:53 +0000
Subject: [issue13243] _Py_identifier should be _Py_IDENTIFER
In-Reply-To: <1319265500.1.0.820067486138.issue13243@psf.upfronthosting.co.za>
Message-ID: <1319309933.72.0.0368107238724.issue13243@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Good catch.  I see what happened.  7109f31300fb updated
Python/Python-ast.c but not Parser/asdl_c.py.  I will apply your patch 
shortly.  Thanks.

----------
assignee:  -> meador.inge
nosy: +meador.inge
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13243>
_______________________________________

From report at bugs.python.org  Sat Oct 22 21:03:25 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 22 Oct 2011 19:03:25 +0000
Subject: [issue13243] _Py_identifier should be _Py_IDENTIFER
In-Reply-To: <1319265500.1.0.820067486138.issue13243@psf.upfronthosting.co.za>
Message-ID: <1319310205.15.0.503943075259.issue13243@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Oh, and just to be clear I reproduced the build break by doing:

./Parser/asdl_c.py -c ./Python ./Parser/Python.asdl
make

in a built tree.  The reason that this wasn't caught is that the make
rules have the ASDL files as dependencies on the AST C files.  So, the
C files are *not* updated unless the ASDL files are.

Maybe we should change the build system to always regenerate the files
or add something to automation that regenerates the AST C file every
time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13243>
_______________________________________

From report at bugs.python.org  Sat Oct 22 21:05:55 2011
From: report at bugs.python.org (Chris Clark)
Date: Sat, 22 Oct 2011 19:05:55 +0000
Subject: [issue13245] sched.py kwargs addition and default time functions
Message-ID: <1319310354.56.0.392534213439.issue13245@psf.upfronthosting.co.za>


New submission from Chris Clark <clach04 at gmail.com>:

I ended up implementing my own sched.py equivalent as I needed kwargs support. This is my attempt to improve the stdlib, so I can throw my module way ;-)

Added kwargs support, and made "argument" optional. "argument" is still named argument, I would like to rename this args but I'm unclear on the backwards compat rules for stdlib, in theory it should be fine unless someone has code that treats argument as a keyword arg).

The scheduler init no long requires timer functions to be provided, it defaults to time.time, time.sleep as a helper to reduce repeated code for callers. This still allows callers to provide custom timer routines.

I added a few (non exhaustive) tests for the new additions.

It looks like there are a few pep8 improvements could be made to sched.py but I've not done that to reduce diffs and make it easier to see what I changed. Similar doc strings could be made more clear.

I snuck in a hack to the test so that the full test suite isn't needed, I do not expect that to be accepted :-) I don't have enough network bandwidth to pull the whole hg repo so I ended up pulling the tip version for 2.7 of sched and its test (as of 2011-10-22 this is 5110d723fbb1)

----------
components: Library (Lib)
files: kwargs_def_timer.patch
keywords: patch
messages: 146180
nosy: clach04
priority: normal
severity: normal
status: open
title: sched.py kwargs addition and default time functions
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file23496/kwargs_def_timer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13245>
_______________________________________

From report at bugs.python.org  Sat Oct 22 21:08:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 22 Oct 2011 19:08:45 +0000
Subject: [issue13245] sched.py kwargs addition and default time functions
In-Reply-To: <1319310354.56.0.392534213439.issue13245@psf.upfronthosting.co.za>
Message-ID: <1319310525.16.0.932375739659.issue13245@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Hi, thanks for the patch!
2.7 receives only bug fixes, so your patch can't be applied to 2.7.
If the feature is accepted it can go to 3.3 though.

----------
nosy: +ezio.melotti
stage:  -> patch review
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13245>
_______________________________________

From report at bugs.python.org  Sat Oct 22 21:12:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 22 Oct 2011 19:12:35 +0000
Subject: [issue13243] _Py_identifier should be _Py_IDENTIFER
In-Reply-To: <1319265500.1.0.820067486138.issue13243@psf.upfronthosting.co.za>
Message-ID: <E1RHgzZ-0001i5-VK@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 941d015053c6 by Meador Inge in branch 'default':
Issue 13243: Rename _Py_identifier to _Py_IDENTIFIER in asdl_c.py
http://hg.python.org/cpython/rev/941d015053c6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13243>
_______________________________________

From report at bugs.python.org  Sat Oct 22 21:14:28 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 22 Oct 2011 19:14:28 +0000
Subject: [issue13243] _Py_identifier should be _Py_IDENTIFER
In-Reply-To: <1319265500.1.0.820067486138.issue13243@psf.upfronthosting.co.za>
Message-ID: <1319310868.64.0.507946864365.issue13243@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Committed.  Thanks!

----------
nosy:  -python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13243>
_______________________________________

From report at bugs.python.org  Sat Oct 22 21:15:57 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 22 Oct 2011 19:15:57 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1319310957.11.0.648763735876.issue12675@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12675>
_______________________________________

From report at bugs.python.org  Sat Oct 22 21:31:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 22 Oct 2011 19:31:23 +0000
Subject: [issue1548891] shlex (or perhaps cStringIO) and unicode strings
Message-ID: <E1RHhHq-00032t-Do@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 27ae7d4e1983 by Antoine Pitrou in branch '2.7':
Issue #1548891: The cStringIO.StringIO() constructor now encodes unicode
http://hg.python.org/cpython/rev/27ae7d4e1983

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1548891>
_______________________________________

From report at bugs.python.org  Sat Oct 22 21:32:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Oct 2011 19:32:34 +0000
Subject: [issue1548891] shlex (or perhaps cStringIO) and unicode strings
Message-ID: <1319311954.4.0.844717232256.issue1548891@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If you think it's fine to change this behavior, then yes :)

Well, the "documented" behaviour makes no sense.
Either it should raise TypeError or convert. Since write() converts, it's logical for the constructor to do so as well.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1548891>
_______________________________________

From report at bugs.python.org  Sat Oct 22 21:45:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Oct 2011 19:45:03 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319312703.35.0.8721824373.issue13218@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Barry, perhaps you could try to know what in Ubuntu's OpenSSL build can lead to such failures?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Sat Oct 22 21:52:56 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 22 Oct 2011 19:52:56 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1319313176.36.0.573153527032.issue12675@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12675>
_______________________________________

From report at bugs.python.org  Sat Oct 22 22:13:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Oct 2011 20:13:50 +0000
Subject: [issue13246] Py_UCS4_strlen and friends needn't be public
Message-ID: <1319314430.74.0.993573606288.issue13246@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It seems there's no reason to document these functions which operate on null-terminated unicode arrays.

----------
assignee: docs at python
components: Documentation
messages: 146187
nosy: docs at python, ezio.melotti, georg.brandl, haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: Py_UCS4_strlen and friends needn't be public
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13246>
_______________________________________

From report at bugs.python.org  Sat Oct 22 22:32:33 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 22 Oct 2011 20:32:33 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319315553.68.0.644767093477.issue13244@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

I added a patch that adds support for WebSocket URL protocol.

However, a few pointers (and questions):

- The patch is now implemented according to Draft 17[1] of WebSocket protocol

- Draft 17 does not support fragments, it states that the fragments should be treated as a part of the URL, so I didn't add the ws and wss support in uses_fragments. However, the Draft 17 states also, that those should always be encoded. Should there be a special case for ws/wss URLs that have non-encoded number-signs in them, for example should we raise some sort of an exception?

[1] http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17

----------
keywords: +patch
nosy: +nailor
Added file: http://bugs.python.org/file23497/issue13244.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sat Oct 22 22:47:34 2011
From: report at bugs.python.org (Tobias Oberstein)
Date: Sat, 22 Oct 2011 20:47:34 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319316454.48.0.762240675949.issue13244@psf.upfronthosting.co.za>


Tobias Oberstein <tobias.oberstein at tavendo.de> added the comment:

fragment identifiers:

the spec says:

"Fragment identifiers are meaningless in the context of WebSocket
URIs, and MUST NOT be used on these URIs.  The character "#" in URIs
MUST be escaped as %23 if used as part of the query component."

[see last line of my initial comment]

I nevertheless added the ws/wss schemes to urlparse.uses_fragment so that I can detect them being used and throw.

Does urllib throw when an URL contains a fragment identifier, but the scheme of the URL is not in urlparse.uses_fragment?

If so, thats fine and of course better than putting the burden of checking on the user.

==

Further, when "#" is to be used in a WS URL, it MUST be encoded, and if so, it's interpreted as part of the query component.

So in summary, I think the best would be:

urllib throws upon non-encoded "#", and interpret it as part of the query component when encoded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sat Oct 22 22:54:35 2011
From: report at bugs.python.org (Tobias Oberstein)
Date: Sat, 22 Oct 2011 20:54:35 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319316875.96.0.747816269539.issue13244@psf.upfronthosting.co.za>


Tobias Oberstein <tobias.oberstein at tavendo.de> added the comment:

Well, thinking about it, %23 can also appear in a percent encoded path component.

I don't get the conditional "..if used as part of the query component" in the spec.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sat Oct 22 22:55:14 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Oct 2011 20:55:14 +0000
Subject: [issue13246] Py_UCS4_strlen and friends needn't be public
In-Reply-To: <1319314430.74.0.993573606288.issue13246@psf.upfronthosting.co.za>
Message-ID: <1319316914.09.0.192431592943.issue13246@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If they aren't public, they should get an underscore.

All our API functions are either public or private; all public ones should be documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13246>
_______________________________________

From report at bugs.python.org  Sat Oct 22 23:03:53 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 22 Oct 2011 21:03:53 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319317433.89.0.729245716793.issue13244@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

Actually, if I get it right, it means that following url is valid:

  ws://example.com/something#somewhere/

and the # should be considered as being a part of the path. The spec does not say a thing should the # in path component be encoded, so I think it's safe to assume it should can be unencoded. However, following url

  ws://example.com/something?query=foo#bar

Is not considered to be valid, as the # is in the query part and is not escaped. So the valid would be:

  ws://example.com/something?query=foo%23bar

I think the motivation behind this is to reduce possible conflicts with browsers that might take the #-part as a fragment when it should be part of the query parameters. However, the confusion is still possible with # in path part.

My take on this would be to omit fragments and just parse the url as is without fragments. Encoding could be left to user, even in the case # is in query part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sat Oct 22 23:18:33 2011
From: report at bugs.python.org (Tobias Oberstein)
Date: Sat, 22 Oct 2011 21:18:33 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319318313.14.0.68314351713.issue13244@psf.upfronthosting.co.za>


Tobias Oberstein <tobias.oberstein at tavendo.de> added the comment:

I see how you interpret that sentence in the spec, but I would have read it differently:

invalid:

1. ws://example.com/something#somewhere
2. ws://example.com/something#somewhere/
3. ws://example.com/something#somewhere/foo
4. ws://example.com/something?query=foo#bar

valid:

5. ws://example.com/something%23somewhere
6. ws://example.com/something%23somewhere/
7. ws://example.com/something%23somewhere/foo
8. ws://example.com/something?query=foo%23bar

You would take 2. and 3. as valid, but 1. and 4. as invalid, right?
 
But you are right, the spec does not talk about # in path.

If above is a valid summary of the question, I'd better take that to the Hybi list to get feedback before rushing into anything with urllib ..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sat Oct 22 23:25:31 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 22 Oct 2011 21:25:31 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319318731.62.0.867411690813.issue13244@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

I'd take only 4. as invalid, as the WebSocket (to my interpretation) do not have fragments, so it is assumed to be a part of the path in that case.

But yeah, a confirmation from HyBi would be great. Can you link to the discussion from here, if you ask them (in case it's possible)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sat Oct 22 23:30:25 2011
From: report at bugs.python.org (Tobias Oberstein)
Date: Sat, 22 Oct 2011 21:30:25 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319319025.96.0.259009497533.issue13244@psf.upfronthosting.co.za>


Tobias Oberstein <tobias.oberstein at tavendo.de> added the comment:

I'll ask (to be sure) and link.

However, after rereading the Hybi 17 section, it says

"""
path = <path-abempty, defined in [RFC3986], Section 3.3>
"""

And http://tools.ietf.org/html/rfc3986 says:

"""
The path is terminated by the first question mark ("?") or number sign ("#") character, or by the end of the URI.
"""

So my reading would be: non-escaped # can never be part of path for a WebSocket URL by reference of RFC3986.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sun Oct 23 00:23:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Oct 2011 22:23:33 +0000
Subject: [issue11183] Finer-grained exceptions for the ssl module
In-Reply-To: <1297418910.83.0.110389671752.issue11183@psf.upfronthosting.co.za>
Message-ID: <1319322213.58.0.0733215580724.issue11183@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. It adds SSLZeroReturnError, SSLWantReadError, SSLWantWriteError, SSLSyscallError and SSLEOFError.

----------
keywords: +patch
Added file: http://bugs.python.org/file23498/sslerrors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11183>
_______________________________________

From report at bugs.python.org  Sun Oct 23 00:23:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Oct 2011 22:23:38 +0000
Subject: [issue11183] Finer-grained exceptions for the ssl module
In-Reply-To: <1297418910.83.0.110389671752.issue11183@psf.upfronthosting.co.za>
Message-ID: <1319322218.78.0.133506353452.issue11183@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11183>
_______________________________________

From report at bugs.python.org  Sun Oct 23 00:34:28 2011
From: report at bugs.python.org (Tobias Oberstein)
Date: Sat, 22 Oct 2011 22:34:28 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319322868.07.0.518376693986.issue13244@psf.upfronthosting.co.za>


Tobias Oberstein <tobias.oberstein at tavendo.de> added the comment:

here the links to the question on the Hybi list:

http://www.ietf.org/mail-archive/web/hybi/current/msg09257.html

and

http://www.ietf.org/mail-archive/web/hybi/current/msg09258.html
http://www.ietf.org/mail-archive/web/hybi/current/msg09243.html

==

I'll track those and come back when there is a conclusion ..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sun Oct 23 00:51:36 2011
From: report at bugs.python.org (Sven Marnach)
Date: Sat, 22 Oct 2011 22:51:36 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1319323896.93.0.854767652504.issue13201@psf.upfronthosting.co.za>


Sven Marnach <sven at marnach.net> added the comment:

Thanks for the updates, Mark.  I was just about to look into this again.  The changes are fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Sun Oct 23 00:54:42 2011
From: report at bugs.python.org (Sven Marnach)
Date: Sat, 22 Oct 2011 22:54:42 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1319324082.07.0.833030640608.issue13201@psf.upfronthosting.co.za>


Sven Marnach <sven at marnach.net> added the comment:

Victor Stinner wrote:
> If would be nice to have a PyLong_CompareLong() function.

In most cases, global variables Py_Zero and Py_One would be enough to simplify this kind of code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Sun Oct 23 01:12:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Oct 2011 23:12:12 +0000
Subject: [issue6988] shlex.split() converts unicode input to UCS-4 output
In-Reply-To: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>
Message-ID: <1319325132.38.0.756050185293.issue6988@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

$ ./python 
Python 2.7.2+ (2.7:27ae7d4e1983+, Oct 23 2011, 00:09:06) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> shlex.split(u'Hello, World!')
['Hello,', 'World!']

This was fixed indirectly by a StringIO fix in 27ae7d4e1983, for #1548891.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6988>
_______________________________________

From report at bugs.python.org  Sun Oct 23 01:14:30 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 22 Oct 2011 23:14:30 +0000
Subject: [issue13140] ThreadingMixIn.daemon_threads is not honored when parent
	is daemon
In-Reply-To: <1318191525.3.0.322601594247.issue13140@psf.upfronthosting.co.za>
Message-ID: <1319325270.49.0.594851522806.issue13140@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I would prefer to preserve the inheritance by default, and to change the daemonic attribute only if it is explicitly set to True or False.
This way it will be backward compatible.

Patch attached.

----------
versions:  -Python 2.6
Added file: http://bugs.python.org/file23499/issue13140.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13140>
_______________________________________

From report at bugs.python.org  Sun Oct 23 01:22:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Oct 2011 23:22:24 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319325744.5.0.533186605654.issue13244@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Actually, if I get it right, it means that following url is valid:
>  ws://example.com/something#somewhere/
I don?t think so.  The URI syntax RFC is generic, so a scheme spec cannot redefine the parsing to mean that in your above example, there is no fragment and the path is /something#somewhere/ .  I believe the spec means that a # in any component must be %-escaped.

> Does urllib throw when an URL contains a fragment identifier, but the scheme of the URL is not
> in urlparse.uses_fragment?
Could you try it in a shell and tell us?  BTW, please don?t use ?throw? in a code or doc patch: exceptions are raised, throw is related but different generator method.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sun Oct 23 01:44:21 2011
From: report at bugs.python.org (Tobias Oberstein)
Date: Sat, 22 Oct 2011 23:44:21 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319327061.71.0.159869251415.issue13244@psf.upfronthosting.co.za>


Tobias Oberstein <tobias.oberstein at tavendo.de> added the comment:

sorry for "throw" .. somewhat bad habit (stemming from wandering between languages).

uses_fragment extended:

[autobahn at autobahnhub ~/Autobahn]$ python
Python 2.7.1 (r271:86832, Dec 13 2010, 15:52:15)
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> import urlparse
>>> wsschemes = ["ws", "wss"]
>>> urlparse.uses_relative.extend(wsschemes)
>>> urlparse.uses_netloc.extend(wsschemes)
>>> urlparse.uses_params.extend(wsschemes)
>>> urlparse.uses_query.extend(wsschemes)
>>> urlparse.uses_fragment.extend(wsschemes)
>>> urlparse.urlparse("ws://example.com/something#somewhere/")
ParseResult(scheme='ws', netloc='example.com', path='/something', params='', query='', fragment='somewhere/')
>>> urlparse.urlparse("ws://example.com/something#somewhere")
ParseResult(scheme='ws', netloc='example.com', path='/something', params='', query='', fragment='somewhere')
>>>

=> fragment extracted


uses_fragment not extended:

[autobahn at autobahnhub ~/Autobahn]$ python
Python 2.7.1 (r271:86832, Dec 13 2010, 15:52:15)
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> import urlparse
>>> wsschemes = ["ws", "wss"]
>>> urlparse.uses_relative.extend(wsschemes)
>>> urlparse.uses_netloc.extend(wsschemes)
>>> urlparse.uses_params.extend(wsschemes)
>>> urlparse.uses_query.extend(wsschemes)
>>> urlparse.urlparse("ws://example.com/something#somewhere/")
ParseResult(scheme='ws', netloc='example.com', path='/something#somewhere/', params='', query='', fragment='')
>>> urlparse.urlparse("ws://example.com/something#somewhere")
ParseResult(scheme='ws', netloc='example.com', path='/something#somewhere', params='', query='', fragment='')
>>>

=> no fragment extracted, but interpreted as part of path component
=> no exception raised

The answer on Hybi outstanding, but I would interpret Hybi-17: # must always be escaped, both in path and query components. Fragment components are not allowed. Thus, unescaped # can never appear in WS URL. Further, it must not be ignored, but the WS handshake failed.

If this should indeed be the correct reading of the WS spec, then I think urlparse should raise an exception upon unescaped # within URLs from ws/wss schemes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sun Oct 23 01:45:24 2011
From: report at bugs.python.org (Yuval Greenfield)
Date: Sat, 22 Oct 2011 23:45:24 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
Message-ID: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>


New submission from Yuval Greenfield <ubershmekel at gmail.com>:

For Python 2:

    Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32
    >>> os.path.abspath('.')
    'C:\\Users\\yuv\\Desktop\\YuvDesktop\\??????'
    >>> os.path.abspath(u'.')
    u'C:\\Users\\yuv\\Desktop\\YuvDesktop\\\u05d0\u05d1\u05d2\u05d3\u05d4\u05d5'

For Python 3:
    Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
    >>> os.path.abspath('.')
    'C:\\Users\\yuv\\Desktop\\YuvDesktop\\\u05d0\u05d1\u05d2\u05d3\u05d4\u05d5'
    >>> os.path.abspath(b'.')
    b'C:\\Users\\yuv\\Desktop\\YuvDesktop\\??????'


The returned path with question marks is completely useless. It's better that python throw an error than return the question marks. Another option is to try and get the ascii version of the path, I believe windows has one.

----------
components: Library (Lib)
messages: 146204
nosy: ubershmekel
priority: normal
severity: normal
status: open
title: os.path.abspath returns unicode paths as question marks
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Sun Oct 23 01:45:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Oct 2011 23:45:49 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319327149.64.0.0732650070786.issue13244@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>>> urlparse.urlparse("ws://example.com/something#somewhere")
ParseResult(scheme='ws', netloc='example.com', path='/something#somewhere', params='', query='', fragment='')

This makes me sad.  I thought we had fixed urllib months ago to follow the damn rules that have been in a bunch of RFCs for years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Sun Oct 23 01:47:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Oct 2011 23:47:02 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319327222.79.0.860159705743.issue13247@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +haypo
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Sun Oct 23 02:29:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 00:29:38 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1319329778.84.0.289300128807.issue6210@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I like the class method idea, but not the no_context name.  Would without_context be too long?

I don?t dislike raise MyError from None, but a method will be more easy to search and will help people reading code and discovering this unknown idiom.  I think it?s also easier to implement than a syntax change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Sun Oct 23 02:31:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 00:31:51 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1319329911.28.0.50478721182.issue11751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Still can't reproduce
It only shows in 2.4 and 2.5.

> (though I got one failure and three other errors)
If these are not covered in #13170, please add them to that report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Sun Oct 23 02:53:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 00:53:41 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1319331221.41.0.468664179197.issue11751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve found the reason: #6665.  fnmatch.translate (used by _glob_to_re was changed to support filenames with embedded newlines.  I don?t think it?s a concern for us: As the input we give to _glob_to_re comes one line at a time from a file, we just never have filenames with newlines.

We can do one of these things for d2:
- Special-case 2.4 and 2.5 in the tests.
- Tweak _glob_to_re so that it changes the generated regex to match what we get in newer versions.
- Tweak _glob_to_re to remove the inline flags, as we don?t need them.

I think the last idea would be best.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Sun Oct 23 02:56:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 00:56:34 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1319331394.97.0.390739074656.issue12930@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I want to look at this but lack time right now.  Could someone make one up-to-date patch with all changes, code and tests?  It will be much easier to review and test than an archive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12930>
_______________________________________

From report at bugs.python.org  Sun Oct 23 03:01:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 01:01:50 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319331710.66.0.951319200735.issue13238@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> [snip rationale about why shutil and not subprocess]
I?m convinced (with one nit: sh in the shutil name does not ring a security alarm for me, as I understand it as ?shell-like conveniences in nice, dont-do-nasty-things-with-stings Python? :) but the shell in check_shell_call does warn).

Automatic call of shlex.quote is an argument in favor of the new helpers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sun Oct 23 03:02:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 01:02:40 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319331760.31.0.342823019253.issue13238@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

s/stings/strings/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sun Oct 23 03:09:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 01:09:49 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1319332189.79.0.755080613552.issue12930@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Forget that, there are no automated tests for tools.  So, a text version of the files would be nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12930>
_______________________________________

From report at bugs.python.org  Sun Oct 23 03:26:11 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Sun, 23 Oct 2011 01:26:11 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1319333171.72.0.334439272363.issue12930@psf.upfronthosting.co.za>


Caio Rom?o <caioromao at gmail.com> added the comment:

Attaching files from tarball as requested. See http://bugs.python.org/issue12930#msg144314 for explanation

----------
Added file: http://bugs.python.org/file23500/testfile-original.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12930>
_______________________________________

From report at bugs.python.org  Sun Oct 23 03:26:25 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Sun, 23 Oct 2011 01:26:25 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1319333185.7.0.108778743063.issue12930@psf.upfronthosting.co.za>


Changes by Caio Rom?o <caioromao at gmail.com>:


Added file: http://bugs.python.org/file23501/testfile-expected.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12930>
_______________________________________

From report at bugs.python.org  Sun Oct 23 03:26:38 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Sun, 23 Oct 2011 01:26:38 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1319333198.14.0.188747005051.issue12930@psf.upfronthosting.co.za>


Changes by Caio Rom?o <caioromao at gmail.com>:


Added file: http://bugs.python.org/file23502/testfile-issue.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12930>
_______________________________________

From report at bugs.python.org  Sun Oct 23 04:08:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 02:08:04 +0000
Subject: [issue13132] distutils sends non-RFC compliant HTTP request
In-Reply-To: <1318085788.89.0.459164084672.issue13132@psf.upfronthosting.co.za>
Message-ID: <1319335684.22.0.451053057914.issue13132@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The requests we send are multipart/form-data, so the RFC exception for text/* would not apply.  I?m closing this bug as a duplicate and will ask on the other one if we should reopen it.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: pending -> closed
superseder:  -> packaging upload/register should use CRLF in HTTP requests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13132>
_______________________________________

From report at bugs.python.org  Sun Oct 23 04:13:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 02:13:09 +0000
Subject: [issue10510] packaging upload/register should use CRLF in HTTP
	requests
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1319335989.56.0.115309792266.issue10510@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Mitchell Hashimoto provided this link on a duplicate report:

> RFC2616 page 31 (http://tools.ietf.org/html/rfc2616#page-31) states that headers must be separated
> by CRLF. Specifically, the above "\n\n" for the header separator is causing issues with some
> minimal RFC-compliant web servers.

So I checked the RFC carefully again and found this:

> http://tools.ietf.org/html/rfc2616#section-3.7.1
>
> When in canonical form, media subtypes of the "text" type use CRLF as
> the text line break. HTTP relaxes this requirement and allows the
> transport of text media with plain CR or LF alone representing a line
> break when it is done consistently for an entire entity-body. HTTP
> applications MUST accept CRLF, bare CR, and bare LF as being
> representative of a line break in text media received via HTTP

The requests we send are multipart/form-data, so the RFC exception for text/* would not apply.  On one hand, I don?t think we can say that sending LF is not a bug, on the other hand, I believe nearly all HTTP servers just accept all newlines anyway.

----------
nosy: +mitchellh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Sun Oct 23 04:14:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 02:14:03 +0000
Subject: [issue10510] distutils upload/register should use CRLF in HTTP
	requests
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1319336043.71.0.0208168903466.issue10510@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: duplicate -> 
stage: committed/rejected -> 
superseder: Factor out common code for d2 commands register, upload and upload_docs -> 
title: packaging upload/register should use CRLF in HTTP requests -> distutils upload/register should use CRLF in HTTP requests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Sun Oct 23 04:30:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 02:30:19 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319337019.6.0.774398070312.issue13237@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Sun Oct 23 04:31:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 02:31:47 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1319337107.2.0.45069404764.issue13224@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here?s the python-ideas thread: http://mail.python.org/pipermail/python-ideas/2011-October/thread.html#12459

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Sun Oct 23 04:38:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Oct 2011 02:38:02 +0000
Subject: [issue1548891] shlex (or perhaps cStringIO) and unicode strings
Message-ID: <E1RHnwj-0005QX-Ov@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0b39f2486314 by ?ric Araujo in branch '2.7':
Note that the #1548891 fix indirectly fixes shlex (#6988, #1170)
http://hg.python.org/cpython/rev/0b39f2486314

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1548891>
_______________________________________

From report at bugs.python.org  Sun Oct 23 07:18:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 05:18:53 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1319347133.75.0.958636685872.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, distribute recently committed two fixes for the exe wrappers: https://bitbucket.org/tarek/distribute/issue/238 and https://bitbucket.org/tarek/distribute/issue/207

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sun Oct 23 07:36:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 05:36:14 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1319348174.64.0.93692321826.issue1170@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

$ ./python 
Python 2.7.2+ (2.7:27ae7d4e1983+, Oct 23 2011, 00:09:06) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> shlex.split(u'Hello, World!')
['Hello,', 'World!']

This bug was fixed indirectly by a StringIO fix in 27ae7d4e1983, for #1548891.  BTW, this report was a duplicate of #6988, closed a year ago.

Python 2.7.3 will finally support unicode in shlex, so the doc change requested in this report is outdated.  However, I still want to do something for this.  I?ve noticed that shlex.split?s argument can be a file-like object, and I wonder if passing a StringIO.StringIO(my_unicode_string) wouldn?t work.  If such a short recipe works, I?m all for including it in the 2.7 docs for users of older versions.  If a longer recipe is needed, then ActiveState?s Python Cookbook would be more appropriate, and I?ll add a link to the docs.  If it?s very long and requires a PyPI project, then I?m willing to link to that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Sun Oct 23 07:42:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Oct 2011 05:42:51 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1319348571.19.0.524419861853.issue1170@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The second message in this page reports that StringIO.StringIO works, but when I pass a unicode string with non-ASCII chars there?s a method call that fails because of implicit unicode-to-str conversion:

Traceback (most recent call last):
  File "/usr/lib/python2.7/shlex.py", line 150, in read_token
    elif nextchar in self.wordchars:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xdf in position 63: ordinal not in range(128)

I?ll try to create a Shlex instance, replace self.wordchars with a decoded version and try again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Sun Oct 23 11:08:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Oct 2011 09:08:30 +0000
Subject: [issue13246] Py_UCS4_strlen and friends needn't be public
In-Reply-To: <1319314430.74.0.993573606288.issue13246@psf.upfronthosting.co.za>
Message-ID: <1319360910.1.0.634191736155.issue13246@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It seems there's no reason to document these functions
> which operate on null-terminated unicode arrays.

It's the easiest way to create a new string with the new Unicode API, when it's difficult to predict the exact output length and maximum character:

Py_UCS4 *buffer = PyMem_Malloc(...);
...
str = PyUnicode_FromKindAndBuffer(buffer, PyUnicode_4BYTE_KIND);
PyMem_Free(buffer);

PyUCS4_* functions are useful in the "..." (to write characters, expecially when you manipulate multiple strings).

For examples, see Python/import.c which used char*, then Py_UNICODE* and now Py_UCS4*. It's maybe possible to avoid functions like xxx_strlen(), but it was easier to replace str*() functions by Py_UNICODE_* and then PyUCS4_* functions.

--

Py_UNICODE_* and PyUCS4_* functions are not part of the stable API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13246>
_______________________________________

From report at bugs.python.org  Sun Oct 23 11:19:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Oct 2011 09:19:48 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319361588.08.0.91822099695.issue13247@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

abspath() is implemented using nt._getfullpathname() which calls GetFullPathNameA().

> The returned path with question marks is completely useless.

Can you open the file using such filename? If no, I agree that the result is useless.

> It's better that python throw an error than return the question marks.

Python is currently a thin wrapper on the Windows API. Windows doesn't consider that a filename with question marks as an error.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364963%28v=vs.85%29.aspx

Python can maybe uses GetFullPathNameW() and encode manually the filename using its strict MBCS codec. MBCS codec is strict since Python 3.2: it raises a UnicodeEncodeError if the string cannot be encoded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Sun Oct 23 12:33:24 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 23 Oct 2011 10:33:24 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319366004.13.0.0322672338968.issue13241@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Thank you all for help. I finally managed to build it. :-)
So here are complete steps I've taken to build python after OS reinstall:
1. Install XCode 4.2
2. Install MacPorts
3. sudo port -v selfupdate
4. sudo port install gcc46
5. ./configure CC=gcc-mp-4.6 LDFLAGS=-L/opt/local/lib --with-pydebug && make -j2

Should I post this somewhere for others who may face similar problems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Sun Oct 23 12:35:58 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 23 Oct 2011 10:35:58 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319366158.87.0.242643174144.issue13241@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


----------
resolution:  -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Sun Oct 23 12:38:27 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 23 Oct 2011 10:38:27 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319366307.49.0.818452087892.issue13241@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Sun Oct 23 12:39:22 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 23 Oct 2011 10:39:22 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319366362.47.0.374207411888.issue13241@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


----------
resolution: works for me -> fixed
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Sun Oct 23 12:46:12 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 23 Oct 2011 10:46:12 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319366772.81.0.92149983703.issue13241@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Sun Oct 23 13:04:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Oct 2011 11:04:39 +0000
Subject: [issue13105] Please elaborate on how 2.x and 3.x are different heads
In-Reply-To: <1317770656.72.0.880626385137.issue13105@psf.upfronthosting.co.za>
Message-ID: <E1RHvr0-0001a2-7p@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0541f815d016 by Nick Coghlan in branch 'default':
Update NEWS entry policy based on recent mailing list discussion and forward porting section based on Issue 13105
http://hg.python.org/devguide/rev/0541f815d016

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13105>
_______________________________________

From report at bugs.python.org  Sun Oct 23 13:07:17 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 23 Oct 2011 11:07:17 +0000
Subject: [issue13105] Please elaborate on how 2.x and 3.x are different heads
In-Reply-To: <1317770656.72.0.880626385137.issue13105@psf.upfronthosting.co.za>
Message-ID: <1319368037.46.0.522207869304.issue13105@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The devguide actually did align with what I said in my email, but this wasn't clear if you only read the "Forward Porting" section (you had to read the "Porting Between Major Versions" section further down the page as well).

I added a new paragraph to the forward porting section so it describes the whole policy, leaving the following two sections to cover the mechanics of actually handling that with Mercurial.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13105>
_______________________________________

From report at bugs.python.org  Sun Oct 23 13:07:59 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 23 Oct 2011 11:07:59 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1319368079.31.0.0860958044408.issue8828@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The recent issue #13146 renewed my interest, so I'd like to make this move forward, since I think an atomic rename/write API could be quite useful.
Issue #8604 (Adding an atomic FS write API) can be achieved relatively easily with the typical (fsync() left aside)
- create temporary file
- write to the temp file
- atomically rename the temp file to the target path

But the problem is that rename is only atomic on POSIX, and not on Windows.
So I'd suggest to:
- rename this issue to target specifically Windows ;-)
- add MoveFileTransacted to the standard library (PC/msvcrtmodule.c, posixmodule?)

I'm -1 on exposing a "best effort" atomic rename/file API: either the OS offers the primitives necessary to achieve atomicity, or it doesn't. It's better to have a working implementation on some OSes than a flaky implementation on every OS.

Note that I'll happily take over the atomic file API part (issue #8604), but since my Windows kung-fu is so poor, it'd be nice if someone with some Windows experience could tackle this MoveFileTransacted

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Sun Oct 23 13:28:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 23 Oct 2011 11:28:55 +0000
Subject: [issue13140] ThreadingMixIn.daemon_threads is not honored when parent
	is daemon
In-Reply-To: <1319325270.49.0.594851522806.issue13140@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0zkkZWyrVreafxfiEeDo48MC0JGBHDD423XbXb4xQZBQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I would prefer to preserve the inheritance by default, and to change the daemonic attribute only if it is explicitly set to True or False.
> This way it will be backward compatible.

It may be backward compatible, but IMHO, the current behavior is
broken: while it can certainly make sense to set the server thread
daemonic, you most certainly don't want to have client threads
daemonic implicitely (since you usually don't want to terminate the
client's connections abruptly when the main thread exits).
But I must admit I don't have a strong opinion, so both solutions are OK to me.
The only thing that bothers me is this:
"""
+.. versionchanged:: 3.3
+   previously, the *daemon_threads = False* flag was ignored.
"""

You usually document new features or behavior changes: this really
looks like a bug fix (and is one actually). Something like "the
semantics of *daemon_threads* changed slighty" might be better (but
I'm no native speaker).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13140>
_______________________________________

From report at bugs.python.org  Sun Oct 23 13:56:34 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 23 Oct 2011 11:56:34 +0000
Subject: [issue13217] Missing header dependencies in Makefile
In-Reply-To: <1318983258.55.0.960297108265.issue13217@psf.upfronthosting.co.za>
Message-ID: <1319370994.13.0.229064802633.issue13217@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13217>
_______________________________________

From report at bugs.python.org  Sun Oct 23 14:26:42 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 23 Oct 2011 12:26:42 +0000
Subject: [issue13243] _Py_identifier should be _Py_IDENTIFER
In-Reply-To: <1319310205.15.0.503943075259.issue13243@psf.upfronthosting.co.za>
Message-ID: <4EA407FD.2080809@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Maybe we should change the build system to always regenerate the files
> or add something to automation that regenerates the AST C file every
> time.

Most definitely not. It is very deliberate that asdl_c.py is only
invoked when the ASDL sources change. Otherwise, having Python installed
would be a build requirement for Python, which it must be not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13243>
_______________________________________

From report at bugs.python.org  Sun Oct 23 14:30:07 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 23 Oct 2011 12:30:07 +0000
Subject: [issue13246] Py_UCS4_strlen and friends needn't be public
In-Reply-To: <1319314430.74.0.993573606288.issue13246@psf.upfronthosting.co.za>
Message-ID: <1319373007.67.0.308116153963.issue13246@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Before the release, we should consider whether we can drop these functions altogether.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13246>
_______________________________________

From report at bugs.python.org  Sun Oct 23 14:37:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Oct 2011 12:37:17 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <E1RHxIe-0007qD-Oe@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c2a89b509be4 by Nick Coghlan in branch '3.2':
Issue 1294232: Fix errors in metaclass calculation affecting some cases of metaclass inheritance. Patch by Daniel Urban.
http://hg.python.org/cpython/rev/c2a89b509be4

New changeset c72063032a7a by Nick Coghlan in branch 'default':
Merge issue 1294232 patch from 3.2
http://hg.python.org/cpython/rev/c72063032a7a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Sun Oct 23 14:40:31 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 23 Oct 2011 12:40:31 +0000
Subject: [issue13246] Py_UCS4_strlen and friends needn't be public
In-Reply-To: <1319314430.74.0.993573606288.issue13246@psf.upfronthosting.co.za>
Message-ID: <1319373631.88.0.509592662322.issue13246@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Making sure we don't forget that :)

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13246>
_______________________________________

From report at bugs.python.org  Sun Oct 23 14:41:33 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 23 Oct 2011 12:41:33 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1319373693.14.0.60585581585.issue1294232@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fix has been applied to 3.x and hence will be in 3.3 and the next 3.2 release.

I have adjusted the issue metadata to reflect the fact 2,7 still exhibits the problem, but the patch requires significant work to account for the 3.x vs 2.x changes in class creation before it can be backported.

----------
components:  -Documentation
stage: patch review -> needs patch
versions:  -Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Sun Oct 23 18:17:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 23 Oct 2011 16:17:03 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319386623.69.0.490453411809.issue13241@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

In general, I would not recommend using anything other than an Apple-supplied tool chain for building anything on Mac OS X.  To help us better understand the issues, can you say exactly which compilers you tried originally, i.e. the complete --version output from the compiler(s) used in your failing Python builds?

Because of the current somewhat chaotic OS X compiler situation, I am in the process of performing a controlled test of building and testing various current versions of Python with the available Xcode compilers for 10.7 and 10.6.

----------
assignee:  -> ned.deily
components: +Macintosh
priority: normal -> high
resolution: fixed -> 
status: pending -> open
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Sun Oct 23 19:06:26 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 23 Oct 2011 17:06:26 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319389586.09.0.496823602911.issue13241@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Ah, of course.
Initially I've tried to compile using this:

i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

XCode version 4.2, build 4C199

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Sun Oct 23 19:20:41 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 23 Oct 2011 17:20:41 +0000
Subject: [issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
In-Reply-To: <1319208086.31.0.00990210804778.issue13240@psf.upfronthosting.co.za>
Message-ID: <1319390441.49.0.220252427576.issue13240@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> Actually, I think sysconfig does the right thing when it comes to all
> the configure-generated HAVE_XXX variables

I agree.  The 'configure' script could be improved, though.  If we truly
want to enable this by default, then the defaulting should be moved to
configure.  This will give a more accurate portrayal in sysconfig.
Also, we can do the USE but !HAVE check in configure, which is better
anyway because the error is caught earlier.

I am thinking something like the attached.  Thoughts?

P.S. We could probably get rid of the HAVE macro all together by doing
all the work in the 'configure' script.

----------
keywords: +patch
nosy: +meador.inge
Added file: http://bugs.python.org/file23503/issue13240.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Sun Oct 23 19:49:46 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 23 Oct 2011 17:49:46 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
Message-ID: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The PEP 387 suggests that deprecated objects or arguments are removed in version (n+1).
I've listed these DeprecationWarnings in 3.2, which are still in 3.3.
I assume that most of these deprecated objects or arguments could be removed before next release.


*_pyio*
  argument "max_buffer_size" of BufferedWriter and BufferedRWPair
*argparse*
  argument "version" and related methods of ArgumentParser
*asyncore*
  shortcut "dispatcher.*" for "dispatcher.socket.*" attributes
*base64*
  functions "encodestring" and "decodestring"
*cgi*
  functions "parse_qs" and "parse_qsl"
*configparser*
  "ParsingError.filename", "RawConfigParser.readfp", "SafeConfigParser"
*decimal*
  "Context._clamp"
*difflib*
  "SequenceMatcher.isbjunk", "SequenceMatcher.isbpopular"
*gzip*
  "GzipFile.filename"
*http.client*
  argument "strict" of HTTPResponse and HTTPConnection
*lib2to3*
  methods "set_prefix" and "get_prefix" of "pytree.Base"
*mailbox*
  argument of type "StringIO" or "text mode files"
*ntpath*
  function "splitunc"
*tarfile*
  argument "exclude" of "TarFile.add"
*trace*
  old API
*unittest*
  "assert{DictContainsSubset,RaisesRegexp,RegexpMatches}", "fail*"
*xml.etree*
  "Element.getchildren", "XMLParser.doctype"

----------
components: Library (Lib)
messages: 146236
nosy: flox
priority: normal
severity: normal
status: open
title: deprecated in 3.2, should be removed in 3.3
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Sun Oct 23 20:01:51 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 23 Oct 2011 18:01:51 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1319392911.16.0.287941607847.issue13248@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

In addition, we have some object and attributes which are triggering "PendingDeprecationWarning" in 3.2.
We may keep these warnings in 3.3, or choose to turn some of them into "DeprecationWarning", to prepare their removal in 3.5.


*cgi*
  "cgi.escape"
*distutils"
  argument compress="compress" of make_tarball
  function "check_metadata" in "command.register"
  option "force-manifest" of "command.sdist"
*importlib*
  "abc.PyLoader" and "abc.PyPycLoader"
*nntplib*
  "_NNTPBase.xgtitle" and "_NNTPBase.xpath"
*smtpd*
  the class-private "__*" attributes
*xml.etree*
  method "getiterator" of "Element" and "ElementTree"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Sun Oct 23 20:32:39 2011
From: report at bugs.python.org (Roy Smith)
Date: Sun, 23 Oct 2011 18:32:39 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
Message-ID: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

The docs list the arguments in the order:

class argparse.ArgumentParser([description][, epilog][, prog]...

but the code (I'm looking at the 2.7.2 source) lists them as:

 class ArgumentParser(_AttributeHolder, _ActionsContainer):
   [...]
   def __init__(self,
                 prog=None,
                 usage=None,
                 description=None,
                 [...]

If you create a parser with just:

parser = argparse.ArgumentParser("foo")

you end up setting the 'prog' argument instead of the expected 'description'.  

It's unclear if the order in the code should be fixed to match the docs, or the order in the docs fixed to match the code, or just a note added to the docs saying you should not rely on positional argument ordering and always create a parser with named arguments.

----------
components: Library (Lib)
messages: 146238
nosy: roysmith
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser() lists arguments in the wrong order
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Sun Oct 23 20:33:25 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 23 Oct 2011 18:33:25 +0000
Subject: [issue13243] _Py_identifier should be _Py_IDENTIFER
In-Reply-To: <4EA407FD.2080809@v.loewis.de>
Message-ID: <CAK1QoorSrNnA8MJzHyyp+YAX_O7R7w1p0Zw44QJ9Q6Ttc9ZXkA@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

> Most definitely not. It is very deliberate that asdl_c.py is only
> invoked when the ASDL sources change. Otherwise, having Python installed
> would be a build requirement for Python, which it must be not.

OK, thanks for the background.  To be clear, though, the build dependency
is already there.  You just have to touch the ASDL sources to run
into it (Lib/opcode.py as well).  This is even documented in the
Makefile*:

# XXX Note that a build now requires Python exist before the build starts
ASDLGEN=	 $(srcdir)/Parser/asdl_c.py

However, modifying the ASDL source is, with respect to other source
modifications, not as common.  So, I see no reason to make the situation worse
by running asd_c.py all the time.  Suggestion withdrawn.

* If not relying on an external Python is a hard requirement (and I do
see why that may be useful),
then the build system could be changed to only allow changes to
problematic sources
(ASDL, opcode.py) after Python has been built once.  Then the built
Python could be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13243>
_______________________________________

From report at bugs.python.org  Sun Oct 23 20:35:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Oct 2011 18:35:33 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319394933.97.0.181341813622.issue13241@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

Oh, that's not GCC but llvm-gcc. It is maybe a bug in LLVM?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Sun Oct 23 20:39:12 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 23 Oct 2011 18:39:12 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1319395152.39.0.913326580198.issue13249@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

in 3.x, same issue.
IMHO documentation should be fixed.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +bethard, docs at python, flox
stage:  -> needs patch
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Sun Oct 23 20:45:08 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 23 Oct 2011 18:45:08 +0000
Subject: [issue13250] ctypes: reference leak in POINTER code
Message-ID: <1319395508.92.0.449724155939.issue13250@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

While implementing a patch for issue13096 I found a reference leak in 'ctypes'.  I couldn't find the cause immediately, but it can be 
reproduced by applying the attached patch and running:

[meadori at motherbrain cpython]$ ./python -m test -R : test_ctypes
[1/1] test_ctypes
beginning 9 repetitions
123456789
.........
test_ctypes leaked [51, 51, 51, 51] references, sum=204
1 test failed:
    test_ctypes
[174347 refs]

----------
components: ctypes
files: ctypes-refleak-repro.patch
keywords: patch
messages: 146242
nosy: amaury.forgeotdarc, belopolsky, meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: ctypes: reference leak in POINTER code
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file23504/ctypes-refleak-repro.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13250>
_______________________________________

From report at bugs.python.org  Sun Oct 23 20:46:54 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 23 Oct 2011 18:46:54 +0000
Subject: [issue13250] ctypes: reference leak in POINTER code
In-Reply-To: <1319395508.92.0.449724155939.issue13250@psf.upfronthosting.co.za>
Message-ID: <1319395614.18.0.919170562818.issue13250@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The cause is ctypes caches POINTER types. You have to make sure to clear the cache.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13250>
_______________________________________

From report at bugs.python.org  Sun Oct 23 20:53:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Oct 2011 18:53:12 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <E1RI3AR-0001K1-S5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 479a7dd1ea6a by Mark Dickinson in branch 'default':
Issue #13201: equality for range objects is now based on equality of the underlying sequences.  Thanks Sven Marnach for the patch.
http://hg.python.org/cpython/rev/479a7dd1ea6a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Sun Oct 23 20:53:55 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Oct 2011 18:53:55 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1319396035.58.0.375928930903.issue13201@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> In most cases, global variables Py_Zero and Py_One would be enough to
> simplify this kind of code.

Agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Sun Oct 23 20:54:23 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Oct 2011 18:54:23 +0000
Subject: [issue13201] Implement comparison operators for range objects
In-Reply-To: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za>
Message-ID: <1319396063.99.0.964237328152.issue13201@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13201>
_______________________________________

From report at bugs.python.org  Sun Oct 23 21:02:13 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 23 Oct 2011 19:02:13 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1319396533.24.0.902260555796.issue13249@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Fixing the documentation is better, as changing the argument order would break existing code.

----------
keywords: +easy
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Sun Oct 23 21:06:00 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sun, 23 Oct 2011 19:06:00 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1319396760.6.0.797983893499.issue13249@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Sun Oct 23 21:07:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Oct 2011 19:07:54 +0000
Subject: [issue10925] Document pure Python version of integer-to-float
	correctly-rounded conversion
In-Reply-To: <1295269244.12.0.126728941356.issue10925@psf.upfronthosting.co.za>
Message-ID: <E1RI3Of-0002HU-9Q@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 117d51d3dd7d by Mark Dickinson in branch 'default':
Issue #10925: Add equivalent pure Python code for the builtin int-to-float conversion to test_long.
http://hg.python.org/cpython/rev/117d51d3dd7d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10925>
_______________________________________

From report at bugs.python.org  Sun Oct 23 21:08:13 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Oct 2011 19:08:13 +0000
Subject: [issue10925] Document pure Python version of integer-to-float
	correctly-rounded conversion
In-Reply-To: <1295269244.12.0.126728941356.issue10925@psf.upfronthosting.co.za>
Message-ID: <1319396893.4.0.366510099539.issue10925@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10925>
_______________________________________

From report at bugs.python.org  Sun Oct 23 21:11:03 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Oct 2011 19:11:03 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1319397063.2.0.604319843974.issue13249@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In the doc, the signature line is followed by a list of short descriptions in a third order. That perhaps should be changed to follow the same corrected order as the signature line. On the other hand, it matches the order of the detail sections that follow. On the third hand, that current order is confusing as it intermixes parameters that affect the help message behavior with those that affect the actual argument parsing behavior. I think these should be separated with one group following the other.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Sun Oct 23 21:11:13 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Oct 2011 19:11:13 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1319397073.77.0.978407745522.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing as "won't fix", for reasons given above.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Sun Oct 23 21:16:12 2011
From: report at bugs.python.org (Roy Smith)
Date: Sun, 23 Oct 2011 19:16:12 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1319397372.68.0.934562589756.issue13249@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

An Nth place is in the docstring:

    Keyword Arguments:                                                                              
        - prog -- The name of the program (default: sys.argv[0])                                    
        - usage -- A usage message (default: auto-generated from arguments)                         
        - description -- A description of what the program does                                     
        - epilog -- Text following the argument descriptions                                        
        - parents -- Parsers whose arguments should be copied into this one                         
        - formatter_class -- HelpFormatter class for printing help messages                         
        - prefix_chars -- Characters that prefix optional arguments                                 
        - fromfile_prefix_chars -- Characters that prefix files containing                          
            additional arguments                                                                    
        - argument_default -- The default value for all arguments                                   
        - conflict_handler -- String indicating how to handle conflicts                             
        - add_help -- Add a -h/-help option

which omits 'version'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Sun Oct 23 21:47:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Oct 2011 19:47:52 +0000
Subject: [issue12965] longobject: documentation improvements
In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>
Message-ID: <E1RI41F-0004na-Cr@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d4839fea4a5a by Mark Dickinson in branch 'default':
Issue #12965: Fix some inaccurate comments in Objects/longobject.c.  Thanks Stefan Krah.
http://hg.python.org/cpython/rev/d4839fea4a5a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12965>
_______________________________________

From report at bugs.python.org  Sun Oct 23 21:55:01 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Oct 2011 19:55:01 +0000
Subject: [issue12965] longobject: documentation improvements
In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>
Message-ID: <1319399701.74.0.394531537782.issue12965@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've fixed some of the inaccurate comments in Objects/longobject.c, for the default branch;  I'm still looking at the Doc update.

This really is a bit of a mess, especially for cases like PyLong_AsVoidPtr, which can either end up calling PyLong_As(Long)Long (which  allows conversion via __int__), or PyLong_AsUnsigned(Long)Long (which doesn't).

Ultimately, I think it would make sense to remove all __int__ conversions from Objects/longobject.c;  this would affect:

  - PyLong_AsLongAndOverflow
  - PyLong_AsLong
  - PyLong_AsUnsignedLongMask

and the 'LongLong' variants of these.  The ramifications of such a change might be quite long-reaching;  in particular, I seem to recall that this would affect the 'getargs' machinery.

It could be fun to remove these conversions and see how much of the test-suite fails. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12965>
_______________________________________

From report at bugs.python.org  Sun Oct 23 22:14:40 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Oct 2011 20:14:40 +0000
Subject: [issue12965] longobject: documentation improvements
In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>
Message-ID: <1319400880.4.0.27885284992.issue12965@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It could be fun to remove these conversions and see how much of the
> test-suite fails. :-)

... On my machine, just test_ctypes and test_getargs2, as it turns out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12965>
_______________________________________

From report at bugs.python.org  Sun Oct 23 22:31:55 2011
From: report at bugs.python.org (Roy Smith)
Date: Sun, 23 Oct 2011 20:31:55 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1319401915.74.0.749008630165.issue13249@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

I'm working on a doc patch now...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Sun Oct 23 22:48:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Oct 2011 20:48:15 +0000
Subject: [issue13141] get rid of old threading API in the examples
In-Reply-To: <1318192627.46.0.311858462486.issue13141@psf.upfronthosting.co.za>
Message-ID: <E1RI4xm-0000Zw-4e@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d34beaaf7060 by Florent Xicluna in branch '3.2':
Issue 13141: Demonstrate recommended style for socketserver examples.
http://hg.python.org/cpython/rev/d34beaaf7060

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13141>
_______________________________________

From report at bugs.python.org  Sun Oct 23 23:08:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Oct 2011 21:08:25 +0000
Subject: [issue13141] get rid of old threading API in the examples
In-Reply-To: <1318192627.46.0.311858462486.issue13141@psf.upfronthosting.co.za>
Message-ID: <E1RI5HI-0001tp-4J@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8de472fb8cfe by Florent Xicluna in branch '2.7':
Issue #13141: Demonstrate recommended style for SocketServer examples.
http://hg.python.org/cpython/rev/8de472fb8cfe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13141>
_______________________________________

From report at bugs.python.org  Sun Oct 23 23:09:36 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 23 Oct 2011 21:09:36 +0000
Subject: [issue13141] get rid of old threading API in the examples
In-Reply-To: <1318192627.46.0.311858462486.issue13141@psf.upfronthosting.co.za>
Message-ID: <1319404176.99.0.186433062182.issue13141@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13141>
_______________________________________

From report at bugs.python.org  Sun Oct 23 23:12:59 2011
From: report at bugs.python.org (Roy Smith)
Date: Sun, 23 Oct 2011 21:12:59 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1319404379.51.0.929534798441.issue13249@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

Patch attached.  I just deal with putting all the items into the same order, not terry.reedy's idea for separating them into two groups.

Added a recommendation to only use keywords, which seems sane given the number of arguments.

----------
keywords: +patch
Added file: http://bugs.python.org/file23505/Issue13249.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Sun Oct 23 23:14:32 2011
From: report at bugs.python.org (Roy Smith)
Date: Sun, 23 Oct 2011 21:14:32 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1319404472.42.0.562503839638.issue13249@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

PS -- this is against the 2.7 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Sun Oct 23 23:30:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 23 Oct 2011 21:30:17 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1319405417.4.0.0431579497463.issue13248@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

*unittest*
  "assert{DictContainsSubset,RaisesRegexp,RegexpMatches}", "fail*"

The "fail*" should stay.

The general idea is that with Python3 we can wait a bit more before getting rid of things, because if someone jumps from 2.7 to 3.3, he might not find things that got deprecated in 3.2 and disappeared on 3.3.

That said, some of the more obscure functions/method/attributes can probably go.

Also I think that PendingDeprecations are now quite useless, since DeprecationWarnings are silenced by default.  I think we can convert them to DeprecationWarnings, even if we leave them there for a couple of versions.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Sun Oct 23 23:57:24 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 23 Oct 2011 21:57:24 +0000
Subject: [issue13243] _Py_identifier should be _Py_IDENTIFER
In-Reply-To: <CAK1QoorSrNnA8MJzHyyp+YAX_O7R7w1p0Zw44QJ9Q6Ttc9ZXkA@mail.gmail.com>
Message-ID: <4EA48DBE.5020700@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 23.10.2011 20:33, schrieb Meador Inge:
> 
> Meador Inge <meadori at gmail.com> added the comment:
> 
>> Most definitely not. It is very deliberate that asdl_c.py is only
>> invoked when the ASDL sources change. Otherwise, having Python installed
>> would be a build requirement for Python, which it must be not.
> 
> OK, thanks for the background.  To be clear, though, the build dependency
> is already there.  You just have to touch the ASDL sources to run
> into it (Lib/opcode.py as well).  This is even documented in the
> Makefile*:

Just to be more clear: normally, generated files shouldn't be checked
into the source repository. However, exceptions are typically made for
generated files that may be difficult to regenerate on some target
systems. For Python, this includes configure (depends on autoconf being
run), and various files generated from Python scripts (also including
the Unicode database, for example).

So when we check in generated files, the build dependency becomes unused
unless the source file gets modified - which, as you point out, happens
rarely, and never happens for somebody who just wants to build Python.

> * If not relying on an external Python is a hard requirement (and I do
> see why that may be useful), then the build system could be changed to only allow changes to
> problematic sources (ASDL, opcode.py) after Python has been built once.  Then the built
> Python could be used.

See above. It's fine to require core contributors to have Python
installed (and also autoconf). We just need to make sure that
Python is not required on the target system (as people may try
to install Python initially on that system).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13243>
_______________________________________

From report at bugs.python.org  Sun Oct 23 23:58:50 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 23 Oct 2011 21:58:50 +0000
Subject: [issue13250] ctypes: reference leak in POINTER code
In-Reply-To: <1319395508.92.0.449724155939.issue13250@psf.upfronthosting.co.za>
Message-ID: <1319407130.43.0.68172393523.issue13250@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

So it's not a bug at all, right?

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13250>
_______________________________________

From report at bugs.python.org  Mon Oct 24 00:22:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 23 Oct 2011 22:22:40 +0000
Subject: [issue13251] Update string description in datamodel.rst
Message-ID: <1319408560.2.0.695201505258.issue13251@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The attached patch updates the definition of "String" after PEP 393.

----------
assignee: ezio.melotti
components: Documentation, Unicode
files: issue13251.diff
keywords: needs review, patch
messages: 146262
nosy: eric.araujo, ezio.melotti, haypo, lemburg, loewis
priority: normal
severity: normal
stage: patch review
status: open
title: Update string description in datamodel.rst
versions: Python 3.3
Added file: http://bugs.python.org/file23506/issue13251.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13251>
_______________________________________

From report at bugs.python.org  Mon Oct 24 00:32:48 2011
From: report at bugs.python.org (Carlo Verre)
Date: Sun, 23 Oct 2011 22:32:48 +0000
Subject: [issue13252] new decumulate() function in itertools module
Message-ID: <1319409168.22.0.462760902888.issue13252@psf.upfronthosting.co.za>


New submission from Carlo Verre <carlo.verre at gmail.com>:

After in Python 3.2 the accumulate() function has been added to itertools module, for self-evident reasons of completeness and symmetry we could add in 3.3 the inverse decumulate() function, which, given the iterable argument p, yields p[0], p[1] - p[0], p[2] - p[1]... Its equivalent python form is in the attached file decumulate.py, below.

----------
components: Extension Modules
files: decumulate.py
messages: 146263
nosy: carlo.verre, rhettinger
priority: normal
severity: normal
status: open
title: new decumulate() function in itertools module
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23507/decumulate.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13252>
_______________________________________

From report at bugs.python.org  Mon Oct 24 00:38:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 23 Oct 2011 22:38:55 +0000
Subject: [issue13251] Update string description in datamodel.rst
In-Reply-To: <1319408560.2.0.695201505258.issue13251@psf.upfronthosting.co.za>
Message-ID: <1319409535.23.0.195188502075.issue13251@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

New patch that doesn't mention surrogates, as suggested by Antoine.

----------
Added file: http://bugs.python.org/file23508/issue13251-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13251>
_______________________________________

From report at bugs.python.org  Mon Oct 24 00:44:05 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 23 Oct 2011 22:44:05 +0000
Subject: [issue13251] Update string description in datamodel.rst
In-Reply-To: <1319408560.2.0.695201505258.issue13251@psf.upfronthosting.co.za>
Message-ID: <1319409845.82.0.103288051236.issue13251@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13251>
_______________________________________

From report at bugs.python.org  Mon Oct 24 00:51:08 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 23 Oct 2011 22:51:08 +0000
Subject: [issue13250] ctypes: reference leak in POINTER code
In-Reply-To: <1319407130.43.0.68172393523.issue13250@psf.upfronthosting.co.za>
Message-ID: <CAK1Qoop2=TOazchVLJfwOLYmzZ78=jMJKGtb1VMtotGNrRg41A@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

Ah, I see now.  Thanks Benjamin.

> So it's not a bug at all, right?

A bug in regrtest.py maybe.  'dash_R_cleanup' clears various other caches in
between test runs to avoid false positives like this.  Perhaps
'ctypes._pointer_type_cache'
should be cleared there as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13250>
_______________________________________

From report at bugs.python.org  Mon Oct 24 01:05:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Oct 2011 23:05:01 +0000
Subject: [issue13215] multiprocessing Manager.connect() aggressively retries
	refused connections
In-Reply-To: <1318965417.81.0.122561387998.issue13215@psf.upfronthosting.co.za>
Message-ID: <1319411101.71.0.604010251025.issue13215@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure, but I think that would be for the case where you are spawning the server yourself and the child process takes time to start up.

----------
nosy: +neologix, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13215>
_______________________________________

From report at bugs.python.org  Mon Oct 24 01:09:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Oct 2011 23:09:36 +0000
Subject: [issue10332] Multiprocessing maxtasksperchild results in hang
In-Reply-To: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>
Message-ID: <1319411376.02.0.0186918010889.issue10332@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks good to me, thanks.

----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10332>
_______________________________________

From report at bugs.python.org  Mon Oct 24 01:09:59 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 23 Oct 2011 23:09:59 +0000
Subject: [issue13228] Add "Quick Start" section to the devguide index
In-Reply-To: <1319067423.48.0.288389971536.issue13228@psf.upfronthosting.co.za>
Message-ID: <1319411399.71.0.161044853804.issue13228@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That's a good point, but I find the wording a bit long.  The attached patch tries to keep it short and adds a link to the section that explains when and why it's python.exe.

----------
Added file: http://bugs.python.org/file23509/issue13228-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13228>
_______________________________________

From report at bugs.python.org  Mon Oct 24 01:30:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Oct 2011 23:30:43 +0000
Subject: [issue13228] Add "Quick Start" section to the devguide index
In-Reply-To: <1319067423.48.0.288389971536.issue13228@psf.upfronthosting.co.za>
Message-ID: <E1RI7V0-0003Eu-Cb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 25f1c003ea01 by Ezio Melotti in branch 'default':
#13228: add a "Quick Start" section to the index page.
http://hg.python.org/devguide/rev/25f1c003ea01

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13228>
_______________________________________

From report at bugs.python.org  Mon Oct 24 01:31:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 23 Oct 2011 23:31:52 +0000
Subject: [issue13228] Add "Quick Start" section to the devguide index
In-Reply-To: <1319067423.48.0.288389971536.issue13228@psf.upfronthosting.co.za>
Message-ID: <1319412712.69.0.782514410641.issue13228@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Done, thanks for the feedback!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13228>
_______________________________________

From report at bugs.python.org  Mon Oct 24 02:01:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 00:01:15 +0000
Subject: [issue13141] get rid of old threading API in the examples
In-Reply-To: <1318192627.46.0.311858462486.issue13141@psf.upfronthosting.co.za>
Message-ID: <1319414475.24.0.491165167676.issue13141@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be closed, no?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13141>
_______________________________________

From report at bugs.python.org  Mon Oct 24 02:23:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 00:23:12 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1319415792.67.0.0588059217963.issue8828@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

MoveFileTransacted is only available under Vista or later. You should be able to use MoveFileEx for the same effect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Mon Oct 24 02:27:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 00:27:07 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1319416027.54.0.54295917045.issue8828@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

"The solution? Let's remember that metadata changes are atomic. Rename is such a case."

This is from a MSDN blog, I would hope he knows what he's talking about.
http://blogs.msdn.com/b/adioltean/archive/2005/12/28/507866.aspx

(MoveFileEx appears in Windows XP, which is fine: in Python 3.3, "Windows 2000 and Windows platforms which set COMSPEC to command.com are no longer supported due to maintenance burden")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Mon Oct 24 03:17:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 01:17:51 +0000
Subject: [issue9239] zipfile: truncating comment can corrupt the zipfile
In-Reply-To: <1278979006.42.0.00730549521889.issue9239@psf.upfronthosting.co.za>
Message-ID: <1319419071.97.0.490179680604.issue9239@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
type: performance -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9239>
_______________________________________

From report at bugs.python.org  Mon Oct 24 03:23:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 01:23:29 +0000
Subject: [issue6216] Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
In-Reply-To: <1244246653.62.0.629764911773.issue6216@psf.upfronthosting.co.za>
Message-ID: <1319419409.94.0.793269824447.issue6216@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Closing as outdated. There are no freelists anymore in the unicode implementation.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6216>
_______________________________________

From report at bugs.python.org  Mon Oct 24 03:25:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 01:25:36 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <1319419536.98.0.974724239082.issue10363@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
versions: +Python 3.2, Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________

From report at bugs.python.org  Mon Oct 24 03:29:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 01:29:13 +0000
Subject: [issue11447] test_pydoc refleak
In-Reply-To: <1299630382.79.0.412893020199.issue11447@psf.upfronthosting.co.za>
Message-ID: <1319419753.58.0.556109032716.issue11447@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't reproduce anymore. I believe this may have been due to the fact that pydoc can try to import everything on sys.path, including third-party libraries. I got bitten by that on another issue.

----------
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11447>
_______________________________________

From report at bugs.python.org  Mon Oct 24 06:02:32 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 24 Oct 2011 04:02:32 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1319428952.48.0.0356444713836.issue13062@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Nick, the revised definition of 'getclosurevars' seems reasonable to me.
I will cut a new patch this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13062>
_______________________________________

From report at bugs.python.org  Mon Oct 24 08:08:01 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 06:08:01 +0000
Subject: [issue13141] get rid of old threading API in the examples
In-Reply-To: <1318192627.46.0.311858462486.issue13141@psf.upfronthosting.co.za>
Message-ID: <1319436481.58.0.73095413765.issue13141@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13141>
_______________________________________

From report at bugs.python.org  Mon Oct 24 08:25:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 24 Oct 2011 06:25:52 +0000
Subject: [issue13253] 2to3 fix_renames renames sys.maxint only in imports
Message-ID: <1319437552.82.0.780264952493.issue13253@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

$ cat deleteme.py 
from sys import maxint
print 'maxint', maxint
$ 2to3 deleteme.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored deleteme.py
--- deleteme.py (original)
+++ deleteme.py (refactored)
@@ -1,2 +1,2 @@
-from sys import maxint
-print 'maxint', maxint
+from sys import maxsize
+print('maxint', maxint)
RefactoringTool: Files that need to be modified:
RefactoringTool: deleteme.py

The maxint in the print should be converted too.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 146278
nosy: benjamin.peterson, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: 2to3 fix_renames renames sys.maxint only in imports
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13253>
_______________________________________

From report at bugs.python.org  Mon Oct 24 08:30:11 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 24 Oct 2011 06:30:11 +0000
Subject: [issue13241] Assertion failed in _PyUnicode_CheckConsistency during
	build of default branch on Mac OS X
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319437811.91.0.310074399144.issue13241@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Oleg, thanks. That is consistent with previous reports; so far, this issue has only been reported with llvm-gcc, not the plain gcc-4.2's shipped in Xcode prior to 4.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Mon Oct 24 08:46:54 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 24 Oct 2011 06:46:54 +0000
Subject: [issue13252] new decumulate() function in itertools module
In-Reply-To: <1319409168.22.0.462760902888.issue13252@psf.upfronthosting.co.za>
Message-ID: <1319438814.65.0.755876225739.issue13252@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13252>
_______________________________________

From report at bugs.python.org  Mon Oct 24 08:56:17 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 24 Oct 2011 06:56:17 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1319416027.54.0.54295917045.issue8828@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2N0jTcE692iYdFnF+WJsAQpFoJR20qU6EtHU7+RnyRsA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> MoveFileTransacted is only available under Vista or later. You should be able to use MoveFileEx for the same effect.

Nice.

> "The solution? Let's remember that metadata changes are atomic. Rename is such a case."
>

Hmmm.
Is he referring to the "standard" rename? The blog doesn't evoke a
specific function, but if it was the case, then why bother at all?

By the way:
"""
 - MoveFileEx() with MOVEFILE_REPLACE_EXISTING and
MOVEFILE_WRITE_THROUGH flags: not atomic (eg. "If the file is to be
moved to a different volume, the function simulates the move by using
the CopyFile and DeleteFile functions."), version >= Windows 2000
"""

There's exactly the same limitation with the POSIX version (except
that it'll fail with EXDEV instead of silently doing the copy+unlink).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Mon Oct 24 09:03:03 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 24 Oct 2011 07:03:03 +0000
Subject: [issue13018] dictobject.c: refleak
In-Reply-To: <1316530564.57.0.408350668852.issue13018@psf.upfronthosting.co.za>
Message-ID: <1319439783.17.0.137808431642.issue13018@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
keywords: +needs review, patch
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13018>
_______________________________________

From report at bugs.python.org  Mon Oct 24 09:03:53 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 24 Oct 2011 07:03:53 +0000
Subject: [issue13017] pyexpat.c: refleak
In-Reply-To: <1316530520.98.0.265221985232.issue13017@psf.upfronthosting.co.za>
Message-ID: <1319439833.53.0.0839659589956.issue13017@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
keywords: +after moratorium, needs review, patch
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13017>
_______________________________________

From report at bugs.python.org  Mon Oct 24 09:04:35 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 24 Oct 2011 07:04:35 +0000
Subject: [issue13016] selectmodule.c: refleak
In-Reply-To: <1316530474.09.0.885561459136.issue13016@psf.upfronthosting.co.za>
Message-ID: <1319439875.57.0.30246301205.issue13016@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
keywords: +needs review, patch
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13016>
_______________________________________

From report at bugs.python.org  Mon Oct 24 09:29:52 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 07:29:52 +0000
Subject: [issue11440] fix_callable should be dropped from lib2to3 / changed
In-Reply-To: <1299600488.07.0.0466070744973.issue11440@psf.upfronthosting.co.za>
Message-ID: <1319441392.71.0.922657105106.issue11440@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11440>
_______________________________________

From report at bugs.python.org  Mon Oct 24 09:33:55 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 07:33:55 +0000
Subject: [issue11440] fix_callable should be dropped from lib2to3 / changed
In-Reply-To: <1299600488.07.0.0466070744973.issue11440@psf.upfronthosting.co.za>
Message-ID: <1319441635.67.0.0172951287344.issue11440@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The decision should be left to the user.
IMHO, we could disable this automatic fixer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11440>
_______________________________________

From report at bugs.python.org  Mon Oct 24 09:35:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 24 Oct 2011 07:35:44 +0000
Subject: [issue11440] fix_callable should be dropped from lib2to3 / changed
In-Reply-To: <1299600488.07.0.0466070744973.issue11440@psf.upfronthosting.co.za>
Message-ID: <1319441744.98.0.13147641419.issue11440@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11440>
_______________________________________

From report at bugs.python.org  Mon Oct 24 09:36:38 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 07:36:38 +0000
Subject: [issue12501] callable(): remove/amend the deprecation warning in
	Python 2.7
In-Reply-To: <1309865750.34.0.541248470896.issue12501@psf.upfronthosting.co.za>
Message-ID: <1319441798.7.0.875318607808.issue12501@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12501>
_______________________________________

From report at bugs.python.org  Mon Oct 24 10:47:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 08:47:40 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <CAH_1eM2N0jTcE692iYdFnF+WJsAQpFoJR20qU6EtHU7+RnyRsA@mail.gmail.com>
Message-ID: <1319445814.3298.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > "The solution? Let's remember that metadata changes are atomic. Rename is such a case."
> >
> 
> Hmmm.
> Is he referring to the "standard" rename? The blog doesn't evoke a
> specific function, but if it was the case, then why bother at all?

Standard rename (MoveFile) fails when the target exists, and that's
AFAICT the whole problem with it. MoveFileEx allows to overwrite the
target with MOVEFILE_REPLACE_EXISTING.

> By the way:
> """
>  - MoveFileEx() with MOVEFILE_REPLACE_EXISTING and
> MOVEFILE_WRITE_THROUGH flags: not atomic (eg. "If the file is to be
> moved to a different volume, the function simulates the move by using
> the CopyFile and DeleteFile functions."), version >= Windows 2000
> """
> 
> There's exactly the same limitation with the POSIX version (except
> that it'll fail with EXDEV instead of silently doing the copy+unlink).

If you don't specify the MOVEFILE_COPY_ALLOWED flag, MoveFileEx also
fails. I don't understand what Victor was trying to say.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Mon Oct 24 11:14:59 2011
From: report at bugs.python.org (marco ghidinelli)
Date: Mon, 24 Oct 2011 09:14:59 +0000
Subject: [issue13254] maildir.items() broken
Message-ID: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>


New submission from marco ghidinelli <marcogh at gmail.com>:

since python 2.7.2 
maildir.items() doesn't return anything:

>>> from mailbox import Maildir
>>> x = Maildir('test')
>>> x.items()
[]

untils something was written on the maildir.

>>> x.add('bubu')
'1319447613.M259111P6097Q1.deeppurple'
>>> x.items()
[('1319447013.M913187P6096Q1.deeppurple', <rfc822.Message instance at 0x7f25f5b612d8>), ('1319447613.M259111P6097Q1.deeppurple', <rfc822.Message instance at 0x7f25f5b61680>)]

----------
components: Library (Lib)
messages: 146283
nosy: marco.ghidinelli
priority: normal
severity: normal
status: open
title: maildir.items() broken
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13254>
_______________________________________

From report at bugs.python.org  Mon Oct 24 11:32:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Oct 2011 09:32:09 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <E1RIGt1-0007F5-FK@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 221638ba5d2a by Mark Dickinson in branch 'default':
Issue #13248, issue #8540: Remove deprecated Context._clamp attribute from Decimal module.
http://hg.python.org/cpython/rev/221638ba5d2a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Mon Oct 24 11:33:52 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 24 Oct 2011 09:33:52 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1319448832.61.0.733040728746.issue8540@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

New changeset 221638ba5d2a by Mark Dickinson in branch 'default':
Issue #13248, issue #8540: Remove deprecated Context._clamp attribute from Decimal module.
http://hg.python.org/cpython/rev/221638ba5d2a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Mon Oct 24 11:38:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 09:38:20 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1319449100.12.0.370637032159.issue13254@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +r.david.murray
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13254>
_______________________________________

From report at bugs.python.org  Mon Oct 24 11:48:23 2011
From: report at bugs.python.org (marco ghidinelli)
Date: Mon, 24 Oct 2011 09:48:23 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1319449703.72.0.491520228755.issue13254@psf.upfronthosting.co.za>


marco ghidinelli <marcogh at gmail.com> added the comment:

i verified now, and the 2.7.1 version is ok, the bug is present since the 2.7.2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13254>
_______________________________________

From report at bugs.python.org  Mon Oct 24 11:57:53 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 24 Oct 2011 09:57:53 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1319450273.04.0.117603914694.issue13254@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13254>
_______________________________________

From report at bugs.python.org  Mon Oct 24 12:19:16 2011
From: report at bugs.python.org (marco ghidinelli)
Date: Mon, 24 Oct 2011 10:19:16 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1319451556.24.0.461781787302.issue13254@psf.upfronthosting.co.za>


marco ghidinelli <marcogh at gmail.com> added the comment:

3.1 is ok
3.2.2 is affected

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13254>
_______________________________________

From report at bugs.python.org  Mon Oct 24 12:32:45 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 10:32:45 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1319452365.04.0.51091383175.issue13248@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I missed these warnings in C modules.


*array*
  "fromstring" and "tostring" methods
*io* (like _pyio)
  argument "max_buffer_size" of BufferedWriter and BufferedRWPair
*sys*
  "sys.getcheckinterval" and "sys.setcheckinterval"


and some complaints from Objects/typeobject.c:

  "object.__init__() takes no parameters"
  "object.__new__() takes no parameters"
  "object.__format__ with a non-empty format string is deprecated"
  "Type %.100s defines tp_reserved (formerly tp_compare) but not "
    "tp_richcompare. Comparisons may not behave as intended."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Mon Oct 24 12:41:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 10:41:05 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1319452865.0.0.896828156254.issue13248@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> *array*
>   "fromstring" and "tostring" methods

I think these ones (and other well-known 2.x methods) should be kept to ease porting to 3.x.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Mon Oct 24 12:45:05 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 24 Oct 2011 10:45:05 +0000
Subject: [issue13252] new decumulate() function in itertools module
In-Reply-To: <1319409168.22.0.462760902888.issue13252@psf.upfronthosting.co.za>
Message-ID: <1319453105.57.0.717854970654.issue13252@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, looking at the code I realised what you're trying to get at is the idea of reporting the differences between values in a series, such that:

x = list(accumulate(seq))
assert x == list(accumulate(differences(x)))

I don't think the use cases are there to justify the addition (not every iterator we can think of should be a building block in itertools), but if such a thing were to be added, "differences" would convey the intention significantly better than the invented term "decumulate".

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13252>
_______________________________________

From report at bugs.python.org  Mon Oct 24 12:45:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 24 Oct 2011 10:45:41 +0000
Subject: [issue12296] Minor clarification in devguide
In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za>
Message-ID: <1319453141.94.0.50096160415.issue12296@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

PEP 387 explains the rules about backward compatibility.  The paragraph could just link to that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12296>
_______________________________________

From report at bugs.python.org  Mon Oct 24 12:48:07 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 10:48:07 +0000
Subject: [issue13255] wrong docstring for array.fromunicode
Message-ID: <1319453287.77.0.97617561601.issue13255@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The docstring should say "ustr.encode" instead of "ustr.decode".
The documentation page is correct.

>>> print(array.array.fromunicode.__doc__)
fromunicode(ustr)

Extends this array with data from the unicode string ustr.
The array must be a unicode type array; otherwise a ValueError
is raised.  Use array.frombytes(ustr.decode(...)) to
append Unicode data to an array of some other type.

----------
assignee: docs at python
components: Documentation
messages: 146292
nosy: docs at python, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: wrong docstring for array.fromunicode
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13255>
_______________________________________

From report at bugs.python.org  Mon Oct 24 13:17:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Oct 2011 11:17:58 +0000
Subject: [issue13255] wrong docstring for array.fromunicode
In-Reply-To: <1319453287.77.0.97617561601.issue13255@psf.upfronthosting.co.za>
Message-ID: <E1RIIXR-0007sj-Hc@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 451fa5782145 by Florent Xicluna in branch '3.2':
Issue #13255: wrong docstrings in array module.
http://hg.python.org/cpython/rev/451fa5782145

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13255>
_______________________________________

From report at bugs.python.org  Mon Oct 24 13:18:53 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 11:18:53 +0000
Subject: [issue13255] wrong docstrings in array module
In-Reply-To: <1319453287.77.0.97617561601.issue13255@psf.upfronthosting.co.za>
Message-ID: <1319455133.49.0.608777604238.issue13255@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
title: wrong docstring for array.fromunicode -> wrong docstrings in array module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13255>
_______________________________________

From report at bugs.python.org  Mon Oct 24 13:46:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Oct 2011 11:46:15 +0000
Subject: [issue13256] Document and test new socket options
Message-ID: <1319456775.82.0.463656498781.issue13256@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The commit c64216addd7f for issue #6560 added various socket option, but some of them are not well documented or tested.

Authentication:
 * SO_PASSCRED, SO_PEERCRED, LOCAL_PEERCRED
 * SCM_RIGHTS, SCM_CREDENTIALS, SCM_CREDS

SCTP:
 * socket.IPPROTO_SCTP is not mentioned in socket.socket() doc (but it's tested)

etc.

----------
messages: 146294
nosy: haypo
priority: normal
severity: normal
status: open
title: Document and test new socket options

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13256>
_______________________________________

From report at bugs.python.org  Mon Oct 24 13:48:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Oct 2011 11:48:22 +0000
Subject: [issue13256] Document and test new socket options
In-Reply-To: <1319456775.82.0.463656498781.issue13256@psf.upfronthosting.co.za>
Message-ID: <1319456902.18.0.504218571712.issue13256@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another issue: the "version added" tag is not used, it's not possible to know that socket.SO_PEERCRED was added in Python 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13256>
_______________________________________

From report at bugs.python.org  Mon Oct 24 14:21:51 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 24 Oct 2011 12:21:51 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1319458911.23.0.92907408001.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

FYI: In pythonv, the build_scripts functionality provides identical support for dotted callables to what ?ric proposed, while preserving existing functionality for ordinary script files. Thus:

scripts = demo1
  demo2 = amodule.main
  demo3 = apackage.asubpackage.main gui

copies demo1 (adjusting its shebang) and creates demo2 and demo3 from the dotted callables (using the appropriate shebang).

While working on this, I came up against a problem with build_scripts in virtual environments: if I install a project into virtual env 1, then scripts are built with shebangs pointing to that env. If I then install the same project into virtual env 2, then the scripts are not re-created, so they would be installed into virtual env 2 with shebangs referencing virtual env 1. One solution is to set the force flag for virtual environments, but then if you later install into the system Python, then files with wrong shebangs could be installed there. I think the force flag should default to True for build_scripts; the extra script build time would be negligible except in pathological cases. Do you agree?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Mon Oct 24 14:23:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Oct 2011 12:23:18 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <E1RIJYf-00072E-0P@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2184df0e0f89 by Nick Coghlan in branch '2.7':
Issue #13237: Rearrange subprocess module documentation to emphasise the convenience functions and commonly needed arguments
http://hg.python.org/cpython/rev/2184df0e0f89

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Mon Oct 24 14:35:36 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 24 Oct 2011 12:35:36 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1319459736.4.0.431583066353.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Re. the launcher changes, those improvements by Guy Rozendorn are welcome. I noticed some differences from the approach taken by Mark Hammond and Curt Hagenlocher in the PEP 397 implementation, which I ported to C:

The Ctrl-C is ignored by the PEP 397 launcher. AFAICT it's passed to the child process anyway by Windows. The ignoring prevents the default behaviour (premature termination of the launcher).

The PEP 397 launcher also duplicates the standard handles before creating the child process.

The PEP 397 launcher also associates the launcher and the child together using the Job API.

----------
nosy: +guyrozendorn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Mon Oct 24 14:42:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 24 Oct 2011 12:42:27 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319460147.4.0.30578803049.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Unfortunately, I don't think including implicit shlex.quote() calls is going to have the effect I was originally looking for:

>>> subprocess.call("du -hs ../py*", shell=True)
593M    ../py3k
577M    ../py3k_pristine
479M    ../python27
300M    ../python31
381M    ../python32
288K    ../python_swallowed_whole
0

>>> subprocess.call("du -hs {}".format(shlex.quote("../py*")), shell=True)
du: cannot access `../py*': No such file or directory
1

However, tinkering with this did provide some other "feels like using the shell" examples:

>>> subprocess.call("du -hs ~/devel", shell=True)
4.5G    /home/ncoghlan/devel
0

>>> subprocess.call(["du","-hs","~/devel"])
du: cannot access `~/devel': No such file or directory
1

(I'm using the existing subprocess calls rather than the proposed API, since I'm playing with this on the current hg tip without making any changes)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Mon Oct 24 14:54:31 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 24 Oct 2011 12:54:31 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319460871.28.0.524554245167.issue13237@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm reasonably happy with the changes I just checked in, but rather than doing multiple forward ports, my plan is to let them settle for a while, update them based on any feedback I get, then incorporate the final version into the 3.x series.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Mon Oct 24 15:16:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Oct 2011 13:16:24 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1319462184.15.0.0884044362268.issue13254@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm assigning this to myself so I don't lose it, but if someone wants to work on a patch please do.  It'll be a bit before I can look at it.

----------
assignee:  -> r.david.murray
priority: normal -> high
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13254>
_______________________________________

From report at bugs.python.org  Mon Oct 24 15:18:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Oct 2011 13:18:36 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1319462316.05.0.271146775366.issue13254@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since this is a regression I'm upping the priority further to release blocker, so that we don't put out another release with the regression still in it.

----------
nosy: +benjamin.peterson, georg.brandl
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13254>
_______________________________________

From report at bugs.python.org  Mon Oct 24 15:23:42 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 13:23:42 +0000
Subject: [issue2470] Need fixer for dl (removed) -> ctypes module
In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za>
Message-ID: <1319462622.33.0.906841420097.issue2470@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

for the RTLD_ constants, refer to issue #13226.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2470>
_______________________________________

From report at bugs.python.org  Mon Oct 24 17:33:04 2011
From: report at bugs.python.org (Tobias Oberstein)
Date: Mon, 24 Oct 2011 15:33:04 +0000
Subject: [issue13244] WebSocket schemes in urlparse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319470384.16.0.848797192701.issue13244@psf.upfronthosting.co.za>


Tobias Oberstein <tobias.oberstein at tavendo.de> added the comment:

ok, there was feedback on Hybi list:

http://www.ietf.org/mail-archive/web/hybi/current/msg09270.html

"""
    1. ws://example.com/something#somewhere
    2. ws://example.com/something#somewhere/
    3. ws://example.com/something#somewhere/foo
    4. ws://example.com/something?query=foo#bar

I think all of these are invalid. 
"""
Alexey Melnikov, Co-author of the WS spec.

And Julian Reschke:

http://www.ietf.org/mail-archive/web/hybi/current/msg09277.html

==

Thus, I would upload my comment:

"# must always be escaped, both in path and query components. Fragment components are not allowed. Thus, unescaped # can never appear in WS URL. Further, it must not be ignored, but the WS handshake failed."

And further: urlparse should raise an exception upon unescaped # within URLs from ws/wss schemes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Mon Oct 24 18:19:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 24 Oct 2011 16:19:33 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1319473173.66.0.0769780446884.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Spamlib-0.1.dist-info is in a directory on sys.path, so the error makes no sense to me.  Can you inspect the content of that directory?  (i.e os.listdir and file contents)  Also, if you can interrupt the test to get a Python or pdb shell, could you try this:

  >>> from packaging.database import Distribution
  >>> d = Distribution('path/to/Spamlib-0.1.dist-info')
  >>> d.metadata
  >>> d.list_distinfo_files()
  >>> d.list_installed_files()

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Oct 24 18:26:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 24 Oct 2011 16:26:08 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1319473568.47.0.365762176827.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> FYI: In pythonv, the build_scripts functionality provides identical support for dotted
> callables to what ?ric proposed, while preserving existing functionality for ordinary script
> files.

My current preference is to use only new-style generated scripts for the scripts field in the files section, and to let people use the data-files/resources system for old-style file scripts.

We?ll have to think about the shebang munging and decide if we keep it.  I think recommending that people use ?/usr/bin/env python? (or python3) and not doing anything to the shebang may be the best thing.

> While working on this, I came up against a problem with build_scripts in virtual environments:
This is also a bug in current distutils and distutils2 scripts.  Scripts should always be regenerated, as they depend on the running Python, not on other files.

----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Mon Oct 24 18:40:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 16:40:28 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1319474428.2.0.632209163038.issue8828@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I see that Sun/Oracle Java trusts MoveFileEx to do atomic renames:

  290           // atomic case
  291           if (atomicMove) {
  292               try {
  293                   MoveFileEx(sourcePath, targetPath, MOVEFILE_REPLACE_EXISTING);
  294               } catch (WindowsException x) {
  295                   if (x.lastError() == ERROR_NOT_SAME_DEVICE) {
  296                       throw new AtomicMoveNotSupportedException(
  297                           source.getPathForExceptionMessage(),
  298                           target.getPathForExceptionMessage(),
  299                           x.errorString());
  300                   }
  301                   x.rethrowAsIOException(source, target);
  302               }
  303               return;
  304           }

(from http://www.docjar.com/html/api/sun/nio/fs/WindowsFileCopy.java.html )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Mon Oct 24 18:45:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Oct 2011 16:45:33 +0000
Subject: [issue10332] Multiprocessing maxtasksperchild results in hang
In-Reply-To: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>
Message-ID: <E1RINeO-0000j5-7c@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3465a9b2d25c by Charles-Fran?ois Natali in branch '2.7':
Issue #10332: multiprocessing: fix a race condition when a Pool is closed
http://hg.python.org/cpython/rev/3465a9b2d25c

New changeset 52c98a729a71 by Charles-Fran?ois Natali in branch '3.2':
Issue #10332: multiprocessing: fix a race condition when a Pool is closed
http://hg.python.org/cpython/rev/52c98a729a71

New changeset c2cdabc44665 by Charles-Fran?ois Natali in branch 'default':
Issue #10332: multiprocessing: fix a race condition when a Pool is closed
http://hg.python.org/cpython/rev/c2cdabc44665

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10332>
_______________________________________

From report at bugs.python.org  Mon Oct 24 19:00:49 2011
From: report at bugs.python.org (Sjoerd de Vries)
Date: Mon, 24 Oct 2011 17:00:49 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1319475649.8.0.862930515877.issue12618@psf.upfronthosting.co.za>


Sjoerd de Vries <sjdv1982 at gmail.com> added the comment:

Hi ?ric,

There you go, adapted from http://effbot.org/librarybook/py-compile.htm :

############
# File: py-compile-example-1.py

import py_compile

# explicitly compile this module
py_compile.compile("py-compile-example-1.py","py-compile-example-1.pyc")

############

Also, I tested and this bug is present neither on 3.1 nor on 2.x

cheers
Sjoerd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Mon Oct 24 19:16:04 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 24 Oct 2011 17:16:04 +0000
Subject: [issue13215] multiprocessing Manager.connect() aggressively retries
	refused connections
In-Reply-To: <1319411101.71.0.604010251025.issue13215@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM10sMioFiOQa=B2f0W3hQ5PEoOrY=4euCLdR6O_Sw0VoA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

>  While a 20 second timeout may make sense for *unresponsive* servers,
> ECONNREFUSED probably indicates that the server is not listening on this port, so
> hammering it with 1,999 more connection attempts isn't going to help.

That's funny, I noticed this a couple days ago, and it also puzzled me...

> I'm not sure, but I think that would be for the case where you are spawning the
> server yourself and the child process takes time to start up.

That's also what I think.
But that's strange, since:
- this holds for every client/server communication (e.g. why not do
that for smtplib, telnetlib, etc. ?)
- it's against the classical connect() semantics
- some code may prefer failing immediately (instead of "hammering" the
remote host) if the remote server is down, or the address is
incorrect: it can still handle the ECONNREFUSED if it wants to retry,
with a custom retry timeout
I removed the retry code and run test_multiprocessing and
test_concurrent_futures in loop, and didn't see any failure (on
Linux), so I'd say we could probably remove that.
OTOH, I would feel bad if this broke someone's code (even though code
relying on the automatic retries is probably broken).
So I'm +1 on removing the retry logic altogether, unless of course
someone comes up with a good reason to keep it (I digged a little
through the logs to see when this was introduced, but apparently it
was there in the original import).
If we don't remove it, I agree we should at least reduce the timeout
and increase the period (an exponential backoff may be a bit
overkill).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13215>
_______________________________________

From report at bugs.python.org  Mon Oct 24 19:46:41 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 24 Oct 2011 17:46:41 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1319473568.47.0.365762176827.issue12394@psf.upfronthosting.co.za>
Message-ID: <1319478394.80352.YahooMailNeo@web25808.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> We?ll have to think about the shebang munging and decide if we keep it.? I think?

> recommending that people use ?/usr/bin/env python? (or python3) and not doing 
> anything to the shebang may be the best thing.

What about Windows support? Of course there is PEP 397 which brings shebang-line functionality to Windows, but that PEP has not yet been finalised. Without the existing shebang functionality, IMO there will be problems for Windows users with the??/usr/bin/env python??approach you suggest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Mon Oct 24 20:00:42 2011
From: report at bugs.python.org (Ariel)
Date: Mon, 24 Oct 2011 18:00:42 +0000
Subject: [issue10364] Color coding fails after running program.
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1319479242.83.0.831503407689.issue10364@psf.upfronthosting.co.za>


Ariel <arielbr10 at walla.com> added the comment:

Excuse me for budging in, I was having the same problem (both python 3.2 and 2.7, on both win XP and 7) without knowing the file extention is the cause.

Why doesn't IDLE editor save files with the .py extention unless specificly ordered to? The Save as dialoge window has a "type" drop-down menue. Maybe I'm missing some of the logic behind it?

----------
nosy: +Ariel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10364>
_______________________________________

From report at bugs.python.org  Mon Oct 24 20:01:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 18:01:43 +0000
Subject: [issue13256] Document and test new socket options
In-Reply-To: <1319456775.82.0.463656498781.issue13256@psf.upfronthosting.co.za>
Message-ID: <1319479303.32.0.416886202353.issue13256@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> docs at python
components: +Documentation, Tests
nosy: +docs at python
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13256>
_______________________________________

From report at bugs.python.org  Mon Oct 24 20:06:43 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 24 Oct 2011 18:06:43 +0000
Subject: [issue10332] Multiprocessing maxtasksperchild results in hang
In-Reply-To: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>
Message-ID: <1319479603.4.0.182209295631.issue10332@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

James, thanks for the report!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10332>
_______________________________________

From report at bugs.python.org  Mon Oct 24 20:33:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Oct 2011 18:33:33 +0000
Subject: [issue13018] dictobject.c: refleak
In-Reply-To: <1316530564.57.0.408350668852.issue13018@psf.upfronthosting.co.za>
Message-ID: <E1RIPKy-00038c-B7@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5d7164febff1 by Petri Lehtinen in branch '2.7':
Issue #13018: Fix reference leaks in error paths in dictobject.c.
http://hg.python.org/cpython/rev/5d7164febff1

New changeset df24a8b57148 by Petri Lehtinen in branch '3.2':
Issue #13018: Fix reference leaks in error paths in dictobject.c.
http://hg.python.org/cpython/rev/df24a8b57148

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13018>
_______________________________________

From report at bugs.python.org  Mon Oct 24 20:36:19 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 24 Oct 2011 18:36:19 +0000
Subject: [issue13018] dictobject.c: refleak
In-Reply-To: <1316530564.57.0.408350668852.issue13018@psf.upfronthosting.co.za>
Message-ID: <1319481379.26.0.502976795015.issue13018@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Thanks for the patch, fixed.

----------
keywords:  -needs review
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13018>
_______________________________________

From report at bugs.python.org  Mon Oct 24 20:50:20 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 24 Oct 2011 18:50:20 +0000
Subject: [issue13218] test_ssl failures on Ubuntu 11.10
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319482220.46.0.366052361783.issue13218@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Still investigating, but FTR, this isn't technically an Ubuntu issue as much as it is a Debian issue (and thus inherited by Ubuntu).  I can reproduce the failure in Python 3.3 on Debian Wheezy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Mon Oct 24 20:50:35 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 24 Oct 2011 18:50:35 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319482235.98.0.109599454034.issue13218@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
title: test_ssl failures on Ubuntu 11.10 -> test_ssl failures on Debian/Ubuntu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Mon Oct 24 21:16:51 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Oct 2011 19:16:51 +0000
Subject: [issue13257] Move importlib over to PEP 3151 exceptions
Message-ID: <1319483811.65.0.194402902365.issue13257@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Importlib uses the errno module explicitly for properly checking OSError for EEXIST and IOError for EACCES. Thanks to PEP 3151, however, neither check is needed since those exceptions correspond to FileExistsError and PermissionError, respectively.

As long as posix.mkdir() uses the new exceptions, the entire need for errno goes away for the module, eliminating one more module required for bootstrapping.

----------
assignee: brett.cannon
components: Library (Lib)
keywords: easy
messages: 146317
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Move importlib over to PEP 3151 exceptions
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13257>
_______________________________________

From report at bugs.python.org  Mon Oct 24 21:33:55 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 24 Oct 2011 19:33:55 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1319484835.12.0.765767440321.issue13193@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Hi Eli,
I cannot find the file/Distro:

find / -name *'dist-info' 2> /dev/null

/home/ci/cpython/Lib/packaging/tests/fake_dists/grammar-1.0a4.dist-info

/home/ci/cpython/Lib/packaging/tests/fake_dists/towel_stuff-0.1.dist-info

/home/ci/cpython/Lib/packaging/tests/fake_dists/babar-0.1.dist-info

/home/ci/cpython/Lib/packaging/tests/fake_dists/choxie-2.0.0.9.dist-info

/home/ci/cpython/.hg/store/data/_lib/packaging/tests/fake__dists/grammar-1.0a4.dist-info

/home/ci/cpython/.hg/store/data/_lib/packaging/tests/fake__dists/babar-0.1.dist-info

/home/ci/cpython/.hg/store/data/_lib/packaging/tests/fake__dists/towel__stuff-0.1.dist-info

/home/ci/cpython/.hg/store/data/_lib/packaging/tests/fake__dists/choxie-2.0.0.9.dist-info

Where should be the distro?

Cheers,

francis

----------
nosy: +francismb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Oct 24 21:38:12 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 24 Oct 2011 19:38:12 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1319485092.65.0.306454354927.issue13193@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

The changeset was:
$ hg tip
changeset:   73075:d4839fea4a5a
[...]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Oct 24 21:46:15 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 19:46:15 +0000
Subject: [issue13258] replace hasattr(obj, '__call__') with callable(obj)
Message-ID: <1319485575.06.0.0356181366596.issue13258@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

Now that callable() is back in 3.2, we may replace hasattr(obj, '__call__') with callable(obj).

The built-in function is easier to read and gives better performance than attribute lookup.


$ ./python -m timeit "hasattr(None, '__call__')"
100000 loops, best of 3: 4.09 usec per loop
$ ./python -m timeit "hasattr(str, '__call__')"
1000000 loops, best of 3: 1.3 usec per loop

$ ./python -m timeit "callable(None)"
1000000 loops, best of 3: 0.299 usec per loop
$ ./python -m timeit "callable(str)"
1000000 loops, best of 3: 0.369 usec per loop

----------
components: Library (Lib)
messages: 146320
nosy: flox
priority: normal
severity: normal
status: open
title: replace hasattr(obj, '__call__') with callable(obj)
type: performance
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13258>
_______________________________________

From report at bugs.python.org  Mon Oct 24 21:48:21 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 19:48:21 +0000
Subject: [issue13258] replace hasattr(obj, '__call__') with callable(obj)
In-Reply-To: <1319485575.06.0.0356181366596.issue13258@psf.upfronthosting.co.za>
Message-ID: <1319485701.36.0.507431164289.issue13258@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Proposed patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file23510/issue13258_callable.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13258>
_______________________________________

From report at bugs.python.org  Mon Oct 24 21:51:40 2011
From: report at bugs.python.org (Yuval Greenfield)
Date: Mon, 24 Oct 2011 19:51:40 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319485900.27.0.175540709121.issue13247@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

An example error with abspath and bytes input:

    >>> os.path.abspath('.')
    'C:\\Users\\yuv\\Desktop\\YuvDesktop\\\u05d0\u05d1\u05d2\u05d3\u05d4\u05d5'
    >>> os.path.abspath(b'.')
    b'C:\\Users\\yuv\\Desktop\\YuvDesktop\\??????'
    >>> os.listdir(os.path.abspath(b'.'))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: 'C:\\Users\\yuv\\Desktop\\YuvDesktop\\??????/*.*'
    >>>


I couldn't follow the implementation, I got stuck not being able to locate the definition for os.getcwdb so I couldn't join you for that part. Here's another possible solution:

    >>> win32api.GetFullPathName('.')
    'C:\\Users\\yuv\\Desktop\\YuvDesktop\\\u05d0\u05d1\u05d2\u05d3\u05d4\u05d5'
    >>> win32api.GetShortPathName(win32api.GetFullPathName('.'))
    'C:\\Users\\yuv\\Desktop\\YUVDES~1\\5F30~1'

The short path is ascii but the problem is not all windows file systems have 8.3 filenames [1]. So I think your suggestion is the best solution.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#short_vs._long_names

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Mon Oct 24 22:07:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 20:07:56 +0000
Subject: [issue13258] replace hasattr(obj, '__call__') with callable(obj)
In-Reply-To: <1319485575.06.0.0356181366596.issue13258@psf.upfronthosting.co.za>
Message-ID: <1319486876.47.0.650934104306.issue13258@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For packaging I'm not sure it's worth complicating backporting.

----------
nosy: +eric.araujo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13258>
_______________________________________

From report at bugs.python.org  Mon Oct 24 22:16:13 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 20:16:13 +0000
Subject: [issue13258] replace hasattr(obj, '__call__') with callable(obj)
In-Reply-To: <1319485575.06.0.0356181366596.issue13258@psf.upfronthosting.co.za>
Message-ID: <1319487373.51.0.853218107457.issue13258@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Updated with a special note for "packaging".

----------
Added file: http://bugs.python.org/file23511/issue13258_callable_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13258>
_______________________________________

From report at bugs.python.org  Mon Oct 24 23:35:02 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Oct 2011 21:35:02 +0000
Subject: [issue10364] IDLE: make .py default added extension on save
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1319492102.11.0.106822759902.issue10364@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am guessing that because the extension could be either .py or .pyw, the initial save does not add either but forces the user to type one or the other. I find this annoying too, so I am thinking about separating the choices and see if .py, .pyw, and maybe .txt can be automatically added if not written, while avoiding '.py.py', etc. Hence the change of issue title and type. (Note to self: make sure this is not a duplicate.)

----------
title: Color coding fails after running program. -> IDLE: make .py default added extension on save
type:  -> feature request
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10364>
_______________________________________

From report at bugs.python.org  Mon Oct 24 23:44:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Oct 2011 21:44:58 +0000
Subject: [issue13258] replace hasattr(obj, '__call__') with callable(obj)
In-Reply-To: <1319485575.06.0.0356181366596.issue13258@psf.upfronthosting.co.za>
Message-ID: <1319492698.23.0.640994259296.issue13258@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

callable() is not just faster, it's also "more correct": hasattr(obj, "__call__") doesn't call base classes. See callable() of the six module:


def callable(obj):
  return any("__call__" in klass.__dict__ for klass in type(obj).__mro__)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13258>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:15:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Oct 2011 22:15:05 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1319494505.66.0.770093049917.issue8036@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This came up on python-list with
os.spawnl (os.P_NOWAIT, r"c:\windows\notepad.exe")
Tim Golden confirmed crash with Win7 on 2.7.?
I did same with 3.2.2 in both interpreter and from IDLE (IDLE hangs and then restarts after closing the 'pythonw has stopped' error message box).
Above apparently works in XP, at least with Py2.2.

----------
nosy: +loewis, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:18:39 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 Oct 2011 22:18:39 +0000
Subject: [issue13258] replace hasattr(obj, '__call__') with callable(obj)
In-Reply-To: <1319485575.06.0.0356181366596.issue13258@psf.upfronthosting.co.za>
Message-ID: <1319494719.51.0.332026336599.issue13258@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

We have so many alternatives, it's funny ...


def callable(obj):
    return hasattr(obj, '__call__') or hasattr(obj, '__bases__')

def callable(obj):
    return isinstance(obj, collections.abc.Callable)

def callable(obj):
    return hasattr(obj, '__call__') or type(obj) == types.ClassType

def callable(obj):
    return any("__call__" in klass.__dict__
               for klass in type(obj).__mro__)

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13258>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:20:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Oct 2011 22:20:04 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1319494804.32.0.129496980472.issue8036@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:21:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Oct 2011 22:21:12 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1319494872.96.0.525074998666.issue8036@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@nvetoshkin: Can you please also write tests (in Lib/test/test_os.py) for your patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:23:54 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 24 Oct 2011 22:23:54 +0000
Subject: [issue13258] replace hasattr(obj, '__call__') with callable(obj)
In-Reply-To: <1319485575.06.0.0356181366596.issue13258@psf.upfronthosting.co.za>
Message-ID: <1319495034.27.0.723220550723.issue13258@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Is it actually appropiate to commit this to 3.2?. I am neutral to it, just asking.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13258>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:25:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Oct 2011 22:25:56 +0000
Subject: [issue13258] replace hasattr(obj, '__call__') with callable(obj)
In-Reply-To: <1319485575.06.0.0356181366596.issue13258@psf.upfronthosting.co.za>
Message-ID: <1319495156.79.0.229200735076.issue13258@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Is it actually appropiate to commit this to 3.2?

If it fixes a bug, the fix should be backported to 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13258>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:26:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Oct 2011 22:26:40 +0000
Subject: [issue13232] Logging: Unicode Error
In-Reply-To: <1319121800.04.0.366773580653.issue13232@psf.upfronthosting.co.za>
Message-ID: <E1RISyZ-0007cY-6O@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4bb1dc4e2cec by Vinay Sajip in branch '2.7':
Closes #13232: Handle multiple encodings in exception logging.
http://hg.python.org/cpython/rev/4bb1dc4e2cec

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13232>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:27:41 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 24 Oct 2011 22:27:41 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1319495261.02.0.937855884137.issue13193@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Spamlib-0.1.dist-info is in a directory on sys.path, so the error makes no sense to me.  Can you inspect the content of that directory?  (i.e os.listdir and file contents)  Also, if you can interrupt the test to get a Python or pdb shell, could you try this:
> 
>   >>> from packaging.database import Distribution
>   >>> d = Distribution('path/to/Spamlib-0.1.dist-info')
>   >>> d.metadata
>   >>> d.list_distinfo_files()
>   >>> d.list_installed_files()

(Pdb) p install_dir
'c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b'

(Pdb) from packaging.database import Distribution
(Pdb) _d = Distribution(os.path.join(install_dir, "Spamlib-0.1.dist-info"))
(Pdb) p _d
<Distribution 'Spamlib' 0.1 at 'c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b\\Spamlib-0.1.dist-info'>

(Pdb) p _d.metadata
<packaging.metadata.Metadata object at 0x0351C118>

(Pdb) p dict(_d.metadata.items())
{'Name': 'Spamlib', 'License': 'UNKNOWN', 'Author': 'UNKNOWN', 'Metadata-Version': '1.0',
 'Home-page': 'UNKNOWN', 'Summary': 'UNKNOWN', 'Platform': [], 'Version': '0.1',
 'Keywords': [''], 'Author-email': 'UNKNOWN', 'Description': 'UNKNOWN'}

(Pdb) p list(_d.list_distinfo_files())
['c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b\\Spamlib-0.1.dist-info\\METADATA',
 'c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b\\Spamlib-0.1.dist-info\\INSTALLER',
 'c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b\\Spamlib-0.1.dist-info\\REQUESTED',
 'c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b\\Spamlib-0.1.dist-info\\RESOURCES',
 'c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b\\Spamlib-0.1.dist-info\\RECORD']

(Pdb) p list(_d.list_installed_files())
[('c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmpo8yw3_\\spamd', 'd13e6156ce78919a981e424b2fdcd974', '15'),
 ('c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b\\Spamlib-0.1.dist-info\\METADATA', '8c9f474663f774563ded42983eb22447', '182'),
 ('c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b\\Spamlib-0.1.dist-info\\INSTALLER', '44e3fde05f3f537ed85831969acf396d', '9'),
 ('c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b\\Spamlib-0.1.dist-info\\REQUESTED', 'd41d8cd98f00b204e9800998ecf8427e', '0'),
 ('c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b\\Spamlib-0.1.dist-info\\RESOURCES', '1c5aec043865966e17b1044e20087b9d', '68'),
 ('c:\\users\\nadeem\\appdata\\local\\temp\\tmpe96yhv\\tmp9ga04b\\Spamlib-0.1.dist-info\\RECORD', '', '')]

==== File contents:

spamd [no EOL]:
    # Python script

METADATA:
    Metadata-Version: 1.0
    Name: Spamlib
    Version: 0.1
    Summary: UNKNOWN
    Description: UNKNOWN
    Keywords: 
    Home-page: UNKNOWN
    Author: UNKNOWN
    Author-email: UNKNOWN
    License: UNKNOWN

INSTALLER [no EOL]:
    distutils

REQUESTED is empty

RESOURCES:
    spamd,c:\users\nadeem\appdata\local\temp\tmpe96yhv\tmpo8yw3_\spamd

RECORD:
    c:\users\nadeem\appdata\local\temp\tmpe96yhv\tmpo8yw3_\spamd,d13e6156ce78919a981e424b2fdcd974,15
    c:\users\nadeem\appdata\local\temp\tmpe96yhv\tmp9ga04b\Spamlib-0.1.dist-info\METADATA,8c9f474663f774563ded42983eb22447,182
    c:\users\nadeem\appdata\local\temp\tmpe96yhv\tmp9ga04b\Spamlib-0.1.dist-info\INSTALLER,44e3fde05f3f537ed85831969acf396d,9
    c:\users\nadeem\appdata\local\temp\tmpe96yhv\tmp9ga04b\Spamlib-0.1.dist-info\REQUESTED,d41d8cd98f00b204e9800998ecf8427e,0
    c:\users\nadeem\appdata\local\temp\tmpe96yhv\tmp9ga04b\Spamlib-0.1.dist-info\RESOURCES,1c5aec043865966e17b1044e20087b9d,68
    c:\users\nadeem\appdata\local\temp\tmpe96yhv\tmp9ga04b\Spamlib-0.1.dist-info\RECORD,,

====

> Where should be the distro?

You won't find it in the hg repository - it gets created by the test, and
then deleted afterwards.

> The changeset was:
> $ hg tip
> changeset:   73075:d4839fea4a5a
> [...]

That's not possible - these failures have been around for over a week now,
and that changeset was only committed yesterday.

>From running the tests locally, it looks like test_resources was failing on
Windows since it was first introduced in 1f3459b08298. This didn't show up so
clearly on the buildbots because the build was broken at the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:46:42 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 24 Oct 2011 22:46:42 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319496402.43.0.498193384366.issue13237@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee: docs at python -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:49:10 2011
From: report at bugs.python.org (Arkadiusz Wahlig)
Date: Mon, 24 Oct 2011 22:49:10 +0000
Subject: [issue13259] __bytes__ not documented
Message-ID: <1319496550.21.0.905326658417.issue13259@psf.upfronthosting.co.za>


New submission from Arkadiusz Wahlig <arkadiusz.wahlig at gmail.com>:

It looks like Python 3 supports the __bytes__ magic method (called by bytes(obj)). However, it's not documented anywhere.

Also, I could not find any reference to BDFL accepting it but it looks like it got in anyway.

Here are some posts back from 2007 where he argues against it:
http://mail.python.org/pipermail/python-3000/2007-August/009375.html

----------
assignee: docs at python
components: Documentation
messages: 146334
nosy: docs at python, yak
priority: normal
severity: normal
status: open
title: __bytes__ not documented
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13259>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:56:45 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 24 Oct 2011 22:56:45 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1319495261.02.0.937855884137.issue13193@psf.upfronthosting.co.za>
Message-ID: <4EA5ED7A.9070106@email.de>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

>
>> Where should be the distro?
>
> You won't find it in the hg repository - it gets created by the test, and
> then deleted afterwards.

Thanks for the info

>
>> The changeset was:
>> $ hg tip
>> changeset:   73075:d4839fea4a5a
>> [...]
>
> That's not possible - these failures have been around for over a week now,
> and that changeset was only committed yesterday.
>

Thanks again, next time I'll search the exact start point of failure in 
the repo. I've just put the ref to MY actual tip ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Tue Oct 25 00:58:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Oct 2011 22:58:09 +0000
Subject: [issue13259] __bytes__ not documented
In-Reply-To: <1319496550.21.0.905326658417.issue13259@psf.upfronthosting.co.za>
Message-ID: <1319497089.61.0.0246081291984.issue13259@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed. I didn't even remember we had that. There are tests, however, in Lib/test/test_bytes.py.
This was added in issue #2415, by the way.

----------
nosy: +pitrou
stage:  -> needs patch
versions:  -Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13259>
_______________________________________

From report at bugs.python.org  Tue Oct 25 01:17:10 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 24 Oct 2011 23:17:10 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319498230.79.0.234450478002.issue13218@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

TL;DR: Let's rip out the false assumption that an SSLv23 client cannot connect to an SSLv3/TLSv1 server.

I now believe this is simply an erroneous assumption on the part of the Python test suite, namely that SSLv23 method clients cannot connect to SSLv3 or TLSv1 servers.  Here is an excerpt from openssl's CHANGES file:


 Changes between 0.9.7g and 0.9.7h  [11 Oct 2005]
...

  *) Change the client implementation for SSLv23_method() and
     SSLv23_client_method() so that is uses the SSL 3.0/TLS 1.0
     Client Hello message format if the SSL_OP_NO_SSLv2 option is set.
     (Previously, the SSL 2.0 backwards compatible Client Hello
     message format would be used even with SSL_OP_NO_SSLv2.)
     [Bodo Moeller]

It looks like it's been this way for a long time too.  What may have changed recently on Debian/Ubuntu though is that, as of Ubuntu version 1.0.0d-2ubuntu1 (in Ubuntu 11.04), we now use the no-ssl configuration option to disable SSLv2.  My guess is that "the SSL_OP_NO_SSLv2 option" gets set by this configuration option, which is what switches the client hello to use SSLv3/TLSv1 format, thus enabling such connections.  I'm not entirely sure which Debian version of the package this got changed in, but it certainly works the same way on Wheezy as it does in Oneiric.

It's probably too difficult, and not really Python's responsibility, to determine whether SSL_OP_NO_SSLv2 is set.  Rather, I think the test is simply bogus and should be disabled or removed.  Antoine implies as such in 

http://bugs.python.org/issue13218#msg145912

A couple of other things: it is not true that Ubuntu (or Debian for that matter) is changing the semantics of a library here.  It's simply using a supported upstream configuration option to disable SSLv2, and the openssl library itself changes the semantics of client/server connection success based on that.

Also, I think @skip_if_broken_ubuntu_ssl is both a misnomer (since all that behavior is inherited from Debian) and besides, it's useless now since on Debian/Ubuntu, ssl.PROTOCOL_SSLv2 will never be defined, at least with modernish versions of both OS's.  But I guess ripping that out is a task for a different bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Tue Oct 25 01:33:14 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 24 Oct 2011 23:33:14 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319499194.97.0.39053741209.issue13234@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

I'd also like to point out that Unicode path is handled correctly in both 2.7.x
and 3.x:

    Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win
    32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import os
    >>> os.listdir(u'\\\\?\\D:\\Temp\\tempdir')
    [u'sub1', u'test1.txt']
    >>> os.listdir('\\\\?\\D:\\Temp\\tempdir')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    WindowsError: [Error 123] The filename, directory name, or volume label syntax i
    s incorrect: '\\\\?\\D:\\Temp\\tempdir/*.*'

    Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)] on win
    32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import os
    >>> os.listdir('\\\\?\\D:\\Temp\\tempdir')
    ['sub1', 'test1.txt']
    >>> os.listdir(b'\\\\?\\D:\\Temp\\tempdir')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    WindowsError: [Error 123] The filename, directory name, or volume label syntax i
    s incorrect: '\\\\?\\D:\\Temp\\tempdir/*.*'

The problem only lies in the code handling narrow string paths. If you look at
(py33) posixmodule.c:2545-6, the bare path is appended with L"\\*.*". Whereas
in the narrow string case, posixmodule.c:2625-6, the bare path is appended with
"/*.*", instead.

To be consistent, we should use '\\'.

----------
Added file: http://bugs.python.org/file23512/issue13234_py33.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 01:34:19 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 24 Oct 2011 23:34:19 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319499259.16.0.52450869223.issue13234@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

There are also several other edge cases to be taken care of:

    Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win
    32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import os
    >>> os.listdir(r'\\?\C:\Python27/')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    WindowsError: [Error 123] The filename, directory name, or volume label syntax i
    s incorrect: '\\\\?\\C:\\Python27/*.*'
    >>> os.listdir(r'\\?\C:/Python27\Lib')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    WindowsError: [Error 3] The system cannot find the path specified: '\\\\?\\C:/Py
    thon27\\Lib/*.*'

----------
Added file: http://bugs.python.org/file23513/issue13234_py33_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 01:41:40 2011
From: report at bugs.python.org (Alexander Myodov)
Date: Mon, 24 Oct 2011 23:41:40 +0000
Subject: [issue13260] distutils and cross-compiling the extensions
Message-ID: <1319499699.99.0.666933133396.issue13260@psf.upfronthosting.co.za>


New submission from Alexander Myodov <amyodov at gmail.com>:

I was recently trying to cross-compile several extensions (host: Linux, target: Win32) using mingw-gcc, and noticed that there is quite a little amount of changes needed to distutils code to at least make proper win32-compabible modules.

Some of them require pretty noticeable functionality changes to distutils (like, adding a new option) thus they are unlikely a target for 2.7 anymore (though with some luck, any person who wants to follow my way and do cross-compilation, may just subclass the existing code). But some others are obvious bugs, and their fixes may still be useful for users stuck at 2.7.

1. (This is dubious but still is related to the problem, and was required to build some of the modules). "--include-dirs" and "--library-dirs" options to build_ext command support multiple paths separated by os.pathsep. For some reason (which I may be unaware of) "--libraries" option doesn't. A tiny fix just adds this support.

2. (more obvious issue) get_msvcr() function in distutils/cygwincompiler.py tries to guess the C runtime library which the target extension should link to. To do that, it tests the Python where the setup.py is *running* for what library it was linked to. But when the compilation target is Win32 but the compilation host is Linux, the hosts's Python won't contain such information. In this case, this function will return None. The result then gets assigned to self.dll_libraries (in an instance of CygwinCCompiler or Mingw32CCompiler), and gets used in a context which implies it is always an iterable (libraries.extend(self.dll_libraries)).

These changes, together with altering or subclassing Mingw32CCompiler to use a different compiler name (like, "i586-mingw32msvc-gcc" instead of "gcc"), make it possible to cross-compile a number of extensions which were non-compileable before.

----------
assignee: tarek
components: Distutils
files: distutils.patch
keywords: patch
messages: 146340
nosy: amyodov, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils and cross-compiling the extensions
versions: Python 2.7
Added file: http://bugs.python.org/file23514/distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13260>
_______________________________________

From report at bugs.python.org  Tue Oct 25 02:00:41 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 25 Oct 2011 00:00:41 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319500841.03.0.363496414994.issue13234@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Additionally, there might be issues in other APIs when handling with extended path lengths:

D:\Temp\tempdir>dir
 Volume in drive D is Data
 Volume Serial Number is 7E3D-EC81

 Directory of D:\Temp\tempdir

10/24/2011  04:22 PM    <DIR>          .
10/24/2011  04:22 PM    <DIR>          ..
10/24/2011  04:28 PM    <DIR>          AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
10/24/2011  01:31 PM    <DIR>          sub1
10/24/2011  03:39 PM               262 test1.txt
               1 File(s)            262 bytes
               4 Dir(s)  244,483,321,856 bytes free

D:\Temp\tempdir>cd AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA

D:\Temp\tempdir\AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAA>dir
 Volume in drive D is Data
 Volume Serial Number is 7E3D-EC81

 Directory of D:\Temp\tempdir\AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAA

10/24/2011  04:28 PM    <DIR>          .
10/24/2011  04:28 PM    <DIR>          ..
10/24/2011  04:14 PM                 0 1234567.txt
10/24/2011  04:28 PM    <DIR>          BBBBBBBBBBBBB
               1 File(s)              0 bytes
               3 Dir(s)  244,483,321,856 bytes free

Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> subdir = 'B'*13
>>> os.path.isdir(subdir)
False
>>> os.getcwd()
'D:\\Temp\\tempdir\\AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA'
>>> subdir_abs = os.path.join(os.getcwd(), subdir)
>>> os.path.isdir(subdir)
False
>>> subdir_ext = r'\\?\%s' % subdir_abs
>>> os.path.isdir(subdir_ext)
True

In the above example, perhaps a ValueError('path too long') is better than returning False?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 06:07:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Oct 2011 04:07:23 +0000
Subject: [issue13259] __bytes__ not documented
In-Reply-To: <1319496550.21.0.905326658417.issue13259@psf.upfronthosting.co.za>
Message-ID: <E1RIYIH-0007d0-IH@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 199d9e3fe0ce by Benjamin Peterson in branch '3.2':
document __bytes__ special method (closes #13259)
http://hg.python.org/cpython/rev/199d9e3fe0ce

New changeset 4128de054937 by Benjamin Peterson in branch 'default':
merge 3.2 (#13259)
http://hg.python.org/cpython/rev/4128de054937

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13259>
_______________________________________

From report at bugs.python.org  Tue Oct 25 07:33:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Oct 2011 05:33:27 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1319520807.31.0.0648529062481.issue3982@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Tue Oct 25 08:23:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Oct 2011 06:23:55 +0000
Subject: [issue13251] Update string description in datamodel.rst
In-Reply-To: <1319408560.2.0.695201505258.issue13251@psf.upfronthosting.co.za>
Message-ID: <E1RIaQQ-0000aL-84@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 11d18ebb2dd1 by Ezio Melotti in branch 'default':
#13251: update string description in datamodel.rst.
http://hg.python.org/cpython/rev/11d18ebb2dd1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13251>
_______________________________________

From report at bugs.python.org  Tue Oct 25 08:24:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Oct 2011 06:24:32 +0000
Subject: [issue13251] Update string description in datamodel.rst
In-Reply-To: <1319408560.2.0.695201505258.issue13251@psf.upfronthosting.co.za>
Message-ID: <1319523872.55.0.88806517394.issue13251@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13251>
_______________________________________

From report at bugs.python.org  Tue Oct 25 08:36:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Oct 2011 06:36:08 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1319524568.62.0.87384476882.issue13248@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Maybe a 2to3 fixer to convert the names should be added?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Tue Oct 25 10:52:26 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 25 Oct 2011 08:52:26 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319532746.52.0.893489260366.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Considering this further, I've realised that the idea of implicit quoting for this style of helper function is misguided on another level - the parameters to be interpolated may not even be strings yet, so attempting to quote them would fail:

>>> subprocess.call("exit {}".format(1), shell=True)
1
>>> shlex.quote(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ncoghlan/devel/py3k/Lib/shlex.py", line 285, in quote
    if _find_unsafe(s) is None:
TypeError: expected string or buffer

I'll note that none of these problems will be unique to the new convenience API - they're all a general reflection of the impedance mismatch between typical shell interfaces and filenames that can contain spaces.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Tue Oct 25 10:54:37 2011
From: report at bugs.python.org (Manuel de la Pena)
Date: Tue, 25 Oct 2011 08:54:37 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319532877.35.0.60620094953.issue13234@psf.upfronthosting.co.za>


Manuel de la Pena <manuel at canonical.com> added the comment:

Indeed, in our code we had to write a number of wrappers around the os calls to be able to work with long path on Windows. At the moment working with long paths on windows and python is broken in a number of places and is a PITA to work with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 11:37:07 2011
From: report at bugs.python.org (Elijah Merkin)
Date: Tue, 25 Oct 2011 09:37:07 +0000
Subject: [issue13261] time.clock () has very low resolution on Linux
Message-ID: <1319535427.57.0.472664899853.issue13261@psf.upfronthosting.co.za>


New submission from Elijah Merkin <elm at transas.com>:

time.clock () has very poor time resolution on Linux (tested on Ubuntu 11.04).

The result of call to clock () changes once per several seconds. On the other side, on Windows it provides very good resolution.

Here is a doctest that fails on Linux:
"""
 >>> from time import sleep
 >>> prev = clock ()
 >>> res = True
 >>> for i in xrange(10):
 ...     sleep(0.15)
 ...     next = clock ()
 ...     res = res and (next - prev) > 0.1
 ...     prev = next
 >>> print res
 True
"""

Currently on Linux I am using a workaround that is attached to the issue.

----------
components: None
files: monotime_unix.py
messages: 146347
nosy: ellioh
priority: normal
severity: normal
status: open
title: time.clock () has very low resolution on Linux
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file23515/monotime_unix.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13261>
_______________________________________

From report at bugs.python.org  Tue Oct 25 11:39:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Oct 2011 09:39:27 +0000
Subject: [issue13261] time.clock () has very low resolution on Linux
In-Reply-To: <1319535427.57.0.472664899853.issue13261@psf.upfronthosting.co.za>
Message-ID: <1319535567.39.0.83722606328.issue13261@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is a duplicate of the issue #10278.

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13261>
_______________________________________

From report at bugs.python.org  Tue Oct 25 11:40:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Oct 2011 09:40:56 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1319535656.47.0.923136828921.issue10278@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The issue #13261 has been marked as a duplicate of this issue. Copy of msg146347:
-------------
time.clock () has very poor time resolution on Linux (tested on Ubuntu 11.04).

The result of call to clock () changes once per several seconds. On the other side, on Windows it provides very good resolution.

Here is a doctest that fails on Linux:
"""
 >>> from time import sleep
 >>> prev = clock ()
 >>> res = True
 >>> for i in xrange(10):
 ...     sleep(0.15)
 ...     next = clock ()
 ...     res = res and (next - prev) > 0.1
 ...     prev = next
 >>> print res
 True
"""

Currently on Linux I am using a workaround that is attached to the issue.
-------------

The issue has also a script:
http://bugs.python.org/file23515/monotime_unix.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Tue Oct 25 11:47:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Oct 2011 09:47:25 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319536045.12.0.943874631015.issue13234@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch. Is there a reason you don't use shutil.rmtree in tearDown()?
I don't know if it's our business to convert forward slashes passed by the user. Also, general support for extended paths is another can of worms ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 11:51:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Oct 2011 09:51:39 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1319536299.42.0.945255558236.issue10278@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

CLOCK_MONOTONIC, CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID are optional according to POSIX, which only mandates CLOCK_REALTIME. You should mention it in the docs.

You might also want to export clock_getres():
http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Tue Oct 25 11:56:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Oct 2011 09:56:57 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319498230.79.0.234450478002.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319536368.15328.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It looks like it's been this way for a long time too.

But tests have always passed here using OpenSSL 1.0.0.

> It's probably too difficult, and not really Python's responsibility,
> to determine whether SSL_OP_NO_SSLv2 is set.

See http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.options

> Rather, I think the test is simply bogus and should be disabled or
> removed.

I think it would be good to keep a simplified/minimal (and, of course,
working :-)) version of these tests.
Patches welcome, anyway. I can't really test with Debian's OpenSSL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Tue Oct 25 12:12:35 2011
From: report at bugs.python.org (Manuel de la Pena)
Date: Tue, 25 Oct 2011 10:12:35 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319537555.09.0.475039078581.issue13234@psf.upfronthosting.co.za>


Manuel de la Pena <manuel at canonical.com> added the comment:

In case of my patch (I don't know about santa4nt case) I did not use shutil.remove because it was not used in the other tests and I wanted to be consistent and not add a new import. Certainly if there is not an issue with that we should use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 12:22:14 2011
From: report at bugs.python.org (Aivar Annamaa)
Date: Tue, 25 Oct 2011 10:22:14 +0000
Subject: [issue13262] IDLE opens partially hidden
Message-ID: <1319538134.39.0.210129529894.issue13262@psf.upfronthosting.co.za>


New submission from Aivar Annamaa <aivar.annamaa at gmail.com>:

When IDLE opens in Windows 7, its bottom edge will be hidden behind taskbar. It should position itself so that it's fully visible.

----------
components: IDLE
messages: 146354
nosy: Aivar.Annamaa
priority: normal
severity: normal
status: open
title: IDLE opens partially hidden
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13262>
_______________________________________

From report at bugs.python.org  Tue Oct 25 13:07:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Oct 2011 11:07:25 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <E1RIeqm-0006rH-7m@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 35e4b7c4bafa by Victor Stinner in branch 'default':
Close #10278: Add clock_getres(), clock_gettime() and CLOCK_xxx constants to
http://hg.python.org/cpython/rev/35e4b7c4bafa

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Tue Oct 25 13:28:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Oct 2011 11:28:22 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1319542102.4.0.630134203876.issue10278@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I closed maybe this issue too quickly. My commit doesn't solve the initial issue: Python doesn't provide a portable "wallclock" function.

wallclock.patch should be updated to use:

 - time.clock() on Windows (use QueryPerformanceCounter)
 - or time.clock_gettime(CLOCK_MONOTONIC_RAW) if available
 - or time.clock_gettime(CLOCK_MONOTONIC) if available
 - or time.time() (which is usually gettimeofday())

Pseudo-code:

wallclock = None
if hasattr(time, 'clock_gettime') and hasattr(time, 'CLOCK_MONOTONIC_RAW'):
  # I understood that CLOCK_MONOTONIC_RAW is more reliable
  # than CLOCK_MONOTONIC, because CLOCK_MONOTONIC may be adjusted
  # by NTP. I don't know if it's correct.
  def wallclock():
    return time.clock_gettime(CLOCK_MONOTONIC_RAW)

elif hasattr(time, 'clock_gettime') and hasattr(time, 'CLOCK_MONOTONIC'):
  def wallclock():
    return time.clock_gettime(CLOCK_MONOTONIC)

elif os.name == 'nt':
  # define a new function to be able to set its docstring
  def wallclock():
    return time.clock()

else:
  def wallclock():
     return time.time()
if wallclock is not None:
   wallclock.__doc__ = 'monotonic time'
else:
   del wallclock

wallclock() doc should also explain that time.time() may be adjusted by NTP or manually by the administrator.

--

By the way, it would be nice to expose the precision of time.clock(): it's 1/divisor or 1/CLOCKS_PER_SEC on Windows, 1/CLOCKS_PER_SEC on UNIX.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Tue Oct 25 13:31:03 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 25 Oct 2011 11:31:03 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319536368.15328.2.camel@localhost.localdomain>
Message-ID: <20111025073050.174628cb@limelight.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Oct 25, 2011, at 09:56 AM, Antoine Pitrou wrote:

>
>Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> It looks like it's been this way for a long time too.
>
>But tests have always passed here using OpenSSL 1.0.0.

Right, sorry, what I meant was this particular behavior (switching to SSLv3
client hello when SSLv2 is disabled) appears to have been in upstream openssl
since about 2005.  What's changed recently is that instead of patching openssl
to disable SSLv2 (and thereby not triggering the client hello switch), Debian
has started to use the no-ssl Configure option, which is what probably started
allowing this test to unexpectedly succeed.

>> It's probably too difficult, and not really Python's responsibility,
>> to determine whether SSL_OP_NO_SSLv2 is set.
>
>See http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.options

Interesting, thanks for the pointer.

>> Rather, I think the test is simply bogus and should be disabled or
>> removed.
>
>I think it would be good to keep a simplified/minimal (and, of course,
>working :-)) version of these tests.
>Patches welcome, anyway. I can't really test with Debian's OpenSSL.

I'll work up a patch.

-Barry

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Tue Oct 25 13:34:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Oct 2011 11:34:12 +0000
Subject: [issue13226] Expose RTLD_* constants in the posix module
In-Reply-To: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za>
Message-ID: <E1RIfGh-0000ue-BE@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c75427c0da06 by Victor Stinner in branch 'default':
Issue #13226: Add RTLD_xxx constants to the os module. These constants can by
http://hg.python.org/cpython/rev/c75427c0da06

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13226>
_______________________________________

From report at bugs.python.org  Tue Oct 25 13:34:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Oct 2011 11:34:21 +0000
Subject: [issue13226] Expose RTLD_* constants in the posix module
In-Reply-To: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za>
Message-ID: <1319542461.31.0.0517245280659.issue13226@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13226>
_______________________________________

From report at bugs.python.org  Tue Oct 25 13:45:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Oct 2011 11:45:56 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <E1RIfS2-000276-LG@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6159311f0f44 by Victor Stinner in branch 'default':
Issue #12619: Expose socket.SO_BINDTODEVICE constant
http://hg.python.org/cpython/rev/6159311f0f44

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Tue Oct 25 13:46:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Oct 2011 11:46:42 +0000
Subject: [issue13256] Document and test new socket options
In-Reply-To: <1319456775.82.0.463656498781.issue13256@psf.upfronthosting.co.za>
Message-ID: <1319543202.7.0.620966926723.issue13256@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

For #12619, I added socket.SO_BINDTODEVICE constant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13256>
_______________________________________

From report at bugs.python.org  Tue Oct 25 14:00:51 2011
From: report at bugs.python.org (Lucas Sinclair)
Date: Tue, 25 Oct 2011 12:00:51 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1319544051.2.0.757892305489.issue9750@psf.upfronthosting.co.za>


Lucas Sinclair <blastocyst at mac.com> added the comment:

I just encountered this issue today.

So, it's been several months, will the patch be merged into the master branch ? Or will this never be fixed ?

----------
nosy: +xapple

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Tue Oct 25 14:06:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Oct 2011 12:06:17 +0000
Subject: [issue13263] Group some os functions in submodules
Message-ID: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

In Python 3.3 the os module gained a few new functions and constants:

Python 3.2.2+ (3.2:58a75eeb5c8e, Sep 29 2011, 02:11:05) 
>>> import os; len(dir(os))
232

Python 3.3.0a0 (default:a50f080c22ca+, Oct 25 2011, 09:56:01) 
>>> import os; len(dir(os))
332

http://docs.python.org/dev/py3k/whatsnew/3.3.html#os lists some of these additions, and they are already grouped (e.g. the sched_* functions, the "at" functions, ...).

Before the os API gets even more bloated, maybe we should group some of these functions in new submodules, like os.sched.*.

----------
components: Extension Modules
messages: 146363
nosy: benjamin.peterson, ezio.melotti, georg.brandl, loewis, pitrou, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Group some os functions in submodules
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Tue Oct 25 14:20:14 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 25 Oct 2011 12:20:14 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319545214.21.0.438827457418.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I discovered a couple of APIs that were moved from the commands module to the subprocess module in 3.0:
http://docs.python.org/dev/library/subprocess#subprocess.getstatusoutput

However, they have issues, especially on Windows: http://bugs.python.org/issue10197

So part of this patch would include deprecating those two interfaces in favour of the new shutil ones - the existing APIs break the subprocess promise of never invoking the shell implicitly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Tue Oct 25 14:23:01 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 25 Oct 2011 12:23:01 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1319545381.54.0.0929729124965.issue10197@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Without knowing this issue existed, I recently started working on adding some convenience APIs for shell invocation to shutil: http://bugs.python.org/issue13238

I think the getstatus and getstatusoutput APIs were copied from the commands module in 3.0 without sufficient thought being given to whether or not they fit with the design principles of the subprocess module. IMO, both should be deprecated:
   - they're not cross-platform
   - they invoke the shell implicitly, which subprocess promises never to do

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Tue Oct 25 14:24:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Oct 2011 12:24:38 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319545478.18.0.558197565389.issue13263@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Tue Oct 25 14:29:36 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 25 Oct 2011 12:29:36 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319545776.92.0.865006987945.issue13263@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Tue Oct 25 14:32:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Oct 2011 12:32:20 +0000
Subject: [issue13256] Document and test new socket options
In-Reply-To: <1319456775.82.0.463656498781.issue13256@psf.upfronthosting.co.za>
Message-ID: <1319545940.8.0.404605845329.issue13256@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23516/socket_options_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13256>
_______________________________________

From report at bugs.python.org  Tue Oct 25 14:44:12 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 25 Oct 2011 12:44:12 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319546652.7.0.572120776402.issue13263@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Tue Oct 25 14:45:05 2011
From: report at bugs.python.org (Artem Tomilov)
Date: Tue, 25 Oct 2011 12:45:05 +0000
Subject: [issue13264] Monkeypatching using metaclass
Message-ID: <1319546705.67.0.958518065524.issue13264@psf.upfronthosting.co.za>


New submission from Artem Tomilov <scraplesh at gmail.com>:

from abc import ABCMeta

class Meta(ABCMeta):
    def __instancecheck__(cls, instance):
        # monkeypatching class method
        cls.__subclasscheck__ = super(Meta, cls).__subclasscheck__
        return super(Meta, cls).__instancecheck__(instance)

    def __subclasscheck__(cls, sub):
        return cls in sub.mro()

class A(object):
    __metaclass__ = Meta

class B(object): pass

# registering class 'B' as a virtual subclass of 'A'
A.register(B)

>>> issubclass(B, A)
False
>>> isinstance(B(), A) # => method __subclasscheck__ is now monkeypatched
True
>>> issubclass(B, A) # => desire to get 'True' because 'B' is a virtual subclass
False

----------
components: None
messages: 146366
nosy: Artem.Tomilov
priority: normal
severity: normal
status: open
title: Monkeypatching using metaclass
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13264>
_______________________________________

From report at bugs.python.org  Tue Oct 25 14:47:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 25 Oct 2011 12:47:32 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319546852.21.0.708857249703.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

After a bit of thought, I realised I could use the string.Formatter API to implement a custom formatter for the shell command helpers that auto-escapes whitespace while leaving the other shell metacharacters alone (so you can still interpolate paths containing wildcards, etc).

People that want to bypass the autoescaping of whitespace can do the interpolation prior to the shell call, those that also want to escape shell metacharacters can use shlex.quote explicitly.

Diff can be seen here:
https://bitbucket.org/ncoghlan/cpython_sandbox/changeset/f19accc9a91b

----------
hgrepos: +85

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Tue Oct 25 14:49:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Oct 2011 12:49:05 +0000
Subject: [issue13264] Monkeypatching using metaclass
In-Reply-To: <1319546705.67.0.958518065524.issue13264@psf.upfronthosting.co.za>
Message-ID: <1319546945.3.0.812211202272.issue13264@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13264>
_______________________________________

From report at bugs.python.org  Tue Oct 25 16:16:20 2011
From: report at bugs.python.org (ben)
Date: Tue, 25 Oct 2011 14:16:20 +0000
Subject: [issue13220] print function unable while multiprocessing.Process is
	being run
In-Reply-To: <1319038082.58.0.169311394229.issue13220@psf.upfronthosting.co.za>
Message-ID: <1319552180.09.0.370093904207.issue13220@psf.upfronthosting.co.za>


ben <thelen_ben at yahoo.com> added the comment:

Thanks Terry,

That does solve the problem, so the bug is really with IDLE (I got a previous Issue (12967) reported which also was connected to the stdout).

I changed the component to IDLE as the lib. is working as it should do.

----------
components: +IDLE -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13220>
_______________________________________

From report at bugs.python.org  Tue Oct 25 16:23:48 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Tue, 25 Oct 2011 14:23:48 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1319552628.15.0.186875545072.issue8036@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

against py3k branch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Tue Oct 25 16:27:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Oct 2011 14:27:16 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1319552836.46.0.58639606242.issue8036@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Now we are using Mercurial, and what was called 'py3k' on SVN is now 'default'.  Since we now commit on older branches first and then merge with the most recent ones, the patch should either be against 3.2 or 2.7.
You can check the devguide for more informations.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Tue Oct 25 17:05:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Oct 2011 15:05:40 +0000
Subject: [issue13258] replace hasattr(obj, '__call__') with callable(obj)
In-Reply-To: <1319485575.06.0.0356181366596.issue13258@psf.upfronthosting.co.za>
Message-ID: <1319555140.89.0.580378364223.issue13258@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This change is fine for packaging.  In the 2.x backport I already use callable (and damn the py3k warning) and  the 3.x backport uses the incorrect hasattr(inst, '__call__'); I?ll change that to use a backported d2.compat.callable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13258>
_______________________________________

From report at bugs.python.org  Tue Oct 25 17:16:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Oct 2011 15:16:18 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1319555778.52.0.983911015026.issue12618@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I can reproduce in 3.2 and 3.3.  I?ll commit a test and patch when I get the time, or another dev can take this over.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Tue Oct 25 17:22:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Oct 2011 15:22:39 +0000
Subject: [issue13260] distutils and cross-compiling the extensions
In-Reply-To: <1319499699.99.0.666933133396.issue13260@psf.upfronthosting.co.za>
Message-ID: <1319556159.36.0.127032030667.issue13260@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Alexander,

Thanks for your interest in improving Python.  I?m forced to reject your request because

- Python 2.7 does not get new features (and support for cross-compilation would be one).

- distutils does not get new features (we had to freeze it because improvements broke many setup scripts depending on undocumented behavior or working around bugs).

- This request has been made many times already: http://mail.python.org/pipermail/python-dev/2011-March/110099.html

To get cross-compilation, here?s one would have to do:

- Work on distutils2, the replacement for distutils and setuptools (it?s included in Python 3.3 under the ?packaging? name).

- Define exactly what is supported (cross-compiling from any platform to any platform for example), possibly by reviewing all other bug reports about and hashing things out on the distutils-sig mailing list.

- Think about getting buildbots running to make sure we don?t get regressions.

----------
assignee: tarek -> eric.araujo
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13260>
_______________________________________

From report at bugs.python.org  Tue Oct 25 17:24:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Oct 2011 15:24:15 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1319556255.06.0.520158243401.issue9750@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Lucas.  Have you read my previous message?  The patch needs to be updated.  Would you like to do it?

----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Tue Oct 25 17:48:46 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 25 Oct 2011 15:48:46 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319557726.84.0.844835963281.issue13234@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Even if we decide not to convert any forward slash, listdir() adds u"\\*.*" when the input is unicode, but it adds "/*.*" when it is not, before passing it off to Windows API. Hence the inconsistency and the problem Manuel saw.

IMO, his patch shouldn't have differentiated if the path starts with r"\\?\" and just be consistent with adding "\\*.*", unicode or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 17:54:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Oct 2011 15:54:53 +0000
Subject: [issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
In-Reply-To: <1319208086.31.0.00990210804778.issue13240@psf.upfronthosting.co.za>
Message-ID: <1319558093.66.0.999138200551.issue13240@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> If we truly want to enable this by default, then the defaulting should be moved to
> configure.  This will give a more accurate portrayal in sysconfig.
This sounds good.  (I know little about configure/pyconfig.h, but making sysconfig more accurate is a valuable result.)

> P.S. We could probably get rid of the HAVE macro all together by doing
> all the work in the 'configure' script.
Would that be a breach of backward compatibility for sysconfig?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Tue Oct 25 18:07:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Oct 2011 16:07:25 +0000
Subject: [issue13244] WebSocket schemes in urllib.parse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319558845.81.0.586041450538.issue13244@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> # must always be escaped, both in path and query components.

Agreed.  This just follows from the Generic URI Syntax RFC, it?s not specific to WebSockets.

> And further: urlparse should raise an exception upon unescaped # within URLs
> from ws/wss schemes.

I?d say that urlparse should raise an exception when a ws/wss URI contains a fragment part.  I?m not sure this will be possible; from a glance at the source and a quick test, urlparse will happily break the Generic URI Syntax RFC and return a path including a # character!

----------
title: WebSocket schemes in urlparse -> WebSocket schemes in urllib.parse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Tue Oct 25 18:08:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Oct 2011 16:08:37 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1319558917.78.0.911981770611.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> What about Windows support?
Just like with distutils: the file extension is used, not the shebang.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Tue Oct 25 18:11:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Oct 2011 16:11:01 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1319559061.93.0.957417062573.issue10197@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> IMO, both should be deprecated:
> - they're not cross-platform
Isn?t the purpose of this report to fix that? :)

> - they invoke the shell implicitly, which subprocess promises never to do
One could argue that it?s not implicit if it?s documented.  Nonetheless, I agree that they don?t fit well with the subprocess promises.

So, +1 on deprecating and +1 on new, safer helpers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Tue Oct 25 18:23:18 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 25 Oct 2011 16:23:18 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319559798.65.0.0369489972126.issue13218@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm not sure I particularly like this patch, and I can't test it on anything other than Debian/Ubuntu right now, but it does "fix" the test (defined as: making it pass :).

AFAICT, there's no way to tell openssl to revert back to trying SSLv2 client hello when the library has been compiled with no-ssl, but still setting OP_NO_SSLv2 or OP_NO_TLSv1 kind of seems like keeping a couple of tests that can't possibly succeed (because neither v2 nor v3, nor tlsv1 will be tried).

The other thing is that testing the flags on the client context doesn't seem to work:


Python 3.2.2+ (3.2:03ef6108beae, Oct 25 2011, 10:57:32) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> cc = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
>>> cc.options & ssl.OP_NO_SSLv2
0

Now, the other way to go is to set OP_NO_SSLv2 on both tests and change the sense of it from False to True, so that we'd always expect the connection to succeed.  I'll attach that patch next, and it does seem a bit more sane.  Let me know what you think.

----------
Added file: http://bugs.python.org/file23517/issue13218.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Tue Oct 25 18:24:35 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 25 Oct 2011 16:24:35 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319559875.61.0.0229589752481.issue13218@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Here's the diff that disables SSLv2 and changes the expected sense of the connection results.  Again, I can't test this on other than Debian/Ubuntu atm, so feedback would be useful.

----------
Added file: http://bugs.python.org/file23518/issue13218-true.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Tue Oct 25 18:29:35 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 25 Oct 2011 16:29:35 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1319558917.78.0.911981770611.issue12394@psf.upfronthosting.co.za>
Message-ID: <1319560169.934.YahooMailNeo@web25807.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> 

>>  What about Windows support?
> Just like with distutils: the file extension is used, not the shebang.

Please spell out for me how you see this working: I don't see it. Note that scripts have to use the correct Python even if they are invoked using an explicit path pointing into a virtual environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Tue Oct 25 18:39:39 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 25 Oct 2011 16:39:39 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1319560779.17.0.567006853841.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

To expand on what I said about not seeing how things will work under Windows: are we going to place .exe launchers adjacent to the script, like setuptools does? If the script just has a shebang of "#!/usr/bin/env python", how is the launcher supposed to determine the exact Python to use from that, in a venv scenario where multiple Pythons will be installed? Scripts in virtual envs are supposed to run if invoked, even if the env is not on the PATH.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Tue Oct 25 18:56:48 2011
From: report at bugs.python.org (Seppo Yli-Olli)
Date: Tue, 25 Oct 2011 16:56:48 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1319561808.08.0.64455369536.issue12641@psf.upfronthosting.co.za>


Seppo Yli-Olli <seppo.yliolli at gmail.com> added the comment:

Would it be practical to have a trivial compilation test to see if we are capable of using GCC with -mno-cygwin and if so, use it, otherwise drop off? I think GNU autotools uses a similar strategy for detecting compiler capabilities.

----------
nosy: +Seppo.Yli-Olli

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Oct 25 20:04:43 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 25 Oct 2011 18:04:43 +0000
Subject: [issue13017] pyexpat.c: refleak
In-Reply-To: <1316530520.98.0.265221985232.issue13017@psf.upfronthosting.co.za>
Message-ID: <1319565883.76.0.536089525192.issue13017@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The patch is not correct: modelobj must not be decref'd, because it has been inserted to the args tuple with the reference-stealing 'N' format. args is later decref'd in function's cleanup code after "finally:".

----------
keywords:  -after moratorium
resolution:  -> rejected
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13017>
_______________________________________

From report at bugs.python.org  Tue Oct 25 20:20:36 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 25 Oct 2011 18:20:36 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319566836.2.0.210379478811.issue13263@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think there is a value to use the very same function names in the posix module as in the posix API. The posix API (and C in general) is also flat, and uses the prefix convention. People who look at the function lists will know to ignore blocks of functions by prefix if they don't need them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Tue Oct 25 20:25:48 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 25 Oct 2011 18:25:48 +0000
Subject: [issue13016] selectmodule.c: refleak
In-Reply-To: <1316530474.09.0.885561459136.issue13016@psf.upfronthosting.co.za>
Message-ID: <1319567148.1.0.95532116102.issue13016@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

PySequence_Fast_GET_ITEM expects that the object is valid and the index is within bounds, and never returns NULL. There's no need to decref and actually there's even no need to check the return value of PySequence_Fast_GET_ITEM.

----------
resolution:  -> rejected
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13016>
_______________________________________

From report at bugs.python.org  Tue Oct 25 20:33:41 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 25 Oct 2011 18:33:41 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319567621.42.0.475895261806.issue13234@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This issue is getting messy. I declare that this issue is *only* about the original problem reported in msg146031. When that is fixed, this issue will be closed, and any further issues need to be reported separately.

As for the original problem, ISTM that the right fix is to replace

    namebuf[len++] = '/';

with

    namebuf[len++] = '\\';

No further change should be necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 20:34:13 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 25 Oct 2011 18:34:13 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319567653.92.0.987156781697.issue13234@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Addressing patch comments.

----------
Added file: http://bugs.python.org/file23519/issue13234_py33_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 20:40:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Oct 2011 18:40:14 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319568014.36.0.00482258358026.issue13263@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Of the new ones, only the sched_* ones share a common prefix, the *xattr and *at functions share a common suffix, and it's difficult to find them e.g. in dir() (also it's difficult to find other common os functions among all the names).  The fact that the Posix API and C in general use a flat API doesn't seem to me a valid reason to do the same in Python.  Having the same name is a good reason to avoid sched.*, even if I don't think that having sched.* will make finding/recognizing these functions much more difficult.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Tue Oct 25 20:42:10 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 25 Oct 2011 18:42:10 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319568130.79.0.184736665386.issue13234@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Fair enough. Simplifying.

----------
Added file: http://bugs.python.org/file23520/issue13234_py33_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 20:45:22 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 25 Oct 2011 18:45:22 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319568322.99.0.352396670297.issue13263@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I think there is a value to use the very same function names in the 
> posix module as in the posix API.

It would still be the case, except that they'd live in distinct submodule.

> The posix API (and C in general) is also flat, and uses the prefix 
> convention.

That's because C doesn't have namespaces: it's certainly due to this limitation, and not a design choice (and when you think about it, there is a namespace hierarchy, in the header files: <sys/sched.h>, <attr/xatr.h>, etc.).

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Tue Oct 25 20:49:00 2011
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 25 Oct 2011 18:49:00 +0000
Subject: [issue13264] Monkeypatching using metaclass
In-Reply-To: <1319546705.67.0.958518065524.issue13264@psf.upfronthosting.co.za>
Message-ID: <1319568540.12.0.73117983765.issue13264@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13264>
_______________________________________

From report at bugs.python.org  Tue Oct 25 21:04:32 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 25 Oct 2011 19:04:32 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319569472.49.0.940311252051.issue13263@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Some functions would be easy to split off into separate modules conceptually like the sched_* functions and the cap_* functions (see #1615158).

However, certain groups of functions like the *at functions cover a lot of different functionality and don't really belong together.

Perhaps the only grouping that should be done is for functions that start with a common prefix like sched_* since they are basically in a C "namespace".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Tue Oct 25 21:20:31 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 25 Oct 2011 19:20:31 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1319570431.55.0.652292218801.issue13188@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The same issue exists on 2.7, working on a patch.

----------
status: closed -> open
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Tue Oct 25 21:40:46 2011
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 25 Oct 2011 19:40:46 +0000
Subject: [issue13264] Monkeypatching using metaclass
In-Reply-To: <1319546705.67.0.958518065524.issue13264@psf.upfronthosting.co.za>
Message-ID: <1319571646.49.0.783350619737.issue13264@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> class Meta(ABCMeta):
>     def __instancecheck__(cls, instance):
>         # monkeypatching class method
>         cls.__subclasscheck__ = super(Meta, cls).__subclasscheck__

This line is approximately the same as:
        cls.__dict__['__subclasscheck__'] = ...
So it will put the object in the namespace of cls. The function in the namespace of type(cls) will remain there. (Also, the object you put in there is a bound method, so this is probably not what you want.)


>         return super(Meta, cls).__instancecheck__(instance)
> 
>     def __subclasscheck__(cls, sub):
>         return cls in sub.mro()
> 
> class A(object):
>     __metaclass__ = Meta
> 
> class B(object): pass
> 
> # registering class 'B' as a virtual subclass of 'A'
> A.register(B)
> 
> >>> issubclass(B, A)
> False
> >>> isinstance(B(), A) # => method __subclasscheck__ is now
> monkeypatched

A.__dict__['__subclasscheck__'] is now indeed the other method you put in there, but issubclass will call  type(A).__dict__['__subclasscheck__'] which remain the same. (Because __special__ methods a looked up directly in the namespace of the type of an object, see http://docs.python.org/dev/py3k/reference/datamodel#special-lookup).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13264>
_______________________________________

From report at bugs.python.org  Tue Oct 25 21:51:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Oct 2011 19:51:30 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319572290.31.0.634076359504.issue13247@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

os.getcwdb() (GetCurrentDirectoryA) and os.listdir(bytes) (FindNextFileA & co) encode filenames using WideCharToMultiByte() in default mode (flags=0): unencodable characters are replaced by question marks. Such filenames cannot be used, open() fails with OSError(22, "invalid argument: '?'") for example.

Attached patch changes os.getcwdb() and os.listdir(bytes) to use the Windows native API (wide character API) with Python MBCS codec in strict mode (error handler "strict") to notify directly the user that the filename cannot be decoded.

The patch only changes the behaviour for filename not encodable to the ANSI code page, such filenames are rare.

----------
keywords: +patch
Added file: http://bugs.python.org/file23521/os_mbcs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Tue Oct 25 22:00:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Oct 2011 20:00:09 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319572809.97.0.358678742068.issue13247@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

os_mbcs.patch adds _Py_EncodeCodePage() to encode directly wchar_t* filenames without having to create a temporary Unicode object.

The patch removes HAVE_MBCS because the MBCS is now always needed by the posixmodule.c. Anyway, I don't see why MultiByteToWideChar() and WideCharToMultiByte() would not be available on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Tue Oct 25 22:19:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Oct 2011 20:19:53 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319573993.81.0.786855014875.issue13234@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

-        if (ch != SEP && ch != ALTSEP && ch != ':')
+        if (ch != '\\' && ch != '/' && ch != ':')

I don't understand this change in issue13234_py33_v4.patch (the change looks to be useless).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 22:25:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Oct 2011 20:25:24 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319574324.92.0.0418307320774.issue13263@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I would prefer to keep the shared prefix even if we move functions to a new module. Python refers usually to the C documentation for the details of a function. If we rename a function, it becomes more difficult to get the manual of the function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Tue Oct 25 22:51:36 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 25 Oct 2011 20:51:36 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1319575896.23.0.887111941447.issue13234@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

> I don't understand this change in issue13234_py33_v4.patch (the change looks to be useless).

It's pedantic correctness on my part. SEP and ALTSEP are defined as wide strings L'\\' and L'/' respectively. Their usage in the unicode conditional branch and the bytes conditional branch seem to have been reversed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13234>
_______________________________________

From report at bugs.python.org  Tue Oct 25 23:00:57 2011
From: report at bugs.python.org (Tobias Oberstein)
Date: Tue, 25 Oct 2011 21:00:57 +0000
Subject: [issue13244] WebSocket schemes in urllib.parse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319576457.08.0.637351405698.issue13244@psf.upfronthosting.co.za>


Tobias Oberstein <tobias.oberstein at tavendo.de> added the comment:

> I?d say that urlparse should raise an exception when a ws/wss URI contains a fragment part.

Yep, better.

> I?m not sure this will be possible; from a glance at the source and a quick test, urlparse will happily break the Generic URI Syntax RFC and return a path including a # character!

That's unfortunate.

In that case I'd probably prefer the lesser evil, namely that urlparse be set up (falsely) such that ws/wss scheme would falsely allow fragments, so I get back the non-empty fragment as a separate component, and check myself.

If urlparse returns the fragment (falsely) within path, then a user could check only by searching for # in the path. Also hacky .. even worse than compare fragment for != "". 

Essentially, this would be exactly "the hack" that I posted in my very first comment:

urlparse.uses_fragment.extend(wsschemes)

===

Alternative: make this bug dependent on fixing urlparse for fragment rules in generic URI RFC and don't do anything until then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Wed Oct 26 00:55:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Oct 2011 22:55:10 +0000
Subject: [issue13220] print function unable while multiprocessing.Process is
	being run
In-Reply-To: <1319038082.58.0.169311394229.issue13220@psf.upfronthosting.co.za>
Message-ID: <1319583310.47.0.100215052404.issue13220@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This may be a 'cannot fix' issue due to the way Windows connects the output and input streams of various processes. It would be helpful to know if *nix has the same difference of behavior between interpreter and IDLE shell. Otherwise some experiments are needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13220>
_______________________________________

From report at bugs.python.org  Wed Oct 26 01:32:10 2011
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Tue, 25 Oct 2011 23:32:10 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319585530.67.0.809395329671.issue13247@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

-1 from me.

- I hate to see Unicode exceptions here. It would be an another source of mysterious Unicode exception. Programmers and users would be confused by error message. If you make such characters error, Python should raise an OSError or such.

- File names with '?' are fine to display informations to users. Not all file names are nessesary to be used to open files.

- I don't think filenames cannot be decoded in ANSI code page are rare enough to be ignored. I use Japanese edition of windows, but I sometime receive files with Chinese or German names. 

Or, in some case, I have to change codepage with 'chcp 437' command to run console application made for American environment. I seldom run such application in these days, though.

----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Wed Oct 26 02:03:34 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 26 Oct 2011 00:03:34 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1319587414.81.0.325781809677.issue1559549@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Here's an updated patch, plus support for a second attribute that I need for #10854. I previously wrote a patch that does this same thing for that issue, but this one handles things a lot more nicely :)

I renamed "module_name" to just be "name" since I was adding "path" and didn't want to have to name it "module_path" and have two "module_" attributes since I think it's clear what they are for. We can go back to "module_" names if you want - no big deal.

It's really just the same patch as before but updated for a few minor changes (the ComplexExtendsException sig changed), and the moving of keyword handling in ImportError_init into a macro since we have to do the same initialization twice now. I'm not married to that implementation, it just minimized duplication and seems to work alright.

Also, this removes the import.c change (see Brett's last message).

----------
nosy: +brian.curtin
Added file: http://bugs.python.org/file23522/issue1559549.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Wed Oct 26 02:12:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 00:12:44 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319585530.67.0.809395329671.issue13247@psf.upfronthosting.co.za>
Message-ID: <4EA750BF.6010505@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le 26/10/2011 01:32, Atsuo Ishimoto a ?crit :
> - I don't think filenames cannot be decoded in ANSI code page are rare enough to be ignored.

The issue is able being able to be noticied of encoding errors. 
Currently, unencodable characters are silently replaced and you don't 
know if the filename is valid or not. If a UnicodeEncodeError is raised, 
you will be noticed and so you have to fix the problem.

Anyway, you must use the Unicode API on Windows. If you use the Unicode 
API, filenames are no more encoded and code pages are no more used, so 
bye bye Unicode errors!

The Windows bytes API is just kept for backward compatibility. More 
details in my email to python-dev:
http://mail.python.org/pipermail/python-dev/2011-October/114203.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Wed Oct 26 02:47:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 Oct 2011 00:47:39 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319590059.3.0.903159805255.issue13247@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The doc says "All functions accepting path or file names accept both bytes and string objects, and result in an object of the same type, if a path or file name is returned." It does that now (the encoding assumed or produced for bytes is not specified). It says nothing about raising exceptions in certain situations. So this is a feature change request, one that would likely break existing code.

Users can test for invalid returned paths with "'?' in returned_path", though I admit that the use of '?' as a glob, regex, and url special char makes it a bad choice of error char.

----------
nosy: +terry.reedy
type: behavior -> feature request
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Wed Oct 26 04:18:44 2011
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Wed, 26 Oct 2011 02:18:44 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <4EA750BF.6010505@haypocalc.com>
Message-ID: <CAK2Ax-VSjLJT5fQW5k92P5kLwLR=x4QFXSf6=FBOmDcO4mXTkA@mail.gmail.com>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

On Wed, Oct 26, 2011 at 9:12 AM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> Le 26/10/2011 01:32, Atsuo Ishimoto a ?crit :
>> - I don't think filenames cannot be decoded in ANSI code page are rare enough to be ignored.
>
> The issue is able being able to be noticied of encoding errors.

This patch solve nothing, but just raises exception. It can break
existing codes. Also, I don't think it worth to add weired behavior to
Python std lib. I'll be surprised if *Byte* API raised an
UnicodeEncodeError.

> Anyway, you must use the Unicode API on Windows. If you use the Unicode
> API, filenames are no more encoded and code pages are no more used, so
> bye bye Unicode errors!
>

Agreed. So I would like to suggest not to adding unnecessary
complexity to the Byte API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Wed Oct 26 05:15:02 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 26 Oct 2011 03:15:02 +0000
Subject: [issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
In-Reply-To: <1319558093.66.0.999138200551.issue13240@psf.upfronthosting.co.za>
Message-ID: <CAK1QoooExok_9nFAsL7OhWQk42fY_RCQfbNut99btr=WrKv2Hw@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

>> P.S. We could probably get rid of the HAVE macro all together by doing
>> all the work in the 'configure' script.
> Would that be a breach of backward compatibility for sysconfig?

Yeah, I think so.  Best to leave it alone then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13240>
_______________________________________

From report at bugs.python.org  Wed Oct 26 06:25:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 26 Oct 2011 04:25:14 +0000
Subject: [issue11440] fix_callable should be dropped from lib2to3 / changed
In-Reply-To: <1299600488.07.0.0466070744973.issue11440@psf.upfronthosting.co.za>
Message-ID: <1319603114.85.0.452456091749.issue11440@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Benjamin added a note in d9571fb37269.
I agree with Florent though, if the fixer is disabled by default and people are using 3.1 they will see the error and enable it.
If they aren't 2to3 will correctly leave callable().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11440>
_______________________________________

From report at bugs.python.org  Wed Oct 26 06:29:54 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 26 Oct 2011 04:29:54 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1319603394.0.0.0631931699136.issue12618@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I think it might be easier to just always use the absolute path rather than looking at the directory length.  Maybe something like the attached.  I added unit tests as well.

----------
nosy: +meador.inge
stage: test needed -> patch review
Added file: http://bugs.python.org/file23523/issue12618-0.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Wed Oct 26 06:30:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 26 Oct 2011 04:30:43 +0000
Subject: [issue13207] os.path.expanduser breaks when using unicode character
	in the username
In-Reply-To: <1318937669.16.0.167083698894.issue13207@psf.upfronthosting.co.za>
Message-ID: <1319603443.01.0.792460402686.issue13207@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13207>
_______________________________________

From report at bugs.python.org  Wed Oct 26 06:32:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 26 Oct 2011 04:32:56 +0000
Subject: [issue13161] problems with help() documentation of __i*__ operators
In-Reply-To: <1318436543.45.0.46958950416.issue13161@psf.upfronthosting.co.za>
Message-ID: <1319603576.83.0.755281015845.issue13161@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13161>
_______________________________________

From report at bugs.python.org  Wed Oct 26 06:34:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 26 Oct 2011 04:34:05 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1319603645.29.0.261990792525.issue12892@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
dependencies: +Refactor code using unicode_encode_call_errorhandler() in unicodeobject.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12892>
_______________________________________

From report at bugs.python.org  Wed Oct 26 07:48:49 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 26 Oct 2011 05:48:49 +0000
Subject: [issue13265] IDLE crashes when printing some unprintable characters.
Message-ID: <1319608129.37.0.0558883356195.issue13265@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

When you print an unprintable character, IDLE raises an error.
>>> print(chr(500304)) # print an unprintable character
The error is only visible when you run the code from a commmand-line.
When you run python from the command-line and execute the code it shows
the unprintable character symbol (looks like []).

----------
components: IDLE
messages: 146411
nosy: maniram.maniram
priority: normal
severity: normal
status: open
title: IDLE crashes when printing some unprintable characters.
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13265>
_______________________________________

From report at bugs.python.org  Wed Oct 26 07:51:33 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 26 Oct 2011 05:51:33 +0000
Subject: [issue13265] IDLE crashes when printing some unprintable characters.
In-Reply-To: <1319608129.37.0.0558883356195.issue13265@psf.upfronthosting.co.za>
Message-ID: <1319608293.91.0.75771596887.issue13265@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Here's the Error message.
*** Internal Error: rpc.py:SocketIO.localcall()

 Object: stdout 
 Method: <bound method PseudoFile.write of <idlelib.PyShell.PseudoFile object at 0x2675550>> 
 Args: ('\U0007a250',)

Traceback (most recent call last):
  File "/usr/lib/python3.2/idlelib/rpc.py", line 188, in localcall
    ret = method(*args, **kwargs)
  File "/usr/lib/python3.2/idlelib/PyShell.py", line 1220, in write
    self.shell.write(s, self.tags)
  File "/usr/lib/python3.2/idlelib/PyShell.py", line 1202, in write
    OutputWindow.write(self, s, tags, "iomark")
  File "/usr/lib/python3.2/idlelib/OutputWindow.py", line 40, in write
    self.text.insert(mark, s, tags)
  File "/usr/lib/python3.2/idlelib/Percolator.py", line 25, in insert
    self.top.insert(index, chars, tags)
  File "/usr/lib/python3.2/idlelib/ColorDelegator.py", line 79, in insert
    self.delegate.insert(index, chars, tags)
  File "/usr/lib/python3.2/idlelib/PyShell.py", line 312, in insert
    UndoDelegator.insert(self, index, chars, tags)
  File "/usr/lib/python3.2/idlelib/UndoDelegator.py", line 81, in insert
    self.addcmd(InsertCommand(index, chars, tags))
  File "/usr/lib/python3.2/idlelib/UndoDelegator.py", line 116, in addcmd
    cmd.do(self.delegate)
  File "/usr/lib/python3.2/idlelib/UndoDelegator.py", line 219, in do
    text.insert(self.index1, self.chars, self.tags)
  File "/usr/lib/python3.2/idlelib/ColorDelegator.py", line 79, in insert
    self.delegate.insert(index, chars, tags)
  File "/usr/lib/python3.2/idlelib/WidgetRedirector.py", line 104, in __call__
    return self.tk_call(self.orig_and_operation + args)
ValueError: unsupported character

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13265>
_______________________________________

From report at bugs.python.org  Wed Oct 26 07:56:04 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 26 Oct 2011 05:56:04 +0000
Subject: [issue13265] IDLE crashes when printing some unprintable characters.
In-Reply-To: <1319608129.37.0.0558883356195.issue13265@psf.upfronthosting.co.za>
Message-ID: <1319608564.53.0.903305677512.issue13265@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

My OS is Ubuntu Linux 11.10 (Oneiric Ocelot)
Running uname -a gives "Linux ramcomputer 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13265>
_______________________________________

From report at bugs.python.org  Wed Oct 26 07:57:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 26 Oct 2011 05:57:32 +0000
Subject: [issue13265] IDLE crashes when printing some unprintable characters.
In-Reply-To: <1319608129.37.0.0558883356195.issue13265@psf.upfronthosting.co.za>
Message-ID: <1319608652.32.0.19845589775.issue13265@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Both print(chr(500304)) and print('\U0007a250') seem to work and print two empty boxes on IDLE with Python 3.2/WinXP.

Is that error displayed in the IDLE window or does IDLE crash and you see the error somewhere else?

----------
nosy: +ezio.melotti, kbk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13265>
_______________________________________

From report at bugs.python.org  Wed Oct 26 07:59:36 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 26 Oct 2011 05:59:36 +0000
Subject: [issue13265] IDLE crashes when printing some unprintable characters.
In-Reply-To: <1319608129.37.0.0558883356195.issue13265@psf.upfronthosting.co.za>
Message-ID: <1319608776.85.0.989837232753.issue13265@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

The error is visible from the command-line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13265>
_______________________________________

From report at bugs.python.org  Wed Oct 26 08:03:21 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 26 Oct 2011 06:03:21 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1319609001.29.0.984494426255.issue13211@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> It appears the Python 3.2 docs no longer include documentation for URLError

Both URLError and HTTPError are documented in 3.2 and 3.3:

http://docs.python.org/py3k/library/urllib.error.html#urllib.error.URLError

http://docs.python.org/dev/library/urllib.error.html#urllib.error.URLError

It needs to be investigated whether each point raising a HTTPError sets a good msg. If this is the case, reason can be aliased to msg.

This could be done for 2.7, too, because this is a bug (deviation from what the documentation says) rather than a new feature.

----------
keywords: +easy
nosy: +petri.lehtinen
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Wed Oct 26 08:30:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 26 Oct 2011 06:30:00 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319574324.92.0.0418307320774.issue13263@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2isCGZKQmbj3iEY8G-vUdDAcMb=ptOh25z76xRCSf=Wg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I would prefer to keep the shared prefix even if we move functions to a new module. Python refers usually to the C documentation for the details of a function. If we rename a function, it becomes more difficult to get the manual of the function.

Indeed.
But that's what I understood from Ezio's proposal, I don't think he's
suggesting to rename them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Wed Oct 26 08:36:33 2011
From: report at bugs.python.org (Yuval Greenfield)
Date: Wed, 26 Oct 2011 06:36:33 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319610993.02.0.935018614875.issue13247@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

I use python a lot with Hebrew and many websites have internationalization which may involve unicode paths. I agree that saying "unicode paths are rare" is inaccurate. 

If the current situation isn't fixed though - you just can't use the resulting path for almost anything. Do you have a use case Ishimoto?

Windows XP and up implement paths as unicode, that means that a bytes api doesn't even make sense unless python does some encoding and decoding for you. E.g. python can use the unicode API's internally and return utf-8 encoded bytes. But you couldn't use these paths outside of python. The fact is you shouldn't be doing os.path.abspath(b'.') in windows to begin with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Wed Oct 26 08:41:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 26 Oct 2011 06:41:47 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319611307.67.0.266956628534.issue13263@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It would be fine for me to rename os.sched_get_priority_max() to os.sched.get_priority_max().
os.sched.sched_get_priority_max() is a bit redundant, and I think it's not to difficult to figure out that os.sched.get_priority_max() corresponds to the posix sched_get_priority_max() function, especially if we add a note to the doc (I'm only -0 about keeping the original name though).
Regarding the other functions that don't share a common prefix it's certainty better to keep the original name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Wed Oct 26 08:43:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Oct 2011 06:43:11 +0000
Subject: [issue13266] Support for unwrapping __wrapped__ functions in
	'inspect' module
Message-ID: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I just got bitten by the singularly unhelpful results of doing inspect.getsource(generator_context_manager).

Now that @functools.wraps adds the __wrapped__ attribute, perhaps inspect.getsource(f) should follow the wrapper chain by default?

This would affect other inspect APIs as well, such as getgeneratorstate() and the new getclosurevars() and getgeneratorlocals() that will be available in 3.3

While the source code of the wrapper could still be accessed by doing inspect.getsource(f.__code__), this isn't a reliable alternative in general (e.g. it doesn't work when introspecting closure state, since that needs access to the function object to look things up correctly). Accordingly, there would need to be a way to disable the "follow wrapper chains behaviour".

Alternatively (and more simply), we could just add an "inspect.unwrap(f)" function that followed a chain of __wrapped__ attributes and returned the last object in the chain (using an "already seen" set to avoid hit the recursion limit if someone sets up a wrapper loop). Applying this would then be a manual process when the initial output of an inspect function is clearly coming from a wrapper rather than the underlying function definition.

----------
components: Library (Lib)
messages: 146420
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Support for unwrapping __wrapped__ functions in 'inspect' module
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13266>
_______________________________________

From report at bugs.python.org  Wed Oct 26 08:44:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 26 Oct 2011 06:44:47 +0000
Subject: [issue13266] Support for unwrapping __wrapped__ functions in
	'inspect' module
In-Reply-To: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za>
Message-ID: <1319611487.81.0.726181500629.issue13266@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13266>
_______________________________________

From report at bugs.python.org  Wed Oct 26 08:56:38 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Oct 2011 06:56:38 +0000
Subject: [issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__"
	chains
In-Reply-To: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za>
Message-ID: <1319612198.22.0.978372453736.issue13266@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

After a little thought, I think the explicit "unwrap" function is the only viable approach. Doing the unwrapping implicitly just has too many nasty corner cases to track down to ensure we aren't losing existing functionality.

I'd also suggest that we add a __wrapped__ alias for the 'func' attribute of functools.partial objects.

----------
title: Support for unwrapping __wrapped__ functions in 'inspect' module -> Add inspect.unwrap(f) to easily unravel "__wrapped__" chains

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13266>
_______________________________________

From report at bugs.python.org  Wed Oct 26 09:02:40 2011
From: report at bugs.python.org (Yuval Greenfield)
Date: Wed, 26 Oct 2011 07:02:40 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319612560.91.0.441550203825.issue13247@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

Another option btw is to use utf-16, which will work but it's a bit ugly as well:

>>> os.listdir(os.path.abspath(u'.').encode('utf-16'))
[]
>>> os.path.abspath(u'.')
u'C:\\Users\\alon\\Desktop\\\u05e9\u05dc\u05d5\u05dd'
>>> os.path.abspath(u'.').encode('utf-16')
'\xff\xfeC\x00:\x00\\\x00U\x00s\x00e\x00r\x00s\x00\\\x00a\x00l\x00o\x00n\x00\\\x
00D\x00e\x00s\x00k\x00t\x00o\x00p\x00\\\x00\xe9\x05\xdc\x05\xd5\x05\xdd\x05'
>>> os.listdir(os.path.abspath(u'.').encode('utf-16'))
[]

Tested on python 2.7, but you know what I mean.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Wed Oct 26 09:23:05 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 26 Oct 2011 07:23:05 +0000
Subject: [issue13267] Add an option to disable importing orphaned bytecode
	files
Message-ID: <1319613785.83.0.955902072358.issue13267@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

This has been discussed in python-ideas approx. two years ago:

http://mail.python.org/pipermail/python-ideas/2009-December/006635.html

It seems to me that having an opt-in command-line option, environment variable and sys variable to disable loading orphaned bytecode files upon import had most use cases and gained most support.

----------
components: Interpreter Core
messages: 146423
nosy: brett.cannon, ncoghlan, petri.lehtinen, pitrou
priority: normal
severity: normal
status: open
title: Add an option to disable importing orphaned bytecode files
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13267>
_______________________________________

From report at bugs.python.org  Wed Oct 26 10:01:34 2011
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Wed, 26 Oct 2011 08:01:34 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319610993.02.0.935018614875.issue13247@psf.upfronthosting.co.za>
Message-ID: <CAK2Ax-WKkPmQpPB9F1R_DjxY82jzLfHPQ1Ye9YeShxmt-_b9Qw@mail.gmail.com>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

On Wed, Oct 26, 2011 at 3:36 PM, Yuval Greenfield
<report at bugs.python.org> wrote:

> If the current situation isn't fixed though - you just can't use the resulting path for almost anything. Do you have a use case Ishimoto?

I don't have use case. But does raising UnicodeEncodeError fix
problems?  It could break existing code, but I don't see much
difference over WindowsError caused by the broken file names.

> The fact is you shouldn't be doing os.path.abspath(b'.') in windows to begin with.

Agreed. So I think adding Windows specific check to Byte API does not
improve situation, but increase complexity of std lib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Wed Oct 26 10:18:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Oct 2011 08:18:27 +0000
Subject: [issue13267] Add an option to disable importing orphaned bytecode
	files
In-Reply-To: <1319613785.83.0.955902072358.issue13267@psf.upfronthosting.co.za>
Message-ID: <1319617107.73.0.754179448145.issue13267@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This feature is unnecessary now that PEP 3147 has been adopted. The way it works in 3.2+ is that orphaned bytecode files inside __pycache__ are always ignored, while bytecode files that live directly in the source directories are always imported.

This handles both use cases nicely:
- the implicitly created cache files are ignored if their source file has been deleted
- bytecode only distribution is still supported by explicitly installing bytecode files instead of source files

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13267>
_______________________________________

From report at bugs.python.org  Wed Oct 26 11:04:39 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 26 Oct 2011 09:04:39 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1319619879.58.0.237988374692.issue13211@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I scanned through the libs for Python 2.7, 3.2, and 3.3 and there is no construction of HTTPError that does not pass a string for msg. I believe it would be reasonable to alias reason to msg. I'll put together the changesets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Wed Oct 26 11:08:31 2011
From: report at bugs.python.org (Yuval Greenfield)
Date: Wed, 26 Oct 2011 09:08:31 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319620111.05.0.999774597823.issue13247@psf.upfronthosting.co.za>


Yuval Greenfield <ubershmekel at gmail.com> added the comment:

It won't break existing code. Ignoring this problem here only moves the exception to whenever the data returned is first used.

Any code this fix "breaks" is already broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Wed Oct 26 12:10:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 10:10:27 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319612560.91.0.441550203825.issue13247@psf.upfronthosting.co.za>
Message-ID: <3099146.F7zfWAW4XK@dsk000552>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Yuval Greenfield <ubershmekel at gmail.com> added the comment:
> Another option btw is to use utf-16

UTF-8, UTF-16 or any encoding different than the ANSI code page are not an 
option. The Windows bytes API expect filenames encoded to the ANSI code page. 
os.listdir() would raise an error (unknown directory) or return an empty list 
instead of the content of the directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Wed Oct 26 13:06:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Oct 2011 11:06:24 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <E1RJ1JJ-0004Nn-NH@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0b4df6701c4d by Nick Coghlan in branch '2.7':
Issue #13237: further updates to subprocess documentation
http://hg.python.org/cpython/rev/0b4df6701c4d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Wed Oct 26 13:16:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Oct 2011 11:16:11 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <E1RJ1Sn-00057F-PI@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f445c125aca3 by Nick Coghlan in branch '2.7':
Issue #13237: remove some details that only apply to the 3.x version of this module and cross reference the relocated warning about the dangers of invoking the shell with untrusted input
http://hg.python.org/cpython/rev/f445c125aca3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Wed Oct 26 13:18:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 11:18:09 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1+ on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319627889.44.0.412729065229.issue13241@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X -> llvm-gcc-4.2 miscompiles Python (XCode 4.1+ on Mac OS 10.7)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Wed Oct 26 13:19:02 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Oct 2011 11:19:02 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319627942.67.0.613222649965.issue13237@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Absent any further feedback, I think I'm done with the changes to the 2.7 subprocess docs. I'll let them sit for a few days, then do the forward port to 3.2 and default.

There are a couple of additional changes I'll add to the 3.x versions:
- mention redirecting to DEVNULL as a way of suppressing output when using call() and check_call()
- mention the UTF-8 assumption involved in using the universal newlines mode for pipes in 3.x (i.e. the stuff I mistakenly checked in to 2.7 and then reverted)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Wed Oct 26 13:34:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Oct 2011 11:34:45 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <E1RJ1kk-0006oe-Nc@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5dfe6d7f7c61 by Nick Coghlan in branch '2.7':
Issue #13237: fix typo
http://hg.python.org/cpython/rev/5dfe6d7f7c61

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Wed Oct 26 13:52:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 11:52:51 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319629971.1.0.114339840689.issue13241@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I asked for more information about llvm-gcc on IRC (#llvm). Extracts:

 - "llvm-gcc is not maintained." ("Clang and DragonEgg are.) "Apple is the maintainer of Apple's version of llvm-gcc and clang."
 - "Apple ships a [llvm-gcc] branch at a random point in svn + some bug fixes, not a proper release."
 - "llvm-gcc is Apple's GCC (which was never sync'd with mainline past 4.2.1 because the FSF changed the license) with LLVM on the back end."
 - llvm-gcc-4.5 in Ubuntu 10.10 is not llvm-gcc, it's dragonegg, a new project

If I understood correctly, llvm-gcc is only the default C compiler of Xcode 4.1. I don't think that you should workaround llvm-gcc bugs. If you are using Xcode 4.1, you can compile Python with clang. clang is a different C compiler and it doesn't have the bug.

----------
title: llvm-gcc-4.2 miscompiles Python (XCode 4.1+ on Mac OS 10.7) -> llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Wed Oct 26 15:43:29 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 26 Oct 2011 13:43:29 +0000
Subject: [issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__"
	chains
In-Reply-To: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za>
Message-ID: <1319636609.02.0.156970431206.issue13266@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13266>
_______________________________________

From report at bugs.python.org  Wed Oct 26 17:32:11 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 15:32:11 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319643131.32.0.106983527026.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
hgrepos: +86

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Oct 26 17:33:16 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 15:33:16 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319643196.33.0.51593628723.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23524/d014fd90a487.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Oct 26 17:35:23 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 15:35:23 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319643323.16.0.602298255381.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23524/d014fd90a487.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Oct 26 17:43:57 2011
From: report at bugs.python.org (Alexander Myodov)
Date: Wed, 26 Oct 2011 15:43:57 +0000
Subject: [issue13268] assert
Message-ID: <1319643837.13.0.0801682507198.issue13268@psf.upfronthosting.co.za>


New submission from Alexander Myodov <amyodov at gmail.com>:

The extended version of assert statement has a strange violation of documented behaviour.

According to the http://docs.python.org/reference/simple_stmts.html#the-assert-statement, "assert expression1, expression2" should be equivalent to "if __debug__: if not expression1: raise AssertionError(expression2)". Nevertheless, it is not so for the following scenario:

class A(object):
    def __str__(self):
        return "str"
    def __unicode__(self):
        return "unicode"
    def __repr__(self):
        return "repr"

expression1 = False
expression2 = (A(),)

That is, when expression2 is a single-item tuple, assert statement prints the str-evaluation of the item itself, rather than of the tuple.

This occurs in 2.x branch only, seems fixed in 3.x, and it would be great to have it backported for consistency.

----------
messages: 146434
nosy: amyodov
priority: normal
severity: normal
status: open
title: assert
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13268>
_______________________________________

From report at bugs.python.org  Wed Oct 26 17:53:22 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 15:53:22 +0000
Subject: [issue13269] Document that "Remote hg repo" accepts remote branches
Message-ID: <1319644402.17.0.721295098845.issue13269@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

"Remote hg repo" accepts remote branches, but the devguide says that the patch must be in "default" branch.

Update the docs.

I take care of this.

----------
assignee: jcea
keywords: easy
messages: 146435
nosy: jcea
priority: normal
severity: normal
status: open
title: Document that "Remote hg repo" accepts remote branches

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13269>
_______________________________________

From report at bugs.python.org  Wed Oct 26 17:54:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 26 Oct 2011 15:54:15 +0000
Subject: [issue13269] Document that "Remote hg repo" accepts remote branches
In-Reply-To: <1319644402.17.0.721295098845.issue13269@psf.upfronthosting.co.za>
Message-ID: <1319644455.13.0.123615690282.issue13269@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Distutils
nosy: +eric.araujo, ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13269>
_______________________________________

From report at bugs.python.org  Wed Oct 26 17:55:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 26 Oct 2011 15:55:04 +0000
Subject: [issue13269] Document that "Remote hg repo" accepts remote branches
In-Reply-To: <1319644402.17.0.721295098845.issue13269@psf.upfronthosting.co.za>
Message-ID: <1319644504.11.0.464336073931.issue13269@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I take care of this.
Okay, as long as you don?t use Git terminology like ?remote? :)

----------
components: +Devguide -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13269>
_______________________________________

From report at bugs.python.org  Wed Oct 26 17:58:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Oct 2011 15:58:18 +0000
Subject: [issue13269] Document that "Remote hg repo" accepts remote branches
In-Reply-To: <1319644402.17.0.721295098845.issue13269@psf.upfronthosting.co.za>
Message-ID: <E1RJ5ro-00080d-WB@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7fbd2fe8c13c by Jesus Cea in branch 'default':
Close #13269: Document that "Remote hg repo" accepts remote branches
http://hg.python.org/devguide/rev/7fbd2fe8c13c

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13269>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:00:52 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 16:00:52 +0000
Subject: [issue13269] Document that "Remote hg repo" accepts remote branches
In-Reply-To: <1319644402.17.0.721295098845.issue13269@psf.upfronthosting.co.za>
Message-ID: <1319644852.88.0.611743989435.issue13269@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Eric, the original text says:

"""
The Create Patch button will then compute a diff for the head revision of the remote branch, and attach the diff to the issue.
    ^^^^^^
"""

:-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13269>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:01:37 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 16:01:37 +0000
Subject: [issue13269] Document that "Remote hg repo" accepts remote branches
In-Reply-To: <1319644402.17.0.721295098845.issue13269@psf.upfronthosting.co.za>
Message-ID: <1319644897.01.0.73306486951.issue13269@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
Removed message: http://bugs.python.org/msg146438

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13269>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:02:05 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 16:02:05 +0000
Subject: [issue13269] Document that "Remote hg repo" accepts remote branches
In-Reply-To: <1319644402.17.0.721295098845.issue13269@psf.upfronthosting.co.za>
Message-ID: <1319644925.55.0.471624613463.issue13269@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Eric, the original text says:

"""
The Create Patch button will then compute a diff for the head revision of the **remote** branch, and attach the diff to the issue.
"""

:-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13269>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:06:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 26 Oct 2011 16:06:28 +0000
Subject: =?utf-8?q?=5Bissue1011113=5D_Make_=E2=80=9Cinstall=E2=80=9D_find_the_buil?=
	=?utf-8?q?d=5Fbase_directory?=
Message-ID: <1319645188.17.0.665306170882.issue1011113@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Actually I think this bug can be fixed in distutils.

----------
components: +Distutils
keywords: +easy
resolution: remind -> 
stage:  -> needs patch
type: feature request -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1011113>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:12:37 2011
From: report at bugs.python.org (Alexander Myodov)
Date: Wed, 26 Oct 2011 16:12:37 +0000
Subject: [issue13268] assert statement violates the documentation
In-Reply-To: <1319643837.13.0.0801682507198.issue13268@psf.upfronthosting.co.za>
Message-ID: <1319645557.13.0.694518186145.issue13268@psf.upfronthosting.co.za>


Changes by Alexander Myodov <amyodov at gmail.com>:


----------
title: assert -> assert statement violates the documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13268>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:13:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 26 Oct 2011 16:13:11 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319645591.02.0.949782576852.issue13237@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I want to review the doc, but lack time right now.  For example, one function signature in your patch uses keyword-only arguments but 2.7 doesn?t support them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:14:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 26 Oct 2011 16:14:08 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1319645648.32.0.206124266971.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

anikom15, can you give me a URI to download the OS you used?  I don?t know when I?ll be able to download Windows, but surely a linux-using OS will take less space and time to download and install in a VM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:37:00 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 26 Oct 2011 16:37:00 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1319647020.13.0.159002358172.issue13193@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I've been able to consistently reproduce the test_resources failure on Ubuntu 11.10 64-bit, FWIW.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:40:01 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 26 Oct 2011 16:40:01 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319647201.46.0.0497072547383.issue13241@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Haypo, the OP has a workaround. IMO, we should not be making any recommendations about which Apple compiler to use on OS X 10.7 until we have completed test cycles of each.  There are too many variables at the moment.  I am doing that and should have results in a few days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:43:58 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 16:43:58 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319647438.98.0.85733358135.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23525/6ea157b9d110.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:46:24 2011
From: report at bugs.python.org (Amirouche Boubekki)
Date: Wed, 26 Oct 2011 16:46:24 +0000
Subject: [issue12657] Cannot override JSON encoding of basic type subclasses
In-Reply-To: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za>
Message-ID: <1319647584.41.0.292877653492.issue12657@psf.upfronthosting.co.za>


Changes by Amirouche Boubekki <amirouche.boubekki at gmail.com>:


----------
nosy: +abki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12657>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:46:58 2011
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 26 Oct 2011 16:46:58 +0000
Subject: [issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__"
	chains
In-Reply-To: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za>
Message-ID: <1319647618.85.0.322010671937.issue13266@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13266>
_______________________________________

From report at bugs.python.org  Wed Oct 26 18:52:02 2011
From: report at bugs.python.org (Amirouche Boubekki)
Date: Wed, 26 Oct 2011 16:52:02 +0000
Subject: [issue4945] json checks True/False by identity, not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1319647922.4.0.26821477777.issue4945@psf.upfronthosting.co.za>


Changes by Amirouche Boubekki <amirouche.boubekki at gmail.com>:


----------
nosy: +abki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________

From report at bugs.python.org  Wed Oct 26 19:01:56 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 17:01:56 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319648516.88.0.668621952584.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23525/6ea157b9d110.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Oct 26 19:05:24 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 17:05:24 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319648724.68.0.844966395345.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23526/0ee4386d8f51.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Oct 26 19:20:30 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 17:20:30 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319649630.6.0.913446160591.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

First version of the patch. Review 0ee4386d8f51.diff http://bugs.python.org/file23526/0ee4386d8f51.diff

Details:

1. Current code aliases "devpoll" in platforms with "/dev/poll" (Solaris and derivatives). Considering all the other points, I think that providing a separate "select.devpoll" object would be a better idea. Opinions?.

2. I am not providing the exception contract documented in "select.poll". For instance, "poll.unregister" of a "fd" not previously registered doesn't raise an exception. Idem "poll.modify", etc. I could do it, but is pointless extra code.

3. I have added a boolean "select.isdevpoll" to indicate if "selec.poll" uses "poll()" or "/dev/poll". Ugly.

4. I release the GIL when waiting for the fds, but not when registering/unregistering fds, etc. I guess that the syscall would be very fast, but I haven't actually measure it.

5. The internal REMOVE is because if you "register" several times the same fd, the events are ORed. To avoid that I do an internal REMOVE first. I should scan the pollfds internally and update the events inplace. Or provide a separate "devpoll" and document this fact...

6. If the number of active fds is bigger that SIZE_DEVPOLL, only SIZE_DEVPOLL fds are returned. If you "poll" several times, you get the SAME fds, if they are still active. So, others active fds can suffer of starvation. Solutions: selftunning (if the module provide 20 slots and the OS provide 20 active fds, call again with 40 free slots, etc) or provide a separate "devpoll" and document this fact, posibly providing a "maxsize" parameter. "select.epoll" uses FD_SETSIZE, directly.

With this, I am starting to think that providing a separate "select.devpoll" is actually a better idea.

Opinions?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Oct 26 19:21:07 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 17:21:07 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319649667.62.0.619391967558.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
keywords: +needs review
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Oct 26 19:22:17 2011
From: report at bugs.python.org (Peter Eisentraut)
Date: Wed, 26 Oct 2011 17:22:17 +0000
Subject: [issue13236] unittest needs more flush calls
In-Reply-To: <1319137324.16.0.266090134048.issue13236@psf.upfronthosting.co.za>
Message-ID: <1319649737.62.0.241645321953.issue13236@psf.upfronthosting.co.za>


Peter Eisentraut <peter_e at gmx.net> added the comment:

Attached is a test file.  The key here is that I'm running the unittest suite inside of a long-running server process, so there is no predictable point of exit and cleanup.  Therefore, the steps I show at the end of the file should be run in an interactive interpreter.  Here is what I see:

>>> import unittest                                                                                                                             
>>> import testcase                                                                                                                             
>>> unittest.main(module=testcase)
.F.
======================================================================
FAIL: test_three (testcase.test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "testcase.py", line 35, in test_three
    self.fail("intentional failure")
AssertionError: intentional failure

----------------------------------------------------------------------
Ran 3 tests in 0.002s

FAILED (failures=1)

That's good.

But:

>>> import unittest                                                                                                                             
>>> import testcase                                                                                                                             
>>> unittest.main(module=testcase, testRunner=testcase.FunnyTestRunner, exit=False)                                                             
.
F
.
<unittest.main.TestProgram object at 0xf718fd4c>

You see, the test report at the end is missing.

I'm happy to consider other ways of addressing this, if anyone has an idea.

----------
Added file: http://bugs.python.org/file23527/testcase.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13236>
_______________________________________

From report at bugs.python.org  Wed Oct 26 19:49:56 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 26 Oct 2011 17:49:56 +0000
Subject: [issue13268] assert statement violates the documentation
In-Reply-To: <1319643837.13.0.0801682507198.issue13268@psf.upfronthosting.co.za>
Message-ID: <1319651396.64.0.444571435504.issue13268@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
components: +Interpreter Core
nosy: +petri.lehtinen
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13268>
_______________________________________

From report at bugs.python.org  Wed Oct 26 20:04:31 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 26 Oct 2011 18:04:31 +0000
Subject: [issue4945] json checks True/False by identity, not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1319652271.09.0.484420387279.issue4945@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________

From report at bugs.python.org  Wed Oct 26 20:11:09 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 26 Oct 2011 18:11:09 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1319652669.58.0.787797432261.issue13188@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

It seems this cannot be achieved the same way in 2.7 as the traceback is not directly associated with the exception. However, if we're currently in an exception handler and sys.exc_info() corresponds to the exception passed to generator.throw(), we could use the current traceback. Would this approach be too complicated and not worth it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Wed Oct 26 20:15:13 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 26 Oct 2011 18:15:13 +0000
Subject: [issue13265] IDLE crashes when printing some unprintable characters.
In-Reply-To: <1319608129.37.0.0558883356195.issue13265@psf.upfronthosting.co.za>
Message-ID: <1319652913.38.0.9368751239.issue13265@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

With a current 3.3 build (i.e. "wide" build) on OS X, I can reproduce this. It causes an exception on the execution of that command in the IDLE shell but it doesn't crash IDLE.  Not surprisingly, it doesn't seem to be reproducible with 3.2 "narrow" builds.

----------
nosy: +ned.deily
type: crash -> 
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13265>
_______________________________________

From report at bugs.python.org  Wed Oct 26 20:31:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Oct 2011 18:31:05 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <E1RJ8Fd-0006Zn-4J@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e0499b2b28aa by Petri Lehtinen in branch '2.7':
Issue #10860: Skip the new test if HTTPS is not available
http://hg.python.org/cpython/rev/e0499b2b28aa

New changeset a3939c2f6727 by Petri Lehtinen in branch '3.2':
Issue #10860: Skip the new test if HTTPS is not available
http://hg.python.org/cpython/rev/a3939c2f6727

New changeset 2dd106799aa9 by Petri Lehtinen in branch 'default':
Issue #10860: Skip the new test if HTTPS is not available
http://hg.python.org/cpython/rev/2dd106799aa9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Wed Oct 26 20:32:52 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 26 Oct 2011 18:32:52 +0000
Subject: [issue13207] os.path.expanduser breaks when using unicode character
	in the username
In-Reply-To: <1318937669.16.0.167083698894.issue13207@psf.upfronthosting.co.za>
Message-ID: <1319653972.76.0.104343013768.issue13207@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Unicode environment vars work properly in Python 3.x on Windows, too, because the convertenviron() function in posixmodule.c uses extern _wenviron PyUnicode_FromWideChar() in Python 3.x. In Python 2.7, convertenviron() uses extern environ and PyString_FromString*().

----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13207>
_______________________________________

From report at bugs.python.org  Wed Oct 26 20:43:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 Oct 2011 18:43:33 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319654613.99.0.917876813304.issue13247@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Yuval, you are assuming that *no one* who uses the os byte APIs on Windows is either checking for '?' in returned paths or catching later exceptions. With Google code search, I did find one instance where someone tests paths for '?' after encoding with the file system encoding. It was not an instance of os.xxx output, but it is the same idea.

In any case,
1. Our experience is that any change will affect someone. I was the victim of a 'harmless' micro change introduced in 3.1.2 (an intentional violation of the bugfix-only rule in bugfix releases -- and the last that I know of ;-).
2. The change will introduce an incompatibility between 3.2- and 3.3+.

The justification that mitigates the above is that there is little reason to request os bytes returns. By the same reasoning, the change is hardly worth bothering with as there should be little to no benefit in real code. So I am +-0 on the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Wed Oct 26 21:24:57 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 26 Oct 2011 19:24:57 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <1319657097.65.0.798876452476.issue5661@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> I am not marking 'test needed' since the problem is 'hardly reproducible'.

The attached script named 'asyncore_epipe.py' may be used to reproduce
systematically the EPIPE error on linux with Python 3.2:

    * the Reader closes the socket after receiving the first data
    * the Writer gets an exception when attempting to write the next
      message on the closed socket

When you run 'python asyncore_epipe.py' or 'python asyncore_epipe.py
1025' you get an EPIPE error (1025 is the size of exchanged messages,
so the last Writer message has been fully read by the Reader before
closing).

When you run 'python asyncore_epipe.py 128' you get an ECONNRESET (the
Reader reads only 128 bytes before closing the socket)

Note that ECONNRESET has been removed in this script, from the
frozenset of handled errors, to make this last point visible.

So it seems that, on linux, when writing to a closed socket, you get
an ECONNRESET when there is still data in the socket, and an EPIPE
otherwise. In the first case the tcp connection ends with a single
RESET, and in the second case it ends with the sequence FIN-ACK-RESET.

----------
nosy: +xdegaye
Added file: http://bugs.python.org/file23528/asyncore_epipe.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Wed Oct 26 21:30:34 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Wed, 26 Oct 2011 19:30:34 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1319657434.93.0.188438129743.issue8036@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

added some tests (not sure if in appropriate place).

----------
Added file: http://bugs.python.org/file23529/issue_8036_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Wed Oct 26 22:48:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Oct 2011 20:48:49 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319645591.02.0.949782576852.issue13237@psf.upfronthosting.co.za>
Message-ID: <CADiSq7e1fxy3uCjLTfDfqUvUwyJn792=_42XF8MXEqbXqdVspQ@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

That's deliberate, as I'm only showing a selected subset of the full
signature at that point and using the subprocess API's with positional
arguments would lead to almost incomprehensible code. I'm not in any great
hurry to forward port though, so I'm happy to wait until you get a chance to
review the changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Wed Oct 26 23:15:50 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 26 Oct 2011 21:15:50 +0000
Subject: [issue13270] all classes are new style
Message-ID: <1319663750.31.0.916391635164.issue13270@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

these last references to old/new classes should be dropped.
See patch.

----------
assignee: docs at python
components: Documentation
files: all_classes_belong_to_new_style.diff
keywords: patch
messages: 146455
nosy: docs at python, flox
priority: normal
severity: normal
stage: patch review
status: open
title: all classes are new style
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23530/all_classes_belong_to_new_style.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13270>
_______________________________________

From report at bugs.python.org  Wed Oct 26 23:17:40 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Wed, 26 Oct 2011 21:17:40 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1319663860.91.0.583774292982.issue13193@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

http://www.archlinux.org/download/

It's a minimalist distribution but if you read through the install guide or beginner's guide you'll be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Wed Oct 26 23:22:07 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 21:22:07 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319664127.13.0.280916880806.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I have decided to segregate "select.devpoll" to a separate object, like "select.epoll".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Oct 26 23:25:52 2011
From: report at bugs.python.org (Joshua Chia)
Date: Wed, 26 Oct 2011 21:25:52 +0000
Subject: [issue13271] When -h is used with argparse,
	default values that fail should not matter
Message-ID: <1319664352.05.0.511704738067.issue13271@psf.upfronthosting.co.za>


New submission from Joshua Chia <joshchia at gmail.com>:

What steps will reproduce the problem?
1. Make a script containing this code:

 parser = argparse.ArgumentParser()
 parser.add_argument('-i', '--input-base-directory',
                     type=argparse.FileType('r'),
                     default='/home')
 parser.parse_args()

2. Run the script with '-h'.
3. See it complain that '/home' is a directory

Detailed explanation:
With '-h', we just need to print the help message. We shouldn't fail on a default value that's wrong or else the help message will not get printed and the user will have no idea what the problem is. This is a valid use case as I want to provide a default location, but I can't guarantee that the location works on the user's machine. I end up doing my own checking.

----------
components: Library (Lib)
messages: 146458
nosy: Joshua.Chia
priority: normal
severity: normal
status: open
title: When -h is used with argparse, default values that fail should not matter
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13271>
_______________________________________

From report at bugs.python.org  Wed Oct 26 23:26:38 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 21:26:38 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319664398.36.0.924961019372.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Solved points 1, 3 and 4.

2 will be solved with the documentation.

5 and 6 still pending.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Oct 26 23:27:30 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 21:27:30 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319664450.42.0.555022829842.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23526/0ee4386d8f51.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Oct 26 23:28:04 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 21:28:04 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319664484.94.0.101657785003.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23531/6becc4e3eece.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Thu Oct 27 00:50:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 22:50:04 +0000
Subject: [issue13207] os.path.expanduser breaks when using unicode character
	in the username
In-Reply-To: <1318937669.16.0.167083698894.issue13207@psf.upfronthosting.co.za>
Message-ID: <1319669404.0.0.604649290929.issue13207@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python 2 uses byte strings. If characters are not encodable to the ANSI code page, Windows replaces them by question marks. See the issue #13247 for another example (in Python 3 when using explicitly the bytes API). To be able to support characters not encodable to the ANSI code page, you have to use Unicode *everywhere*.

Because Python 2 doesn't have access to the Unicode environment and uses bytes in most cases, I don't think that we can fix this issue in Python 2.

I close this issue because it would require too much work to fix this issue in Python 2, whereas it already works in Python 3.  Move to Python 3 is the best solution of this issue.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13207>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:18:27 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 23:18:27 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319671107.52.0.854663197131.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23531/6becc4e3eece.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:18:50 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 23:18:50 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319671130.45.0.00452908416492.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23532/0b701eb5e9e3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:20:34 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 23:20:34 +0000
Subject: [issue6397] Implementing Solaris "poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319671234.75.0.703229651713.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Documentation added. That solves 2 and 5.

I still have to solve 6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:24:47 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Oct 2011 23:24:47 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1319671487.07.0.61222367251.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
title: Implementing Solaris "poll" in the "select" module -> Implementing Solaris "/dev/poll" in the "select" module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:39:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Oct 2011 23:39:22 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <E1RJD40-00028O-DK@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2cad20e2e588 by Victor Stinner in branch 'default':
Close #13247: Add cp65001 codec, the Windows UTF-8 (CP_UTF8)
http://hg.python.org/cpython/rev/2cad20e2e588

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:42:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Oct 2011 23:42:44 +0000
Subject: [issue13216] Add cp65001 codec
In-Reply-To: <1318977871.28.0.0371088882056.issue13216@psf.upfronthosting.co.za>
Message-ID: <E1RJD7G-0002QC-8R@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0eac706d82d1 by Victor Stinner in branch 'default':
Fix the issue number of my cp65001 commit: 13247 => issue #13216
http://hg.python.org/cpython/rev/0eac706d82d1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13216>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:43:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 23:43:06 +0000
Subject: [issue13216] Add cp65001 codec
In-Reply-To: <1318977871.28.0.0371088882056.issue13216@psf.upfronthosting.co.za>
Message-ID: <1319672586.56.0.136765451791.issue13216@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New changeset 2cad20e2e588 by Victor Stinner in branch 'default':
Close #13247: Add cp65001 codec, the Windows UTF-8 (CP_UTF8)
http://hg.python.org/cpython/rev/2cad20e2e588

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13216>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:43:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 23:43:35 +0000
Subject: [issue13247] os.path.abspath returns unicode paths as question marks
In-Reply-To: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za>
Message-ID: <1319672615.21.0.602712732085.issue13247@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, I specified the wrong issue number in my changeset 2cad20e2e588, it's the issue #13216.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13247>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:44:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 23:44:53 +0000
Subject: [issue13216] Add cp65001 codec
In-Reply-To: <1318977871.28.0.0371088882056.issue13216@psf.upfronthosting.co.za>
Message-ID: <1319672693.13.0.143753588585.issue13216@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Lib/encodings/cp65001.py uses a little trick to mark the codec as specific to Windows:
-----------------
if not hasattr(codecs, 'code_page_encode'):
    raise LookupError("cp65001 encoding is only available on Windows")
-----------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13216>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:48:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 23:48:08 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1319672888.22.0.603024706145.issue6058@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I added a cp65001 codec to Python 3.3: see issue #13216.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:48:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 23:48:26 +0000
Subject: [issue12281] bytes.decode('mbcs',
	'ignore') does replace undecodable bytes on Windows Vista or later
In-Reply-To: <1307483285.51.0.642940083136.issue12281@psf.upfronthosting.co.za>
Message-ID: <1319672906.21.0.0445007808725.issue12281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I added a cp65001 codec to Python 3.3: see issue #13216.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12281>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:49:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 23:49:03 +0000
Subject: [issue10920] cp65001, PowerShell, Python crash.
In-Reply-To: <1295207262.38.0.033573856036.issue10920@psf.upfronthosting.co.za>
Message-ID: <1319672943.66.0.613278067845.issue10920@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I added a cp65001 codec to Python 3.3: see issue #13216. So Python will not "crash" anymore if the console code page is set to cp65001.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10920>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:49:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 23:49:45 +0000
Subject: [issue7441] Py3.1: Fatal Python Error: Py_Initialize...unknown
	encoding: chcp 65001.
In-Reply-To: <1260009658.59.0.0106753931217.issue7441@psf.upfronthosting.co.za>
Message-ID: <1319672985.03.0.157286906814.issue7441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I added a cp65001 codec to Python 3.3: see issue #13216. So Python will not "crash" anymore if the console code page is set to cp65001.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7441>
_______________________________________

From report at bugs.python.org  Thu Oct 27 01:50:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Oct 2011 23:50:17 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1319673017.88.0.440926874376.issue1602@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I added a cp65001 codec to Python 3.3: see issue #13216.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Thu Oct 27 03:30:53 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 27 Oct 2011 01:30:53 +0000
Subject: [issue13271] When -h is used with argparse,
	default values that fail should not matter
In-Reply-To: <1319664352.05.0.511704738067.issue13271@psf.upfronthosting.co.za>
Message-ID: <1319679053.4.0.320535121791.issue13271@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +bethard, eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13271>
_______________________________________

From report at bugs.python.org  Thu Oct 27 05:51:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 03:51:08 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319687468.97.0.364363368029.issue13237@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think ?ric is referring to the foo(bar, *, baz=None) syntax.  In 2.7 you can drop the '*' and still leave only the keyword arguments that you think are more useful.
I also see that you converted a few examples to use shell=True, but afaiu that should be avoided (even if the input is trusted, it can be a bad example and lead to escaping issues).
For the 'exit 1' example you could add a note saying that the example is run with shell=True because 'exit' requires a shell, or just keep the more verbose Python version.
My concern is that many people just go trough the examples and copy/paste what they see without reading the text around unless it's necessary to make the command work, so, if many examples use shell=True, they might end up picking one of those.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Thu Oct 27 05:54:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 03:54:19 +0000
Subject: [issue13268] assert statement violates the documentation
In-Reply-To: <1319643837.13.0.0801682507198.issue13268@psf.upfronthosting.co.za>
Message-ID: <1319687659.43.0.747665311332.issue13268@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13268>
_______________________________________

From report at bugs.python.org  Thu Oct 27 07:47:33 2011
From: report at bugs.python.org (Alister Cordiner)
Date: Thu, 27 Oct 2011 05:47:33 +0000
Subject: [issue10015] Creating a multiprocess.pool.ThreadPool from a child
	thread blows up.
In-Reply-To: <1286028029.62.0.429525925265.issue10015@psf.upfronthosting.co.za>
Message-ID: <1319694453.69.0.540951161448.issue10015@psf.upfronthosting.co.za>


Alister Cordiner <acordiner at gmail.com> added the comment:

I think that workaround should be:

if not hasattr(threading.current_thread(), "_children"):
    threading.current_thread()._children = weakref.WeakKeyDictionary()

----------
nosy: +acordiner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10015>
_______________________________________

From report at bugs.python.org  Thu Oct 27 09:16:33 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Thu, 27 Oct 2011 07:16:33 +0000
Subject: [issue13244] WebSocket schemes in urllib.parse
In-Reply-To: <1319576457.08.0.637351405698.issue13244@psf.upfronthosting.co.za>
Message-ID: <CAM0Q7WBMKNjz5w_+7hbSA+kbKvGYRKjYs5kROmNHjcStzvbDUA@mail.gmail.com>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

> Alternative: make this bug dependent on fixing urlparse for fragment rules in generic URI RFC and don't do anything until then?

I'd go with this, even though it probably would be a lot bigger work
than this. What's ?ric's take on this approach?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Thu Oct 27 09:17:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 07:17:07 +0000
Subject: [issue12657] Cannot override JSON encoding of basic type subclasses
In-Reply-To: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za>
Message-ID: <1319699827.61.0.947795470817.issue12657@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12657>
_______________________________________

From report at bugs.python.org  Thu Oct 27 09:27:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 07:27:05 +0000
Subject: [issue13272] 2to3 fix_renames doesn't rename
	string.lowercase/uppercase/letters
Message-ID: <1319700425.9.0.635731429373.issue13272@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

$ cat deleteme.py 
from string import lowercase, uppercase, letters
print uppercase == 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
print lowercase == 'abcdefghijklmnopqrstuvwxyz'
print letters == 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
$ python deleteme.py 
True
True
True
$ 2to3 -w deleteme.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored deleteme.py
--- deleteme.py (original)
+++ deleteme.py (refactored)
@@ -1,4 +1,4 @@
 from string import lowercase, uppercase, letters
-print uppercase == 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
-print lowercase == 'abcdefghijklmnopqrstuvwxyz'
-print letters == 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
+print(uppercase == 'ABCDEFGHIJKLMNOPQRSTUVWXYZ')
+print(lowercase == 'abcdefghijklmnopqrstuvwxyz')
+print(letters == 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ')
RefactoringTool: Files that were modified:
RefactoringTool: deleteme.py
$ python3 deleteme.py 
Traceback (most recent call last):
  File "deleteme.py", line 1, in <module>
    from string import lowercase, uppercase, letters
ImportError: cannot import name lowercase

They should be renamed to ascii_*.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 146475
nosy: benjamin.peterson, ezio.melotti
priority: normal
severity: normal
stage: test needed
status: open
title: 2to3 fix_renames doesn't rename string.lowercase/uppercase/letters
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13272>
_______________________________________

From report at bugs.python.org  Thu Oct 27 09:30:57 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 27 Oct 2011 07:30:57 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319700657.32.0.0489285752463.issue13237@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

We can only protect people from themselves so much - "shell=True" is invaluable when you actually want to invoke the shell, and the shell has much better tools for process invocation and pipeline processing than Python does (since shells are, in effect, domain specific languages dedicated to those tasks).

If someone is blindly copying and pasting code from the internet, then shell injection attacks are likely to be the *least* of the security problems in anything they're building.

The point of the examples is to demonstrate the return code handling and using the shell is the easiest way to do that. I'll add a note to the docstrings to be aware of the security issues with the parameter, though.

As far as the keyword arguments go, no, I can't just drop the bare '*' from the abbreviated signature, because that would be making claims about the signature that are just plain *wrong* (there are other positional arguments that appear before 'stdin'). I'll add a note explaining that point somewhere in the 2.7 version, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Thu Oct 27 09:51:28 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 27 Oct 2011 07:51:28 +0000
Subject: [issue13244] WebSocket schemes in urllib.parse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319701888.75.0.510595484327.issue13244@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

This kind of suggestion has come up before and easy fix is to add individual schemes as the patch does. There is a number of limitations if want to make the parser generic for any scheme. The difficult thing being the parsing behavior and requirements as defined by scheme. 

The generic parsing rule, which was added previously was, when someone comes up a new scheme and what could be default "fall-back parsing rule".

In this report, I see ws and wss has some requirements, which needs to be codified in the parsing rules followed by urlparse module. To start with, going with patch is a good way. 

If you find any other library (I look at libcurl) handling it differently, please point it out here, so that it can could be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Thu Oct 27 09:55:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Oct 2011 07:55:49 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <E1RJKoR-000422-Eh@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2a2df6a72ccb by Nick Coghlan in branch '2.7':
Issue #13237: Make the subprocess convenience helper documentation self-contained aside from the shared parameter description. Downgrade the pipe warnings at that level to notes (since those pipes are hidden, people are unlikely to even try it)
http://hg.python.org/cpython/rev/2a2df6a72ccb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Thu Oct 27 09:56:02 2011
From: report at bugs.python.org (Christopher Allen-Poole)
Date: Thu, 27 Oct 2011 07:56:02 +0000
Subject: [issue13273] HTMLParser improperly handling open tags when strict is
	False
Message-ID: <1319702162.06.0.209889524007.issue13273@psf.upfronthosting.co.za>


New submission from Christopher Allen-Poole <christopherw at allen-poole.com>:

This is is encountered when extending html.parser.HTMLParser and running with strict mode False.

Expected behavior:
When '''<div style=""    ><b>The <a href="some_url">rain</a> <br /> in <span>Spain</span></b></div>''' is passed to the feed method, div, b, a, br, and span should all be passed to the handle_starttag method.

Actual behavior
The handle_data method receives the values <div style=""    >,<b>,<a href="some_url">,<br />,<span> in addition to the regular text.

This can be fixed by changing this (inside the parse_starttag method):

m = hparse.attrfind_tolerant.search(rawdata, k)

to

m = hparse.attrfind_tolerant.match(rawdata, k)

----------
components: Library (Lib)
messages: 146479
nosy: Christopher.Allen-Poole
priority: normal
severity: normal
status: open
title: HTMLParser improperly handling open tags when strict is False
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13273>
_______________________________________

From report at bugs.python.org  Thu Oct 27 10:06:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 27 Oct 2011 08:06:27 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1319702787.71.0.114868395611.issue13237@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As the last checkin message says, I've made the documentation for the helper functions more self-contained. Each now has its own short "shell=True" warning with a pointer to the full explanation in the shared parameter description. There was also a copy-and-paste error in the Popen docs where the cross-reference for "shell=True" was a note rather than a warning, so I fixed that.

For the helper functions, people are unlikely to pass in "stdout=PIPE" or "stderr=PIPE" in the first place, since there's no point (you can't get at the Popen object, so you can't at the streams in order to read from them). Accordingly, I downgraded the relevant boxes to be notes rather than warnings (the boxes down near Popen.wait() and the data attribute descriptions remain warnings).

The latest version also uses the "keyword only" syntax for all three helper functions, but describes them with the following text in each case:

=========
The arguments shown above are merely the most common ones, described below in :ref:`frequently-used-arguments` (hence the slightly odd notation in the abbreviated signature).
=========

For 3.x, I'll reword that to:

=========
The arguments shown above are merely the most common ones, described below in :ref:`frequently-used-arguments` (hence the use of keyword only argument notation in the abbreviated signature).
=========

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Thu Oct 27 10:15:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 08:15:13 +0000
Subject: [issue13273] HTMLParser improperly handling open tags when strict is
	False
In-Reply-To: <1319702162.06.0.209889524007.issue13273@psf.upfronthosting.co.za>
Message-ID: <1319703313.12.0.276811053391.issue13273@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13273>
_______________________________________

From report at bugs.python.org  Thu Oct 27 10:31:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 08:31:16 +0000
Subject: [issue13273] HTMLParser improperly handling open tags when strict is
	False
In-Reply-To: <1319702162.06.0.209889524007.issue13273@psf.upfronthosting.co.za>
Message-ID: <1319704276.03.0.31587232147.issue13273@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Incidentally I was just investigating this very same issue, and your suggestion seems to work for me too.
I'll see if the change has any downside and come up with a patch + test.
Thanks for the report!

----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13273>
_______________________________________

From report at bugs.python.org  Thu Oct 27 10:36:20 2011
From: report at bugs.python.org (Tobias Oberstein)
Date: Thu, 27 Oct 2011 08:36:20 +0000
Subject: [issue13244] WebSocket schemes in urllib.parse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319704580.93.0.835632664964.issue13244@psf.upfronthosting.co.za>


Tobias Oberstein <tobias.oberstein at tavendo.de> added the comment:

The patch as it stands will result in wrong behavior:

+        self.assertEqual(urllib.parse.urlparse("ws://example.com/stuff#ff"),
+                         ('ws', 'example.com', '/stuff#ff', '', '', ''))

The path component returned is invalid for ws/wss and is invalid for any scheme following the generic URI RFC, since # must be always escaped in path components.

Is urlparse meant to follow the generic URI RFC?

IMHO, the patch at least should do the equivalent of

urlparse.uses_fragment.extend(wsschemes)

so users of urlparse can do the checking for fragment != "", required for ws/wss on their own.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Thu Oct 27 10:50:25 2011
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Thu, 27 Oct 2011 08:50:25 +0000
Subject: [issue13274] heapq pure python version uses islice without guarding
	for negative counts
Message-ID: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com>:

the problem manifests when calling with negative counts

when the c versions are used, a empty list is returned,
however if the pure python version is called islice errors out

----------
components: Library (Lib)
messages: 146483
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: heapq pure python version uses islice without guarding for negative counts
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13274>
_______________________________________

From report at bugs.python.org  Thu Oct 27 11:45:33 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 27 Oct 2011 09:45:33 +0000
Subject: [issue10015] Creating a multiprocess.pool.ThreadPool from a child
	thread blows up.
In-Reply-To: <1286028029.62.0.429525925265.issue10015@psf.upfronthosting.co.za>
Message-ID: <1319708733.97.0.953391795836.issue10015@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10015>
_______________________________________

From report at bugs.python.org  Thu Oct 27 11:47:34 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 27 Oct 2011 09:47:34 +0000
Subject: [issue12657] Cannot override JSON encoding of basic type subclasses
In-Reply-To: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za>
Message-ID: <1319708854.8.0.208400466497.issue12657@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12657>
_______________________________________

From report at bugs.python.org  Thu Oct 27 12:05:59 2011
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 27 Oct 2011 10:05:59 +0000
Subject: [issue13275] Recommend xml.etree for XML processing
Message-ID: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za>


New submission from Alexey Shamrin <shamrin at gmail.com>:

There are many libraries in Python stdlib [1]

xml.dom
xml.dom.minidom
xml.dom.pulldom
xml.sax
xml.etree

Tutorial mentions xml.dom and xml.sax. [2]

In my experience xml.etree is the best library to quickly load some xml and mess with it. It would be nice to recommend people xml.etree in the tutorial [2] and in the beginning of section 19, "Structured Markup Processing Tools". [1]

[1]: http://docs.python.org/library/markup.html
[2]: http://docs.python.org/tutorial/stdlib.html#batteries-included

----------
assignee: docs at python
components: Documentation
messages: 146484
nosy: ash, docs at python
priority: normal
severity: normal
status: open
title: Recommend xml.etree for XML processing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13275>
_______________________________________

From report at bugs.python.org  Thu Oct 27 12:16:37 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 27 Oct 2011 10:16:37 +0000
Subject: [issue13275] Recommend xml.etree for XML processing
In-Reply-To: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za>
Message-ID: <1319710597.8.0.633663489061.issue13275@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
components: +XML
type:  -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13275>
_______________________________________

From report at bugs.python.org  Thu Oct 27 12:16:49 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 27 Oct 2011 10:16:49 +0000
Subject: [issue13275] Recommend xml.etree for XML processing
In-Reply-To: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za>
Message-ID: <1319710609.4.0.208318253198.issue13275@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13275>
_______________________________________

From report at bugs.python.org  Thu Oct 27 14:24:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Oct 2011 12:24:59 +0000
Subject: [issue13268] assert statement violates the documentation
In-Reply-To: <1319643837.13.0.0801682507198.issue13268@psf.upfronthosting.co.za>
Message-ID: <E1RJP0v-0002Pp-4u@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7bef55ae5753 by Benjamin Peterson in branch '2.7':
don't let a tuple msg be interpreted as arguments to AssertionError (closes #13268)
http://hg.python.org/cpython/rev/7bef55ae5753

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13268>
_______________________________________

From report at bugs.python.org  Thu Oct 27 14:28:28 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 27 Oct 2011 12:28:28 +0000
Subject: [issue13271] When -h is used with argparse,
	default values that fail should not matter
In-Reply-To: <1319664352.05.0.511704738067.issue13271@psf.upfronthosting.co.za>
Message-ID: <1319718508.92.0.055447314296.issue13271@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13271>
_______________________________________

From report at bugs.python.org  Thu Oct 27 14:28:47 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 27 Oct 2011 12:28:47 +0000
Subject: [issue13274] heapq pure python version uses islice without guarding
	for negative counts
In-Reply-To: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za>
Message-ID: <1319718527.27.0.0587181581859.issue13274@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13274>
_______________________________________

From report at bugs.python.org  Thu Oct 27 14:28:56 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 27 Oct 2011 12:28:56 +0000
Subject: [issue13275] Recommend xml.etree for XML processing
In-Reply-To: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za>
Message-ID: <1319718536.21.0.710649528914.issue13275@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13275>
_______________________________________

From report at bugs.python.org  Thu Oct 27 14:54:42 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 27 Oct 2011 12:54:42 +0000
Subject: [issue13274] heapq pure python version uses islice without guarding
	for negative counts
In-Reply-To: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za>
Message-ID: <1319720082.85.0.638420149684.issue13274@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13274>
_______________________________________

From report at bugs.python.org  Thu Oct 27 15:00:55 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 27 Oct 2011 13:00:55 +0000
Subject: [issue13033] Add shutil.chowntree
In-Reply-To: <1316769849.87.0.0298236424523.issue13033@psf.upfronthosting.co.za>
Message-ID: <1319720455.07.0.0334529808881.issue13033@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13033>
_______________________________________

From report at bugs.python.org  Thu Oct 27 15:54:43 2011
From: report at bugs.python.org (Arkadiusz Wahlig)
Date: Thu, 27 Oct 2011 13:54:43 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1319723684.0.0.861765437816.issue13188@psf.upfronthosting.co.za>


Arkadiusz Wahlig <arkadiusz.wahlig at gmail.com> added the comment:

I don't think this should be applied to 2.7.

In 2.x, the full exception info consists of the (type, value, traceback)-trio. Programmer is expected to pass this around to retain full exception info. Re-raising just the value (exception instance) using "raise value" starts a fresh traceback. Currently "raise" and gen.throw() behave the same in that regard and there's no reason to change that.

Python 3 reduces the exception info to one object by adding __traceback__ to the exception instance so it's reasonable to expect that "raise" and gen.throw() will be able to extract the full info from just the instance.

"raise" does that today, gen.throw() didn't, hence this bug report.

----------
nosy: +yak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Thu Oct 27 16:07:22 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 27 Oct 2011 14:07:22 +0000
Subject: [issue13272] 2to3 fix_renames doesn't rename
	string.lowercase/uppercase/letters
In-Reply-To: <1319700425.9.0.635731429373.issue13272@psf.upfronthosting.co.za>
Message-ID: <1319724442.49.0.288936073011.issue13272@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13272>
_______________________________________

From report at bugs.python.org  Thu Oct 27 16:08:57 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 27 Oct 2011 14:08:57 +0000
Subject: [issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__"
	chains
In-Reply-To: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za>
Message-ID: <1319724537.74.0.666640781848.issue13266@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13266>
_______________________________________

From report at bugs.python.org  Thu Oct 27 16:14:21 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 27 Oct 2011 14:14:21 +0000
Subject: [issue13253] 2to3 fix_renames renames sys.maxint only in imports
In-Reply-To: <1319437552.82.0.780264952493.issue13253@psf.upfronthosting.co.za>
Message-ID: <1319724861.57.0.933148541824.issue13253@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13253>
_______________________________________

From report at bugs.python.org  Thu Oct 27 16:38:04 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 27 Oct 2011 14:38:04 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <1319726284.91.0.306595528349.issue5661@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Uploaded the patch 'epipe-default.patch' with a test case that breaks
on linux when EPIPE is not handled by asyncore, which is the case with
Python 3.2 and previous versions.

----------
Added file: http://bugs.python.org/file23533/epipe-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Thu Oct 27 16:39:34 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 27 Oct 2011 14:39:34 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <1319726374.98.0.167587832549.issue5661@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Uploaded the same test case for Python 2.7.

----------
Added file: http://bugs.python.org/file23534/epipe-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Thu Oct 27 16:42:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Oct 2011 14:42:15 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <1319726535.95.0.608119496088.issue5661@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Thu Oct 27 16:49:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 14:49:39 +0000
Subject: [issue13244] WebSocket schemes in urllib.parse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319726979.62.0.52239539315.issue13244@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Is urlparse meant to follow the generic URI RFC?
No, it predates it.

> IMHO, the patch at least should do the equivalent of
> urlparse.uses_fragment.extend(wsschemes)
> so users of urlparse can do the checking for fragment != "", required for ws/wss on their own.
That?s probably the most urllib.parse can do, sadly.

> Alternative: make this bug dependent on fixing urlparse for fragment rules in generic
> URI RFC and don't do anything until then?
I?m not sure we can fix urllib.parse that way, because of backward compatibility concerns.  We might change the default handling (i.e. when parsing an unknown scheme) to comply with the RFC, but I?d much rather have a new, clean module.

> This kind of suggestion has come up before
I recall some discussion on that too.  Maybe we should bring it up again on python-dev?  I think I read a discussion from years ago where Guido learned that the URI syntax was now generic and that urlparse?s design was obsolete.  There was also someone else who had a new module (was it Nick?) implementing the RFC.  IIRC this module was not discussed for inclusion because urllib gained many tests for RFC compliance and was thought Good Enough?.

> There is a number of limitations if want to make the parser generic for any scheme. The
> difficult thing being the parsing behavior and requirements as defined by scheme. 
I don?t understand what you need.  If I get the RFC correctly, the point is that parsing rules are the same for any and all schemes, then it?s up to the application to refuse some component or do any other scheme-specific handling of the components.  But the parsing of a URI into components is the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Thu Oct 27 16:49:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 14:49:41 +0000
Subject: [issue13273] HTMLParser improperly handling open tags when strict is
	False
In-Reply-To: <1319702162.06.0.209889524007.issue13273@psf.upfronthosting.co.za>
Message-ID: <1319726981.63.0.101274312989.issue13273@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The attached patch fixes replaces search with match as you suggested and tweaks a regex to make the old tests pass.

----------
keywords: +patch
stage: test needed -> commit review
versions: +Python 2.7, Python 3.3
Added file: http://bugs.python.org/file23535/issue13273.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13273>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:11:32 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 27 Oct 2011 15:11:32 +0000
Subject: [issue13244] WebSocket schemes in urllib.parse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319728292.67.0.006791624926.issue13244@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Similar issue Issue7904 and 7da7f9bfdaac wherein the accepted way to parse x-newscheme://foo.com/stuff was added. Does the new ws:// scheme not fall under that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:15:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 15:15:03 +0000
Subject: [issue13244] WebSocket schemes in urllib.parse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319728503.7.0.00851766793703.issue13244@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:30:55 2011
From: report at bugs.python.org (francisco)
Date: Thu, 27 Oct 2011 15:30:55 +0000
Subject: [issue13276] distutils bdist_wininst created installer does not run
	the postinstallation script on uninstalling
Message-ID: <1319729455.78.0.312367178712.issue13276@psf.upfronthosting.co.za>


New submission from francisco <frandelapena at gmail.com>:

The bug can be reproduced by running the following command to create a Windows installer for the attached module:

python setup.py bdist_wininst --install-script pis.py

I include also the installer that I have created in the dist folder.

The installer installs everything correctly and it runs the pis.py script, which simply creates a file in the USERPROFILE directory with the "Installing" string. However, when uninstalling the program from the Windows Control Panel the script is not called, what can be verified by checking that the "Uninstalling" string is not appended to the file.

I am experiencing this problem in Windows 7 64 bits, but it may be present in other platforms.

----------
assignee: tarek
components: Distutils
files: foo.zip
messages: 146492
nosy: eric.araujo, francisco, tarek
priority: normal
severity: normal
status: open
title: distutils bdist_wininst created installer does not run the postinstallation script on uninstalling
versions: Python 2.7
Added file: http://bugs.python.org/file23536/foo.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13276>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:36:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 15:36:30 +0000
Subject: [issue13276] distutils bdist_wininst created installer does not run
	the postinstallation script on uninstalling
In-Reply-To: <1319729455.78.0.312367178712.issue13276@psf.upfronthosting.co.za>
Message-ID: <1319729790.07.0.524588261285.issue13276@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +loewis, mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13276>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:37:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 15:37:49 +0000
Subject: [issue13253] 2to3 fix_renames renames sys.maxint only in imports
In-Reply-To: <1319437552.82.0.780264952493.issue13253@psf.upfronthosting.co.za>
Message-ID: <1319729869.2.0.55339635287.issue13253@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do people really import maxint from sys?  I?d find that less readable than using sys.maxint ?which should, if you ask me, also be replaced :)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13253>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:38:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 15:38:29 +0000
Subject: [issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__"
	chains
In-Reply-To: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za>
Message-ID: <1319729909.4.0.753259323755.issue13266@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13266>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:39:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 15:39:09 +0000
Subject: [issue13274] heapq pure python version uses islice without guarding
	for negative counts
In-Reply-To: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za>
Message-ID: <1319729949.33.0.592702231885.issue13274@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> test needed
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13274>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:44:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 15:44:20 +0000
Subject: [issue13275] Recommend xml.etree for XML processing
In-Reply-To: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za>
Message-ID: <1319730260.53.0.431545944737.issue13275@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It makes sense that SAX and DOM would be mentioned in the tutorial: SAX is similar to how HTMLParser works and is used in many languages; DOM is the official W3C API and is used in many languages, despite its ugliness.  ElementTree is not a very elegant API in my opinion, but the majority seems to disagree as it was included in Python 2.5, so I wouldn?t object to a one-line edition in the doc to suggest it.

If you?d like to work on a doc patch, here are guidelines:
http://docs.python.org/documenting
http://docs.python.org/devguide

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13275>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:44:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 15:44:53 +0000
Subject: [issue13253] 2to3 fix_renames renames sys.maxint only in imports
In-Reply-To: <1319437552.82.0.780264952493.issue13253@psf.upfronthosting.co.za>
Message-ID: <1319730293.42.0.466781276795.issue13253@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I do (or at least did it in at least one place :).
I think the problem is actually more general, and I don't know if it's by design.
If a name in the import is changed, all the other occurrences of the name should be changed as well.  I don't know if 2to3 is powerful enough to recognize what occurrences should be left untouched (e.g. if I also have maxsize = 100 inside a function), and how difficult would it be to do it.
See also #13272.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13253>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:46:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 15:46:25 +0000
Subject: [issue13275] Recommend xml.etree for XML processing
In-Reply-To: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za>
Message-ID: <1319730385.88.0.339188850672.issue13275@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13275>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:46:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 15:46:43 +0000
Subject: [issue13271] When -h is used with argparse,
	default values that fail should not matter
In-Reply-To: <1319664352.05.0.511704738067.issue13271@psf.upfronthosting.co.za>
Message-ID: <1319730403.56.0.220918700758.issue13271@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d argue this is a behavior bug that could be fixed in 2.7 and 3.2 too, but Steven will decide.

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13271>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:47:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 15:47:57 +0000
Subject: [issue13270] all classes are new style
In-Reply-To: <1319663750.31.0.916391635164.issue13270@psf.upfronthosting.co.za>
Message-ID: <1319730477.39.0.946583559866.issue13270@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

LGTM.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13270>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:51:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 15:51:38 +0000
Subject: [issue4945] json checks True/False by identity, not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1319730698.08.0.25185800898.issue4945@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree with the request.  I don?t know if this behavior change can go into stable versions; Raymond will decide, as Bob seems to have retired from the maintenance of stdlib json.

----------
nosy: +eric.araujo, ezio.melotti, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:54:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 15:54:14 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319730854.24.0.840949858877.issue13263@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Thu Oct 27 17:55:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 15:55:29 +0000
Subject: [issue11440] fix_callable should be dropped from lib2to3 / changed
In-Reply-To: <1299600488.07.0.0466070744973.issue11440@psf.upfronthosting.co.za>
Message-ID: <1319730929.75.0.0985039816445.issue11440@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11440>
_______________________________________

From report at bugs.python.org  Thu Oct 27 18:03:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 16:03:56 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1319731436.84.0.934521461893.issue12641@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Would it be practical to have a trivial compilation test to see if we
> are capable of using GCC with -mno-cygwin and if so, use it, otherwise
> drop off? I think GNU autotools uses a similar strategy for detecting
> compiler capabilities.

The config command does such things, but the compiler classes don?t.  I?d prefer something more lightweight, like a version check (see msg141231).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Oct 27 18:11:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Oct 2011 16:11:16 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1319731876.86.0.122174520652.issue13248@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

distutils will not change.  I?ll ask if removing the deprecation warnings is okay, otherwise they?ll stay.

For ConfigParser.readfp, it would ease porting between 2.x and 3.x if the method could stay longer, or forever.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Thu Oct 27 18:40:07 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 27 Oct 2011 16:40:07 +0000
Subject: [issue13277] tzinfo subclasses information
Message-ID: <1319733607.49.0.8093265907.issue13277@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <senthil at uthcode.com>:

This was in the docs mailing list, not translated to bug report

Paul Koning wrote:

Section 8.1.6 of the library manual talks about utcoffset(dt)-dst(dt) as the "standard offset" and says that this should not depend on the date or +time but only on the location.

This is not true as there cases were certain locations changed the time offsets as per their convenience. 

It is either a doc fix to remove that sentence if the datetime.astimezone does not depend upon utcoffset(dt)-dst(dt), or if it does, then it is a code fix.

----------
assignee: docs at python
messages: 146501
nosy: docs at python, orsenthil
priority: normal
severity: normal
stage: needs patch
status: open
title: tzinfo subclasses information
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13277>
_______________________________________

From report at bugs.python.org  Thu Oct 27 18:43:56 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Thu, 27 Oct 2011 16:43:56 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1319733836.99.0.915149090725.issue7523@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Started implementing accept4() socket method and stuck on socket object's timeout attribute. What value should we assign to sock->sock_timeout if SOCK_NONBLOCK was specified in accept4() call? And in socket.py should we check as in original accept:
if getdefaulttimeout() is None and self.gettimeout():
    sock.setblocking(True)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Thu Oct 27 18:45:04 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Thu, 27 Oct 2011 16:45:04 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1319733904.89.0.319232231199.issue7523@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Sorry, wrong ticket. Right one is 10115

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Thu Oct 27 18:45:10 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Thu, 27 Oct 2011 16:45:10 +0000
Subject: [issue10115] Support accept4() for atomic setting of flags at socket
	creation
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1319733910.56.0.0679234438498.issue10115@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Started implementing accept4() socket method and stuck on socket object's timeout attribute. What value should we assign to sock->sock_timeout if SOCK_NONBLOCK was specified in accept4() call? And in socket.py should we check as in original accept:
if getdefaulttimeout() is None and self.gettimeout():
   sock.setblocking(True)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Thu Oct 27 18:47:49 2011
From: report at bugs.python.org (Paul)
Date: Thu, 27 Oct 2011 16:47:49 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1319734069.73.0.956477838041.issue6434@psf.upfronthosting.co.za>


Paul <paul.bauer.spearstone at gmail.com> added the comment:

This is a problem with python2.7 as well.  A change in struct between python2.6 and 2.7 raises an exception on overflow instead of silently allowing it.  This prevents zipping any file larger than 4.5G.  This exception concurs when writing the 32-bit headers (which are not used on large files anyway)

The patch should be simple.  Just wrap line 1100: 
...struct.pack("<LLL",...
with a try: except: to revert to the old behavior.   Alternatively, check if size is bigger than ZIP64_LIMIT and set to anything less than ZIP64_LIMIT.

----------
nosy: +Paul
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6434>
_______________________________________

From report at bugs.python.org  Thu Oct 27 18:49:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 16:49:35 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1319734175.09.0.192692804074.issue6434@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6434>
_______________________________________

From report at bugs.python.org  Thu Oct 27 18:53:43 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 27 Oct 2011 16:53:43 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1319734423.86.0.574671730171.issue13211@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Thu Oct 27 18:58:16 2011
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Thu, 27 Oct 2011 16:58:16 +0000
Subject: [issue13278] Typo in documentation for sched module
Message-ID: <1319734696.41.0.842696728904.issue13278@psf.upfronthosting.co.za>


New submission from Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com>:

In the documentation for the sched.scheduler.enter() function, change the phrase "Other then the relative time" to "Other than the relative time" (i.e. change "then" to "than").

----------
assignee: docs at python
components: Documentation
messages: 146506
nosy: docs at python, jfinkels
priority: normal
severity: normal
status: open
title: Typo in documentation for sched module
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13278>
_______________________________________

From report at bugs.python.org  Thu Oct 27 18:58:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 16:58:52 +0000
Subject: [issue13278] Typo in documentation for sched module
In-Reply-To: <1319734696.41.0.842696728904.issue13278@psf.upfronthosting.co.za>
Message-ID: <1319734732.06.0.576798346974.issue13278@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13278>
_______________________________________

From senthil at uthcode.com  Thu Oct 27 19:05:38 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Fri, 28 Oct 2011 01:05:38 +0800
Subject: [issue13208] Problems with urllib on windows
In-Reply-To: <1318966358.47.0.920729232412.issue13208@psf.upfronthosting.co.za>
References: <1318938589.99.0.598751159325.issue13208@psf.upfronthosting.co.za>
	<1318966358.47.0.920729232412.issue13208@psf.upfronthosting.co.za>
Message-ID: <20111027170538.GA1895@mathmagic>

The code is pretty straight forward and works on Linux. Is the problem
with the download? If you open the json file, is it a valid one?

From report at bugs.python.org  Thu Oct 27 19:05:53 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 27 Oct 2011 17:05:53 +0000
Subject: [issue13208] Problems with urllib on windows
In-Reply-To: <1318966358.47.0.920729232412.issue13208@psf.upfronthosting.co.za>
Message-ID: <20111027170538.GA1895@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The code is pretty straight forward and works on Linux. Is the problem
with the download? If you open the json file, is it a valid one?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13208>
_______________________________________

From report at bugs.python.org  Thu Oct 27 19:52:41 2011
From: report at bugs.python.org (Richard Saunders)
Date: Thu, 27 Oct 2011 17:52:41 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing compares
Message-ID: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>


New submission from Richard Saunders <RichIsMyName at mac.com>:

In discussions of memcmp performance, (http://www.picklingtools.com/study.pdf)
it was noted how well Python 2.7 can take advantage of faster memcmps (indeed, the rich comparisons are all memcmp calls).
There have been some discussion on python-dev at python.org as well.

With unicode and Python 3.3 (and anyPython 3.x) there are a 
few places we could call memcmp to make string comparisons faster, but they are not completely trivial.

Basically, if the unicode strings are "1 byte kind", then memcmp can be used almost as is.  If the unicode strings are the same kind, they can at least use memcmp to compare for equality or inequality.

There is also a minor optimization laying in unicode_compare: if you
are comparing two strings for equality/inequality, there is no reason to look at the entire string if the lengths are different.

These 3 minor optimizations can make unicode_compare faster.

----------
components: Interpreter Core
messages: 146508
nosy: RichIsMyName, asmodai, loewis, pitrou, scoder
priority: normal
severity: normal
status: open
title: Add memcmp into unicode_compare for optimizing compares
type: performance
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Thu Oct 27 19:53:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Oct 2011 17:53:31 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319738011.32.0.195641317952.issue13263@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think submodules are a good idea. In practice, for example, urllib.request.urlopen is more painful to use than good old urllib.urlopen.

If it's a matter of documentation, it can be split in several subchapters.
If it's a matter of organizing source code, it can also be split in several C files: see the _io module for an example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Thu Oct 27 19:58:17 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 27 Oct 2011 17:58:17 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <1319738297.93.0.746173035667.issue5661@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Did you try with the current branches?
AFAICT, this should have been solved by 208a5290fd38 (issue #11265), and I did a quick test with default and it seems to be fixed.
In any case, it's probably a good idea to add this test to test_asyncore.

> So it seems that, on linux, when writing to a closed socket, you get
> an ECONNRESET when there is still data in the socket, and an EPIPE
> otherwise. In the first case the tcp connection ends with a single
> RESET, and in the second case it ends with the sequence FIN-ACK-RESET.

Yes, see RFC1122 section 4.2.2.13:
"""
            A host MAY implement a "half-duplex" TCP close sequence, so
            that an application that has called CLOSE cannot continue to
            read data from the connection.  If such a host issues a
            CLOSE call while received data is still pending in TCP, or
            if new data is received after CLOSE is called, its TCP
            SHOULD send a RST to show that data was lost.
"""

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Thu Oct 27 19:58:55 2011
From: report at bugs.python.org (Richard Saunders)
Date: Thu, 27 Oct 2011 17:58:55 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing
	comparisons
In-Reply-To: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>
Message-ID: <1319738335.56.0.703860911621.issue13279@psf.upfronthosting.co.za>


Richard Saunders <RichIsMyName at mac.com> added the comment:

This is a potential patch: 
I believe it follows the C-style of PEP 7

There is a test as well, testing 1 and 2 byte kinds.

I have run it through the python tests and have added no new breakages
(there were some tests that failed, but they failed with and without the patch)

----------
keywords: +patch
title: Add memcmp into unicode_compare for optimizing compares -> Add memcmp into unicode_compare for optimizing comparisons
Added file: http://bugs.python.org/file23537/unicode_with_memcmp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Thu Oct 27 19:59:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Oct 2011 17:59:24 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319738364.39.0.252169865855.issue13263@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I agree about urllib.request.urlopen, but os.sched.get_priority_max() is not longer than os.sched_get_priority_max().
I also agree about the documentation -- that should be organized in several sections, regardless of what happens with the module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Thu Oct 27 20:09:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Oct 2011 18:09:07 +0000
Subject: [issue13263] Group some os functions in submodules
In-Reply-To: <1319738364.39.0.252169865855.issue13263@psf.upfronthosting.co.za>
Message-ID: <1319738695.3216.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I agree about urllib.request.urlopen, but os.sched.get_priority_max()
> is not longer than os.sched_get_priority_max().

Agreed. There are not many functions which could get this treatment,
though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13263>
_______________________________________

From report at bugs.python.org  Thu Oct 27 20:37:31 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 27 Oct 2011 18:37:31 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <1319740651.32.0.315486895161.issue5661@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> Did you try with the current branches?

Yes, the test is pass against the current default and 2.7 branches.
One must remove EPIPE from the asyncore._DISCONNECTED frozenset to
make the test to fail.


> Yes, see RFC1122 section 4.2.2.13:
> """
>             A host MAY implement a "half-duplex" TCP close sequence, so
>             that an application that has called CLOSE cannot continue to
>             read data from the connection.  If such a host issues a
>             CLOSE call while received data is still pending in TCP, or
>             if new data is received after CLOSE is called, its TCP
>             SHOULD send a RST to show that data was lost.
> """

Thanks for the pointer. Note that the "half-duplex" FIN-ACK-RESET
occurs when all received data has been read, and a single RESET is
sent when received data is still pending in the stream.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Thu Oct 27 21:31:10 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 27 Oct 2011 19:31:10 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319743870.57.0.577579035698.issue13218@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

On further reflection, I don't much like my second patch either.  I don't think it'll be portable.  I suggest just removing this test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Thu Oct 27 21:45:52 2011
From: report at bugs.python.org (Julian Berman)
Date: Thu, 27 Oct 2011 19:45:52 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319744752.05.0.0909228288988.issue13241@psf.upfronthosting.co.za>


Changes by Julian Berman <Julian+Python.org at GrayVines.com>:


----------
nosy: +Julian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Thu Oct 27 22:19:11 2011
From: report at bugs.python.org (Patrick Westerhoff)
Date: Thu, 27 Oct 2011 20:19:11 +0000
Subject: [issue13280] argparse should use the new Formatter class
Message-ID: <1319746751.8.0.206945992721.issue13280@psf.upfronthosting.co.za>


New submission from Patrick Westerhoff <PatrickWesterhoff at gmail.com>:

Hey,

according to PEP 3101, the new string.Formatter class is supposed to replace the old string formatting with %. At least that is what I was always thinking. Given that argparse is a Python 3.2+ exclusive module, I think it should make use of that new formatting method.

Is there any special reason why that is not the case and the old %-formatting is used? It feels a bit weird to have Python 3 code using only string.Formatter and then have a short section where the old formatter is used ? especially when that module was introduced with Python 3.2.

----------
components: Library (Lib)
messages: 146516
nosy: poke
priority: normal
severity: normal
status: open
title: argparse should use the new Formatter class
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13280>
_______________________________________

From report at bugs.python.org  Thu Oct 27 22:24:24 2011
From: report at bugs.python.org (Julian Berman)
Date: Thu, 27 Oct 2011 20:24:24 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319747064.14.0.951693105239.issue13241@psf.upfronthosting.co.za>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

I was unsuccessful building tip with any of the 3 compilers. Full paste of output from ./configure and make, along with haypo's test file are attached.

http://paste.pound-python.org/show/14320/

I'm on 10.7.2, XCode is 4.1 (compiler versions in the paste).

Upgrading to XCode 4.2 is undesirable, since it removes vanilla gcc. Myself and a few others are avoiding upgrading until homebrew adds vanilla gcc and / or Apple gets things fully sorted, so, being able to build with this would be nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Thu Oct 27 22:30:44 2011
From: report at bugs.python.org (Brian Bernstein)
Date: Thu, 27 Oct 2011 20:30:44 +0000
Subject: [issue13281] robotparser.RobotFileParser ignores rules preceeded by a
	blank line
Message-ID: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>


New submission from Brian Bernstein <bernie9998 at gmail.com>:

When attempting to parse a robots.txt file which has a blank line between allow/disallow rules, all rules after the blank line are ignored.

If a blank line occurs between the user-agent and its rules, all of the rules for that user-agent are ignored.

I am not sure if having a blank line between rules is allowed in the spec, but I am seeing this behavior in a number of sites, for instance:

http://www.whitehouse.gov/robots.txt has a blank line between the disallow rules all other lines, including the associated user-agent line, resulting in the python RobotFileParser to ignore all rules.

http://www.last.fm/robots.txt appears to separate their rules with arbitrary blank lines between them.  The python RobotFileParser only sees the first two rule between the user-agent and the next newline.

If the parser is changed to simply ignore all blank lines, would it have any adverse affect on parsing robots.txt files?

I am including a simple patch which ignores all blank lines and appears to find all rules from these robots.txt files.

----------
files: robotparser.py.patch
keywords: patch
messages: 146518
nosy: bernie9998
priority: normal
severity: normal
status: open
title: robotparser.RobotFileParser ignores rules preceeded by a blank line
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23538/robotparser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Thu Oct 27 23:12:10 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 27 Oct 2011 21:12:10 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319749930.51.0.787269416211.issue13241@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Julian, I am able to build and run the current default (3.3) tip (52b35dae22d1) on 10.7.2 with the gcc-4.2 from Xcode 4.1, with or without debug enabled.  Are you sure you have pulled all the latest updates and are using a clean build directory?  If so, please open a new issue showing the details and the exact ./configure command used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Thu Oct 27 23:42:56 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 27 Oct 2011 21:42:56 +0000
Subject: [issue13280] argparse should use the new Formatter class
In-Reply-To: <1319746751.8.0.206945992721.issue13280@psf.upfronthosting.co.za>
Message-ID: <1319751776.02.0.949364026065.issue13280@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Well argparse exists since 2006 (ref [1]), and "should work on Python >= 2.3" (ref [2]).
It was merged in the standard library with Python 3.2.

However, I agree we may switch to the advanced string formatting for this module.


[1] http://objectmix.com/python/180879-%5Bann%5D-argparse-module.html
[2] http://pypi.python.org/pypi/argparse#compatibility

----------
nosy: +flox
priority: normal -> low
versions:  -Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13280>
_______________________________________

From report at bugs.python.org  Thu Oct 27 23:55:35 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 27 Oct 2011 21:55:35 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1319752535.43.0.292717440191.issue13041@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
stage:  -> patch review
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13041>
_______________________________________

From report at bugs.python.org  Thu Oct 27 23:57:11 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 27 Oct 2011 21:57:11 +0000
Subject: [issue13280] argparse should use the new Formatter class
In-Reply-To: <1319746751.8.0.206945992721.issue13280@psf.upfronthosting.co.za>
Message-ID: <1319752631.82.0.369009016336.issue13280@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13280>
_______________________________________

From report at bugs.python.org  Thu Oct 27 23:58:06 2011
From: report at bugs.python.org (Julian Berman)
Date: Thu, 27 Oct 2011 21:58:06 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319752686.4.0.9916174833.issue13241@psf.upfronthosting.co.za>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

Never mind, yes, you're correct, somehow my build dir must have been dirty.

Sorry bout that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Fri Oct 28 00:01:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Oct 2011 22:01:16 +0000
Subject: [issue11183] Finer-grained exceptions for the ssl module
In-Reply-To: <1297418910.83.0.110389671752.issue11183@psf.upfronthosting.co.za>
Message-ID: <E1RJY0W-0006j9-Ts@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2c4a9c778bb3 by Antoine Pitrou in branch 'default':
Issue #11183: Add finer-grained exceptions to the ssl module, so that
http://hg.python.org/cpython/rev/2c4a9c778bb3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11183>
_______________________________________

From report at bugs.python.org  Fri Oct 28 00:03:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Oct 2011 22:03:54 +0000
Subject: [issue11183] Finer-grained exceptions for the ssl module
In-Reply-To: <1297418910.83.0.110389671752.issue11183@psf.upfronthosting.co.za>
Message-ID: <1319753034.46.0.0376527155568.issue11183@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed now.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11183>
_______________________________________

From report at bugs.python.org  Fri Oct 28 00:08:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Oct 2011 22:08:00 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319753280.44.0.195862098704.issue13218@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, both patches work fine here (Mageia 1, OpenSSL 1.0.0d).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Fri Oct 28 00:14:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Oct 2011 22:14:28 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing
	comparisons
In-Reply-To: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>
Message-ID: <1319753668.47.0.547785492712.issue13279@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ezio.melotti, haypo
stage:  -> patch review
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Fri Oct 28 00:16:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Oct 2011 22:16:08 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1319753768.82.0.840761790602.issue13188@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree with Arkadiusz, this doesn't seem to match Python 2's exception semantics, where you always specify the traceback explicitly if you want to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Fri Oct 28 00:17:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Oct 2011 22:17:33 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1319753853.05.0.0887861779024.issue6434@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.2, Python 3.3 -Python 2.4, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6434>
_______________________________________

From report at bugs.python.org  Fri Oct 28 00:24:26 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 27 Oct 2011 22:24:26 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319753280.44.0.195862098704.issue13218@psf.upfronthosting.co.za>
Message-ID: <20111027182416.3c1e9f2c@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Oct 27, 2011, at 10:08 PM, Antoine Pitrou wrote:

>Antoine Pitrou <pitrou at free.fr> added the comment:
>
>For the record, both patches work fine here (Mageia 1, OpenSSL 1.0.0d).

Cool.  I'll try to verify them on OS X 10.6 (and maybe 10.7).  If they work
there I'll figure out one of them to commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Fri Oct 28 00:26:37 2011
From: report at bugs.python.org (Paul)
Date: Thu, 27 Oct 2011 22:26:37 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1319754397.81.0.554894942994.issue6434@psf.upfronthosting.co.za>


Paul <paul.bauer.spearstone at gmail.com> added the comment:

I attempted to "re-allow overflow" in the struct(...) call by replacing `zinfo.file_size` with `ZIP64_LIMIT % zinfo.file_size` in zipfile.py, and successfully produced a compressed file from a 10G file, but the resulting compressed file could not be uncompressed and was deemed "invalid" by any unzip util I tried.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6434>
_______________________________________

From report at bugs.python.org  Fri Oct 28 00:39:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Oct 2011 22:39:23 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <1319755163.11.0.101213996797.issue10363@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch that fixes some of these handle leaks in Python 3.2.
However, as a general guideline, you shouldn't unload the Python DLL if you fish to use it later again. Just keep it in memory (the DLL isn't very big, is it?). Yes, C++ would allow to solve this, but the interpreter is currently written in C and there's no plan, even in the middle term, to change this.

----------
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file23539/freelocks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________

From report at bugs.python.org  Fri Oct 28 00:50:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Oct 2011 22:50:58 +0000
Subject: [issue13059] Sporadic test_multiprocessing failure: IOError("bad
	message length") in recv_bytes()
In-Reply-To: <1317300485.05.0.349182962077.issue13059@psf.upfronthosting.co.za>
Message-ID: <1319755858.0.0.397191025609.issue13059@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is a really weird error. At this point, the child is waiting for a challenge from the parent, and the challenge is something like 32 bytes long:

    message = os.urandom(MESSAGE_LENGTH)
    connection.send_bytes(CHALLENGE + message)

So, this can only mean, IMO, that someone else than the parent (another process?) is writing on the socket...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13059>
_______________________________________

From report at bugs.python.org  Fri Oct 28 04:01:26 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 28 Oct 2011 02:01:26 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1319767286.41.0.440553290972.issue13224@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

What's holding this up?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Fri Oct 28 05:09:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Oct 2011 03:09:07 +0000
Subject: [issue13274] heapq pure python version uses islice without guarding
	for negative counts
In-Reply-To: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za>
Message-ID: <1319771347.31.0.561223253752.issue13274@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The behavior is undefined for negative inputs, so implementations are free to the most expedient choices.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13274>
_______________________________________

From report at bugs.python.org  Fri Oct 28 05:11:20 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Oct 2011 03:11:20 +0000
Subject: [issue13270] all classes are new style
In-Reply-To: <1319663750.31.0.916391635164.issue13270@psf.upfronthosting.co.za>
Message-ID: <1319771480.92.0.903264498068.issue13270@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Removed the newstyle/oldstyle comments is fine.  I don't see the reason for the type->class change though.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13270>
_______________________________________

From report at bugs.python.org  Fri Oct 28 05:14:34 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Oct 2011 03:14:34 +0000
Subject: [issue13280] argparse should use the new Formatter class
In-Reply-To: <1319746751.8.0.206945992721.issue13280@psf.upfronthosting.co.za>
Message-ID: <1319771674.74.0.764904972465.issue13280@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

There's no reason to switch the implementation.  The % formatting isn't going away and we've decided against doing switch-overs in existing code (it risks introducing bugs while conferring zero benefits to users).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13280>
_______________________________________

From report at bugs.python.org  Fri Oct 28 06:56:32 2011
From: report at bugs.python.org (David Barnett)
Date: Fri, 28 Oct 2011 04:56:32 +0000
Subject: [issue13170] distutils2 test failures
In-Reply-To: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>
Message-ID: <1319777792.8.0.729640636988.issue13170@psf.upfronthosting.co.za>


David Barnett <davidbarnett2 at gmail.com> added the comment:

The remaining test (test_command_install_data.InstallDataTestCase.test_simple_run) was broken in r1152. What's happening is that the type of exception being raised was changed and it's getting through the try/except block in install_data.run().

Instead of calling shutil.copyfile, the code in 1152 is calling distutils2._backport.shutil.copyfile, which instead of raising a shutil.Error instance raises a distutils2._backport.shutil.Error instance.

Ideally, I think distutils2/_backport/shutil.py should do "from shutil import Error" instead of defining its own Error class, but I'm not sure if that's kosher for the way backports are supposed to work, and importing shutil from the stdlib is broken in that file besides.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Fri Oct 28 07:23:35 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 28 Oct 2011 05:23:35 +0000
Subject: [issue13188] generator.throw() ignores __traceback__ of exception
In-Reply-To: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za>
Message-ID: <1319779415.91.0.033551462738.issue13188@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Ok, I think we have reached a consensus. Closing.

----------
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13188>
_______________________________________

From report at bugs.python.org  Fri Oct 28 07:25:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 28 Oct 2011 05:25:37 +0000
Subject: [issue13277] tzinfo subclasses information
In-Reply-To: <1319733607.49.0.8093265907.issue13277@psf.upfronthosting.co.za>
Message-ID: <1319779537.61.0.955178808509.issue13277@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13277>
_______________________________________

From report at bugs.python.org  Fri Oct 28 07:26:15 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 28 Oct 2011 05:26:15 +0000
Subject: [issue13278] Typo in documentation for sched module
In-Reply-To: <1319734696.41.0.842696728904.issue13278@psf.upfronthosting.co.za>
Message-ID: <1319779575.68.0.643787526164.issue13278@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13278>
_______________________________________

From report at bugs.python.org  Fri Oct 28 07:31:02 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 28 Oct 2011 05:31:02 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing
	comparisons
In-Reply-To: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>
Message-ID: <1319779862.07.0.565894780866.issue13279@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Fri Oct 28 07:32:05 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 28 Oct 2011 05:32:05 +0000
Subject: [issue13280] argparse should use the new Formatter class
In-Reply-To: <1319746751.8.0.206945992721.issue13280@psf.upfronthosting.co.za>
Message-ID: <1319779925.18.0.511933408236.issue13280@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13280>
_______________________________________

From report at bugs.python.org  Fri Oct 28 07:32:58 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 28 Oct 2011 05:32:58 +0000
Subject: [issue13281] robotparser.RobotFileParser ignores rules preceeded by a
	blank line
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1319779978.24.0.480905564174.issue13281@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Fri Oct 28 07:43:24 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 28 Oct 2011 05:43:24 +0000
Subject: [issue13281] robotparser.RobotFileParser ignores rules preceeded by a
	blank line
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1319780604.01.0.380347410397.issue13281@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Blank lines are allowed according to the specification at http://www.robotstxt.org/norobots-rfc.txt, section 3.3 Formal Syntax.

The issue also seems to exist on 3.2 and 3.3.

----------
components: +Library (Lib)
keywords: +needs review
stage:  -> patch review
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Fri Oct 28 08:38:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 28 Oct 2011 06:38:34 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1319740651.32.0.315486895161.issue5661@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1Py9825BzwDL6WmPRHMNuNQK1UtsN9E9s8ZaD-Z_dHHA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

>> Did you try with the current branches?
>
> Yes, the test is pass against the current default and 2.7 branches.
> One must remove EPIPE from the asyncore._DISCONNECTED frozenset to
> make the test to fail.

OK. Then I'll add this test to test_asyncore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Fri Oct 28 08:54:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 28 Oct 2011 06:54:20 +0000
Subject: [issue13281] robotparser.RobotFileParser ignores rules preceeded by a
	blank line
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1319784860.65.0.600680765563.issue13281@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Fri Oct 28 10:17:35 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 28 Oct 2011 08:17:35 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1319789855.14.0.0274587326001.issue6745@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Fri Oct 28 10:17:40 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 28 Oct 2011 08:17:40 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1319789860.85.0.330492393121.issue12567@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Fri Oct 28 10:46:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Oct 2011 08:46:21 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319791581.15.0.304867954764.issue13218@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"./python -m test -v -u all test_ssl" pass with issue13218.diff or issue13218-true.diff on Ubuntu 10.10.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Fri Oct 28 10:49:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Oct 2011 08:49:29 +0000
Subject: [issue13059] Sporadic test_multiprocessing failure: IOError("bad
	message length") in recv_bytes()
In-Reply-To: <1317300485.05.0.349182962077.issue13059@psf.upfronthosting.co.za>
Message-ID: <1319791769.54.0.902501182876.issue13059@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@antoine: can you try to add more debug messages?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13059>
_______________________________________

From report at bugs.python.org  Fri Oct 28 10:52:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Oct 2011 08:52:45 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing
	comparisons
In-Reply-To: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>
Message-ID: <1319791965.63.0.369777775443.issue13279@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I would be nice to have a third path for inegality with kind1==kind2, something like:

else if (kind1 == PyUnicode_2BYTE_KIND && kind2 == PyUnicode_2BYTE_KIND)
{
  /* use Py_UCS2* pointers */
}
else if (kind1 == PyUnicode_4BYTE_KIND && kind2 == PyUnicode_4BYTE_KIND)
{
  /* use Py_UCS4* pointers */
}

Inegality comparaisons are used to sort Unicode lists for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Fri Oct 28 10:54:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Oct 2011 08:54:09 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing
	comparisons
In-Reply-To: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>
Message-ID: <1319792049.92.0.674115386978.issue13279@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> These 3 minor optimizations can make unicode_compare faster.

Can you please try to write a short benchmark script? (or just run a benchmark using ./python -m timeit)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Fri Oct 28 10:55:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 28 Oct 2011 08:55:08 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1319792108.57.0.514355617846.issue10570@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen
stage:  -> test needed
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10570>
_______________________________________

From report at bugs.python.org  Fri Oct 28 10:57:03 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 28 Oct 2011 08:57:03 +0000
Subject: [issue13270] all classes are new style
In-Reply-To: <1319663750.31.0.916391635164.issue13270@psf.upfronthosting.co.za>
Message-ID: <1319792223.56.0.359213920328.issue13270@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

the type>class change reflects the current output on 3.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13270>
_______________________________________

From report at bugs.python.org  Fri Oct 28 11:08:28 2011
From: report at bugs.python.org (Martin Dunschen)
Date: Fri, 28 Oct 2011 09:08:28 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1319755163.11.0.101213996797.issue10363@psf.upfronthosting.co.za>
Message-ID: <CAK55gbBfH40bJg-Lubknm7nMXmFpO0uB5EdXXi1EdZy_CPqcEw@mail.gmail.com>


Martin Dunschen <mdunschen at gmail.com> added the comment:

Hello Antoine

Unloading would not be necessary if the DLL is just the python interpreter,
but if you build a DLL with python embedded that does quite a bit more than
some python interpreting (in my case complex C/C++ numerical calculations)
unloading the DLL is a convenient way to free up unused resources. There are
C++ classes that extend python in my code (via swig), and that's where the
size of the DLL get's increased.

If the handle leaks are restricted to the windows implementation of cpython,
could it not be justified to allow C++ in a patch, I can't think of a C only
compiler for windows?

Thanks

Martin

On Thu, Oct 27, 2011 at 11:39 PM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Here is a patch that fixes some of these handle leaks in Python 3.2.
> However, as a general guideline, you shouldn't unload the Python DLL if you
> fish to use it later again. Just keep it in memory (the DLL isn't very big,
> is it?). Yes, C++ would allow to solve this, but the interpreter is
> currently written in C and there's no plan, even in the middle term, to
> change this.
>
> ----------
> keywords: +patch
> nosy: +loewis
> Added file: http://bugs.python.org/file23539/freelocks.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10363>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________

From report at bugs.python.org  Fri Oct 28 11:24:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Oct 2011 09:24:04 +0000
Subject: [issue13270] all classes are new style
In-Reply-To: <1319663750.31.0.916391635164.issue13270@psf.upfronthosting.co.za>
Message-ID: <E1RJifL-0004MG-MX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 54abca0ab03b by Florent Xicluna in branch '3.2':
Fixes #13270: obsolete reference to old-style/new-style classes.
http://hg.python.org/cpython/rev/54abca0ab03b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13270>
_______________________________________

From report at bugs.python.org  Fri Oct 28 11:27:34 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 28 Oct 2011 09:27:34 +0000
Subject: [issue13270] all classes are new style
In-Reply-To: <1319663750.31.0.916391635164.issue13270@psf.upfronthosting.co.za>
Message-ID: <1319794054.3.0.218547818844.issue13270@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13270>
_______________________________________

From report at bugs.python.org  Fri Oct 28 11:33:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Oct 2011 09:33:52 +0000
Subject: [issue13278] Typo in documentation for sched module
In-Reply-To: <1319734696.41.0.842696728904.issue13278@psf.upfronthosting.co.za>
Message-ID: <E1RJios-0005JN-DD@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3e72de3c8ad5 by Ezio Melotti in branch '2.7':
#13278: fix typo.
http://hg.python.org/cpython/rev/3e72de3c8ad5

New changeset 9c4b62f67a28 by Ezio Melotti in branch '3.2':
#13278: fix typo.
http://hg.python.org/cpython/rev/9c4b62f67a28

New changeset 64b2efa5009f by Ezio Melotti in branch 'default':
#13278: merge with 3.2.
http://hg.python.org/cpython/rev/64b2efa5009f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13278>
_______________________________________

From report at bugs.python.org  Fri Oct 28 11:36:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 28 Oct 2011 09:36:40 +0000
Subject: [issue13278] Typo in documentation for sched module
In-Reply-To: <1319734696.41.0.842696728904.issue13278@psf.upfronthosting.co.za>
Message-ID: <1319794600.62.0.919466478523.issue13278@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13278>
_______________________________________

From report at bugs.python.org  Fri Oct 28 12:00:11 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 28 Oct 2011 10:00:11 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1319796011.38.0.69850825913.issue1294232@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

After changeset c72063032a7a I get this complain:

Python/bltinmodule.c: In function ?builtin___build_class__?:
Python/bltinmodule.c:43: warning: unused variable ?nbases?

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Fri Oct 28 12:08:26 2011
From: report at bugs.python.org (wrobell)
Date: Fri, 28 Oct 2011 10:08:26 +0000
Subject: [issue13282] the table of contents in epub file is too long
Message-ID: <1319796506.79.0.347343158897.issue13282@psf.upfronthosting.co.za>


New submission from wrobell <wrobell at pld-linux.org>:

the table of contents in python documentation epub file is very very long. it takes several long minutes to jump from first page to a part containing language reference toc.

imho it would be great if first page of epub file contained pointers
to tutorial, lang ref, mod ref without detailed table of contents as it is at docs.python.org.

----------
assignee: docs at python
components: Documentation
messages: 146548
nosy: docs at python, wrobell
priority: normal
severity: normal
status: open
title: the table of contents in epub file is too long
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13282>
_______________________________________

From report at bugs.python.org  Fri Oct 28 12:14:23 2011
From: report at bugs.python.org (=?utf-8?q?Nicolas_=C3=89vrard?=)
Date: Fri, 28 Oct 2011 10:14:23 +0000
Subject: [issue13283] removal of two unused variable in locale.py
Message-ID: <1319796863.15.0.791142726242.issue13283@psf.upfronthosting.co.za>


New submission from Nicolas ?vrard <nicoe at no-log.org>:

While using pyflake on some of my file I noticed in a copied version of _group two unused variables.

The attached patch fixed that very little annoyance.

----------
components: Library (Lib)
files: locale.diff
keywords: patch
messages: 146549
nosy: nicoe
priority: normal
severity: normal
status: open
title: removal of two unused variable in locale.py
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file23540/locale.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13283>
_______________________________________

From report at bugs.python.org  Fri Oct 28 12:24:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Oct 2011 10:24:14 +0000
Subject: [issue13273] HTMLParser improperly handling open tags when strict is
	False
In-Reply-To: <1319702162.06.0.209889524007.issue13273@psf.upfronthosting.co.za>
Message-ID: <E1RJjbb-0000x2-Km@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 41d41776aa6d by Ezio Melotti in branch '3.2':
#13273: fix a bug that prevented HTMLParser to properly detect some tags when strict=False.
http://hg.python.org/cpython/rev/41d41776aa6d

New changeset b194117f176c by Ezio Melotti in branch 'default':
#13273: merge with 3.2.
http://hg.python.org/cpython/rev/b194117f176c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13273>
_______________________________________

From report at bugs.python.org  Fri Oct 28 12:26:04 2011
From: report at bugs.python.org (Burak Arslan)
Date: Fri, 28 Oct 2011 10:26:04 +0000
Subject: [issue13284] email.utils.formatdate function does not handle
	timezones correctly.
Message-ID: <1319797564.66.0.629117270841.issue13284@psf.upfronthosting.co.za>


New submission from Burak Arslan <burak.arslan at arskom.com.tr>:

There's an issue with email.utils.formatdate function, illustrated here: https://gist.github.com/1321994

for reference i'm on Europe/Istanbul timezone, which is +03:00 because of DST at the time of this writing.

I'm on stable Python 2.7.2 on gentoo linux. 

When I run the attached script, I get:

    Fri, 28 Oct 2011 07:56:14 -0000
    datetime.datetime(2011, 10, 28, 9, 56, 14, 945831, tzinfo=<UTC>)

when the local time is 12:56. so the second line is correct and first one is not.

let me know if you need any more information.
thanks for your attention.

----------
components: Library (Lib)
files: test_formatdate.py
messages: 146551
nosy: burak.arslan
priority: normal
severity: normal
status: open
title: email.utils.formatdate function does not handle timezones correctly.
versions: Python 2.7
Added file: http://bugs.python.org/file23541/test_formatdate.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13284>
_______________________________________

From report at bugs.python.org  Fri Oct 28 12:27:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 28 Oct 2011 10:27:48 +0000
Subject: [issue13273] HTMLParser improperly handling open tags when strict is
	False
In-Reply-To: <1319702162.06.0.209889524007.issue13273@psf.upfronthosting.co.za>
Message-ID: <1319797668.99.0.924335606741.issue13273@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks a lot for the report!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13273>
_______________________________________

From report at bugs.python.org  Fri Oct 28 13:18:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Oct 2011 11:18:56 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1319800736.14.0.249481086985.issue6877@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +benjamin.peterson, georg.brandl
Removed file: http://bugs.python.org/file16209/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Fri Oct 28 13:18:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Oct 2011 11:18:57 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1319800737.84.0.39038050523.issue6877@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16169/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Fri Oct 28 13:27:58 2011
From: report at bugs.python.org (Vilya Harvey)
Date: Fri, 28 Oct 2011 11:27:58 +0000
Subject: [issue13285] signal module in ignores external signal changes
Message-ID: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>


New submission from Vilya Harvey <vilya.harvey at gmail.com>:

The signal module is oblivious to any changes to the set of installed signal handlers which occur outside of the module. This can happen when a native module changes a signal handler, or when the python interpreter is embedded in another program which installs its own signal handlers.

In this case, saving and restoring a signal handler through python doesn't work correctly. For example, if the SIGINT handler is set externally after the signal module is initialised, the following code will replace the external signal handler with python's default_int_handler:

  handler = signal.getsignal(signal.SIGINT)
  signal.signal(signal.SIGINT, handler)

So it's impossible to reliably save and restore signal handlers through python when they can also be changed outside the python interpreter.

Also, if there's a signal handler installed before the module is initialised, signal.getsignal() will return None for it - making it impossible to restore the correct handler after disabling it.

The reason is that the signal module only checks for existing handlers when it's initialised. The results get stored in the Handlers array, which is then used by all subsequent calls to signal.getsignal(). There are no further checks to see whether the native signal handlers have changed.

----------
messages: 146553
nosy: vilya
priority: normal
severity: normal
status: open
title: signal module in ignores external signal changes
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13285>
_______________________________________

From report at bugs.python.org  Fri Oct 28 13:28:24 2011
From: report at bugs.python.org (Vilya Harvey)
Date: Fri, 28 Oct 2011 11:28:24 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1319801304.12.0.461653692396.issue13285@psf.upfronthosting.co.za>


Changes by Vilya Harvey <vilya.harvey at gmail.com>:


----------
title: signal module in ignores external signal changes -> signal module ignores external signal changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13285>
_______________________________________

From report at bugs.python.org  Fri Oct 28 14:06:35 2011
From: report at bugs.python.org (Burak Arslan)
Date: Fri, 28 Oct 2011 12:06:35 +0000
Subject: [issue13284] email.utils.formatdate function does not handle
	timezones correctly.
In-Reply-To: <1319797564.66.0.629117270841.issue13284@psf.upfronthosting.co.za>
Message-ID: <1319803595.43.0.202651684081.issue13284@psf.upfronthosting.co.za>


Burak Arslan <burak.arslan at arskom.com.tr> added the comment:

turns out timetuple was not passing timezone information. the correct way of converting a datetime.datetime object to a correct rfc-2822 compliant date string seems to be:

email.utils.formatdate(time.mktime(a.utctimetuple()) + 1e-6 * a.microsecond - time.timezone)

what a mess. if the above is indeed the right way to do this, is it possible to add the following function to the email.utils module?

def formatdatetime(dt_object):
    return email.utils.formatdate(time.mktime(dt_object.utctimetuple()) + 1e-6 * a.microsecond - time.timezone)

this works for datetime instances both with and without time zone information.

ps: i updated the code in the github link but not here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13284>
_______________________________________

From report at bugs.python.org  Fri Oct 28 14:23:17 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 28 Oct 2011 12:23:17 +0000
Subject: [issue13270] all classes are new style
In-Reply-To: <1319663750.31.0.916391635164.issue13270@psf.upfronthosting.co.za>
Message-ID: <1319804597.41.0.875323855562.issue13270@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13270>
_______________________________________

From report at bugs.python.org  Fri Oct 28 14:28:15 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 28 Oct 2011 12:28:15 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319804895.08.0.271643141584.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I realised I could use the convert_field() option in the custom formatter to choose between several interpolation quoting options:

  default - str + shutil.quote_ascii_whitespace
  !q - str + shlex.quote
  !u - unquoted (i.e. no conversion, str.format default behaviour)
  !s - str (as usual)
  !r - repr (as usual)

The most recent commit also exposes public APIs for the formatting aspects (shutil.quote_ascii_whitespace, shutil.shell_format, shutil.shell_format_map)

----------
keywords: +patch
Added file: http://bugs.python.org/file23542/issue13238_shell_helpers.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Fri Oct 28 14:31:12 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 28 Oct 2011 12:31:12 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319805072.92.0.46382346926.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Some examples:

>>> import shutil
>>> shutil.shell_call("du -hs {}", "../py*")
594M    ../py3k
579M    ../py3k_pristine
480M    ../python27
301M    ../python31
382M    ../python32
288K    ../python_swallowed_whole
0
>>> shutil.shell_call("du -hs {!q}", "../py*")
du: cannot access `../py*': No such file or directory
1
>>> shutil.shell_call("ls {}", "no file")
ls: cannot access no file: No such file or directory
2
>>> shutil.shell_call("ls {!u}", "no file")
ls: cannot access no: No such file or directory
ls: cannot access file: No such file or directory
2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Fri Oct 28 14:53:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Oct 2011 12:53:43 +0000
Subject: [issue13258] replace hasattr(obj, '__call__') with callable(obj)
In-Reply-To: <1319485575.06.0.0356181366596.issue13258@psf.upfronthosting.co.za>
Message-ID: <E1RJlwF-00052o-5m@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8e57b5d8f58f by Florent Xicluna in branch '3.2':
Closes #13258: Use callable() built-in in the standard library.
http://hg.python.org/cpython/rev/8e57b5d8f58f

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13258>
_______________________________________

From report at bugs.python.org  Fri Oct 28 15:07:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Oct 2011 13:07:08 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <E1RJm9F-0006Es-Nj@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b9bb9340eb0c by Florent Xicluna in branch 'default':
Merge 3.2 (linked to issue #1294232)
http://hg.python.org/cpython/rev/b9bb9340eb0c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Fri Oct 28 15:51:20 2011
From: report at bugs.python.org (Tobias Oberstein)
Date: Fri, 28 Oct 2011 13:51:20 +0000
Subject: [issue13244] WebSocket schemes in urllib.parse
In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za>
Message-ID: <1319809880.94.0.832512540755.issue13244@psf.upfronthosting.co.za>


Tobias Oberstein <tobias.oberstein at tavendo.de> added the comment:

Is that patch supposed to be in Python 2.7.2?

If so, it doesn't work for "ws":

"ws://example.com/somewhere?foo=bar#dgdg"

F:\scm\Autobahn\testsuite\websockets\servers>python
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from urlparse import urlparse
>>> urlparse("ws://example.com/somewhere?foo=bar#dgdg")
ParseResult(scheme='ws', netloc='example.com', path='/somewhere?foo=bar#dgdg', params='', query='', fragment='')
>>> urlparse("ws://example.com/somewhere?foo=bar#dgdg", allow_fragments = True)
ParseResult(scheme='ws', netloc='example.com', path='/somewhere?foo=bar#dgdg', params='', query='', fragment='')
>>> urlparse("ws://example.com/somewhere?foo=bar#dgdg", allow_fragments = False)
ParseResult(scheme='ws', netloc='example.com', path='/somewhere?foo=bar#dgdg', params='', query='', fragment='')
>>>

urlparse will neither parse the query nor the (invalid) fragment component for the "ws" scheme

I would have expected

ParseResult(scheme='ws', netloc='example.com', path='/somewhere', params='', query='foo=bar', fragment='dgdg')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13244>
_______________________________________

From report at bugs.python.org  Fri Oct 28 16:01:07 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 28 Oct 2011 14:01:07 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1319810467.76.0.418658140835.issue13285@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> So it's impossible to reliably save and restore signal handlers through 
> python when they can also be changed outside the python interpreter.

signal.getsignal() or signal.signal() return the current/previous handler as a Python function. How could it return a reference to a native (i.e. C) signal handler?
While we could in theory return it as a magic cookie (i.e. the handler's address as returned by sigaction/signal) that can just be passed back to signal.signal(), it would be a bad idea: if the user passes an invalid address, the process will crash when the signal is received.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13285>
_______________________________________

From report at bugs.python.org  Fri Oct 28 16:02:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Oct 2011 14:02:14 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1319810534.73.0.585742505265.issue13285@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13285>
_______________________________________

From report at bugs.python.org  Fri Oct 28 16:14:13 2011
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Fri, 28 Oct 2011 14:14:13 +0000
Subject: [issue13278] Typo in documentation for sched module
In-Reply-To: <1319794600.62.0.919466478523.issue13278@psf.upfronthosting.co.za>
Message-ID: <CAHz=fgB4OHEdRjuDMK=dkm7yygQYRuwd59WdyA4J+27bBRUtrg@mail.gmail.com>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

Thank you for the great work, Python project!

On Fri, Oct 28, 2011 at 5:36 AM, Ezio Melotti <report at bugs.python.org> wrote:
>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> Fixed, thanks for the report!
>
> ----------
> assignee: docs at python -> ezio.melotti
> resolution: ?-> fixed
> stage: ?-> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13278>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13278>
_______________________________________

From report at bugs.python.org  Fri Oct 28 16:18:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Oct 2011 14:18:50 +0000
Subject: [issue13286] PEP 3151 breaks backward compatibility: it should be
	documented
Message-ID: <1319811530.69.0.689775391155.issue13286@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following example works on Python 2.7 and 3.2, but fails on Python 3.3:
-----------
import errno
import os

try:
    os.rmdir("testdir")
except:
    pass
os.mkdir("testdir")

try:
    try:
        os.mkdir("testdir")
    except IOError as exc:
        # If can't get proper access, then just forget about writing
        # the data.
        if exc.errno == errno.EACCES:
            pass
        else:
            raise
    except OSError as exc:
        # Probably another Python process already created the dir.
        if exc.errno == errno.EEXIST:
            pass
        else:
            raise
except Exception:
    print("PEP 3151 broke backward compatibility on such pattern!")
-----------

I noticed the problem while reading the changeset e4d44c2e8e81.

----------
assignee: docs at python
components: Documentation
messages: 146562
nosy: docs at python, flox, haypo, pitrou
priority: normal
severity: normal
status: open
title: PEP 3151 breaks backward compatibility: it should be documented
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13286>
_______________________________________

From report at bugs.python.org  Fri Oct 28 16:24:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Oct 2011 14:24:35 +0000
Subject: [issue13286] PEP 3151 breaks backward compatibility: it should be
	documented
In-Reply-To: <1319811530.69.0.689775391155.issue13286@psf.upfronthosting.co.za>
Message-ID: <1319811875.51.0.601383944396.issue13286@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why would you catch IOError after os.mkdir()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13286>
_______________________________________

From report at bugs.python.org  Fri Oct 28 16:25:11 2011
From: report at bugs.python.org (Vilya Harvey)
Date: Fri, 28 Oct 2011 14:25:11 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1319811911.15.0.800009051595.issue13285@psf.upfronthosting.co.za>


Vilya Harvey <vilya.harvey at gmail.com> added the comment:

Could it return an opaque wrapper object, rather than just the raw address? Something like:

typedef struct _PyNativeSignalHandler {
  PyObject_HEAD
  sighandler_t handler_func;
} PyNativeSignalHandler;

where the type object doesn't expose any way to read or manipulate the handler_func. Would that work, do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13285>
_______________________________________

From report at bugs.python.org  Fri Oct 28 16:32:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Oct 2011 14:32:53 +0000
Subject: [issue13286] PEP 3151 breaks backward compatibility: it should be
	documented
In-Reply-To: <1319811530.69.0.689775391155.issue13286@psf.upfronthosting.co.za>
Message-ID: <1319812373.27.0.956000617592.issue13286@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The first example was extracted from Lib/importlib/_bootstrap.py. The code was maybe wrong, I don't know.

Another example:
----------------------
import errno
import os

try:
    os.rmdir("testdir")
except:
    pass
os.mkdir("testdir")

try:
    try:
        #os.mkdir("testdir")
        open("NOT EXISTING FILENAME")
    except OSError as exc:
        if exc.errno == errno.EEXIST:
            pass
        else:
            raise
    except IOError as exc:
        if exc.errno == errno.ENOENT:
            pass
        else:
            raise
except Exception:
    raise
    print("PEP 3151 broke backward compatibility on such pattern!")
----------------------

Uncomment mkdir() to test both paths.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13286>
_______________________________________

From report at bugs.python.org  Fri Oct 28 16:44:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 Oct 2011 14:44:39 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1319813079.57.0.16365734166.issue13224@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Guido]
> What's holding this up?

- I haven?t updated the patch for function and module objects yet
- I need to catch up with the python-ideas discussion
- There is at least one strong argument against the idea (I?ll point it out on the ML)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Fri Oct 28 16:50:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 Oct 2011 14:50:20 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319813420.64.0.785650332834.issue13238@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The custom formatter idea sounds brilliant.  Can you test that auto-escaping of spaces works well with glob patterns?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Fri Oct 28 17:01:15 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 28 Oct 2011 15:01:15 +0000
Subject: [issue13287] urllib.request exposes too many names
Message-ID: <1319814075.5.0.569025067527.issue13287@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

>>> len(dir())
4
>>> import urllib.request import *
>>> len(dir())
88


In this list we find 14 modules:
['base64', 'collections', 'ssl', 'bisect', 'http', 're', 'email', 'socket', 'os', 'posixpath', 'hashlib', 'io', 'time', 'sys']

And many non-documented functions:
 - ftperrors
 - getproxies_environment
 - getproxies_macosx_sysconf
 - localhost
 - noheaders
 - parse_http_list
 - parse_keqv_list
 - proxy_bypass
 - proxy_bypass_environment
 - proxy_bypass_macosx_sysconf
 - quote
 - randombytes
 - request_host
 - urlunparse
 - splitattr
 - splithost
 - splitpasswd
 - splitport
 - splitquery
 - splittag
 - splittype
 - splituser
 - splitvalue
 - thishost
 - to_bytes
 - unquote
 - unwrap
 - urljoin
 - urlparse
 - urlsplit

It may be good to define __all__ for this module, and to preprend "_" on some of these names.

----------
components: Library (Lib)
messages: 146568
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.request exposes too many names
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13287>
_______________________________________

From report at bugs.python.org  Fri Oct 28 17:11:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Oct 2011 15:11:14 +0000
Subject: [issue13287] urllib.request exposes too many names
In-Reply-To: <1319814075.5.0.569025067527.issue13287@psf.upfronthosting.co.za>
Message-ID: <1319814674.84.0.504164734395.issue13287@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13287>
_______________________________________

From report at bugs.python.org  Fri Oct 28 17:18:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 Oct 2011 15:18:33 +0000
Subject: [issue13170] distutils2 test failures
In-Reply-To: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>
Message-ID: <1319815113.97.0.284828117462.issue13170@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The remaining test (test_command_install_data.InstallDataTestCase.test_simple_run) was
> broken in r1152.
This looks like a local revision number, which has no meaning outside of one specific repository.  What is the changeset identifier?  (see http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html#id345536)

Thanks for the diagnosis!  Code calling functions from the backported shutil should obviously catch exceptions from the backported shutil.  I?ll review all modules using the backport.

FYI, some distutils2 modules use shutil from the stdlib, for functions that are already here in 2.4; not sure if that is good or bad.

> Ideally, I think distutils2/_backport/shutil.py should do "from shutil import Error"
> instead of defining its own Error class
Oh, no, our backported module is strictly independent from the stdlib one.

> importing shutil from the stdlib is broken in that file besides.
I don?t understand this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Fri Oct 28 17:21:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Oct 2011 15:21:38 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319815298.56.0.679227092753.issue13238@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>  default - str + shutil.quote_ascii_whitespace
>  !q - str + shlex.quote
>  !u - unquoted (i.e. no conversion, str.format default behaviour)

The default doesn't look very understandable to me. Why would you quote only some characters and not all of them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Fri Oct 28 17:23:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 28 Oct 2011 15:23:33 +0000
Subject: [issue13287] urllib.request exposes too many names
In-Reply-To: <1319814075.5.0.569025067527.issue13287@psf.upfronthosting.co.za>
Message-ID: <1319815413.63.0.635843649954.issue13287@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is technically backward incompatible, so if we define an __all__ with most of these names, we are officially making them public, if we leave them out, from urllib.request import * will break for someone.
You could argue that import * is discouraged though.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13287>
_______________________________________

From report at bugs.python.org  Fri Oct 28 17:26:53 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 28 Oct 2011 15:26:53 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1319815613.09.0.10472953547.issue13241@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Fri Oct 28 18:06:38 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 28 Oct 2011 16:06:38 +0000
Subject: [issue13287] urllib.request exposes too many names
In-Reply-To: <1319815413.63.0.635843649954.issue13287@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOSwN0o39m82rtVVg2zySOPajkrqjXTrneR4OsLXaCGYLA@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Let's deprecate some of these (or add deprecation warnings) for
upcoming release.  But, doing from xxx import * is not a recommended
way for any module, as we know that it stands to pollute the namespace
with unneccesary functions/methods. I would be careful in adding
anything to __all__ and if done, may go for only 3.3. Ezio has a valid
point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13287>
_______________________________________

From report at bugs.python.org  Fri Oct 28 19:24:34 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Oct 2011 17:24:34 +0000
Subject: [issue13257] Move importlib over to PEP 3151 exceptions
In-Reply-To: <1319483811.65.0.194402902365.issue13257@psf.upfronthosting.co.za>
Message-ID: <1319822674.61.0.0299268132274.issue13257@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Florent inadvertently did this for me in rev 73169.

----------
resolution:  -> fixed
stage: needs patch -> 
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13257>
_______________________________________

From report at bugs.python.org  Fri Oct 28 20:01:52 2011
From: report at bugs.python.org (David Barnett)
Date: Fri, 28 Oct 2011 18:01:52 +0000
Subject: [issue13170] distutils2 test failures
In-Reply-To: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>
Message-ID: <1319824912.04.0.598558583219.issue13170@psf.upfronthosting.co.za>


David Barnett <davidbarnett2 at gmail.com> added the comment:

>> The remaining test (test_command_install_data.InstallDataTestCase.test_simple_run) was
>> broken in r1152.
>This looks like a local revision number, which has no meaning outside of one specific repository.  What is the changeset identifier?  (see http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html#id345536)
Oh, sorry, it's d1d251292ee7. (I got the short rev from the hg.python.org interface, so I thought it would be "authoritative" enough, but I guess it is ambiguous)

>> importing shutil from the stdlib is broken in that file besides.
> I don?t understand this.
When I do "import shutil" inside _backport/shutil.py, it seems to be importing itself (??) if I don't explicitly enable absolute imports (in python 2.7). If I delete the "class Error" definition and instead add "from shutil import Error", I get an ImportError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Fri Oct 28 20:50:01 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 28 Oct 2011 18:50:01 +0000
Subject: [issue13283] removal of two unused variable in locale.py
In-Reply-To: <1319796863.15.0.791142726242.issue13283@psf.upfronthosting.co.za>
Message-ID: <1319827801.09.0.766219350967.issue13283@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13283>
_______________________________________

From report at bugs.python.org  Fri Oct 28 21:33:09 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 28 Oct 2011 19:33:09 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319830389.73.0.908862724805.issue13218@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I can't test this on OS X 10.7 because of issue 13241 but it works fine on OS X 10.6.

I'm going to go with the first diff (i.e. the non-sense changing version).  I can't say why I favor that version but since you've both verified it works on !Ubuntu, we'll go with that and let people scream if it starts failing for them.  I'll apply to 3.2 and 3.3, back port to 2.7, and then watch the buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Fri Oct 28 21:49:14 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 28 Oct 2011 19:49:14 +0000
Subject: [issue13287] urllib.request exposes too many names
In-Reply-To: <1319814075.5.0.569025067527.issue13287@psf.upfronthosting.co.za>
Message-ID: <1319831354.21.0.203532958799.issue13287@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

We should only expose the names which are documented.
The modules and the objects from urllib.parse don't need to be exposed in urllib.request.

I suggest to apply this patch on 3.3 only.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23543/issue13287_urllib_request.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13287>
_______________________________________

From report at bugs.python.org  Fri Oct 28 22:52:51 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 28 Oct 2011 20:52:51 +0000
Subject: [issue13283] removal of two unused variable in locale.py
In-Reply-To: <1319796863.15.0.791142726242.issue13283@psf.upfronthosting.co.za>
Message-ID: <1319835171.06.0.84936256511.issue13283@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This patch looks good.
Is it relevant for minor releases 2.7.3 and 3.2.3? I cannot confirm.

----------
nosy: +flox
priority: normal -> low
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13283>
_______________________________________

From report at bugs.python.org  Fri Oct 28 22:55:48 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 28 Oct 2011 20:55:48 +0000
Subject: [issue13286] PEP 3151 breaks backward compatibility: it should be
	documented
In-Reply-To: <1319811530.69.0.689775391155.issue13286@psf.upfronthosting.co.za>
Message-ID: <1319835348.78.0.799018840343.issue13286@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13286>
_______________________________________

From report at bugs.python.org  Fri Oct 28 22:57:54 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 28 Oct 2011 20:57:54 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1319835474.73.0.308580413824.issue6877@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Fri Oct 28 23:08:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Oct 2011 21:08:32 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <E1RJtf7-0008Fr-Ev@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3c225f938dae by Barry Warsaw in branch '2.7':
- Issue #13218: Fix test_ssl failures on Debian/Ubuntu.
http://hg.python.org/cpython/rev/3c225f938dae

New changeset 415e2c998e18 by Barry Warsaw in branch '3.2':
- Issue #13218: Fix test_ssl failures on Debian/Ubuntu.
http://hg.python.org/cpython/rev/415e2c998e18

New changeset 7a241bc34dd7 by Barry Warsaw in branch '3.2':
- Issue #13218: Fix test_ssl failures on Debian/Ubuntu.
http://hg.python.org/cpython/rev/7a241bc34dd7

New changeset 472219ffa1d7 by Barry Warsaw in branch 'default':
- Issue #13218: Fix test_ssl failures on Debian/Ubuntu.
http://hg.python.org/cpython/rev/472219ffa1d7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Fri Oct 28 23:12:22 2011
From: report at bugs.python.org (John Nagle)
Date: Fri, 28 Oct 2011 21:12:22 +0000
Subject: [issue13288] SSL module doesn't allow access to cert issuer
	information
Message-ID: <1319836342.01.0.0498331341848.issue13288@psf.upfronthosting.co.za>


New submission from John Nagle <nagle at users.sourceforge.net>:

The SSL module still doesn't return much information from the
certificate.  SSLSocket.getpeercert only returns a few basic items
about the certificate subject.  You can't retrieve issuer information,
and you can't get the extensions needed to check if a cert is an EV cert.

With the latest flaps about phony cert issuers, (another CA compromise hit the news today) it's worth having issuer info available.
It was available in the old M2Crypto module, but not in the current Python SSL module.

                                John Nagle

----------
components: Library (Lib)
messages: 146579
nosy: nagle
priority: normal
severity: normal
status: open
title: SSL module doesn't allow access to cert issuer information
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13288>
_______________________________________

From report at bugs.python.org  Fri Oct 28 23:34:16 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 28 Oct 2011 21:34:16 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1319837656.33.0.805564227748.issue13285@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
components: +Library (Lib)
nosy: +flox
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13285>
_______________________________________

From report at bugs.python.org  Sat Oct 29 00:06:43 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 28 Oct 2011 22:06:43 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319839603.1.0.524460438565.issue13218@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Sat Oct 29 01:12:58 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 28 Oct 2011 23:12:58 +0000
Subject: [issue2892] improve cElementTree iterparse error handling
In-Reply-To: <1210940435.5.0.243679200602.issue2892@psf.upfronthosting.co.za>
Message-ID: <1319843578.82.0.958035904204.issue2892@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

unfortunately, I did not find the fix and the test in the upstream repository.

AFAIK, upstream should be there:
https://bitbucket.org/effbot/et-2009-provolone/src

----------
components: +XML -Extension Modules
type: feature request -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2892>
_______________________________________

From report at bugs.python.org  Sat Oct 29 01:42:06 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Oct 2011 23:42:06 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1319845326.11.0.627839036438.issue13248@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The difflib deprecations are mine and I think they should happen in 3.3.
This will serve as a reminder.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Sat Oct 29 01:56:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Oct 2011 23:56:37 +0000
Subject: [issue13262] IDLE opens partially hidden
In-Reply-To: <1319538134.39.0.210129529894.issue13262@psf.upfronthosting.co.za>
Message-ID: <1319846197.16.0.730196433355.issue13262@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree and commented about this on some previous issue (which I cannot find now). I actually would like it to save the window position and size.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13262>
_______________________________________

From report at bugs.python.org  Sat Oct 29 02:24:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Oct 2011 00:24:19 +0000
Subject: [issue13275] Recommend xml.etree for XML processing
In-Reply-To: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za>
Message-ID: <1319847859.26.0.0404629548836.issue13275@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In the tutorial, "The xml.dom and xml.sax packages" should be expanded to "The xml.dom, xml.sax, and xml.etree packages". I suspect that the current line predates the addition of .etree.

We try to mostly not give opinion-based recommendations; the docs are for facts. Some people recommend using lxml instead of any of the above ;-).

"The documentation for the xml.dom and xml.sax packages are the definition of the Python bindings for the DOM and SAX interfaces."

could be followed by a factual sentence like "xml.etree provides an  third alternative."

Looking more: the intro to 19.6. xml.dom ? The Document Object Model API nicely explains the difference between SAX and DOM processing as sequential versus random access. The intro to 19.13. xml.etree.ElementTree ? The ElementTree XML API says nothing about how it compares to the others. Perhaps the sentence should be "xml.etree provides a tree-based interface different from xml.dom." (assuming this is a fact). Make your suggestion.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13275>
_______________________________________

From report at bugs.python.org  Sat Oct 29 02:29:28 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 00:29:28 +0000
Subject: [issue2892] improve cElementTree iterparse error handling
In-Reply-To: <1210940435.5.0.243679200602.issue2892@psf.upfronthosting.co.za>
Message-ID: <1319848168.37.0.795941366431.issue2892@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Proposed patch for 3.3.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23544/issue2892_etree_iterparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2892>
_______________________________________

From report at bugs.python.org  Sat Oct 29 03:05:03 2011
From: report at bugs.python.org (James Burgess)
Date: Sat, 29 Oct 2011 01:05:03 +0000
Subject: [issue1681674] subprocess.Popen fails with socket._fileobject on
	Windows
Message-ID: <1319850303.54.0.0266873802592.issue1681674@psf.upfronthosting.co.za>


James Burgess <jamestreborburgess at gmail.com> added the comment:

"Can't Fix" that is not true. 

I've just fixed this in 2.7 with a trivial change to subprocesss.py, I think it'd work in over versions too.

Note that type shenanigans are already in play in _get_handles, it's looking at the types of the parameters being passed in to decide how to get a hold of the "handle". The socket module makes a duck type of the file object. The fileno() method of the socket object returns a handle not a CRT file descriptor. This is exactly the kind of handle that _get_handles() is looking for.

So all that is needed is one more "if" to the sequence of how to get the "handle" which for a socket object would be just stdin.fileno() etc.

I've just tested this in a fairly complicated remote job queuing software (a commercial product) that has the ability to connect the spooler (on one machine) with an arbitrary server machine (linux, osx and now windows) via a socket. The job is launched with subprocess.Popen and sockets are wired into the stdin,stdout and stderr. Works beautifully now.

I've attached a patch file made with:
$ diff -c subprocess.py.ORIG subprocess.py  > subprocess.py.patch

Apply with:
$ cd  Python-2.7.1/Lib ; patch -p0 < c:/temp/subprocess.py.patch

Cheers,
- James

----------
keywords: +patch
nosy: +James.Burgess
Added file: http://bugs.python.org/file23545/subprocess.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1681674>
_______________________________________

From report at bugs.python.org  Sat Oct 29 03:06:25 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Oct 2011 01:06:25 +0000
Subject: [issue13281] robotparser.RobotFileParser ignores rules preceeded by a
	blank line
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1319850385.04.0.516165867155.issue13281@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Because of the line break, clicking that link gives "Server error 404".
http://www.robotstxt.org/norobots-rfc.txt
works (so please pay attention to formatting). The main page is
http://www.robotstxt.org/robotstxt.html 

The way I read the grammar, 'records' (which start with an agent line) cannot have blank lines and must be separated by blank lines. Other than than, the suggestion seems reasonable, but it also seems like a feature request. Does test/test_robotparser pass with the patch?

I also do not see "Crawl-delay" and "Sitemap" (from whitehouse.gov) in the grammar referenced above. So I wonder if de facto practice has evolved.

Philip S.: do you have any opinions?
(I am asking you because of your comments on #1437699.)

----------
nosy: +osvenskan, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Sat Oct 29 03:09:28 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 01:09:28 +0000
Subject: [issue7334] ElementTree: file locking in Jython 2.5 (OSError on
	Windows)
In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>
Message-ID: <1319850568.97.0.72519444088.issue7334@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Changeset cff78ffb932a fixed the issue for 3.2.
I will consider backporting.

----------
resolution:  -> fixed
stage: needs patch -> patch review
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7334>
_______________________________________

From report at bugs.python.org  Sat Oct 29 03:39:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 29 Oct 2011 01:39:41 +0000
Subject: [issue7334] ElementTree: file locking in Jython 2.5 (OSError on
	Windows)
In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>
Message-ID: <E1RJxtW-0000mn-RT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset eceaa31252b3 by Florent Xicluna in branch '2.7':
Closes #7334: close source files on ElementTree.parse and iterparse (partial backport of issue #10093 from 3.2).
http://hg.python.org/cpython/rev/eceaa31252b3

----------
nosy: +python-dev
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7334>
_______________________________________

From report at bugs.python.org  Sat Oct 29 03:40:15 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Oct 2011 01:40:15 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319852415.39.0.944796154343.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The first version I wrote *did* automatically invoke shlex.quote on all interpolated values, but that breaks wildcard handling. You can see that in the examples I posted above. With the default whitespace escaping (which allows spaces in filenames), wildcard matching still works (thus the list of directories matching the "../py*" pattern), but with full quoting it breaks (thus the "nothing named '../py*'" result).

So I figured the simplest default was "you can have spaces in your filenames, but otherwise you can do what you want". Now that I have the 'unquoted' conversion specifier, I'm open to tweaking that scheme to allow the same chars that shlex.quote does *plus* specifically the wildcard matching chars (i.e. '*', '?').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sat Oct 29 04:04:40 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 02:04:40 +0000
Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception;
	io.StringIO().encoding is None
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1319853880.91.0.898026786031.issue8256@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Confirmed in 3.3.
The patch does not apply cleanly on trunk.

----------
stage: test needed -> needs patch
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Sat Oct 29 04:07:27 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 02:07:27 +0000
Subject: [issue6057] sqlite3 error classes should be documented
In-Reply-To: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za>
Message-ID: <1319854047.88.0.563066118479.issue6057@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6057>
_______________________________________

From report at bugs.python.org  Sat Oct 29 04:14:39 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 02:14:39 +0000
Subject: [issue6655] etree iterative find[text]
In-Reply-To: <1249529720.45.0.62463367335.issue6655@psf.upfronthosting.co.za>
Message-ID: <1319854479.84.0.466795036051.issue6655@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

ElementTree 1.3 added the "iterfind" method to Python 2.7 and 3.2.
http://docs.python.org/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.iterfind

----------
resolution:  -> out of date
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6655>
_______________________________________

From report at bugs.python.org  Sat Oct 29 04:23:28 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 02:23:28 +0000
Subject: [issue9375] ElementPath parser in ElementTree 1.3 does not reject
	"element//" as invalid
In-Reply-To: <1280043129.76.0.83882182954.issue9375@psf.upfronthosting.co.za>
Message-ID: <1319855008.83.0.525012428326.issue9375@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This behavior is verified with unit tests.
I don't plan to change it.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9375>
_______________________________________

From report at bugs.python.org  Sat Oct 29 04:35:58 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 02:35:58 +0000
Subject: [issue8277] ElementTree won't parse comments
In-Reply-To: <1270085866.99.0.0885322891054.issue8277@psf.upfronthosting.co.za>
Message-ID: <1319855758.7.0.137623979067.issue8277@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8277>
_______________________________________

From report at bugs.python.org  Sat Oct 29 04:37:46 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 02:37:46 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1319855866.04.0.394776318746.issue8047@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

3.1 is no longer in scope for this issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Sat Oct 29 04:55:11 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 02:55:11 +0000
Subject: [issue7710] Inconsistent Exception for int() conversion
In-Reply-To: <1263584123.75.0.822719915688.issue7710@psf.upfronthosting.co.za>
Message-ID: <1319856911.5.0.687288358051.issue7710@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

On 3.2 it is fixed (I didn't find the related changeset).

Not backported to 2.7.

----------
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7710>
_______________________________________

From report at bugs.python.org  Sat Oct 29 04:59:12 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 02:59:12 +0000
Subject: [issue4221] inconsistent exception from int is confusing
In-Reply-To: <1225213917.89.0.391557406226.issue4221@psf.upfronthosting.co.za>
Message-ID: <1319857152.0.0.298544728378.issue4221@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

No more bug with Python 3.2.

On 2.7, we still experience the behavior described in msg75290.

----------
versions:  -Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4221>
_______________________________________

From report at bugs.python.org  Sat Oct 29 05:07:07 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 03:07:07 +0000
Subject: [issue9708] cElementTree iterparse does not support "parser" argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <1319857627.45.0.497540717981.issue9708@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Documentation should be fixed for 3.2 and 2.7.
Patch welcomed.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9708>
_______________________________________

From report at bugs.python.org  Sat Oct 29 05:34:47 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Oct 2011 03:34:47 +0000
Subject: [issue1681674] subprocess.Popen fails with socket._fileobject on
	Windows
Message-ID: <1319859287.43.0.145161576744.issue1681674@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1681674>
_______________________________________

From report at bugs.python.org  Sat Oct 29 05:50:23 2011
From: report at bugs.python.org (args wu)
Date: Sat, 29 Oct 2011 03:50:23 +0000
Subject: =?utf-8?q?=5Bissue13289=5D_a_spell_error_in_standard_lib_SocketServer?=
	=?utf-8?b?4oCYcyBjb21tZW50?=
Message-ID: <1319860223.7.0.549256662259.issue13289@psf.upfronthosting.co.za>


New submission from args wu <lonependulm at gmail.com>:

In line 85, the reqd should be read.
I also checked in python3.2's lib, the error still be there?

----------
components: Library (Lib)
messages: 146597
nosy: args.wu
priority: normal
severity: normal
status: open
title: a spell error in standard lib SocketServer?s comment
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13289>
_______________________________________

From report at bugs.python.org  Sat Oct 29 09:04:12 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Sat, 29 Oct 2011 07:04:12 +0000
Subject: [issue13290] get vars for object with __slots__
Message-ID: <1319871850.77.0.869546838833.issue13290@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo <jbvsmo at gmail.com>:

I just realized the builtin function `vars` can't handle custom objects without the __dict__ attribute.

It would be nice if it worked with objects that have __slots__ to make them look more like normal objects and to make debugging easier.

I changed the source of "Python/bltinmodule.c" to accept this new case, but, as I'm fairly new to the C API, it may not be much good.

I'm attaching the whole file to this Issue and the `builtin_vars` function was modified (lines 1859 to 1921) to work with:
__slots__ = ('a', 'b', 'c')
__slots__ = 'single_name'
__slots__ = {'some': 'mapping'}

The output is a dict (just like in the __dict__ case).

#Example
>>> class C:
       __slots__ = ['x', 'y']

>>> c = C()
>>> c.x = 123
>>> vars(c)
{'x': 123}

----------
components: Interpreter Core
files: bltinmodule.c
messages: 146598
nosy: JBernardo
priority: normal
severity: normal
status: open
title: get vars for object with __slots__
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23546/bltinmodule.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13290>
_______________________________________

From report at bugs.python.org  Sat Oct 29 09:45:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 29 Oct 2011 07:45:18 +0000
Subject: =?utf-8?q?=5Bissue13289=5D_a_spell_error_in_standard_lib_SocketServer?=
	=?utf-8?b?4oCYcyBjb21tZW50?=
In-Reply-To: <1319860223.7.0.549256662259.issue13289@psf.upfronthosting.co.za>
Message-ID: <E1RK3bL-0004o2-Ck@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8ddd4c618b48 by Ezio Melotti in branch '2.7':
#13289: fix typo.
http://hg.python.org/cpython/rev/8ddd4c618b48

New changeset fec8fdbccf3b by Ezio Melotti in branch '3.2':
#13289: fix typo.
http://hg.python.org/cpython/rev/fec8fdbccf3b

New changeset 4411a59dc23c by Ezio Melotti in branch 'default':
#13289: merge with 3.2.
http://hg.python.org/cpython/rev/4411a59dc23c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13289>
_______________________________________

From report at bugs.python.org  Sat Oct 29 09:46:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 29 Oct 2011 07:46:11 +0000
Subject: =?utf-8?q?=5Bissue13289=5D_a_spell_error_in_standard_lib_SocketServer?=
	=?utf-8?b?4oCYcyBjb21tZW50?=
In-Reply-To: <1319860223.7.0.549256662259.issue13289@psf.upfronthosting.co.za>
Message-ID: <1319874371.26.0.775634332217.issue13289@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13289>
_______________________________________

From report at bugs.python.org  Sat Oct 29 10:10:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 29 Oct 2011 08:10:51 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1319875851.58.0.425452397813.issue670664@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Sat Oct 29 12:11:21 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 29 Oct 2011 10:11:21 +0000
Subject: [issue13281] robotparser.RobotFileParser ignores rules preceeded by a
	blank line
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1319883081.38.0.331407344057.issue13281@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> Because of the line break, clicking that link gives "Server error 404".

I don't see a line break, but the comma after the link seems to breaks it. Sorry.

> The way I read the grammar, 'records' (which start with an agent
> line) cannot have blank lines and must be separated by blank lines.

Ah, true. But it seems to me that having blank lines elsewhere doesn't break the parsing. If other robots.txt parser implementations allow arbitrary blank lines, we could add a strict=False parameter to make the parser non-strict. This would be a new feature of course.

Does the parser currently handle blank lines between full records (agentline(s) + ruleline(s)) correctly?

> I also do not see "Crawl-delay" and "Sitemap" (from whitehouse.gov) in the grammar referenced above. So I wonder if de facto practice has evolved.

The spec says:

   Lines with Fields not explicitly specified by this specification
   may occur in the /robots.txt, allowing for future extension of the
   format.

So these seem to be nonstandard extensions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Sat Oct 29 12:42:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 29 Oct 2011 10:42:48 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <E1RK6N7-00023N-QE@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bf1c4984d4e5 by Charles-Fran?ois Natali in branch 'default':
Issue #5661: Add a test for ECONNRESET/EPIPE handling to test_asyncore. Patch
http://hg.python.org/cpython/rev/bf1c4984d4e5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Sat Oct 29 13:16:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Oct 2011 11:16:52 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319852415.39.0.944796154343.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319886757.3244.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

>  With the default whitespace escaping (which allows spaces in
> filenames), wildcard matching still works (thus the list of
> directories matching the "../py*" pattern), but with full quoting it
> breaks (thus the "nothing named '../py*'" result).

My question is why it would be a good idea to make a difference between
whitespace and other characters. If you use a wildcard pattern,
generally it won't contain spaces at all, so you don't have to quote it.
If you are injecting a normal filename, noticing that whitespace gets
quoted may get you a false sense of security until somebody injects a
wildcard character that won't get quoted.

So what I'm saying is that a middleground between quoting and no quoting
is dangerous and not very useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sat Oct 29 13:17:38 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 29 Oct 2011 11:17:38 +0000
Subject: [issue13265] IDLE crashes when printing some unprintable characters.
In-Reply-To: <1319608129.37.0.0558883356195.issue13265@psf.upfronthosting.co.za>
Message-ID: <1319887058.57.0.432897323509.issue13265@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13265>
_______________________________________

From report at bugs.python.org  Sat Oct 29 13:37:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 29 Oct 2011 11:37:46 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <1319888266.99.0.531539816522.issue5661@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The test fails on OS X:
"""
======================================================================
ERROR: test_handle_close_after_conn_broken (test.test_asyncore.TestAPI_UseIPv4Poll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/test_asyncore.py", line 661, in test_handle_close_after_conn_broken
    self.loop_waiting_for_flag(client)
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/test_asyncore.py", line 523, in loop_waiting_for_flag
    asyncore.loop(timeout=0.01, count=1, use_poll=self.use_poll)
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/asyncore.py", line 215, in loop
    poll_fun(timeout, map)
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/asyncore.py", line 196, in poll2
    readwrite(obj, flags)
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/asyncore.py", line 123, in readwrite
    obj.handle_error()
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/asyncore.py", line 112, in readwrite
    obj.handle_expt_event()
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/asyncore.py", line 476, in handle_expt_event
    self.handle_expt()
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/test_asyncore.py", line 470, in handle_expt
    raise Exception("handle_expt not supposed to be called")
Exception: handle_expt not supposed to be called
"""

Looks like the FD is returned in the exception set on OS X...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Sat Oct 29 14:26:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 29 Oct 2011 12:26:40 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <E1RK7zd-0002BV-7w@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 507dfb0ceb3b by Charles-Fran?ois Natali in branch 'default':
Issue #5661: on EPIPE/ECONNRESET, OS X returns the FD with the POLLPRI flag...
http://hg.python.org/cpython/rev/507dfb0ceb3b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Sat Oct 29 14:27:21 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 29 Oct 2011 12:27:21 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <1319891241.32.0.251885135107.issue5661@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

The test fails when use_poll is True.
The difference between using poll() and poll2():

    poll: All the read events are processed before the write events,
    so the close after the first recv by TestHandler will be followed
    by a send by TestClient within the same call to poll(). The
    test is deterministic.

    poll2: The order in which events are received is os dependent. So
    it is possible that the first recv by TestHandler is the last
    event in the 'r' list, so that after the close, a new call to
    poll2() is done and the first event in this new 'r' list, is not
    the expected write event for TestClient.

What about forcing self.use_poll to False, before calling
loop_waiting_for_flag() ? The drawback being that the test will be run
twice with the same environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Sat Oct 29 15:23:43 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 29 Oct 2011 13:23:43 +0000
Subject: [issue5661] asyncore should catch EPIPE while sending() and
	receiving()
In-Reply-To: <1238634207.37.0.10074614667.issue5661@psf.upfronthosting.co.za>
Message-ID: <1319894623.59.0.0195639405276.issue5661@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The test fails when use_poll is True.
> The difference between using poll() and poll2():

poll uses select(2), while poll2 uses poll(2) (duh, that's confusing).
It seems that on OS X Snow Leopard, poll(2) sets the POLLPRI flag upon EPIPE (and probably doesn't return the FD in the exception set for select(2)...).
Not sure whether it's legal, but it's the only OS to do that (POLLPRI usually used for OOB data). Also, note that Tiger doesn't behave that way.
OS X often offers such surprises :-)

> What about forcing self.use_poll to False, before calling
> loop_waiting_for_flag() ? The drawback being that the test will be run
> twice with the same environment.

I just added an handle_expt() handler, and it works fine.

Closing, thanks for the patch!

----------
assignee: josiahcarlson -> 
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5661>
_______________________________________

From report at bugs.python.org  Sat Oct 29 15:57:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Oct 2011 13:57:38 +0000
Subject: [issue13288] SSL module doesn't allow access to cert issuer
	information
In-Reply-To: <1319836342.01.0.0498331341848.issue13288@psf.upfronthosting.co.za>
Message-ID: <1319896658.41.0.834215128797.issue13288@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's available in 3.3:

>>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
>>> ctx.verify_mode = ssl.CERT_REQUIRED
>>> ctx.set_default_verify_paths()
>>> with ctx.wrap_socket(socket.socket()) as sock:
...   sock.connect(("svn.python.org", 443))
...   cert = sock.getpeercert()
... 
>>> pprint.pprint(cert)
{'issuer': ((('organizationName', 'Root CA'),),
            (('organizationalUnitName', 'http://www.cacert.org'),),
            (('commonName', 'CA Cert Signing Authority'),),
            (('emailAddress', 'support at cacert.org'),)),
 'notAfter': 'Jan  9 20:50:13 2012 GMT',
 'notBefore': 'Jan  9 20:50:13 2010 GMT',
 'serialNumber': '0806E3',
 'subject': ((('commonName', 'svn.python.org'),),),
 'subjectAltName': (('DNS', 'svn.python.org'), ('othername', '<unsupported>')),
 'version': 3}

----------
nosy: +pitrou
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13288>
_______________________________________

From report at bugs.python.org  Sat Oct 29 16:11:02 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Oct 2011 14:11:02 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1319897462.28.0.370761583004.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, I was thinking about this a bit more and realised that I'd rejected the "quote everything by default" approach before I had the idea of providing a custom conversion specifier to disable the implicit string conversion and quoting.

So perhaps a better alternative would be:

  default - str + shlex.quote
  !u - unquoted (i.e. normal str.format default behaviour)

When you have a concise way to explicitly bypass it, making the default behaviour as safe as possible seems like a good way to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sat Oct 29 16:25:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Oct 2011 14:25:14 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <1319898314.16.0.620120286565.issue10363@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If the handle leaks are restricted to the windows implementation of cpython,
> could it not be justified to allow C++ in a patch, I can't think of a C only
> compiler for windows?

Well, I think that would be rather clumsy. I'm not a Windows user myself, perhaps other people can share opinions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________

From report at bugs.python.org  Sat Oct 29 17:52:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 29 Oct 2011 15:52:05 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za>
Message-ID: <1319903525.11.0.715654988725.issue12905@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

R?mi, do you want to submit a patch to skip those tests on OpenBSD?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12905>
_______________________________________

From report at bugs.python.org  Sat Oct 29 17:57:14 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 29 Oct 2011 15:57:14 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1319903834.55.0.989136725694.issue12797@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Thanks. Although, on second thought, I'm not sure whether Amaury's 
> idea (allowing a custom opener) is not better... Thoughts?

+1.
This would also address issues #12760 and #12105.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sat Oct 29 17:57:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 29 Oct 2011 15:57:50 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1319903870.03.0.0529909497286.issue12105@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
status: open -> closed
superseder:  -> io.FileIO and io.open should support openat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sat Oct 29 17:58:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 29 Oct 2011 15:58:21 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1319903901.39.0.51478615908.issue12760@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> io.FileIO and io.open should support openat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Sat Oct 29 18:16:37 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 29 Oct 2011 16:16:37 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1319904997.98.0.774962892547.issue12797@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

What would you envisage the API for the custom opener to look like?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sat Oct 29 18:23:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Oct 2011 16:23:30 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1319904997.98.0.774962892547.issue12797@psf.upfronthosting.co.za>
Message-ID: <1319905154.3244.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What would you envisage the API for the custom opener to look like?

The same as os.open(), I would say.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sat Oct 29 18:29:46 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 29 Oct 2011 16:29:46 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1319905786.72.0.638306607908.issue12797@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sat Oct 29 19:41:31 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 29 Oct 2011 17:41:31 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <1319910091.36.0.258221221326.issue10363@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As a policy, we will not rely on C++ destructors for cleanup. There are really two issues here: "global" locks, and module-specific locks.

The global locks can and should be released in Py_Finalize, with no API change. Antoine's patch looks good to me.

For module-level locks, PEP-3121-style module finalization should be used. Patches are welcome.

Martin: Please understand that there are *MANY* more issues with reloading Python in the same process, as a really large number of stuff doesn't get cleanup up on shutdown. Also expect that fixing these will take 10 years or more, unless somebody puts a huge effort into it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________

From report at bugs.python.org  Sat Oct 29 19:53:31 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 29 Oct 2011 17:53:31 +0000
Subject: [issue13284] email.utils.formatdate function does not handle
	timezones correctly.
In-Reply-To: <1319797564.66.0.629117270841.issue13284@psf.upfronthosting.co.za>
Message-ID: <1319910811.32.0.159257674284.issue13284@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13284>
_______________________________________

From report at bugs.python.org  Sat Oct 29 19:56:22 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 29 Oct 2011 17:56:22 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1319910982.5.0.295913913666.issue13285@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13285>
_______________________________________

From report at bugs.python.org  Sat Oct 29 20:33:51 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 29 Oct 2011 18:33:51 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1319913231.7.0.462773799141.issue12797@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Before I implement it properly, is this the kind of api that's desired?

"""
import os
import io

class MyOpener:
    def __init__(self, dirname):
        self.dirfd = os.open(dirname, os.O_RDONLY)

    def open(self, path, flags, mode):
        return os.openat(self.dirfd, path, flags, mode)

myop = MyOpener("/tmp")
f = open("testfile", "w", opener=myop.open)
f.write("hello")
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sat Oct 29 20:35:14 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 29 Oct 2011 18:35:14 +0000
Subject: [issue10519] setobject.c no-op typo
In-Reply-To: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>
Message-ID: <1319913314.27.0.456595603374.issue10519@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10519>
_______________________________________

From report at bugs.python.org  Sat Oct 29 20:37:54 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 29 Oct 2011 18:37:54 +0000
Subject: [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <1319913474.58.0.0757000435153.issue12761@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12761>
_______________________________________

From report at bugs.python.org  Sat Oct 29 20:39:52 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 29 Oct 2011 18:39:52 +0000
Subject: [issue6650] sre_parse contains a confusing generic error message
In-Reply-To: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za>
Message-ID: <1319913592.31.0.0579843550177.issue6650@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6650>
_______________________________________

From report at bugs.python.org  Sat Oct 29 21:21:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Oct 2011 19:21:01 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1319916061.32.0.940039008079.issue12797@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Before I implement it properly, is this the kind of api that's desired?

Yes, although I think most people would use a closure instead of a dedicated class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sat Oct 29 21:32:13 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 29 Oct 2011 19:32:13 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1319916733.54.0.962280734185.issue12498@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> Actually the class asyncore.dispatcher_with_send do not handle
> properly disconnection. When the endpoint shutdown his sending part
> of the socket, but keep the socket open in reading, the current
> implementation of dispatcher_with_send will close the socket without
> sending pending data.
>
> Adding this method to the class fix the problem:
>
>     def handle_close(self):
>         if not self.writable():
>             dispatcher.close()


This does not seem to work. The attached Python 3.2 script
'asyncore_12498.py' goes into an infinite loop of calls to
handle_read/handle_close when handle_close is defined as above. In
this script the Writer sends a 4096 bytes message when connected, the
Reader reads only 64 bytes and closes the connection afterwards. Then
follows the sequence:

    select() returns a read event handled by handle_read()
    handle_read() calls recv()
    socket.recv() returns 0 to indicate a closed connection
    recv() calls handle_close

This sequence is repeated forever in asyncore.loop() since out_buffer
is never empty.

Note that after the first 'handle_close' has been printed, there are
no 'handle_write' printed, which indicates that the operating system
(here linux) states that the socket is not writable.

----------
nosy: +xdegaye
Added file: http://bugs.python.org/file23547/asyncore_12498.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12498>
_______________________________________

From report at bugs.python.org  Sat Oct 29 21:45:55 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Oct 2011 19:45:55 +0000
Subject: [issue13280] argparse should use the new Formatter class
In-Reply-To: <1319746751.8.0.206945992721.issue13280@psf.upfronthosting.co.za>
Message-ID: <1319917555.58.0.72643733589.issue13280@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13280>
_______________________________________

From report at bugs.python.org  Sat Oct 29 22:02:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Oct 2011 20:02:24 +0000
Subject: [issue13281] robotparser.RobotFileParser ignores rules preceeded by a
	blank line
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1319918544.81.0.227586538408.issue13281@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Sorry, the visual linebreak depends on font size. It *is* the comma that caused the problem.

You missed my question about the current test suite.

Senthil, you are the listed expert for urllib, which includes robotparser. Any opinions on what to do?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Sat Oct 29 22:13:44 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Oct 2011 20:13:44 +0000
Subject: [issue13173] Default values for string.Template
In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>
Message-ID: <1319919224.7.0.82724291402.issue13173@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Barry, any thoughts?

----------
assignee: rhettinger -> barry
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13173>
_______________________________________

From report at bugs.python.org  Sat Oct 29 22:43:13 2011
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Sat, 29 Oct 2011 20:43:13 +0000
Subject: [issue13274] heapq pure python version uses islice without guarding
	for negative counts
In-Reply-To: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za>
Message-ID: <1319920993.67.0.113151120472.issue13274@psf.upfronthosting.co.za>


Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com> added the comment:

however some basic consistency between the cpython and pure python versions within the stdlib would be nice

since it basically implicitly breaks unaware code on non cpython

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13274>
_______________________________________

From report at bugs.python.org  Sat Oct 29 22:58:32 2011
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 29 Oct 2011 20:58:32 +0000
Subject: [issue10519] setobject.c no-op typo
In-Reply-To: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>
Message-ID: <1319921912.29.0.825938493061.issue10519@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
assignee: arigo -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10519>
_______________________________________

From report at bugs.python.org  Sun Oct 30 00:51:23 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 29 Oct 2011 22:51:23 +0000
Subject: [issue13291] latent NameError in xmlrpc package
Message-ID: <1319928683.07.0.326015714252.issue13291@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

There's two names which should be fixed in "xmlrpc" package:

--- a/Lib/xmlrpc/client.py
-        elif isinstance(other, (str, unicode)):


--- a/Lib/xmlrpc/server.py
-            response = xmlrpclib.dumps(
-                xmlrpclib.Fault(1, "%s:%s" % (exc_type, exc_value)),


We may extend test coverage too.

----------
components: Library (Lib), XML
messages: 146622
nosy: flox
priority: normal
severity: normal
stage: test needed
status: open
title: latent NameError in xmlrpc package
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13291>
_______________________________________

From report at bugs.python.org  Sun Oct 30 01:47:37 2011
From: report at bugs.python.org (David Barnett)
Date: Sat, 29 Oct 2011 23:47:37 +0000
Subject: [issue11638] python setup.py sdist crashes if version is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1319932057.08.0.236199352618.issue11638@psf.upfronthosting.co.za>


David Barnett <davidbarnett2 at gmail.com> added the comment:

Here's a test for the bug.

----------
keywords: +patch
Added file: http://bugs.python.org/file23548/test_unicode_sdist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Sun Oct 30 02:04:41 2011
From: report at bugs.python.org (David Barnett)
Date: Sun, 30 Oct 2011 00:04:41 +0000
Subject: [issue11638] python setup.py sdist crashes if version is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1319933081.3.0.334751591927.issue11638@psf.upfronthosting.co.za>


David Barnett <davidbarnett2 at gmail.com> added the comment:

One way to fix the symptom (maybe not the correct way) would be to edit tarfile._Stream._init_write_gz and change the line that reads
  self.__write(self.name + NUL)
to something like
  self.__write(self.name.encode('utf-8') + NUL)

tarfile is building up an encoded stream of bytes, and whatever self.name is it needs to be encoded before being inserted into the stream. I'm not positive UTF-8 is right, and maybe it should only convert if isinstance(self.name, unicode).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Sun Oct 30 02:59:13 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 30 Oct 2011 00:59:13 +0000
Subject: [issue13291] latent NameError in xmlrpc package
In-Reply-To: <1319928683.07.0.326015714252.issue13291@psf.upfronthosting.co.za>
Message-ID: <1319936353.06.0.654985614491.issue13291@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Proposed fix, with some tests.

----------
keywords: +patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file23549/issue13291_xmlrpc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13291>
_______________________________________

From report at bugs.python.org  Sun Oct 30 02:08:38 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 30 Oct 2011 01:08:38 +0000
Subject: [issue13274] heapq pure python version uses islice without guarding
	for negative counts
In-Reply-To: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za>
Message-ID: <1319936918.89.0.856960415781.issue13274@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13274>
_______________________________________

From report at bugs.python.org  Sun Oct 30 03:47:44 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 30 Oct 2011 02:47:44 +0000
Subject: [issue13274] heapq pure python version uses islice without guarding
	for negative counts
In-Reply-To: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za>
Message-ID: <1319942864.88.0.310593330552.issue13274@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13274>
_______________________________________

From report at bugs.python.org  Sun Oct 30 06:32:15 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 30 Oct 2011 05:32:15 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1319952735.3.0.579803994977.issue12797@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

The attached patch adds the opener keyword + tests.

----------
Added file: http://bugs.python.org/file23550/opener.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sun Oct 30 08:13:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Oct 2011 07:13:08 +0000
Subject: [issue13291] latent NameError in xmlrpc package
In-Reply-To: <1319928683.07.0.326015714252.issue13291@psf.upfronthosting.co.za>
Message-ID: <1319958788.58.0.188509749194.issue13291@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I left a couple of comments on rietveld.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13291>
_______________________________________

From report at bugs.python.org  Sun Oct 30 10:40:51 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 30 Oct 2011 09:40:51 +0000
Subject: [issue13218] test_ssl failures on Debian/Ubuntu
In-Reply-To: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za>
Message-ID: <1319967651.34.0.909185568733.issue13218@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> New changeset 3c225f938dae by Barry Warsaw in branch '2.7':
> - Issue #13218: Fix test_ssl failures on Debian/Ubuntu.
> http://hg.python.org/cpython/rev/3c225f938dae

This changeset appears to have broken a number of the 2.7 Linux buildbots:

    http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%202.7/builds/861
    http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%202.7/builds/287
    http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%202.7/builds/245
    http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%202.7/builds/1147
    http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%202.7/builds/24

All of the errors look something like:

    ======================================================================
    ERROR: test_protocol_sslv3 (test.test_ssl.ThreadedTests)
    Connecting to an SSLv3 server with various client options
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/buildbot/buildarea/2.7.ochtman-gentoo-amd64/build/Lib/test/test_ssl.py", line 75, in f
        return func(*args, **kwargs)
      File "/home/buildbot/buildarea/2.7.ochtman-gentoo-amd64/build/Lib/test/test_ssl.py", line 1029, in test_protocol_sslv3
        client_options=ssl.OP_NO_SSLv3)
    AttributeError: 'module' object has no attribute 'OP_NO_SSLv3'

    ======================================================================
    ERROR: test_protocol_tlsv1 (test.test_ssl.ThreadedTests)
    Connecting to a TLSv1 server with various client options
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/buildbot/buildarea/2.7.ochtman-gentoo-amd64/build/Lib/test/test_ssl.py", line 75, in f
        return func(*args, **kwargs)
      File "/home/buildbot/buildarea/2.7.ochtman-gentoo-amd64/build/Lib/test/test_ssl.py", line 1044, in test_protocol_tlsv1
        client_options=ssl.OP_NO_TLSv1)
    AttributeError: 'module' object has no attribute 'OP_NO_TLSv1'

The ARM Ubuntu builder gets two additional errors, saying that
ssl.PROTOCOL_SSLv2 doesn't exist either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13218>
_______________________________________

From report at bugs.python.org  Sun Oct 30 10:59:17 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 30 Oct 2011 09:59:17 +0000
Subject: [issue13291] latent NameError in xmlrpc package
In-Reply-To: <1319928683.07.0.326015714252.issue13291@psf.upfronthosting.co.za>
Message-ID: <1319968757.6.0.447463852815.issue13291@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Thank you. Patch updated.

----------
Added file: http://bugs.python.org/file23551/issue13291_xmlrpc_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13291>
_______________________________________

From report at bugs.python.org  Sun Oct 30 12:16:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 30 Oct 2011 11:16:24 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1319916733.54.0.962280734185.issue12498@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3Sso0j7WkGQDkxaKoiddODq_gsvUMPy6mgFuG5W5+aBg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> This does not seem to work.

Yes, the proposed fix is buggy: the solution is to drain the output
buffer, guarding against recursive calls between send() and
handle_close() (patch attached).

> Note that after the first 'handle_close' has been printed, there are
> no 'handle_write' printed, which indicates that the operating system
> (here linux) states that the socket is not writable.

That's because you're closing the socket, whereas the original report
is dealing with half-shutdown connections.
Try this:
"""
 class Reader(asyncore.dispatcher):
     def __init__(self, sock):
         asyncore.dispatcher.__init__(self, sock)
+        self.shutdown = False

     def writable(self):
         return False

     def handle_read(self):
         self.recv(64)
-        self.close()
+        if not self.shutdown:
+            self.shutdown = True
+            self.socket.shutdown(socket.SHUT_WR)

 class Writer(asyncore.dispatcher_with_send):
     def __init__(self, address):
"""

This will behave as expected.
Calling socket.shutdown(socket.SHUT_WR) means that you won't send any
more data, but that you're still ready to receive: it results in a FIN
being sent to the remote endpoint, which will receive EOF on recv().
But subsequent send() from the remote endpoint will still succeed.
Whereas with socket.close(), you not only shut down your sending part,
but you also signify that you don't want to receive data any more: a
FIN will be sent immediately to the remote endpoint, and on subsequent
send() from the remote endpoint, a RST will be returned, which will
result in EPIPE (or, in there was data in the receive socket buffer
when the local endpoint was closed, a RST will be sent directly,
resulting in ECONNRESET).

I still need to write a test.

----------
keywords: +patch
Added file: http://bugs.python.org/file23552/asyncore_drain.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12498>
_______________________________________
-------------- next part --------------
diff --git a/Lib/asyncore.py b/Lib/asyncore.py
--- a/Lib/asyncore.py
+++ b/Lib/asyncore.py
@@ -535,6 +535,7 @@
         num_sent = 0
         num_sent = dispatcher.send(self, self.out_buffer[:512])
         self.out_buffer = self.out_buffer[num_sent:]
+        return num_sent
 
     def handle_write(self):
         self.initiate_send()
@@ -548,6 +549,15 @@
         self.out_buffer = self.out_buffer + data
         self.initiate_send()
 
+    def handle_close(self):
+        if not self.closing:
+            self.closing = True
+            # try to drain the output buffer
+            while self.writable() and self.initiate_send() > 0:
+                pass
+        self.close()
+
+
 # ---------------------------------------------------------------------------
 # used for debugging.
 # ---------------------------------------------------------------------------

From report at bugs.python.org  Sun Oct 30 12:37:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 30 Oct 2011 11:37:44 +0000
Subject: [issue5875] test_distutils failing on OpenSUSE 10.3, Py3k
In-Reply-To: <1240991372.08.0.469372196929.issue5875@psf.upfronthosting.co.za>
Message-ID: <1319974664.83.0.0737367004772.issue5875@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's the error message:
"""
error: File not found: /tmp/tmpsga9lh/foo/build/bdist.linux-i686/rpm/BUILDROOT/foo-0.1-1.i386/usr/local/lib/python3.3/site-packages/foo.pyc
error: File not found: /tmp/tmpsga9lh/foo/build/bdist.linux-i686/rpm/BUILDROOT/foo-0.1-1.i386/usr/local/lib/python3.3/site-packages/foo.pyo
    File not found: /tmp/tmpsga9lh/foo/build/bdist.linux-i686/rpm/BUILDROOT/foo-0.1-1.i386/usr/local/lib/python3.3/site-packages/foo.pyc
    File not found: /tmp/tmpsga9lh/foo/build/bdist.linux-i686/rpm/BUILDROOT/foo-0.1-1.i386/usr/local/lib/python3.3/site-packages/foo.pyo
"""
http://python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/934/steps/test/logs/stdio

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5875>
_______________________________________

From report at bugs.python.org  Sun Oct 30 12:40:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Oct 2011 11:40:27 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1319974827.85.0.486764790179.issue670664@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached a new patch with a few more tests and minor refactoring.

----------
keywords: +needs review
stage: patch review -> commit review
versions: +Python 2.7
Added file: http://bugs.python.org/file23553/issue670664.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Sun Oct 30 12:52:13 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 30 Oct 2011 11:52:13 +0000
Subject: [issue13292] missing versionadded for bytearray
Message-ID: <1319975533.88.0.431386848219.issue13292@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

versionadded is missing here:
http://docs.python.org/library/functions.html#bytearray

----------
assignee: docs at python
components: Documentation
messages: 146633
nosy: docs at python, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: missing versionadded for bytearray
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13292>
_______________________________________

From report at bugs.python.org  Sun Oct 30 13:06:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Oct 2011 12:06:01 +0000
Subject: [issue10519] setobject.c no-op typo
In-Reply-To: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>
Message-ID: <E1RKU9B-0004fU-GJ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 72de2ac8bb4f by Petri Lehtinen in branch '2.7':
Avoid unnecessary recursive function calls (closes #10519)
http://hg.python.org/cpython/rev/72de2ac8bb4f

New changeset 664bf4f3a820 by Petri Lehtinen in branch '3.2':
Avoid unnecessary recursive function calls (closes #10519)
http://hg.python.org/cpython/rev/664bf4f3a820

New changeset a5c4ae15b59d by Petri Lehtinen in branch 'default':
Avoid unnecessary recursive function calls (#closes #10519)
http://hg.python.org/cpython/rev/a5c4ae15b59d

----------
nosy: +python-dev
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10519>
_______________________________________

From report at bugs.python.org  Sun Oct 30 13:36:41 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 30 Oct 2011 12:36:41 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1319978201.55.0.887214496269.issue12498@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Thanks for the explanations.
I confirm that the patch fixes 'asyncore_12498.py' with your changes
applied to this script.

Note that the patch may break applications that have given different
semantics to 'closing' ('closing' being such a common name for a
network application) after they noticed that this attribute is never
used by asyncore nor by asynchat.

It seems that the same fix could also be applied to asynchat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12498>
_______________________________________

From report at bugs.python.org  Sun Oct 30 13:38:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Oct 2011 12:38:40 +0000
Subject: [issue10519] setobject.c no-op typo
In-Reply-To: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>
Message-ID: <E1RKUen-0006oM-Kk@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7ddc7b339a8b by Petri Lehtinen in branch '2.7':
Fix the return value of set_discard (issue #10519)
http://hg.python.org/cpython/rev/7ddc7b339a8b

New changeset b643458a0108 by Petri Lehtinen in branch '3.2':
Fix the return value of set_discard (issue #10519)
http://hg.python.org/cpython/rev/b643458a0108

New changeset f634102aca01 by Petri Lehtinen in branch 'default':
Fix the return value of set_discard (issue #10519)
http://hg.python.org/cpython/rev/f634102aca01

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10519>
_______________________________________

From report at bugs.python.org  Sun Oct 30 13:55:55 2011
From: report at bugs.python.org (luchenue)
Date: Sun, 30 Oct 2011 12:55:55 +0000
Subject: [issue13293] xmlrpc.client encode error
Message-ID: <1319979355.49.0.42965800698.issue13293@psf.upfronthosting.co.za>


New submission from luchenue <l at ooa.cc>:

import xmlrpc.client

server = xmlrpc.client.Server('XXX')
print(server.login(b'bHVjaGVudWU=',b'bHVjaGVudWU='))

=> xmlrpc.client 
def dump_string
  write(escape(value))

dispatch[bytes] = dump_string

=>
def escape(s):
    s = s.replace("&", "&amp;")



bytes can't replace

----------
messages: 146637
nosy: luchenue
priority: normal
severity: normal
status: open
title: xmlrpc.client encode error
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13293>
_______________________________________

From report at bugs.python.org  Sun Oct 30 14:01:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Oct 2011 13:01:53 +0000
Subject: [issue13277] tzinfo subclasses information
In-Reply-To: <1319733607.49.0.8093265907.issue13277@psf.upfronthosting.co.za>
Message-ID: <1319979713.64.0.772728932724.issue13277@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +belopolsky, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13277>
_______________________________________

From report at bugs.python.org  Sun Oct 30 14:03:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Oct 2011 13:03:18 +0000
Subject: [issue12762] EnvironmentError_str contributes to unportable code
In-Reply-To: <1313514546.35.0.211291095895.issue12762@psf.upfronthosting.co.za>
Message-ID: <1319979798.41.0.54544217878.issue12762@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12762>
_______________________________________

From report at bugs.python.org  Sun Oct 30 14:52:52 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 30 Oct 2011 13:52:52 +0000
Subject: [issue13293] xmlrpc.client encode error
In-Reply-To: <1319979355.49.0.42965800698.issue13293@psf.upfronthosting.co.za>
Message-ID: <1319982772.47.0.232379265825.issue13293@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

binary data should be wrapped with Binary.
http://docs.python.org/dev/library/xmlrpc.client.html#binary-objects

----------
components: +Library (Lib), XML
nosy: +flox
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13293>
_______________________________________

From report at bugs.python.org  Sun Oct 30 15:40:42 2011
From: report at bugs.python.org (karl)
Date: Sun, 30 Oct 2011 14:40:42 +0000
Subject: [issue13294] http.server - HEAD request when no resource is defined.
Message-ID: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>


New submission from karl <karl+pythonbugs at la-grange.net>:

A very simple HTTP server

#!/usr/bin/python3
import http.server
from os import chdir

# CONFIG
ROOTPATH = '/Your/path/'
PORT = 8000

# CODE
def run(server_class=http.server.HTTPServer, server_handler=http.server.SimpleHTTPRequestHandler):
    server_address = ('', PORT)
    httpd = server_class(server_address, server_handler)
    httpd.serve_forever()

class MyRequestHandler(http.server.SimpleHTTPRequestHandler):
    def do_GET(self):
        pass
    
if __name__ == '__main__':
    chdir(ROOTPATH)
    print("server started on PORT:?"+str(PORT))
    run(server_handler=MyRequestHandler)


Let's start the server.

% python3 serveur1.py 
server started on PORT:?8000


And let's do a GET request with curl.

% curl -v http://localhost:8000/
* About to connect() to localhost port 8000 (#0)
*   Trying ::1... Connection refused
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8000 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: localhost:8000
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server
* Closing connection #0

The server sends nothing because GET is not defined and I haven't defined anything in case of errors. So far so good. Now let's do a HEAD request on the same resource.

% curl -vsI http://localhost:8000/
* About to connect() to localhost port 8000 (#0)
*   Trying ::1... Connection refused
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8000 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: localhost:8000
> Accept: */*
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
HTTP/1.0 200 OK
< Server: SimpleHTTP/0.6 Python/3.1.2
Server: SimpleHTTP/0.6 Python/3.1.2
< Date: Sun, 30 Oct 2011 14:19:00 GMT
Date: Sun, 30 Oct 2011 14:19:00 GMT
< Content-type: text/html; charset=utf-8
Content-type: text/html; charset=utf-8
< Content-Length: 346
Content-Length: 346

< 
* Closing connection #0


The server shows in the log the request
localhost - - [30/Oct/2011 10:19:00] "HEAD / HTTP/1.1" 200 -

And is answering.

I would suggest that the default behavior is to have something similar to the one for the GET aka nothing. Or to modify the library code that for any resources not yet defined. The server answers a code 403 Forbidden. 

I could submit a patch in the next few days.

----------
components: Library (Lib)
messages: 146639
nosy: karlcow, orsenthil
priority: normal
severity: normal
status: open
title: http.server - HEAD request when no resource is defined.
type: feature request
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Sun Oct 30 15:57:11 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 30 Oct 2011 14:57:11 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1319986631.21.0.745649989993.issue12801@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Another problem with the POSIX realpath(3): it can fail with ENOENT if the target path doesn't exist, whereas the current Python implementation "succeeds" even if a component in the path doesn't exist.
Note the quotes around "succeeds", because I'm not sure whether this behavior is a good thing: the result is just plain wrong. I wonder whether we should break backwards compatibility on this particular point...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Sun Oct 30 16:07:25 2011
From: report at bugs.python.org (karl)
Date: Sun, 30 Oct 2011 15:07:25 +0000
Subject: [issue13295] html5 template for Lib/http/server.py
Message-ID: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>


New submission from karl <karl+pythonbugs at la-grange.net>:

The code has a set of old HTML templates. Here is a patch to change it to very simple html5 templates.

----------
components: Library (Lib)
files: server-html5.patch
keywords: patch
messages: 146641
nosy: karlcow, orsenthil
priority: normal
severity: normal
status: open
title: html5 template for Lib/http/server.py
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file23554/server-html5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Sun Oct 30 16:59:54 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 30 Oct 2011 15:59:54 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1319990394.56.0.309115728448.issue12498@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> Note that the patch may break applications that have given different
> semantics to 'closing' ('closing' being such a common name for a
> network application) after they noticed that this attribute is never
> used by asyncore nor by asynchat.

I was thinking about the discussion in issue 1641, the second part of
the discussion starting with msg 84972.

The attached patch uses another name and drains the output buffer only
on a close event, not on error conditions.

I will do the patch for asynchat and do both test cases, unless you
beat me to it.

----------
Added file: http://bugs.python.org/file23555/asyncore_drain_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12498>
_______________________________________

From report at bugs.python.org  Sun Oct 30 17:12:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Oct 2011 16:12:52 +0000
Subject: [issue13295] html5 template for Lib/http/server.py
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1319991172.21.0.719712861151.issue13295@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think HTML 4.01 strict is still fine -- no need to move to HTML 5 yet.
The template that uses HTML 3.2 can probably be updated though.

----------
nosy: +eric.araujo, ezio.melotti
versions: +Python 3.3 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Sun Oct 30 17:25:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Oct 2011 16:25:09 +0000
Subject: [issue13295] html5 template for Lib/http/server.py
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1319991909.27.0.85463815734.issue13295@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a patch to replace 3.2 with 4.01.
The output of the page should be checked and validated before committing this.
I'm not sure if this should go in 2.7/3.2 too, on one hand it's not a bug fix so it shouldn't, on the other hand I don't think it will break anything and it's consistent with the doctype used for the error page.

----------
Added file: http://bugs.python.org/file23556/issue13295.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Sun Oct 30 17:54:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Oct 2011 16:54:17 +0000
Subject: [issue13294] http.server - HEAD request when no resource is defined.
In-Reply-To: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>
Message-ID: <1319993657.09.0.221229211676.issue13294@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Sun Oct 30 18:09:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 30 Oct 2011 17:09:42 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1319990394.56.0.309115728448.issue12498@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2nXVLGnepoAVtmU2N2C+1MAt68qetGQHBkvEp1+M5itA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The attached patch uses another name

In that case, you should use a name starting with an underscore
("private" namespace).

> and drains the output buffer only on a close event, not on error conditions.

Hmmm...
I don't think it's a good idea.
For example, look at this in send():
"""
        except socket.error as why:
            # winsock sometimes throws ENOTCONN
            if why.args[0] in _DISCONNECTED:
                self.handle_close()
                return b''
"""

So it looks like on Windows, ENOTCONN can be returned instead of EOF:
the pending_close_evt flag wouldn't be set, and we wouldn't drain the
output buffer.
Also, some OSes can return POLLHUP without POLLIN when the remote end
shut down the connection:
http://blogs.oracle.com/vlad/entry/poll_and_pollhup_in_solaris
readwrite() would call handle_close() without setting the flag, and
the output buffer would also be lost (Note that the current code is
probably broken: when POLLHUP is received, this likely means that the
remote end has shutdown the connection, but there might still be some
data in the input socket buffer. I'll try to dig a little...).
So I'd rather stay on the safe side, and always try to drain the
output buffer in handle_close (worth case, we'll receive a
EPIPE/ECONNRESET, initiate_send will return 0 and we'll break out of
the loop).

> I will do the patch for asynchat and do both test cases, unless you
> beat me to it.

Go ahead :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12498>
_______________________________________

From report at bugs.python.org  Sun Oct 30 18:24:52 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 30 Oct 2011 17:24:52 +0000
Subject: [issue13296] IDLE: __future__ flags don't clear on shell restart
Message-ID: <1319995491.95.0.0388029066665.issue13296@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

The interactive interpreter in IDLE does not reset its compiler __future__ flags when you restart the shell. 

To verify this, type into the shell:
    
    >>> from __future__ import barry_as_FLUFL
    >>> 1 != 2

You'll get a syntax error. Restart the shell and type

    >>> 1 != 2

A syntax error still occurs.

The ModifiedInterpreter class in PyShell.py ultimately relies on codeop to mimic the interactive prompt. The codeop module was created specifically for remembering __future__ flags for subsequent commands. 

The provided patch stores the flags of the interpreter when it first initializes, and then restores them in "restart_subprocess". It's a patch against 3.2.2.

----------
components: IDLE
files: patch_future.diff
keywords: patch
messages: 146646
nosy: ezio.melotti, serwy
priority: normal
severity: normal
status: open
title: IDLE: __future__ flags don't clear on shell restart
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file23557/patch_future.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13296>
_______________________________________

From report at bugs.python.org  Sun Oct 30 18:30:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 Oct 2011 17:30:40 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1319995840.62.0.0509665537284.issue12797@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is my quick review:
- shouldn't the opener also get the third open() argument (although it currently seems to always be 0o666)?
- when fdobj is NULL, you shouldn't override the original error
- PyLong_AsLong can fail (if the opener returns too large an int), you should check for that

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sun Oct 30 18:47:53 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 30 Oct 2011 17:47:53 +0000
Subject: [issue5219] IDLE/Tkinter: edit win stops updating when tooltip is
	active
In-Reply-To: <1234382300.54.0.847679485731.issue5219@psf.upfronthosting.co.za>
Message-ID: <1319996873.2.0.664520403138.issue5219@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Attached is a patch against 3.2.2 which does proper after_cancel calls on the after calls to checkhide_event.

----------
Added file: http://bugs.python.org/file23558/patch5219.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5219>
_______________________________________

From report at bugs.python.org  Sun Oct 30 18:49:53 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 30 Oct 2011 17:49:53 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1319996993.6.0.459566924998.issue12498@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


Added file: http://bugs.python.org/file23559/asyncore_shutdown.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12498>
_______________________________________

From report at bugs.python.org  Sun Oct 30 19:02:28 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 30 Oct 2011 18:02:28 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1319997748.61.0.676793938656.issue12498@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

While writing the test case, I found out that the test case does not
fail before the patch. It seems that draining the output buffer
already works:

The attached script 'asyncore_shutdown.py' drains the output buffer
when run without the patch, with Python 3.2, and prints 'Done.'. The
dispatcher_with_send handle_close() method is never called.

The attached 'asyncore_shutdown.log' file is the output of the tcpdump
of the connection. It shows that packets are sent after the first FIN.
This is on linux.

----------
Added file: http://bugs.python.org/file23560/asyncore_shutdown.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12498>
_______________________________________

From report at bugs.python.org  Sun Oct 30 19:15:05 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 Oct 2011 18:15:05 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1319998505.41.0.55436299235.issue12797@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Also, the documentation should indicate what exactly is supposed to be returned by "opener".

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sun Oct 30 19:19:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Oct 2011 18:19:55 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <E1RKZz1-0004hx-BC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 608975eafe86 by Antoine Pitrou in branch '3.2':
Issue #10363: Deallocate global locks in Py_Finalize().
http://hg.python.org/cpython/rev/608975eafe86

New changeset 728595c16acd by Antoine Pitrou in branch 'default':
Issue #10363: Deallocate global locks in Py_Finalize().
http://hg.python.org/cpython/rev/728595c16acd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________

From report at bugs.python.org  Sun Oct 30 19:43:12 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 30 Oct 2011 18:43:12 +0000
Subject: [issue13265] IDLE crashes when printing some unprintable characters.
In-Reply-To: <1319608129.37.0.0558883356195.issue13265@psf.upfronthosting.co.za>
Message-ID: <1320000192.43.0.725719050405.issue13265@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I can reproduce the problem with Ubuntu 11.04 with Python 3.2. The WidgetRedirector calls tk_call with a tuple containing unencoded Unicode strings. 

Attached is a patch to encode all arguments if the argument has the "encode" attribute. This seems to fix the problem, but can someone who knows more about Python and Tk's Unicode handling take a look?

----------
keywords: +patch
nosy: +serwy
Added file: http://bugs.python.org/file23561/patch13265.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13265>
_______________________________________

From report at bugs.python.org  Sun Oct 30 19:43:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 30 Oct 2011 18:43:24 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1319997748.61.0.676793938656.issue12498@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0tzYpbocux-rDGiwiyTWquvGzOte6tW2F2ywa-3OZZww@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> While writing the test case, I found out that the test case does not
> fail before the patch. It seems that draining the output buffer
> already works:
>
> The attached script 'asyncore_shutdown.py' drains the output buffer
> when run without the patch, with Python 3.2, and prints 'Done.'. The
> dispatcher_with_send handle_close() method is never called.

That's because you didn't define a handle_read() method: since you
never read from the socket, you don't detect EOF, and never call
handle_close():

Try with this:
"""
             print('Done.')
             self.close()

+    def handle_read(self):
+        self.recv(MSG_SIZE)
+
     def handle_close(self):
         print('calling handle_close')
         asyncore.dispatcher_with_send.handle_close(self)
"""

And it'll fail ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12498>
_______________________________________

From report at bugs.python.org  Sun Oct 30 20:10:49 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 30 Oct 2011 19:10:49 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1320001849.2.0.522761398517.issue12797@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Updated patch:
* checks for long overflow
* raises original exception if opener returns null
* makes it explicit that "opener" must return an open file descriptor.

I don't think that mode should be passed in since it is not specified in the parameters to open() (and always defaults to 0o666 anyway). Specifying the file mode should be left to the opener if needed.

----------
Added file: http://bugs.python.org/file23562/opener_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sun Oct 30 20:23:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Oct 2011 19:23:07 +0000
Subject: [issue10519] setobject.c no-op typo
In-Reply-To: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>
Message-ID: <E1RKay8-0000Yf-Pk@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5c17394b0b95 by Petri Lehtinen in branch '3.2':
Add Misc/NEWS entry for issue #10519
http://hg.python.org/cpython/rev/5c17394b0b95

New changeset 3bda54275817 by Petri Lehtinen in branch '2.7':
Add Misc/NEWS entry for issue #10519
http://hg.python.org/cpython/rev/3bda54275817

New changeset a912ea48dd4c by Petri Lehtinen in branch 'default':
Add Misc/NEWS entry for issue #10519
http://hg.python.org/cpython/rev/a912ea48dd4c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10519>
_______________________________________

From report at bugs.python.org  Sun Oct 30 20:26:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Oct 2011 19:26:54 +0000
Subject: [issue13293] xmlrpc.client encode error
In-Reply-To: <1319979355.49.0.42965800698.issue13293@psf.upfronthosting.co.za>
Message-ID: <E1RKb1r-0000sY-62@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 013d2881beb5 by Florent Xicluna in branch '3.2':
Issue #13293: Better error message when trying to marshal bytes using xmlrpc.client.
http://hg.python.org/cpython/rev/013d2881beb5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13293>
_______________________________________

From report at bugs.python.org  Sun Oct 30 20:26:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Oct 2011 19:26:54 +0000
Subject: [issue13291] latent NameError in xmlrpc package
In-Reply-To: <1319928683.07.0.326015714252.issue13291@psf.upfronthosting.co.za>
Message-ID: <E1RKb1r-0000sY-5v@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f3d454b20b35 by Florent Xicluna in branch '3.2':
Closes #13291: NameError in xmlrpc package.
http://hg.python.org/cpython/rev/f3d454b20b35

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13291>
_______________________________________

From report at bugs.python.org  Sun Oct 30 20:51:05 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 30 Oct 2011 19:51:05 +0000
Subject: [issue1467929] %-formatting and dicts
Message-ID: <1320004265.43.0.213605511822.issue1467929@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
stage: needs patch -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1467929>
_______________________________________

From report at bugs.python.org  Sun Oct 30 21:41:14 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 30 Oct 2011 20:41:14 +0000
Subject: [issue13295] html5 template for Lib/http/server.py
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1320007274.91.0.795945170757.issue13295@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ezio: your patch is fine for 3.3. I agree it's not a bug fix.
I propose the following additional changes, though:
- the name of the root element should be lower-case in the DOCTYPE declaration.
- DEFAULT_ERROR_MESSAGE should get an opening html tag.

karl: HTML 3.2 may be old, but it's not outdated.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Sun Oct 30 22:15:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 30 Oct 2011 21:15:54 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1320009354.08.0.128131891467.issue12105@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: fixed -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun Oct 30 22:29:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Oct 2011 21:29:24 +0000
Subject: [issue13274] heapq pure python version uses islice without guarding
	for negative counts
In-Reply-To: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za>
Message-ID: <E1RKcwP-0000pT-9B@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 57f73b0f921c by Raymond Hettinger in branch '2.7':
Issue 13274:  Make the pure python code for heapq more closely match the C implementation for an undefined corner case.
http://hg.python.org/cpython/rev/57f73b0f921c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13274>
_______________________________________

From report at bugs.python.org  Sun Oct 30 22:33:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Oct 2011 21:33:59 +0000
Subject: [issue13274] heapq pure python version uses islice without guarding
	for negative counts
In-Reply-To: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za>
Message-ID: <E1RKd0q-00018l-CV@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 155e57a449b5 by Raymond Hettinger in branch '3.2':
Issue 13274:  Make the pure python code for heapq more closely match the C implementation for an undefined corner case.
http://hg.python.org/cpython/rev/155e57a449b5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13274>
_______________________________________

From report at bugs.python.org  Sun Oct 30 22:38:16 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 30 Oct 2011 21:38:16 +0000
Subject: [issue13274] heapq pure python version uses islice without guarding
	for negative counts
In-Reply-To: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za>
Message-ID: <1320010696.27.0.542556187416.issue13274@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I went ahead an added the guards to the pure python code.

Still disagree with your assertion that non-cpython implementations were somehow broken when an undefined behavior was implemented in a different way -- nsmallest() and nlargest() have no guaranteed meaning for negative numbers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13274>
_______________________________________

From report at bugs.python.org  Sun Oct 30 22:45:57 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 30 Oct 2011 21:45:57 +0000
Subject: [issue13265] IDLE crashes when printing some unprintable characters.
In-Reply-To: <1319608129.37.0.0558883356195.issue13265@psf.upfronthosting.co.za>
Message-ID: <1320011157.93.0.866672001775.issue13265@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Sorry, I should have noticed earlier that this is a duplicate of Issue12342.  The problem is simply that Tcl/Tk does not currently support the display of Unicode code points outside of the BMP.  The question then is what IDLE to do when asked to display such characters.  The current behavior of letting tkinter detect the unsupported code point and bubbling up a somewhat unhelpful exception message is not the most user-friendly response.  Let's continue any discussion of this over on the earlier issue.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> characters with ord above 65535 fail to display in IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13265>
_______________________________________

From report at bugs.python.org  Sun Oct 30 22:46:56 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 30 Oct 2011 21:46:56 +0000
Subject: [issue12342] characters with ord above 65535 fail to display in IDLE
In-Reply-To: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>
Message-ID: <1320011216.06.0.83774941329.issue12342@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Merging CC list from duplicate Issue13265.

----------
nosy: +ezio.melotti, kbk, maniram.maniram, serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12342>
_______________________________________

From report at bugs.python.org  Sun Oct 30 22:48:29 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 30 Oct 2011 21:48:29 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320011309.89.0.757492025876.issue12498@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> That's because you didn't define a handle_read() method

Ooops...

Attached is a patch for dispatcher_with_send and asynchat with a test
case for each, that fail when the fix is not applied.

----------
Added file: http://bugs.python.org/file23563/asyncore_drain_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12498>
_______________________________________

From report at bugs.python.org  Sun Oct 30 23:33:31 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 30 Oct 2011 22:33:31 +0000
Subject: [issue12342] characters with ord above 65535 fail to display in IDLE
In-Reply-To: <1308171600.34.0.388895530939.issue12342@psf.upfronthosting.co.za>
Message-ID: <1320014011.83.0.190099163174.issue12342@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Changing the error message sounds fine to me.

People in need of the feature should lobby their system vendors to provide a Tcl build that uses a 32-bit Tcl_UniChar. Not sure whether it would actually render the string correctly, but at least it would be able to represent it correctly internally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12342>
_______________________________________

From report at bugs.python.org  Mon Oct 31 00:29:19 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 30 Oct 2011 23:29:19 +0000
Subject: [issue2979] use_datetime in SimpleXMLRPCServer
In-Reply-To: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
Message-ID: <1320017359.29.0.653825582196.issue2979@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
stage: needs patch -> patch review
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2979>
_______________________________________

From report at bugs.python.org  Mon Oct 31 00:41:40 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 30 Oct 2011 23:41:40 +0000
Subject: [issue13297] xmlrpc.client could accept bytes for input and output
Message-ID: <1320018100.14.0.184941596185.issue13297@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

Since Python 3 makes clear the distinction between bytes and string, there is no more reason to use the xmlrpc.client.Binary wrapper for binary objects.

The xmlrpc library may deal with bytes and bytearray normally.
To support backward compatibility, the ServerProxy will have a keyword argument "use_bytes" similar to the "use_datetime" from issue #1120353.

----------
components: Library (Lib), XML
messages: 146666
nosy: flox
priority: normal
severity: normal
status: open
title: xmlrpc.client could accept bytes for input and output
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13297>
_______________________________________

From report at bugs.python.org  Mon Oct 31 00:44:36 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 30 Oct 2011 23:44:36 +0000
Subject: [issue13297] xmlrpc.client could accept bytes for input and output
In-Reply-To: <1320018100.14.0.184941596185.issue13297@psf.upfronthosting.co.za>
Message-ID: <1320018276.16.0.949729915042.issue13297@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file23564/issue13297_xmlrpc_bytes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13297>
_______________________________________

From report at bugs.python.org  Mon Oct 31 00:49:37 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 30 Oct 2011 23:49:37 +0000
Subject: [issue13293] xmlrpc.client encode error
In-Reply-To: <1319979355.49.0.42965800698.issue13293@psf.upfronthosting.co.za>
Message-ID: <1320018577.98.0.0923865021306.issue13293@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

FWIW, I opened a feature request #13297.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13293>
_______________________________________

From report at bugs.python.org  Mon Oct 31 01:01:49 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 31 Oct 2011 00:01:49 +0000
Subject: [issue13281] robotparser.RobotFileParser ignores rules preceeded by a
	blank line
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1320019309.85.0.424736960495.issue13281@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I agree with your interpretation of the RFC. The parsing rules do not specify any provision for inclusion of blank lines "within" the records.

However, I find that inclusion is no harm either. I checked that with a robots.txt parser (Google webmaster tools) and presented the last.fm's robots.txt file which had blank line within records. As expected, it did not crib. 

I would say that we can be lenient on this front and the question would if we allow, would it break any parsing rules? I think, no.

The patch does not break any tests, but a new test should be added to reflect this situation. 

I don't have a strong opinion on having a strict=(True|False) for the blank line accommodation within records(only). I think, it is better we don't add a new parameter and just be lenient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Mon Oct 31 01:14:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Oct 2011 00:14:37 +0000
Subject: [issue13298] Result type depends on order of operands for bytes and
	bytearray
Message-ID: <1320020077.78.0.866789839878.issue13298@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

In a recent python-ideas discussion of the differences between concatenation and augmented assignment on lists, I pointed out the general guiding principle behind Python's binary operation semantics was that the type of a binary operation should not depend on the order of the operands. That is "X op Y" and "Y op X" should either consistently create results of the same type ("1 + 1.1", "1.1 + 1") or else throw an exception ("[] + ()", "() + []").

This principle is why list concatenation normally only works with other lists, but will accept arbitrary iterables for augmented assignment. collections.deque exhibits similar behaviour (i.e. strict on the binary operation, permissive on augmented assignment).

However, bytes and bytearray don't follow this principle - they accept anything that implements the buffer interface even in the binary operation, leading to the following asymmetries:

>>> b'' + bytearray()
b''
>>> b'' + memoryview(b'')
b''
>>> bytearray() + b''
bytearray(b'')
>>> bytearray() + memoryview(b'')
bytearray(b'')
>>> memoryview(b'') + b''
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'memoryview' and 'bytes'
>>> memoryview(b'') + bytearray(b'')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'memoryview' and 'bytearray'

Now, the latter two cases are due to a known problem where returning NotImplemented from sq_concat or sq_repeat doesn't work properly (so none of the relevant method implementations in the stdlib even try), but the bytes and bytearray interaction is exactly the kind of type asymmetry the operand order independence guideline is intended to prevent.

My question is - do we care enough to try to change this? If we do, then it's necessary to decide on more appropriate semantics:

1. The "list" solution, permitting only the same type in binary operations (high risk of breaking quite a lot of code)
2. Don't allow arbitrary buffers, but do allow bytes/bytearray interoperability
  2a. always return bytes from mixed operations
  2b. always return bytearray from mixed operations
  2c. return the type of the first operand (ala set.__or__)

Or just accept that this really is more of a guideline than a rule and adjust the documentation accordingly.

----------
components: Interpreter Core
messages: 146669
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Result type depends on order of operands for bytes and bytearray
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13298>
_______________________________________

From report at bugs.python.org  Mon Oct 31 01:32:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Oct 2011 00:32:25 +0000
Subject: [issue13299] namedtuple row factory for sqlite3
Message-ID: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Currently, sqlite3 allows rows to be easily returned as ordinary tuples (default) or sqlite3.Row objects (which allow dict-style access).

collections.namedtuple provides a much nicer interface than sqlite3.Row for accessing ordered data which uses valid Python identifiers for field names, and can also tolerate field names which are *not* valid identifiers.

It would be convenient if sqlite3 provided a row factory along the lines of the one posted here:
http://peter-hoffmann.com/2010/python-sqlite-namedtuple-factory.html

(except with smarter caching on the named tuples)

----------
messages: 146670
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: namedtuple row factory for sqlite3
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13299>
_______________________________________

From report at bugs.python.org  Mon Oct 31 01:35:47 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 31 Oct 2011 00:35:47 +0000
Subject: [issue2979] use_datetime in SimpleXMLRPCServer
In-Reply-To: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
Message-ID: <1320021347.67.0.827717263303.issue2979@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
assignee:  -> flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2979>
_______________________________________

From report at bugs.python.org  Mon Oct 31 01:39:38 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 31 Oct 2011 00:39:38 +0000
Subject: [issue13298] Result type depends on order of operands for bytes and
	bytearray
In-Reply-To: <1320020077.78.0.866789839878.issue13298@psf.upfronthosting.co.za>
Message-ID: <1320021578.97.0.83307199907.issue13298@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13298>
_______________________________________

From report at bugs.python.org  Mon Oct 31 02:27:38 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 31 Oct 2011 01:27:38 +0000
Subject: [issue13226] Expose RTLD_* constants in the posix module
In-Reply-To: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za>
Message-ID: <1320024458.6.0.438176501509.issue13226@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Python/sysmodule.c still contains references to DLFCN module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13226>
_______________________________________

From report at bugs.python.org  Mon Oct 31 03:06:39 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 31 Oct 2011 02:06:39 +0000
Subject: [issue13300] IDLE 3.3 Restart Shell command fails
Message-ID: <1320026799.26.0.540984948832.issue13300@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Currently in the default (pre-3.3) branch, IDLE fails if its Restart Shell command is attempted:

Exception in Tkinter callback
Traceback (most recent call last):
  File "Lib/tkinter/__init__.py", line 1397, in __call__
    return self.func(*args)
  File "Lib/idlelib/PyShell.py", line 1180, in restart_shell
    self.interp.restart_subprocess()
  File "Lib/idlelib/PyShell.py", line 429, in restart_subprocess
    self.rpcclt.accept()
  File "Lib/idlelib/rpc.py", line 525, in accept
    working_sock, address = self.listening_sock.accept()
  File "Lib/socket.py", line 134, in accept
    fd, addr = self._accept()
OSError: [Errno 9] Bad file descriptor
IDLE Subprocess: socket error: Connection refused, retrying....
IDLE Subprocess: socket error: Connection refused, retrying....

Warning (from warnings module):
  File "Lib/idlelib/run.py", line 127
    socket_error = err
ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=0>
IDLE Subprocess: socket error: Connection refused, retrying....

The culprit is recent changeset 3a5a0943b201 which attempted to prevent some debug ResourceWarnings during IDLE shutdown.  Adding the close override to the RPCClient class causes the listening socket to be closed when the shell is restarted but then a new listening socket is not opened.  The listening socket should only be closed when IDLE terminates, not when the subprocess is restarted.

----------
assignee: ned.deily
components: IDLE
messages: 146672
nosy: amaury.forgeotdarc, ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE 3.3 Restart Shell command fails
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13300>
_______________________________________

From report at bugs.python.org  Mon Oct 31 03:13:31 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 31 Oct 2011 02:13:31 +0000
Subject: [issue13300] IDLE 3.3 Restart Shell command fails
In-Reply-To: <1320026799.26.0.540984948832.issue13300@psf.upfronthosting.co.za>
Message-ID: <1320027211.02.0.340419558158.issue13300@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23565/issue13300-3x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13300>
_______________________________________

From report at bugs.python.org  Mon Oct 31 04:06:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 31 Oct 2011 03:06:29 +0000
Subject: [issue13296] IDLE: __future__ flags don't clear on shell restart
In-Reply-To: <1319995491.95.0.0388029066665.issue13296@psf.upfronthosting.co.za>
Message-ID: <E1RKiCb-0006P2-R4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 87251608cb64 by Ned Deily in branch '2.7':
Issue 13296: Fix IDLE to clear compile __future__ flags on shell restart.
http://hg.python.org/cpython/rev/87251608cb64

New changeset 9fbf79d6be56 by Ned Deily in branch '3.2':
Issue 13296: Fix IDLE to clear compile __future__ flags on shell restart.
http://hg.python.org/cpython/rev/9fbf79d6be56

New changeset d8acd4344ce9 by Ned Deily in branch 'default':
Issue 13296: Fix IDLE to clear compile __future__ flags on shell restart.
http://hg.python.org/cpython/rev/d8acd4344ce9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13296>
_______________________________________

From report at bugs.python.org  Mon Oct 31 04:08:36 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 31 Oct 2011 03:08:36 +0000
Subject: [issue13296] IDLE: __future__ flags don't clear on shell restart
In-Reply-To: <1319995491.95.0.0388029066665.issue13296@psf.upfronthosting.co.za>
Message-ID: <1320030516.47.0.851617052365.issue13296@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the patch!  Committed to 27 (for release in 2.7.3), 32 (for 3.2.3), and default (for 3.3).

----------
assignee:  -> ned.deily
nosy: +ned.deily
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13296>
_______________________________________

From report at bugs.python.org  Mon Oct 31 04:22:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 31 Oct 2011 03:22:28 +0000
Subject: [issue13281] Make robotparser.RobotFileParser ignore blank lines
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1320031348.82.0.289846322566.issue13281@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since following the spec is not a bug, this issue is a feature request for 3.3. I agree with just being lenient with no added parameter. Perhaps that should be mentioned in the doc with (or in) a version-added note. Senthil: does doc standard allow something like

Version added 3.3: Ignore blanks lines within record groups.
?

----------
title: robotparser.RobotFileParser ignores rules preceeded by a blank line -> Make robotparser.RobotFileParser ignore blank lines
type: behavior -> feature request
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Mon Oct 31 06:12:23 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 31 Oct 2011 05:12:23 +0000
Subject: [issue13299] namedtuple row factory for sqlite3
In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za>
Message-ID: <1320037943.87.0.854625848025.issue13299@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13299>
_______________________________________

From report at bugs.python.org  Mon Oct 31 08:00:09 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 31 Oct 2011 07:00:09 +0000
Subject: [issue5219] IDLE/Tkinter: edit win stops updating when tooltip is
	active
In-Reply-To: <1234382300.54.0.847679485731.issue5219@psf.upfronthosting.co.za>
Message-ID: <1320044409.02.0.637834540977.issue5219@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I can fairly easily reproduce the hang on a current OS X system and the latest patch appears to solve the problem.  Looks good to me.

----------
nosy: +ned.deily
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5219>
_______________________________________

From report at bugs.python.org  Mon Oct 31 08:41:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 31 Oct 2011 07:41:15 +0000
Subject: [issue13246] Py_UCS4_strlen and friends needn't be public
In-Reply-To: <1319314430.74.0.993573606288.issue13246@psf.upfronthosting.co.za>
Message-ID: <E1RKmUW-0007di-Fz@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 80a7ab9ac29f by Martin v. L?wis in branch 'default':
Drop Py_UCS4_ functions. Closes #13246.
http://hg.python.org/cpython/rev/80a7ab9ac29f

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13246>
_______________________________________

From report at bugs.python.org  Mon Oct 31 10:18:16 2011
From: report at bugs.python.org (David Jean Louis)
Date: Mon, 31 Oct 2011 09:18:16 +0000
Subject: [issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code
	execution via po files
Message-ID: <1320052696.17.0.926291745102.issue13301@psf.upfronthosting.co.za>


New submission from David Jean Louis <izimobil at gmail.com>:

Hi, 

I'm the author of the polib python module, incidentally (after a bug report in polib: https://bitbucket.org/izi/polib/issue/27/polib-doesnt-check-unescaped-quote) I've found that the eval() in Tools/i18n/msgfmt.py allows arbitrary code execution, someone could create a malicious po entry like this:

msgid "owned!"
msgstr "" or __import__("os").popen("rm -rf /")

As this is an "internal tool" used by developers, maybe it is not very important, but given that people may reuse this script for generating mo files, I think this needs to be fixed, I'm adding a patch for this issue.

Regards,

-- 
David

----------
components: Demos and Tools
files: msgfmt.py.diff
keywords: patch
messages: 146678
nosy: izi
priority: normal
severity: normal
status: open
title: the script Tools/i18n/msgfmt.py allows arbitrary code execution via po files
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23566/msgfmt.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13301>
_______________________________________

From report at bugs.python.org  Mon Oct 31 10:22:32 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 31 Oct 2011 09:22:32 +0000
Subject: [issue13298] Result type depends on order of operands for bytes and
	bytearray
In-Reply-To: <1320020077.78.0.866789839878.issue13298@psf.upfronthosting.co.za>
Message-ID: <1320052952.22.0.920277137493.issue13298@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13298>
_______________________________________

From report at bugs.python.org  Mon Oct 31 10:26:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 31 Oct 2011 09:26:02 +0000
Subject: [issue13281] Make robotparser.RobotFileParser ignore blank lines
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1320053162.73.0.921335107414.issue13281@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If it's added it should be a versionchanged, not a versionadded.
I'm also not entirely sure this should be considered a new feature and don't see the point of having a strict mode.  IMHO robotparser should honor what the robots.txt files say, and not doing so because there's an extra blank line doesn't strike me as a useful behavior.  Of course it shouldn't parse every kind of broken syntax, but the OP pointed to two fairly popular websites that use blank lines and that seems to indicate that blank lines are generally allowed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Mon Oct 31 10:30:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 31 Oct 2011 09:30:27 +0000
Subject: [issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code
	execution via po files
In-Reply-To: <1320052696.17.0.926291745102.issue13301@psf.upfronthosting.co.za>
Message-ID: <1320053427.71.0.591929909092.issue13301@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +barry, benjamin.peterson, ezio.melotti, georg.brandl
stage:  -> patch review
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13301>
_______________________________________

From report at bugs.python.org  Mon Oct 31 10:34:06 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 31 Oct 2011 09:34:06 +0000
Subject: [issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code
	execution via po files
In-Reply-To: <1320052696.17.0.926291745102.issue13301@psf.upfronthosting.co.za>
Message-ID: <1320053646.35.0.423637585408.issue13301@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13301>
_______________________________________

From report at bugs.python.org  Mon Oct 31 10:58:49 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 31 Oct 2011 09:58:49 +0000
Subject: [issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code
	execution via po files
In-Reply-To: <1320052696.17.0.926291745102.issue13301@psf.upfronthosting.co.za>
Message-ID: <1320055129.85.0.840484451035.issue13301@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This should be fixed; the patch doesn't seem correct though, it doesn't handle escapes like eval() would.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13301>
_______________________________________

From report at bugs.python.org  Mon Oct 31 11:02:40 2011
From: report at bugs.python.org (David Jean Louis)
Date: Mon, 31 Oct 2011 10:02:40 +0000
Subject: [issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code
	execution via po files
In-Reply-To: <1320052696.17.0.926291745102.issue13301@psf.upfronthosting.co.za>
Message-ID: <1320055360.97.0.98731934585.issue13301@psf.upfronthosting.co.za>


David Jean Louis <izimobil at gmail.com> added the comment:

I'm adding an updated patch that also handles unescaped double quote at the beginning of the string.

----------
versions: +Python 2.6, Python 3.1, Python 3.4
Added file: http://bugs.python.org/file23567/msgfmt.py.diff.update1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13301>
_______________________________________

From report at bugs.python.org  Mon Oct 31 11:04:54 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 31 Oct 2011 10:04:54 +0000
Subject: [issue1234674] filecmp.cmp's "shallow" option
Message-ID: <1320055494.79.0.326160277805.issue1234674@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
we recently received a this message on docs@ : http://mail.python.org/pipermail/docs/2011-October/006121.html that's actually related to this issue: how can we move it forward?

----------
nosy: +sandro.tosi
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1234674>
_______________________________________

From report at bugs.python.org  Mon Oct 31 11:06:24 2011
From: report at bugs.python.org (David Jean Louis)
Date: Mon, 31 Oct 2011 10:06:24 +0000
Subject: [issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code
	execution via po files
In-Reply-To: <1320052696.17.0.926291745102.issue13301@psf.upfronthosting.co.za>
Message-ID: <1320055584.26.0.17318878636.issue13301@psf.upfronthosting.co.za>


David Jean Louis <izimobil at gmail.com> added the comment:

Hmm, I missed your previous message, indeed, unescaping is not handled by this patch, sorry about that. Here's how it is handled in polib:
https://bitbucket.org/izi/polib/src/dbafdc621bf4/polib.py#cl-206

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13301>
_______________________________________

From report at bugs.python.org  Mon Oct 31 11:22:04 2011
From: report at bugs.python.org (David Townshend)
Date: Mon, 31 Oct 2011 10:22:04 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1320056524.33.0.982594959643.issue12760@psf.upfronthosting.co.za>


David Townshend <aquavitae69 at gmail.com> added the comment:

I see this has been marked as a duplicate of http://bugs.python.org/issue12797.  Please explain how this is, since that proposal does not appear to provide the functionality discussed here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Mon Oct 31 11:22:44 2011
From: report at bugs.python.org (john doe)
Date: Mon, 31 Oct 2011 10:22:44 +0000
Subject: [issue1336] subprocess.Popen hangs when child writes to stderr
In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za>
Message-ID: <1320056564.29.0.110558034625.issue1336@psf.upfronthosting.co.za>


john doe <tnagy1024 at gmail.com> added the comment:

The following piece of code does not seem to be thread-safe:

gc.disable()
try:
    os.fork()
except:
    ...

If calling subprocess.Popen() is supposed to work from threads without any particular protection, then a lock is needed in subprocess.py:

try:
   spawn_lock.acquire()
   gc.disable()
   try:
       os.fork()
   except:
       ...
finally:
   spawn_lock.release()

Such issues are very difficult to reproduce and to track. The documentation should at least mention that calling gc.enable() may cause subprocess() to hang!

The following issue seems to be relevant: http://bugs.python.org/issue12739

----------
nosy: +ita1024

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1336>
_______________________________________

From report at bugs.python.org  Mon Oct 31 11:32:11 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 31 Oct 2011 10:32:11 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1320057131.67.0.966689497472.issue12760@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

issue12797 would allow things like:

def create_exclusive_file(filename):
  return open(filename, "w",
              opener=lambda path, mode: os.open(path, mode|os.O_CREAT|os.O_EXCL))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Mon Oct 31 11:41:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 Oct 2011 10:41:06 +0000
Subject: [issue1336] subprocess.Popen hangs when child writes to stderr
In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za>
Message-ID: <1320057666.92.0.418714740816.issue1336@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1336>
_______________________________________

From report at bugs.python.org  Mon Oct 31 11:42:43 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 31 Oct 2011 10:42:43 +0000
Subject: [issue13302] Clarification needed in C API arg parsing
Message-ID: <1320057763.71.0.58387430149.issue13302@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello,
given I can't fully comprehend the user request (sent on docs@ as of http://mail.python.org/pipermail/docs/2011-September/005791.html), I'm just echoing it :

>>>
recently I embedded Python into one of my applications, which included
some string parsing.
In my opinion the doc page about parsing arguments
(http://docs.python.org/c-api/arg.html) is missing the information, that
you must not free the returned const char *, like e.g. said here
(http://docs.python.org/c-api/string.html#PyString_AsString).
It was quite confusing for my first, so I would suggest adding this tiny
bit of information.
<<<

----------
assignee: docs at python
components: Documentation
messages: 146687
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarification needed in C API arg parsing
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13302>
_______________________________________

From report at bugs.python.org  Mon Oct 31 11:50:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 31 Oct 2011 10:50:33 +0000
Subject: [issue13226] Expose RTLD_* constants in the posix module
In-Reply-To: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za>
Message-ID: <E1RKpRh-00063f-IJ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 05e2bdc00c0c by Victor Stinner in branch 'default':
Issue #13226: Update sys.setdlopenflags() docstring
http://hg.python.org/cpython/rev/05e2bdc00c0c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13226>
_______________________________________

From report at bugs.python.org  Mon Oct 31 11:55:16 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 31 Oct 2011 10:55:16 +0000
Subject: [issue2979] use_datetime in SimpleXMLRPCServer
In-Reply-To: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
Message-ID: <1320058516.68.0.296768369284.issue2979@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

2096158376e5 broke test_xmlrpc:

"""
======================================================================
ERROR: test_datetime_before_1900 (test.test_xmlrpc.XMLRPCTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cf/python/cpython/Lib/test/test_xmlrpc.py", line 62, in test_datetime_before_1900
    (newdt,), m = xmlrpclib.loads(s, use_datetime=1)
  File "/home/cf/python/cpython/Lib/xmlrpc/client.py", line 969, in loads
    p.feed(data)
  File "/home/cf/python/cpython/Lib/xmlrpc/client.py", line 430, in feed
    self._parser.Parse(data, 0)
  File "/home/cf/python/cpython/Lib/xmlrpc/client.py", line 662, in end
    return f(self, "".join(self._data))
  File "/home/cf/python/cpython/Lib/xmlrpc/client.py", line 745, in end_dateTime
    value = _datetime_type(data)
  File "/home/cf/python/cpython/Lib/xmlrpc/client.py", line 359, in _datetime_type
    return datetime.strptime(data, "%Y%m%dT%H:%M:%S")
  File "/home/cf/python/cpython/Lib/_strptime.py", line 488, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/home/cf/python/cpython/Lib/_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '10210T11:41:23' does not match format '%Y%m%dT%H:%M:%S'

----------------------------------------------------------------------
"""

That's because datetime.strptime() expects a year ("%Y") on exactly 4 digits:
"""
            #XXX: Does 'Y' need to worry about having less or more than
            #     4 digits?
            'Y': r"(?P<Y>\d\d\d\d)",
"""

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2979>
_______________________________________

From report at bugs.python.org  Mon Oct 31 11:55:36 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 31 Oct 2011 10:55:36 +0000
Subject: [issue1336] subprocess.Popen hangs when child writes to stderr
In-Reply-To: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za>
Message-ID: <1320058536.43.0.988998094835.issue1336@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

ita1024: please don't post to closed issues; your message here will be ignored.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1336>
_______________________________________

From report at bugs.python.org  Mon Oct 31 12:01:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 Oct 2011 11:01:11 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
Message-ID: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 1186, in runtest_inner
    indirect_test()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_ttk_textonly.py", line 11, in test_main
    *runtktests.get_tests(gui=False, packages=['test_ttk']))
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/tkinter/test/runtktests.py", line 65, in get_tests
    for module in get_tests_modules(gui=gui, packages=packages):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/tkinter/test/runtktests.py", line 50, in get_tests_modules
    "tkinter.test")
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/__init__.py", line 123, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 834, in _gcd_import
    loader.load_module(name)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 460, in load_module
    return self._load_module(fullname)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 164, in decorated
    return fxn(self, module, *args, **kwargs)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 365, in _load_module
    exec(code_object, module.__dict__)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/tkinter/test/test_ttk/test_style.py", line 6, in <module>
    import tkinter.test.support as support
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 460, in load_module
    return self._load_module(fullname)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 164, in decorated
    return fxn(self, module, *args, **kwargs)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 353, in _load_module
    code_object = self.get_code(name)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 447, in get_code
    self.set_data(bytecode_path, data)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 514, in set_data
    _write_atomic(path, data)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 94, in _write_atomic
    _os.rename(path_tmp, path)
FileNotFoundError: [Errno 2] No such file or directory

----------
components: Library (Lib)
messages: 146691
nosy: brett.cannon, haypo, pitrou
priority: normal
severity: normal
status: open
title: Sporadic importlib failures: FileNotFoundError on os.rename()
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Mon Oct 31 12:17:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 31 Oct 2011 11:17:33 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320059853.88.0.807408481829.issue13303@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

There's a race in _write_atomic():
"""
        # On POSIX-like platforms, renaming is atomic
        path_tmp = path + '.tmp'
        try:
            fd = _os.open(path_tmp, _os.O_EXCL | _os.O_CREAT | _os.O_WRONLY)
            with _io.FileIO(fd, 'wb') as file:
                file.write(data)
            _os.rename(path_tmp, path)
        except OSError:
            try:
                _os.unlink(path_tmp)
            except OSError:
                pass
            raise
"""

Let's pretend a process managed to open the file (with O_EXCL): before it finishes and calls rename(), another process tries to open the file: since it can't create it (with O_EXCL), it jumps to:

        except OSError:
            try:
                _os.unlink(path_tmp)
            except OSError:
                pass
            raise

and unlinks the file.
The first process then calls rename()...

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Mon Oct 31 12:32:37 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 31 Oct 2011 11:32:37 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320060757.13.0.248776004498.issue13303@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file23568/import_atomic_race.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Mon Oct 31 13:51:17 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Oct 2011 12:51:17 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1320065477.37.0.374519730211.issue11816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Bitbucket repo and attached patch updated relative to current tip.

----------
Added file: http://bugs.python.org/file23569/issue11816_get_opinfo_branch_20111031.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Oct 31 13:51:36 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Oct 2011 12:51:36 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1320065496.37.0.748560344203.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23197/issue11816_get_opinfo_branch_20110920.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Oct 31 13:51:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Oct 2011 12:51:39 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1320065499.95.0.548730941902.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23095/issue11816_get_opinfo_branch_20110904.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Oct 31 13:51:43 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Oct 2011 12:51:43 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1320065503.42.0.445341090563.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23019/issue11816_get_opinfo_branch_20110824.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Oct 31 13:51:46 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Oct 2011 12:51:46 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1320065506.57.0.293884547588.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file21599/dis.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Oct 31 13:58:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Oct 2011 12:58:58 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1320065938.21.0.55322693542.issue11682@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Bitbucket repo and attached patch updated relative to latest get_opinfo branch (which in turn was updated to apply cleanly against current CPython tip).

(I still need to incorporate the doc updates and look into adding keyword argument support)

----------
Added file: http://bugs.python.org/file23570/issue11682_pep380_branch_20111131.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Mon Oct 31 13:59:17 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Oct 2011 12:59:17 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1320065957.51.0.902625630934.issue11682@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file22616/pep380-missing-docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Mon Oct 31 13:59:20 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Oct 2011 12:59:20 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1320065960.47.0.798890014386.issue11682@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23096/issue11682_pep380_branch_20110904.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Mon Oct 31 15:44:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Oct 2011 14:44:38 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320072278.54.0.835667733706.issue13303@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This looks good to me. I'm slightly worried about what happens when there's a stale tmp file (for example if the Python process crashed before renaming it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Mon Oct 31 16:05:15 2011
From: report at bugs.python.org (karl)
Date: Mon, 31 Oct 2011 15:05:15 +0000
Subject: [issue13295] html5 template for Lib/http/server.py
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1320073515.82.0.400748361426.issue13295@psf.upfronthosting.co.za>


karl <karl+pythonbugs at la-grange.net> added the comment:

Ezio, Martin, 

HTML 3.2, HTML 4.01 are not outdated. They have stable specifications. That said their doctypes have not influence at all in browsers. The html5 doctype <!DOCTYPE html> has been chosen because it was the minimal string of characters that put the browsers into strict mode rendering (See Quirks Mode in CSS). The W3C validator is the only tool implementing an SGML parser able to understand HTML 3.2 and HTML 4.01. Note also that the W3C validtor includes an html5 validator if the concern is the validity of the output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Mon Oct 31 16:05:40 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 31 Oct 2011 15:05:40 +0000
Subject: [issue13283] removal of two unused variable in locale.py
In-Reply-To: <1319796863.15.0.791142726242.issue13283@psf.upfronthosting.co.za>
Message-ID: <1320073540.14.0.375225205134.issue13283@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

2.7 is a long term maintenance branch, and this patch is trivial enough. I think it is risk free :)

----------
assignee:  -> jcea
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13283>
_______________________________________

From report at bugs.python.org  Mon Oct 31 16:05:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 31 Oct 2011 15:05:53 +0000
Subject: [issue13283] removal of two unused variable in locale.py
In-Reply-To: <1319796863.15.0.791142726242.issue13283@psf.upfronthosting.co.za>
Message-ID: <E1RKtQo-0005Mh-C1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0694ebb5db99 by Jesus Cea in branch '2.7':
Closes #13283: removal of two unused variable in locale.py
http://hg.python.org/cpython/rev/0694ebb5db99

New changeset a479aad0231e by Jesus Cea in branch '3.2':
Closes #13283: removal of two unused variable in locale.py
http://hg.python.org/cpython/rev/a479aad0231e

New changeset a228890c624d by Jesus Cea in branch 'default':
MERGE: Closes #13283: removal of two unused variable in locale.py
http://hg.python.org/cpython/rev/a228890c624d

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13283>
_______________________________________

From report at bugs.python.org  Mon Oct 31 16:08:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 31 Oct 2011 15:08:01 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320073681.21.0.959123433038.issue13303@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Then we won't write the bytecode any more.
But it will be consistent.
The solution would be to create a random temporary file (with e.g. mkstemp()): in case of crash, we'll let dangling temporary files, but we'll be able to update the bytecode.
I'm note sure it's worth it (and it won't be easy since we're really restricted in what we're allowed to call).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Mon Oct 31 16:13:29 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 31 Oct 2011 15:13:29 +0000
Subject: [issue13295] html5 template for Lib/http/server.py
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1320074009.73.0.488662037488.issue13295@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

My point is that the HTML5 doctype doesn't bring us anything (except maybe a shorter string), so I don't see the point of changing it.
When the HTML5 spec is stable we can switch to it, but even then the update won't change anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Mon Oct 31 16:16:56 2011
From: report at bugs.python.org (Lucas Sinclair)
Date: Mon, 31 Oct 2011 15:16:56 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1320074216.57.0.339967940208.issue9750@psf.upfronthosting.co.za>


Lucas Sinclair <blastocyst at mac.com> added the comment:

Sure, I can have a try at it and address the issues you pointed out.

The URL to the guidelines you provided gives a 404. In what form exactly would you like the patch to be ?

I wouldn't mind either adding to the test suite, but I'm not sure how to do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Mon Oct 31 16:35:56 2011
From: report at bugs.python.org (karl)
Date: Mon, 31 Oct 2011 15:35:56 +0000
Subject: [issue13295] html5 template for Lib/http/server.py
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1320075356.72.0.987282400859.issue13295@psf.upfronthosting.co.za>


karl <karl+pythonbugs at la-grange.net> added the comment:

Yup. I doesn't bring anything except putting the output in line with the reality of browsers implementations. You may close it. I don't mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Mon Oct 31 16:51:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 31 Oct 2011 15:51:37 +0000
Subject: [issue13295] html5 template for Lib/http/server.py
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1320076297.48.0.554929411468.issue13295@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:08:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Oct 2011 16:08:24 +0000
Subject: [issue13295] html5 template for Lib/http/server.py
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1320077304.2.0.877170868062.issue13295@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d rather fix the page (look at the diff to find one violation: the first heading is an h2 instead of h1) and use an HTML5 doctype, as it?s just HTML 4.01 + pragmatism.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:09:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Oct 2011 16:09:46 +0000
Subject: [issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code
	execution via po files
In-Reply-To: <1320052696.17.0.926291745102.issue13301@psf.upfronthosting.co.za>
Message-ID: <1320077386.67.0.775178971175.issue13301@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13301>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:16:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Oct 2011 16:16:58 +0000
Subject: [issue13238] Add shell command helpers to shutil module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1320077818.8.0.1348812378.issue13238@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure my question was well phrased.

If I have these files:
  spam.py
  ham.py
  foo bar.py

will a pattern of '*.py' match all of them with your functions, even the one with an embedded space?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:22:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Oct 2011 16:22:46 +0000
Subject: [issue11638] python setup.py sdist crashes if version is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1320078166.97.0.78225774942.issue11638@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Here's a test for the bug.
Thanks!  Some comments are strange, but the patch is a good start.

> One way to fix the symptom (maybe not the correct way) would be to edit
> tarfile._Stream._init_write_gz
I?d rather change distutils, not tarfile.  I think the best place to encode it may be in the cmd module (see the make_archive method).

> I'm not positive UTF-8 is right
It is.

> and maybe it should only convert if isinstance(self.name, unicode).
Indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:29:48 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 31 Oct 2011 16:29:48 +0000
Subject: [issue13288] SSL module doesn't allow access to cert issuer
	information
In-Reply-To: <1319836342.01.0.0498331341848.issue13288@psf.upfronthosting.co.za>
Message-ID: <1320078588.84.0.226484296865.issue13288@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13288>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:31:27 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 31 Oct 2011 16:31:27 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320078687.84.0.142919296244.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Any progress on this?. I still see frequent OpenIndiana Buildbots failures because of this. Is anybody activelly working on this?. Should I get involved?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:32:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Oct 2011 16:32:49 +0000
Subject: [issue5875] test_distutils failing on OpenSUSE 10.3, Py3k
In-Reply-To: <1240991372.08.0.469372196929.issue5875@psf.upfronthosting.co.za>
Message-ID: <1320078769.84.0.500699492223.issue5875@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Here's the error message:
> error: File not found: /tmp/tmpsga9lh/foo/build/bdist.linux-i686/rpm/BUILDROOT/foo-0.1-1.i386/usr/local/lib/python3.3/site-packages/foo.pyc

Thanks.  Some rpm tool is looking for byte-compiled files in the old location, but I?ve fixed sdist (used under the cover by bdist_rpm) recently to use __pycache__ directories.  There must be some other code path that reports wrong locations for byte-compiled files, similar to the get_outputs methods that I fixed in another commit, but I?m unable to find it right now.  I?ll try to install Fedora in a VM when I get more time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5875>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:35:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Oct 2011 16:35:07 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1320078907.07.0.809936910167.issue670664@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

-    def set_cdata_mode(self):
+    def set_cdata_mode(self, elem):
Looks like an incompatible behavior change.  Is it only an internal method that will never affect users? code (even subclasses)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:41:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Oct 2011 16:41:23 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1320079283.76.0.0523951187063.issue9750@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Sure, I can have a try at it and address the issues you pointed out.
Nice!

> The URL to the guidelines you provided gives a 404.
They?ve moved to http://docs.python.org/devguide meanwhile.

> I wouldn't mind either adding to the test suite, but I'm not sure how to do that.
Edit Lib/sqlite3/test/dump.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:51:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 31 Oct 2011 16:51:21 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320079881.87.0.454279355141.issue13303@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch using pseudo-random filenames.
I used id(path) to generate a random name: it's faster than getpid(), and doesn't pollute strace's output (I'm one of strace's biggest fan :-).

----------
Added file: http://bugs.python.org/file23571/import_atomic_race-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:58:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Oct 2011 16:58:05 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320079881.87.0.454279355141.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320080026.3382.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Here's a patch using pseudo-random filenames.
> I used id(path) to generate a random name: it's faster than getpid(),
> and doesn't pollute strace's output (I'm one of strace's biggest
> fan :-).

If you go that way, you should also modify Python/import.c to use a
similar logic.
(it does sound a bit overkill to me :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:58:17 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 31 Oct 2011 16:58:17 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320080297.65.0.806337262898.issue11812@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Is anybody activelly working on this?.

I don't think so.

> Should I get involved?

Sure, if you have access to a machine on which you can reliably reproduce the problem, it'll be much easier. I would bet on a deficient name resolution service: using 127.0.0.1 instead of 'localhost' for support.HOST could help. It could also be due to a firewall setting (e.g., drop incoming connections requests when the connection rate is too high).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Mon Oct 31 17:59:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Oct 2011 16:59:57 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1320001849.2.0.522761398517.issue12797@psf.upfronthosting.co.za>
Message-ID: <1320080138.3382.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Updated patch:
> * checks for long overflow
> * raises original exception if opener returns null
> * makes it explicit that "opener" must return an open file descriptor.

This looks good to me. You just need to add a "versionchanged" attribute
in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Mon Oct 31 18:05:27 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 31 Oct 2011 17:05:27 +0000
Subject: [issue13295] html5 template for Lib/http/server.py
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1320080727.27.0.764973200548.issue13295@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I declare the original issue closed - there is no reason to switch to HTML 5 in this code.

There are side issues, such as the HTML 3.2 perhaps being incorrect; people who want to commit patches in that respect can just go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Mon Oct 31 18:05:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 31 Oct 2011 17:05:50 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320080750.81.0.150936749898.issue13303@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> (it does sound a bit overkill to me :-))

Well, it depends on what we want:
- if having a stale bytecode file indefinitely is acceptable, then the '.tmp' suffix approach is OK
- if not, then we should use pseudo-random files

> If you go that way, you should also modify Python/import.c to use a
> similar logic.

I think I would use mkstemp(), but yes, that's the idea.

So, what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Mon Oct 31 18:13:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 31 Oct 2011 17:13:22 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1320081202.1.0.815364818408.issue670664@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think it's internal.  While it's not explicitly mentioned in the source, the method is not documented and I don't think people subclassed it.  All that it does is changing the regex used to parse the data, and if someone needs to change this, it's probably easier to just change the regex.
OTOH this method is called just in one place, so in theory it's possible to set self.cdata_elem there before the set_cdata_mode() call, but that might make the code more fragile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Mon Oct 31 18:15:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Oct 2011 17:15:30 +0000
Subject: [issue13295] Fix HTML produced by http.server
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1320081330.55.0.764443764018.issue13295@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay.

----------
title: html5 template for Lib/http/server.py -> Fix HTML produced by http.server
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Mon Oct 31 18:29:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Oct 2011 17:29:46 +0000
Subject: [issue13170] distutils2 test failures
In-Reply-To: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>
Message-ID: <1320082186.44.0.993704439323.issue13170@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> When I do "import shutil" inside _backport/shutil.py
You shouldn?t do that!  Our backported module is fully stand-alone.

I have fixed the bug with this change in install_data.py:
 
-from shutil import Error
+from distutils2._backport.shutil import Error

I think I?m going to update our whole codebase to only use the backported shutil, never the stdlib one, for clarity (i.e. to avoid similar bugs in the future).

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Mon Oct 31 18:31:08 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 31 Oct 2011 17:31:08 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320082268.34.0.693627588995.issue13303@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch for Python/import.c using mkstemp(3). AFAICT, mkstemp should always be available (on Unix of course).

----------
Added file: http://bugs.python.org/file23572/import_atomic_race-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Mon Oct 31 18:40:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 31 Oct 2011 17:40:16 +0000
Subject: [issue10817] urllib.request.urlretrieve never raises
	ContentTooShortError if no reporthook
In-Reply-To: <1294069804.34.0.860239284714.issue10817@psf.upfronthosting.co.za>
Message-ID: <E1RKvqC-00040X-Ks@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2ca415cbf2ac by Senthil Kumaran in branch '3.2':
Fix issue 10817 - Fix urlretrieve function to raise ContentTooShortError
http://hg.python.org/cpython/rev/2ca415cbf2ac

New changeset e3e5b6f03f79 by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix issue 10817 - Fix urlretrieve function to raise ContentTooShortError
http://hg.python.org/cpython/rev/e3e5b6f03f79

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10817>
_______________________________________

From report at bugs.python.org  Mon Oct 31 19:31:08 2011
From: report at bugs.python.org (Carl Meyer)
Date: Mon, 31 Oct 2011 18:31:08 +0000
Subject: [issue13304] test_site assumes that site.ENABLE_USER_SITE is True
Message-ID: <1320085868.02.0.130211137087.issue13304@psf.upfronthosting.co.za>


New submission from Carl Meyer <carl at dirtcircle.com>:

If the test suite is run with PYTHONNOUSERSITE=true, the test_s_option test in test_site fails, because it implicitly assumes that site.ENABLE_USER_SITE is True and that site.USER_SITE should unconditionally be in sys.path.

This is a practical problem in the reference implementation for PEP 404, as the tests should pass when run from within a virtual environment, but a system-isolated virtual environment disables user-site (i.e. has the same effect as PYTHONNOUSERSITE).

I think the correct fix here is to conditionally skip that test if site.ENABLE_USER_SITE is not True.

I also think the module-level conditional check at the top of the file, which, if site.USER_SITE does not exist, creates site.USER_SITE and calls site.addsitedir() on it, should only run if site.ENABLE_USER_SITE is True.

----------
components: Tests
messages: 146722
nosy: carljm
priority: normal
severity: normal
status: open
title: test_site assumes that site.ENABLE_USER_SITE is True

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13304>
_______________________________________

From report at bugs.python.org  Mon Oct 31 19:33:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Oct 2011 18:33:10 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320082268.34.0.693627588995.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320085731.3382.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Here's a patch for Python/import.c using mkstemp(3). AFAICT, mkstemp
> should always be available (on Unix of course).

This looks fine to me. The code simplification tastes good :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Mon Oct 31 19:34:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 31 Oct 2011 18:34:30 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <E1RKwgg-00011J-Ry@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0d64d9ac2b78 by Ross Lagerwall in branch 'default':
Issue #12797: Added custom opener parameter to builtin open() and FileIO.open().
http://hg.python.org/cpython/rev/0d64d9ac2b78

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Mon Oct 31 19:36:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Oct 2011 18:36:50 +0000
Subject: [issue13291] latent NameError in xmlrpc package
In-Reply-To: <1319928683.07.0.326015714252.issue13291@psf.upfronthosting.co.za>
Message-ID: <1320086210.63.0.144577688037.issue13291@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently buildbot failures are caused by this commit:


======================================================================
ERROR: test_datetime_before_1900 (test.test_xmlrpc.XMLRPCTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_xmlrpc.py", line 62, in test_datetime_before_1900
    (newdt,), m = xmlrpclib.loads(s, use_datetime=1)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/xmlrpc/client.py", line 969, in loads
    p.feed(data)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/xmlrpc/client.py", line 430, in feed
    self._parser.Parse(data, 0)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/xmlrpc/client.py", line 662, in end
    return f(self, "".join(self._data))
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/xmlrpc/client.py", line 745, in end_dateTime
    value = _datetime_type(data)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/xmlrpc/client.py", line 359, in _datetime_type
    return datetime.strptime(data, "%Y%m%dT%H:%M:%S")
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/_strptime.py", line 488, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '10210T11:41:23' does not match format '%Y%m%dT%H:%M:%S'

http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/4704

----------
assignee:  -> flox
nosy: +pitrou
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13291>
_______________________________________

From report at bugs.python.org  Mon Oct 31 19:45:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 31 Oct 2011 18:45:25 +0000
Subject: [issue10817] urllib.request.urlretrieve never raises
	ContentTooShortError if no reporthook
In-Reply-To: <1294069804.34.0.860239284714.issue10817@psf.upfronthosting.co.za>
Message-ID: <E1RKwrF-0002E8-U9@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1ef30d6429db by Senthil Kumaran in branch '2.7':
Port to 2.7 - issue 10817 - Fix urlretrieve function to raise
http://hg.python.org/cpython/rev/1ef30d6429db

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10817>
_______________________________________

From report at bugs.python.org  Mon Oct 31 19:46:32 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 31 Oct 2011 18:46:32 +0000
Subject: [issue10817] urllib.request.urlretrieve never raises
	ContentTooShortError if no reporthook
In-Reply-To: <1294069804.34.0.860239284714.issue10817@psf.upfronthosting.co.za>
Message-ID: <1320086792.46.0.0506257824372.issue10817@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

This is fixed in all codelines. Thanks for your contribution, Jyrki Pulliainen.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10817>
_______________________________________

From report at bugs.python.org  Mon Oct 31 19:48:42 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Mon, 31 Oct 2011 18:48:42 +0000
Subject: [issue10817] urllib.request.urlretrieve never raises
	ContentTooShortError if no reporthook
In-Reply-To: <1294069804.34.0.860239284714.issue10817@psf.upfronthosting.co.za>
Message-ID: <1320086922.28.0.239640068522.issue10817@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

Cheers, thank you for commiting!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10817>
_______________________________________

From report at bugs.python.org  Mon Oct 31 19:53:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 31 Oct 2011 18:53:41 +0000
Subject: [issue13295] Fix HTML produced by http.server
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1320087221.22.0.21294615916.issue13295@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached patch updates the pages to pass the validation, use HTML 4.01 and specify the encoding of the page in the <meta> tag.

----------
stage: patch review -> commit review
versions:  -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23573/issue13295-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13295>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:00:00 2011
From: report at bugs.python.org (Richard Saunders)
Date: Mon, 31 Oct 2011 19:00:00 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing
	comparisons
In-Reply-To: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>
Message-ID: <1320087600.87.0.174575557963.issue13279@psf.upfronthosting.co.za>


Richard Saunders <RichIsMyName at mac.com> added the comment:

Here's a test demonstrating the memcmp optimization effect:
-----------------------------------------------------------
more ~/PickTest5/Python/string_test3.py

a = []
b = []
c = []
d = []
for x in range(0,1000) :
    a.append("the quick brown fox"+str(x))
    b.append("the wuick brown fox"+str(x))
    c.append("the quick brown fox"+str(x))
    d.append("the wuick brown fox"+str(x))

count = 0
for x in range(0,200000) :
    if a==c : count += 1
    if a==c : count += 2
    if a==d : count += 3
    if b==c : count += 5
    if b==d : count += 7
    if c==d : count += 11

print(count)



---------------------------------------------------------------------

# plain Python 3.3  no memcmp, no UCS specialization 

% time ./python ~/PickTest5/Python/string_test3.py 
2000000
28.918u 0.014s 0:29.02 99.6%	0+0k 0+0io 0pf+0w


% setenv CFLAGS -fno-builtin-memcmp # (reconfigure and remake)


% time ./python ~/PickTest5/Python/string_test3.py
2000000
29.783u 0.017s 0:29.88 99.6%	0+0k 0+0io 0pf+0w


-------------------------------------------------------------------------
# Python 3.3 with memcmp optimizations and UCS2/4 specialization (no CFLAGS)

% time ./python ~/PickTest5/Python/string_test3.py
2000000
37.126u 0.046s 0:37.35 99.4%	0+0k 0+0io 0pf+0w


% setenv CFLAGS -fno-builtin-memcmp # (reconfigure and remake)

% time ./python ~/PickTest5/Python/string_test3.py
2000000
18.621u 0.013s 0:18.69 99.6%	0+0k 0+0io 0pf+0w



---------------------------------------------------------------------

Note we only really see the effect if we make sure that gcc
isn't emitting its "special" memcmp: that's why the -fno-builtin-memcmp
is SO important on gcc builds!
See http://www.picklingtools.com/study.pdf

I am currently working with Bob Arendt (a colleague who works
frequently with Fedora) to try to put the
-fno-builtin-memcmp in the .spec file for their Python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:00:44 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 31 Oct 2011 19:00:44 +0000
Subject: [issue13281] Make robotparser.RobotFileParser ignore blank lines
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1320087644.42.0.438011120206.issue13281@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The robotparser is currently doing exactly what it is documented as doing. 20.9. urllib.robotparser ? Parser for robots.txt
says "For more details on the structure of robots.txt files, see http://www.robotstxt.org/orig.html." (Since there are no previous details, 'more' should be deleted.) That page, in turn, says

'''The file consists of one or more records separated by one or more blank lines (terminated by CR,CR/NL, or NL). Each record contains lines of the form "<field>:<optionalspace><value><optionalspace>".'''

The formal grammar says the same thing. The page goes on with

'''Comments ... are discarded completely, and therefore do not indicate a record boundary.'''

followed by

'''The record starts with one or more User-agent lines, followed by one or more Disallow lines, as detailed below. Unrecognised headers are ignored.'''

Not allowing blank lines within records is obviously, to me, intentional and not an accidental oversight. It aids error detection.  Consider:

User-agent: A ...
Disallow: ...

User-aget: B ...
Disallow: ...

Currently, the blank line signals a new record, the misspelled 'User-aget' line is ignored, and the new record, starting with 'Disallow' instead of 'User-agent' is correctly seen as an error and ignored. The same would be true if the User-agent line were accidentally omitted. When humans edit files, perhaps from someone else's notes, such things happen.

With this change, the second disallow line will be incorrectly attributed to A. We can justify that on the hypothesis that intentional blank lines within record, in violation of the standard, are now more common than missing or misspelled User-Agent lines. Or we can decide that mis-attributing Disallow lines is a lesser sin than ignoring them. But the change is pretty plainly a feature change and not a bug fix. 

My current suggested doc change is to replace the sentence quoted at the top with
"Such files are parsed according to the rules given at http://www.robotstxt.org/orig.html , with the exception that blank lines are allowed within records.
Versionchanged 3.3: allow blank lines within records"

Side note: The example in the doc uses musi-cal.com. We need a replacement as it was closed last June, as noted in
http://www.wolfgangsvault.com/blog/index.php/2011/06/closing-mojam-com-and-musi-cal-com/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:03:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Oct 2011 19:03:37 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing
	comparisons
In-Reply-To: <1320087600.87.0.174575557963.issue13279@psf.upfronthosting.co.za>
Message-ID: <1320087558.3382.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I am currently working with Bob Arendt (a colleague who works
> frequently with Fedora) to try to put the
> -fno-builtin-memcmp in the .spec file for their Python

Wouldn't it be better to have it enabled by default in their gcc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:03:47 2011
From: report at bugs.python.org (Richard Saunders)
Date: Mon, 31 Oct 2011 19:03:47 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing
	comparisons
In-Reply-To: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>
Message-ID: <1320087827.64.0.948721139555.issue13279@psf.upfronthosting.co.za>


Richard Saunders <RichIsMyName at mac.com> added the comment:

Added branches for specializing for UCS2 and UCS4 types

----------
Added file: http://bugs.python.org/file23574/unicode_with_memcmp_and_ucs_specialization.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:23:18 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 31 Oct 2011 19:23:18 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1320088998.38.0.631250420861.issue12797@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is "an open file descriptor" correct in English? I'd have written "an opened file descriptor" instead (in 5 places).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:26:10 2011
From: report at bugs.python.org (Carl Meyer)
Date: Mon, 31 Oct 2011 19:26:10 +0000
Subject: [issue13304] test_site assumes that site.ENABLE_USER_SITE is True
In-Reply-To: <1320085868.02.0.130211137087.issue13304@psf.upfronthosting.co.za>
Message-ID: <1320089170.65.0.230380296036.issue13304@psf.upfronthosting.co.za>


Carl Meyer <carl at dirtcircle.com> added the comment:

Added a patch implementing my proposed fix.

----------
hgrepos: +87

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13304>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:27:15 2011
From: report at bugs.python.org (Carl Meyer)
Date: Mon, 31 Oct 2011 19:27:15 +0000
Subject: [issue13304] test_site assumes that site.ENABLE_USER_SITE is True
In-Reply-To: <1320085868.02.0.130211137087.issue13304@psf.upfronthosting.co.za>
Message-ID: <1320089235.96.0.106237158234.issue13304@psf.upfronthosting.co.za>


Changes by Carl Meyer <carl at dirtcircle.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23575/cea40c2d7323.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13304>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:32:06 2011
From: report at bugs.python.org (Carl Meyer)
Date: Mon, 31 Oct 2011 19:32:06 +0000
Subject: [issue13304] test_site assumes that site.ENABLE_USER_SITE is True
In-Reply-To: <1320085868.02.0.130211137087.issue13304@psf.upfronthosting.co.za>
Message-ID: <1320089526.49.0.35907113847.issue13304@psf.upfronthosting.co.za>


Changes by Carl Meyer <carl at dirtcircle.com>:


Removed file: http://bugs.python.org/file23575/cea40c2d7323.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13304>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:35:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 31 Oct 2011 19:35:33 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1320089733.67.0.728383740919.issue12797@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Is "an open file descriptor" correct in English? I'd have written "an
> opened file descriptor" instead (in 5 places).

"open" is correct.
For example, you say "the store is open", not "the store is opened": "open" is an adjective, whereas "opened" is the past participe.
See http://www.usingenglish.com/forum/ask-teacher/15771-open-opened-welcome-welcomed.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:40:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 31 Oct 2011 19:40:28 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1320088998.38.0.631250420861.issue12797@psf.upfronthosting.co.za>
Message-ID: <4EAEF987.7000802@udel.edu>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> I'd have written "an opened file descriptor" instead (in 5 places).

Yes, 'open' is an adjective as well as a verb, and the correct one in 
this context. Something that has been opened, such as a sealed jar or 
envelope, might have been re-closed, but it is no longer the same as 
never-opened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:44:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Oct 2011 19:44:37 +0000
Subject: [issue13299] namedtuple row factory for sqlite3
In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za>
Message-ID: <1320090277.86.0.558255641934.issue13299@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13299>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:48:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 31 Oct 2011 19:48:52 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <E1RKxqf-0000EG-13@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 740baff4f169 by Charles-Fran?ois Natali in branch 'default':
Issue #13303: Fix a race condition in the bytecode file creation.
http://hg.python.org/cpython/rev/740baff4f169

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Mon Oct 31 20:51:15 2011
From: report at bugs.python.org (Carl Meyer)
Date: Mon, 31 Oct 2011 19:51:15 +0000
Subject: [issue13304] test_site assumes that site.ENABLE_USER_SITE is True
In-Reply-To: <1320085868.02.0.130211137087.issue13304@psf.upfronthosting.co.za>
Message-ID: <1320090675.75.0.416724271214.issue13304@psf.upfronthosting.co.za>


Changes by Carl Meyer <carl at dirtcircle.com>:


Added file: http://bugs.python.org/file23576/d851c64c745a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13304>
_______________________________________

From report at bugs.python.org  Mon Oct 31 21:12:37 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 31 Oct 2011 20:12:37 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
Message-ID: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

See msg146725 on issue 13291.

on linux
>>> datetime(1,  2, 10, 11, 41, 23).strftime("%Y")
'1'

on osx
>>> datetime(1,  2, 10, 11, 41, 23).strftime("%Y")
'0001'


>>> datetime.strptime('0001', '%Y')
datetime.datetime(1, 1, 1, 0, 0)

>>> datetime.strptime('1', '%Y')
ValueError: time data '1' does not match format '%Y'

----------
components: Library (Lib)
messages: 146740
nosy: flox
priority: normal
severity: normal
stage: test needed
status: open
title: datetime.strftime("%Y") not consistent for years < 1000
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13305>
_______________________________________

From report at bugs.python.org  Mon Oct 31 21:44:41 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 31 Oct 2011 20:44:41 +0000
Subject: [issue13291] latent NameError in xmlrpc package
In-Reply-To: <1319928683.07.0.326015714252.issue13291@psf.upfronthosting.co.za>
Message-ID: <1320093881.04.0.143165062558.issue13291@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This last issue is in the datetime module. issue #13305

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13291>
_______________________________________

From report at bugs.python.org  Mon Oct 31 21:49:34 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 31 Oct 2011 20:49:34 +0000
Subject: [issue13279] Add memcmp into unicode_compare for
	optimizing	comparisons
In-Reply-To: <1320087600.87.0.174575557963.issue13279@psf.upfronthosting.co.za>
Message-ID: <4EAF09D5.90800@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Note we only really see the effect if we make sure that gcc
> isn't emitting its "special" memcmp: that's why the -fno-builtin-memcmp
> is SO important on gcc builds!

I'd rather infer the opposite: given how GCC generates code, this patch
is not worthwhile. Given that it actually slows down Python in the
default system configuration, I'm -1 on applying it. This is really not
a route we should take; it leads to maintenance pain.

----------
title: Add memcmp into unicode_compare for optimizing comparisons -> Add memcmp into unicode_compare for optimizing	comparisons

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Mon Oct 31 21:54:43 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 31 Oct 2011 20:54:43 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1320094483.43.0.38091854541.issue13305@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

FWIW, issue #1777412 added support for years < 1000 to Python 3.3 strftime.

----------
nosy: +belopolsky, haypo
stage: test needed -> needs patch
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13305>
_______________________________________

From report at bugs.python.org  Mon Oct 31 21:56:52 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Oct 2011 20:56:52 +0000
Subject: [issue13279] Add memcmp into unicode_compare for
	optimizing	comparisons
In-Reply-To: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>
Message-ID: <1320094612.41.0.266626376212.issue13279@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Martin.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Mon Oct 31 21:59:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 31 Oct 2011 20:59:01 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1320094741.13.0.29447585459.issue13305@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13305>
_______________________________________

From report at bugs.python.org  Mon Oct 31 22:05:00 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Oct 2011 21:05:00 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1320095100.3.0.775693759892.issue13305@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I am not sure this can be fixed without distributing our own implementation of strftime.  See issue 3173.

----------
dependencies: +external strftime for Python?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13305>
_______________________________________

From report at bugs.python.org  Mon Oct 31 23:07:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Oct 2011 22:07:00 +0000
Subject: [issue13306] Add diagnostic tools to importlib?
Message-ID: <1320098820.25.0.925823454462.issue13306@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

In discussing the module aliasing PEP on python-ideas, it occurred to me that we could potentially add some useful "sanity check" utilities to an "importlib.diagnostics" subpackage. For example:

- scan sys.path looking for entries that are inside packages
- scan sys.modules looking for entries with duplicate __file__ attributes
- scan for shadowed modules (i.e. like find module, but don't stop when we get a hit, and report *all* modules found)

Thoughts?

----------
messages: 146746
nosy: brett.cannon, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add diagnostic tools to importlib?
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13306>
_______________________________________

From report at bugs.python.org  Mon Oct 31 23:30:03 2011
From: report at bugs.python.org (Richard Saunders)
Date: Mon, 31 Oct 2011 22:30:03 +0000
Subject: [issue13279] Add memcmp into unicode_compare for
	optimizing	comparisons
In-Reply-To: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>
Message-ID: <1320100203.67.0.617615809843.issue13279@psf.upfronthosting.co.za>


Richard Saunders <RichIsMyName at mac.com> added the comment:

Some more information:

Bob Arendt and I have been playing with the Fedora Core .spec file
for python on Fedora Core 15: 
the compile options we found seem to automatically (as we did non invoke
this option) invoke '-fno-builtin-memcmp' somehow?  We disassembled the
Python binary we built for the machine ourselves (via the spec file)
code and saw, yes, it was calling memcmp on the system, even though we
didn't bypass it explicitly.

Our conjecture is that the -m32 or -mtune=atom automatically turns the builtin memcmp off, but we're not sure (we're still playing with it). 

However, perhaps Fedora builds on a more generic machine: that generic build keeps the 'rep cmbsb'?

Frustrating.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________

From report at bugs.python.org  Mon Oct 31 23:38:37 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 31 Oct 2011 22:38:37 +0000
Subject: [issue13307] test_bdist_rpm: INSTALLED_FILES does not use __pycache__
Message-ID: <1320100717.66.0.765161985418.issue13307@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The failures seen on the Fedora buildbot are caused by the fact that
INSTALLED_FILES does not use __pycache__:

[stefan at fedora-14-i386 foo]$ cat build/bdist.linux-i686/rpm/BUILD/foo-0.1/INSTALLED_FILES
/usr/local/lib/python3.3/site-packages/foo.py
/usr/local/lib/python3.3/site-packages/foo.pyc
/usr/local/lib/python3.3/site-packages/foo.pyo
/usr/local/lib/python3.3/site-packages/foo-0.1-py3.3.egg-info



I'm not familiar with rpm, so I've no clue at which point this
file is generated.

----------
components: Tests
messages: 146748
nosy: eric.araujo, skrah
priority: normal
severity: normal
status: open
title: test_bdist_rpm: INSTALLED_FILES does not use __pycache__
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13307>
_______________________________________

From report at bugs.python.org  Mon Oct 31 23:41:55 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 31 Oct 2011 22:41:55 +0000
Subject: [issue5875] test_distutils failing on OpenSUSE 10.3, Py3k
In-Reply-To: <1240991372.08.0.469372196929.issue5875@psf.upfronthosting.co.za>
Message-ID: <1320100915.19.0.027567473563.issue5875@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

For the buildbot failures see #13307. I think that it's indeed a
different issue, since AFAIK __pycache__ didn't exist when this one
was opened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5875>
_______________________________________

From report at bugs.python.org  Mon Oct 31 23:59:35 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 31 Oct 2011 22:59:35 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1320101975.87.0.905530497538.issue13305@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

There's many discrepancies between OS X and Linux about time formatting...

OS X
>>> from datetime import datetime
>>> datetime(1900, 1, 1).strftime("%6Y")
'6Y'

Linux
>>> from datetime import datetime
>>> datetime(1900, 1, 1).strftime("%6Y")
'001900'

BTW, these discrepancies are already mentioned:
http://docs.python.org/dev/library/datetime.html#strftime-strptime-behavior

?The full set of format codes supported varies across platforms, because Python calls the platform C library?s strftime() function, and platform variations are common.?

We should had an asterisk to the "%Y" saying that the padding is not consistent across platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13305>
_______________________________________