From report at bugs.python.org  Sun Jul  1 00:03:04 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 30 Jun 2012 22:03:04 +0000
Subject: [issue10650] decimal.py: quantize(): excess digits with watchexp=0
In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za>
Message-ID: <1341093784.58.0.474037103875.issue10650@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'd be happy to see watchexp deprecated.  It feels like a leftover implementation artefact;  its behaviour isn't properly defined anywhere, and as far as I can tell it has only a single testcase.

----------

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

From report at bugs.python.org  Sun Jul  1 00:40:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jun 2012 22:40:48 +0000
Subject: [issue14330] don't use host python,
	use host search paths for host compiler
In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za>
Message-ID: <E1Sl6LO-0001Hz-UD@dinsdale.python.org>


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

New changeset 7955d769fdf5 by doko in branch 'default':
- Issue #14330: Don't derive the include and library search dirs
http://hg.python.org/cpython/rev/7955d769fdf5

----------

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

From report at bugs.python.org  Sun Jul  1 00:40:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jun 2012 22:40:48 +0000
Subject: [issue15194] libffi-3.0.11 update
In-Reply-To: <1340723218.62.0.173444932066.issue15194@psf.upfronthosting.co.za>
Message-ID: <E1Sl6LO-0001Hz-U1@dinsdale.python.org>


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

New changeset 989efaab9525 by doko in branch 'default':
- Issue #15194: check in the missing m4/ax_check_compile_flag.m4 file.
http://hg.python.org/cpython/rev/989efaab9525

----------

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

From report at bugs.python.org  Sun Jul  1 01:01:53 2012
From: report at bugs.python.org (Daniel Lenski)
Date: Sat, 30 Jun 2012 23:01:53 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on
	Windows
In-Reply-To: <1341045988.98.0.559965486608.issue14243@psf.upfronthosting.co.za>
Message-ID: <CAOw_LSGBiSkO2aDHbwoe6AGBUWxOcaPe9FkrCJx23Rtm2gG3Yw@mail.gmail.com>


Daniel Lenski <dlenski at gmail.com> added the comment:

Davide, the @contextlib.contextmanager decorator effectively wraps the
yield statement in the necessary glue so that everything prior to the yield
statement occurs in the __enter__() method of the contextmanager, while
everything subsequent occurs in the __exit__() method.

On Sat, Jun 30, 2012 at 1:46 AM, Davide Rizzo <report at bugs.python.org>wrote:

>
> Davide Rizzo <sorcio at gmail.com> added the comment:
>
> Daniel, Nick, shouldn't the context manager yield f within a with block?
>
> ----------
> nosy: +davide.rizzo
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue14243>
> _______________________________________
>

----------
title: tempfile.NamedTemporaryFile not particularly useful on	Windows -> tempfile.NamedTemporaryFile not particularly useful on Windows

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

From report at bugs.python.org  Sun Jul  1 01:08:10 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jun 2012 23:08:10 +0000
Subject: [issue15034] Devguide should document best practices for stdlib
	exceptions
In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>
Message-ID: <1341097690.48.0.332302304949.issue15034@psf.upfronthosting.co.za>


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

I agree with Raymond that this, especially super() is not tutorial material. I agree with David that we need something somewhere else. Just today a commit was pushed about IOException subclasses causing problems because they have an __init__ but don't call super(). (Something like that.) I had no idea about this issue.

The stdlib has things like "class ModException(Exception): pass". Is that okay because it does *not* have __init__ override?

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

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

From report at bugs.python.org  Sun Jul  1 01:10:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jun 2012 23:10:35 +0000
Subject: [issue15194] libffi-3.0.11 update
In-Reply-To: <1340723218.62.0.173444932066.issue15194@psf.upfronthosting.co.za>
Message-ID: <E1Sl6oA-0002nA-Vl@dinsdale.python.org>


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

New changeset 6fe974b8056c by doko in branch 'default':
- Issue #15194: check in the missing m4/ax_append_flag.m4 file.
http://hg.python.org/cpython/rev/6fe974b8056c

----------

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

From report at bugs.python.org  Sun Jul  1 02:01:48 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Jul 2012 00:01:48 +0000
Subject: [issue1207613] Bottom Scroll Bar
Message-ID: <1341100908.83.0.29398263506.issue1207613@psf.upfronthosting.co.za>


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

#15141, which I will close as a duplicate, makes the same request (for the edit window). Roger Serwy notes that his extension package
http://idlex.sourceforge.net/extensions.html
has horizontal.py, which does what is requested. He is willing for that (or other) extension(s) to be bundled with idle for default or optional activation. I presume that is done in some .cfg file. I re-opened for that purpose.

(Note: it would seem nice to be able to get a list of extensions available and those enabled from the menu. Or is there a reason not too?)

Some arguments for h. scroll:
1. The shell window is a print output as well as code input window. Output should not necessarily be limited to 80 chars. With variable pitch font, that does not even make much sense.
2. Edit windows are not limited to python code. Else they would *always* syntax hilight. Or Pycode might be embedded in other formats. If #6858 were implemented, h scroll would be more useful.
3. Not everyone agrees with the 80 char limits.
4. People sometimes edit a file written by someone else.

Counter-arguments:
1. A full screen window allows about 200 chars or more, which is enough for any code entry and most print output and most 'files written by someone else'.
2. For exceptions, put cursor on long line and use => arrow key.

----------
nosy: +serwy, terry.reedy
resolution: rejected -> 
status: closed -> open
versions: +Python 3.4

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

From report at bugs.python.org  Sun Jul  1 02:02:49 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Jul 2012 00:02:49 +0000
Subject: [issue15141] IDLE horizontal scroll bar missing (Win-XPsp3)
In-Reply-To: <1340390215.85.0.455282030507.issue15141@psf.upfronthosting.co.za>
Message-ID: <1341100969.02.0.134178761115.issue15141@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Bottom Scroll Bar

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

From report at bugs.python.org  Sun Jul  1 02:21:26 2012
From: report at bugs.python.org (Benjamin S Wolf)
Date: Sun, 01 Jul 2012 00:21:26 +0000
Subject: [issue15230] runpy.run_path broken: Breaks scoping;
	pollutes sys.modules; doesn't set __package__
Message-ID: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>


New submission from Benjamin S Wolf <jokeserver at gmail.com>:

(Python 3.2.3)

1. After discarding the module run_path used to run the code in, all references to variables from local scopes (even if they are references to global variables) are bound to None, preventing any code in functions from running properly.

/tmp/a.py --------------------------------------
FOO = 'bar'

def f():
    print(FOO)

f()
------------------------------------------------
/tmp/b.py --------------------------------------
# Hack needed for:
#  python3 /tmp/b.py,
#  python3 -m /tmp/b
#  runpy.run_path('/tmp/b.py')
from os.path import dirname
__path__ = [dirname(__file__)]
del dirname

# Hack needed for:
#  python3 -m /tmp/b
if __name__ == '__main__' and not __package__:
    __package__ = '__main__'

from . import a

def g():
    print(a.FOO)

g()
------------------------------------------------

~$ python3
>>> import runpy
>>> d = runpy.run_module('/tmp/a')
bar
>>> d2 = runpy.run_path('/tmp/a.py')
bar
>>> d['f']
<function f at 0xb7451b6c>
>>> d['FOO']
'bar'
>>> d['f']()
bar
>>> d2['f']
<function f at 0xb7451bac>
>>> d2['FOO']
'bar'
>>> d2['f']()
None
>>> d3 = runpy.run_path('/tmp/b.py')
bar
bar
>>> d3['g']
<function g at 0xb746e26c>
>>> d3['a']
<module '<run_path>.a' from '/tmp/a.py'>
>>> d3['g']()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/b.py", line 15, in g
    print(a.FOO)
AttributeError: 'NoneType' object has no attribute 'FOO'

Notice that run_module gets this right, as d['f']() prints 'bar' but d2['f']() and d3['g']() do not.


2. run_path pollutes the module namespace when running a module that uses relative imports. This prevents any code that imports the same module in the same manner from running.

Continuing from #1 without having closed the interpreter:
>>> d4 = runpy.run_path('/tmp/b.py')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/runpy.py", line 250, in run_path
    return _run_module_code(code, init_globals, run_name, path_name)
  File "/usr/lib/python3.2/runpy.py", line 83, in _run_module_code
    mod_name, mod_fname, mod_loader, pkg_name)
  File "/usr/lib/python3.2/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/tmp/b.py", line 12, in <module>
    from . import a
ImportError: cannot import name a
>>> '<run_path>' in sys.modules
False
>>> '<run_path>.a' in sys.modules
True
>>> d3['a'].f()
bar
>>> del sys.modules['<run_path>.a']
>>> d4 = runpy.run_path('/tmp/b.py')
bar
bar
>>>

run_module, on the other hand, also alters sys.modules, but this does not prevent the module from being run, only from the secondary module from being re-imported:
[Create an empty file /tmp/__init__.py]
>>> sys.path = ['/'] + sys.path
>>> d5 = runpy.run_module('tmp.b')
bar
bar
>>> d6 = runpy.run_module('tmp.b')
bar
>>> d7 = runpy.run_module('tmp.b')
bar
>>> 'tmp' in sys.modules
True
>>> 'tmp.b' in sys.modules
False
>>> 'tmp.a' in sys.modules
True

[This was the only way I could get run_module to run /tmp/b.py, regardless of the presence or lack of the path and __package__ hacks at the top of the file, or any other changes I've experimented with. runpy.run_module('/tmp/b'), runpy.run_module('b') [with '/tmp' in sys.path] would generally result in:
  ValueError: Attempted relative import in non-package
and setting run_name='__main__' alongside any of the other changes would result in:
  ImportError: cannot import name a

python3 /tmp/b.py and python3 -m /tmp/b run fine.]


3. And finally, an examination of the run_path code shows that it doesn't, as the docs indicate, set __package__ to be run_name.rpartition('.')[0], but either the empty string or None: http://hg.python.org/cpython/file/3.2/Lib/runpy.py#l269

----------
components: Library (Lib)
messages: 164437
nosy: Benjamin.S.Wolf
priority: normal
severity: normal
status: open
title: runpy.run_path broken: Breaks scoping; pollutes sys.modules; doesn't set __package__
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Jul  1 02:34:29 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Jul 2012 00:34:29 +0000
Subject: [issue15224] Range: Additional Methods (min/max/__and__)
In-Reply-To: <1340987823.51.0.113696334515.issue15224@psf.upfronthosting.co.za>
Message-ID: <1341102869.82.0.313202970896.issue15224@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, I concur with rejecting this for the reasons that Mark mentioned.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sun Jul  1 02:40:49 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Jul 2012 00:40:49 +0000
Subject: [issue10650] decimal.py: quantize(): excess digits with watchexp=0
In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za>
Message-ID: <1341103249.02.0.963827122512.issue10650@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Does anyone know why watchexp was put there in the first place?

http://speleotrove.com/decimal/daops.html#refquant

If no motivation for this can be found, I agree with Mark that it should be deprecated and removed.

----------

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

From report at bugs.python.org  Sun Jul  1 02:45:04 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Jul 2012 00:45:04 +0000
Subject: [issue15158] Add support for multi-character delimiters in csv
In-Reply-To: <1340509645.86.0.375714044709.issue15158@psf.upfronthosting.co.za>
Message-ID: <1341103504.25.0.473891042739.issue15158@psf.upfronthosting.co.za>


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

Did you read "Unfortunately, delimiter is represented by a character in C." in one of the answers? If so, this should be rejected. For the posted problem, I added the following.

>>> list(s[1:-1] for s in '"1234"||"abcd"||"a1s1"'.split('||'))
['1234', 'abcd', 'a1s1']

re.split is intended for general splitting tasks. The SO had other posted solutions that also do the job. So I do not see the need.

Using commas both within quoted fields and between fields is semi-sensible, or at least widely done. Anyway, csv was designed for that and then generalized. I do not see the need to cater to something as foolish and rare as using a multichar delimiter that is also within fields.

I suggest you post enhancement ideas on python-ideas first, as it is a better place for discussion and reaches more people.

----------
nosy: +terry.reedy
stage:  -> test needed
versions:  -Python 3.3

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

From report at bugs.python.org  Sun Jul  1 03:03:36 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Jul 2012 01:03:36 +0000
Subject: [issue15178] Doctest should handle situations when test files are not
	readable
In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za>
Message-ID: <1341104616.87.0.384758100425.issue15178@psf.upfronthosting.co.za>


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

Failure modes tend to get less attention that successful behavior. If I wrote a program that used doctest/unittest to test multiple files, I should like it to run an many as possible. If a filename is bad, print name as usual, say 'aborted', and '0/0 tests' run. Then at the end tell me via return value or exception about problems. In any case, having error behavior documented and consistent between modules would be good.  I am not sure how much of this would be a bugfix versus enhancement.

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

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

From report at bugs.python.org  Sun Jul  1 03:12:38 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Jul 2012 01:12:38 +0000
Subject: [issue15180] Cryptic traceback from os.path.join when mixing str &
	bytes
In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za>
Message-ID: <1341105158.02.0.53513042202.issue15180@psf.upfronthosting.co.za>


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

This strikes me as a bugfix that does not get backported because code might depend on the bug. If the policy for exception messages, such as it is, documented somewhere?

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

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

From report at bugs.python.org  Sun Jul  1 03:15:32 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Jul 2012 01:15:32 +0000
Subject: [issue15189] tkinter.messagebox does not use the application's icon
In-Reply-To: <1340695188.66.0.13086714969.issue15189@psf.upfronthosting.co.za>
Message-ID: <1341105332.2.0.907308689159.issue15189@psf.upfronthosting.co.za>


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

It is not clear to me what change your are proposing.

----------
nosy: +gpolo, terry.reedy
type:  -> enhancement
versions: +Python 3.4 -Python 3.2

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

From report at bugs.python.org  Sun Jul  1 03:22:22 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Jul 2012 01:22:22 +0000
Subject: [issue15191] tkinter convenience dialogs don't use themed widgets
In-Reply-To: <1340700094.05.0.57171486761.issue15191@psf.upfronthosting.co.za>
Message-ID: <1341105742.49.0.459633446326.issue15191@psf.upfronthosting.co.za>


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

It has been agreed that IDLE could assume tk8.5 (or possibly 8.4 + tile extension) and use themed widgets (though it is not yet) and not run otherwise. Further discussion would be needed to do the same for tkinter, but maybe by 3.4 that might be reasonable.

----------
nosy: +terry.reedy
type:  -> enhancement
versions: +Python 3.4 -Python 3.2

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

From report at bugs.python.org  Sun Jul  1 04:34:33 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 01 Jul 2012 02:34:33 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
Message-ID: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I had an issue whereby my reST long_description wasn't getting rendered as HTML when uploaded to PyPI.  Following the instructions here did not work as-is:

http://docs.python.org/dev/distutils/uploading.html#pypi-package-display

It seems that PyPI passes --no-raw (no HTML allowed) to rst2html.py, in which case the guidance would be better updated to read--

$ python setup.py --long-description | rst2html.py --no-raw > output.html

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164445
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: update PyPI upload doc to say --no-raw passed to rst2html.py
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  1 05:18:21 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 01 Jul 2012 03:18:21 +0000
Subject: [issue1207613] Bottom Scroll Bar
In-Reply-To: <1341100908.83.0.29398263506.issue1207613@psf.upfronthosting.co.za>
Message-ID: <4FEFC178.2020807@gmail.com>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I wrote Horizontal.py as an extension in order to avoid forking IDLE. It 
should be simple to incorporate a toggling horizontal scroll bar within 
the EditorWindow class itself.
> (Note: it would seem nice to be able to get a list of extensions available and those enabled from the menu. Or is there a reason not too?)

IdleX provides a dialog for enabling and disabling extensions.

The shell window has wrapping enabled on its text widget. A horizontal 
bar is not needed there.
> 2. Edit windows are not limited to python code. Else they would *always* syntax hilight. Or Pycode might be embedded in other formats. If #6858 were implemented, h scroll would be more useful.
True. The Editor window does not wrap, which is why the horizontal bar 
is needed there.
> 3. Not everyone agrees with the 80 char limits.
The limit does make printing code simpler, however.  But that's a 
separate discussion.
> 4. People sometimes edit a file written by someone else.
Yes, and often times it is one or two lines in the file that extend 
beyond the right border of the editor.
> Counter-arguments:
> 1. A full screen window allows about 200 chars or more, which is enough for any code entry and most print output and most 'files written by someone else'.
I shouldn't have to resize the editor to see its contents.
> 2. For exceptions, put cursor on long line and use =>  arrow key.
>
> ----------
> nosy: +serwy, terry.reedy
> resolution: rejected ->
> status: closed ->  open
> versions: +Python 3.4
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue1207613>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sun Jul  1 05:21:33 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 01 Jul 2012 03:21:33 +0000
Subject: [issue15178] Doctest should handle situations when test files are not
	readable
In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za>
Message-ID: <1341112893.47.0.0838634149346.issue15178@psf.upfronthosting.co.za>


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

The  problem with running all the files as things stand is that the errors get lost in the other output.  Changing that would definitely be an enhancement.

----------

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

From report at bugs.python.org  Sun Jul  1 05:53:34 2012
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sun, 01 Jul 2012 03:53:34 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	packaging
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1341114814.02.0.378244478745.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

> distutils2 is the place to add such new features. 

you're not getting it.  you've just told both this
mingw32 project and also the new effort by ray that
they can go fuck themselves, because their efforts
are a total waste of time (as far as python 2 is
concerned).

why? because without patches to python 2 distutils, you're condemning
their work to total irrelevance.  why? because nobody in their
right mind is going to do what you suggest - "go educate people"
about using distutils2.  that's tens of thousands of package
maintainers, and you're expecting *two* people to do that job - 
you must be off your head if you think that's even remotely
realistic!  i can't quite understand why you would even make such
a recommendation, because it's so clearly unworkable and unrealistic.

now, if python2 was in any way going to die, be totally
irrelevant or otherwise be superceded at any time in
the next ten years i would in no way be so pissed at this
freeze, and would in no way bother to comment on this.
i don't like doing this sort of thing: it makes me look
like i'm some sort of fucking idiot - but that's tough luck
on me.  someone has to tell it straight, and truthfully say
the things that everyone else doesn't have the balls to say.

what has me particularly pissed off is that the freeze happened
years *AFTER* roumen created this initial patch.

also what has me particularly pissed off is that the freeze
happened because *other people* - not roumen, and not ray -
didn't do their job, either in checking that their modifications
to distutils would have an impact on any other ports, but more
than that, neither did anyone else in the python team.

why should ray and roumen's work be made insultingly irrelevant,
just because of mistakes made by *other people*?


by complete contrast, i absolutely agree with you 100% that in
NO WAY should any modifications to distutils in python3 sources
be EVER permitted.  forcing people to use distutils2
for *new* packages, as well as packages being transitioned to python3,
and documenting that fact (and the required procedure to be followed)
prominently on the python web site, is perfectly reasonable.

the reason why it is perfectly reasonable is because the developer
who is writing the new package (or transitioning the old one) is
*actively* taking the steps - THEY are taking steps - THEY are the
ones ACTIVELY doing the work.  intiated BY THEM.  people PLURAL.
tens of THOUSANDS of people.  and those people will read documentation,
and will ask questions on the mailing list, and will generally follow
the advice and guidance of the community.

contrast this with a completely unrealistic expectation that TWO
people must DEMAND of those exact same tens of thousands of python2
developers that "ohhh, you muuust use distutils2" and you can perhaps
appreciate why i am not exactly impressed.

of course, if the Python Software Foundation is offering to fund
these two developers with a campaign to educate the entire world of
python2 package maintainers with the demand that they all convert to
distutils2, and is willing to support them by creating a write-up
and a series of articles and other supporting documentation on the
python.org web site, then that is an entirely different matter.

----------

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

From report at bugs.python.org  Sun Jul  1 06:16:01 2012
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sun, 01 Jul 2012 04:16:01 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	packaging
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1341116161.97.0.641410078454.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

> The feature freeze applies to all branches.  Even when 3.4 starts, the 
> same rule that has been repeatedly explained for two years will apply: 
> no new features in distutils.  Again, neither Tarek nor I are happy
> about that, but it was the decision taken by python-dev due to the big 
> number of setup.py scripts depending on undocumented behavior, bugs and 
> quirks.

then you use monkeypatching.  split the new functionality into
a separate module - ..../distutils/mingw.py - that is called by
a clear ONE LINE modification in distutils.py that CLEARLY cannot
have IN ANY WAY not one SINGLE effect on ANY OTHER python port.

that line would be something like:

    if sys.compiler == 'mingw32': import distutils.mingw

within that distutils.mingw it would monkey-patch distutils to
add itself into the distutils code.

the same technique could be used by ray to monkey-patch the
cygwin compiler by doing this:

distutils/specialportmaintainedbyray.py:

distutils.cygwincompiler.RE_VERSION = re.compile(b'[\D\s]*(\d+\.\d+(\.\d+)*)[\D\s]*$')

of course, for this to work, support for the ports are required
(identification of the ports) down at the sys.py and os.py level.
unless you expect these port maintainers to put in special 
monkeypatching into the c-code itself (which would of course be 
conditionally compiled and would in no way affect ANY other port of
python).

this would be perfectly reasonable.  the impact on other ports would
be zero.  consideration of the one line patch would take a few
minutes.

... and for those packages that depend on undocumented behaviour?
in the unlikely event that they ever get compiled for mingw32 or
ray's port, well, the person who compiled such a package would 
encounter an error, and would wonder why it was broken, and then
would get onto a mailing list and go "i have a problem, can anyone
help me".

chances are that the majority of packages would however compile
cleanly.

there's always a way.

----------

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

From report at bugs.python.org  Sun Jul  1 07:02:25 2012
From: report at bugs.python.org (Chris Pickett)
Date: Sun, 01 Jul 2012 05:02:25 +0000
Subject: [issue15232] maildir parsing can split up messages with 'From ' at
	the start of a line
Message-ID: <1341118945.33.0.829442271947.issue15232@psf.upfronthosting.co.za>


New submission from Chris Pickett <cpicke at gmail.com>:

tar xvfz maildir_bug.tar.gz
cd maildir_bug
./bug.sh

The attachment contains a maildir with a single message.  This message has two body lines beginning with 'From '.  When converted to mbox using the maildir2mbox.py, only the second line gets a '>' at the beginning.  Thunderbird subsequently splits the message in two.  I think the fix is to put a '>' in front of each 'From ' line and not just the second one.  However, when I did that, Thunderbird displayed the '>', so either it is not the right fix, or Thunderbird has a bug.

I am using Python 2.7.1.  I searched the bug tracker and didn't see this issue, so decided to file even though I don't have the latest version.

Chris

----------
files: maildir_bug.tar.gz
messages: 164450
nosy: Chris.Pickett
priority: normal
severity: normal
status: open
title: maildir parsing can split up messages with 'From ' at the start of a line
Added file: http://bugs.python.org/file26221/maildir_bug.tar.gz

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

From report at bugs.python.org  Sun Jul  1 07:38:34 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 01 Jul 2012 05:38:34 +0000
Subject: [issue15232] maildir parsing can split up messages with 'From ' at
	the start of a line
In-Reply-To: <1341118945.33.0.829442271947.issue15232@psf.upfronthosting.co.za>
Message-ID: <1341121114.91.0.967749415257.issue15232@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +email
nosy: +barry, r.david.murray

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

From report at bugs.python.org  Sun Jul  1 09:04:53 2012
From: report at bugs.python.org (Ray Donnelly)
Date: Sun, 01 Jul 2012 07:04:53 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	packaging
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1341126293.55.0.131234722217.issue3871@psf.upfronthosting.co.za>


Ray Donnelly <mingw.android at gmail.com> added the comment:

For me, it's all about being able to build useful software. I like Python a lot, but my goal is and has always been cross compilation of gdb with Python support. To that end, if I have to maintain some out of tree patches for 2.7.3 then so be it. For 3.x things are looking better and I'm hopeful that we'll get everything merged at some point.

For anyone who's interested in my almost-final set of patches against the released tarballs for both 2.7.3 and 3.3.0b1 they're at:

http://mingw-and-ndk.googlecode.com/files/python-273-and-330b1-patches-WIP.7z

AFAIK, the only real change I'll be making is to the build script.

Once Matthias has finished merging Roumen's cross compilation work to 3, I'll rebase my 3.3.0b1 patches against that and open an issue for each patch. If mingw cross touches too much of distutils for people's liking then hopefully we can get mac osx cross merged and that'll at least mean that the infrastructure is cross-compilation friendly.

----------

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

From report at bugs.python.org  Sun Jul  1 09:11:43 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 01 Jul 2012 07:11:43 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341126703.13.0.980257763601.issue15202@psf.upfronthosting.co.za>


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

storchaka: I can (finally!) spend some time reviewing patches today.  Which ones do I look at?  I'm guessing just the last two, "followlinks-to-follow_symlinks-2.patch" and "symlinks-to-follow_symlinks-2.patch".  But I wanted to confirm before I got knee-deep in it.

----------

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

From report at bugs.python.org  Sun Jul  1 09:28:18 2012
From: report at bugs.python.org (Ray Donnelly)
Date: Sun, 01 Jul 2012 07:28:18 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	packaging
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1341127698.38.0.943626855719.issue3871@psf.upfronthosting.co.za>


Ray Donnelly <mingw.android at gmail.com> added the comment:

I'm not personally interested in Cygwin (it's too slow for my liking) and I've spent a lot of time patching and building software to avoid forcing people to use it (no offence meant to Cygwin people, I can see the value of it, but IMHO native is always best) .

All of my patches target mingw-w64 (and Mac OS X cross); I'll do my best to make sure that the Cygwin port still works though (and also mingw32).

----------

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

From report at bugs.python.org  Sun Jul  1 09:58:41 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 01 Jul 2012 07:58:41 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
Message-ID: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Currently, the atexit docs state

"The order in which the functions are called is not defined" in the introduction and

"all functions registered are called in last in, first out order" in the docs of the atexit() function.

While the latter is correct, I don't think we should guarantee that behaviour by documenting it.  Suggestions?

----------
assignee: docs at python
components: Documentation
messages: 164454
nosy: docs at python, georg.brandl, loewis, pitrou
priority: normal
severity: normal
status: open
title: atexit: guarantee order of execution of registered functions?
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul  1 10:01:35 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 01 Jul 2012 08:01:35 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341129695.38.0.75694506158.issue15231@psf.upfronthosting.co.za>


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

There are more checks applied in PyPI than just the refusal to incorporate raw html. I doubt it is possible to perform the exact same check with the rst2html command line.

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

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

From report at bugs.python.org  Sun Jul  1 10:16:10 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 01 Jul 2012 08:16:10 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341130570.16.0.299883559544.issue15110@psf.upfronthosting.co.za>


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

Setting to blocker for b2.

----------
priority: critical -> release blocker

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

From report at bugs.python.org  Sun Jul  1 10:16:29 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 01 Jul 2012 08:16:29 +0000
Subject: [issue15198] multiprocessing Pipe send of non-picklable objects
	doesn't raise error
In-Reply-To: <1340767549.24.0.475642908305.issue15198@psf.upfronthosting.co.za>
Message-ID: <1341130589.8.0.829611358454.issue15198@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Then I doubt this is a bug in Python.

If your class does not override __reduce__, __reduce_ex__ or __getstate__/__setstate__, then it is probably one of the attributes of your instance which is causing the problem.  You could try to find out which one by trying

    cPickle.loads(cPickle.dumps(attribute, -1))

for each attribute of an instance of your class to see if it raises an error.

----------

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

From report at bugs.python.org  Sun Jul  1 10:20:49 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Jul 2012 08:20:49 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341130849.14.0.299738096552.issue15233@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I believe it should be guaranteed behavior and that code may reasonably want to have a predictable sequence of unwinding behaviors.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sun Jul  1 10:26:52 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 01 Jul 2012 08:26:52 +0000
Subject: [issue15198] multiprocessing Pipe send of non-picklable objects
	doesn't raise error
In-Reply-To: <1341130589.8.0.829611358454.issue15198@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOQKFfdr1JvOnR0YpVjt9f5TA5TNhP7Mvu+qgn1z3Yi6wQ@mail.gmail.com>


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

On Sun, Jul 1, 2012 at 1:16 AM, Richard Oudkerk <report at bugs.python.org> wrote:
> Then I doubt this is a bug in Python.

I guess, you meant, this is NOT a bug in Python.

----------
nosy: +orsenthil

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

From report at bugs.python.org  Sun Jul  1 10:29:14 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 01 Jul 2012 08:29:14 +0000
Subject: [issue15234] avoid runtime library path for extensions found in
	system directories
Message-ID: <1341131354.31.0.215672210129.issue15234@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

if a runtime library path is passed to build an extension, it always ends up in the .so file. it's not needed, so avoid runtime library path for extensions found in system directories.

----------
assignee: doko
components: Build
files: rpath.diff
keywords: patch
messages: 164460
nosy: doko
priority: normal
severity: normal
status: open
title: avoid runtime library path for extensions found in system directories
versions: Python 3.3
Added file: http://bugs.python.org/file26222/rpath.diff

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

From report at bugs.python.org  Sun Jul  1 10:36:08 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 01 Jul 2012 08:36:08 +0000
Subject: [issue15235] allow newer berkley db versions
Message-ID: <1341131768.44.0.275273067892.issue15235@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

setup.py still has a version check for berkley db, currently only allowing versions up to 5.1.x. I'm checking in a patch to bump this to allow versions up to 5.3.x.

Maybe this version check should be disabled (after 3.3), using berkley db as a backend for the dbm module doesn't rely on any fancy berkley db features.

----------
assignee: doko
components: Build
messages: 164461
nosy: doko
priority: normal
severity: normal
status: open
title: allow newer berkley db versions
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  1 10:38:10 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Jul 2012 08:38:10 +0000
Subject: [issue15235] allow newer berkley db versions
In-Reply-To: <1341131768.44.0.275273067892.issue15235@psf.upfronthosting.co.za>
Message-ID: <E1SlFfU-0002mc-DV@dinsdale.python.org>


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

New changeset 7be082d80b8a by doko in branch 'default':
- Issue #15235: Allow Berkley DB versions up to 5.3 to build the dbm module.
http://hg.python.org/cpython/rev/7be082d80b8a

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

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

From report at bugs.python.org  Sun Jul  1 10:52:05 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 01 Jul 2012 08:52:05 +0000
Subject: [issue15174] amd64\python_d.exe -m test fails
In-Reply-To: <1340577253.64.0.707739710326.issue15174@psf.upfronthosting.co.za>
Message-ID: <1341132725.86.0.267633906745.issue15174@psf.upfronthosting.co.za>


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

In dbc94178703f it works again. Closing.

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

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

From report at bugs.python.org  Sun Jul  1 11:20:25 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 01 Jul 2012 09:20:25 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341134425.98.0.64646897414.issue15202@psf.upfronthosting.co.za>


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

Bad news: Fearless Leader (Georg) just told me on #python-dev that he's had a change of heart and doesn't want this in 3.3.  I've marked the bug 3.4, and there's no rush on doing this work--we can't check it in until the 3.4 branch exists.  Sorry, Serhiy :(

----------
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Sun Jul  1 11:24:16 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 01 Jul 2012 09:24:16 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341134656.36.0.482460021563.issue15202@psf.upfronthosting.co.za>


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

Georg just clarified: we can just change the parameter names for new APIs.  It's the deprecation / new parameter stuff we can't do for 3.3.  So cut a (much) simpler patch and let's get it in right quick.

----------
versions: +Python 3.3 -Python 3.4

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

From report at bugs.python.org  Sun Jul  1 11:35:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 01 Jul 2012 09:35:26 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341135326.65.0.842491310611.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks.  Then perhaps the documentation can be updated to make that clear.

Currently, the documentation implies that running the given command is sufficient to catch all errors, which can lead to confusion when warning-free content is not rendered as HTML.

----------

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

From report at bugs.python.org  Sun Jul  1 11:42:29 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 01 Jul 2012 09:42:29 +0000
Subject: [issue10650] decimal.py: quantize(): excess digits with watchexp=0
In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za>
Message-ID: <1341135749.96.0.451368057832.issue10650@psf.upfronthosting.co.za>


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

watchexp was available in rescale() from the beginning ...

http://svn.python.org/view/sandbox/trunk/decimal/Decimal.py?revision=40721&view=markup


... and rescale() was renamed to quantize() in

http://svn.python.org/view/sandbox/trunk/decimal/Decimal.py?revision=40909&view=markup


rescale() was once part of the specification, but had identical semantics to
quantize(), which is not specified to allow unlimited rescaling.


I suppose the original rescale() in the sandbox had watchexp for convenience,
in order to avoid two separate functions.

watchexp made it into quantize(), probably because people thought there is
a need for unlimited rescaling. This may be true, but I'd really prefer to
expose rescale() as the unlimited version then.


While it's unusual to just drop an API without deprecation, I think it's OK
in this instance: Virtually all decimal code I saw needs to be cleaned up
anyway because it uses tons of underscore methods from decimal.py.


The only thing that worries me is that there might be code which *really*
needs unlimited rescaling. Such code could of course also use a temporary
context.


So I propose this: Deprecate watchexp and leave it in the Python version for
one release. The C version won't have watchexp from the start. After all,
PEP-399 allows accelerator modules to implement a subset of the functionality
of the Python version -- sometimes PEPs are a wonderful thing :).

----------

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

From report at bugs.python.org  Sun Jul  1 11:46:24 2012
From: report at bugs.python.org (Kai Sterker)
Date: Sun, 01 Jul 2012 09:46:24 +0000
Subject: [issue15236] SEGFAULT in visit_decref
Message-ID: <1341135983.73.0.665812827799.issue15236@psf.upfronthosting.co.za>


New submission from Kai Sterker <kai.sterker at gmail.com>:

Since update to Python 2.7.3 (as distributed by Ubuntu 12.04 64bit), I experience occasional crashes in the application I am developing (which uses Python scripting). The crash either happens at the first key press or it does not happen at all. Smells like a race condition to me.

I installed the debug version of Python 2.7.3 and compiled my project against that, which gave the attached stack trace. The crash also appears to be easier to reproduce with the debug version, but it still does not occur every time.

The application that exhibits the crash can be found here:
https://github.com/ksterker/adonthell

The Python method executed when the crash happens is this one:

    def estimate_speed (self, terrain):
        try:
            return self.Dic[terrain]
        except: return 0


Don't think it will be possible to construct a minimum example to demonstrate the issue, but if there is any other information helpful to shed more light on the issue, I'm happy to provide it.

Regards,

Kai

----------
files: stacktrace.txt
messages: 164468
nosy: Kai.Sterker
priority: normal
severity: normal
status: open
title: SEGFAULT in visit_decref
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file26223/stacktrace.txt

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

From report at bugs.python.org  Sun Jul  1 12:02:51 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 01 Jul 2012 10:02:51 +0000
Subject: [issue15237] Add capsule API to _decimal
Message-ID: <1341136971.24.0.846129884923.issue15237@psf.upfronthosting.co.za>


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

Unfortunately, this won't make it into 3.3. -- The self-review of mpdecimal.c had priority and was extremely time consuming.

----------
assignee: skrah
messages: 164469
nosy: lemburg, mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add capsule API to _decimal
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jul  1 12:06:20 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 01 Jul 2012 10:06:20 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1341137180.46.0.942342769033.issue7652@psf.upfronthosting.co.za>


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

I've opened #15237 for the capsule API. I didn't add everyone to the
nosy list, since I suspect it's not of general interest.

----------

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

From report at bugs.python.org  Sun Jul  1 12:09:42 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 01 Jul 2012 10:09:42 +0000
Subject: [issue15237] Add capsule API to _decimal
In-Reply-To: <1341136971.24.0.846129884923.issue15237@psf.upfronthosting.co.za>
Message-ID: <1341137382.83.0.222774144761.issue15237@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
nosy: +larry

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

From report at bugs.python.org  Sun Jul  1 12:17:29 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Jul 2012 10:17:29 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341137849.84.0.0751676027195.issue15233@psf.upfronthosting.co.za>


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

It is guaranteed by libc's atexit(3), and should also be guaranteed here.

----------
nosy: +neologix

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

From report at bugs.python.org  Sun Jul  1 12:20:25 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 01 Jul 2012 10:20:25 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341138025.45.0.43246570336.issue15233@psf.upfronthosting.co.za>


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

+1 to guaranteeing the order.

----------
nosy: +larry

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

From report at bugs.python.org  Sun Jul  1 12:41:24 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 01 Jul 2012 10:41:24 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	packaging
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1341139284.43.0.939011450375.issue3871@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

fyi, the cross build changes are now checked in. Checked with an x86_64-linux-gnu to arm-linux-gnueabi cross build.  I don't plan to add anything more for the 3.3 release besides bug fixes.

----------

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

From report at bugs.python.org  Sun Jul  1 12:42:27 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 01 Jul 2012 10:42:27 +0000
Subject: [issue15237] Add capsule API to _decimal
In-Reply-To: <1341136971.24.0.846129884923.issue15237@psf.upfronthosting.co.za>
Message-ID: <1341139347.49.0.903428296739.issue15237@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See issue #7652 for context.

----------

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

From report at bugs.python.org  Sun Jul  1 13:27:15 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Jul 2012 11:27:15 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341130849.14.0.299738096552.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341141975.3363.0.camel@localhost.localdomain>


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

> I believe it should be guaranteed behavior and that code may
> reasonably want to have a predictable sequence of unwinding behaviors.

Agreed.

----------

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

From report at bugs.python.org  Sun Jul  1 14:04:12 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Sun, 01 Jul 2012 12:04:12 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341144252.01.0.0683657027347.issue14902@psf.upfronthosting.co.za>


Juancarlo A?ez <apalala at gmail.com> added the comment:

My local timezone is (VET,VET) == time.tzname, and test_logging fails because time.timezone is off by 30 minutes. I couldn't find the cause for the problem with time.timezone, but logging is not to blame. I'm running the tests on Ubuntu 12.04 AMD64 which handles my time zone correctly throughout.

I'm submitting a patch that allows test_logging to pass by not relying on time.timezone.

----------
keywords: +patch
nosy: +apalala
Added file: http://bugs.python.org/file26224/test_logging_wo_timezone.patch

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

From report at bugs.python.org  Sun Jul  1 14:40:48 2012
From: report at bugs.python.org (Ray Donnelly)
Date: Sun, 01 Jul 2012 12:40:48 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	packaging
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1341146448.16.0.374108716509.issue3871@psf.upfronthosting.co.za>


Ray Donnelly <mingw.android at gmail.com> added the comment:

Thanks Matthias, I might wait until b2 (or rc1) before I rebase my patches, just because I'm so unfamiliar with Mercurial.

----------

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

From report at bugs.python.org  Sun Jul  1 15:10:10 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Jul 2012 13:10:10 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1341134656.36.0.482460021563.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341148212.3264.65.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Here is an updated patches (with index 3). No aliased parameters, only
new parameters renamed. Some minor errors have fixed.

----------
Added file: http://bugs.python.org/file26225/followlinks-to-follow_symlinks-3.patch
Added file: http://bugs.python.org/file26226/symlinks-to-follow_symlinks-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15202>
_______________________________________
-------------- next part --------------
diff -r a1c8302e6b27 Doc/library/os.rst
--- a/Doc/library/os.rst	Sun Jul 01 12:24:20 2012 +0200
+++ b/Doc/library/os.rst	Sun Jul 01 15:54:02 2012 +0300
@@ -2211,7 +2211,7 @@
               os.rmdir(os.path.join(root, name))
 
 
-.. function:: fwalk(top='.', topdown=True, onerror=None, followlinks=False, *, dir_fd=None)
+.. function:: fwalk(top='.', topdown=True, onerror=None, follow_symlinks=False, *, dir_fd=None)
 
    .. index::
       single: directory; walking
diff -r a1c8302e6b27 Lib/os.py
--- a/Lib/os.py	Sun Jul 01 12:24:20 2012 +0200
+++ b/Lib/os.py	Sun Jul 01 15:54:02 2012 +0300
@@ -424,7 +424,7 @@
 
 if {open, stat} <= supports_dir_fd and {listdir, stat} <= supports_fd:
 
-    def fwalk(top=".", topdown=True, onerror=None, followlinks=False, *, dir_fd=None):
+    def fwalk(top=".", topdown=True, onerror=None, follow_symlinks=False, *, dir_fd=None):
         """Directory tree generator.
 
         This behaves exactly like walk(), except that it yields a 4-tuple
@@ -435,7 +435,7 @@
         and `dirfd` is a file descriptor referring to the directory `dirpath`.
 
         The advantage of fwalk() over walk() is that it's safe against symlink
-        races (when followlinks is False).
+        races (when follow_symlinks is False).
 
         If dir_fd is not None, it should be a file descriptor open to a directory,
           and top should be relative; top will then be relative to that directory.
@@ -462,13 +462,13 @@
         orig_st = stat(top, follow_symlinks=False, dir_fd=dir_fd)
         topfd = open(top, O_RDONLY, dir_fd=dir_fd)
         try:
-            if (followlinks or (st.S_ISDIR(orig_st.st_mode) and
-                                path.samestat(orig_st, stat(topfd)))):
-                yield from _fwalk(topfd, top, topdown, onerror, followlinks)
+            if (follow_symlinks or (st.S_ISDIR(orig_st.st_mode) and
+                                    path.samestat(orig_st, stat(topfd)))):
+                yield from _fwalk(topfd, top, topdown, onerror, follow_symlinks)
         finally:
             close(topfd)
 
-    def _fwalk(topfd, toppath, topdown, onerror, followlinks):
+    def _fwalk(topfd, toppath, topdown, onerror, follow_symlinks):
         # Note: This uses O(depth of the directory tree) file descriptors: if
         # necessary, it can be adapted to only require O(1) FDs, see issue
         # #13734.
@@ -499,16 +499,16 @@
 
         for name in dirs:
             try:
-                orig_st = stat(name, dir_fd=topfd, follow_symlinks=followlinks)
+                orig_st = stat(name, dir_fd=topfd, follow_symlinks=follow_symlinks)
                 dirfd = open(name, O_RDONLY, dir_fd=topfd)
             except error as err:
                 if onerror is not None:
                     onerror(err)
                 return
             try:
-                if followlinks or path.samestat(orig_st, stat(dirfd)):
+                if follow_symlinks or path.samestat(orig_st, stat(dirfd)):
                     dirpath = path.join(toppath, name)
-                    yield from _fwalk(dirfd, dirpath, topdown, onerror, followlinks)
+                    yield from _fwalk(dirfd, dirpath, topdown, onerror, follow_symlinks)
             finally:
                 close(dirfd)
 
diff -r a1c8302e6b27 Lib/test/test_os.py
--- a/Lib/test/test_os.py	Sun Jul 01 12:24:20 2012 +0200
+++ b/Lib/test/test_os.py	Sun Jul 01 15:54:02 2012 +0300
@@ -745,10 +745,11 @@
         """
         compare with walk() results.
         """
-        for topdown, followlinks in itertools.product((True, False), repeat=2):
-            d = {'topdown': topdown, 'followlinks': followlinks}
-            walk_kwargs.update(d)
-            fwalk_kwargs.update(d)
+        walk_kwargs = walk_kwargs.copy()
+        fwalk_kwargs = fwalk_kwargs.copy()
+        for topdown, follow_symlinks in itertools.product((True, False), repeat=2):
+            walk_kwargs.update(topdown=topdown, followlinks=follow_symlinks)
+            fwalk_kwargs.update(topdown=topdown, follow_symlinks=follow_symlinks)
 
             expected = {}
             for root, dirs, files in os.walk(**walk_kwargs):
@@ -774,8 +775,8 @@
 
     def test_yields_correct_dir_fd(self):
         # check returned file descriptors
-        for topdown, followlinks in itertools.product((True, False), repeat=2):
-            args = support.TESTFN, topdown, None, followlinks
+        for topdown, follow_symlinks in itertools.product((True, False), repeat=2):
+            args = support.TESTFN, topdown, None, follow_symlinks
             for root, dirs, files, rootfd in os.fwalk(*args):
                 # check that the FD is valid
                 os.fstat(rootfd)
-------------- next part --------------
diff -r a1c8302e6b27 Doc/library/shutil.rst
--- a/Doc/library/shutil.rst	Sun Jul 01 12:24:20 2012 +0200
+++ b/Doc/library/shutil.rst	Sun Jul 01 16:04:48 2012 +0300
@@ -47,7 +47,7 @@
    be copied.
 
 
-.. function:: copyfile(src, dst, symlinks=False)
+.. function:: copyfile(src, dst, follow_symlinks=True)
 
    Copy the contents (no metadata) of the file named *src* to a file named
    *dst* and return *dst*.  *dst* must be the complete target file name; look at
@@ -59,63 +59,63 @@
    such as character or block devices and pipes cannot be copied with this
    function.  *src* and *dst* are path names given as strings.
 
-   If *symlinks* is true and *src* is a symbolic link, a new symbolic link will
+   If *follow_symlinks* is false and *src* is a symbolic link, a new symbolic link will
    be created instead of copying the file *src* points to.
 
    .. versionchanged:: 3.3
       :exc:`IOError` used to be raised instead of :exc:`OSError`.
-      Added *symlinks* argument.
+      Added *follow_symlinks* argument.
 
    .. versionchanged:: 3.3
       Added return of the *dst*.
 
-.. function:: copymode(src, dst, symlinks=False)
+.. function:: copymode(src, dst, follow_symlinks=True)
 
    Copy the permission bits from *src* to *dst*.  The file contents, owner, and
    group are unaffected.  *src* and *dst* are path names given as strings.  If
-   *symlinks* is true, *src* a symbolic link and the operating system supports
+   *follow_symlinks* is false, *src* a symbolic link and the operating system supports
    modes for symbolic links (for example BSD-based ones), the mode of the link
    will be copied.
 
    .. versionchanged:: 3.3
-      Added *symlinks* argument.
+      Added *follow_symlinks* argument.
 
-.. function:: copystat(src, dst, symlinks=False)
+.. function:: copystat(src, dst, follow_symlinks=True)
 
    Copy the permission bits, last access time, last modification time, and flags
    from *src* to *dst*.  The file contents, owner, and group are unaffected.  *src*
    and *dst* are path names given as strings.  If *src* and *dst* are both
-   symbolic links and *symlinks* true, the stats of the link will be copied as
+   symbolic links and *follow_symlinks* false, the stats of the link will be copied as
    far as the platform allows.
 
    .. versionchanged:: 3.3
-      Added *symlinks* argument.
+      Added *follow_symlinks* argument.
 
-.. function:: copy(src, dst, symlinks=False)
+.. function:: copy(src, dst, follow_symlinks=True)
 
    Copy the file *src* to the file or directory *dst* and return the file's
    destination.  If *dst* is a directory, a
    file with the same basename as *src*  is created (or overwritten) in the
    directory specified.  Permission bits are copied.  *src* and *dst* are path
-   names given as strings.  If *symlinks* is true, symbolic links won't be
+   names given as strings.  If *follow_symlinks* is false, symbolic links won't be
    followed but recreated instead -- this resembles GNU's :program:`cp -P`.
 
    .. versionchanged:: 3.3
-      Added *symlinks* argument.
+      Added *follow_symlinks* argument.
 
    .. versionchanged:: 3.3
       Added return of the *dst*.
 
-.. function:: copy2(src, dst, symlinks=False)
+.. function:: copy2(src, dst, follow_symlinks=True)
 
    Similar to :func:`shutil.copy`, including that the destination is
    returned, but metadata is copied as well. This is
-   similar to the Unix command :program:`cp -p`.  If *symlinks* is true,
+   similar to the Unix command :program:`cp -p`.  If *follow_symlinks* is false,
    symbolic links won't be followed but recreated instead -- this resembles
    GNU's :program:`cp -P`.
 
    .. versionchanged:: 3.3
-      Added *symlinks* argument, try to copy extended file system attributes
+      Added *follow_symlinks* argument, try to copy extended file system attributes
       too (currently Linux only).
 
    .. versionchanged:: 3.3
diff -r a1c8302e6b27 Lib/shutil.py
--- a/Lib/shutil.py	Sun Jul 01 12:24:20 2012 +0200
+++ b/Lib/shutil.py	Sun Jul 01 16:04:48 2012 +0300
@@ -82,10 +82,10 @@
     return (os.path.normcase(os.path.abspath(src)) ==
             os.path.normcase(os.path.abspath(dst)))
 
-def copyfile(src, dst, symlinks=False):
+def copyfile(src, dst, follow_symlinks=True):
     """Copy data from src to dst.
 
-    If optional flag `symlinks` is set and `src` is a symbolic link, a new
+    If optional flag `follow_symlinks` is not set and `src` is a symbolic link, a new
     symlink will be created instead of copying the file it points to.
 
     """
@@ -103,7 +103,7 @@
             if stat.S_ISFIFO(st.st_mode):
                 raise SpecialFileError("`%s` is a named pipe" % fn)
 
-    if symlinks and os.path.islink(src):
+    if not follow_symlinks and os.path.islink(src):
         os.symlink(os.readlink(src), dst)
     else:
         with open(src, 'rb') as fsrc:
@@ -111,15 +111,15 @@
                 copyfileobj(fsrc, fdst)
     return dst
 
-def copymode(src, dst, symlinks=False):
+def copymode(src, dst, follow_symlinks=True):
     """Copy mode bits from src to dst.
 
-    If the optional flag `symlinks` is set, symlinks aren't followed if and
+    If the optional flag `follow_symlinks` is not set, symlinks aren't followed if and
     only if both `src` and `dst` are symlinks. If `lchmod` isn't available (eg.
     Linux), in these cases, this method does nothing.
 
     """
-    if symlinks and os.path.islink(src) and os.path.islink(dst):
+    if not follow_symlinks and os.path.islink(src) and os.path.islink(dst):
         if hasattr(os, 'lchmod'):
             stat_func, chmod_func = os.lstat, os.lchmod
         else:
@@ -132,10 +132,10 @@
     st = stat_func(src)
     chmod_func(dst, stat.S_IMODE(st.st_mode))
 
-def copystat(src, dst, symlinks=False):
+def copystat(src, dst, follow_symlinks=True):
     """Copy all stat info (mode bits, atime, mtime, flags) from src to dst.
 
-    If the optional flag `symlinks` is set, symlinks aren't followed if and
+    If the optional flag `follow_symlinks` is not set, symlinks aren't followed if and
     only if both `src` and `dst` are symlinks.
 
     """
@@ -143,7 +143,7 @@
         pass
 
     # follow symlinks (aka don't not follow symlinks)
-    follow = not (symlinks and os.path.islink(src) and os.path.islink(dst))
+    follow = follow_symlinks or not (os.path.islink(src) and os.path.islink(dst))
     if follow:
         # use the real function if it exists
         def lookup(name):
@@ -186,19 +186,19 @@
                 raise
 
 if hasattr(os, 'listxattr'):
-    def _copyxattr(src, dst, symlinks=False):
+    def _copyxattr(src, dst, follow_symlinks=True):
         """Copy extended filesystem attributes from `src` to `dst`.
 
         Overwrite existing attributes.
 
-        If the optional flag `symlinks` is set, symlinks won't be followed.
+        If the optional flag `follow_symlinks` is not set, symlinks won't be followed.
 
         """
 
-        for name in os.listxattr(src, follow_symlinks=symlinks):
+        for name in os.listxattr(src, follow_symlinks=follow_symlinks):
             try:
-                value = os.getxattr(src, name, follow_symlinks=symlinks)
-                os.setxattr(dst, name, value, follow_symlinks=symlinks)
+                value = os.getxattr(src, name, follow_symlinks=follow_symlinks)
+                os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
             except OSError as e:
                 if e.errno not in (errno.EPERM, errno.ENOTSUP, errno.ENODATA):
                     raise
@@ -206,36 +206,36 @@
     def _copyxattr(*args, **kwargs):
         pass
 
-def copy(src, dst, symlinks=False):
+def copy(src, dst, follow_symlinks=True):
     """Copy data and mode bits ("cp src dst"). Return the file's destination.
 
     The destination may be a directory.
 
-    If the optional flag `symlinks` is set, symlinks won't be followed. This
+    If the optional flag `follow_symlinks` is not set, symlinks won't be followed. This
     resembles GNU's "cp -P src dst".
 
     """
     if os.path.isdir(dst):
         dst = os.path.join(dst, os.path.basename(src))
-    copyfile(src, dst, symlinks=symlinks)
-    copymode(src, dst, symlinks=symlinks)
+    copyfile(src, dst, follow_symlinks=follow_symlinks)
+    copymode(src, dst, follow_symlinks=follow_symlinks)
     return dst
 
-def copy2(src, dst, symlinks=False):
+def copy2(src, dst, follow_symlinks=True):
     """Copy data and all stat info ("cp -p src dst"). Return the file's
     destination."
 
     The destination may be a directory.
 
-    If the optional flag `symlinks` is set, symlinks won't be followed. This
+    If the optional flag `follow_symlinks` is not set, symlinks won't be followed. This
     resembles GNU's "cp -P src dst".
 
     """
     if os.path.isdir(dst):
         dst = os.path.join(dst, os.path.basename(src))
-    copyfile(src, dst, symlinks=symlinks)
-    copystat(src, dst, symlinks=symlinks)
-    _copyxattr(src, dst, symlinks=symlinks)
+    copyfile(src, dst, follow_symlinks=follow_symlinks)
+    copystat(src, dst, follow_symlinks=follow_symlinks)
+    _copyxattr(src, dst, follow_symlinks=follow_symlinks)
     return dst
 
 def ignore_patterns(*patterns):
@@ -307,7 +307,7 @@
                     # code with a custom `copy_function` may rely on copytree
                     # doing the right thing.
                     os.symlink(linkto, dstname)
-                    copystat(srcname, dstname, symlinks=symlinks)
+                    copystat(srcname, dstname, follow_symlinks=not symlinks)
                 else:
                     # ignore dangling symlink if the flag is on
                     if not os.path.exists(linkto) and ignore_dangling_symlinks:
diff -r a1c8302e6b27 Lib/test/test_shutil.py
--- a/Lib/test/test_shutil.py	Sun Jul 01 12:24:20 2012 +0200
+++ b/Lib/test/test_shutil.py	Sun Jul 01 16:04:48 2012 +0300
@@ -277,17 +277,17 @@
         os.lchmod(src_link, stat.S_IRWXO|stat.S_IRWXG)
         # link to link
         os.lchmod(dst_link, stat.S_IRWXO)
-        shutil.copymode(src_link, dst_link, symlinks=True)
+        shutil.copymode(src_link, dst_link, follow_symlinks=False)
         self.assertEqual(os.lstat(src_link).st_mode,
                          os.lstat(dst_link).st_mode)
         self.assertNotEqual(os.stat(src).st_mode, os.stat(dst).st_mode)
         # src link - use chmod
         os.lchmod(dst_link, stat.S_IRWXO)
-        shutil.copymode(src_link, dst, symlinks=True)
+        shutil.copymode(src_link, dst, follow_symlinks=False)
         self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode)
         # dst link - use chmod
         os.lchmod(dst_link, stat.S_IRWXO)
-        shutil.copymode(src, dst_link, symlinks=True)
+        shutil.copymode(src, dst_link, follow_symlinks=False)
         self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode)
 
     @unittest.skipIf(hasattr(os, 'lchmod'), 'requires os.lchmod to be missing')
@@ -302,7 +302,7 @@
         write_file(dst, 'foo')
         os.symlink(src, src_link)
         os.symlink(dst, dst_link)
-        shutil.copymode(src_link, dst_link, symlinks=True)  # silent fail
+        shutil.copymode(src_link, dst_link, follow_symlinks=False)  # silent fail
 
     @support.skip_unless_symlink
     def test_copystat_symlinks(self):
@@ -326,10 +326,10 @@
         src_link_stat = os.lstat(src_link)
         # follow
         if hasattr(os, 'lchmod'):
-            shutil.copystat(src_link, dst_link, symlinks=False)
+            shutil.copystat(src_link, dst_link, follow_symlinks=True)
             self.assertNotEqual(src_link_stat.st_mode, os.stat(dst).st_mode)
         # don't follow
-        shutil.copystat(src_link, dst_link, symlinks=True)
+        shutil.copystat(src_link, dst_link, follow_symlinks=False)
         dst_link_stat = os.lstat(dst_link)
         if os.utime in os.supports_follow_symlinks:
             for attr in 'st_atime', 'st_mtime':
@@ -341,7 +341,7 @@
         if hasattr(os, 'lchflags') and hasattr(src_link_stat, 'st_flags'):
             self.assertEqual(src_link_stat.st_flags, dst_link_stat.st_flags)
         # tell to follow but dst is not a link
-        shutil.copystat(src_link, dst, symlinks=True)
+        shutil.copystat(src_link, dst, follow_symlinks=False)
         self.assertTrue(abs(os.stat(src).st_mtime - os.stat(dst).st_mtime) <
                         00000.1)
 
@@ -429,10 +429,10 @@
         dst_link = os.path.join(tmp_dir, 'qux')
         write_file(dst, 'bar')
         os.symlink(dst, dst_link)
-        shutil._copyxattr(src_link, dst_link, symlinks=True)
+        shutil._copyxattr(src_link, dst_link, follow_symlinks=False)
         self.assertEqual(os.getxattr(dst_link, 'trusted.foo', follow_symlinks=False), b'43')
         self.assertRaises(OSError, os.getxattr, dst, 'trusted.foo')
-        shutil._copyxattr(src_link, dst, symlinks=True)
+        shutil._copyxattr(src_link, dst, follow_symlinks=False)
         self.assertEqual(os.getxattr(dst, 'trusted.foo'), b'43')
 
     @support.skip_unless_symlink
@@ -446,12 +446,12 @@
         if hasattr(os, 'lchmod'):
             os.lchmod(src_link, stat.S_IRWXU | stat.S_IRWXO)
         # don't follow
-        shutil.copy(src_link, dst, symlinks=False)
+        shutil.copy(src_link, dst, follow_symlinks=True)
         self.assertFalse(os.path.islink(dst))
         self.assertEqual(read_file(src), read_file(dst))
         os.remove(dst)
         # follow
-        shutil.copy(src_link, dst, symlinks=True)
+        shutil.copy(src_link, dst, follow_symlinks=False)
         self.assertTrue(os.path.islink(dst))
         self.assertEqual(os.readlink(dst), os.readlink(src_link))
         if hasattr(os, 'lchmod'):
@@ -473,12 +473,12 @@
         src_stat = os.stat(src)
         src_link_stat = os.lstat(src_link)
         # follow
-        shutil.copy2(src_link, dst, symlinks=False)
+        shutil.copy2(src_link, dst, follow_symlinks=True)
         self.assertFalse(os.path.islink(dst))
         self.assertEqual(read_file(src), read_file(dst))
         os.remove(dst)
         # don't follow
-        shutil.copy2(src_link, dst, symlinks=True)
+        shutil.copy2(src_link, dst, follow_symlinks=False)
         self.assertTrue(os.path.islink(dst))
         self.assertEqual(os.readlink(dst), os.readlink(src_link))
         dst_stat = os.lstat(dst)
@@ -516,7 +516,7 @@
         write_file(src, 'foo')
         os.symlink(src, link)
         # don't follow
-        shutil.copyfile(link, dst_link, symlinks=True)
+        shutil.copyfile(link, dst_link, follow_symlinks=False)
         self.assertTrue(os.path.islink(dst_link))
         self.assertEqual(os.readlink(link), os.readlink(dst_link))
         # follow

From report at bugs.python.org  Sun Jul  1 15:10:17 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Jul 2012 13:10:17 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341148217.23.0.970418769356.issue15202@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file26194/followlinks-to-follow_symlinks-2.patch

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

From report at bugs.python.org  Sun Jul  1 15:10:38 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Jul 2012 13:10:38 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341148238.74.0.342874584272.issue15202@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file26195/symlinks-to-follow_symlinks-2.patch

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

From report at bugs.python.org  Sun Jul  1 15:38:29 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 01 Jul 2012 13:38:29 +0000
Subject: [issue15235] allow newer berkley db versions
In-Reply-To: <1341131768.44.0.275273067892.issue15235@psf.upfronthosting.co.za>
Message-ID: <1341149909.06.0.561661132612.issue15235@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Mattias, the tracker indicates that PDF doesn't have your contributor agreement. Could you possibly send one?.

http://www.python.org/psf/contrib/contrib-form/

----------
nosy: +jcea

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

From report at bugs.python.org  Sun Jul  1 15:39:05 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 01 Jul 2012 13:39:05 +0000
Subject: [issue15235] allow newer berkley db versions
In-Reply-To: <1341131768.44.0.275273067892.issue15235@psf.upfronthosting.co.za>
Message-ID: <1341149945.79.0.402718755098.issue15235@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

PDF = PSF (Python software Foundation)

----------

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

From report at bugs.python.org  Sun Jul  1 15:42:47 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 01 Jul 2012 13:42:47 +0000
Subject: [issue15236] SEGFAULT in visit_decref
In-Reply-To: <1341135983.73.0.665812827799.issue15236@psf.upfronthosting.co.za>
Message-ID: <1341150167.14.0.459983900184.issue15236@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/issue15236>
_______________________________________

From report at bugs.python.org  Sun Jul  1 16:21:40 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 01 Jul 2012 14:21:40 +0000
Subject: [issue15235] allow newer berkley db versions
In-Reply-To: <1341131768.44.0.275273067892.issue15235@psf.upfronthosting.co.za>
Message-ID: <1341152500.54.0.980426629573.issue15235@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

hmm, that was submitted years ago ... (can we move this off line?)

----------

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

From report at bugs.python.org  Sun Jul  1 16:41:16 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Jul 2012 14:41:16 +0000
Subject: [issue15237] Add capsule API to _decimal
In-Reply-To: <1341136971.24.0.846129884923.issue15237@psf.upfronthosting.co.za>
Message-ID: <1341153676.42.0.801257905917.issue15237@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/issue15237>
_______________________________________

From report at bugs.python.org  Sun Jul  1 16:58:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Jul 2012 14:58:56 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1341154735.91.0.721488895683.issue2771@psf.upfronthosting.co.za>


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

New changeset b449118653fe by Antoine Pitrou in branch 'default':
some new t?st (issue #2771)
http://hg.python.org/test/rev/b449118653fe

----------

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

From report at bugs.python.org  Sun Jul  1 17:13:29 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 01 Jul 2012 15:13:29 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
Message-ID: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>


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

3.3 adds the *xattr() extended attribute functions on Linux.  shutil implements a new internal function(_copyxattr) which copies these extended attributes.  However, it's only used in shutil.copy2().  I assert that shutil.copystat() should also preserve this metadata.  (Which, having subsumed this functionality, means that shutil.copy2() would no longer need to explicitly call it.)

Also: it might be worth considering taking the same approach _copyxattr uses for the other conditional functionality (see "def lookup" inside copystat).  Computing platform support at import time instead of runtime looks cleaner.

Georg, how much of this (if any) do you consider a 3.3 bugfix?

----------
assignee: larry
messages: 164483
nosy: georg.brandl, larry, storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: shutil.copystat should copy Linux extended attributes
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  1 17:14:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Jul 2012 15:14:54 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <1341155694.34.0.898370769358.issue15238@psf.upfronthosting.co.za>


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


----------
nosy: +hynek

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

From report at bugs.python.org  Sun Jul  1 17:42:36 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 01 Jul 2012 15:42:36 +0000
Subject: [issue15206] uuid module falls back to unsuitable RNG
In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za>
Message-ID: <1341157356.12.0.165748173107.issue15206@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The rest of the module uses bar excepts. I could change the signature if you insist.

----------

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

From report at bugs.python.org  Sun Jul  1 18:03:57 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 01 Jul 2012 16:03:57 +0000
Subject: [issue15236] SEGFAULT in visit_decref
In-Reply-To: <1341135983.73.0.665812827799.issue15236@psf.upfronthosting.co.za>
Message-ID: <1341158637.95.0.194630478733.issue15236@psf.upfronthosting.co.za>


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

This programs embeds a Python interpreter and uses the C API extensively.
I tried to compile it, but could not make it use Python 2.7.

Your stracktrace suggests a buffer overflow, or reuse of a freed object:
"ob_refcnt = 8462385097079783424, ob_type = 0x72746e6f633a3a74" contains the ascii of "input::contr".  Probably a "input::control_event*" which is the raised event.

I suspect that the memory corruption has always occurred, but with 2.7.3 a garbage collection happens in the middle of an event callback.  Could you add some "gc.collect()" here and there, and see if other versions Of Python crash as well?

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Sun Jul  1 18:40:08 2012
From: report at bugs.python.org (Erno Tukia)
Date: Sun, 01 Jul 2012 16:40:08 +0000
Subject: [issue13700] imaplib.IMAP4.authenticate authobject does not work
	correctly in python3
In-Reply-To: <1325553089.14.0.504978991098.issue13700@psf.upfronthosting.co.za>
Message-ID: <1341160808.69.0.928219383934.issue13700@psf.upfronthosting.co.za>


Erno Tukia <erno.tukia at iki.fi> added the comment:

Here's the updated patch. Tests now works. PLAIN works for me, that's only I can test against live system.

test_login_cram_md5 test had extra \r\n in _send_tagged.

diff imaplib_authenticate.patch imaplib_authenticate_v2.patch
< + self._send_tagged(tag, 'OK', 'CRAM-MD5 successful\r\n')
---
> + self._send_tagged(tag, 'OK', 'CRAM-MD5 successful')

----------
Added file: http://bugs.python.org/file26227/imaplib_authenticate_v2.patch

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

From report at bugs.python.org  Sun Jul  1 19:19:36 2012
From: report at bugs.python.org (Daniel Lenski)
Date: Sun, 01 Jul 2012 17:19:36 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on
	Windows
In-Reply-To: <1341072450.66.0.0658698533961.issue14243@psf.upfronthosting.co.za>
Message-ID: <CAOw_LSErVeZzdruJKgksOQ71=VkFYW91D=0KyXeM6WoovL5xTg@mail.gmail.com>


Daniel Lenski <dlenski at gmail.com> added the comment:

Richard, I think the problem with this is that it spreads the non-portable
or OS-dependent parts of the code over several places rather than
concentrating them all in one place.

After close_without_unlink(), what would happen when the context manager
exits or when the object is garbage collected?  Would it then get unlinked?

My preference would be to specify the behavior of close/__exit__/GC
operations at the time of the NamedTemporaryFile creation, so that the rest
of the code can be left unchanged.

----------

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

From report at bugs.python.org  Sun Jul  1 19:22:04 2012
From: report at bugs.python.org (Ian Bell)
Date: Sun, 01 Jul 2012 17:22:04 +0000
Subject: [issue15198] multiprocessing Pipe send of non-picklable objects
	doesn't raise error
In-Reply-To: <1340767549.24.0.475642908305.issue15198@psf.upfronthosting.co.za>
Message-ID: <1341163324.34.0.791063004228.issue15198@psf.upfronthosting.co.za>


Ian Bell <ian.h.bell at gmail.com> added the comment:

I have repaired my class so that it pickles properly, but that does not resolve the issue that if you send a non-picklable object through a pipe, it should raise an error, rather than hang.

----------

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

From report at bugs.python.org  Sun Jul  1 19:36:14 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Jul 2012 17:36:14 +0000
Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py
Message-ID: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

It seems that Tools/unicode/mkstringprep.py has not been used for many years. Now it is not valid Python3 code nor Python2 code. The proposed patch fixes all porting errors.

Apparently, Lib/stringprep.py would have regenerated. Tools/unicode/mkstringprep.py output is a bit different from Lib/stringprep.py (in b3_exceptions).

----------
components: Demos and Tools, Unicode
messages: 164489
nosy: ezio.melotti, storchaka
priority: normal
severity: normal
status: open
title: Abandoned Tools/unicode/mkstringprep.py
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul  1 19:37:27 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Jul 2012 17:37:27 +0000
Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py
In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za>
Message-ID: <1341164247.94.0.500173762209.issue15239@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file26228/mkstringprep.patch

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

From report at bugs.python.org  Sun Jul  1 19:40:49 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 01 Jul 2012 17:40:49 +0000
Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py
In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za>
Message-ID: <1341164449.42.0.392193036556.issue15239@psf.upfronthosting.co.za>


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

Indeed, the code hasn't been run, and really shouldn't have to. If it produces different output today, we should investigate why.

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

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

From report at bugs.python.org  Sun Jul  1 20:10:57 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 01 Jul 2012 18:10:57 +0000
Subject: [issue15198] multiprocessing Pipe send of non-picklable objects
	doesn't raise error
In-Reply-To: <1340767549.24.0.475642908305.issue15198@psf.upfronthosting.co.za>
Message-ID: <1341166257.03.0.213058138981.issue15198@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

> I have repaired my class so that it pickles properly, but that does not 
> resolve the issue that if you send a non-picklable object through a pipe, 
> it should raise an error, rather than hang.

What do you mean by hang?  Do you mean that send() succeeds and recv() raises an error.  That might cause your *program* to hang, but send() itself should not hang.

----------

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

From report at bugs.python.org  Sun Jul  1 20:40:55 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Jul 2012 18:40:55 +0000
Subject: [issue15206] uuid module falls back to unsuitable RNG
In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za>
Message-ID: <1341168055.73.0.747530258628.issue15206@psf.upfronthosting.co.za>


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

> The rest of the module uses bar excepts.

It was probably written in prehistoric times :)
The other excepts can be converted later, if the module gets other changes. I don't think it is a deliberate style choice (it would be particularly distasteful :-)).

----------

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

From report at bugs.python.org  Sun Jul  1 20:42:37 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 01 Jul 2012 18:42:37 +0000
Subject: [issue15232] email.generator.Generator doesn't mangle "From " lines
	in MIME preamble
In-Reply-To: <1341118945.33.0.829442271947.issue15232@psf.upfronthosting.co.za>
Message-ID: <1341168157.15.0.511827066099.issue15232@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Hi and thanks for the report. It seems that this is a bug in email.generator.Generator, as it fails to mangle "From " lines in the MIME preamble (after the headers, before the first "--Boundary..." line).

----------
components: +Library (Lib)
nosy: +petri.lehtinen
stage:  -> needs patch
title: maildir parsing can split up messages with 'From ' at the start of a line -> email.generator.Generator doesn't mangle "From " lines in MIME preamble
type:  -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul  1 22:18:15 2012
From: report at bugs.python.org (Kai Sterker)
Date: Sun, 01 Jul 2012 20:18:15 +0000
Subject: [issue15236] SEGFAULT in visit_decref
In-Reply-To: <1341135983.73.0.665812827799.issue15236@psf.upfronthosting.co.za>
Message-ID: <1341173895.8.0.289175205538.issue15236@psf.upfronthosting.co.za>


Kai Sterker <kai.sterker at gmail.com> added the comment:

To compile against a python version that is not system-default, configure with

  PYTHON=/usr/bin/python2.7 ../adonthell/configure --with-py-cflags=-I/usr/include/python2.7 --with-py-libs=-lpython2.7


Regardless of that, your hints are proving useful. I compiled with 2.6.8 and was not able to reproduce the issue. However, with a gc.collect() call added to estimate_speed, it will again happen sometimes.

So it does not seem to be specific to Python 2.7.3 (and is probably not even a problem with Python at all). Could this be triggered by a missing Py_INCREF somewhere? Or would you suspect something totally unrelated? (But then I would expect other random crashes, too.)

----------

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

From report at bugs.python.org  Sun Jul  1 22:30:38 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 01 Jul 2012 20:30:38 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on
	Windows
In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za>
Message-ID: <1341174638.32.0.317785771531.issue14243@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

The webpage

    http://msdn.microsoft.com/en-us/library/aa273350(v=vs.60).aspx

describes the sopen() function which is like open() but has an extra shflag parameter for specifying the sharing allowed.

If sopen() and the associated constants SH_DENYRD, SH_DENYWR, SH_DENYRW and SH_DENYNO were exposed in the os module, then maybe tempfile could use os.sopen() on Windows instead of os.open() to allow the file to be reopened without closing.

----------

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

From report at bugs.python.org  Sun Jul  1 22:37:11 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Jul 2012 20:37:11 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on
	Windows
In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za>
Message-ID: <1341175031.38.0.128120138352.issue14243@psf.upfronthosting.co.za>


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

> If sopen() and the associated constants SH_DENYRD, SH_DENYWR, SH_DENYRW 
> and SH_DENYNO were exposed in the os module, then maybe tempfile could 
> use os.sopen() on Windows instead of os.open() to allow the file to be 
> reopened without closing.

Sounds like a good way forward.

----------
components: +Windows
stage:  -> needs patch
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Sun Jul  1 22:39:00 2012
From: report at bugs.python.org (Tim Golden)
Date: Sun, 01 Jul 2012 20:39:00 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on
	Windows
In-Reply-To: <1341175031.38.0.128120138352.issue14243@psf.upfronthosting.co.za>
Message-ID: <4FF0B55C.5000804@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

On 01/07/2012 21:37, Antoine Pitrou wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> If sopen() and the associated constants SH_DENYRD, SH_DENYWR, SH_DENYRW
>> and SH_DENYNO were exposed in the os module, then maybe tempfile could
>> use os.sopen() on Windows instead of os.open() to allow the file to be
>> reopened without closing.
>
> Sounds like a good way forward.

Agreed. Richard: do you have time to put something together?
I'm happy to try if you don't.

----------

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

From report at bugs.python.org  Sun Jul  1 22:58:00 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Jul 2012 20:58:00 +0000
Subject: [issue12605] Enhancements to gdb 7 debugging hooks
In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za>
Message-ID: <1341176280.88.0.0635068024791.issue12605@psf.upfronthosting.co.za>


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


----------
priority: release blocker -> normal

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

From report at bugs.python.org  Sun Jul  1 23:08:55 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Jul 2012 21:08:55 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <3WQPN43DbbzP9L@mail.python.org>


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

New changeset b4af3925bda6 by Antoine Pitrou in branch 'default':
some new t?st (issue #2771)
http://hg.python.org/test/rev/b4af3925bda6

----------

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

From report at bugs.python.org  Sun Jul  1 23:18:54 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Jul 2012 21:18:54 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <3WQPbc6lzSzPJH@mail.python.org>


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

New changeset 3e4513003ded by Antoine Pitrou in branch 'default':
some new t?st (issue #2771)
http://hg.python.org/test/rev/3e4513003ded

New changeset b449118653fe by Antoine Pitrou in branch 'default':
some new t?st (issue #2771)
http://hg.python.org/test/rev/b449118653fe

New changeset 99fbc7dfb076 by Antoine Pitrou in branch 'default':
some new t?st (issue #2771)
http://hg.python.org/test/rev/99fbc7dfb076

New changeset b4af3925bda6 by Antoine Pitrou in branch 'default':
some new t?st (issue #2771)
http://hg.python.org/test/rev/b4af3925bda6

New changeset 76da38684c9d by Antoine Pitrou in branch 'default':
some other test (issue #2771)
http://hg.python.org/test/rev/76da38684c9d

----------

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

From report at bugs.python.org  Sun Jul  1 23:26:19 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 01 Jul 2012 21:26:19 +0000
Subject: [issue15236] SEGFAULT in visit_decref
In-Reply-To: <1341135983.73.0.665812827799.issue15236@psf.upfronthosting.co.za>
Message-ID: <1341177979.71.0.0477822447949.issue15236@psf.upfronthosting.co.za>


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

Yes, some INCREF may be missing.  The issue may be with the callback mechanism; these are usually difficult to get right.

Actually by pure luck I found suspect code that may be the cause of this crash:
in src/event/listener_python.cc, the "Args" tuple is first allocated, but item #1 is not set.  It's a bit wrong (try to print it!) but if does not leak outside, it won't probably crash here; gc traverse function luckily skips NULL pointers.
BUT in raise_event(), this Args[1] is set to an event object, which is DECREF'd afterwards.  The pointer now points to invalid memory, and next gc.collect() will crash...

I also found other issues with reference counting here and there (ex: in src/python/python.cc, PyTuple_SET_ITEM (new_tuple, i, Py_None) steals one reference to Py_None each time!)

There are many bugs in this application to fix before we can impute CPython.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Mon Jul  2 00:02:54 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Jul 2012 22:02:54 +0000
Subject: [issue15212] Rename SC_GLOBAL_EXPLICT to SC_GLOBAL_EXPLICIT in
	compiler module
In-Reply-To: <1340844073.78.0.438515570461.issue15212@psf.upfronthosting.co.za>
Message-ID: <3WQQZP0y8nzPHN@mail.python.org>


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

New changeset 55130516d1d2 by Antoine Pitrou in branch '2.7':
Issue #15212: fix typo in compiler module (rename SC_GLOBAL_EXPLICT to SC_GLOBAL_EXPLICIT).
http://hg.python.org/cpython/rev/55130516d1d2

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

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

From report at bugs.python.org  Mon Jul  2 00:04:16 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Jul 2012 22:04:16 +0000
Subject: [issue15212] Rename SC_GLOBAL_EXPLICT to SC_GLOBAL_EXPLICIT in
	compiler module
In-Reply-To: <1340844073.78.0.438515570461.issue15212@psf.upfronthosting.co.za>
Message-ID: <1341180256.35.0.163570269497.issue15212@psf.upfronthosting.co.za>


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

Thank you, fixed now.

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

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

From report at bugs.python.org  Mon Jul  2 00:46:15 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 01 Jul 2012 22:46:15 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on
	Windows
In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za>
Message-ID: <1341182775.55.0.361093237736.issue14243@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

> Agreed. Richard: do you have time to put something together?
> I'm happy to try if you don't.

I'm looking into it.

Unfortunately, it seems that you need to use non-default flags when reopening a shared file.  Eg, if the file is currently opened with SH_DENYNO and O_TEMPORARY, then you must reopen it using SH_DENYNO and O_TEMPORARY.

However, I have an initial implementation of os.sopen() which makes the following work:

  import os, tempfile

  FNAME = "foo.txt"
  DATA = "hello bob"

  def opener(name, flag, mode=0o777):
      return os.sopen(name, flag | os.O_TEMPORARY, os.SH_DENYNO, mode)

  with open(FNAME, "w", opener=opener) as f:
      f.write(DATA)
      f.flush()
      with open(FNAME, "r", opener=opener) as f:
          assert f.read() == DATA

  assert not os.path.exists(FNAME)

BTW, Maybe it would be better to add a keyword-only shareflag argument to os.open() rather than add os.sopen().

----------

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

From report at bugs.python.org  Mon Jul  2 01:45:48 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 01 Jul 2012 23:45:48 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on
	Windows
In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za>
Message-ID: <1341186348.92.0.717832797592.issue14243@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

I checked the source in

   c:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/crt/src/open.c

and it seems that on Windows open() is more or less implemented as a wrapper of sopen(..., ..., SH_DENYNO, ...).

So the only reason that trying to reopen a NamedTemporaryFile fails on Windows is because when we reopen we need to use O_TEMPORARY.

The following works for unmodified python:

  import os, tempfile

  DATA = b"hello bob"

  def temp_opener(name, flag, mode=0o777):
      return os.open(name, flag | os.O_TEMPORARY, mode)

  with tempfile.NamedTemporaryFile() as f:
      f.write(DATA)
      f.flush()
      with open(f.name, "rb", opener=temp_opener) as f:
          assert f.read() == DATA

  assert not os.path.exists(f.name)

So maybe we should just define tempfile.opener().

----------

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

From report at bugs.python.org  Mon Jul  2 02:45:21 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 02 Jul 2012 00:45:21 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on
	Windows
In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za>
Message-ID: <1341189921.43.0.515396595756.issue14243@psf.upfronthosting.co.za>


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

Alternatively, perhaps it would make sense to have a "reopen()" method on file objects that covers the necessary dance to reopen with the correct flags?

That would solve more problems than just this one (possibly including making it possible to "reopen" StringIO and BytesIO objects).

----------

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

From report at bugs.python.org  Mon Jul  2 07:39:02 2012
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Mon, 02 Jul 2012 05:39:02 +0000
Subject: [issue15178] Doctest should handle situations when test files are not
	readable
In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za>
Message-ID: <1341207542.05.0.130177193641.issue15178@psf.upfronthosting.co.za>


Bohuslav "Slavek" Kabrda <bkabrda at redhat.com> added the comment:

So maybe an optimal solution would be to add a note summarizing this to the end of output? I mean that this:

X passed and Y failed.

Could be replaced by:

X passed and Y failed, Z files were not loaded.

Then the user will know that the files were not loaded and he can search the test output for the reasons.

----------

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

From report at bugs.python.org  Mon Jul  2 08:11:15 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 Jul 2012 06:11:15 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341209475.41.0.211740748822.issue15202@psf.upfronthosting.co.za>


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

Serihy: for the "followlinks" patch, how about we plan ahead: I give you feedback for just the code (if there is any), and then I take over the patch and do the doc rewrite that I will find irresistable.

----------

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

From report at bugs.python.org  Mon Jul  2 08:48:53 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 Jul 2012 06:48:53 +0000
Subject: [issue15178] Doctest should handle situations when test files are not
	readable
In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za>
Message-ID: <1341211733.21.0.954316400072.issue15178@psf.upfronthosting.co.za>


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

I think that sounds reasonable.  The message should say files in all three cases', since the individual  test file summary method will be similar but talking about numbers of tests.

----------

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

From report at bugs.python.org  Mon Jul  2 10:53:39 2012
From: report at bugs.python.org (Tim Golden)
Date: Mon, 02 Jul 2012 08:53:39 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful
	on	Windows
In-Reply-To: <1341035137.77.0.664208977189.issue14243@psf.upfronthosting.co.za>
Message-ID: <4FF1618F.900@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

On 30/06/2012 06:45, Daniel Lenski wrote:
> My preferred solution would be to replace the binary delete argument of the current NamedTemporaryFile implementation with finer-grained options:
>    delete=False         # don't delete
>    delete=True          # delete after file closed, current behavior
>    delete=AFTER_CLOSE   # delete after file closed
>    delete=AFTER_CM_EXIT # delete after context manager exits
>    delete=AFTER_CM_EXIT_NO_EXCEPTION # delete after CM exit, unless this is due to an exception

I'm aware that Richard & others are fleshing out alternatives. But my
having asked you to propose something I wanted to come back on this
particular suggestion. I think it's just too complex an API. Not least
because, on Windows, we're making use of a filesystem feature which will
delete on closure regardless (so the implementation on Windows skips the
context-based delete).

I'm not sure what we'll end up with but I'm more inclined towards the
sort of method-based closer/reopener which is more explicit.

----------
title: tempfile.NamedTemporaryFile not particularly useful on Windows -> tempfile.NamedTemporaryFile not particularly useful on	Windows

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

From report at bugs.python.org  Mon Jul  2 12:23:57 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Jul 2012 10:23:57 +0000
Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py
In-Reply-To: <1341164449.42.0.392193036556.issue15239@psf.upfronthosting.co.za>
Message-ID: <1341224663.3264.183.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

>  If it produces different output today, we should investigate why.

Lib/stringprep.py differs from updated Tools/unicode/mkstringprep.py output only by additional entity 0x130:'i\u0307' in b3_exceptions.

In 3.2 and lower '\u0130'.lower() == '\u0069', in 3.3 '\u0130'.lower() == '\u0069\u0307'.

----------

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

From report at bugs.python.org  Mon Jul  2 13:23:59 2012
From: report at bugs.python.org (Borja Ruiz Castro)
Date: Mon, 02 Jul 2012 11:23:59 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1338429461.78.0.271322068709.issue7897@psf.upfronthosting.co.za>
Message-ID: <CAONoiAH92se6yF9gKihnr1vH1VP2coOQtt3piz2osA7Nck+4RA@mail.gmail.com>


Borja Ruiz Castro <bruiz at alienvault.com> added the comment:

Hi Murray!

I use a lot od parametrized tests. I usually use the ENV to pass these
parameters and/or a custon configuration file.

What is your approach to parametrize all the test stuff?

Regards,

Borja.

On 31 May 2012 03:57, R. David Murray <report at bugs.python.org> wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> People interested in this issue might be interested in changeset
> e6a33938b03f.  I use parameterized unit tests in email a lot, and was
> annoyed by the fact that I couldn't run the tests individually using the
> unittest CLI.  The fix for that turned out to be trivial, but by the time I
> figured it out, I'd already written most of the metaclass.  So since the
> metaclass reduces the boilerplate (albeit at the cost of looking like black
> magic), I decided to go with it.  And the metaclass at least avoids the
> rather questionable use of the "modify locals()" hack I was using before.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7897>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe:
> http://mail.python.org/mailman/options/python-bugs-list/isec%40alienvault.com
>
>

----------
nosy: +borja.ruiz

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

From report at bugs.python.org  Mon Jul  2 13:42:28 2012
From: report at bugs.python.org (Borja Ruiz Castro)
Date: Mon, 02 Jul 2012 11:42:28 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <CAONoiAH92se6yF9gKihnr1vH1VP2coOQtt3piz2osA7Nck+4RA@mail.gmail.com>
Message-ID: <CAONoiAF+GMvKzCkAiKPfzj+7+6s1u5J_i9LoDCOjxOAKQZ8s7A@mail.gmail.com>


Borja Ruiz Castro <bruiz at alienvault.com> added the comment:

Sorry, I failed to mention that I use Testify to launch all my tests!

On 2 July 2012 13:23, Borja Ruiz Castro <report at bugs.python.org> wrote:

>
> Borja Ruiz Castro <bruiz at alienvault.com> added the comment:
>
> Hi Murray!
>
> I use a lot od parametrized tests. I usually use the ENV to pass these
> parameters and/or a custon configuration file.
>
> What is your approach to parametrize all the test stuff?
>
> Regards,
>
> Borja.
>
> On 31 May 2012 03:57, R. David Murray <report at bugs.python.org> wrote:
>
> >
> > R. David Murray <rdmurray at bitdance.com> added the comment:
> >
> > People interested in this issue might be interested in changeset
> > e6a33938b03f.  I use parameterized unit tests in email a lot, and was
> > annoyed by the fact that I couldn't run the tests individually using the
> > unittest CLI.  The fix for that turned out to be trivial, but by the
> time I
> > figured it out, I'd already written most of the metaclass.  So since the
> > metaclass reduces the boilerplate (albeit at the cost of looking like
> black
> > magic), I decided to go with it.  And the metaclass at least avoids the
> > rather questionable use of the "modify locals()" hack I was using before.
> >
> > ----------
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <http://bugs.python.org/issue7897>
> > _______________________________________
> > _______________________________________________
> > Python-bugs-list mailing list
> > Unsubscribe:
> >
> http://mail.python.org/mailman/options/python-bugs-list/isec%40alienvault.com
> >
> >
>
> ----------
> nosy: +borja.ruiz
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7897>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Jul  2 14:33:33 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 02 Jul 2012 12:33:33 +0000
Subject: [issue15223] datetime instances lack __module__ attribute
In-Reply-To: <1340985927.81.0.282972335734.issue15223@psf.upfronthosting.co.za>
Message-ID: <1341232413.9.0.680141220561.issue15223@psf.upfronthosting.co.za>


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

In PyPy, datetime.py is a pure Python module (similar to the one in 3.x, but without the _datetime acceleration module).  So comparison with CPython is not relevant here.

In CPython, __module__ is not an attribute of the type, but a property: it is defined in the 'type' object.  The situation is similar to the following script (2.x syntax); the "foo" attribute can be found on the class, but not on instances of the class.

class Type(type):
    foo = 42
class Datetime:
    __metaclass__ = Type
print Datetime.foo
print Datetime().foo

This is a good thing sometimes: for example 'str' has a __dict__ (containing methods) but strings don't have a __dict__ -- storage is optimized and only has an array of chars.  In this case you wouldn't want the class __dict__ be returned instead.

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Mon Jul  2 15:34:37 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 02 Jul 2012 13:34:37 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful
	on	Windows
In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za>
Message-ID: <1341236077.02.0.845745751602.issue14243@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

I wrote in an earlier message that a file opened with O_TEMPORARY must be reopened with O_TEMPORARY.  This is not quite accurate.

Using O_TEMPORARY causes the FILE_SHARE_DELETE sharing mode to be used, and a file currently opened with FILE_SHARE_DELETE can only be reopened with FILE_SHARE_DELETE.

Unfortunately using O_TEMPORARY is the only way allowed by msvcrt to get FILE_SHARE_DELETE, even though it also has the orthogonal effect of unlinking the file when all handles are closed.

The nice thing about FILE_SHARE_DELETE is that it gives Unix-like behaviour: the file can be renamed or deleted while you have an open handle, and you can still continue to use the handle.

Attached is a mostly untested attempt at writing replacements for open() and os.open() which use the FILE_SHARE_DELETE sharing mode.  Among other things, these can be used for reopening temporary files.

Even if tempfile does not use make use of this, I think something similar would be useful in the stdlib.

----------
Added file: http://bugs.python.org/file26229/share.py

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

From report at bugs.python.org  Mon Jul  2 16:10:12 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 Jul 2012 14:10:12 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341238212.53.0.779754229418.issue15202@psf.upfronthosting.co.za>


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

Storchaka: change of plan.  Since doc changes are much lower risk than code changes, how about we go with your existing patch and I'll fix up the docs separately.

So, please make the relevant code changes I proposed on Rietveld (adding "*," everywhere was it iirc) and resubmit and we can get that in.  I'll give you a code-only review of the other patch too--I'll start on that now.

----------

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

From report at bugs.python.org  Mon Jul  2 16:24:42 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 Jul 2012 14:24:42 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341239082.17.0.116906098643.issue15233@psf.upfronthosting.co.za>


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

Here's a patch.  I read the implementation to find out what it does, then documented it.  Happily it does the sane thing.

----------
keywords: +patch
Added file: http://bugs.python.org/file26230/larry.atexit.1.diff

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

From report at bugs.python.org  Mon Jul  2 16:30:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Jul 2012 14:30:22 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341239082.17.0.116906098643.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341239354.3368.1.camel@localhost.localdomain>


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

> Here's a patch.  I read the implementation to find out what it does,
> then documented it.  Happily it does the sane thing.

Is it tested for?

----------

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

From report at bugs.python.org  Mon Jul  2 17:16:29 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Jul 2012 15:16:29 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1341238212.53.0.779754229418.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341242199.3264.192.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> So, please make the relevant code changes I proposed on Rietveld (adding "*," everywhere was it iirc) and resubmit and we can get that in.  I'll give you a code-only review of the other patch too--I'll start on that now.

Here is a changed patches.

Personally, I doubt that followlinks-to-follow_symlinks-4.patch is
better than followlinks-to-follow_symlinks-3.patch. Also my concern is
the incompatibility of the arguments of os.walk and os.fwalk.

----------
Added file: http://bugs.python.org/file26231/followlinks-to-follow_symlinks-4.patch
Added file: http://bugs.python.org/file26232/symlinks-to-follow_symlinks-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15202>
_______________________________________
-------------- next part --------------
diff -r a1c8302e6b27 Doc/library/os.rst
--- a/Doc/library/os.rst	Sun Jul 01 12:24:20 2012 +0200
+++ b/Doc/library/os.rst	Mon Jul 02 18:07:59 2012 +0300
@@ -2211,7 +2211,7 @@
               os.rmdir(os.path.join(root, name))
 
 
-.. function:: fwalk(top='.', topdown=True, onerror=None, followlinks=False, *, dir_fd=None)
+.. function:: fwalk(top='.', topdown=True, onerror=None, *, follow_symlinks=False, dir_fd=None)
 
    .. index::
       single: directory; walking
diff -r a1c8302e6b27 Lib/os.py
--- a/Lib/os.py	Sun Jul 01 12:24:20 2012 +0200
+++ b/Lib/os.py	Mon Jul 02 18:07:59 2012 +0300
@@ -424,7 +424,7 @@
 
 if {open, stat} <= supports_dir_fd and {listdir, stat} <= supports_fd:
 
-    def fwalk(top=".", topdown=True, onerror=None, followlinks=False, *, dir_fd=None):
+    def fwalk(top=".", topdown=True, onerror=None, *, follow_symlinks=False, dir_fd=None):
         """Directory tree generator.
 
         This behaves exactly like walk(), except that it yields a 4-tuple
@@ -435,7 +435,7 @@
         and `dirfd` is a file descriptor referring to the directory `dirpath`.
 
         The advantage of fwalk() over walk() is that it's safe against symlink
-        races (when followlinks is False).
+        races (when follow_symlinks is False).
 
         If dir_fd is not None, it should be a file descriptor open to a directory,
           and top should be relative; top will then be relative to that directory.
@@ -462,13 +462,13 @@
         orig_st = stat(top, follow_symlinks=False, dir_fd=dir_fd)
         topfd = open(top, O_RDONLY, dir_fd=dir_fd)
         try:
-            if (followlinks or (st.S_ISDIR(orig_st.st_mode) and
-                                path.samestat(orig_st, stat(topfd)))):
-                yield from _fwalk(topfd, top, topdown, onerror, followlinks)
+            if (follow_symlinks or (st.S_ISDIR(orig_st.st_mode) and
+                                    path.samestat(orig_st, stat(topfd)))):
+                yield from _fwalk(topfd, top, topdown, onerror, follow_symlinks)
         finally:
             close(topfd)
 
-    def _fwalk(topfd, toppath, topdown, onerror, followlinks):
+    def _fwalk(topfd, toppath, topdown, onerror, follow_symlinks):
         # Note: This uses O(depth of the directory tree) file descriptors: if
         # necessary, it can be adapted to only require O(1) FDs, see issue
         # #13734.
@@ -499,16 +499,16 @@
 
         for name in dirs:
             try:
-                orig_st = stat(name, dir_fd=topfd, follow_symlinks=followlinks)
+                orig_st = stat(name, dir_fd=topfd, follow_symlinks=follow_symlinks)
                 dirfd = open(name, O_RDONLY, dir_fd=topfd)
             except error as err:
                 if onerror is not None:
                     onerror(err)
                 return
             try:
-                if followlinks or path.samestat(orig_st, stat(dirfd)):
+                if follow_symlinks or path.samestat(orig_st, stat(dirfd)):
                     dirpath = path.join(toppath, name)
-                    yield from _fwalk(dirfd, dirpath, topdown, onerror, followlinks)
+                    yield from _fwalk(dirfd, dirpath, topdown, onerror, follow_symlinks)
             finally:
                 close(dirfd)
 
diff -r a1c8302e6b27 Lib/test/test_os.py
--- a/Lib/test/test_os.py	Sun Jul 01 12:24:20 2012 +0200
+++ b/Lib/test/test_os.py	Mon Jul 02 18:07:59 2012 +0300
@@ -745,10 +745,11 @@
         """
         compare with walk() results.
         """
-        for topdown, followlinks in itertools.product((True, False), repeat=2):
-            d = {'topdown': topdown, 'followlinks': followlinks}
-            walk_kwargs.update(d)
-            fwalk_kwargs.update(d)
+        walk_kwargs = walk_kwargs.copy()
+        fwalk_kwargs = fwalk_kwargs.copy()
+        for topdown, follow_symlinks in itertools.product((True, False), repeat=2):
+            walk_kwargs.update(topdown=topdown, followlinks=follow_symlinks)
+            fwalk_kwargs.update(topdown=topdown, follow_symlinks=follow_symlinks)
 
             expected = {}
             for root, dirs, files in os.walk(**walk_kwargs):
@@ -774,9 +775,9 @@
 
     def test_yields_correct_dir_fd(self):
         # check returned file descriptors
-        for topdown, followlinks in itertools.product((True, False), repeat=2):
-            args = support.TESTFN, topdown, None, followlinks
-            for root, dirs, files, rootfd in os.fwalk(*args):
+        for topdown, follow_symlinks in itertools.product((True, False), repeat=2):
+            args = support.TESTFN, topdown, None
+            for root, dirs, files, rootfd in os.fwalk(*args, follow_symlinks=follow_symlinks):
                 # check that the FD is valid
                 os.fstat(rootfd)
                 # redundant check
-------------- next part --------------
diff -r a1c8302e6b27 Doc/library/shutil.rst
--- a/Doc/library/shutil.rst	Sun Jul 01 12:24:20 2012 +0200
+++ b/Doc/library/shutil.rst	Mon Jul 02 17:57:45 2012 +0300
@@ -47,7 +47,7 @@
    be copied.
 
 
-.. function:: copyfile(src, dst, symlinks=False)
+.. function:: copyfile(src, dst, *, symlinks=False)
 
    Copy the contents (no metadata) of the file named *src* to a file named
    *dst* and return *dst*.  *dst* must be the complete target file name; look at
@@ -69,7 +69,7 @@
    .. versionchanged:: 3.3
       Added return of the *dst*.
 
-.. function:: copymode(src, dst, symlinks=False)
+.. function:: copymode(src, dst, *, symlinks=False)
 
    Copy the permission bits from *src* to *dst*.  The file contents, owner, and
    group are unaffected.  *src* and *dst* are path names given as strings.  If
@@ -80,7 +80,7 @@
    .. versionchanged:: 3.3
       Added *symlinks* argument.
 
-.. function:: copystat(src, dst, symlinks=False)
+.. function:: copystat(src, dst, *, symlinks=False)
 
    Copy the permission bits, last access time, last modification time, and flags
    from *src* to *dst*.  The file contents, owner, and group are unaffected.  *src*
@@ -91,7 +91,7 @@
    .. versionchanged:: 3.3
       Added *symlinks* argument.
 
-.. function:: copy(src, dst, symlinks=False)
+.. function:: copy(src, dst, *, symlinks=False)
 
    Copy the file *src* to the file or directory *dst* and return the file's
    destination.  If *dst* is a directory, a
@@ -106,7 +106,7 @@
    .. versionchanged:: 3.3
       Added return of the *dst*.
 
-.. function:: copy2(src, dst, symlinks=False)
+.. function:: copy2(src, dst, *, symlinks=False)
 
    Similar to :func:`shutil.copy`, including that the destination is
    returned, but metadata is copied as well. This is
diff -r a1c8302e6b27 Lib/shutil.py
--- a/Lib/shutil.py	Sun Jul 01 12:24:20 2012 +0200
+++ b/Lib/shutil.py	Mon Jul 02 17:57:45 2012 +0300
@@ -82,10 +82,10 @@
     return (os.path.normcase(os.path.abspath(src)) ==
             os.path.normcase(os.path.abspath(dst)))
 
-def copyfile(src, dst, symlinks=False):
+def copyfile(src, dst, *, follow_symlinks=True):
     """Copy data from src to dst.
 
-    If optional flag `symlinks` is set and `src` is a symbolic link, a new
+    If optional flag `follow_symlinks` is not set and `src` is a symbolic link, a new
     symlink will be created instead of copying the file it points to.
 
     """
@@ -103,7 +103,7 @@
             if stat.S_ISFIFO(st.st_mode):
                 raise SpecialFileError("`%s` is a named pipe" % fn)
 
-    if symlinks and os.path.islink(src):
+    if not follow_symlinks and os.path.islink(src):
         os.symlink(os.readlink(src), dst)
     else:
         with open(src, 'rb') as fsrc:
@@ -111,15 +111,15 @@
                 copyfileobj(fsrc, fdst)
     return dst
 
-def copymode(src, dst, symlinks=False):
+def copymode(src, dst, *, follow_symlinks=True):
     """Copy mode bits from src to dst.
 
-    If the optional flag `symlinks` is set, symlinks aren't followed if and
+    If the optional flag `follow_symlinks` is not set, symlinks aren't followed if and
     only if both `src` and `dst` are symlinks. If `lchmod` isn't available (eg.
     Linux), in these cases, this method does nothing.
 
     """
-    if symlinks and os.path.islink(src) and os.path.islink(dst):
+    if not follow_symlinks and os.path.islink(src) and os.path.islink(dst):
         if hasattr(os, 'lchmod'):
             stat_func, chmod_func = os.lstat, os.lchmod
         else:
@@ -132,10 +132,10 @@
     st = stat_func(src)
     chmod_func(dst, stat.S_IMODE(st.st_mode))
 
-def copystat(src, dst, symlinks=False):
+def copystat(src, dst, *, follow_symlinks=True):
     """Copy all stat info (mode bits, atime, mtime, flags) from src to dst.
 
-    If the optional flag `symlinks` is set, symlinks aren't followed if and
+    If the optional flag `follow_symlinks` is not set, symlinks aren't followed if and
     only if both `src` and `dst` are symlinks.
 
     """
@@ -143,7 +143,7 @@
         pass
 
     # follow symlinks (aka don't not follow symlinks)
-    follow = not (symlinks and os.path.islink(src) and os.path.islink(dst))
+    follow = follow_symlinks or not (os.path.islink(src) and os.path.islink(dst))
     if follow:
         # use the real function if it exists
         def lookup(name):
@@ -186,19 +186,19 @@
                 raise
 
 if hasattr(os, 'listxattr'):
-    def _copyxattr(src, dst, symlinks=False):
+    def _copyxattr(src, dst, *, follow_symlinks=True):
         """Copy extended filesystem attributes from `src` to `dst`.
 
         Overwrite existing attributes.
 
-        If the optional flag `symlinks` is set, symlinks won't be followed.
+        If the optional flag `follow_symlinks` is not set, symlinks won't be followed.
 
         """
 
-        for name in os.listxattr(src, follow_symlinks=symlinks):
+        for name in os.listxattr(src, follow_symlinks=follow_symlinks):
             try:
-                value = os.getxattr(src, name, follow_symlinks=symlinks)
-                os.setxattr(dst, name, value, follow_symlinks=symlinks)
+                value = os.getxattr(src, name, follow_symlinks=follow_symlinks)
+                os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
             except OSError as e:
                 if e.errno not in (errno.EPERM, errno.ENOTSUP, errno.ENODATA):
                     raise
@@ -206,36 +206,36 @@
     def _copyxattr(*args, **kwargs):
         pass
 
-def copy(src, dst, symlinks=False):
+def copy(src, dst, *, follow_symlinks=True):
     """Copy data and mode bits ("cp src dst"). Return the file's destination.
 
     The destination may be a directory.
 
-    If the optional flag `symlinks` is set, symlinks won't be followed. This
+    If the optional flag `follow_symlinks` is not set, symlinks won't be followed. This
     resembles GNU's "cp -P src dst".
 
     """
     if os.path.isdir(dst):
         dst = os.path.join(dst, os.path.basename(src))
-    copyfile(src, dst, symlinks=symlinks)
-    copymode(src, dst, symlinks=symlinks)
+    copyfile(src, dst, follow_symlinks=follow_symlinks)
+    copymode(src, dst, follow_symlinks=follow_symlinks)
     return dst
 
-def copy2(src, dst, symlinks=False):
+def copy2(src, dst, *, follow_symlinks=True):
     """Copy data and all stat info ("cp -p src dst"). Return the file's
     destination."
 
     The destination may be a directory.
 
-    If the optional flag `symlinks` is set, symlinks won't be followed. This
+    If the optional flag `follow_symlinks` is not set, symlinks won't be followed. This
     resembles GNU's "cp -P src dst".
 
     """
     if os.path.isdir(dst):
         dst = os.path.join(dst, os.path.basename(src))
-    copyfile(src, dst, symlinks=symlinks)
-    copystat(src, dst, symlinks=symlinks)
-    _copyxattr(src, dst, symlinks=symlinks)
+    copyfile(src, dst, follow_symlinks=follow_symlinks)
+    copystat(src, dst, follow_symlinks=follow_symlinks)
+    _copyxattr(src, dst, follow_symlinks=follow_symlinks)
     return dst
 
 def ignore_patterns(*patterns):
@@ -307,7 +307,7 @@
                     # code with a custom `copy_function` may rely on copytree
                     # doing the right thing.
                     os.symlink(linkto, dstname)
-                    copystat(srcname, dstname, symlinks=symlinks)
+                    copystat(srcname, dstname, follow_symlinks=not symlinks)
                 else:
                     # ignore dangling symlink if the flag is on
                     if not os.path.exists(linkto) and ignore_dangling_symlinks:
diff -r a1c8302e6b27 Lib/test/test_shutil.py
--- a/Lib/test/test_shutil.py	Sun Jul 01 12:24:20 2012 +0200
+++ b/Lib/test/test_shutil.py	Mon Jul 02 17:57:45 2012 +0300
@@ -277,17 +277,17 @@
         os.lchmod(src_link, stat.S_IRWXO|stat.S_IRWXG)
         # link to link
         os.lchmod(dst_link, stat.S_IRWXO)
-        shutil.copymode(src_link, dst_link, symlinks=True)
+        shutil.copymode(src_link, dst_link, follow_symlinks=False)
         self.assertEqual(os.lstat(src_link).st_mode,
                          os.lstat(dst_link).st_mode)
         self.assertNotEqual(os.stat(src).st_mode, os.stat(dst).st_mode)
         # src link - use chmod
         os.lchmod(dst_link, stat.S_IRWXO)
-        shutil.copymode(src_link, dst, symlinks=True)
+        shutil.copymode(src_link, dst, follow_symlinks=False)
         self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode)
         # dst link - use chmod
         os.lchmod(dst_link, stat.S_IRWXO)
-        shutil.copymode(src, dst_link, symlinks=True)
+        shutil.copymode(src, dst_link, follow_symlinks=False)
         self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode)
 
     @unittest.skipIf(hasattr(os, 'lchmod'), 'requires os.lchmod to be missing')
@@ -302,7 +302,7 @@
         write_file(dst, 'foo')
         os.symlink(src, src_link)
         os.symlink(dst, dst_link)
-        shutil.copymode(src_link, dst_link, symlinks=True)  # silent fail
+        shutil.copymode(src_link, dst_link, follow_symlinks=False)  # silent fail
 
     @support.skip_unless_symlink
     def test_copystat_symlinks(self):
@@ -326,10 +326,10 @@
         src_link_stat = os.lstat(src_link)
         # follow
         if hasattr(os, 'lchmod'):
-            shutil.copystat(src_link, dst_link, symlinks=False)
+            shutil.copystat(src_link, dst_link, follow_symlinks=True)
             self.assertNotEqual(src_link_stat.st_mode, os.stat(dst).st_mode)
         # don't follow
-        shutil.copystat(src_link, dst_link, symlinks=True)
+        shutil.copystat(src_link, dst_link, follow_symlinks=False)
         dst_link_stat = os.lstat(dst_link)
         if os.utime in os.supports_follow_symlinks:
             for attr in 'st_atime', 'st_mtime':
@@ -341,7 +341,7 @@
         if hasattr(os, 'lchflags') and hasattr(src_link_stat, 'st_flags'):
             self.assertEqual(src_link_stat.st_flags, dst_link_stat.st_flags)
         # tell to follow but dst is not a link
-        shutil.copystat(src_link, dst, symlinks=True)
+        shutil.copystat(src_link, dst, follow_symlinks=False)
         self.assertTrue(abs(os.stat(src).st_mtime - os.stat(dst).st_mtime) <
                         00000.1)
 
@@ -429,10 +429,10 @@
         dst_link = os.path.join(tmp_dir, 'qux')
         write_file(dst, 'bar')
         os.symlink(dst, dst_link)
-        shutil._copyxattr(src_link, dst_link, symlinks=True)
+        shutil._copyxattr(src_link, dst_link, follow_symlinks=False)
         self.assertEqual(os.getxattr(dst_link, 'trusted.foo', follow_symlinks=False), b'43')
         self.assertRaises(OSError, os.getxattr, dst, 'trusted.foo')
-        shutil._copyxattr(src_link, dst, symlinks=True)
+        shutil._copyxattr(src_link, dst, follow_symlinks=False)
         self.assertEqual(os.getxattr(dst, 'trusted.foo'), b'43')
 
     @support.skip_unless_symlink
@@ -446,12 +446,12 @@
         if hasattr(os, 'lchmod'):
             os.lchmod(src_link, stat.S_IRWXU | stat.S_IRWXO)
         # don't follow
-        shutil.copy(src_link, dst, symlinks=False)
+        shutil.copy(src_link, dst, follow_symlinks=True)
         self.assertFalse(os.path.islink(dst))
         self.assertEqual(read_file(src), read_file(dst))
         os.remove(dst)
         # follow
-        shutil.copy(src_link, dst, symlinks=True)
+        shutil.copy(src_link, dst, follow_symlinks=False)
         self.assertTrue(os.path.islink(dst))
         self.assertEqual(os.readlink(dst), os.readlink(src_link))
         if hasattr(os, 'lchmod'):
@@ -473,12 +473,12 @@
         src_stat = os.stat(src)
         src_link_stat = os.lstat(src_link)
         # follow
-        shutil.copy2(src_link, dst, symlinks=False)
+        shutil.copy2(src_link, dst, follow_symlinks=True)
         self.assertFalse(os.path.islink(dst))
         self.assertEqual(read_file(src), read_file(dst))
         os.remove(dst)
         # don't follow
-        shutil.copy2(src_link, dst, symlinks=True)
+        shutil.copy2(src_link, dst, follow_symlinks=False)
         self.assertTrue(os.path.islink(dst))
         self.assertEqual(os.readlink(dst), os.readlink(src_link))
         dst_stat = os.lstat(dst)
@@ -516,7 +516,7 @@
         write_file(src, 'foo')
         os.symlink(src, link)
         # don't follow
-        shutil.copyfile(link, dst_link, symlinks=True)
+        shutil.copyfile(link, dst_link, follow_symlinks=False)
         self.assertTrue(os.path.islink(dst_link))
         self.assertEqual(os.readlink(link), os.readlink(dst_link))
         # follow

From report at bugs.python.org  Mon Jul  2 17:20:49 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Jul 2012 15:20:49 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341242449.4.0.0963973460768.issue15202@psf.upfronthosting.co.za>


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

What's the urge to make parameters keyword-only?
Also, copyfile() shouldn't change signature.

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Jul  2 17:38:51 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Jul 2012 15:38:51 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341243531.11.0.797903464448.issue15202@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file26232/symlinks-to-follow_symlinks-4.patch

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

From report at bugs.python.org  Mon Jul  2 17:43:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Jul 2012 15:43:45 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341243825.63.0.788557467692.issue15202@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26233/symlinks-to-follow_symlinks-4.patch

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

From report at bugs.python.org  Mon Jul  2 17:49:34 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Jul 2012 15:49:34 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1341242449.4.0.0963973460768.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341244192.3264.196.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> What's the urge to make parameters keyword-only?

If anyone uses these functions with a new "symlinks" parameter in 3.3b1,
he will get loud error (follow_symlinks == not symlinks).

> Also, copyfile() shouldn't change signature.

Why not?

----------

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

From report at bugs.python.org  Mon Jul  2 17:52:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Jul 2012 15:52:46 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341244366.83.0.050611006793.issue15202@psf.upfronthosting.co.za>


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

> > Also, copyfile() shouldn't change signature.

> Why not?

Seems like I have misread the docs. Apparently the symlinks parameter was added in 3.3.

----------

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

From report at bugs.python.org  Mon Jul  2 20:33:04 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 02 Jul 2012 18:33:04 +0000
Subject: [issue15122] Add an option to always rewrite single-file mailboxes
	in-place.
In-Reply-To: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za>
Message-ID: <1341253984.92.0.0787811295524.issue15122@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

This might be the only way to fix #1599254, see http://bugs.python.org/issue1599254#msg30590. If another program is waiting on the fcntl lock (and doesn't use dotlocking), as soon as mailbox.py closes the original file (to replace it with a new file) and releases the lock, the other program writes its message to the now deleted original file.

----------

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

From report at bugs.python.org  Mon Jul  2 20:39:16 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Jul 2012 18:39:16 +0000
Subject: [issue15030] PyPycLoader can't read cached .pyc files
In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za>
Message-ID: <1341254356.76.0.356198453222.issue15030@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Changeset b7463ec1980c has the fix and test update (went with a simple solution for the tests which uses the mock to verify). Thanks to Ronan and Marc for helping out!

----------
dependencies:  -Split .pyc parsing from module loading
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Jul  2 20:53:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Jul 2012 18:53:14 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>
Message-ID: <3WQyK53K14zP7Z@mail.python.org>


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

New changeset 818db871d29a by Brett Cannon in branch 'default':
Issue #15210: If _frozen_importlib is not found in sys.modules by
http://hg.python.org/cpython/rev/818db871d29a

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

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

From report at bugs.python.org  Mon Jul  2 20:53:40 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Jul 2012 18:53:40 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>
Message-ID: <1341255220.01.0.963032822211.issue15210@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jul  2 20:58:22 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Jul 2012 18:58:22 +0000
Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError
	when cache tag not available
In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za>
Message-ID: <1341255502.41.0.475172052273.issue15056@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Implement imp.get_tag() using sys.implementation

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

From report at bugs.python.org  Mon Jul  2 21:10:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 19:10:52 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341256252.69.0.270896506924.issue15233@psf.upfronthosting.co.za>


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

See #9788 for previous discussion.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Mon Jul  2 21:13:18 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Jul 2012 19:13:18 +0000
Subject: [issue15166] Implement imp.get_tag() using sys.implementation
In-Reply-To: <1340567412.76.0.552732396402.issue15166@psf.upfronthosting.co.za>
Message-ID: <3WQymD6CttzNC6@mail.python.org>


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

New changeset b36bed82c9d0 by Brett Cannon in branch 'default':
Issue #15166: Re-implement imp.get_tag() using sys.implementation.
http://hg.python.org/cpython/rev/b36bed82c9d0

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

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

From report at bugs.python.org  Mon Jul  2 21:15:48 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Jul 2012 19:15:48 +0000
Subject: [issue15166] Implement imp.get_tag() using sys.implementation
In-Reply-To: <1340567412.76.0.552732396402.issue15166@psf.upfronthosting.co.za>
Message-ID: <1341256548.33.0.460981608336.issue15166@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I ended up applying Eric's patch from #14797 and then comparing against Jeff's patch here since Eric's cleaned up the C code. Thanks to both for the work!

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

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

From report at bugs.python.org  Mon Jul  2 21:16:34 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Jul 2012 19:16:34 +0000
Subject: [issue15166] Implement imp.get_tag() using sys.implementation
In-Reply-To: <1340567412.76.0.552732396402.issue15166@psf.upfronthosting.co.za>
Message-ID: <1341256594.54.0.145275436967.issue15166@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I meant issue #13959 for Eric's patch; wrong tab. =)

----------

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

From report at bugs.python.org  Mon Jul  2 21:24:13 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Jul 2012 19:24:13 +0000
Subject: [issue2345] Using an exception variable outside an 'except' clause
	should raise a Py3K warning
In-Reply-To: <1205778549.05.0.340690581025.issue2345@psf.upfronthosting.co.za>
Message-ID: <1341257053.92.0.978094817245.issue2345@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Mon Jul  2 21:24:20 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Jul 2012 19:24:20 +0000
Subject: [issue2345] Using an exception variable outside an 'except' clause
	should raise a Py3K warning
In-Reply-To: <1205778549.05.0.340690581025.issue2345@psf.upfronthosting.co.za>
Message-ID: <1341257060.94.0.888732931802.issue2345@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution: out of date -> wont fix

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

From report at bugs.python.org  Mon Jul  2 21:25:13 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Jul 2012 19:25:13 +0000
Subject: [issue4011] Create DAG for PEP 101
In-Reply-To: <1222896665.95.0.381960877122.issue4011@psf.upfronthosting.co.za>
Message-ID: <1341257113.76.0.225426221045.issue4011@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Is this still worth doing, Georg? Or should we make Larry do it? =)

----------
nosy: +larry

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

From report at bugs.python.org  Mon Jul  2 21:26:27 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Jul 2012 19:26:27 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1341257187.26.0.724179423509.issue2876@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Closing since 2.7 is already out the door.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Mon Jul  2 21:28:51 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Jul 2012 19:28:51 +0000
Subject: [issue14070] Idea: Add a flag to reload from source,
	e.g. reload(module, ignore_pyc=True)
In-Reply-To: <1329793221.07.0.0985593378146.issue14070@psf.upfronthosting.co.za>
Message-ID: <1341257331.92.0.169013770695.issue14070@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Never heard back from OP.

----------
resolution:  -> works for me
status: pending -> closed

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

From report at bugs.python.org  Mon Jul  2 21:29:08 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Jul 2012 19:29:08 +0000
Subject: [issue11207] Pythong seg fault with PIL/numpy
In-Reply-To: <1297634163.23.0.527834418081.issue11207@psf.upfronthosting.co.za>
Message-ID: <1341257348.95.0.595817912604.issue11207@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
status: pending -> closed

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

From report at bugs.python.org  Mon Jul  2 21:29:42 2012
From: report at bugs.python.org (Vincent Pelletier)
Date: Mon, 02 Jul 2012 19:29:42 +0000
Subject: [issue15240] ctype Structure keeps reference to function pointers
Message-ID: <1341257382.75.0.880502955632.issue15240@psf.upfronthosting.co.za>


New submission from Vincent Pelletier <plr.vincent at gmail.com>:

When storing a ctype function pointer in a ctype structure field, a reference remains even when that field is overwritten with some values:
- None
- None cast into a function pointer
But the reference is somehow removed when overwriting the field with a "real" function pointer (a lambda in attached test case).

This causes problem when the structure is a class property and function pointer is created out of a method of the same class: a circular reference is created, which is not garbage-collected.

To run the attached test case, you need objgraph[1], and to uncomment one (or none) of the commented-out lines in "close" method.

[1] http://mg.pov.lt/objgraph/

----------
components: ctypes
files: reproduce.py
messages: 164534
nosy: vpelletier
priority: normal
severity: normal
status: open
title: ctype Structure keeps reference to function pointers
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file26234/reproduce.py

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

From report at bugs.python.org  Mon Jul  2 21:40:38 2012
From: report at bugs.python.org (Vincent Pelletier)
Date: Mon, 02 Jul 2012 19:40:38 +0000
Subject: [issue15240] ctype Structure keeps reference to function pointers
In-Reply-To: <1341257382.75.0.880502955632.issue15240@psf.upfronthosting.co.za>
Message-ID: <1341258038.16.0.484965351849.issue15240@psf.upfronthosting.co.za>


Vincent Pelletier <plr.vincent at gmail.com> added the comment:

Trying to generate a graph on several python and several uncommented lines, I see that my test case is incomplete. Time to review my copy.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Mon Jul  2 21:41:42 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 19:41:42 +0000
Subject: [issue15214] Warn against removing elements from a list (or seq)
	while iterating
In-Reply-To: <1340855093.79.0.494705749272.issue15214@psf.upfronthosting.co.za>
Message-ID: <1341258102.39.0.208627026021.issue15214@psf.upfronthosting.co.za>


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

Maybe there is a section in the documentation that could be enhanced to make readers expect this behavior?  (reference for list or tutorial)

----------
nosy: +eric.araujo
title: list.startswith() and list.remove() fails to catch consecutive items in a list. -> Warn against removing elements from a list (or seq) while iterating

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

From report at bugs.python.org  Mon Jul  2 21:46:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 19:46:07 +0000
Subject: [issue15163] pydoc displays __loader__ as module data
In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za>
Message-ID: <1341258367.29.0.537057577796.issue15163@psf.upfronthosting.co.za>


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

Attached patch does the trick.  (Also removes extra whitespace in three lines and groups the ignored names by topic for ease of reading.)

No test fails before or after the patch; there are some pydoc tests that check full text or HTML output, but apparently none that triggers the appearance of of __loader__ in the module data section.  If someone thinks such a test is needed, please complete my patch, otherwise I can commit it.

----------
keywords: +patch
nosy: +eric.araujo
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26235/pydoc-ignore-__loader__.diff

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

From report at bugs.python.org  Mon Jul  2 21:51:09 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 19:51:09 +0000
Subject: [issue15180] Cryptic traceback from os.path.join when mixing str &
	bytes
In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za>
Message-ID: <1341258669.44.0.103141030132.issue15180@psf.upfronthosting.co.za>


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

> This strikes me as a bugfix that does not get backported because code might depend on
> the bug. If the policy for exception messages, such as it is, documented somewhere?

I don?t know if it?s written anywhere, but the rule I follow is that even though exact error messages are not specified by the Python language, they should not be changed in bugfix releases (I seem to remember bugs for argparse and tarfile where this was invoked).  The commit policy seems in flux these days however, with code cleanups going in stable versions (urllib and collections recently).

----------
nosy: +eric.araujo, georg.brandl, r.david.murray

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

From report at bugs.python.org  Mon Jul  2 21:51:32 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Jul 2012 19:51:32 +0000
Subject: [issue15163] pydoc displays __loader__ as module data
In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za>
Message-ID: <1341258692.37.0.0374406490711.issue15163@psf.upfronthosting.co.za>


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

Looks good to me.

----------

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

From report at bugs.python.org  Mon Jul  2 21:51:59 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 02 Jul 2012 19:51:59 +0000
Subject: [issue15240] ctype Structure keeps reference to function pointers
In-Reply-To: <1341257382.75.0.880502955632.issue15240@psf.upfronthosting.co.za>
Message-ID: <1341258719.2.0.185025574456.issue15240@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/issue15240>
_______________________________________

From report at bugs.python.org  Mon Jul  2 21:53:14 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Jul 2012 19:53:14 +0000
Subject: [issue15180] Cryptic traceback from os.path.join when mixing str &
	bytes
In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za>
Message-ID: <1341258794.44.0.447622893113.issue15180@psf.upfronthosting.co.za>


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

> If the policy for exception messages, such as it is, documented
> somewhere?

I think we are quite free to change exception messages, as long as the change is motivated. They are not part of the API definitions, and people shouldn't rely on them (the exception may for KeyError and such exceptions where the message is actually the value of the failed key).

----------

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

From report at bugs.python.org  Mon Jul  2 22:13:36 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:13:36 +0000
Subject: [issue15180] Cryptic traceback from os.path.join when mixing str &
	bytes
In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za>
Message-ID: <1341260016.68.0.57310990599.issue15180@psf.upfronthosting.co.za>


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

Patch looks good.  Left some comments on Rietveld and +1 to Antoine?s note about quotes :)

----------

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

From report at bugs.python.org  Mon Jul  2 22:27:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:27:24 +0000
Subject: [issue15205] distutils dereferences symlinks on Mac OS X but not on
	Linux
In-Reply-To: <1340801621.17.0.778641533675.issue15205@psf.upfronthosting.co.za>
Message-ID: <1341260844.03.0.855309286553.issue15205@psf.upfronthosting.co.za>


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

As I said in the other bug, symlinks handling in not fully specified: some functions (like copy_file and copy_tree) have arguments to control copy/link/symlink, but the higher-level commands don?t expose that choice to the user.  At present I am not sure if having symlinks in a distribution makes sense, and if the install command (or platform-specific systems for bdists) supports it.  I am not sure what the correct behavior would be here.

(BTW the example you link to is not at all monkey-patching, but clean extension of distutils using the provided hooks. :)

----------

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

From report at bugs.python.org  Mon Jul  2 22:37:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:37:24 +0000
Subject: [issue8876] distutils should not assume that hardlinks will work
In-Reply-To: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za>
Message-ID: <1341261444.79.0.524400767305.issue8876@psf.upfronthosting.co.za>


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

AFAICT using hard links only serves to save up a little time and disk space; it seems to me that always copying would solve one or two bugs at a small cost (not so small for large projects, I don?t know).  Could this impact setup scripts?  Maybe if os.link were monkey-patched and expected to be called.  I could ask on distutils-sig.

In #15205 Ollie noted this: ?distutils2 appears to always copy instead of hardlinking resolving all of these issues?.  That would be because d2 uses shutil.copytree and distutils.util.copy_file (yes, a function from distutils1 because of some Windows issue :().

----------
assignee: tarek -> eric.araujo
nosy: +lemburg, olliewalsh, pitrou
stage:  -> needs patch
versions: +Python 3.3 -Python 3.1

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

From report at bugs.python.org  Mon Jul  2 22:41:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:41:24 +0000
Subject: [issue15205] distutils dereferences symlinks on Mac OS X but not on
	Linux
In-Reply-To: <1340801621.17.0.778641533675.issue15205@psf.upfronthosting.co.za>
Message-ID: <1341261684.66.0.9460286774.issue15205@psf.upfronthosting.co.za>


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

(Hm OK ?del os.link? is definitely a hack :)

----------

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

From report at bugs.python.org  Mon Jul  2 22:44:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:44:59 +0000
Subject: [issue8876] distutils should not assume that hardlinks will work
In-Reply-To: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za>
Message-ID: <1341261899.36.0.843213345549.issue8876@psf.upfronthosting.co.za>


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

Of course the conservative fix would be to try linking as of now and do a copy when an exception is caught, as was proposed.

FTR python.org link to the thread mentioned: http://mail.python.org/pipermail/distutils-sig/2005-August/004954.html

----------

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

From report at bugs.python.org  Mon Jul  2 22:49:10 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:49:10 +0000
Subject: [issue8876] distutils should not assume that hardlinks will work
In-Reply-To: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za>
Message-ID: <1341262150.3.0.184698106464.issue8876@psf.upfronthosting.co.za>


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

samtygier?s patch to implement the fallback-to-copy idea looks good.  Not sure if an automated test would be written, but samtygier says it was manually tested.

----------
components:  -Distutils2
keywords: +needs review
stage: needs patch -> patch review
versions:  -3rd party

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

From report at bugs.python.org  Mon Jul  2 22:51:09 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:51:09 +0000
Subject: [issue15003] make PyNamespace_New() public
In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za>
Message-ID: <1341262269.03.0.278193918723.issue15003@psf.upfronthosting.co.za>


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

Suggest closing or marking ?remind? and see if people use / request / reimplement SimpleNamespace.

----------
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Mon Jul  2 22:52:01 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:52:01 +0000
Subject: [issue15020] default value for progname in pythonrun.c should be
	python3 for Python 3
In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za>
Message-ID: <1341262321.43.0.493067484892.issue15020@psf.upfronthosting.co.za>


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

Any opposition?

----------
nosy: +benjamin.peterson, georg.brandl

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

From report at bugs.python.org  Mon Jul  2 22:52:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:52:43 +0000
Subject: [issue15020] default value for progname in pythonrun.c should be
	python3 for Python 3
In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za>
Message-ID: <1341262363.84.0.106604849957.issue15020@psf.upfronthosting.co.za>


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

Joshua: what command did you run under strace?

----------

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

From report at bugs.python.org  Mon Jul  2 22:53:15 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:53:15 +0000
Subject: [issue15033] Different exit status when using -m
In-Reply-To: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za>
Message-ID: <1341262395.17.0.610200945579.issue15033@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
stage:  -> needs patch

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

From report at bugs.python.org  Mon Jul  2 22:55:47 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Mon, 02 Jul 2012 20:55:47 +0000
Subject: [issue15030] PyPycLoader can't read cached .pyc files
In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za>
Message-ID: <1341262547.62.0.853180487527.issue15030@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

Hi Brett, can I get an ack in Misc/ACKS please (to make my Mom proud :-))? Attaching patch.

----------
Added file: http://bugs.python.org/file26236/Misc_ACKS.patch

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

From report at bugs.python.org  Mon Jul  2 22:55:55 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:55:55 +0000
Subject: [issue14978] distutils Extension fails to be created with unicode
	package names
In-Reply-To: <1338545385.38.0.440171490662.issue14978@psf.upfronthosting.co.za>
Message-ID: <1341262555.18.0.46368510078.issue14978@psf.upfronthosting.co.za>


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

Thanks for the report and patch.  Would you mind turning it into a patch for the CPython 2.7 repository, with a unit test?  Guidelines are in the devguide; if you don?t have the time I?ll take it over.

----------
stage:  -> test needed

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

From report at bugs.python.org  Mon Jul  2 22:56:49 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 20:56:49 +0000
Subject: =?utf-8?q?=5Bissue13943=5D_distutils=E2=80=99_build=5Fpy_fails_when_packa?=
	=?utf-8?q?ge_string_is_unicode?=
In-Reply-To: <1328388068.27.0.743003863578.issue13943@psf.upfronthosting.co.za>
Message-ID: <1341262609.55.0.18714578295.issue13943@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Mon Jul  2 23:06:33 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 21:06:33 +0000
Subject: [issue15166] Implement imp.get_tag() using sys.implementation
In-Reply-To: <1340567412.76.0.552732396402.issue15166@psf.upfronthosting.co.za>
Message-ID: <1341263193.78.0.0772782749184.issue15166@psf.upfronthosting.co.za>


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

One small thing: this comment from import.c was not copied to sysmodule.c and is now deleted:

-   TAG must change for each major Python release. The magic number will take
-   care of any bytecode changes that occur during development.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Mon Jul  2 23:30:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Jul 2012 21:30:36 +0000
Subject: [issue15020] default value for progname in pythonrun.c should be
	python3 for Python 3
In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za>
Message-ID: <1341264636.74.0.892316111342.issue15020@psf.upfronthosting.co.za>


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

This sounds reasonable. Is there any reason that this change might be detrimental?

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Jul  2 23:32:06 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Jul 2012 21:32:06 +0000
Subject: [issue8876] distutils should not assume that hardlinks will work
In-Reply-To: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za>
Message-ID: <1341264726.3.0.662538371511.issue8876@psf.upfronthosting.co.za>


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

> AFAICT using hard links only serves to save up a little time and disk
> space; it seems to me that always copying would solve one or two bugs
> at a small cost

I agree with this.

----------

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

From report at bugs.python.org  Mon Jul  2 23:34:36 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 Jul 2012 21:34:36 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341264876.63.0.138527351034.issue15233@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The patch wording is fine.  However, I would avoid the "note" markup.  It is visually distracting and there isn't a reason to pull this out of the main text.

----------

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

From report at bugs.python.org  Mon Jul  2 23:40:46 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 02 Jul 2012 21:40:46 +0000
Subject: [issue15030] PyPycLoader can't read cached .pyc files
In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za>
Message-ID: <1341265246.12.0.190451518083.issue15030@psf.upfronthosting.co.za>


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

Marc, can you please submit a contributor form?

----------

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

From report at bugs.python.org  Tue Jul  3 00:00:55 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 22:00:55 +0000
Subject: [issue14479] Replace transplant with graft in devguide
In-Reply-To: <1333398825.72.0.80965455601.issue14479@psf.upfronthosting.co.za>
Message-ID: <1341266455.98.0.355449132658.issue14479@psf.upfronthosting.co.za>


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

The disadvantage of graft is that by default it commits before you can run tests.  Recommending to run ?graft --edit? would help (as long as you don?t close your editor you can go to the repo in another shell).

----------

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

From report at bugs.python.org  Tue Jul  3 00:05:55 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 22:05:55 +0000
Subject: [issue15182] find_library_file() should try to link
In-Reply-To: <1340631736.41.0.714328941122.issue15182@psf.upfronthosting.co.za>
Message-ID: <1341266755.73.0.862015397668.issue15182@psf.upfronthosting.co.za>


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

Hi Jeroen, thanks for the report.  Did you run into this while building a distribution or did you find it just reading the code?  Distutils is in a special state where we only fix bugs but don?t do any improvement for the sake of improvements, because many setup.py scripts rely on undocumented details.

----------

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

From report at bugs.python.org  Tue Jul  3 00:07:58 2012
From: report at bugs.python.org (Eric Snow)
Date: Mon, 02 Jul 2012 22:07:58 +0000
Subject: [issue15166] Implement imp.get_tag() using sys.implementation
In-Reply-To: <1340567412.76.0.552732396402.issue15166@psf.upfronthosting.co.za>
Message-ID: <1341266878.23.0.599649011155.issue15166@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Good catch.  However, do we need that comment?  The tag is programmatically derived from the version (in Python/sysmodule.c).

----------

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

From report at bugs.python.org  Tue Jul  3 00:15:13 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Mon, 02 Jul 2012 22:15:13 +0000
Subject: [issue15030] PyPycLoader can't read cached .pyc files
In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za>
Message-ID: <1341267313.98.0.321754362514.issue15030@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

Hi Martin,

I already did. See http://bugs.python.org/msg164162 and http://bugs.python.org/msg164164. Maybe it's not "on file" yet?

----------

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

From report at bugs.python.org  Tue Jul  3 00:39:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 22:39:59 +0000
Subject: [issue15166] Implement imp.get_tag() using sys.implementation
In-Reply-To: <1340567412.76.0.552732396402.issue15166@psf.upfronthosting.co.za>
Message-ID: <1341268799.8.0.954750267644.issue15166@psf.upfronthosting.co.za>


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

Ah, good, if it?s automatically derived then we don?t need the comment.

----------

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

From report at bugs.python.org  Tue Jul  3 01:02:22 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 02 Jul 2012 23:02:22 +0000
Subject: [issue15180] Cryptic traceback from os.path.join when mixing str &
	bytes
In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za>
Message-ID: <1341270142.03.0.0209400155794.issue15180@psf.upfronthosting.co.za>


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

This is definitely a motivated change ;-). I would like this re-typed as behavior and applied to 2.7, 3.2, and 3.3. I see the current message as being much like a garbled sentence in the docs that people can only understand if they already understand the background.

----------

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

From report at bugs.python.org  Tue Jul  3 02:13:00 2012
From: report at bugs.python.org (Axel Wegen)
Date: Tue, 03 Jul 2012 00:13:00 +0000
Subject: [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>
Message-ID: <1341274380.11.0.287905593994.issue13498@psf.upfronthosting.co.za>


Changes by Axel Wegen <axel.wegen at googlemail.com>:


----------
nosy: +Axel.Wegen

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

From report at bugs.python.org  Tue Jul  3 02:33:56 2012
From: report at bugs.python.org (Axel Wegen)
Date: Tue, 03 Jul 2012 00:33:56 +0000
Subject: [issue12716] Reorganize os docs for files/dirs/fds
In-Reply-To: <1312900904.97.0.581848486096.issue12716@psf.upfronthosting.co.za>
Message-ID: <1341275636.3.0.0863120260411.issue12716@psf.upfronthosting.co.za>


Changes by Axel Wegen <axel.wegen at googlemail.com>:


----------
nosy: +Axel.Wegen

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

From report at bugs.python.org  Tue Jul  3 06:18:55 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 04:18:55 +0000
Subject: [issue4011] Create DAG for PEP 101
In-Reply-To: <1222896665.95.0.381960877122.issue4011@psf.upfronthosting.co.za>
Message-ID: <1341289135.63.0.0889152025749.issue4011@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/issue4011>
_______________________________________

From report at bugs.python.org  Tue Jul  3 06:22:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 04:22:54 +0000
Subject: [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
Message-ID: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I did not find any doc or test for the behavior of the interpreter in virtual mode, only for venv and pyvenv.

A new paragraph in site.py exists, but it?s missing from site.rst, contains what I think is an error (saying that sys.prefix is always the real prefix), and should be somewhere more obvious than the site docs or linked from somewhere more obvious, like the Usage and Setup docs or maybe the tutorial.

----------
assignee: docs at python
components: Documentation, Tests
messages: 164563
nosy: docs at python, eric.araujo, vinay.sajip
priority: normal
severity: normal
status: open
title: venv module and pyvenv script documented, but not python behavior itself
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul  3 06:27:56 2012
From: report at bugs.python.org (Patrick Andrew)
Date: Tue, 03 Jul 2012 04:27:56 +0000
Subject: [issue14978] distutils Extension fails to be created with unicode
	package names
In-Reply-To: <1338545385.38.0.440171490662.issue14978@psf.upfronthosting.co.za>
Message-ID: <1341289676.57.0.270905437511.issue14978@psf.upfronthosting.co.za>


Patrick Andrew <pandrew at isilon.com> added the comment:

Sure, I'll have that for you shortly.

----------

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

From report at bugs.python.org  Tue Jul  3 06:31:16 2012
From: report at bugs.python.org (moijes12)
Date: Tue, 03 Jul 2012 04:31:16 +0000
Subject: [issue1660009] continuing problem with httplib multiple set-cookie
	headers
Message-ID: <1341289876.22.0.980424327795.issue1660009@psf.upfronthosting.co.za>


Changes by moijes12 <moijes12 at gmail.com>:


----------
nosy: +moijes12

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

From report at bugs.python.org  Tue Jul  3 06:33:15 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 04:33:15 +0000
Subject: [issue14964] distutils2.utils.resolve_name cleanup
In-Reply-To: <1338419313.79.0.682817999286.issue14964@psf.upfronthosting.co.za>
Message-ID: <1341289995.27.0.945690229521.issue14964@psf.upfronthosting.co.za>


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

Closing as duplicate.  I have new tests for resolve_name (need to port them from p7g to d2 and upload a patch); if your patch makes them pass or if it can be merged with another patch that fixes the function, it?s easier to have all on one issue; if your patch makes the code more readable without fixing it then I think another patch will go in.

----------

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

From report at bugs.python.org  Tue Jul  3 06:33:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 04:33:59 +0000
Subject: [issue14964] distutils2.utils.resolve_name cleanup
In-Reply-To: <1338419313.79.0.682817999286.issue14964@psf.upfronthosting.co.za>
Message-ID: <1341290039.27.0.217522858174.issue14964@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file25773/resolve_name.patch

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

From report at bugs.python.org  Tue Jul  3 06:34:36 2012
From: report at bugs.python.org (moijes12)
Date: Tue, 03 Jul 2012 04:34:36 +0000
Subject: [issue11664] Add patch method to unittest.TestCase
In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za>
Message-ID: <1341290076.61.0.657170453551.issue11664@psf.upfronthosting.co.za>


Changes by moijes12 <moijes12 at gmail.com>:


----------
nosy: +moijes12

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

From report at bugs.python.org  Tue Jul  3 06:35:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 04:35:21 +0000
Subject: [issue14964] distutils2.utils.resolve_name cleanup
In-Reply-To: <1338419313.79.0.682817999286.issue14964@psf.upfronthosting.co.za>
Message-ID: <1341290121.56.0.453415637861.issue14964@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file25773/resolve_name.patch

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

From report at bugs.python.org  Tue Jul  3 06:36:30 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 04:36:30 +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: <1341290190.31.0.769555424283.issue12703@psf.upfronthosting.co.za>


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

http://bugs.python.org/file25773/resolve_name.patch is a patch that cleans up the function; I?ll see if it can be used to solve our problems without having to follow my drastic find_object idea.

----------

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

From report at bugs.python.org  Tue Jul  3 06:37:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 04:37:39 +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: <1341290259.65.0.239897336211.issue12703@psf.upfronthosting.co.za>


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

BTW modules in the standard library all use the dotted notation AFAIK, not the colon notation, so I would strongly prefer avoiding the colon notation.

----------

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

From report at bugs.python.org  Tue Jul  3 06:39:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 04:39:06 +0000
Subject: [issue14967] distutils2.utils.resolve_name cannot be implemented to
	give correct errors in all situations
In-Reply-To: <1338464077.51.0.267710921151.issue14967@psf.upfronthosting.co.za>
Message-ID: <1341290346.68.0.887307934014.issue14967@psf.upfronthosting.co.za>


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

Please keep the discussion in one place, the other bug report.

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

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

From report at bugs.python.org  Tue Jul  3 06:49:57 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 04:49:57 +0000
Subject: [issue11880] add a {dist-info} category to distutils2
In-Reply-To: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za>
Message-ID: <1341290997.01.0.129727166641.issue11880@psf.upfronthosting.co.za>


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

Did a first review on Rietveld, but I see that the patch may be outdated (it had no tests).

----------
versions: +3rd party, Python 3.4 -Python 3.3

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

From report at bugs.python.org  Tue Jul  3 07:02:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 05:02:43 +0000
Subject: [issue7719] distutils: ignore .nfsXXXX files
In-Reply-To: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za>
Message-ID: <1341291763.16.0.921415294077.issue7719@psf.upfronthosting.co.za>


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

SilentGhost, could you submit a contributor agreement to the PSF for your patches?  See http://www.python.org/psf/contrib/ .  Thanks.

----------

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

From report at bugs.python.org  Tue Jul  3 07:14:02 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 05:14:02 +0000
Subject: [issue7719] distutils: ignore .nfsXXXX files
In-Reply-To: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za>
Message-ID: <3WRD5P07FTzN0D@mail.python.org>


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

New changeset a56cebff113a by ?ric Araujo in branch '2.7':
Ignore .nfs* files in distutils (#7719).
http://hg.python.org/cpython/rev/a56cebff113a

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

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

From report at bugs.python.org  Tue Jul  3 07:14:25 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 03 Jul 2012 05:14:25 +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: <1341292465.88.0.663695002289.issue1602@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

For the win_console.patch, it seems like adding the line

self.errors='strict'

inside UnicodeOutput.__init__ resolves the problem with input causing exceptions.

Not sure if the sys_write_stdout.patch has the same sort of problem. Sure home this issue makes it into 3.3.

----------

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

From report at bugs.python.org  Tue Jul  3 07:23:54 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 05:23:54 +0000
Subject: [issue13512] ~/.pypirc created insecurely
In-Reply-To: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za>
Message-ID: <3WRDJm4tqbzN7R@mail.python.org>


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

New changeset f833e7ec4de1 by ?ric Araujo in branch '2.7':
Create ~/.pypirc securely (#13512).
http://hg.python.org/cpython/rev/f833e7ec4de1

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

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

From report at bugs.python.org  Tue Jul  3 07:26:17 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 05:26:17 +0000
Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does
	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1341293177.3.0.603083311439.issue10571@psf.upfronthosting.co.za>


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

Reopening for d2.  According to our rules a unit test would be required, but if we don?t have machinery to test upload already in place then I would just commit it; we definitely want to have automated tests for all commands, but it needn?t hold up this fix.

----------
stage: committed/rejected -> commit review
status: closed -> open
versions: +3rd party

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

From report at bugs.python.org  Tue Jul  3 07:27:08 2012
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 03 Jul 2012 05:27:08 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1341293228.71.0.126707116167.issue15202@psf.upfronthosting.co.za>


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

> What's the urge to make parameters keyword-only?

I suggest that boolean parameters are best made keyword-only.  Otherwise you have mystery meat like

shutil.copyfile("src", "dst", True)

Also, all the extant uses of "follow_symlinks" in os are keyword-only, and as long as it's a new parameter it'd be nice to keep it consistent.

----------

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

From report at bugs.python.org  Tue Jul  3 07:27:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 05:27:12 +0000
Subject: [issue13512] ~/.pypirc created insecurely
In-Reply-To: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za>
Message-ID: <1341293232.0.0.309247839666.issue13512@psf.upfronthosting.co.za>


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

Will port to 3.2 soon.

Release managers: there are CVE and ocert numbers for this; do we take that as indication that it should be fixed in security releases too or do we stand by our own assessment that it?s just a bugfix?

----------

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

From report at bugs.python.org  Tue Jul  3 07:39:01 2012
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 03 Jul 2012 05:39:01 +0000
Subject: [issue4011] Create DAG for PEP 101
In-Reply-To: <1222896665.95.0.381960877122.issue4011@psf.upfronthosting.co.za>
Message-ID: <1341293941.53.0.393923940078.issue4011@psf.upfronthosting.co.za>


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

Note: I don't have Macs, so I can't run OmniGiraffe.  And a quick gander at the Graphviz website suggests its output lacks the sublime elegance Python documentation has become known for.

----------

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

From report at bugs.python.org  Tue Jul  3 07:56:19 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 03 Jul 2012 05:56:19 +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: <1341294979.36.0.515785353401.issue1602@psf.upfronthosting.co.za>


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

3.3b0, Win7, 64 bit. Original test script stops at
File "C:\Programs\Python33\lib\encodings\cp437.py", line 19, in encode
  return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\x80' in position 6:

I am slightly puzzled because cp437 is an extended ascii codepage and there *is* a character for 0x80
https://en.wikipedia.org/wiki/Code_page_437

If I add .encode('latin1'), it does not print the pentagon for 0x7e, but does print \x7e to \xff.

Someone wrote elsewhere that 3.3 could use cp65001. True?

----------

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

From report at bugs.python.org  Tue Jul  3 08:26:20 2012
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 03 Jul 2012 06:26:20 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341296780.03.0.994278148727.issue15233@psf.upfronthosting.co.za>


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

> Is it tested for?

Amusingly enough, yes.  test_order() in Lib/test/test_atexit.py already ensures reverse order.

----------

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

From report at bugs.python.org  Tue Jul  3 08:47:08 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 03 Jul 2012 06:47:08 +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: <1341298028.82.0.232727751683.issue1602@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

My fix for this "errors" error, might be similar to what is needed for issue 12967, although I don't know if my fix is really correct... just that it gets past the error, and 'strict' is the default for TextIOWrapper.

I'm not at all sure why there is now (since 3.2) an interaction between input on stdin and the particulars of the output class for stdout. But I'm not at all an expert in Python internals or Python IO.

I'm not sure whether or not you applied the patch to your b0, if not, that is what I'm running, too... but using the win_console.patch as supporting code.  The original test script didn't use the supporting code.

If you did patch your b0 bwith unicode3.py, then you shouldn't need to do a chcp to write any Unicode characters; someone reported that doing a chcp caused problems, but I don't know how to apply the patch or build a Python with it, so can't really test all the cases. Victor did add a cp65001 codec using a different issue, not sure how that is relevant here, other than for the tests he wrote.

----------

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

From report at bugs.python.org  Tue Jul  3 08:51:05 2012
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 03 Jul 2012 06:51:05 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341298265.89.0.804062264834.issue15233@psf.upfronthosting.co.za>


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

> I would avoid the "note" markup.  It is visually distracting
> and there isn't a reason to pull this out of the main text.

I think it's an improvement; it helps draw the eye to an important warning.

Does anyone else have an opinion one way or another?

----------

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

From report at bugs.python.org  Tue Jul  3 08:54:13 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 03 Jul 2012 06:54:13 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
Message-ID: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

There was some concern with PyImport_GetMagicTag() extracting its value from sys.implementation.cache_tag.  One solution is to have the two use a common underlying value.  However, that's basically what was already in import.c and I'd rather minimize that file at this point.

An alternative is to have the underlying value defined in a more amenable spot, but I'm not convinced that buys a whole lot over simply exposing the underlying value in PyImport_GetMagicTag().  If we could deprecate that function...

Another possibility is to move the underlying value to configure.  The down-side is that it's platform-specific.  I've attached a patch that does this.  While it may do too much as-is, it demonstrates my point.

----------
components: Interpreter Core
files: cache_tag_via_configure.diff
keywords: patch
messages: 164582
nosy: amaury.forgeotdarc, brett.cannon, eric.snow
priority: normal
severity: normal
stage: patch review
status: open
title: PyImport_GetMagicTag() should use the same const char * as sys.implementation.cache_tag
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26237/cache_tag_via_configure.diff

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

From report at bugs.python.org  Tue Jul  3 08:54:39 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 03 Jul 2012 06:54:39 +0000
Subject: [issue15166] Implement imp.get_tag() using sys.implementation
In-Reply-To: <1340567412.76.0.552732396402.issue15166@psf.upfronthosting.co.za>
Message-ID: <1341298479.05.0.216033383294.issue15166@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

There was some concern with PyImport_GetMagicTag() extracting its value from sys.implementation.cache_tag.  I've addressed this in issue15242.

----------

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

From report at bugs.python.org  Tue Jul  3 09:16:31 2012
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 03 Jul 2012 07:16:31 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <1341299791.47.0.79483345694.issue15238@psf.upfronthosting.co.za>


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

First patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file26238/larry.copystat.xattrs.1.diff

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

From report at bugs.python.org  Tue Jul  3 09:17:01 2012
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Tue, 03 Jul 2012 07:17:01 +0000
Subject: [issue15178] Doctest should handle situations when test files are not
	readable
In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za>
Message-ID: <1341299821.76.0.465775684731.issue15178@psf.upfronthosting.co.za>


Bohuslav "Slavek" Kabrda <bkabrda at redhat.com> added the comment:

Fifth version :)

- On failure in a loaded test, the _test function returns, so this behaviour is preserved.
- During _test function, count of both loaded and non-loaded files is kept.
- If a file fails to be loaded, the tests continue, but a non-zero return code is returned. Moreover, the results of loaded and non-loaded files are printed after each invocation.

This is a sample output:


$ python3 -m doctest -v spam c.py beans
Cannot read 'spam': [Errno 2] No such file or directory: 'spam'
Trying:
    2 * 2
Expecting:
    4
ok
1 items passed all tests:
   1 tests in c
1 tests in 1 items.
1 passed and 0 failed.
Test passed.
Cannot read 'beans': [Errno 2] No such file or directory: 'beans'
Test files read successfully: 1
Unreadable files: 2


Does this look better?

----------
Added file: http://bugs.python.org/file26239/doctest-dont-end-with-exception-on-unreadable-files-v5.patch

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

From report at bugs.python.org  Tue Jul  3 09:18:23 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 07:18:23 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341299903.44.0.784073032253.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Added file: http://bugs.python.org/file26240/poplib_02_server_capabilities.diff

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

From report at bugs.python.org  Tue Jul  3 09:18:37 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 07:18:37 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341299917.04.0.168615217059.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Removed file: http://bugs.python.org/file26133/poplib_02_server_capabilities.diff

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

From report at bugs.python.org  Tue Jul  3 09:18:53 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 07:18:53 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341299933.79.0.376801656162.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Removed file: http://bugs.python.org/file26134/poplib_03_starttls.diff

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

From report at bugs.python.org  Tue Jul  3 09:19:05 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 07:19:05 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341299945.71.0.344781846596.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Added file: http://bugs.python.org/file26241/poplib_03_starttls.diff

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

From report at bugs.python.org  Tue Jul  3 09:25:52 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 07:25:52 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341300352.57.0.558034469187.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Removed file: http://bugs.python.org/file26241/poplib_03_starttls.diff

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

From report at bugs.python.org  Tue Jul  3 09:26:47 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 07:26:47 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341300407.49.0.285585129436.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Added file: http://bugs.python.org/file26242/poplib_03_starttls.diff

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

From report at bugs.python.org  Tue Jul  3 09:33:09 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 07:33:09 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341300789.93.0.766357238419.issue4473@psf.upfronthosting.co.za>


Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it> added the comment:

I've refreshed once more the patches, adding the implementation of the stls command in test_poplib.py.

IMHO, the changes as they stand now are low risk, and could as well go into 3.3.

With many thanks to Giampaolo for implementing the asynchat/asyncore pop3 server!

----------

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

From report at bugs.python.org  Tue Jul  3 09:54:33 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 03 Jul 2012 07:54:33 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <1341302073.15.0.728029458855.issue15242@psf.upfronthosting.co.za>


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

Can the #defines appear in pyconfig.h instead?  I find it easier to discover them this way, and will also simplify the implementation on Windows.

----------

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

From report at bugs.python.org  Tue Jul  3 11:23:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Jul 2012 09:23:25 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341307405.39.0.431632679215.issue15233@psf.upfronthosting.co.za>


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

> Does anyone else have an opinion one way or another?

I'm neutral.

----------

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

From report at bugs.python.org  Tue Jul  3 11:39:26 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 03 Jul 2012 09:39:26 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341308366.79.0.623455633831.issue14902@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip

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

From report at bugs.python.org  Tue Jul  3 12:04:52 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Jul 2012 10:04:52 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>
Message-ID: <1341309892.95.0.923455818905.issue15210@psf.upfronthosting.co.za>


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

Ping. The test fails erratically on many buildbots.

----------
nosy: +pitrou
status: closed -> open

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

From report at bugs.python.org  Tue Jul  3 13:03:16 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 03 Jul 2012 11:03:16 +0000
Subject: [issue15139] Speed up threading.Condition wakeup
In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za>
Message-ID: <1341313396.12.0.816385239019.issue15139@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Thank you Richard.
A new patch is included.  Now the processing of "timeout" is done in _acquire_condition().  None is infinite, and negative timeouts are clipped to zero.

Do you feel that it is unnecessary to be able to support other locks than Lock() and RLock() as the outer lock?  If so, then we can drop the "_acquire_restore()" as suggested by Martin.

----------
Added file: http://bugs.python.org/file26243/condition.patch

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

From report at bugs.python.org  Tue Jul  3 13:05:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 11:05:14 +0000
Subject: [issue1667] license() does not process keyboard input correctly
In-Reply-To: <1198129018.94.0.275386656073.issue1667@psf.upfronthosting.co.za>
Message-ID: <3WRMtX1ldyzNdv@mail.python.org>


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

New changeset 7ccc2cea6969 by Jesus Cea in branch '2.7':
Issue #1667: Unused variable warning in Non-Windows
http://hg.python.org/cpython/rev/7ccc2cea6969

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

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

From report at bugs.python.org  Tue Jul  3 13:08:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 11:08:48 +0000
Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows
In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za>
Message-ID: <3WRMyl4vkCzNdv@mail.python.org>


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

New changeset 2de5c9ced464 by Jesus Cea in branch '2.7':
Issue #1677: Unused variable warning in Non-Windows
http://hg.python.org/cpython/rev/2de5c9ced464

----------

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

From report at bugs.python.org  Tue Jul  3 13:18:47 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 11:18:47 +0000
Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows
In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za>
Message-ID: <3WRNBG4xvszMZK@mail.python.org>


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

New changeset 4de541fbdd58 by Jesus Cea in branch '3.2':
Issue #1677: Unused variable warning in Non-Windows
http://hg.python.org/cpython/rev/4de541fbdd58

New changeset 7937aa6b7e92 by Jesus Cea in branch 'default':
NULL MERGE: Issue #1677: Unused variable warning in Non-Windows
http://hg.python.org/cpython/rev/7937aa6b7e92

----------

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

From report at bugs.python.org  Tue Jul  3 13:20:59 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Jul 2012 11:20:59 +0000
Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows
In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za>
Message-ID: <1341314459.26.0.325859177667.issue1677@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/issue1677>
_______________________________________

From report at bugs.python.org  Tue Jul  3 13:21:22 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Jul 2012 11:21:22 +0000
Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows
In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za>
Message-ID: <1341314482.92.0.787954545579.issue1677@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
versions:  -Python 3.1

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

From report at bugs.python.org  Tue Jul  3 13:31:06 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 03 Jul 2012 11:31:06 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341315066.4.0.994016000647.issue14902@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@Yuriy: I set my location to Moscow (using the Gnome date widget) and ran the test, but no failure occurs.

vinay at eta-jaunty:~/projects/python/default$ date
Tue Jul  3 15:12:39 MSD 2012
vinay at eta-jaunty:~/projects/python/default$ ./python Lib/test/regrtest.py test_logging
[1/1] test_logging
1 test OK.

@Juan: Since the logging test doesn't seem to be broken, I'd rather not patch it; it was at least useful for throwing up a problem. For some reason time.timezone seems to be off, and that should probably be flagged as a separate issue.

----------

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

From report at bugs.python.org  Tue Jul  3 13:54:47 2012
From: report at bugs.python.org (Yuriy Syrovetskiy)
Date: Tue, 03 Jul 2012 11:54:47 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341316487.77.0.2053321368.issue14902@psf.upfronthosting.co.za>


Yuriy Syrovetskiy <cblp at cblp.su> added the comment:

@vinay.sajip
My time.timezone is -14400. What is yours?

----------

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

From report at bugs.python.org  Tue Jul  3 13:56:34 2012
From: report at bugs.python.org (Yuriy Syrovetskiy)
Date: Tue, 03 Jul 2012 11:56:34 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341316594.13.0.341629401342.issue14902@psf.upfronthosting.co.za>


Yuriy Syrovetskiy <cblp at cblp.su> added the comment:

And datetime.datetime.now().tzinfo is always None.

----------

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

From report at bugs.python.org  Tue Jul  3 14:32:20 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 03 Jul 2012 12:32:20 +0000
Subject: [issue15180] Cryptic traceback from os.path.join when mixing str &
	bytes
In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za>
Message-ID: <1341318740.07.0.145020401952.issue15180@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Cool, I'll finish it up in the sprints on Saturday.

----------

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

From report at bugs.python.org  Tue Jul  3 14:50:32 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Tue, 03 Jul 2012 12:50:32 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341319832.1.0.469023365452.issue14902@psf.upfronthosting.co.za>


Juancarlo A?ez <apalala at gmail.com> added the comment:

@Vinay The test *is* broken in theory, because it uses today's time.timezone to make calculations over a datetime in the past (1993), even when official time zones have changes in recent years for Caracas, Moscow, and others: http://www.timeanddate.com/news/time/. As it is, the test will pass on some locations and fail on others, even if time.timezone is correct.

If time.timezone is wrong for certain locations is a separate issue that I will post as soon as I complete the unit test. I took a look at Modules/timemodule.c,and there seems to be nothing wrong there.

In short, the bug is: test_time() incorrectly uses the current time.timezone to make calculations over dates in the past.

----------

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

From report at bugs.python.org  Tue Jul  3 14:57:56 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Tue, 03 Jul 2012 12:57:56 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341320276.31.0.381786180912.issue14902@psf.upfronthosting.co.za>


Juancarlo A?ez <apalala at gmail.com> added the comment:

> And datetime.datetime.now().tzinfo is always None.

I can reproduce that.

----------

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

From report at bugs.python.org  Tue Jul  3 15:04:18 2012
From: report at bugs.python.org (Daniel Holth)
Date: Tue, 03 Jul 2012 13:04:18 +0000
Subject: [issue11880] add a {dist-info} category to distutils2
In-Reply-To: <1341290997.01.0.129727166641.issue11880@psf.upfronthosting.co.za>
Message-ID: <85539F14-8DF9-4F4F-8B88-F310513E102A@fastmail.fm>


Daniel Holth <dholth at fastmail.fm> added the comment:

I appreciate it. I had trouble using the patch system after that. I will see whether I can generate a better one.

Daniel Holth

On Jul 3, 2012, at 12:49 AM, ?ric Araujo <report at bugs.python.org> wrote:

> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Did a first review on Rietveld, but I see that the patch may be outdated (it had no tests).
> 
> ----------
> versions: +3rd party, Python 3.4 -Python 3.3
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11880>
> _______________________________________

----------

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

From report at bugs.python.org  Tue Jul  3 15:46:41 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Jul 2012 13:46:41 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341323201.94.0.873868324228.issue4473@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Lorenzo, 3.3 is in beta mode now. No new features accepted :-(.

Please, fulfill a PSF contributor agreement http://www.python.org/psf/contrib/

----------

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

From report at bugs.python.org  Tue Jul  3 16:07:47 2012
From: report at bugs.python.org (Jeff Knupp)
Date: Tue, 03 Jul 2012 14:07:47 +0000
Subject: [issue15033] Different exit status when using -m
In-Reply-To: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za>
Message-ID: <1341324467.44.0.472071282075.issue15033@psf.upfronthosting.co.za>


Jeff Knupp <jknupp at gmail.com> added the comment:

Fixed for 3.3. Does this need to be back ported as well?

----------
keywords: +patch
nosy: +Jeff.Knupp
Added file: http://bugs.python.org/file26244/exit_code.patch

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

From report at bugs.python.org  Tue Jul  3 16:08:39 2012
From: report at bugs.python.org (Jeff Knupp)
Date: Tue, 03 Jul 2012 14:08:39 +0000
Subject: [issue15033] Different exit status when using -m
In-Reply-To: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za>
Message-ID: <1341324519.05.0.374733535546.issue15033@psf.upfronthosting.co.za>


Jeff Knupp <jknupp at gmail.com> added the comment:

And by 'Fixed' I of course meant 'Patched, awaiting review'.

----------

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

From report at bugs.python.org  Tue Jul  3 16:21:31 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 03 Jul 2012 14:21:31 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341325291.52.0.858383837617.issue14902@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Sorry, I didn't quite grasp what the problem was before (timezones changing over time). I understand better now :-)

@Yuriy: On my test machine (Ubuntu Jaunty), with Moscow set as my location, the value of time.timezone is -10800 (for Caracas, it's 16200). The datetime.datetime.now().tzinfo is None, as you've both said.

I will look at this soon. Yuriy, can you confirm that with Juancarlo's patch, the test also works for you?

----------

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

From report at bugs.python.org  Tue Jul  3 16:24:33 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 03 Jul 2012 14:24:33 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341325473.51.0.91405834581.issue14902@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

BTW I just noticed that you created this issue on 24 May. Sorry I only saw it today - in future, if you add logging issues, please add me to the nosy list, and that way I'll pick it up sooner. Usually one of the other committers adds me, but this time no-one did :-(

----------

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

From report at bugs.python.org  Tue Jul  3 17:08:38 2012
From: report at bugs.python.org (William Schwartz)
Date: Tue, 03 Jul 2012 15:08:38 +0000
Subject: [issue15243] Misleading documentation for __prepare__
Message-ID: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>


New submission from William Schwartz <wkschwartz at gmail.com>:

Section 3.3.3.2. "Preparing the class namespace" of the documentation (http://docs.python.org/dev/reference/datamodel.html#preparing-the-class-namespace) states that "If the metaclass has a __prepare__ attribute, it is called as ``namespace = metaclass.__prepare__(name, bases, **kwds)``...." This isn't quite true. By just defining a ``__prepare__`` method in a metaclass, the interpreter calls it as it would a static method -- there is no implicit first argument referring to ``metaclass`` as the documentation implies. The documentation should be amended to say that users can decorate ``__prepare__`` as a class method to get ``metaclass`` passed in as the implicit first argument.

----------
assignee: docs at python
components: Documentation, Tests
messages: 164606
nosy: William.Schwartz, docs at python
priority: normal
severity: normal
status: open
title: Misleading documentation for __prepare__
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul  3 17:30:13 2012
From: report at bugs.python.org (William Schwartz)
Date: Tue, 03 Jul 2012 15:30:13 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341329413.25.0.815543157319.issue15243@psf.upfronthosting.co.za>


William Schwartz <wkschwartz at gmail.com> added the comment:

Attached a unittest script to demonstrate that __prepare__ is implicitly a staticmethod.

----------
Added file: http://bugs.python.org/file26245/test_metaclass.py

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

From report at bugs.python.org  Tue Jul  3 17:31:04 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Tue, 03 Jul 2012 15:31:04 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341329464.27.0.922555841967.issue14902@psf.upfronthosting.co.za>


Juancarlo A?ez <apalala at gmail.com> added the comment:

I did extensive testing on time.timezone, and it is correct as far as the current date is concerned. The problem, as mentioned before, is that test_logging is using time.timezone for dates in the past for which the time zone may have been different from the current one on the current location.

The attached patch shows that time calculations involving time.timezone may not be valid for dates different from the current one, as not even daylight-savings/summer times are taken into account, so the test may also fail depending on the time of the year it is run on.

----------
Added file: http://bugs.python.org/file26246/test_timezones.patch

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

From report at bugs.python.org  Tue Jul  3 17:34:25 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 15:34:25 +0000
Subject: [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
In-Reply-To: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>
Message-ID: <3WRTs95ntbzN2J@mail.python.org>


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

New changeset 4a39ea2c1b11 by Vinay Sajip in branch 'default':
Issue 15241: Improved site.py documentation relating to venvs.
http://hg.python.org/cpython/rev/4a39ea2c1b11

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

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

From report at bugs.python.org  Tue Jul  3 17:41:12 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Jul 2012 15:41:12 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341330072.89.0.702368883722.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file26247/56ac083c60dc.diff

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

From report at bugs.python.org  Tue Jul  3 17:42:12 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Jul 2012 15:42:12 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341330132.88.0.38333427525.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file26248/d12ded643482.diff

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

From report at bugs.python.org  Tue Jul  3 17:48:45 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Jul 2012 15:48:45 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341330525.14.0.967423158195.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Thanks to Marc Abramowitz huge help and support, current patch builds and works perfectly fine under:

1. x86 32 and 64 bits, static and shared library, Solaris 10.

2. x86 32 and 64 bits, static and shared library, OpenSolaris derivatives (Solaris 11, Openindiana)

3. x86 32 and 64 bits, static and shared library, Mac OS X, recent versions.

Pending stuff:

1. SPARC CPU testing.

2. FreeBSD (the custom buildbot we have was not compiled with the "right" kernel flags).

Could anybody help in those areas?.

----------

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

From report at bugs.python.org  Tue Jul  3 17:51:39 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Jul 2012 15:51:39 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341330699.33.0.713756792728.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Tue Jul  3 17:56:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 15:56:58 +0000
Subject: [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
In-Reply-To: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>
Message-ID: <3WRVMF3hG5zNZb@mail.python.org>


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

New changeset 18c2519b9114 by Vinay Sajip in branch 'default':
Issue #15241: Added test for venv prefixes.
http://hg.python.org/cpython/rev/18c2519b9114

----------

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

From report at bugs.python.org  Tue Jul  3 17:59:41 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 03 Jul 2012 15:59:41 +0000
Subject: [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
In-Reply-To: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>
Message-ID: <1341331181.56.0.763786441143.issue15241@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Note that the prefix values (and their meanings in venv/non-venv environments) are documented in the sys module.

----------

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

From report at bugs.python.org  Tue Jul  3 18:11:31 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Jul 2012 16:11:31 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341331891.74.0.404664980374.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file25192/aa2dcffa267f.diff

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

From report at bugs.python.org  Tue Jul  3 18:11:37 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Jul 2012 16:11:37 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341331897.32.0.595054044385.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file25203/4a072278b866.diff

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

From report at bugs.python.org  Tue Jul  3 18:27:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 16:27:08 +0000
Subject: [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
In-Reply-To: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>
Message-ID: <3WRW22597NzN1h@mail.python.org>


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

New changeset 74fea1763d02 by Vinay Sajip in branch 'default':
Closes #15241: Added information on venv prefixes to pyvenv section.
http://hg.python.org/cpython/rev/74fea1763d02

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

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

From report at bugs.python.org  Tue Jul  3 19:16:59 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 03 Jul 2012 17:16:59 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341335819.48.0.147807547947.issue14902@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Yes, thanks for doing the detailed analysis. I see that the original code was trying to adjust the timezone for a past time effectively using current timezone rules, which is why it doesn't work.

Your patch appears equivalent to the slightly simpler

dt = datetime.datetime(1993, 4, 21, 8, 3, 0, 0, utc)
r.created = time.mktime(dt.astimezone(None).timetuple())

which echoes the intent of the original code to adjust for the timezone. Can you see any reason why the above shouldn't work? On my test machine, it worked fine with the above code and locations of Moscow, London and Caracas (the original code failed with Caracas, though not with Moscow - but do I understand that the original is broken).

----------

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

From report at bugs.python.org  Tue Jul  3 19:25:37 2012
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 03 Jul 2012 17:25:37 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341336337.88.0.798188273455.issue15243@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +daniel.urban

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

From report at bugs.python.org  Tue Jul  3 20:15:27 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Tue, 03 Jul 2012 18:15:27 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341339327.6.0.686902776905.issue14902@psf.upfronthosting.co.za>


Juancarlo A?ez <apalala at gmail.com> added the comment:

@Vinay No reason. datetime.astimezone(None) is documented in 3.3. You may even use:

r.created = time.mktime(dt.astimezone().timetuple())

----------

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

From report at bugs.python.org  Tue Jul  3 20:16:15 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Tue, 03 Jul 2012 18:16:15 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <1341339375.3.0.94000412348.issue14902@psf.upfronthosting.co.za>


Changes by Juancarlo A?ez <apalala at gmail.com>:


----------
type: compile error -> behavior

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

From report at bugs.python.org  Tue Jul  3 21:14:55 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 03 Jul 2012 19:14:55 +0000
Subject: [issue15244] Support for opening files with FILE_SHARE_DELETE on
	Windows
Message-ID: <1341342894.98.0.559958462018.issue15244@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

On Unix, files (unless specifically locked) can be renamed and deleted while file descriptors for the file remain open.  The file descriptors remain valid even after deletion of the file.

On Windows this is not possible for files opened using io.open() or os.open().  However, by using the FILE_SHARE_DELETE flag in CreateFile() one can get Unix-like behaviour.

Unfortunately, FILE_SHARE_DELETE is only available through the Win32 API, not through the CRT.  Also, Issue #14243 concerns the fact that on Windows temporary files cannot be reopened unless one uses the FILE_SHARE_DELETE flag.  One can only reopen a file by using a share mode that is at least as permissive as the share mode for all the currently open handles.

The attached patch adds a module "share" (bad name?) with functions share.open() and share.os_open() which act as substitutes for io.open() and os.open().  These by default use FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE as the share mode.  (io.open() and os.open() use FILE_SHARE_READ | FILE_SHARE_WRITE instead.)

To run the full regression test suite with builtins.open(), io.open() and os.open() monkey patched to use these replacements you can do

    python -m test.test_share --regrtest

Nothing seems to break.

----------
components: Library (Lib)
files: share.patch
keywords: patch
messages: 164616
nosy: sbt
priority: normal
severity: normal
stage: patch review
status: open
title: Support for opening files with FILE_SHARE_DELETE on Windows
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26249/share.patch

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

From report at bugs.python.org  Tue Jul  3 21:22:32 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 03 Jul 2012 19:22:32 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful
	on	Windows
In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za>
Message-ID: <1341343352.85.0.42421337653.issue14243@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

I have opened Issue #15244 with a patch to add a share module to the stdlib.

After monkey patching builtins.open(), io.open() and os.open() to be equivalents using FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, the regression test suite still runs successfully.

----------

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

From report at bugs.python.org  Tue Jul  3 21:44:59 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 03 Jul 2012 19:44:59 +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: <1341344699.69.0.529944660608.issue1602@psf.upfronthosting.co.za>


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

I was reporting stock, as distributed 3.3b0.

Is unicode3.py something to run once or import in each app that wants unicode output? Either way, if it is possible to fix the console, why is it not distribute it with the fix?

>Terry, applications for non-programmers that want to emit Unicode on the console... so the IDLE shell isn't appropriate.

Someone just posted on python-list about a problem with that.

Hmm. Maybe IDLE should gain a batch-mode console window -- basically a stripped down version of the current shell -- a minimal auto-gui for apps.

----------

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

From report at bugs.python.org  Tue Jul  3 21:54:34 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 03 Jul 2012 19:54:34 +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: <1341345274.83.0.534415385942.issue1602@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Terry said:
Is unicode3.py something to run once or import in each app that wants unicode output? 

I say:
The latter... import it.

Terry said:
Either way, if it is possible to fix the console, why is it not distribute it with the fix?

I say:
Not sure what you are asking here. Yes it is possible to fix the console, but this fix depends on the version-specific internals of the Python IO system... so unicode3.py works with Python 3.1, but not Python 3.2 or 3.3.  I haven't tested to see if my patched unicode3.py still works on Python 3.1 (I imagine it would, due to the nature of the fix just adding something that Python 3.1 probably would ignore.

So my opinion is the fix is better done inside Python than inside the application.

----------

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

From report at bugs.python.org  Tue Jul  3 22:05:16 2012
From: report at bugs.python.org (Mark Grandi)
Date: Tue, 03 Jul 2012 20:05:16 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1341345916.79.0.247203697974.issue14455@psf.upfronthosting.co.za>


Mark Grandi <markgrandi at gmail.com> added the comment:

Hi,

I noticed in the latest message that d9pounces posted that "JSON format does not allow dates and data, so XML is used by default to write files.". Rthe XML version of plists also do not really 'support' those types, and they are converted as follows:

NSData -> Base64 encoded data
NSDate -> ISO 8601 formatted string

(from http://en.wikipedia.org/wiki/Property_list#Mac_OS_X)

So really it should be the same thing when converting to json no?

----------
nosy: +markgrandi

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

From report at bugs.python.org  Tue Jul  3 22:11:26 2012
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Tue, 03 Jul 2012 20:11:26 +0000
Subject: [issue15245] ast.literal_eval on some literals
Message-ID: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo <jbvsmo at gmail.com>:

`ast.literal_eval` is very strict on names, so it seems to lack some "literals" that may be result of `repr` on built-in objects.

-> Obvious cases:

ast.literal_eval('...')
ast.literal_eval('Ellipsis')

both result on ValueError.



-> Not so obvious:

nan_name = repr(float('nan'))
ast.literal_eval(nan_name) # ValueError

inf_name = repr(float('inf'))
ast.literal_eval(inf_name)  # ValueError

ast.literal_eval("2e308") # == inf


`nan` and `inf` are not literals (at least "inf" should be, but that's another problem), but their representations are not possible to be evaluated unlike any other float numbers with maybe precision loss. 

I think `literal_eval` should include these 3 names the same way it accepts True, False and None.

Another case, that I personally don't care, but seems plausible would be `NotImplemented`.

----------
components: Library (Lib)
messages: 164621
nosy: JBernardo
priority: normal
severity: normal
status: open
title: ast.literal_eval on some literals
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul  3 22:36:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 20:36:59 +0000
Subject: [issue14902] test_logging failed
In-Reply-To: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>
Message-ID: <3WRcZK6PCfzN17@mail.python.org>


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

New changeset 56260d30985d by Vinay Sajip in branch 'default':
Closes #14902: Fixed timezone conversion of a date/time in the past. Thanks to Yuriy Syrovetskiy for the report and Juancarlo A?ez for the patch on which this fix is based.
http://hg.python.org/cpython/rev/56260d30985d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jul  3 22:50:56 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 20:50:56 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341348656.07.0.84631890991.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Added file: http://bugs.python.org/file26250/poplib_01_socket_shutdown_v3.diff

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

From report at bugs.python.org  Tue Jul  3 22:51:07 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 20:51:07 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341348667.53.0.413684885445.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Added file: http://bugs.python.org/file26251/poplib_02_server_capabilities_v3.diff

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

From report at bugs.python.org  Tue Jul  3 22:51:17 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 20:51:17 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341348677.27.0.940099738816.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Added file: http://bugs.python.org/file26252/poplib_03_starttls_v3.diff

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

From report at bugs.python.org  Tue Jul  3 22:51:36 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 20:51:36 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341348696.63.0.649196533906.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Removed file: http://bugs.python.org/file26132/poplib_01_socket_shutdown.diff

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

From report at bugs.python.org  Tue Jul  3 22:51:43 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 20:51:43 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341348703.74.0.624987149872.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Removed file: http://bugs.python.org/file26240/poplib_02_server_capabilities.diff

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

From report at bugs.python.org  Tue Jul  3 22:51:49 2012
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Tue, 03 Jul 2012 20:51:49 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1341348709.23.0.00586315000433.issue4473@psf.upfronthosting.co.za>


Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:


Removed file: http://bugs.python.org/file26242/poplib_03_starttls.diff

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

From report at bugs.python.org  Tue Jul  3 22:52:22 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 03 Jul 2012 20:52:22 +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: <1341348742.93.0.0632877268009.issue12967@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

So this looks like it might be a simple fix... in issue 1602, there was a patch for Windows console for 3.1... sadly not applied then, or 3.2, or 3.3 (yet).  But in 3.2, the fix sprouted a failure just like this one: the console output class would get reported to not have an "errors" attribute when doing an input.  A fix there was to add an attribute errors='strict' to the console output class.

Here it seems the same symptom sprouted in the same time frame, for a similar situation where the output class has been replaced by one that doesn't have an errors attribute... so it should grow one...

----------
nosy: +v+python

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

From report at bugs.python.org  Tue Jul  3 22:54:21 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 03 Jul 2012 20:54:21 +0000
Subject: [issue15030] PyPycLoader can't read cached .pyc files
In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za>
Message-ID: <1341348861.48.0.784247229466.issue15030@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Maybe you can try emailing in the form again, Marc? Let me know when you have and if it is lost again I will bug the proper people.

Anyway, the original patch I committed added you to Misc/ACKS: http://hg.python.org/cpython/file/56260d30985d/Misc/ACKS#l16

----------

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

From report at bugs.python.org  Tue Jul  3 22:54:32 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Jul 2012 20:54:32 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341348872.51.0.0898263167712.issue15245@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson
title: ast.literal_eval on some literals -> ast.literal_eval fails on some literals
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Tue Jul  3 22:56:28 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Jul 2012 20:56:28 +0000
Subject: [issue15033] Different exit status when using -m
In-Reply-To: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za>
Message-ID: <1341348988.14.0.0269485171593.issue15033@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/issue15033>
_______________________________________

From report at bugs.python.org  Tue Jul  3 22:56:35 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 03 Jul 2012 20:56:35 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>
Message-ID: <1341348995.94.0.179025218811.issue15210@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Any suggestions on how to make the test work better? Otherwise I'm fine with dropping the test since the fix has been verified at least on my machine (and if it is broken the other VMs will notice quickly when they start to implement things).

----------

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

From report at bugs.python.org  Tue Jul  3 23:00:03 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 03 Jul 2012 21:00:03 +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: <1341349203.1.0.355766042377.issue12967@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +serwy

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

From report at bugs.python.org  Tue Jul  3 23:06:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Jul 2012 21:06:53 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1341348995.94.0.179025218811.issue15210@psf.upfronthosting.co.za>
Message-ID: <1341349545.3480.3.camel@localhost.localdomain>


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

> Any suggestions on how to make the test work better?

I would suggest tracking what causes the failure. It seems to be
ordering-dependent, so the devguide is your friend:
http://docs.python.org/devguide/buildbots.html#ordering-dependent-failures
;)

----------

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

From report at bugs.python.org  Tue Jul  3 23:50:10 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 03 Jul 2012 21:50:10 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>
Message-ID: <1341352210.75.0.30681235748.issue15210@psf.upfronthosting.co.za>


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

The tests that fail in succession are these:

./python -m test -uall -v test_importlib test_import

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

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

From report at bugs.python.org  Wed Jul  4 00:13:58 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 03 Jul 2012 22:13:58 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>
Message-ID: <1341353638.96.0.671171410233.issue15210@psf.upfronthosting.co.za>


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

If I comment out this, both tests run OK (I don't know if that
breaks anything else though):

diff --git a/Lib/importlib/test/test_api.py b/Lib/importlib/test/test_api.py
--- a/Lib/importlib/test/test_api.py
+++ b/Lib/importlib/test/test_api.py
@@ -172,7 +172,7 @@
                 del sys.modules[name]
             except KeyError:
                 continue
-        modules['_frozen_importlib'] = None
+        # modules['_frozen_importlib'] = None
         import importlib
         for name, module in modules.items():
             sys.modules[name] = module

----------

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

From report at bugs.python.org  Wed Jul  4 01:38:10 2012
From: report at bugs.python.org (Jason Spiro)
Date: Tue, 03 Jul 2012 23:38:10 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1340423716.6.0.746829857651.issue3561@psf.upfronthosting.co.za>
Message-ID: <CAAA-8XzEC1UF4-VuwJPxX-Z9FHdtUh8bPKXnMMoyR_nFJbqiSg@mail.gmail.com>


Jason Spiro <jasonspiro4 at gmail.com> added the comment:

Just a few comments on your new UI design <http://i.imgur.com/415Y1.png>:

== Suggestion 1 ==

It seems, from your screenshot, that you plan to hide the [ Next > ]
and [ Cancel ] buttons, and show your [ Yes ] and [ No ] buttons
instead.  This is doing something completely unexpected to the user.
I've used hundreds or thousands of Windows installers and IIRC never
seen such a thing.

Instead, may I suggest a checkbox:

    [x] Prepend the Python folder to the PATH environment variable (recommended)

and leaving the [ Next > ] and [ Cancel ] buttons as-is.

== Suggestion 2 ==

Better yet, get rid of the screen which talks about changing the PATH
entirely.  Instead, on the feature-selection screen, make the
prepend-Python-to-PATH option be selected by default.

Why not try implementing this suggestion in the next 3.3.0 beta?  Then
you can see if the tech-support burden increases or decreases.

----------

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

From report at bugs.python.org  Wed Jul  4 03:43:39 2012
From: report at bugs.python.org (Eric Snow)
Date: Wed, 04 Jul 2012 01:43:39 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <1341366219.5.0.386929962119.issue15242@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> Can the #defines appear in pyconfig.h instead?  I find it easier to
> discover them this way, and will also simplify the implementation on
> Windows.

Agreed.  I'd like to pull them into Python/sysmodule.h, though.  I'm also going to drop the part that messes with SOABI.

----------

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

From report at bugs.python.org  Wed Jul  4 04:02:06 2012
From: report at bugs.python.org (James King)
Date: Wed, 04 Jul 2012 02:02:06 +0000
Subject: [issue15246] Line coverage for collectionts.abc.Set
Message-ID: <1341367326.82.0.277858740936.issue15246@psf.upfronthosting.co.za>


New submission from James King <james at agentultra.com>:

I'm working on increasing the line-coverage of the tests for the Set ABC in the collections.abc module.

I encountered something a little funky IMO that I'm not sure is an issue or bug... but the __and__ method passes a generator object to the constructor of the Set subclass' constructor where the code seems to check for Iterator. This makes my naive tests for the '&' operator to fail. So I haven't included them in this patch, statisfied with the equality tests and isdisjoint.

First patch, advice welcome.

----------
components: Tests
files: set_abc_coverage.patch
keywords: patch
messages: 164632
nosy: agentultra
priority: normal
severity: normal
status: open
title: Line coverage for collectionts.abc.Set
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26253/set_abc_coverage.patch

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

From report at bugs.python.org  Wed Jul  4 04:55:09 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Wed, 04 Jul 2012 02:55:09 +0000
Subject: [issue15247] io.open() is inconsistent re os.open()
Message-ID: <1341370509.01.0.335541688705.issue15247@psf.upfronthosting.co.za>


New submission from Juancarlo A?ez <apalala at gmail.com>:

>>> import io
>>> d = io.open('.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IsADirectoryError: [Errno 21] Is a directory: '.'
>>> 

>>> import os
>>> d = io.open(os.open('.',0))
>>> d
<_io.TextIOWrapper name=3 mode='r' encoding='UTF-8'>
>>>

----------
components: Library (Lib)
messages: 164633
nosy: apalala
priority: normal
severity: normal
status: open
title: io.open() is inconsistent re os.open()
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Jul  4 04:56:47 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Wed, 04 Jul 2012 02:56:47 +0000
Subject: [issue15247] io.open() is inconsistent re os.open()
In-Reply-To: <1341370509.01.0.335541688705.issue15247@psf.upfronthosting.co.za>
Message-ID: <1341370607.83.0.348097895217.issue15247@psf.upfronthosting.co.za>


Juancarlo A?ez <apalala at gmail.com> added the comment:

io.open() clearly doesn't care about opening directories as long as they are passed as os.open() file descriptors. Quite unexpected!

----------

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

From report at bugs.python.org  Wed Jul  4 06:03:31 2012
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 04 Jul 2012 04:03:31 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1341374611.12.0.914967614144.issue3561@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

> == Suggestion 1 ==

I don't think it's that unexpected. I certainly didn't come up with the idea myself - I've seen them before. Surely it might be new to some people, but is it confusing? For one, we think it's an option users should know about. It's also an option that you should explicitly enable. The yes/no seemed like an easy way to ask a yes/no question if you want it.

> Instead, may I suggest a checkbox:

My first iterations of this patch used a checkbox in an additional window. I guess it's a possibility. If I can even figure out how to make any of this actually work, I'll try a version with a checkbox.

> == Suggestion 2 ==

We can't make it the default. This has been explained on this issue, other issues around the tracker, on python-dev, and in a lot of other places. Believe me, as one of the biggest Python 3 advocates you can find, making Python 3 the default installation is not the right move here. If it's on by default, it absolutely will cause problems because people just click right through the installer and their system will be modified in a way that they don't want and potentially won't know how to undo. This type of change has to be exposed in a loud and non-default way to start.

----------

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

From report at bugs.python.org  Wed Jul  4 06:24:50 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 04 Jul 2012 04:24:50 +0000
Subject: [issue11728] mbox parser incorrect behaviour
In-Reply-To: <1301573066.6.0.277247050127.issue11728@psf.upfronthosting.co.za>
Message-ID: <1341375890.5.0.434784349372.issue11728@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Some thoughts on doing "clever tricks" to enhance mbox parsing:

    http://www.jwz.org/doc/content-length.html

----------

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

From report at bugs.python.org  Wed Jul  4 07:28:42 2012
From: report at bugs.python.org (Ben Longbons)
Date: Wed, 04 Jul 2012 05:28:42 +0000
Subject: [issue15248] In "TypeError: 'tuple' object is not callable",
	suggest a comma.
Message-ID: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>


New submission from Ben Longbons <b.r.longbons at gmail.com>:

I frequently construct lists of tuples, such as:
[
  (1, 2, 3) # oops, missing comma!
  (4, 5, 6)
]

It would be nice if the error message gave a hint on what was *actually* wrong.

Although I always use homogeneous containers, the type that's not callable could be something other than 'tuple'.

You could possibly cut down on false positives (at the risk of false negatives) by checking that the not-callable object is newly constructed.

A better way to cut down on false positives would be to check that a list, tuple, or set is being constructed from a literal, but this might be more complex.

----------
messages: 164637
nosy: o11c
priority: normal
severity: normal
status: open
title: In "TypeError: 'tuple' object is not callable", suggest a comma.
type: enhancement

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

From report at bugs.python.org  Wed Jul  4 07:55:57 2012
From: report at bugs.python.org (lilydjwg)
Date: Wed, 04 Jul 2012 05:55:57 +0000
Subject: [issue15222] mailbox.mbox writes without empty line after each message
In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za>
Message-ID: <1341381357.26.0.534273255161.issue15222@psf.upfronthosting.co.za>


lilydjwg <lilydjwg at gmail.com> added the comment:

Hi, I have figured it out.

The 'mbox2' file should be in correct format now.
Run './bug.py' once to delete the last mail.
'cat newmail >> mbox2' to append a new mail to that mbox.
Run './bug.py' again.

Now, 'mbox2' doesn't have a newline at the end. (And I think a correct mbox should end with a blank line?)

----------
status: pending -> open
Added file: http://bugs.python.org/file26254/mbox2

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

From report at bugs.python.org  Wed Jul  4 07:57:59 2012
From: report at bugs.python.org (lilydjwg)
Date: Wed, 04 Jul 2012 05:57:59 +0000
Subject: [issue15222] mailbox.mbox writes without empty line after each message
In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za>
Message-ID: <1341381479.59.0.774676677948.issue15222@psf.upfronthosting.co.za>


Changes by lilydjwg <lilydjwg at gmail.com>:


Added file: http://bugs.python.org/file26255/newmail

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

From report at bugs.python.org  Wed Jul  4 07:58:28 2012
From: report at bugs.python.org (lilydjwg)
Date: Wed, 04 Jul 2012 05:58:28 +0000
Subject: [issue15222] mailbox.mbox writes without empty line after each message
In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za>
Message-ID: <1341381508.83.0.252430960049.issue15222@psf.upfronthosting.co.za>


Changes by lilydjwg <lilydjwg at gmail.com>:


Added file: http://bugs.python.org/file26256/bug.py

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

From report at bugs.python.org  Wed Jul  4 08:10:46 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 04 Jul 2012 06:10:46 +0000
Subject: [issue13801] The Python 3 Docs don't highlight nonlocal
In-Reply-To: <1326720484.97.0.730349515473.issue13801@psf.upfronthosting.co.za>
Message-ID: <1341382246.07.0.612079861503.issue13801@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

What is the status of this bug?

----------

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

From report at bugs.python.org  Wed Jul  4 11:48:09 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Jul 2012 09:48:09 +0000
Subject: [issue15246] Line coverage for collectionts.abc.Set
In-Reply-To: <1341367326.82.0.277858740936.issue15246@psf.upfronthosting.co.za>
Message-ID: <1341395289.57.0.599779979798.issue15246@psf.upfronthosting.co.za>


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


----------
nosy: +rhettinger, stutzbach
stage:  -> patch review

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

From report at bugs.python.org  Wed Jul  4 12:11:39 2012
From: report at bugs.python.org (Roy Hyunjin Han)
Date: Wed, 04 Jul 2012 10:11:39 +0000
Subject: [issue10574] email.header.decode_header fails if the string contains
	multiple directives
In-Reply-To: <1338761481.64.0.11534318812.issue10574@psf.upfronthosting.co.za>
Message-ID: <CABScDVt7w7j2bJ4A7aG+zJ9-juQrQSA7_kdCUyPWJC_uCGOQGQ@mail.gmail.com>


Roy Hyunjin Han <starsareblueandfaraway at gmail.com> added the comment:

> This is fixed by the fix to issue 1079, but we have decided that fix can't be backported because it is a behavior change that might break existing working programs.

Thanks for this update.

----------

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

From report at bugs.python.org  Wed Jul  4 12:13:06 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 04 Jul 2012 10:13:06 +0000
Subject: [issue15249] email.generator.BytesGenerator doesn't mangle "From "
	lines when non-ASCII bytes are present
Message-ID: <1341396786.66.0.201550976108.issue15249@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

The _handle_text function of BytesGenerator writes the payload straight through if there surrogateescape sequences are present, and skips the "From " mangling.

----------
components: email
messages: 164641
nosy: barry, petri.lehtinen, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email.generator.BytesGenerator doesn't mangle "From " lines when non-ASCII bytes are present
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul  4 12:22:07 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 Jul 2012 10:22:07 +0000
Subject: [issue15246] Line coverage for collectionts.abc.Set
In-Reply-To: <1341367326.82.0.277858740936.issue15246@psf.upfronthosting.co.za>
Message-ID: <1341397327.35.0.494637338966.issue15246@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Can you attach the failing tests for __and__?

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Wed Jul  4 13:05:20 2012
From: report at bugs.python.org (Ollie Walsh)
Date: Wed, 04 Jul 2012 11:05:20 +0000
Subject: [issue15205] distutils dereferences symlinks on Mac OS X but not on
	Linux
In-Reply-To: <1340801621.17.0.778641533675.issue15205@psf.upfronthosting.co.za>
Message-ID: <1341399920.79.0.97360836082.issue15205@psf.upfronthosting.co.za>


Ollie Walsh <ollie.walsh at gmail.com> added the comment:

Hi,

> As I said in the other bug, symlinks handling in not fully specified

Yes. I've mostly submitted a bug report in case anybody else encounters the problem.

> At present I am not sure if having symlinks in a distribution makes sense

I agree.
In my case symlinks are being used to restructure a large legacy module into smaller packages. When creating sdists the symlinks are dereferenced on another developer's host (OSX) and all is well but they on my host (Linux) I get packages with broken symlinks.

> BTW the example you link to is not at all monkey-patching

My mistake. When I worked around this issue I did monkey-patch sdist. I also just wrapped the source path is os.path.readlink() before hardlinking. I think the approach in that link is a much better solution so I have referred to it instead.

-Ollie

----------

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

From report at bugs.python.org  Wed Jul  4 13:07:25 2012
From: report at bugs.python.org (Ollie Walsh)
Date: Wed, 04 Jul 2012 11:07:25 +0000
Subject: [issue15205] distutils dereferences symlinks on Mac OS X but not on
	Linux
In-Reply-To: <1340801621.17.0.778641533675.issue15205@psf.upfronthosting.co.za>
Message-ID: <1341400045.3.0.830521920598.issue15205@psf.upfronthosting.co.za>


Ollie Walsh <ollie.walsh at gmail.com> added the comment:

PS that should be os.readlink()

----------

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

From report at bugs.python.org  Wed Jul  4 15:38:23 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 04 Jul 2012 13:38:23 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>
Message-ID: <1341409103.27.0.361545710137.issue15210@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the diagnosis, Stefan. Unfortunately that line is the crux of the test. =) I will see if I can steal some time to look at the failure to see if there is anything obvious going on.

----------

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

From report at bugs.python.org  Wed Jul  4 16:36:07 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 04 Jul 2012 14:36:07 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
Message-ID: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The documentation for the dircmp class doesn't say that the same_files and diff_files attributes are determined using the "shallow=True" rules described in the filecmp.cmp() and filecmp.cmpfiles().  It should say this.

For example, the documentation describes diff_files as, "Files which are in both a and b, whose contents differ."  But this isn't true since files whose contents differ aren't included if their os.stat() signatures are equal.

See also issue 12932 to allow dircmp to perform non-shallow comparisons.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164646
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: document that filecmp.dircmp comparisons are "shallow"
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul  4 16:39:41 2012
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 04 Jul 2012 14:39:41 +0000
Subject: [issue15139] Speed up threading.Condition wakeup
In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za>
Message-ID: <1341412781.68.0.628020773415.issue15139@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Did this make it into 3.3?

----------
nosy: +anacrolix

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

From report at bugs.python.org  Wed Jul  4 16:41:23 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 04 Jul 2012 14:41:23 +0000
Subject: [issue12932] filecmp.dircmp does not allow non-shallow comparisons
In-Reply-To: <1315411296.33.0.213336425163.issue12932@psf.upfronthosting.co.za>
Message-ID: <1341412883.58.0.666042419236.issue12932@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

+1 for this.

Whether or not this feature is implemented, I think the documentation should state that directory comparisons are done using "shallow=True".  I created issue 15250 for this.

----------
nosy: +cjerdonek

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

From report at bugs.python.org  Wed Jul  4 16:47:08 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 Jul 2012 14:47:08 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341413228.42.0.764429030822.issue15245@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/issue15245>
_______________________________________

From report at bugs.python.org  Wed Jul  4 16:56:12 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 04 Jul 2012 14:56:12 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>
Message-ID: <1341413772.08.0.980117924348.issue15210@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I could be way off (just passing through), but the test flakiness described here seems reminiscent of a discussion we had for issue 7559.  There the solution to order-dependent tests with importlib involved calling importlib.invalidate_caches() at the appropriate time.

----------
nosy: +cjerdonek

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

From report at bugs.python.org  Wed Jul  4 17:52:38 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 04 Jul 2012 15:52:38 +0000
Subject: [issue15139] Speed up threading.Condition wakeup
In-Reply-To: <1341412781.68.0.628020773415.issue15139@psf.upfronthosting.co.za>
Message-ID: <CAGE7PNL0Om1adppXi4+YxJi3k68iOh=hVSaoxkOdpq2TvbpDag@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Nope.

----------

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

From report at bugs.python.org  Wed Jul  4 18:22:02 2012
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 04 Jul 2012 16:22:02 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341418922.81.0.289143308717.issue15245@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

eval(repr(float('nan'))) doesn't work either, so I'm not sure ast.literal_eval should. The same with float('inf').

----------
nosy: +daniel.urban

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

From report at bugs.python.org  Wed Jul  4 19:29:13 2012
From: report at bugs.python.org (Jeffrey Harper)
Date: Wed, 04 Jul 2012 17:29:13 +0000
Subject: [issue15251] new.code and new.function crashes Python iterpretter
Message-ID: <1341422953.77.0.576650378209.issue15251@psf.upfronthosting.co.za>


New submission from Jeffrey Harper <jeff1.61803 at gmail.com>:

I've attached a script that crashes the Python interpreter.  

I can get the crash to occur under Windows Vista with this version of Python:

C:\tmp\remote>c:\Python27\python.exe
Python 2.7.1 Stackless 3.1b3 060516 (release27-maint, Jan  1 2011, 13:04:37) [MSC v.1500 32 bit (Intel)] on win32

Also, I got it to segfault under Ubuntu Linux:

jharper at ubuntu:~$ uname -a
Linux ubuntu 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:29 UTC 2011 i686 GNU/Linux
jharper at ubuntu:~$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) 
[GCC 4.4.5] on linux2

Note, when I commented out the line, "pprint(code_args)", the script generated a SystemError exception instead of crashing.

----------
components: Library (Lib)
files: bug3.py
messages: 164652
nosy: jeffdharper
priority: normal
severity: normal
status: open
title: new.code and new.function crashes Python iterpretter
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file26257/bug3.py

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

From report at bugs.python.org  Wed Jul  4 19:34:13 2012
From: report at bugs.python.org (Jeffrey Harper)
Date: Wed, 04 Jul 2012 17:34:13 +0000
Subject: [issue15251] new.code and new.function crashes Python iterpretter
In-Reply-To: <1341422953.77.0.576650378209.issue15251@psf.upfronthosting.co.za>
Message-ID: <1341423253.24.0.917364063636.issue15251@psf.upfronthosting.co.za>


Jeffrey Harper <jeff1.61803 at gmail.com> added the comment:

The marshal loads and dumps don't seem to be necessary to reproduce the crash.  On both the Windows Vista and Ubuntu Linux systems, the crash still occurred when I replaced:

mcopy_code = loads(dumps(code))

with:

mcopy_code = code #loads(dumps(code))

----------

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

From report at bugs.python.org  Wed Jul  4 19:46:22 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 04 Jul 2012 17:46:22 +0000
Subject: [issue15251] new.code and new.function crashes Python iterpretter
In-Reply-To: <1341422953.77.0.576650378209.issue15251@psf.upfronthosting.co.za>
Message-ID: <1341423982.88.0.244166417073.issue15251@psf.upfronthosting.co.za>


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

You need to pass co_freevars and co_cellvars as well for your example to work. It shouldn't crash, but I don't consider this particular crash as a bug, as it is a known limitation that new.code doesn't perform all consistency checks that are necessary to guarantee that the function execution doesn't crash the interpreter.

It certainly can't be fixed in 2.6.

----------
nosy: +loewis
versions:  -Python 2.6

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

From report at bugs.python.org  Wed Jul  4 19:55:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Jul 2012 17:55:22 +0000
Subject: [issue15247] io.open() is inconsistent re os.open()
In-Reply-To: <1341370509.01.0.335541688705.issue15247@psf.upfronthosting.co.za>
Message-ID: <1341424522.6.0.46942767467.issue15247@psf.upfronthosting.co.za>


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

Good catch indeed.

----------
components: +IO
nosy: +pitrou
stage:  -> needs patch
versions: +Python 3.2

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

From report at bugs.python.org  Wed Jul  4 20:03:50 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Jul 2012 18:03:50 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>
Message-ID: <3WS97843NXzMkQ@mail.python.org>


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

New changeset 906c69928049 by Brett Cannon in branch 'default':
Issue #15210: Greatly simplify the test for supporting importlib
http://hg.python.org/cpython/rev/906c69928049

----------

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

From report at bugs.python.org  Wed Jul  4 20:05:14 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 04 Jul 2012 18:05:14 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>
Message-ID: <1341425114.46.0.0382270209613.issue15210@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I realized the problem was that _frozen_importlib was getting set to None, which won't trigger an exception since the code was just directly accessing sys.modules. I switched to an ``import ... as ...`` clause and moved to using test.support.import_fresh_module() and that seemed to fix the problem.

----------
status: open -> closed

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

From report at bugs.python.org  Wed Jul  4 20:44:32 2012
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 04 Jul 2012 18:44:32 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341427472.15.0.592845241199.issue15245@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

That's what I said by `nan` and `inf` are not literals, but their representations look like they should be.

One solution could be to add another argument to allow some extra names. Maybe a mapping, as `eval`.

----------

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

From report at bugs.python.org  Wed Jul  4 22:11:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Jul 2012 20:11:31 +0000
Subject: [issue15210] importlib.__init__ checks for the wrong exception when
	looking for _frozen_importlib
In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>
Message-ID: <1341432691.22.0.571236622557.issue15210@psf.upfronthosting.co.za>


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

Thanks Brett!

----------

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

From report at bugs.python.org  Wed Jul  4 23:22:15 2012
From: report at bugs.python.org (Jason Spiro)
Date: Wed, 04 Jul 2012 21:22:15 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1341374611.12.0.914967614144.issue3561@psf.upfronthosting.co.za>
Message-ID: <CAAA-8XySbEuF2wRJQ+NCQLNMMvXOyYHBVoEEkEJjdWht5sYc5Q@mail.gmail.com>


Jason Spiro <jasonspiro4 at gmail.com> added the comment:

I'm glad you're willing to consider using a checkbox.  It seems to fit
better with the wizard paradigm, where there are always [ < Back ], [
Next > ], and [ Cancel ] buttons onscreen.

OK, I acknowledge that a lot of third-party software still depends on
Python 2.  Fine.  Why not modify the Python 3 installer to add Python
3 to the *end* of the PATH variable, not the beginning?  Then I think
you could safely modify the PATH variable by default.

----------

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

From report at bugs.python.org  Wed Jul  4 23:40:18 2012
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 04 Jul 2012 21:40:18 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1341438018.94.0.861472212553.issue3561@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

We don't need to stay with some paradigm if it's not the best way. If I can get any of these ways to work, I may post some type of survey on python-dev.

Adding to the end wouldn't make this much of a feature. Most users have already put another Python into their path, so if they decide they want to add 3.3 to it, this option barely helps them.

Anyway, just about everything relating to this feature has been discussed on the above mentioned lists over a long period of time. The feature is implemented as is, it has already been released, and it's staying that way for 3.3. All we can do is tweak the GUI.

----------

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

From report at bugs.python.org  Wed Jul  4 23:50:31 2012
From: report at bugs.python.org (Jason Spiro)
Date: Wed, 04 Jul 2012 21:50:31 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1341438018.94.0.861472212553.issue3561@psf.upfronthosting.co.za>
Message-ID: <CAAA-8XyG98kpF6KDES+nLdjV+ZgTmAxX+FE4bYQrvpAfHZc2gA@mail.gmail.com>


Jason Spiro <jasonspiro4 at gmail.com> added the comment:

Adding Python to the end of the PATH would very much help Windows
non-experts who don't even know what a PATH is.

IMO, when Python 3.4 comes out, it'd make sense add Python to the end
of the PATH by default.  This'd help those non-experts a lot.

On 7/4/12, Brian Curtin <report at bugs.python.org> wrote:
>
> Brian Curtin <brian at python.org> added the comment:
>
> We don't need to stay with some paradigm if it's not the best way. If I can
> get any of these ways to work, I may post some type of survey on
> python-dev.
>
> Adding to the end wouldn't make this much of a feature. Most users have
> already put another Python into their path, so if they decide they want to
> add 3.3 to it, this option barely helps them.
>
> Anyway, just about everything relating to this feature has been discussed on
> the above mentioned lists over a long period of time. The feature is
> implemented as is, it has already been released, and it's staying that way
> for 3.3. All we can do is tweak the GUI.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3561>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Jul  5 00:20:44 2012
From: report at bugs.python.org (Jeffrey Harper)
Date: Wed, 04 Jul 2012 22:20:44 +0000
Subject: [issue15251] new.code and new.function crashes Python iterpretter
In-Reply-To: <1341422953.77.0.576650378209.issue15251@psf.upfronthosting.co.za>
Message-ID: <1341440444.33.0.266413351467.issue15251@psf.upfronthosting.co.za>


Jeffrey Harper <jeff1.61803 at gmail.com> added the comment:

Martin,

Thanks for your response.  I didn't know it was possible to pass freevars and cellvars to new.code.  I think the documentation needs to be updated.  The documentation for 2.7.3 located at http://docs.python.org/library/new.html?highlight=new#new.code is as follows:

new.code(argcount, nlocals, stacksize, flags, codestring, constants, names, varnames, filename, name, firstlineno, lnotab)

After I got your reply to this bug report I did help(new.code) and I see that it includes freevars and cellvars as optional arguments.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

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

From report at bugs.python.org  Thu Jul  5 00:35:44 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 04 Jul 2012 22:35:44 +0000
Subject: [issue15247] io.open() is inconsistent re os.open()
In-Reply-To: <1341370509.01.0.335541688705.issue15247@psf.upfronthosting.co.za>
Message-ID: <1341441344.1.0.149072986701.issue15247@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/issue15247>
_______________________________________

From report at bugs.python.org  Thu Jul  5 01:00:03 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Wed, 04 Jul 2012 23:00:03 +0000
Subject: [issue15247] io.open() is inconsistent re os.open()
In-Reply-To: <1341370509.01.0.335541688705.issue15247@psf.upfronthosting.co.za>
Message-ID: <1341442803.48.0.173147935176.issue15247@psf.upfronthosting.co.za>


Juancarlo A?ez <apalala at gmail.com> added the comment:

Note that attempting subsequent operations on the returned object do raise IsADirectoryError.


>>> import io
>>> import os
>>> d = io.open(os.open('.',0))
>>> d.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IsADirectoryError: [Errno 21] Is a directory
>>>

----------

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

From report at bugs.python.org  Thu Jul  5 01:09:24 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 04 Jul 2012 23:09:24 +0000
Subject: [issue15033] Different exit status when using -m
In-Reply-To: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za>
Message-ID: <1341443364.9.0.972425764419.issue15033@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/issue15033>
_______________________________________

From report at bugs.python.org  Thu Jul  5 01:18:22 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 04 Jul 2012 23:18:22 +0000
Subject: [issue15020] default value for progname in pythonrun.c should be
	python3 for Python 3
In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za>
Message-ID: <1341443902.25.0.1137795379.issue15020@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Maybe it would be better to use L"python3.2" for Python 3.2 and L"python3.3" for Python 3.3.

----------
nosy: +Arfrever

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

From report at bugs.python.org  Thu Jul  5 01:20:56 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 04 Jul 2012 23:20:56 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <1341444056.81.0.12848237754.issue15242@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/issue15242>
_______________________________________

From report at bugs.python.org  Thu Jul  5 03:54:32 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 05 Jul 2012 01:54:32 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341453272.36.0.595352915894.issue15245@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't think literal_eval should handle anything which is not syntax.

----------

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

From report at bugs.python.org  Thu Jul  5 04:34:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Jul 2012 02:34:01 +0000
Subject: [issue15033] Different exit status when using -m
In-Reply-To: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za>
Message-ID: <3WSNRq2zySzNBB@mail.python.org>


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

New changeset fcbd3bda7c0f by Senthil Kumaran in branch '3.2':
Fix issue # 15033 - Return the proper exitcode for failure when modules are invoked using -m switch. Patch contributed by Jeff Knupp
http://hg.python.org/cpython/rev/fcbd3bda7c0f

New changeset 1186d68715cc by Senthil Kumaran in branch 'default':
Fix issue # 15033 - Return the proper exitcode for failure when modules are invoked using -m switch. Patch contributed by Jeff Knupp
http://hg.python.org/cpython/rev/1186d68715cc

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

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

From report at bugs.python.org  Thu Jul  5 04:50:44 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Jul 2012 02:50:44 +0000
Subject: [issue15033] Different exit status when using -m
In-Reply-To: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za>
Message-ID: <3WSNq74DsFzNCm@mail.python.org>


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

New changeset 55b3de6d701e by Senthil Kumaran in branch '2.7':
Fix closes issue # 15033 - Return the proper exitcode for failure when modules are invoked using -m switch. Patch contributed by Jeff Knupp
http://hg.python.org/cpython/rev/55b3de6d701e

----------

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

From report at bugs.python.org  Thu Jul  5 04:53:26 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 05 Jul 2012 02:53:26 +0000
Subject: [issue15033] Different exit status when using -m
In-Reply-To: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za>
Message-ID: <1341456806.01.0.259078809087.issue15033@psf.upfronthosting.co.za>


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

Thanks for the patch Jeff and thanks for the guidance, Nick. 
Committed this in all branches.

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

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

From report at bugs.python.org  Thu Jul  5 05:23:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 03:23:59 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1341458639.11.0.137413551411.issue15250@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> needs patch
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Jul  5 06:11:11 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jul 2012 04:11:11 +0000
Subject: [issue12535] Chained tracebacks are confusing because the first
	traceback is minimal
In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>
Message-ID: <1341461471.51.0.301240927453.issue12535@psf.upfronthosting.co.za>


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

I've thought of a different approach to this which should be less hazardous to doctests: include the truncation warning in the *traceback* section, rather than in the header. doctests already ignore the details of that section because checking it is too fragile.

cc'ing Georg because I think this a potentially big win for the usability of chained tracebacks, but also think it is dubious from a feature vs fix point of view.

With the change I'm considering, truncated tracebacks would look something like:

Traceback (most recent call last):
  <truncated: another exception occurred>
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 466, in __getattr__
    return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/email6/Lib/mailbox.py", line 1631, in set_flags
    self.replace_header('Status', status_flags)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 495, in replace_header
    print('rep', self.header_factory)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 469, in __getattr__
    self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'

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

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

From report at bugs.python.org  Thu Jul  5 06:18:26 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 05 Jul 2012 04:18:26 +0000
Subject: [issue15249] email.generator.BytesGenerator doesn't mangle "From "
	lines when non-ASCII bytes are present
In-Reply-To: <1341396786.66.0.201550976108.issue15249@psf.upfronthosting.co.za>
Message-ID: <1341461906.2.0.709372239303.issue15249@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a test case that fails.

----------
keywords: +patch
Added file: http://bugs.python.org/file26258/issue115249_test.patch

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

From report at bugs.python.org  Thu Jul  5 06:26:26 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 05 Jul 2012 04:26:26 +0000
Subject: [issue15222] mailbox.mbox writes without empty line after each message
In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za>
Message-ID: <1341462386.88.0.0796324759238.issue15222@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Well, by appending newmail to the mailbox, you effectively break the next-to-last message by not inserting a newline after it. This can also be achieved by adding a message that doesn't end in a newline to the mbox (using the mailbox module).

The real bug is that mailbox doesn't insert an empty line after each message, which it should do even if the message doesn't end in a newline. This breaks appending new messages (either by cat message >> mbox or by mailbox.py itself), and it might also break mbox parsing in other programs that search for starts of messages using "\n\nFrom ".

----------
components: +email
nosy: +barry, r.david.murray

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

From report at bugs.python.org  Thu Jul  5 09:32:45 2012
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 05 Jul 2012 07:32:45 +0000
Subject: [issue15252] Delivery reports about your e-mail
In-Reply-To: <1341464098.25.0.322461682765.issueNone@psf.upfronthosting.co.za>
Message-ID: <1341473565.78.0.257064320294.issue15252@psf.upfronthosting.co.za>


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

What fresh hell is this?  Bob, do you have a virus or something?

----------
nosy: +larry

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

From report at bugs.python.org  Thu Jul  5 09:33:07 2012
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 05 Jul 2012 07:33:07 +0000
Subject: [issue15252] Delivery reports about your e-mail
In-Reply-To: <1341464098.25.0.322461682765.issueNone@psf.upfronthosting.co.za>
Message-ID: <1341473587.96.0.594209022539.issue15252@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
nosy:  -larry

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

From report at bugs.python.org  Thu Jul  5 09:38:07 2012
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 05 Jul 2012 07:38:07 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <1341473887.04.0.325787020431.issue15242@psf.upfronthosting.co.za>


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

Sorry for the pedantry, but: I read the title of this bug as wanting these two values to be the exact same pointer.  If you're talking about putting a constant string in a header file, you'll get an (identical) copy of that string in every .o that references it (unless your linker collapses identical strings, which I don't know if they do).

>From the description, it sounds like you want them to merely be guaranteed identical strings, but they don't have to be the same exact pointer.

tl;dr: do you mean "=="?  the title implies you mean "is".

----------
nosy: +larry

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

From report at bugs.python.org  Thu Jul  5 10:27:14 2012
From: report at bugs.python.org (Vincent Pelletier)
Date: Thu, 05 Jul 2012 08:27:14 +0000
Subject: [issue15253] xmlrpclib.ServerProxy does not support 2-tuple value for
	uri parameter
Message-ID: <1341476834.17.0.988428605754.issue15253@psf.upfronthosting.co.za>


New submission from Vincent Pelletier <plr.vincent at gmail.com>:

SafeTransport class supports a 2-tuple as uri, in order to pass x509 parameters to httplib.HTTPSConnection .
xmlrpclib.ServerProxy.__init__ fails when given such tuple, because it calls:
  urllib.splittype(uri)
without checking uri type first.

Minimal test case to reproduce is:

import xmlrpclib
xmlrpclib.ServerProxy(('https://example.com', {}))

----------
messages: 164676
nosy: vpelletier
priority: normal
severity: normal
status: open
title: xmlrpclib.ServerProxy does not support 2-tuple value for uri parameter
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul  5 10:46:50 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 05 Jul 2012 08:46:50 +0000
Subject: [issue15253] xmlrpclib.ServerProxy does not support 2-tuple value for
	uri parameter
In-Reply-To: <1341476834.17.0.988428605754.issue15253@psf.upfronthosting.co.za>
Message-ID: <1341478010.88.0.869579547966.issue15253@psf.upfronthosting.co.za>


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

This is not a bug; the uri parameter is documented as an URI.

Your report can be considered as a feature request (for supporting non-URI values for the uri parameter), however, Python 2 is closed for new features, so this could only be added for 3.x.

Closing this as "won't fix". See

http://www.velocityreviews.com/forums/t710620-python-xmlrpc-client-with-ssl-client-certificates-and-standard-modules.html#post_message_4004113

for a possible work-around.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Jul  5 10:56:21 2012
From: report at bugs.python.org (Vincent Pelletier)
Date: Thu, 05 Jul 2012 08:56:21 +0000
Subject: [issue15253] xmlrpclib.ServerProxy does not support 2-tuple value for
	uri parameter
In-Reply-To: <1341476834.17.0.988428605754.issue15253@psf.upfronthosting.co.za>
Message-ID: <1341478581.04.0.445838709761.issue15253@psf.upfronthosting.co.za>


Vincent Pelletier <plr.vincent at gmail.com> added the comment:

Then I guess SafeTransport should be cleaned to remove its dead code (tuple host handling), and the class you link to should be included (in spirit if not verbatim) in xmlrpclib.

Also, sorry, I realized after posting that this bug is a dupe of #1581. But the closing reason here is more convincing to me than on #1581.

Thanks.

----------

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

From report at bugs.python.org  Thu Jul  5 14:05:42 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 05 Jul 2012 12:05:42 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341489942.41.0.890731628618.issue15245@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I don't think literal_eval should handle anything which is not syntax.
+1

-1 on supporting 'inf' and 'nan'
-0 on supporting 'Ellipsis' or '...';  seems harmless, but I don't really see the point.

----------

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

From report at bugs.python.org  Thu Jul  5 14:45:51 2012
From: report at bugs.python.org (Bob Ippolito)
Date: Thu, 05 Jul 2012 12:45:51 +0000
Subject: [issue15252] Delivery reports about your e-mail
In-Reply-To: <1341473565.78.0.257064320294.issue15252@psf.upfronthosting.co.za>
Message-ID: <CACwMPm97xwLjHwB0aTXxH7bJo2iYKE9UcGtNBPCvdM4-UKXtDQ@mail.gmail.com>


Bob Ippolito <bob at redivi.com> added the comment:

I doubt it, it's more likely that this email came from somewhere else with
my address.

On Thursday, July 5, 2012, Larry Hastings wrote:

>
> Larry Hastings <larry at hastings.org <javascript:;>> added the comment:
>
> What fresh hell is this?  Bob, do you have a virus or something?
>
> ----------
> nosy: +larry
>
> _______________________________________
> Python tracker <report at bugs.python.org <javascript:;>>
> <http://bugs.python.org/issue15252>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Jul  5 14:52:12 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 05 Jul 2012 12:52:12 +0000
Subject: [issue15252] Delivery reports about your e-mail
In-Reply-To: <1341464098.25.0.322461682765.issueNone@psf.upfronthosting.co.za>
Message-ID: <1341492732.95.0.621473219678.issue15252@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Jul  5 16:21:54 2012
From: report at bugs.python.org (Chris Wright)
Date: Thu, 05 Jul 2012 14:21:54 +0000
Subject: [issue15254] 08 is invalid token in lists.
Message-ID: <1341498114.62.0.773022123174.issue15254@psf.upfronthosting.co.za>


New submission from Chris Wright <rikkitikkitavi at gmail.com>:

Python 2.6.6 tk 8.5
Idle 2.6.6

I was trying to generate a multidimensional list, and my test list kept giving errors highlighting 08 as an invalid token.

>>> cube = [[[01,02,03],[04,05,06],[07,08,09]],[[11,12,13],[14,15,16],[17,18,19]],[[21,22,3],[24,25,26],[27,28,29]]]
SyntaxError: invalid token
>>> cube = [[[01,02,03,04,05,06,07,08]]
SyntaxError: invalid token
>>> cube = [08]
SyntaxError: invalid token

----------
components: IDLE
messages: 164681
nosy: Chris.Wright
priority: normal
severity: normal
status: open
title: 08 is invalid token in lists.
versions: Python 2.6

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

From report at bugs.python.org  Thu Jul  5 16:29:16 2012
From: report at bugs.python.org (Tim Golden)
Date: Thu, 05 Jul 2012 14:29:16 +0000
Subject: [issue15254] 08 is invalid token in lists.
In-Reply-To: <1341498114.62.0.773022123174.issue15254@psf.upfronthosting.co.za>
Message-ID: <1341498556.07.0.32667769413.issue15254@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

A "0" prefix to a number is taken by Python 2.x to introduce a series of octal (base 8) digits. You can't have 8 in base 8 so the number (and anything higher) is rejected.

----------
nosy: +tim.golden
resolution:  -> rejected
stage:  -> committed/rejected

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

From report at bugs.python.org  Thu Jul  5 16:29:22 2012
From: report at bugs.python.org (Tim Golden)
Date: Thu, 05 Jul 2012 14:29:22 +0000
Subject: [issue15254] 08 is invalid token in lists.
In-Reply-To: <1341498114.62.0.773022123174.issue15254@psf.upfronthosting.co.za>
Message-ID: <1341498562.14.0.719346599679.issue15254@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
status: open -> closed

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

From report at bugs.python.org  Thu Jul  5 17:41:57 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 05 Jul 2012 15:41:57 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <1341502917.19.0.226164272425.issue15242@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

tl;dr: "==", not "is"

Shouldn't tl;dr go first, else it seems a little pointless since I already read the whole thing. At which point the tl;dr is really just a summary of what I just read, not a "didn't read" line. Just being pedantic. =)

----------

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

From report at bugs.python.org  Thu Jul  5 17:48:05 2012
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Thu, 05 Jul 2012 15:48:05 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341503285.8.0.0409777709765.issue15245@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

Of course `nan` and `inf` are part of the syntax! The `ast.parse` function recognize them as `Name`. 

So that works:

>>> ast.dump(ast.parse('True'))
"Module(body=[Expr(value=Name(id='True', ctx=Load()))])"

>>> ast.dump(ast.parse('inf'))
"Module(body=[Expr(value=Name(id='inf', ctx=Load()))])"

>>> inf = float('inf')
>>> eval('inf')
inf

I've run into some literals with `Ellipsis` and `inf` and couldn't load them with literal_eval. That's why I'm proposing that.

The thing about `nan` and `inf` is because they are the *only* representations of float numbers produced by the interpreter that cannot be loaded.

Something like that could solve the problem keeping `literal_eval` safe and allowing other names:

ast.literal_eval('[1.0, 2.0, inf]', {'inf': float('inf')})

----------

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

From report at bugs.python.org  Thu Jul  5 18:35:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 16:35:52 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341506152.43.0.609632096842.issue15243@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, ncoghlan
stage:  -> needs patch
versions: +Python 3.2

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

From report at bugs.python.org  Thu Jul  5 18:37:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 16:37:59 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341506279.62.0.754388630711.issue15245@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, georg.brandl

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

From report at bugs.python.org  Thu Jul  5 18:47:07 2012
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 05 Jul 2012 16:47:07 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341506827.6.0.513952941101.issue15243@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

__prepare__ is not implicitly a staticmethod, and it is called exactly as documented (also in types.prepare_class). There is no implicit first argument because the method is called on the (meta)class object.

----------

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

From report at bugs.python.org  Thu Jul  5 18:48:24 2012
From: report at bugs.python.org (Joshua Cogliati)
Date: Thu, 05 Jul 2012 16:48:24 +0000
Subject: [issue15020] default value for progname in pythonrun.c should be
	python3 for Python 3
In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za>
Message-ID: <1341506904.54.0.379725396952.issue15020@psf.upfronthosting.co.za>


Joshua Cogliati <jrincayc at gmail.com> added the comment:

> Joshua: what command did you run under strace?

A program I created that embeds python3.  I could create a minimum piece of code that triggered the bug if needed.

> Maybe it would be better to use L"python3.2" for Python 3.2 and L"python3.3" for Python 3.3.

L"python3.2" and L"python3.3" would work better than the current L"python" since calculate_path assumes that progname is the name of an actual executable for python 3.  It only sorta works now with L"python" if python 2 and python 3 are installed in the same location, which was not the case for me since python 2 came with the system and python 3 was a local install.

----------

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

From brad at 16systems.com  Thu Jul  5 18:59:05 2012
From: brad at 16systems.com (Brad Tilley)
Date: Thu, 5 Jul 2012 12:59:05 -0400 (EDT)
Subject: [issue15100] Race conditions in shutil.copy,
	shutil.copy2 and shutil.copyfile 
Message-ID: <47008.128.173.192.90.1341507545.squirrel@webmail.tuffmail.net>

"Additionally, shutil.copyfile procedure seems to have a problem with
symlinks that could result in the corruption of content of any file on
filesystem (in favorable conditions)."

---

Does the shutil.copyfile corruption issue impact Python 2.6? And, what
sort of "favorable conditions" need to exist for this to happen? I ask
because we are seeing some file corruption on a GPFS filesystem where we
are using Python 2.6 and shutil.copyfile with symlinks.

I'm not on this list, so cc me if you reply to the list and want me to see
the response.

Thanks,

Brad


From report at bugs.python.org  Thu Jul  5 19:46:31 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 05 Jul 2012 17:46:31 +0000
Subject: [issue15253] xmlrpclib.ServerProxy does not support 2-tuple value for
	uri parameter
In-Reply-To: <1341476834.17.0.988428605754.issue15253@psf.upfronthosting.co.za>
Message-ID: <1341510391.3.0.701656433697.issue15253@psf.upfronthosting.co.za>


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

The situation is now much different from what it was for #1561. Python 2 is closed for anything but bug fixes; this rules out code cleanup as well.

----------

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

From report at bugs.python.org  Thu Jul  5 19:55:05 2012
From: report at bugs.python.org (andisthermal)
Date: Thu, 05 Jul 2012 17:55:05 +0000
Subject: [issue15255] glose_Fb
Message-ID: <1341510905.93.0.746184432871.issue15255@psf.upfronthosting.co.za>


New submission from andisthermal <andisthermal.555 at gmail.com>:

<p>This automatic page generator is the easiest way to create beautiful pages for all of your projects. Author your page content here using GitHub Flavored Markdown, select a template crafted by a designer, and publish. After your page is generated, you can check out the new branch:</p>

<pre><code>$ cd your_repo_root/repo_name
$ git fetch origin
$ git checkout gh-pages
</code></pre>

<p>If you're using the GitHub for Mac, simply sync your repository and you'll see the new branch.</p>

<h3>Designer Templates</h3>

----------
components: XML
files: Fb.init.js
hgrepos: 138
messages: 164688
nosy: andisthermal555
priority: normal
severity: normal
status: open
title: glose_Fb
type: security
versions: 3rd party
Added file: http://bugs.python.org/file26261/Fb.init.js

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

From report at bugs.python.org  Thu Jul  5 20:16:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Jul 2012 18:16:13 +0000
Subject: [issue15020] default value for progname in pythonrun.c should be
	python3 for Python 3
In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za>
Message-ID: <1341512173.24.0.500142035574.issue15020@psf.upfronthosting.co.za>


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

Hmm, actually, there is a potential problem. While "python3" is the official binary under POSIX, under Windows it is "python" (well, "python.exe").

Joshua, if you are embedding Python, why don't you simply call Py_SetPath to set the search path appropriately? Or is it not enough? (I've lost memory of the mazy details of how we calculate paths :-S).

----------

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

From report at bugs.python.org  Thu Jul  5 20:36:36 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 18:36:36 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1341513396.04.0.888875379284.issue10716@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Modernize pydoc to use CSS -> Modernize pydoc to use better HTML and separate CSS

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

From report at bugs.python.org  Thu Jul  5 20:36:48 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 18:36:48 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1341513408.04.0.654969956533.issue10716@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: lukasz.langa -> eric.araujo
stage:  -> patch review
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Thu Jul  5 20:43:29 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 18:43:29 +0000
Subject: [issue15248] In "TypeError: 'tuple' object is not callable",
	explain that a comma may be missing
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1341513809.04.0.566850208438.issue15248@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
title: In "TypeError: 'tuple' object is not callable", suggest a comma. -> In "TypeError: 'tuple' object is not callable", explain that a comma may be missing

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

From report at bugs.python.org  Thu Jul  5 20:44:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 18:44:38 +0000
Subject: [issue15255] glose_Fb
In-Reply-To: <1341510905.93.0.746184432871.issue15255@psf.upfronthosting.co.za>
Message-ID: <1341513878.13.0.0893002156769.issue15255@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy:  -andisthermal555
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: security -> 

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

From report at bugs.python.org  Thu Jul  5 20:44:47 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 18:44:47 +0000
Subject: [issue15255] glose_Fb
In-Reply-To: <1341510905.93.0.746184432871.issue15255@psf.upfronthosting.co.za>
Message-ID: <1341513887.77.0.851467731947.issue15255@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file26261/Fb.init.js

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

From report at bugs.python.org  Thu Jul  5 20:44:58 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 18:44:58 +0000
Subject: [issue15255] spam / garbage report
In-Reply-To: <1341510905.93.0.746184432871.issue15255@psf.upfronthosting.co.za>
Message-ID: <1341513898.81.0.0995641246008.issue15255@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: glose_Fb -> spam / garbage report

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

From report at bugs.python.org  Thu Jul  5 20:49:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 18:49:21 +0000
Subject: [issue8996] Add a default role to allow writing bare `len` instead of
	:func:`len`
In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>
Message-ID: <1341514161.22.0.412135538752.issue8996@psf.upfronthosting.co.za>


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

> for example, as a result of documentation merge it both
> :func:`someref` and :class:`someref` can appear
I think this would cause a warning from Sphinx, as all class/meth/func/mod/etc roles look up in the same namespace (what Georg said).

Benjamin is -1 for explicitness
I am -0 because of the ` vs. `` possible ambiguity?I prefer disabling the default role altogether
Georg, are you still +1 or should we reject this?

----------

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

From report at bugs.python.org  Thu Jul  5 20:53:41 2012
From: report at bugs.python.org (Joshua Cogliati)
Date: Thu, 05 Jul 2012 18:53:41 +0000
Subject: [issue15020] default value for progname in pythonrun.c should be
	python3 for Python 3
In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za>
Message-ID: <1341514421.21.0.770989866581.issue15020@psf.upfronthosting.co.za>


Joshua Cogliati <jrincayc at gmail.com> added the comment:

> Joshua, if you are embedding Python, why don't you simply call Py_SetPath to set the search path appropriately? Or is it not enough? (I've lost memory of the mazy details of how we calculate paths :-S).

Setting Py_SetPath manually would basically require me to replicate the work done in Modules/getpath.c to figure out where the python libraries are.  I already set PYTHONPATH to get it to find my own modules.  (Note that there is a big difference between setting PYTHONPATH the environmental variable and calling Py_SetPath, Py_SetPath assumes that you are setting the python library module paths as well.)

The basic problem is that in function calculate_path (inside of Modules/getpath.c ) it has the following code:

char *_path = getenv("PATH");
...
wchar_t *prog = Py_GetProgramName();
...
 while (1) {
...
            joinpath(progpath, prog);
            if (isxfile(progpath))
                break;
...

which goes through the path and tries to find an executable with the same name as returned by Py_GetProgramName()

So if I do a """Py_SetProgramName(L"python3");""" that method works because prog="python3" but if I don't then the method fails because prog="python".  

Basically, to fix this bug, somehow, "wchar_t *prog =" in calculate_path needs to get the actual python executable for this version of python.

----------

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

From report at bugs.python.org  Thu Jul  5 20:55:28 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Jul 2012 18:55:28 +0000
Subject: [issue15020] default value for progname in pythonrun.c should be
	python3 for Python 3
In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za>
Message-ID: <1341514528.64.0.197226744752.issue15020@psf.upfronthosting.co.za>


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

Okay, that's convincing enough. Besides, I don't think it has ever worked for Windows, since it misses the adding of a ".exe" suffix.

----------

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

From report at bugs.python.org  Thu Jul  5 20:57:49 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Thu, 05 Jul 2012 18:57:49 +0000
Subject: [issue15256] Typo in error message
Message-ID: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>


New submission from Marc Abramowitz <msabramo at gmail.com>:

>From a failing unit test with coverage.py, I noticed what seems to be a slight typo in the error message when a module cannot be imported:

diff -r 1186d68715cc Lib/imp.py
--- a/Lib/imp.py	Wed Jul 04 19:33:45 2012 -0700
+++ b/Lib/imp.py	Thu Jul 05 11:50:25 2012 -0700
@@ -230,7 +230,7 @@
                 continue
             break  # Break out of outer loop when breaking out of inner loop.
     else:
-        raise ImportError('No module name {!r}'.format(name), name=name)
+        raise ImportError('No module named {!r}'.format(name), name=name)
 
     encoding = None
     if mode == 'U':

Note the missing "d". This makes it match similar existing error messages:

Lib/importlib/_bootstrap.py
1238:_ERR_MSG = 'No module named {!r}'

Lib/modulefinder.py
185:        self.msgout(4, "raise ImportError: No module named", qname)
186:        raise ImportError("No module named " + qname)
198:                self.msgout(4, "raise ImportError: No module named", mname)
199:                raise ImportError("No module named " + mname)
215:                    raise ImportError("No module named " + subname)

Lib/runpy.py
106:        raise ImportError("No module named %s" % mod_name)

I wonder if this can be centralized to ensure that all code uses the exact same message?

----------
components: Library (Lib)
messages: 164693
nosy: Marc.Abramowitz, brett.cannon
priority: normal
severity: normal
status: open
title: Typo in error message
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Jul  5 20:59:30 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Jul 2012 18:59:30 +0000
Subject: [issue15020] default value for progname in pythonrun.c should be
	python3 for Python 3
In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za>
Message-ID: <3WSpJx1zVvzNNc@mail.python.org>


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

New changeset c97d78415f5a by Antoine Pitrou in branch '3.2':
Issue #15020: The program name used to search for Python's path is now "python3" under Unix, not "python".
http://hg.python.org/cpython/rev/c97d78415f5a

New changeset 61e6ac40c816 by Antoine Pitrou in branch 'default':
Issue #15020: The program name used to search for Python's path is now python3 under Unix, not python.
http://hg.python.org/cpython/rev/61e6ac40c816

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

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

From report at bugs.python.org  Thu Jul  5 21:00:11 2012
From: report at bugs.python.org (Ned Batchelder)
Date: Thu, 05 Jul 2012 19:00:11 +0000
Subject: [issue15256] Typo in error message
In-Reply-To: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>
Message-ID: <1341514811.56.0.712979091944.issue15256@psf.upfronthosting.co.za>


Changes by Ned Batchelder <ned at nedbatchelder.com>:


----------
nosy: +nedbat

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

From report at bugs.python.org  Thu Jul  5 21:00:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Jul 2012 19:00:44 +0000
Subject: [issue15020] default value for progname in pythonrun.c should be
	python3 for Python 3
In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za>
Message-ID: <1341514844.63.0.0285306183085.issue15020@psf.upfronthosting.co.za>


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

This should be fixed now. Thanks!

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

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

From report at bugs.python.org  Thu Jul  5 21:59:06 2012
From: report at bugs.python.org (William Schwartz)
Date: Thu, 05 Jul 2012 19:59:06 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341518346.88.0.75057421281.issue15243@psf.upfronthosting.co.za>


William Schwartz <wkschwartz at gmail.com> added the comment:

Daniel, Good point. However it would still be useful for documentation to point out that __prepare__ can be passed the metaclass as the implicit first argument by being decorated by classmethod.

I'll post a small patch when I get a chance to add a sentence saying as much in the documentation and reorganize the test cases in Lib/test/test_metaclass.py to make it part of the narrative of the doctests.

----------

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

From report at bugs.python.org  Thu Jul  5 22:52:19 2012
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 05 Jul 2012 20:52:19 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341521539.64.0.620484242881.issue15243@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Actually the docs contained a similar sentence ("If the metaclass has a :meth:`__prepare__` attribute (usually implemented as a class or static method), ..."), but it was removed in befd56673c80 when Nick rewrote this section.

----------

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

From report at bugs.python.org  Thu Jul  5 23:00:35 2012
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Thu, 05 Jul 2012 21:00:35 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341522035.29.0.691140704264.issue15245@psf.upfronthosting.co.za>


Changes by Jo?o Bernardo <jbvsmo at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file26262/ast.py.diff

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

From report at bugs.python.org  Thu Jul  5 23:02:32 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 21:02:32 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341522152.51.0.585453684387.issue15245@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review
stage:  -> test needed

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

From report at bugs.python.org  Fri Jul  6 00:10:49 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 05 Jul 2012 22:10:49 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341526249.57.0.1271372416.issue15245@psf.upfronthosting.co.za>


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

I like the 'safe_names' idea, but is this patch supposed to work?

>>> isinstance(None, Ellipsis)
TypeError: isinstance() arg 2 must be a type or tuple of types

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Fri Jul  6 00:12:40 2012
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Thu, 05 Jul 2012 22:12:40 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341526360.97.0.786845532143.issue15245@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

Ellipsis in this context is `_ast.Ellipsis`, not the original one...

There's no TypeError there as `_ast.Ellipsis` is a class.

----------

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

From report at bugs.python.org  Fri Jul  6 00:19:11 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 05 Jul 2012 22:19:11 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341526751.92.0.588988060569.issue15245@psf.upfronthosting.co.za>


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

Ah right, that's confusing indeed...

Unit tests and doc updates are needed though.

----------

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

From report at bugs.python.org  Fri Jul  6 00:40:30 2012
From: report at bugs.python.org (rian)
Date: Thu, 05 Jul 2012 22:40:30 +0000
Subject: [issue15257] Misc/.gdbinit:pystack is too brittle
Message-ID: <1341528030.36.0.158267038298.issue15257@psf.upfronthosting.co.za>


New submission from rian <rian at dropbox.com>:

the `pystack`, `pystackv`, and `printframe` macros in the sample gdbinit file distributed with python are too fragile. this patch (which relies on gdb 7) is much more robust.

----------
components: None
files: mypatch.diff
keywords: patch
messages: 164701
nosy: rian
priority: normal
severity: normal
status: open
title: Misc/.gdbinit:pystack is too brittle
Added file: http://bugs.python.org/file26263/mypatch.diff

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

From report at bugs.python.org  Fri Jul  6 00:41:13 2012
From: report at bugs.python.org (Nefarious CodeMonkey, Jr.)
Date: Thu, 05 Jul 2012 22:41:13 +0000
Subject: [issue15258] argparse documentation: Improve optparse section
	regarding allow_interspersed_args
Message-ID: <1341528073.03.0.435446433545.issue15258@psf.upfronthosting.co.za>


New submission from Nefarious CodeMonkey, Jr. <nejucomo at users.sourceforge.net>:

It was not obvious from the documentation on argparse how to emulate the optparse.OptionParser.allow_interspersed_args feature.

Please add something like the following to the section titled "Upgrading optparse code" (see: http://docs.python.org/library/argparse.html#upgrading-optparse-code )

"""
* If the optparse code sets allow_interspersed_args to False, then add an argparse positional argument with nargs=argparse.REMAINDER
"""

----------
assignee: docs at python
components: Documentation
messages: 164702
nosy: docs at python, nejucomo
priority: normal
severity: normal
status: open
title: argparse documentation: Improve optparse section regarding allow_interspersed_args
type: enhancement
versions: 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/issue15258>
_______________________________________

From report at bugs.python.org  Fri Jul  6 00:43:30 2012
From: report at bugs.python.org (rian)
Date: Thu, 05 Jul 2012 22:43:30 +0000
Subject: [issue15257] Misc/.gdbinit:pystack is too brittle
In-Reply-To: <1341528030.36.0.158267038298.issue15257@psf.upfronthosting.co.za>
Message-ID: <1341528210.69.0.417329701007.issue15257@psf.upfronthosting.co.za>


Changes by rian <rian at dropbox.com>:


----------
components: +Demos and Tools -None

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

From report at bugs.python.org  Fri Jul  6 00:44:04 2012
From: report at bugs.python.org (rian)
Date: Thu, 05 Jul 2012 22:44:04 +0000
Subject: [issue15257] Misc/.gdbinit:pystack is too brittle
In-Reply-To: <1341528030.36.0.158267038298.issue15257@psf.upfronthosting.co.za>
Message-ID: <1341528244.04.0.068292649867.issue15257@psf.upfronthosting.co.za>


Changes by rian <rian at dropbox.com>:


----------
versions: +Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jul  6 01:01:46 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 05 Jul 2012 23:01:46 +0000
Subject: [issue15259] "Helping with Documentation" references missing
	dailybuild.py
Message-ID: <1341529306.29.0.594209420115.issue15259@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The intro to the "Helping with Documentation" section of the Developer's Guide--

http://docs.python.org/devguide/docquality.html#helping-with-documentation

includes a reference to a Doc/tools/dailybuild.py script, but this script does not seem to exist in the source tree.

----------
components: Devguide
keywords: easy
messages: 164703
nosy: cjerdonek, ezio.melotti
priority: normal
severity: normal
status: open
title: "Helping with Documentation" references missing dailybuild.py
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  6 01:12:25 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 05 Jul 2012 23:12:25 +0000
Subject: [issue15260] Mention how to order Misc/NEWS entries
Message-ID: <1341529945.6.0.935201074505.issue15260@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think it would help if the "Commit Messages and NEWS Entries" subsection of the Developer's Guide said something about where in the ordering new Misc/NEWS entries should be added (e.g. at the top or bottom or by importance):

http://docs.python.org/devguide/committing.html?highlight=news#commit-messages-and-news-entries

The only reference I could find was an indirect reference in the section about the Developer Log:

http://docs.python.org/devguide/developers.html

----------
components: Devguide
keywords: easy
messages: 164704
nosy: cjerdonek, ezio.melotti
priority: normal
severity: normal
status: open
title: Mention how to order Misc/NEWS entries
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  6 02:02:59 2012
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Fri, 06 Jul 2012 00:02:59 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341532979.42.0.905925902803.issue15245@psf.upfronthosting.co.za>


Changes by Jo?o Bernardo <jbvsmo at gmail.com>:


Added file: http://bugs.python.org/file26264/ast.py_with_tests.diff

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

From report at bugs.python.org  Fri Jul  6 02:03:26 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 06 Jul 2012 00:03:26 +0000
Subject: [issue15261] os.stat(fd) crashes on Windows if fd does not exist
Message-ID: <1341533006.37.0.469874920155.issue15261@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

In Python 3.3 (but not earlier) os.stat() is documented to work with file descriptors.  (os.path.exists() also works with fds since it is implemented in terms of os.stat(), although that is *not* documented.)

However, on Windows if fd is not open then os.stat(fd) triggers an assertion error or crash:

  File: f:\dd\vctools\crt_bld\self_x86\crt\src\osfinfo.c
  Line: 316
  Expression: (_osfile(fh) & FOPEN)

Note that os.fstat() fails on Windows with OSError(EBADF, ...).

----------
messages: 164705
nosy: sbt
priority: high
severity: normal
stage: needs patch
status: open
title: os.stat(fd) crashes on Windows if fd does not exist
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  6 02:10:02 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 06 Jul 2012 00:10:02 +0000
Subject: [issue15261] os.stat(fd) crashes on Windows if fd does not exist
In-Reply-To: <1341533006.37.0.469874920155.issue15261@psf.upfronthosting.co.za>
Message-ID: <1341533402.11.0.084682110739.issue15261@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

This can probably be fixed by using _PyVerify_fd().

----------

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

From report at bugs.python.org  Fri Jul  6 02:10:59 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 00:10:59 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1341533459.27.0.240266036027.issue15250@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26265/issue15250-1.patch

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

From report at bugs.python.org  Fri Jul  6 02:21:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Jul 2012 00:21:05 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341534065.7.0.124598202114.issue15245@psf.upfronthosting.co.za>


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

Thanks for the patch.  It looks good to me, but I think that adding support for Ellipsis and adding a new parameter to allow extra names are two different requests, but someone more knowledgeable than me about AST may judge differently.  My rationale is that supporting Ellipsis literals is a no-brainer addition, whereas adding an argument to support things that are not actual Python literals may be rejected.  You don?t have to split your patch in two anyway, it?s easy to do if the dev who will commit wants to.

Each change would also need a doc update.

----------
stage: test needed -> patch review

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

From report at bugs.python.org  Fri Jul  6 02:23:50 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 06 Jul 2012 00:23:50 +0000
Subject: [issue15257] Misc/.gdbinit:pystack is too brittle
In-Reply-To: <1341528030.36.0.158267038298.issue15257@psf.upfronthosting.co.za>
Message-ID: <1341534230.17.0.598047379658.issue15257@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/issue15257>
_______________________________________

From report at bugs.python.org  Fri Jul  6 02:29:41 2012
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Fri, 06 Jul 2012 00:29:41 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341534581.32.0.261803005102.issue15245@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

Just to be sure: What's a doc update? The `.rst` files are updated automatically with the doc strings?

The adding another argument should require a:
"Changed in version 3.x: Accepts a second argument ..." ?

----------

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

From report at bugs.python.org  Fri Jul  6 02:32:15 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Jul 2012 00:32:15 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341534735.48.0.142888045624.issue15245@psf.upfronthosting.co.za>


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

No, the rst documentation is maintained manually.

Look for versionchanged in the doc source files or the documentation about writing documentation to see how to document the new argument (and new supported Ellipsis literal).

----------

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

From report at bugs.python.org  Fri Jul  6 02:47:59 2012
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Fri, 06 Jul 2012 00:47:59 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341535679.3.0.180773028112.issue15245@psf.upfronthosting.co.za>


Changes by Jo?o Bernardo <jbvsmo at gmail.com>:


Added file: http://bugs.python.org/file26266/ast.py_tests_doc.diff

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

From report at bugs.python.org  Fri Jul  6 03:19:21 2012
From: report at bugs.python.org (James King)
Date: Fri, 06 Jul 2012 01:19:21 +0000
Subject: [issue15246] Line coverage for collectionts.abc.Set
In-Reply-To: <1341367326.82.0.277858740936.issue15246@psf.upfronthosting.co.za>
Message-ID: <1341537561.59.0.527236603133.issue15246@psf.upfronthosting.co.za>


James King <james at agentultra.com> added the comment:

How about a working test instead? Let me know if it looks right.

----------
Added file: http://bugs.python.org/file26267/set_abc_coverage.patch

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

From report at bugs.python.org  Fri Jul  6 03:58:43 2012
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 06 Jul 2012 01:58:43 +0000
Subject: [issue15248] In "TypeError: 'tuple' object is not callable",
	explain that a comma may be missing
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1341539923.28.0.170051232951.issue15248@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I think this suggested enhancement is unreasonable and of limited usefulness, and even if it were useful, too specialised to bother with.

The obvious message is badly misleading. When I read this:

TypeError: 'tuple' object is not callable, a comma may be missing

I look inside the tuple for a missing comma. But that's not the problem, and the error message sends me on a wild goose chase wondering how on earth a missing comma causes Python to try calling my tuple. I've been programming in Python for 15+ years and it mislead me -- what do you think it will do to beginners?

The problem is that the tuple is inside a list, and the LIST is missing a comma.

What about this example?

result = function(
    "the error has nothing to do with tuples"  # oops missed a comma
    (2, 3, 4),
    None
    )

Should the error message say something like:

TypeError: 'str' object is not callable, perhaps it is embedded in a list, tuple, 
function call or some other place you need a comma, and you forgot one 
or more commas?

I don't think so. Besides, most of the time when you get this TypeError, it will be because you genuinely tried to call what you thought was a function but wasn't, and the hint is pointless.

You tried to call a tuple as if it were a function. The reason for that is that you left out a comma in a list, but there are many other reasons that could happen, and "I frequently forget to add commas to lists" is a far too-specialised failure mode to single it out in the error message.

It is unreasonable to expect Python to debug your code for you. It tells you what you did wrong -- you called a tuple as a function -- and it is up to you to determine why.

----------
nosy: +stevenjd

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

From report at bugs.python.org  Fri Jul  6 04:14:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 02:14:26 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341540866.3.0.828004947691.issue15231@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file26268/issue-15231-1.patch

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

From report at bugs.python.org  Fri Jul  6 04:44:36 2012
From: report at bugs.python.org (Buck Golemon)
Date: Fri, 06 Jul 2012 02:44:36 +0000
Subject: [issue15009] urlsplit can't round-trip relative-host urls.
In-Reply-To: <1338935307.83.0.455725477737.issue15009@psf.upfronthosting.co.za>
Message-ID: <1341542676.98.0.853124662549.issue15009@psf.upfronthosting.co.za>


Buck Golemon <buck.golemon at amd.com> added the comment:

Let's examine x://

absolute-URI  = scheme ":" hier-part [ "?" query ]
hier-part     = "//" authority path-abempty

So this is okay if authority and path-abempty can both be empty strings.

authority     = [ userinfo "@" ] host [ ":" port ]
host          = IP-literal / IPv4address / reg-name
reg-name      = *( unreserved / pct-encoded / sub-delims )
path-abempty  = *( "/" segment )

Yep.

And the same applies for x:///y, except that path-abempty matches /y
instead of nothing.

This means these are in fact valid urls per RFC3986, counter to your claim.

----------
nosy: +bukzor

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

From report at bugs.python.org  Fri Jul  6 05:02:26 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 06 Jul 2012 03:02:26 +0000
Subject: [issue14202] The docs of xml.dom.pulldom are almost nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1341543746.53.0.66072394754.issue14202@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Fri Jul  6 05:09:36 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 06 Jul 2012 03:09:36 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1341544176.33.0.68602278946.issue1767933@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Serhiy, note that _SimpleElementPath is now gone in 3.3, since ElementPath.py is always there in stdlib. Could you update the patch to reflect this?

Another thing. I'm trying really hard to phase out the doctest tests of etree, replacing them with unittest-based tests as much as possible. The doctests are causing all kinds of trouble with parametrized testing for both the Python and the C implementations. Please don't add new doctests. If you add tests, add them to existing TestCase classes, or create new ones.

----------

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

From report at bugs.python.org  Fri Jul  6 05:12:37 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 06 Jul 2012 03:12:37 +0000
Subject: [issue9458] xml.etree.ElementTree.ElementTree.write(): encoding
	handling problems
In-Reply-To: <1280782925.67.0.136452249646.issue9458@psf.upfronthosting.co.za>
Message-ID: <1341544357.68.0.602793134406.issue9458@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Please make sure that the patch(es) apply cleanly to 3.3, since this is the version I'll be focusing on.

----------

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

From report at bugs.python.org  Fri Jul  6 05:13:48 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 06 Jul 2012 03:13:48 +0000
Subject: [issue14988] _elementtree: Raise ImportError when importing of
	pyexpat fails
In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za>
Message-ID: <1341544428.81.0.572329253963.issue14988@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
components: +Library (Lib)
stage:  -> test needed
versions: +Python 3.4 -Python 3.2

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

From report at bugs.python.org  Fri Jul  6 05:23:19 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 06 Jul 2012 03:23:19 +0000
Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow
	forcing the use of long tag closing
In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za>
Message-ID: <1341544999.73.0.458674926581.issue14377@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I see no harm in modifying the signature of the private _serialize_* functions to accept another argument or dict of options.

----------

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

From report at bugs.python.org  Fri Jul  6 06:46:15 2012
From: report at bugs.python.org (Ben Longbons)
Date: Fri, 06 Jul 2012 04:46:15 +0000
Subject: [issue15248] In "TypeError: 'tuple' object is not callable",
	explain that a comma may be missing
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1341549975.91.0.176622862713.issue15248@psf.upfronthosting.co.za>


Ben Longbons <b.r.longbons at gmail.com> added the comment:

This kind of "debug your code" is the kind of thing I've gotten used to from the Clang C/C++ compiler. Granted, compiled languages have an advantage here, but enough residual information remains for the interpreter at runtime.

And I am in no way suggesting that *every* attempt to call a non-function have the extra information.

For the cases where the error message is given, something like:
TypeError: 'tuple' object is not callable (missing preceding comma?)

The case of a homogenous container is the most important case.

I've offered two different ways to figure out whether it's a typo or an attempt to call an object that you honestly think is callable:
1. Is the called object a newly-constructed (refcount=1) tuple literal? (Also works for list, set, and dictionary literals; probably wouldn't work for string literals due to interning)
2. Does the false call occur within a container literal or function call?

I'm not intimately familiar with python bytecode or interpreter, but I'm sure anyone who is could extract this information.

----------

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

From report at bugs.python.org  Fri Jul  6 09:49:39 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 06 Jul 2012 07:49:39 +0000
Subject: [issue15261] os.stat(fd) crashes on Windows if fd does not exist
In-Reply-To: <1341533006.37.0.469874920155.issue15261@psf.upfronthosting.co.za>
Message-ID: <1341560979.86.0.644077731903.issue15261@psf.upfronthosting.co.za>


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

Many os functions started to accept file descriptors. I don't know how many are available on Windows, but IMO _PyVerify_fd() could be used for all of them; it's a no-op macro on Unix anyway.

----------
nosy: +amaury.forgeotdarc, larry

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

From report at bugs.python.org  Fri Jul  6 10:28:13 2012
From: report at bugs.python.org (Mark)
Date: Fri, 06 Jul 2012 08:28:13 +0000
Subject: [issue15262] Idle does not show traceback in other threads
Message-ID: <1341563293.08.0.285980110052.issue15262@psf.upfronthosting.co.za>


New submission from Mark <myagna01 at students.poly.edu>:

Consider the following code:

from thread import start_new
def f(): typo #there is no variable called typo
start_new(f, ())

If run from the command line, this produces a traceback.  If run from IDLE, it does not.  I suspect this is not by design.  This caused me endless grief in debugging until one happy day I discovered the traceback module.  I now write:

from thread import start_new
from traceback import print_exc
def f():
 try: typo
 except: print_exc()
start_new(f, ())

this works, but I wish I didn't need it.

----------
components: IDLE
messages: 164718
nosy: Mark
priority: normal
severity: normal
status: open
title: Idle does not show traceback in other threads
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  6 13:23:42 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Jul 2012 11:23:42 +0000
Subject: [issue15261] os.stat(fd) crashes on Windows if fd does not exist
In-Reply-To: <1341533006.37.0.469874920155.issue15261@psf.upfronthosting.co.za>
Message-ID: <3WTD8Y4GQlzNGs@mail.python.org>


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

New changeset 62b9bfbc3356 by Richard Oudkerk in branch 'default':
Issue #15261: Stop os.stat(fd) crashing on Windows when fd not open.
http://hg.python.org/cpython/rev/62b9bfbc3356

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

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

From report at bugs.python.org  Fri Jul  6 13:36:25 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 06 Jul 2012 11:36:25 +0000
Subject: [issue15261] os.stat(fd) crashes on Windows if fd does not exist
In-Reply-To: <1341533006.37.0.469874920155.issue15261@psf.upfronthosting.co.za>
Message-ID: <1341574585.75.0.533854223921.issue15261@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

> Many os functions started to accept file descriptors.  
> I don't know how many are available on Windows...

On Windows os.stat() seems to be the only one:

  >>> os.supports_fd
  {<built-in function stat>}

----------

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

From report at bugs.python.org  Fri Jul  6 14:31:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 12:31:18 +0000
Subject: [issue14649] doctest.DocTestSuite error misleading when module has no
	docstrings
In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za>
Message-ID: <1341577878.14.0.718694938911.issue14649@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
versions: +Python 3.3

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

From report at bugs.python.org  Fri Jul  6 14:32:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 12:32:47 +0000
Subject: [issue14649] doctest.DocTestSuite error misleading when module has no
	docstrings
In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za>
Message-ID: <1341577967.86.0.325574387907.issue14649@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I have attached a patch with tests.

----------
keywords: +easy, patch
stage:  -> patch review
Added file: http://bugs.python.org/file26269/issue-14649-1.patch

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

From report at bugs.python.org  Fri Jul  6 14:45:27 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 06 Jul 2012 12:45:27 +0000
Subject: [issue15261] os.stat(fd) crashes on Windows if fd does not exist
In-Reply-To: <1341533006.37.0.469874920155.issue15261@psf.upfronthosting.co.za>
Message-ID: <1341578727.94.0.0831305753984.issue15261@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


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

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

From report at bugs.python.org  Fri Jul  6 14:52:51 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 12:52:51 +0000
Subject: [issue14649] doctest.DocTestSuite error misleading when module has no
	docstrings
In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za>
Message-ID: <1341579171.9.0.644088821101.issue14649@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +r.david.murray

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

From report at bugs.python.org  Fri Jul  6 15:16:00 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jul 2012 13:16:00 +0000
Subject: [issue15257] Misc/.gdbinit:pystack is too brittle
In-Reply-To: <1341528030.36.0.158267038298.issue15257@psf.upfronthosting.co.za>
Message-ID: <1341580560.28.0.0601041637396.issue15257@psf.upfronthosting.co.za>


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


----------
nosy: +dmalcolm

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

From report at bugs.python.org  Fri Jul  6 16:16:36 2012
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 06 Jul 2012 14:16:36 +0000
Subject: [issue15263] Guard against invalid file handles in os functions
Message-ID: <1341584196.67.0.703107638593.issue15263@psf.upfronthosting.co.za>


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

#15261 shows us that Windows can crash if you pass in an invalid file handle to Windows POSIX-y functions.  We should ensure that functions which accept path-as-an-int-fd guard against this where necessary.

I propose a macro, something like

#ifdef MS_WINDOWS
#define FD_GUARD(fd) (_PyVerify_fd(fd) ? (fd) : INVALID_HANDLE_VALUE)
#else
#define FD_GUARD(fd) (fd)
#endif

----------
assignee: larry
components: Library (Lib)
messages: 164722
nosy: amaury.forgeotdarc, larry, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: Guard against invalid file handles in os functions
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  6 16:16:56 2012
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 06 Jul 2012 14:16:56 +0000
Subject: [issue15261] os.stat(fd) crashes on Windows if fd does not exist
In-Reply-To: <1341533006.37.0.469874920155.issue15261@psf.upfronthosting.co.za>
Message-ID: <1341584216.24.0.670666625941.issue15261@psf.upfronthosting.co.za>


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

The 62b9bfbc3356 changeset does more than add the guard against invalid file handles; it also adds documentation to os.path.exists documenting that it now accepts path-as-int-fd.  While this modification is fine in principle I would have preferred it was submitted separately.

----------

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

From report at bugs.python.org  Fri Jul  6 16:26:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jul 2012 14:26:30 +0000
Subject: [issue15263] Guard against invalid file handles in os functions
In-Reply-To: <1341584196.67.0.703107638593.issue15263@psf.upfronthosting.co.za>
Message-ID: <1341584790.9.0.945323994608.issue15263@psf.upfronthosting.co.za>


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

Which other functions are you thinking about?

----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Jul  6 16:47:09 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 06 Jul 2012 14:47:09 +0000
Subject: [issue15263] Guard against invalid file handles in os functions
In-Reply-To: <1341584196.67.0.703107638593.issue15263@psf.upfronthosting.co.za>
Message-ID: <1341586029.62.0.460939831301.issue15263@psf.upfronthosting.co.za>


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

Windows will also crash if you pass INVALID_HANDLE_VALUE (which is not a file descriptor) to crt functions...
How did you want to use this macro?

----------

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

From report at bugs.python.org  Fri Jul  6 17:03:50 2012
From: report at bugs.python.org (andisthermal)
Date: Fri, 06 Jul 2012 15:03:50 +0000
Subject: [issue15255] spam / garbage report
In-Reply-To: <1341510905.93.0.746184432871.issue15255@psf.upfronthosting.co.za>
Message-ID: <1341587030.01.0.356897663013.issue15255@psf.upfronthosting.co.za>


andisthermal <andisthermal.555 at gmail.com> added the comment:

#!/usr/bin/env python

"""A small wrapper file for parsing AsciiDoc files at Github."""

__author__ = "Devin Weaver" 
__copyright__ = "Copyright (C) 2009 Devin Weaver" 
__license__ = "Public Domain" 
__version__ = "0.1" 

"""
github_asciidoc.py
------------------

This is a wrapper file for parsing AsciiDoc files at github. It wraps the
current AsciiDoc API.

AsciiDoc specifications suggest using the file extension of `.txt` however this
causes conflict because there is no way to determine if a text file is an
AsciiDoc or not without pre-processing the file. This gives us two simple
options:

1. **Parse all text files**. We could have all files ending in `.txt` or
   ``README.txt`` be parsed through AsciiDoc. It will print pretty text fine
   even if it isn't formatted as such. However this could be *not what the user
   expects*.
2. **Pick a unique extension**. We could pick a unique extension (i.e.
   `.asciidoc`) to prevent clashing. Although not directly suggested by the
   author of AsciiDoc there is no standard or practice to the contrary.

Option two is recommended by myself.

Requirements
~~~~~~~~~~~~

The AsciiDoc API comes in two parts. The first is the system installation of
AsciiDoc which has a simple install_. The second part is the API script. You
can either copy this to the current directory or the application's lib folder.
There is more information on the `API page`_

The `re` package is imported here for the purpose to accomplish E-Mail address
cloaking. AsciiDoc does not offer it's own cloaking algorithm like docutils
does. So I made a simple one here to do the same. **If the expense of regex's
is too high it can be easily commented out.**

.. tip::
    AsciiDoc by default runs in *safe mode* which means it will not include
    external files that are **not** in the same directory as the `infile`.
    However since we use a StringIO through the API it should be based on the
    current working directory.

.. _install: http://www.methods.co.nz/asciidoc/userguide.html
.. _API page: http://www.methods.co.nz/asciidoc/asciidocapi.html
"""

try:
    import locale
    locale.setlocale(locale.LC_ALL, '')
except:
    pass

import sys
import cStringIO # faster then StringIO
from asciidocapi import AsciiDocAPI
from asciidocapi import AsciiDocError
import re # only needed to simulate cloak_email_addresses

def main():
    """
    Parses the given AsciiDoc file or the redirected string input and returns
    the HTML body.

    Usage: asciidoc2html < README.rst
           asciidoc2html README.rst
    """
    try:
        text = open(sys.argv[1], 'r').read()
    except IOError: # given filename could not be found
        return ''
    except IndexError: # no filename given
        text = sys.stdin.read()

    infile = cStringIO.StringIO(text)
    outfile = cStringIO.StringIO()
    asciidoc = AsciiDocAPI()
    asciidoc.options('-s')

    try:
        asciidoc.execute(infile, outfile, 'xhtml11')
    except AsciiDocError, strerror:
        str = "%s" % (strerror)
        str = str.replace("&", "&amp;") # Must be done first
        str = str.replace("<", "%lt;")
        str = str.replace(">", "%gt;")
        outfile.write ("<blockquote><strong>AsciiDoc ERROR: %s</strong></blockquote>" % (str))

    """
    Cloak email addresses

    AsciiDoc API does not have a `cloak_email_addresses` option. We can do the
    same with a set of regex but that can be expensive. Keep section commented
    to disable. So ``abc at mail.example.com`` becomes:

    -----------
    <a class="reference" href="mailto:abc&#37;&#52;&#48;mail&#46;example&#46;org">
    abc<span>&#64;</span>mail<span>&#46;</span>example<span>&#46;</span>org</a>
    -----------
    """
    def mangleEmail(matches):
        email1 = "%s&#37;&#52;&#48;%s" % (matches.group(1), matches.group(2))
        email1 = email1.replace(".", "&#46;")
        email2 = "%s<span>&#64;</span>%s" % (matches.group(1), matches.group(2))
        email2 = email2.replace(".", "<span>&#46;</span>")
        return "<a class=\"reference\" href=\"mailto:%s\">%s</a>" % (email1, email2)

    return re.sub(r'<a href="mailto:([^@]+)@([^@]+)">([^@]+)@([^@]+)</a>', mangleEmail, outfile.getvalue())
    #return outfile.getvalue()

if __name__ == '__main__':
    print main()
<div id="rainbow-message" style="display:none">
Double repositories all the way across the sky!<br/>
<a href="http://docs.python.org/devguide/triaging.html#assigned-to/">What does it mean?</a>
</div>

----------
assignee:  -> collinwinter
components: +Benchmarks -XML
hgrepos: +139
nosy: +andisthermal555, collinwinter
resolution: invalid -> fixed
status: closed -> open
type:  -> security
Added file: http://bugs.python.org/file26270/query.csv

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

From report at bugs.python.org  Fri Jul  6 17:10:42 2012
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 06 Jul 2012 15:10:42 +0000
Subject: [issue15263] Guard against invalid file handles in os functions
In-Reply-To: <1341584196.67.0.703107638593.issue15263@psf.upfronthosting.co.za>
Message-ID: <1341587442.42.0.389835180454.issue15263@psf.upfronthosting.co.za>


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

Antoine: all the functions enumerated in os.supports_fd.  Note that the set of such functions may in fact just be os.stat which is already fixed.

Amaury: If you read the checkin that fixes this problem ( 62b9bfbc3356 ) it actually deliberately passes in INVALID_HANDLE_VALUE to win32_fstat.  I admit that's kind of where I lost interest.  I'm not really a Windows developer anymore, so maybe somebody else should do it.  So I have given myself a demotion; I am no longer assigned the bug.

----------
assignee: larry -> 

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

From report at bugs.python.org  Fri Jul  6 17:14:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Jul 2012 15:14:08 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WTKGQ6YqKzNGs@mail.python.org>


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

New changeset b7cfdb48af62 by Nick Coghlan in branch 'default':
Issue 14814: Better handling of cases where octet/hextet parsing fails, including ensuring that tracebacks are still clean even when calling class constructors directly
http://hg.python.org/cpython/rev/b7cfdb48af62

----------

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

From report at bugs.python.org  Fri Jul  6 17:21:35 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jul 2012 15:21:35 +0000
Subject: [issue15263] Guard against invalid file handles in os functions
In-Reply-To: <1341584196.67.0.703107638593.issue15263@psf.upfronthosting.co.za>
Message-ID: <1341588095.65.0.0864068550497.issue15263@psf.upfronthosting.co.za>


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

> Antoine: all the functions enumerated in os.supports_fd.  Note that the 
> set of such functions may in fact just be os.stat which is already fixed.

As far as I can tell, it is:

>>> os.supports_fd
{<built-in function stat>}

----------

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

From report at bugs.python.org  Fri Jul  6 17:43:50 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Jul 2012 15:43:50 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WTKwj1lb5zNGs@mail.python.org>


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

New changeset 30e8f2242190 by Nick Coghlan in branch 'default':
Issue 14814: Eliminate bytes warnings from ipaddress by correctly throwing an exception early when given bytes data of the wrong length. Also removes 2.x backwards compatibility code from associated tests.
http://hg.python.org/cpython/rev/30e8f2242190

----------

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

From report at bugs.python.org  Fri Jul  6 17:54:49 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 06 Jul 2012 15:54:49 +0000
Subject: [issue15263] Guard against invalid file handles in os functions
In-Reply-To: <1341584196.67.0.703107638593.issue15263@psf.upfronthosting.co.za>
Message-ID: <1341590089.28.0.405569829292.issue15263@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Every use of _get_osfhandle() should be guarded by _Py_VerifyFd().  

Grepping through the source it seems that that is now true, but we could instead use

  #define _PY_GET_OSFHANDLE(fd) _Py_VerifyFd(fd) ? _get_osfhandle(fd) : INVALID_HANDLE_VALUE

----------

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

From report at bugs.python.org  Fri Jul  6 17:55:39 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 06 Jul 2012 15:55:39 +0000
Subject: [issue15261] os.stat(fd) crashes on Windows if fd does not exist
In-Reply-To: <1341533006.37.0.469874920155.issue15261@psf.upfronthosting.co.za>
Message-ID: <1341590139.38.0.399839993203.issue15261@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Sorry about that...

----------

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

From report at bugs.python.org  Fri Jul  6 18:18:04 2012
From: report at bugs.python.org (Dave King)
Date: Fri, 06 Jul 2012 16:18:04 +0000
Subject: [issue15247] io.open() is inconsistent re os.open()
In-Reply-To: <1341370509.01.0.335541688705.issue15247@psf.upfronthosting.co.za>
Message-ID: <1341591484.5.0.628692792688.issue15247@psf.upfronthosting.co.za>


Changes by Dave King <dave at davbo.org>:


----------
nosy: +davbo

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

From report at bugs.python.org  Fri Jul  6 18:25:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Jul 2012 16:25:12 +0000
Subject: [issue15230] runpy.run_path broken: Breaks scoping;
	pollutes sys.modules; doesn't set __package__
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <1341591912.43.0.349273343278.issue15230@psf.upfronthosting.co.za>


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

?python3 -m /tmp/b? is invalid IIUC.  -m takes a module name, not a path.

----------
nosy: +eric.araujo, ncoghlan

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

From report at bugs.python.org  Fri Jul  6 18:27:03 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Jul 2012 16:27:03 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341592023.02.0.905104525167.issue15231@psf.upfronthosting.co.za>


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

In 2.7 and newer ?setup.py check? is a better interface than rst2html.  +1 to list all checks performed by PyPI on some wiki or PyPI doc page (and +1 to add the same checks in distutils2?s check command).

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Jul  6 18:27:10 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Jul 2012 16:27:10 +0000
Subject: [issue15235] allow newer berkeley db versions
In-Reply-To: <1341131768.44.0.275273067892.issue15235@psf.upfronthosting.co.za>
Message-ID: <1341592030.08.0.731845460135.issue15235@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: allow newer berkley db versions -> allow newer berkeley db versions

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

From report at bugs.python.org  Fri Jul  6 18:30:08 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Jul 2012 16:30:08 +0000
Subject: [issue15260] Mention how to order Misc/NEWS entries
In-Reply-To: <1341529945.6.0.935201074505.issue15260@psf.upfronthosting.co.za>
Message-ID: <1341592208.98.0.818155389204.issue15260@psf.upfronthosting.co.za>


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

The whole file is ordered with newest on top (newest Python version), so I guess it?s implicit for all committers that sections are also ordered with newest on top.  It does not actually matter; the contents of one ?what?s new in Python W.XyZ? are not ordered.

A nice trick to make Mercurial?s automatic file merge work is to put your entry after the first or the first two entries, so that if you commit, then pull new changesets and merge, the merge will success automatically.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Jul  6 18:40:40 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jul 2012 16:40:40 +0000
Subject: [issue15264] PyErr_SetFromErrnoWithFilenameObject() undocumented
Message-ID: <1341592840.74.0.991788798601.issue15264@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Title says it all.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 164736
nosy: docs at python, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PyErr_SetFromErrnoWithFilenameObject() undocumented
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul  6 19:02:32 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Jul 2012 17:02:32 +0000
Subject: [issue15247] io.open() is inconsistent re os.open()
In-Reply-To: <1341370509.01.0.335541688705.issue15247@psf.upfronthosting.co.za>
Message-ID: <3WTMgW1hzpzLtR@mail.python.org>


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

New changeset 9cf9527358a5 by Antoine Pitrou in branch '3.2':
Issue #15247: FileIO now raises an error when given a file descriptor pointing to a directory.
http://hg.python.org/cpython/rev/9cf9527358a5

New changeset 19bd61ed3b3b by Antoine Pitrou in branch 'default':
Issue #15247: FileIO now raises an error when given a file descriptor pointing to a directory.
http://hg.python.org/cpython/rev/19bd61ed3b3b

New changeset d7040647d590 by Antoine Pitrou in branch '2.7':
Issue #15247: FileIO now raises an error when given a file descriptor pointing to a directory.
http://hg.python.org/cpython/rev/d7040647d590

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

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

From report at bugs.python.org  Fri Jul  6 19:03:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jul 2012 17:03:36 +0000
Subject: [issue15247] io.open() is inconsistent re os.open()
In-Reply-To: <1341370509.01.0.335541688705.issue15247@psf.upfronthosting.co.za>
Message-ID: <1341594216.17.0.459703772739.issue15247@psf.upfronthosting.co.za>


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

Thanks, the issue should be fixed now.

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

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

From report at bugs.python.org  Fri Jul  6 19:11:25 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 06 Jul 2012 17:11:25 +0000
Subject: [issue15256] Typo in error message
In-Reply-To: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>
Message-ID: <1341594685.36.0.203264746887.issue15256@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/issue15256>
_______________________________________

From report at bugs.python.org  Fri Jul  6 19:28:16 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 06 Jul 2012 17:28:16 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341595696.36.0.530590872412.issue15231@psf.upfronthosting.co.za>


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

?ric: your request is in passive voice. I'm not aware that anybody volunteered document the tests, but I doubt that this wiki page can reasonably be kept up-to-date. So the wiki page will outdate just as the current documentation got outdated.

Incorporating the check into distutils 2 is more feasible, but would still require someone to incorporate updates when we make them. The code is (currently) at

https://bitbucket.org/loewis/pypi/raw/default/description_utils.py

----------

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

From report at bugs.python.org  Fri Jul  6 19:29:31 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Jul 2012 17:29:31 +0000
Subject: [issue15245] ast.literal_eval fails on some literals
In-Reply-To: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>
Message-ID: <1341595771.34.0.697518435421.issue15245@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/issue15245>
_______________________________________

From report at bugs.python.org  Fri Jul  6 19:33:05 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Fri, 06 Jul 2012 17:33:05 +0000
Subject: [issue15256] Typo in error message
In-Reply-To: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>
Message-ID: <1341595985.08.0.156802322082.issue15256@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

I think this is just a simple typo and a consistency issue; not a grammatical issue.

The misspelled version was added in a recent commit:

[last: 0] marca at SCML-MarcA:~/dev/hg-repos/cpython$ hg log -r 76455
changeset:   76455:085cf1480cfe
user:        Brett Cannon <brett at python.org>
date:        Sat Apr 21 21:09:46 2012 -0400
summary:     Issue #13959: Re-implement imp.find_module() in Lib/imp.py.

Link to issue: http://bugs.python.org/issue13959

----------

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

From report at bugs.python.org  Fri Jul  6 19:36:40 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Jul 2012 17:36:40 +0000
Subject: [issue15248] In "TypeError: 'tuple' object is not callable",
	explain that a comma may be missing
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1341596200.44.0.249775043609.issue15248@psf.upfronthosting.co.za>


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

A FAQ entry could be added to explain this error, like we already do for the UnboundLocalError: http://docs.python.org/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Fri Jul  6 19:37:53 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Jul 2012 17:37:53 +0000
Subject: [issue15255] spam / garbage report
In-Reply-To: <1341510905.93.0.746184432871.issue15255@psf.upfronthosting.co.za>
Message-ID: <1341596273.01.0.303968152662.issue15255@psf.upfronthosting.co.za>


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


----------
assignee: collinwinter -> 
components:  -Benchmarks
nosy:  -andisthermal555, collinwinter
resolution: fixed -> invalid
status: open -> closed
type: security -> 
versions:  -3rd party

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

From report at bugs.python.org  Fri Jul  6 19:38:05 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Jul 2012 17:38:05 +0000
Subject: [issue15255] spam / garbage report
In-Reply-To: <1341510905.93.0.746184432871.issue15255@psf.upfronthosting.co.za>
Message-ID: <1341596285.6.0.0326517448401.issue15255@psf.upfronthosting.co.za>


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


----------
hgrepos:  -139

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

From report at bugs.python.org  Fri Jul  6 19:38:09 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Jul 2012 17:38:09 +0000
Subject: [issue15255] spam / garbage report
In-Reply-To: <1341510905.93.0.746184432871.issue15255@psf.upfronthosting.co.za>
Message-ID: <1341596289.11.0.0532581009996.issue15255@psf.upfronthosting.co.za>


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


----------
hgrepos:  -138

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

From report at bugs.python.org  Fri Jul  6 19:38:14 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Jul 2012 17:38:14 +0000
Subject: [issue15255] spam / garbage report
In-Reply-To: <1341510905.93.0.746184432871.issue15255@psf.upfronthosting.co.za>
Message-ID: <1341596294.85.0.480577609298.issue15255@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file26270/query.csv

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

From report at bugs.python.org  Fri Jul  6 19:38:55 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Jul 2012 17:38:55 +0000
Subject: [issue15255] spam / garbage report
In-Reply-To: <1341510905.93.0.746184432871.issue15255@psf.upfronthosting.co.za>
Message-ID: <1341596335.02.0.329336081683.issue15255@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/issue15255>
_______________________________________

From report at bugs.python.org  Fri Jul  6 19:40:35 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Jul 2012 17:40:35 +0000
Subject: [issue15256] Typo in error message
In-Reply-To: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>
Message-ID: <1341596435.18.0.57617965938.issue15256@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch

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

From report at bugs.python.org  Fri Jul  6 19:41:22 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Jul 2012 17:41:22 +0000
Subject: [issue15259] "Helping with Documentation" references missing
	dailybuild.py
In-Reply-To: <1341529306.29.0.594209420115.issue15259@psf.upfronthosting.co.za>
Message-ID: <1341596482.67.0.120616306407.issue15259@psf.upfronthosting.co.za>


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


----------
nosy: +georg.brandl
stage:  -> needs patch

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

From report at bugs.python.org  Fri Jul  6 19:50:45 2012
From: report at bugs.python.org (Roy Smith)
Date: Fri, 06 Jul 2012 17:50:45 +0000
Subject: [issue15265] random.sample() docs unclear on k < len(population)
Message-ID: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

The docs don't say what happens if you call random.sample() with a population smaller than k.  Experimentally, it raises ValueError, but this should be documented.

I would have guessed it would return IndexError, by analogy to random.choice().

----------
assignee: docs at python
components: Documentation
messages: 164742
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: random.sample() docs unclear on k < len(population)
type: enhancement

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

From report at bugs.python.org  Fri Jul  6 19:52:36 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 17:52:36 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341597156.77.0.836767131563.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Another way to make it easier for users to run the same command as PyPI locally -- also phrased in the passive voice :) -- would be if PyPI packaged its conversion code as a separate module that could also be run as a stand-alone script, and then relied on that.  That would eliminate the need to keep different code bases in synch.

----------

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

From report at bugs.python.org  Fri Jul  6 20:30:10 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Fri, 06 Jul 2012 18:30:10 +0000
Subject: [issue15256] Typo in error message
In-Reply-To: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>
Message-ID: <1341599410.48.0.185988626627.issue15256@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

Attaching patch

----------
keywords: +patch
Added file: http://bugs.python.org/file26271/python_issue_15256.patch

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

From report at bugs.python.org  Fri Jul  6 21:31:27 2012
From: report at bugs.python.org (Dave Abrahams)
Date: Fri, 06 Jul 2012 19:31:27 +0000
Subject: [issue9458] xml.etree.ElementTree.ElementTree.write(): encoding
	handling problems
In-Reply-To: <1280782925.67.0.136452249646.issue9458@psf.upfronthosting.co.za>
Message-ID: <1341603087.34.0.541142211953.issue9458@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

I won't get to this, FYI.

----------

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

From report at bugs.python.org  Fri Jul  6 21:34:16 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 19:34:16 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341603256.45.0.908636328629.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Does the proposed patch to the documentation look okay given the way things are today?

I can open an issue on the PyPI tracker to discuss the broader issue or, if you prefer, on the main Python tracker.

----------

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

From report at bugs.python.org  Fri Jul  6 21:45:28 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 06 Jul 2012 19:45:28 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341603928.11.0.76305141344.issue15231@psf.upfronthosting.co.za>


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

Chris, can you please submit a contrib form? Thanks.

----------

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

From report at bugs.python.org  Fri Jul  6 21:46:53 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Jul 2012 19:46:53 +0000
Subject: [issue15227] Fatal Python error: PyEval_RestoreThread: NULL tstate on
	example script..
In-Reply-To: <1341030356.65.0.710942348238.issue15227@psf.upfronthosting.co.za>
Message-ID: <1341604013.82.0.0318620655732.issue15227@psf.upfronthosting.co.za>


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

On 3.3b0, Win7, 64-64 bit, run from IDLE, script brings up empty tk window. Closing it gives prompt back in Shell window.

Maslach, can you retry with 2.7.3 (bug fix is generally a good idea anyway) and maybe 64 bit version (you can install both 32 bit and 64 bit if you specify different directory -- I have done it.)

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

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

From report at bugs.python.org  Fri Jul  6 21:51:48 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 06 Jul 2012 19:51:48 +0000
Subject: [issue15259] "Helping with Documentation" references missing
	dailybuild.py
In-Reply-To: <1341529306.29.0.594209420115.issue15259@psf.upfronthosting.co.za>
Message-ID: <1341604308.57.0.152872737587.issue15259@psf.upfronthosting.co.za>


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

It does, in the 2.7 branch.  You're welcome to port it to Python 3 and put it into 3.x.  I don't see the point though, and rather would have the mention removed from the devguide.

----------

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

From report at bugs.python.org  Fri Jul  6 21:52:08 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 06 Jul 2012 19:52:08 +0000
Subject: [issue15259] "Helping with Documentation" references missing
	dailybuild.py
In-Reply-To: <1341529306.29.0.594209420115.issue15259@psf.upfronthosting.co.za>
Message-ID: <1341604328.14.0.0664612808281.issue15259@psf.upfronthosting.co.za>


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

... because the script is absolutely irrelevant to building or helping with the docs.

----------

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

From report at bugs.python.org  Fri Jul  6 21:56:14 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 19:56:14 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341604574.89.0.237183722194.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I did yesterday.  I will post here when I receive a response.

----------

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

From report at bugs.python.org  Fri Jul  6 22:02:31 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 06 Jul 2012 20:02:31 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341604951.96.0.24922994622.issue15231@psf.upfronthosting.co.za>


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

Ah, ok. Processing may take some time.

----------

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

From report at bugs.python.org  Fri Jul  6 22:12:00 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Jul 2012 20:12:00 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341605520.11.0.647343578426.issue15233@psf.upfronthosting.co.za>


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

I agree with Raymond. You might, however, emphasize 'normal' in 'normal
interpreter termination'. That is the key point. The 'note' merely explains 'abnormal'.

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

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

From report at bugs.python.org  Fri Jul  6 22:14:23 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jul 2012 20:14:23 +0000
Subject: [issue15265] random.sample() docs unclear on k < len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341605663.68.0.406578749594.issue15265@psf.upfronthosting.co.za>


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


----------
nosy: +rhettinger

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

From report at bugs.python.org  Fri Jul  6 22:33:53 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Fri, 06 Jul 2012 20:33:53 +0000
Subject: [issue15256] Typo in error message
In-Reply-To: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>
Message-ID: <1341606833.6.0.442969121342.issue15256@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

Patch with Brett's comments

----------
Added file: http://bugs.python.org/file26272/python_issue_15256.patch

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

From report at bugs.python.org  Fri Jul  6 22:43:02 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 06 Jul 2012 20:43:02 +0000
Subject: [issue15258] argparse documentation: Improve optparse section
	regarding allow_interspersed_args
In-Reply-To: <1341528073.03.0.435446433545.issue15258@psf.upfronthosting.co.za>
Message-ID: <1341607382.66.0.745258358291.issue15258@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

See also issue 14191, which describes the problems of trying to make argparse achieve the goal of the default optparse handling of allow_interspersed_args !

The documentation for that branch of the feature is also seriously incomplete, and the workaround is more than a single line.

----------
nosy: +v+python

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

From report at bugs.python.org  Fri Jul  6 23:00:48 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 06 Jul 2012 21:00:48 +0000
Subject: [issue14191] argparse: nargs='*' doesn't get out-of-order positional
	parameters
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1341608448.8.0.222113785274.issue14191@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

See also issue 15258 which points out issues with the converse case.

Further testing and development also discovered that in certain error cases, the help message produced by t18-equivalent code was incorrect.

t18a.py is an update/rewrite (same concepts, though) that produces a correct help message when errors occur.

----------
Added file: http://bugs.python.org/file26273/t18a.py

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

From report at bugs.python.org  Fri Jul  6 23:39:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jul 2012 21:39:30 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1341610770.94.0.763020235863.issue10142@psf.upfronthosting.co.za>


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

Ping. The ARM buildbot still fails on test_fs_holes:
http://buildbot.python.org/all/builders/ARM%20Ubuntu%203.x/builds/775/steps/test/logs/stdio

----------

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

From report at bugs.python.org  Sat Jul  7 00:27:53 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 06 Jul 2012 22:27:53 +0000
Subject: [issue4011] Create DAG for PEP 101
In-Reply-To: <1222896665.95.0.381960877122.issue4011@psf.upfronthosting.co.za>
Message-ID: <1341613673.04.0.797179019318.issue4011@psf.upfronthosting.co.za>


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

I think you can make nice graphs with graphviz if you put effort into it :)

----------
assignee: georg.brandl -> larry

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

From report at bugs.python.org  Sat Jul  7 00:41:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 22:41:29 +0000
Subject: [issue15266] Provide an easy way to check a reST long_description for
	PyPI
Message-ID: <1341614489.26.0.385769914645.issue15266@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

There should be an easy way to check a reST long_description on one's local machine before uploading to PyPI.  The check should use the same rules that PyPI uses, so that passing the check locally ensures that PyPI will convert the description to HTML successfully.

Issue 15231 is related and focuses on the current documentation.  See that issue for some background and ideas.

Also see the corresponding issue filed on the PyPI tracker:

http://sourceforge.net/tracker/?func=detail&aid=3539253&group_id=66150&atid=513503

----------
assignee: eric.araujo
components: Distutils2
messages: 164759
nosy: alexis, cjerdonek, eric.araujo, loewis, tarek
priority: normal
severity: normal
status: open
title: Provide an easy way to check a reST long_description for PyPI

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

From report at bugs.python.org  Sat Jul  7 00:46:04 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 22:46:04 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341614764.85.0.67774431578.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I created issue 15266 for the broader issue.  The corresponding issue I made earlier on the PyPI tracker is also referenced there.

----------

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

From report at bugs.python.org  Sat Jul  7 01:02:27 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Jul 2012 23:02:27 +0000
Subject: [issue15266] Perform the same checks as PyPI for Description field
In-Reply-To: <1341614489.26.0.385769914645.issue15266@psf.upfronthosting.co.za>
Message-ID: <1341615747.31.0.901910888303.issue15266@psf.upfronthosting.co.za>


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

This easy way exists: ?pysetup run check? checks the rst syntax; retitling.

Basically it?s a matter of using the same settings (no file inclusion, etc.) as PyPI and checking the URI schemes.

One maintenance issue is the possible discrepancy between PyPI?s checks and distutils2?s; if the PyPI maintainers agree to announce all changes to catalog-sig it could work (just like for classifiers).

----------
keywords: +easy
stage:  -> needs patch
title: Provide an easy way to check a reST long_description for PyPI -> Perform the same checks as PyPI for Description field
type:  -> behavior
versions: +3rd party

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

From report at bugs.python.org  Sat Jul  7 01:59:54 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 23:59:54 +0000
Subject: [issue15260] Mention how to order Misc/NEWS entries
In-Reply-To: <1341529945.6.0.935201074505.issue15260@psf.upfronthosting.co.za>
Message-ID: <1341619194.52.0.836720840785.issue15260@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Patch attached.  I moved the discussion of NEWS entries to a section before the discussion on commit messages because previously, the commit message discussion referenced NEWS entries before they had been discussed (and not vice versa).  This seems clearer to me.

Let me know if I have mischaracterized what is customary, and I can change the wording.

----------
keywords: +patch
Added file: http://bugs.python.org/file26274/issue-15260-1.patch

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

From report at bugs.python.org  Sat Jul  7 02:21:05 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 00:21:05 +0000
Subject: [issue15259] "Helping with Documentation" references missing
	dailybuild.py
In-Reply-To: <1341529306.29.0.594209420115.issue15259@psf.upfronthosting.co.za>
Message-ID: <1341620465.74.0.228121842923.issue15259@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Patch attached; reference to the script removed.

----------
keywords: +patch
Added file: http://bugs.python.org/file26275/issue-15259-1.patch

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

From report at bugs.python.org  Sat Jul  7 02:24:35 2012
From: report at bugs.python.org (Tim Smith)
Date: Sat, 07 Jul 2012 00:24:35 +0000
Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility
Message-ID: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za>


New submission from Tim Smith <tzs at tzs.net>:

In httplib.py, there is this code to try to get the body length:

    def _set_content_length(self, body):
        # Set the content-length based on the body.
        thelen = None
        try:
            thelen = str(len(body))
        except TypeError, te:
            # If this is a file-like object, try to
            # fstat its file descriptor
            try:
                thelen = str(os.fstat(body.fileno()).st_size)
            except (AttributeError, OSError):
                # Don't send a length if this failed
                if self.debuglevel > 0: print "Cannot stat!!"

However, if the body is a temporary file created by tempfile.TemporaryFile(), the len(body) in the first try throws an AttributeError, not a TypeError, on Windows and so it is not caught and unhappiness ensues. It is fine on Macintosh, and I would presume also on Linux.

Windows behaves different because on the other systems, TemporaryFile() returns an actual file object, and len() on a file throws TypeError. On Windows, TemporaryFile() returns an object that wraps the underlying file, and calling len() on that objects invokes this from tempfile.py (around line 371):

    def __getattr__(self, name):
        # Attribute lookups are delegated to the underlying file
        # and cached for non-numeric results
        # (i.e. methods are cached, closed and friends are not)
        file = self.__dict__['file']
        a = getattr(file, name)
        if not issubclass(type(a), type(0)):
            setattr(self, name, a)
        return a

Since the underlying file does not have a __len__ method, the getattr fails and throws AttributeError.

I'm sorry I'm not submitting a patch, but I do not know enough about the design of these two libraries to know whether the correct fix is for httplib to be more broad in the exceptions that cause it to check for a file when len() fails, or if the object returned by TemporaryFile() should be more closely mimicking a true file object and so should be made to throw TypeError when someone tries to use len() on it.

----------
components: Windows
messages: 164764
nosy: tzs
priority: normal
severity: normal
status: open
title: tempfile.TemporaryFile and httplib incompatibility
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul  7 03:04:34 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 07 Jul 2012 01:04:34 +0000
Subject: [issue15268] curses configure checks fail if only
	/usr/include/ncursesw/curses.h is installed
Message-ID: <1341623074.57.0.341676091224.issue15268@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

the curses configure checks fail if only /usr/include/ncursesw/curses.h is installed (on a Debian/Ubuntu system, uninstall the libncurses5-dev package, and install the libncursesw5-dev package).

The attached patch adds -I/usr/include/ncursesw to CPPFLAGS for the tests.

I assume that most buildbot systems still have an /usr/include/curses.h installed, so the tests do the intended thing, because the features tested are the same in ncurses and ncursesw, but basically the wrong headers are used for these tests if both /usr/include/curses.h and /usr/include/ncursesw/curses.h are installed.

----------
components: Build
files: curses.diff
keywords: patch
messages: 164765
nosy: doko
priority: normal
severity: normal
status: open
title: curses configure checks fail if only /usr/include/ncursesw/curses.h is installed
versions: Python 3.3
Added file: http://bugs.python.org/file26276/curses.diff

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

From report at bugs.python.org  Sat Jul  7 03:08:33 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 01:08:33 +0000
Subject: [issue15268] curses configure checks fail if only
	/usr/include/ncursesw/curses.h is installed
In-Reply-To: <1341623074.57.0.341676091224.issue15268@psf.upfronthosting.co.za>
Message-ID: <3WTZSJ64stzNSS@mail.python.org>


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

New changeset 707761d59a4a by doko in branch 'default':
- Issue #15268: Search curses.h in /usr/include/ncursesw.
http://hg.python.org/cpython/rev/707761d59a4a

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

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

From report at bugs.python.org  Sat Jul  7 03:10:24 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 07 Jul 2012 01:10:24 +0000
Subject: [issue15268] curses configure checks fail if only
	/usr/include/ncursesw/curses.h is installed
In-Reply-To: <1341623074.57.0.341676091224.issue15268@psf.upfronthosting.co.za>
Message-ID: <1341623424.16.0.480366981142.issue15268@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

can be closed if we don't bother to use the "wrong" header for the checks

----------

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

From report at bugs.python.org  Sat Jul  7 03:16:33 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 01:16:33 +0000
Subject: [issue15259] "Helping with Documentation" references missing
	dailybuild.py
In-Reply-To: <1341529306.29.0.594209420115.issue15259@psf.upfronthosting.co.za>
Message-ID: <3WTZdX2zt1zNPs@mail.python.org>


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

New changeset d1958a94d0ff by Ned Deily in branch 'default':
Issue #15259: Remove reference to dailybuild.py.
http://hg.python.org/devguide/rev/d1958a94d0ff

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

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

From report at bugs.python.org  Sat Jul  7 03:17:54 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 07 Jul 2012 01:17:54 +0000
Subject: [issue15268] curses configure checks fail if only
	/usr/include/ncursesw/curses.h is installed
In-Reply-To: <1341623074.57.0.341676091224.issue15268@psf.upfronthosting.co.za>
Message-ID: <1341623874.22.0.464196425286.issue15268@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

and only add the dir for the curses.h and nurses.h header checks

----------
Added file: http://bugs.python.org/file26277/curses2.diff

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

From report at bugs.python.org  Sat Jul  7 03:18:07 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 07 Jul 2012 01:18:07 +0000
Subject: [issue15268] curses configure checks fail if only
	/usr/include/ncursesw/curses.h is installed
In-Reply-To: <1341623074.57.0.341676091224.issue15268@psf.upfronthosting.co.za>
Message-ID: <1341623887.93.0.631810041089.issue15268@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
keywords: +needs review -patch

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

From report at bugs.python.org  Sat Jul  7 03:18:54 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Jul 2012 01:18:54 +0000
Subject: [issue15259] "Helping with Documentation" references missing
	dailybuild.py
In-Reply-To: <1341529306.29.0.594209420115.issue15259@psf.upfronthosting.co.za>
Message-ID: <1341623934.43.0.552269700536.issue15259@psf.upfronthosting.co.za>


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

Thanks of the patch!  I reworded it slightly to completely remove the reference to the script.

----------
nosy: +ned.deily
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jul  7 03:29:58 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 07 Jul 2012 01:29:58 +0000
Subject: [issue15268] curses configure checks fail if only
	/usr/include/ncursesw/curses.h is installed
In-Reply-To: <1341623074.57.0.341676091224.issue15268@psf.upfronthosting.co.za>
Message-ID: <1341624598.13.0.162591543983.issue15268@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

and a variant, which moves all curses header related check together (curses3.diff)

----------
keywords: +patch
Added file: http://bugs.python.org/file26278/curses3.diff

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

From report at bugs.python.org  Sat Jul  7 03:33:11 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 Jul 2012 01:33:11 +0000
Subject: [issue15268] curses configure checks fail if only
	/usr/include/ncursesw/curses.h is installed
In-Reply-To: <1341623074.57.0.341676091224.issue15268@psf.upfronthosting.co.za>
Message-ID: <1341624791.19.0.966812450316.issue15268@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


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

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

From report at bugs.python.org  Sat Jul  7 03:39:53 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 01:39:53 +0000
Subject: [issue15260] Mention how to order Misc/NEWS entries
In-Reply-To: <1341529945.6.0.935201074505.issue15260@psf.upfronthosting.co.za>
Message-ID: <3WTb8S0wZ3zNPx@mail.python.org>


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

New changeset bbe197bf57a1 by Ned Deily in branch 'default':
Issue #15260: Expand information on Misc/NEWS entries.
http://hg.python.org/devguide/rev/bbe197bf57a1

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

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

From report at bugs.python.org  Sat Jul  7 03:41:26 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Jul 2012 01:41:26 +0000
Subject: [issue15260] Mention how to order Misc/NEWS entries
In-Reply-To: <1341529945.6.0.935201074505.issue15260@psf.upfronthosting.co.za>
Message-ID: <1341625286.41.0.112182262012.issue15260@psf.upfronthosting.co.za>


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

Thanks for the patch!

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jul  7 03:44:59 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Jul 2012 01:44:59 +0000
Subject: [issue15248] In "TypeError: 'tuple' object is not callable",
	explain that a comma may be missing
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1341625499.81.0.770893413103.issue15248@psf.upfronthosting.co.za>


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

Stephen is right; this sort of guess-the-bug heuristic is out of scope for the CPython interpreter. I believe you grossly under estimate the difficulty of such a this. Consider that idea rejected.

What *is* disconcerting is the exact form of the error message for this particular code pattern:

Traceback (most recent call last):
  File "<pyshell#0>", line 3, in <module>
    (4, 5, 6)
TypeError: 'tuple' object is not callable

Uh... There was no attempt to call the tuple (4,5,6), which was misinterpreted as a () call operator with 3 args. What might be a reasonable request is to print a size-limited representation of the object that is not callable but was attempted to be called. Truncated representations would be generally useful for traceback messages. I believe we already have them for unittest error messages.

A useful document for someone (or some people) to write would be 'How to interpret exception messages'. That could start with a catalog of messages and possible causes. 'type' would be used to stand for any specific type.

The section on TypeErrors would have an heading
  'type' object is not callable
followed by an explanation
  There are two general reasons for this message. The first is that you intentionally write "expression(args)" with the intent that expression evaluate to a callable, but it does not. The second is that you accidentally omit a comma in a sequence and write "expression (tuple_members)". Note that the error is triggered by the "(args)" call operator and its line is the one printed. So if "expression" is on the preceeding line, it will not appear in the traceback. This can happen with either type of error.

In the meanwhile, the above is a start for a faq entry.

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

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

From report at bugs.python.org  Sat Jul  7 03:45:58 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Jul 2012 01:45:58 +0000
Subject: [issue15248] Better explain "TypeError: 'tuple' object is not
	callable"
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1341625558.33.0.762888150323.issue15248@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> needs patch
title: In "TypeError: 'tuple' object is not callable", explain that a comma may be missing -> Better explain "TypeError: 'tuple' object is not callable"
versions: +Python 3.4

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

From report at bugs.python.org  Sat Jul  7 04:29:13 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Jul 2012 02:29:13 +0000
Subject: [issue15251] new.code and new.function crashes Python iterpretter
In-Reply-To: <1341422953.77.0.576650378209.issue15251@psf.upfronthosting.co.za>
Message-ID: <1341628153.25.0.56751553888.issue15251@psf.upfronthosting.co.za>


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

In Py3, new.code and new.function become types.CodeType and types.FunctionType. The 'documentation' of their signatures is only available with help(types.xxx). So the library doc issue is 2.7 only.

Running with IDLE, 3.3b0, Win7, the converted example does crash after 5 seconds or so even with the missing arg and the pprint gone. The crash is in the new_fun(5) call. I might have gotten something wrong. Or maybe the the help is wrong.

----------
nosy: +terry.reedy
Added file: http://bugs.python.org/file26279/tem.py

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

From report at bugs.python.org  Sat Jul  7 04:32:03 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Jul 2012 02:32:03 +0000
Subject: [issue15256] Typo in error message
In-Reply-To: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>
Message-ID: <1341628323.87.0.0694470003233.issue15256@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Jul  7 04:32:51 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Jul 2012 02:32:51 +0000
Subject: [issue15258] argparse documentation: Improve optparse section
	regarding allow_interspersed_args
In-Reply-To: <1341528073.03.0.435446433545.issue15258@psf.upfronthosting.co.za>
Message-ID: <1341628371.26.0.574034523077.issue15258@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Jul  7 04:54:23 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 02:54:23 +0000
Subject: [issue15266] Perform the same checks as PyPI for Description field
In-Reply-To: <1341614489.26.0.385769914645.issue15266@psf.upfronthosting.co.za>
Message-ID: <1341629663.84.0.45410534752.issue15266@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

With regard to the maintenance issue, what about the idea of aiming for PyPI to include that logic in a separately packaged module?  Then there would be no need to cut and paste -- just include the right version.

If that were done, depending on how the pysetup change is done, users might be able to use PyPI's latest version even if pysetup was out of synch and hadn't been updated yet.

----------

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

From report at bugs.python.org  Sat Jul  7 05:01:16 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Jul 2012 03:01:16 +0000
Subject: [issue15262] Idle does not show traceback in other threads
In-Reply-To: <1341563293.08.0.285980110052.issue15262@psf.upfronthosting.co.za>
Message-ID: <1341630076.83.0.0689970064879.issue15262@psf.upfronthosting.co.za>


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

In 3.3, you do not need it
>>> Unhandled exception in thread started by <function f at 0x00000000031D0158>
Traceback (most recent call last):
  File "F:\Python\mypy\tem.py", line 2, in f
    def f(): typo #there is no variable called typo
NameError: global name 'typo' is not defined

In 3.2 only the first line is printed; the traceback is not.

The change is due to recent internal improvements in core Python 3 exception handling.

(In 3.x, thread was renamed _thread to discourage its direct use and to encourage use of threading instead. I tested with _thread.)

----------
nosy: +terry.reedy
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jul  7 05:35:26 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 03:35:26 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WTdjm4nTkzNPV@mail.python.org>


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

New changeset d9c98730e2e8 by Nick Coghlan in branch 'default':
Issue 14814: %s implies coercion with str() - remove a lot of redundant str() calls from the ipaddress implementation
http://hg.python.org/cpython/rev/d9c98730e2e8

----------

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

From report at bugs.python.org  Sat Jul  7 05:46:35 2012
From: report at bugs.python.org (Justin Venus)
Date: Sat, 07 Jul 2012 03:46:35 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341632795.51.0.00614406294765.issue13405@psf.upfronthosting.co.za>


Justin Venus <justin.venus at gmail.com> added the comment:

@jcea I am the owner of the Solaris 11 buildslave[1]. I have configured the build user to have dtrace privileges if you need to run additional tests against it. Let me know if you encounter any additional issues with this system.


1)http://buildbot.python.org/all/builders/x86%20Solaris%2011%20custom/builds/3

----------
nosy: +Justin.Venus

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

From report at bugs.python.org  Sat Jul  7 06:22:52 2012
From: report at bugs.python.org (Justin Venus)
Date: Sat, 07 Jul 2012 04:22:52 +0000
Subject: [issue15268] curses configure checks fail if only
	/usr/include/ncursesw/curses.h is installed
In-Reply-To: <1341623074.57.0.341676091224.issue15268@psf.upfronthosting.co.za>
Message-ID: <1341634972.17.0.572882436267.issue15268@psf.upfronthosting.co.za>


Justin Venus <justin.venus at gmail.com> added the comment:

I have a similar issue on Solaris and a patch[1] to fix it attached to issue 3786.

1) http://bugs.python.org/file26171/bug3786.patch

----------
nosy: +Justin.Venus

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

From report at bugs.python.org  Sat Jul  7 06:28:00 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 04:28:00 +0000
Subject: [issue15269] Document dircmp.left and dircmp.right
Message-ID: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The documentation for the filecmp.dircmp class doesn't mention dircmp.left and dircmp.right.

Being aware of this up front would make certain simplifications easier to think of.  For example, knowing about these attributes opens up the possibility of passing dircmp instances around without having to pass the two paths separately (e.g. in certain recursive algorithms involving dircmp).  Knowing this also means you can recover the two paths if using the subdirs attribute (whose values are dircmp instances).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164781
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: Document dircmp.left and dircmp.right
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 06:28:43 2012
From: report at bugs.python.org (Justin Venus)
Date: Sat, 07 Jul 2012 04:28:43 +0000
Subject: [issue12927] test_ctypes: segfault with suncc
In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za>
Message-ID: <1341635323.23.0.142915392091.issue12927@psf.upfronthosting.co.za>


Justin Venus <justin.venus at gmail.com> added the comment:

I can confirm this issue is resolved on Solaris 11 x86 and has been since '--with-system-ffi' was added to the build rules.

----------

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

From report at bugs.python.org  Sat Jul  7 06:30:46 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 07 Jul 2012 04:30:46 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <1341635446.29.0.608834429621.issue15242@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Here's a new patch that keeps things simpler, but still cleans up the concerns about using sys.implementation.cache_tag in PyImport_GetMagicTag().

----------
Added file: http://bugs.python.org/file26280/cache_tag_via_sys_var.diff

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

From report at bugs.python.org  Sat Jul  7 06:37:58 2012
From: report at bugs.python.org (Justin Venus)
Date: Sat, 07 Jul 2012 04:37:58 +0000
Subject: [issue13552] Compilation issues of the curses module on OpenIndiana
In-Reply-To: <1323305598.14.0.0193622635558.issue13552@psf.upfronthosting.co.za>
Message-ID: <1341635878.63.0.181821943285.issue13552@psf.upfronthosting.co.za>


Justin Venus <justin.venus at gmail.com> added the comment:

Does OpenIndiana ship with the gnu version of ncurses like Solaris 11?

Headers:
/usr/include/ncurses

Libraries:
/usr/gnu/lib

If it matches Solaris, then you can use my patch[1] in issue 3786 to see if that works around the issue, like it does for Solaris.

1) http://bugs.python.org/file26171/bug3786.patch

----------
nosy: +Justin.Venus

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

From report at bugs.python.org  Sat Jul  7 06:44:01 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 07 Jul 2012 04:44:01 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <1341636241.91.0.434549441187.issue15242@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file26280/cache_tag_via_sys_var.diff

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

From report at bugs.python.org  Sat Jul  7 06:44:38 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 07 Jul 2012 04:44:38 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <1341636278.41.0.969597087529.issue15242@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Patch updated to include a doc addition.

----------
Added file: http://bugs.python.org/file26281/cache_tag_via_sys_var.diff

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

From report at bugs.python.org  Sat Jul  7 07:44:50 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 05:44:50 +0000
Subject: [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1341639890.59.0.286617617265.issue15269@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file26282/issue-15269-1.patch

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

From report at bugs.python.org  Sat Jul  7 07:45:31 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 05:45:31 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1341639931.82.0.0593150195888.issue14814@psf.upfronthosting.co.za>


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

Just letting people know I'm working on a patch that updates the class constructors to give meaningful error messages for malformed addresses, instead of assuming that users can figure it out just by looking at the address. I'm also updating the test suite to check that these more detailed errors are being reported as expected.

----------

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

From report at bugs.python.org  Sat Jul  7 07:59:46 2012
From: report at bugs.python.org (Mark)
Date: Sat, 07 Jul 2012 05:59:46 +0000
Subject: [issue15262] Idle does not show traceback in other threads
In-Reply-To: <1341563293.08.0.285980110052.issue15262@psf.upfronthosting.co.za>
Message-ID: <1341640786.48.0.768277215395.issue15262@psf.upfronthosting.co.za>


Mark <myagna01 at students.poly.edu> added the comment:

So, I should not hold my breath in the hope of this being fixed in 2.7?

----------

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

From report at bugs.python.org  Sat Jul  7 08:03:49 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 06:03:49 +0000
Subject: [issue15270] "Economy of Expression" section outdated
Message-ID: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The "Economy of Expression" section of the Dev Guide's "Documenting Python"--

http://docs.python.org/devguide/documenting.html#economy-of-expression

says, "The documentation for super() is an example of where a good deal of information was condensed into a few short paragraphs."

However, the documentation for super() is now nine short paragraphs.  Back in Python 2.2 (when super() was introduced), the description really was only two short paragraphs (along with a brief code snippet):

http://docs.python.org/release/2.2.3/lib/built-in-funcs.html

So this might no longer be the best example.

----------
components: Devguide
keywords: easy
messages: 164788
nosy: cjerdonek, ezio.melotti
priority: normal
severity: normal
status: open
title: "Economy of Expression" section outdated
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 08:09:52 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 Jul 2012 06:09:52 +0000
Subject: [issue15246] Line coverage for collectionts.abc.Set
In-Reply-To: <1341367326.82.0.277858740936.issue15246@psf.upfronthosting.co.za>
Message-ID: <1341641392.59.0.986010891341.issue15246@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/issue15246>
_______________________________________

From report at bugs.python.org  Sat Jul  7 08:13:06 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 Jul 2012 06:13:06 +0000
Subject: [issue15265] random.sample() docs unclear on k < len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341641586.93.0.48758252835.issue15265@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
priority: normal -> low

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

From report at bugs.python.org  Sat Jul  7 10:10:22 2012
From: report at bugs.python.org (=?utf-8?b?SW9udcibIEFyyJvEg3JpyJlp?=)
Date: Sat, 07 Jul 2012 08:10:22 +0000
Subject: [issue15125] argparse: positional arguments containing - in name not
	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1341648622.71.0.625287845284.issue15125@psf.upfronthosting.co.za>


Ionu? Ar??ri?i <ionut at artarisi.eu> added the comment:

I'm working on this right now as part of EuroPython's CPython sprint.

----------
nosy: +mapleoin

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

From report at bugs.python.org  Sat Jul  7 10:18:40 2012
From: report at bugs.python.org (Dougal Matthews)
Date: Sat, 07 Jul 2012 08:18:40 +0000
Subject: [issue12907] Update test coverage devguide page
In-Reply-To: <1315284413.51.0.757189280849.issue12907@psf.upfronthosting.co.za>
Message-ID: <1341649120.02.0.506733666777.issue12907@psf.upfronthosting.co.za>


Changes by Dougal Matthews <dougal85 at gmail.com>:


----------
nosy: +d0ugal

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

From report at bugs.python.org  Sat Jul  7 10:23:33 2012
From: report at bugs.python.org (Catalin Iacob)
Date: Sat, 07 Jul 2012 08:23:33 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1341649413.11.0.430486935026.issue5053@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

So, how to move this further?

In #13425 Petri proposes 4 alternatives, copying them here:

1) Document the function to make it officially part of the public API
2) Rename and move the function to http.server
3) Leave it undocumented and just fix it
4) Deprecate the function to be removed in 3.4 or 3.5 and "fix" it to always return [].

I assume 4) meant:
4) Deprecate the function to be removed in 3.4 or 3.5 and fix to do what its docstring specifies.

My proposal is a more explicitly spelled out version 2):
5) Remove the function, replace its usage in http.server.CGIHTTPRequestHandler and add a test for http.server.CGIHTTPRequestHandler that exercises the part that currently uses getallmatchingheaders since that's obviously broken now.

The rationale for removal without deprecation is:
* the function duplicates get_all so there's no reason to have it
* it's probably not used by any (working) code because it just doesn't work

Mike can you tell us how you found out about this breakage? Were you using the function? Did you use something else to workaround it since it's broken now?

Senthil, Petri do you agree with option 5)? If so I can provide a patch.

----------
nosy: +catalin.iacob

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

From report at bugs.python.org  Sat Jul  7 10:34:48 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 07 Jul 2012 08:34:48 +0000
Subject: [issue11027] Implement sectionxform in configparser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1341650088.02.0.184148502071.issue11027@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Sat Jul  7 10:35:11 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 07 Jul 2012 08:35:11 +0000
Subject: [issue1410680] Add 'surgical editing' to ConfigParser
Message-ID: <1341650111.05.0.270147633398.issue1410680@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
versions: +Python 3.4 -Python 3.2

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

From report at bugs.python.org  Sat Jul  7 10:40:10 2012
From: report at bugs.python.org (Catalin Iacob)
Date: Sat, 07 Jul 2012 08:40:10 +0000
Subject: [issue12178] csv writer doesn't escape escapechar
In-Reply-To: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za>
Message-ID: <1341650410.19.0.286257761029.issue12178@psf.upfronthosting.co.za>


Changes by Catalin Iacob <iacobcatalin at gmail.com>:


----------
nosy: +larry

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

From report at bugs.python.org  Sat Jul  7 10:45:41 2012
From: report at bugs.python.org (=?utf-8?b?SW9udcibIEFyyJvEg3JpyJlp?=)
Date: Sat, 07 Jul 2012 08:45:41 +0000
Subject: [issue15271] argparse: repeatedly specifying the same argument
	ignores the previous ones
Message-ID: <1341650741.0.0.256570615986.issue15271@psf.upfronthosting.co.za>


New submission from Ionu? Ar??ri?i <ionut at artarisi.eu>:

To reproduce:

>>> import argparse
[74536 refs]
>>> parser = argparse.ArgumentParser()
[74809 refs]
>>> parser.add_argument("foo")
>>> parser.add_argument("foo")
>>> parser.parse_args(["bar"])

usage: ipython [-h] foo foo
ipython: error: too few arguments
An exception has occurred, use %tb to see the full traceback.

SystemExit: 2

>>> parser.parse_args(["bar", "baz"])
>>> Namespace(foo='baz')

So it actually makes you provide two arguments, but it loses/ignores the first one and there's no way to get it back.

----------
messages: 164791
nosy: bethard, mapleoin
priority: normal
severity: normal
status: open
title: argparse: repeatedly specifying the same argument ignores the previous ones
type: behavior

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

From report at bugs.python.org  Sat Jul  7 11:21:23 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 09:21:23 +0000
Subject: [issue15125] argparse: positional arguments containing - in name not
	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1341652883.39.0.751341292225.issue15125@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I don't see a valid use case to support "-" in the name of the positional argument.

IMHO, it should raise an error (probably a ValueError) for the add_argument in this case ...


Or we keep it as-is and close as wont-fix: if the op wants to pass "foo-bar" for the name of the positional argument ... it is his problem.
He can retrieve the value if he really want, with something like:
getattr(args, 'foo-bar')

In this case a single note in the documentation about using valid Python identifier for the names could be enough.

----------
nosy: +flox

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

From report at bugs.python.org  Sat Jul  7 11:31:39 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 09:31:39 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WTncp0QBRzMs8@mail.python.org>


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

New changeset 16ff4889a858 by Nick Coghlan in branch 'default':
Issue 14814: Provide more informative error messages in ipaddress, and ensure that errors are caught as expected
http://hg.python.org/cpython/rev/16ff4889a858

----------

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

From report at bugs.python.org  Sat Jul  7 11:35:34 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 09:35:34 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1341653734.45.0.158326680746.issue14814@psf.upfronthosting.co.za>


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

There's actually one semantic change in that last patch: IPv4Address (et al) will now accept leading zeroes in those cases where they're *not* ambiguous (i.e. values less than 8, which have identical representations in both decimal and octal notation).

----------

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

From report at bugs.python.org  Sat Jul  7 11:36:44 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 09:36:44 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1341653804.81.0.644539968665.issue14814@psf.upfronthosting.co.za>


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

Also, I noted the provisional API status in the NEWS message, but I wonder if it would make more sense to leave that kind of note for the commit messages.

----------

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

From report at bugs.python.org  Sat Jul  7 11:43:03 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 07 Jul 2012 09:43:03 +0000
Subject: [issue14241] io.UnsupportedOperation.__new__(io.UnsupportedOperation)
	fails
In-Reply-To: <1331296756.01.0.329340447456.issue14241@psf.upfronthosting.co.za>
Message-ID: <1341654183.74.0.347871746978.issue14241@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
nosy: +larry

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

From report at bugs.python.org  Sat Jul  7 11:46:56 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 09:46:56 +0000
Subject: [issue11908] Weird `slice.stop or sys.maxint`
In-Reply-To: <1303493846.17.0.214651551769.issue11908@psf.upfronthosting.co.za>
Message-ID: <1341654416.09.0.0438552948578.issue11908@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

The attached patch fixes this

----------
keywords: +patch
nosy: +bbrazil
Added file: http://bugs.python.org/file26283/issue11908-islice-docs.patch

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

From report at bugs.python.org  Sat Jul  7 11:51:14 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 09:51:14 +0000
Subject: [issue15271] argparse: repeatedly specifying the same argument
	ignores the previous ones
In-Reply-To: <1341650741.0.0.256570615986.issue15271@psf.upfronthosting.co.za>
Message-ID: <1341654674.92.0.84649744036.issue15271@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Confirmed.
It should probably raise an ArgumentError like this one.

http://docs.python.org/library/argparse.html#conflict-handler

----------
components: +Library (Lib)
nosy: +flox
stage:  -> needs patch
versions: +Python 3.3

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

From report at bugs.python.org  Sat Jul  7 11:51:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 09:51:20 +0000
Subject: [issue14241] io.UnsupportedOperation.__new__(io.UnsupportedOperation)
	fails
In-Reply-To: <1331296756.01.0.329340447456.issue14241@psf.upfronthosting.co.za>
Message-ID: <1341654680.02.0.243511331341.issue14241@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul  7 11:57:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 09:57:05 +0000
Subject: [issue15270] "Economy of Expression" section outdated
In-Reply-To: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za>
Message-ID: <1341655025.94.0.6648508333.issue15270@psf.upfronthosting.co.za>


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

The super() doc is also a good example of unreadable jargon ("dynamic execution environment" ??). Nowhere is it obvious to a beginner what super() is *practically* used for.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou, rhettinger

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

From report at bugs.python.org  Sat Jul  7 12:01:18 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Jul 2012 10:01:18 +0000
Subject: [issue15144] Possible integer overflow in operations with addresses
	and sizes.
In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za>
Message-ID: <1341655278.94.0.0168302004876.issue15144@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

If we're worrying about undefined behaviour, it looks like recent optimizations have *introduced* new undefined behaviour in the form of strict aliasing violations.  E.g., from ascii_decode:

    unsigned long value = *(const unsigned long *) _p;

(here _p has type const char *).  This should really be fixed;  compilers are known to make optimizations based on the assumption that this sort of undefined behaviour doesn't occur.

----------

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

From report at bugs.python.org  Sat Jul  7 12:08:08 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 10:08:08 +0000
Subject: [issue15144] Possible integer overflow in operations with addresses
	and sizes.
In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za>
Message-ID: <1341655688.26.0.0937467638965.issue15144@psf.upfronthosting.co.za>


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

> This should really be fixed;  compilers are known to make optimizations 
> based on the assumption that this sort of undefined behaviour doesn't
> occur.

Doesn't the compiler have all the necessary information here? It's not like a subroutine is called.
(also, I'm not sure what optimization it could actually make)

----------
nosy: +pitrou

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

From report at bugs.python.org  Sat Jul  7 12:11:34 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Jul 2012 10:11:34 +0000
Subject: [issue15144] Possible integer overflow in operations with addresses
	and sizes.
In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za>
Message-ID: <1341655894.17.0.462125865492.issue15144@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> (also, I'm not sure what optimization it could actually make)

Me neither, but it doesn't seem safe to assume that no compiler will take advantage of this.  I don't want to start guessing what compilers might or might not do;  it would be much better simply to stick to valid C where possible.

----------

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

From report at bugs.python.org  Sat Jul  7 12:13:35 2012
From: report at bugs.python.org (Greg Roodt)
Date: Sat, 07 Jul 2012 10:13:35 +0000
Subject: [issue11176] give more meaningful argument names in argparse
	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1341656015.51.0.0157141294979.issue11176@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

Is this still an issue? If so, I've created a simpler first example as suggested below. 

If we decide these docs still need a bit more work, I can also continue to provide better examples than the "foo bar" ones.

----------
keywords: +patch
nosy: +groodt
Added file: http://bugs.python.org/file26284/argparse_simple_example.diff

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

From report at bugs.python.org  Sat Jul  7 12:13:58 2012
From: report at bugs.python.org (Dougal Matthews)
Date: Sat, 07 Jul 2012 10:13:58 +0000
Subject: [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>
Message-ID: <1341656038.74.0.339972526849.issue13498@psf.upfronthosting.co.za>


Changes by Dougal Matthews <dougal85 at gmail.com>:


----------
nosy: +d0ugal

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

From report at bugs.python.org  Sat Jul  7 12:14:00 2012
From: report at bugs.python.org (Eugenio Minardi)
Date: Sat, 07 Jul 2012 10:14:00 +0000
Subject: [issue15265] random.sample() docs unclear on k < len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341656040.55.0.853324346314.issue15265@psf.upfronthosting.co.za>


Eugenio Minardi <eugenio.minardi at gmail.com> added the comment:

Added the related line to the documentation describing when the exception is raised.

----------
keywords: +patch
nosy: +kmox83
Added file: http://bugs.python.org/file26285/issue15265-fix-docs.patch

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

From report at bugs.python.org  Sat Jul  7 12:14:26 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Jul 2012 10:14:26 +0000
Subject: [issue15144] Possible integer overflow in operations with addresses
	and sizes.
In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za>
Message-ID: <1341656066.52.0.300983849681.issue15144@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

N.B. This could probably be fixed without affecting performance by using the usual union trick.  (IIUC, that trick was technically still undefined behaviour for a while, but was eventually made legal by C99 + TC3.)  As far as I know there aren't any instances of compilers causing problems with that construct.

----------

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

From report at bugs.python.org  Sat Jul  7 12:16:11 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 10:16:11 +0000
Subject: [issue15144] Possible integer overflow in operations with addresses
	and sizes.
In-Reply-To: <1341656066.52.0.300983849681.issue15144@psf.upfronthosting.co.za>
Message-ID: <1341656094.3394.2.camel@localhost.localdomain>


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

> N.B. This could probably be fixed without affecting performance by
> using the usual union trick.

How would it work? We would have to add various unions to the
PyUnicode_Object definition?

----------

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

From report at bugs.python.org  Sat Jul  7 12:19:47 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 10:19:47 +0000
Subject: [issue15272] pkgutil.find_loader accepts invalid module names
Message-ID: <1341656387.47.0.245292094882.issue15272@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The pkgutil import emulation is insane and permits modules identifiers to contain paths.

Identified in #15230 (reporting some very surprising behaviour from runpy.run_module).

----------
messages: 164806
nosy: brett.cannon, ncoghlan
priority: normal
severity: normal
status: open
title: pkgutil.find_loader accepts invalid module names
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul  7 12:24:35 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 10:24:35 +0000
Subject: [issue15130] remove redundant paragraph in socket howto
In-Reply-To: <1340311752.3.0.940656841103.issue15130@psf.upfronthosting.co.za>
Message-ID: <1341656675.91.0.203067331445.issue15130@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

Issue confirmed, patch looks good.

----------
nosy: +bbrazil

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

From report at bugs.python.org  Sat Jul  7 12:24:47 2012
From: report at bugs.python.org (=?utf-8?b?SW9udcibIEFyyJvEg3JpyJlp?=)
Date: Sat, 07 Jul 2012 10:24:47 +0000
Subject: [issue15125] argparse: positional arguments containing - in name not
	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1341656687.66.0.0115353596468.issue15125@psf.upfronthosting.co.za>


Ionu? Ar??ri?i <ionut at artarisi.eu> added the comment:

I agree with Florent that this is maybe just a documentation issue, since the argument is accessible via getattr().

----------
keywords: +patch
Added file: http://bugs.python.org/file26286/argparse-argument-names.diff

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

From report at bugs.python.org  Sat Jul  7 12:24:48 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Jul 2012 10:24:48 +0000
Subject: [issue15144] Possible integer overflow in operations with addresses
	and sizes.
In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za>
Message-ID: <1341656688.86.0.355372302578.issue15144@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> How would it work? We would have to add various unions to the
> PyUnicode_Object definition?

No, you'd just need a temporary union defined in unicodeobject.c that would look something like:

typedef union { unsigned long v; char s[SIZEOF_LONG]; } U;

(with better choices of names).  Python/dtoa.c does a similar thing to read / write the pieces of a C double using integers safely.

----------

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

From report at bugs.python.org  Sat Jul  7 12:26:13 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Jul 2012 10:26:13 +0000
Subject: [issue15144] Possible integer overflow in operations with addresses
	and sizes.
In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za>
Message-ID: <1341656773.56.0.871448174319.issue15144@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'll see if I can come up with a patch, and open a new issue for it (since I've successfully derailed this issue from its original topic)

----------

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

From report at bugs.python.org  Sat Jul  7 12:27:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 10:27:14 +0000
Subject: [issue14990] detect_encoding should fail with SyntaxError on invalid
	encoding
In-Reply-To: <1338719342.67.0.917704298784.issue14990@psf.upfronthosting.co.za>
Message-ID: <3WTprx428GzN5P@mail.python.org>


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

New changeset 5020afc0b7c9 by Florent Xicluna in branch '3.2':
Issue #14990: tokenize: correctly fail with SyntaxError on invalid encoding declaration.
http://hg.python.org/cpython/rev/5020afc0b7c9

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

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

From report at bugs.python.org  Sat Jul  7 12:29:51 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 10:29:51 +0000
Subject: [issue14990] detect_encoding should fail with SyntaxError on invalid
	encoding
In-Reply-To: <1338719342.67.0.917704298784.issue14990@psf.upfronthosting.co.za>
Message-ID: <1341656991.55.0.803966752996.issue14990@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Thanks. Fixed in trunk too, changeset b4322ad1fec4

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

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

From report at bugs.python.org  Sat Jul  7 12:37:19 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 10:37:19 +0000
Subject: [issue15094] Incorrectly placed #endif in _tkinter.c.
In-Reply-To: <1339927047.37.0.67596869478.issue15094@psf.upfronthosting.co.za>
Message-ID: <1341657439.59.0.0231483277835.issue15094@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

Issue confirmed, patch looks good.

----------
nosy: +bbrazil

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

From report at bugs.python.org  Sat Jul  7 12:42:19 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 10:42:19 +0000
Subject: [issue14879] invalid docs for subprocess exceptions with shell=True
In-Reply-To: <1337666994.08.0.287605633225.issue14879@psf.upfronthosting.co.za>
Message-ID: <1341657739.09.0.82313546603.issue14879@psf.upfronthosting.co.za>


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

I would add a simple note to the exceptions section:

"Note, when "shell=True", OSError will be raised by the child only if the selected shell itself cannot be found. To determine if the shell failed to find the requested application, it is necessary to check the return code or output from the subprcess."

----------

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

From report at bugs.python.org  Sat Jul  7 12:43:29 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 07 Jul 2012 10:43:29 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1341657809.63.0.698649285853.issue5053@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

My 4) actually meant that it should always return []. This is what it currently does, so it could be spelled out clearly in the code.

IIRC, getallmatchingheaders() cannot be emulated one-to-one using get_all(), because it handles continuation lines differently. That's why I thought removing or deprecating without fixing it would be the best.

rfc822.Message.getallmatchingheaders() is documented in Python 2, so removing it could make it harder to port code from Python 2 to Python 3. On the other hand, it's broken, so having it removed could actually make things better by not introducing hard-to-find bugs.

All in all, I'm not sure what's the best thing to do.

----------
nosy: +ezio.melotti
versions: +Python 3.3 -Python 3.1

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

From report at bugs.python.org  Sat Jul  7 12:46:20 2012
From: report at bugs.python.org (Floris Bruynooghe)
Date: Sat, 07 Jul 2012 10:46:20 +0000
Subject: [issue8881] socket.getaddrinfo() should return named tuples
In-Reply-To: <1275514288.42.0.225628200657.issue8881@psf.upfronthosting.co.za>
Message-ID: <1341657980.03.0.677038049044.issue8881@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

Attached in a patch for this, I've also changed the version to 3.4 since this is a feature and therefore probably too late to go in 3.3.  Please let me know if anything is inadequate.

----------
keywords: +patch
versions: +Python 3.4 -Python 3.3
Added file: http://bugs.python.org/file26287/getaddrinfo.patch

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

From report at bugs.python.org  Sat Jul  7 12:47:45 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 10:47:45 +0000
Subject: [issue15230] runpy.run_path doesn't set __package__ correctly
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <1341658065.35.0.602404575235.issue15230@psf.upfronthosting.co.za>


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

Firstly, I think you've identified a real bug with __package__ not being set correctly when using runpy.run_path (and I have updated this issue title accordingly).

I have also created a separate bug report (#15272) for the bizarre behaviour you identified in runpy.run_module - names containing "/" characters should be rejected as invalid. 

One of the main reasons you're having trouble though is that you can only do relative imports when inside a package - at the top level (as both of your modules are) relative imports are illegal. By forcing package to "__main__" you are claiming a location in the package namespace of "__main__.__main__" which doesn't make any sense.

The module life cycle problem for functions is covered in #812369. The only reason you're not hitting it in the run_module case is that when "alter_sys" is False, no temporary module is created. For data attributes (the intended use case for runpy), this all works fine regardless, but functions (which retain a reference to the original module namespace) will only work properly with alter_sys turned off. There should probably be a general disclaimer in the module docs that functions and classes are not guaranteed to be valid after using runpy, and importlib.import_module should be used instead for such cases.

#9235 looks into ways the runpy module might be enhanced with a CodeRunner class for other reasons, but the same mechanism could be used to keep the temporary module alive without storing it in sys.modules.

----------
title: runpy.run_path broken: Breaks scoping; pollutes sys.modules; doesn't set __package__ -> runpy.run_path doesn't set __package__ correctly

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

From report at bugs.python.org  Sat Jul  7 12:49:59 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Jul 2012 10:49:59 +0000
Subject: [issue15144] Possible integer overflow in operations with addresses
	and sizes.
In-Reply-To: <1341655278.94.0.0168302004876.issue15144@psf.upfronthosting.co.za>
Message-ID: <1341658229.2458.15.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> If we're worrying about undefined behaviour, it looks like recent optimizations have *introduced* new undefined behaviour in the form of strict aliasing violations.  E.g., from ascii_decode:
> 
>     unsigned long value = *(const unsigned long *) _p;
> 
> (here _p has type const char *).

I don't see what the undefined behavior. Can you specify exactly the
item of the Standard, in which it is mentioned?

>   This should really be fixed;  compilers are known to make optimizations based on the assumption that this sort of undefined behaviour doesn't occur.

I don't know how else you can rewrite it, without destroying completely
the effect of optimization.

In any case, I don't think that the original patch introduces some new
undefined behavior.

----------

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

From report at bugs.python.org  Sat Jul  7 12:51:21 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 10:51:21 +0000
Subject: [issue8881] socket.getaddrinfo() should return named tuples
In-Reply-To: <1275514288.42.0.225628200657.issue8881@psf.upfronthosting.co.za>
Message-ID: <1341658281.69.0.383764009637.issue8881@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Jul  7 12:51:39 2012
From: report at bugs.python.org (Greg Roodt)
Date: Sat, 07 Jul 2012 10:51:39 +0000
Subject: [issue15183] it should be made clear that the statement in the
	--setup option and the setup kw arg aren't included in the count
In-Reply-To: <1340647320.14.0.672684715585.issue15183@psf.upfronthosting.co.za>
Message-ID: <1341658299.06.0.0327666649332.issue15183@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

Confirmed that the setup statement is correctly excluded from the overall timed run.

I've updated the docstring and rst to make this clearer.

----------
keywords: +patch
nosy: +groodt
Added file: http://bugs.python.org/file26288/timeit_setup_clarification.diff

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

From report at bugs.python.org  Sat Jul  7 13:08:50 2012
From: report at bugs.python.org (Catalin Iacob)
Date: Sat, 07 Jul 2012 11:08:50 +0000
Subject: [issue8264] hasattr doesn't show private (double underscore)
	attributes exist
In-Reply-To: <1269946346.53.0.630682854213.issue8264@psf.upfronthosting.co.za>
Message-ID: <1341659330.53.0.1415517488.issue8264@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

Attached a patch that adds a note for getattr and setattr. hasattr is documented in terms of getattr so I would say it's not needed there.

I don't know if the interaction with private attributes is confusing enough that it's worth increasing the verbosity of the getattr and setattr docs, all in all I think I'm +0 to adding the note and -0 to just closing the bug as by design and no doc change needed.

----------
keywords: +patch
nosy: +catalin.iacob
title: hasattr doensn't show private (double underscore) attributes exist -> hasattr doesn't show private (double underscore) attributes exist
Added file: http://bugs.python.org/file26289/get-set-attr-private-name-mangling.patch

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

From report at bugs.python.org  Sat Jul  7 13:09:28 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Jul 2012 11:09:28 +0000
Subject: [issue15144] Possible integer overflow in operations with addresses
	and sizes.
In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za>
Message-ID: <1341659368.69.0.0240785441123.issue15144@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I don't see what the undefined behavior. Can you specify exactly the
> item of the Standard, in which it is mentioned?

It's C99 section 6.5, paragraph 7:  "An object shall have its stored value accessed only by an lvalue expression that has one of the following types ...".  It's the dereferencing of the pointer that's the problem: that's accessing a stored value of type 'char' by an lvalue expression that has type 'unsigned long'.

> In any case, I don't think that the original patch introduces some new
> undefined behavior.

Ah;  were the strict aliasing problems already there before the patch?  I didn't check.

----------

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

From report at bugs.python.org  Sat Jul  7 13:10:33 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 11:10:33 +0000
Subject: [issue15230] runpy.run_path doesn't set __package__ correctly
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <1341659433.25.0.219265710544.issue15230@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

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

From report at bugs.python.org  Sat Jul  7 13:17:09 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 11:17:09 +0000
Subject: [issue15230] runpy.run_path doesn't set __package__ correctly
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <1341659829.02.0.607951468519.issue15230@psf.upfronthosting.co.za>


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

You may also have identified a bug with pkgutil's import emulation failing to clean up sys.modules correctly when an import fails.

----------

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

From report at bugs.python.org  Sat Jul  7 13:21:53 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 11:21:53 +0000
Subject: [issue15230] runpy.run_path doesn't set __package__ correctly
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <1341660113.73.0.745468399569.issue15230@psf.upfronthosting.co.za>


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

Sorry, that's not accurate - you have enough code in b.py to make the relative import work by convincing the interpreter it's actually being done in a package.

So what you're seeing in that regard is the fact that runpy is not any kind of sandbox - it shares process global state, including the import system, with all other modules. While the temporary module will be reverted automatically by runpy, any child imports will always remain visible in sys.modules, and any other side effects will remain in place (e.g. codec registrations).

----------

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

From report at bugs.python.org  Sat Jul  7 13:43:42 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 11:43:42 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WTrY91VBHzNSS@mail.python.org>


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

New changeset af4ae710daf3 by Nick Coghlan in branch 'default':
Issue 14814: Make the ipaddress code easier to follow by using newer language features (patch by Serhiy Storchaka)
http://hg.python.org/cpython/rev/af4ae710daf3

----------

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

From report at bugs.python.org  Sat Jul  7 13:46:46 2012
From: report at bugs.python.org (Floris Bruynooghe)
Date: Sat, 07 Jul 2012 11:46:46 +0000
Subject: [issue14290] Importing script as module causes ImportError with
	pickle.load
In-Reply-To: <1331667642.01.0.680129740358.issue14290@psf.upfronthosting.co.za>
Message-ID: <1341661606.92.0.655131853655.issue14290@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

Hi, I think this is a usage error and if not you should try to provide a test case with both files for this.

Pickle needs to be able to import the module which contains the classes by the same name as the original module.  That means pickling an instance of a class defined in a script will not work unless it is the same script which did the pickling.  The object is probably pickled under the name __main__.YourClass and when you import it in another script it will be objectScript.YourClass, hence pickle is unable to find the class for the object you are trying to unpickle.

----------
nosy: +flub

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

From report at bugs.python.org  Sat Jul  7 13:47:47 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 07 Jul 2012 11:47:47 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1341661667.05.0.243206177031.issue5053@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The CGIHTTPRequestHandler fix and test would be the best thing to start with, though, as it's not related to the eventual fate of getallmatchingheaders().

----------
stage:  -> needs patch

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

From report at bugs.python.org  Sat Jul  7 13:50:12 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 11:50:12 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1341661812.74.0.600709695818.issue14814@psf.upfronthosting.co.za>


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

Many of Serhiy's tweaks were also micro-optimisations, but I committed them mainly because I found them easier to read.

----------

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

From report at bugs.python.org  Sat Jul  7 14:12:26 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 12:12:26 +0000
Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp
In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za>
Message-ID: <1341663146.66.0.793535253133.issue15002@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

I've tested this on head, and the issue appears to be buggy ftp code in python.

>From the attached tcpdump for fetching delegated-ripencc-20120706:

12:57:19.933607 IP myhost.39627 > ftp.ripe.net.ftp: Flags [.], ack 511, win 115, options [nop,nop,TS val 129353190 ecr 1632444059], length 0
12:57:19.934853 IP myhost.39627 > ftp.ripe.net.ftp: Flags [F.], seq 97, ack 511, win 115, options [nop,nop,TS val 129353191 ecr 1632444059], length 0

and a bit later:

12:57:20.043701 IP ftp.ripe.net.42707 > myhost.50818: Flags [.], seq 46337:47785, ack 1, win 227, options [nop,nop,TS val 2552550247 ecr 129353204], length 1448
12:57:20.043717 IP myhost.50818 > ftp.ripe.net.42707: Flags [.], ack 47785, win 353, options [nop,nop,TS val 129353218 ecr 2552550247], length 0
12:57:20.043816 IP ftp.ripe.net.42707 > myhost.50818: Flags [FP.], seq 47785:49153, ack 1, win 227, options [nop,nop,TS val 2552550247 ecr 129353204], length 1368
12:57:20.043992 IP myhost.50818 > ftp.ripe.net.42707: Flags [F.], seq 1, ack 49154, win 376, options [nop,nop,TS val 129353218 ecr 2552550247], length 0
12:57:20.094067 IP ftp.ripe.net.42707 > myhost.50818: Flags [.], ack 2, win 227, options [nop,nop,TS val 2552550299 ecr 129353218], length 0

As you can see we're sending a FIN without sending a close command to the control connection, and in response the server stops sending data about 49k in. Per RFC 959 section 2.3: "The server may abort data transfer if the control connections are closed without command." so this is acceptable behaviour on the part of the server, and means we need to keep the control connection open for longer.

----------
nosy: +bbrazil
Added file: http://bugs.python.org/file26290/issue15002-tcpdump-early-fin

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

From report at bugs.python.org  Sat Jul  7 14:14:25 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 07 Jul 2012 12:14:25 +0000
Subject: [issue15222] mailbox.mbox writes without empty line after each message
In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za>
Message-ID: <1341663265.61.0.330221326299.issue15222@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

MDAs blindly write their message to the end of the user's mail spool file. So, if there's no newline at the end, the mailbox gets corrupted (the new message is "joined" with the previous one).

I tested with Postfix, but this probably happens for other MDA's too.

----------

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

From report at bugs.python.org  Sat Jul  7 14:15:34 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 12:15:34 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WTsFx1Rc9zNcM@mail.python.org>


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

New changeset d03dbc324b60 by Nick Coghlan in branch 'default':
Issue 14814: Explain how to get more error detail in the ipaddress tutorial, and tweak the display for octet errors in IPv4 (noticed the formatting problem when adding to the docs)
http://hg.python.org/cpython/rev/d03dbc324b60

----------

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

From report at bugs.python.org  Sat Jul  7 14:17:00 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 12:17:00 +0000
Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp
In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za>
Message-ID: <1341663420.37.0.703169008115.issue15002@psf.upfronthosting.co.za>


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


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Sat Jul  7 14:29:13 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 07 Jul 2012 12:29:13 +0000
Subject: [issue15273] Remove unnecessarily random behavior from test_unparse.py
Message-ID: <1341664153.44.0.16452834514.issue15273@psf.upfronthosting.co.za>


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

Tools/parser/test_unparse.py is the regression test suite for Tools/unparse.  To save time, if the "cpu" resource is not enabled it only test unparsing ten files.  However it picks these files at random.

It would be nice if the test was 100% repeatable.  It might be nice if it picked the most tortuous ten files.  What ten are the most tortuous is not immediately clear, but a nice first approximation might be to pick the largest ten, provided the stat calls don't themselves make the test slow again.

----------
assignee: mark.dickinson
messages: 164831
nosy: larry, mark.dickinson
priority: low
severity: normal
stage: needs patch
status: open
title: Remove unnecessarily random behavior from test_unparse.py
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 14:30:15 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Jul 2012 12:30:15 +0000
Subject: [issue15273] Remove unnecessarily random behavior from test_unparse.py
In-Reply-To: <1341664153.44.0.16452834514.issue15273@psf.upfronthosting.co.za>
Message-ID: <1341664215.69.0.538523210742.issue15273@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: mark.dickinson -> 
keywords: +easy
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Sat Jul  7 14:31:50 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Jul 2012 12:31:50 +0000
Subject: [issue15273] Remove unnecessarily random behavior from test_unparse.py
In-Reply-To: <1341664153.44.0.16452834514.issue15273@psf.upfronthosting.co.za>
Message-ID: <1341664310.64.0.184675477698.issue15273@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ideally, it would pick a small number of files that are likely to fully exercise Python's grammar.  So things like Lib/test/test_grammar might be useful to include.

Or perhaps there should be a Python file somewhere in Lib/test whose entire purpose is to contain at least one example of each grammar construction?

----------

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

From report at bugs.python.org  Sat Jul  7 14:48:03 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 12:48:03 +0000
Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp
In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za>
Message-ID: <1341665283.14.0.696603286054.issue15002@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

More particularly, the ftpwrapper's ftp member is being GCed sometime after FtpHandler.ftp_open returns.

----------

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

From report at bugs.python.org  Sat Jul  7 14:53:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 12:53:58 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WTt6F50t6zMr6@mail.python.org>


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

New changeset 86d3b4067f74 by Nick Coghlan in branch 'default':
Issue 14814: Further clean ups to the ipaddress tutorial
http://hg.python.org/cpython/rev/86d3b4067f74

----------

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

From report at bugs.python.org  Sat Jul  7 14:57:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 12:57:14 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <3WTtB14CRxzN0G@mail.python.org>


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

New changeset d69f95e57792 by Jesus Cea in branch 'default':
Cope with OSs lying - #10142: Support for SEEK_HOLE/SEEK_DATA
http://hg.python.org/cpython/rev/d69f95e57792

----------

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

From report at bugs.python.org  Sat Jul  7 14:58:39 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 07 Jul 2012 12:58:39 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1341665919.72.0.530082045218.issue10142@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Thanks for the head-up, Antoine.

----------

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

From report at bugs.python.org  Sat Jul  7 14:59:42 2012
From: report at bugs.python.org (Catalin Iacob)
Date: Sat, 07 Jul 2012 12:59:42 +0000
Subject: [issue12271] panel.h is not found even if it's installed on various
	flavours of SUSE
In-Reply-To: <1307365298.12.0.602165301483.issue12271@psf.upfronthosting.co.za>
Message-ID: <1341665982.57.0.440484189488.issue12271@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

The same happens on OpenSUSE 12.1 so Python can't be fully built there which is a bit of a shame.

OpenSUSE uses this patch for their packages, but that would break other distributions so it's not a good solution:
-#include <panel.h>
+#include <ncurses/panel.h>

Here's a list of all curses related files in /usr/include on my OpenSUSE 12.1:
catalin at linux-vo6z:~/cpython/issue12271> find  /usr/include/  -regex '.*curses.*' -and \( -type f -or -type l \) -exec ls -lh {} \; 
-rw-r--r-- 1 root root 4.1K May 10 15:28 /usr/include/python2.7/py_curses.h
lrwxrwxrwx 1 root root 16 Nov 20  2011 /usr/include/curses.h -> ncurses/curses.h
-rw-r--r-- 1 root root 75K Oct 29  2011 /usr/include/ncurses/curses.h
-rw-r--r-- 1 root root 6.5K Oct 29  2011 /usr/include/ncurses/cursesapp.h
-rw-r--r-- 1 root root 27K Oct 29  2011 /usr/include/ncurses/cursesf.h
-rw-r--r-- 1 root root 20K Oct 29  2011 /usr/include/ncurses/cursesm.h
-rw-r--r-- 1 root root 8.3K Oct 29  2011 /usr/include/ncurses/cursesp.h
-rw-r--r-- 1 root root 49K Oct 29  2011 /usr/include/ncurses/cursesw.h
-rw-r--r-- 1 root root 7.2K Oct 29  2011 /usr/include/ncurses/cursslk.h
-rw-r--r-- 1 root root 2.9K Oct 29  2011 /usr/include/ncurses/eti.h
-rw-r--r-- 1 root root 9.1K Oct 29  2011 /usr/include/ncurses/etip.h
-rw-r--r-- 1 root root 18K Oct 29  2011 /usr/include/ncurses/form.h
-rw-r--r-- 1 root root 12K Oct 29  2011 /usr/include/ncurses/menu.h
-rw-r--r-- 1 root root 4.0K Oct 29  2011 /usr/include/ncurses/nc_tparm.h
lrwxrwxrwx 1 root root 8 Nov 20  2011 /usr/include/ncurses/ncurses.h -> curses.h
-rw-r--r-- 1 root root 3.9K Oct 29  2011 /usr/include/ncurses/ncurses_dll.h
-rw-r--r-- 1 root root 4.0K Oct 29  2011 /usr/include/ncurses/panel.h
-rw-r--r-- 1 root root 40K Oct 29  2011 /usr/include/ncurses/term.h
-rw-r--r-- 1 root root 7.2K Oct 29  2011 /usr/include/ncurses/term_entry.h
-rw-r--r-- 1 root root 3.5K Oct 29  2011 /usr/include/ncurses/termcap.h
-rw-r--r-- 1 root root 13K Oct 29  2011 /usr/include/ncurses/tic.h
-rw-r--r-- 1 root root 3.1K Oct 29  2011 /usr/include/ncurses/unctrl.h
lrwxrwxrwx 1 root root 17 Nov 20  2011 /usr/include/ncurses.h -> ncurses/ncurses.h
lrwxrwxrwx 1 root root 16 Nov 20  2011 /usr/include/ncurses6/curses.h -> ncurses/curses.h
-rw-r--r-- 1 root root 75K Oct 29  2011 /usr/include/ncurses6/ncurses/curses.h
-rw-r--r-- 1 root root 6.5K Oct 29  2011 /usr/include/ncurses6/ncurses/cursesapp.h
-rw-r--r-- 1 root root 27K Oct 29  2011 /usr/include/ncurses6/ncurses/cursesf.h
-rw-r--r-- 1 root root 20K Oct 29  2011 /usr/include/ncurses6/ncurses/cursesm.h
-rw-r--r-- 1 root root 8.3K Oct 29  2011 /usr/include/ncurses6/ncurses/cursesp.h
-rw-r--r-- 1 root root 49K Oct 29  2011 /usr/include/ncurses6/ncurses/cursesw.h
-rw-r--r-- 1 root root 7.2K Oct 29  2011 /usr/include/ncurses6/ncurses/cursslk.h
-rw-r--r-- 1 root root 2.9K Oct 29  2011 /usr/include/ncurses6/ncurses/eti.h
-rw-r--r-- 1 root root 9.1K Oct 29  2011 /usr/include/ncurses6/ncurses/etip.h
-rw-r--r-- 1 root root 18K Oct 29  2011 /usr/include/ncurses6/ncurses/form.h
-rw-r--r-- 1 root root 12K Oct 29  2011 /usr/include/ncurses6/ncurses/menu.h
-rw-r--r-- 1 root root 4.0K Oct 29  2011 /usr/include/ncurses6/ncurses/nc_tparm.h
lrwxrwxrwx 1 root root 8 Nov 20  2011 /usr/include/ncurses6/ncurses/ncurses.h -> curses.h
-rw-r--r-- 1 root root 3.9K Oct 29  2011 /usr/include/ncurses6/ncurses/ncurses_dll.h
-rw-r--r-- 1 root root 4.0K Oct 29  2011 /usr/include/ncurses6/ncurses/panel.h
-rw-r--r-- 1 root root 40K Oct 29  2011 /usr/include/ncurses6/ncurses/term.h
-rw-r--r-- 1 root root 7.2K Oct 29  2011 /usr/include/ncurses6/ncurses/term_entry.h
-rw-r--r-- 1 root root 3.5K Oct 29  2011 /usr/include/ncurses6/ncurses/termcap.h
-rw-r--r-- 1 root root 13K Oct 29  2011 /usr/include/ncurses6/ncurses/tic.h
-rw-r--r-- 1 root root 3.1K Oct 29  2011 /usr/include/ncurses6/ncurses/unctrl.h
lrwxrwxrwx 1 root root 17 Nov 20  2011 /usr/include/ncurses6/ncurses.h -> ncurses/ncurses.h
-rw-r--r-- 1 root root 92K Oct 29  2011 /usr/include/ncurses6/ncursesw/curses.h

If we look just for panel.h we get:
catalin at linux-vo6z:~/cpython/issue12271> find  /usr/include/  -regex '.*curses.*' -and \( -type f -or -type l \) -exec ls -lh {} \;  | grep panel.h
-rw-r--r-- 1 root root 4.0K Oct 29  2011 /usr/include/ncurses/panel.h
-rw-r--r-- 1 root root 4.0K Oct 29  2011 /usr/include/ncurses6/ncurses/panel.h
-rw-r--r-- 1 root root 4.0K Oct 29  2011 /usr/include/ncurses6/ncursesw/panel.h
-rw-r--r-- 1 root root 4.0K Oct 29  2011 /usr/include/ncursesw/panel.h

There is some specific code that appends '/usr/include/ncursesw' to the include list in setup.py but that doesn't get triggered here because curses_library == 'ncurses' because readline is built against that.

The attached patch makes it build and the curses tests pass but it feels kind of hack-ish. panel.h is there so Python should find it somehow therefore this is a genuine bug. Ideas for a better solution?

----------
keywords: +patch
nosy: +catalin.iacob
title: Python 2.7.x on IA64 running SLES 11 SP1 -> panel.h is not found even if it's installed on various flavours of SUSE
Added file: http://bugs.python.org/file26291/find-panel-on-opensuse.patch

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

From report at bugs.python.org  Sat Jul  7 15:08:42 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 13:08:42 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WTtRF2jRpzN37@mail.python.org>


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

New changeset 2e9cba1d1554 by Nick Coghlan in branch 'default':
Issue 14814: Correctly return NotImplemented from ipaddress._BaseNetwork.__eq__
http://hg.python.org/cpython/rev/2e9cba1d1554

----------

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

From report at bugs.python.org  Sat Jul  7 15:22:05 2012
From: report at bugs.python.org (Andrea Griffini)
Date: Sat, 07 Jul 2012 13:22:05 +0000
Subject: [issue15274] Patch for issue 5765: stack overflow evaluating
	eval("()" * 30000)
Message-ID: <CALy7ODsifKfYpqVvCcnGh1_wkeHhZvc7ks2qPMt4U+PN6-W1ew@mail.gmail.com>


New submission from Andrea Griffini <agriff at tin.it>:

This is a fix for issue #5765: stack overflow evaluating eval("()" * 30000)

The solution was to add two fields (recursion_depth and
recursion_limit) to the symbol table object and just increment and
check the depth in symtable_visit_expr raising a RuntimeError in case
the limit is exceeded.

The test case added also covers other similar cases (a.b.b.b.b.b...
and a[0][0][0][0]....)

There is no depth check in when visiting statement because I cannot
think to a way to nesting statements too much without getting other
errors before. If there is a way to do it, it would be trivial to also
cover that part.

The patch uses the current depth and current recursion limit but
multiplies them for a factor because I suppose that the amount of C
stack used by the compiler per recursion is smaller than the amount
used by the interpreter; the constant in the patch is 4. Using a
constant of 1 (i.e. just using the normal recursion limit) doesn't
allow a previously existing test about big expressions to pass.

----------
files: compiler_recursion_limit_check.patch
keywords: patch
messages: 164839
nosy: ag6502
priority: normal
severity: normal
status: open
title: Patch for issue 5765: stack overflow evaluating eval("()" * 30000)
Added file: http://bugs.python.org/file26292/compiler_recursion_limit_check.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15274>
_______________________________________
-------------- next part --------------
diff -r d9c98730e2e8 Include/symtable.h
--- a/Include/symtable.h	Sat Jul 07 13:34:50 2012 +1000
+++ b/Include/symtable.h	Sat Jul 07 14:39:38 2012 +0200
@@ -30,6 +30,8 @@
     PyObject *st_private;           /* name of current class or NULL */
     PyFutureFeatures *st_future;    /* module's future features that affect
                                        the symbol table */
+    int recursion_depth;            /* current recursion depth */
+    int recursion_limit;            /* recursion limit */
 };
 
 typedef struct _symtable_entry {
diff -r d9c98730e2e8 Lib/test/test_compile.py
--- a/Lib/test/test_compile.py	Sat Jul 07 13:34:50 2012 +1000
+++ b/Lib/test/test_compile.py	Sat Jul 07 14:39:38 2012 +0200
@@ -474,6 +474,14 @@
         self.assertInvalidSingle('f()\nxy # blah\nblah()')
         self.assertInvalidSingle('x = 5 # comment\nx = 6\n')
 
+    def test_compiler_recursion_limit(self):
+        self.assertRaises(RuntimeError, self.compile_single, "()" * 100000)
+        self.assertRaises(RuntimeError, self.compile_single, "a" + ".b" * 100000)
+        self.assertRaises(RuntimeError, self.compile_single, "a" + "[0]" * 100000)
+        self.compile_single("()" * 2000)
+        self.compile_single("a" + ".b" * 2000)
+        self.compile_single("a" + "[0]" * 2000)
+
 def test_main():
     support.run_unittest(TestSpecifics)
 
diff -r d9c98730e2e8 Python/symtable.c
--- a/Python/symtable.c	Sat Jul 07 13:34:50 2012 +1000
+++ b/Python/symtable.c	Sat Jul 07 14:39:38 2012 +0200
@@ -218,17 +218,37 @@
     return NULL;
 }
 
+/* When compiling the use of C stack is probably going to be a lot
+   lighter than when executing Python code but still can overflow
+   and causing a Python crash if not checked (e.g. eval("()"*300000)).
+   Using the current recursion limit for the compiler too seems
+   overconstraining so a factor is used to allow deeper recursion
+   when compiling an expression.
+*/
+#define COMPILER_STACK_FRAME_SCALE 4
+
 struct symtable *
 PySymtable_Build(mod_ty mod, const char *filename, PyFutureFeatures *future)
 {
     struct symtable *st = symtable_new();
     asdl_seq *seq;
     int i;
+    PyThreadState *tstate;
 
     if (st == NULL)
         return st;
     st->st_filename = filename;
     st->st_future = future;
+
+    /* Setup recursion depth check counters */
+    tstate = PyThreadState_GET();
+    if (!tstate) {
+        PySymtable_Free(st);
+        return NULL;
+    }
+    st->recursion_depth = tstate->recursion_depth * COMPILER_STACK_FRAME_SCALE;
+    st->recursion_limit = Py_GetRecursionLimit() * COMPILER_STACK_FRAME_SCALE;
+
     /* Make the initial symbol information gathering pass */
     if (!GET_IDENTIFIER(top) ||
         !symtable_enter_block(st, top, ModuleBlock, (void *)mod, 0, 0)) {
@@ -1268,6 +1288,12 @@
 static int
 symtable_visit_expr(struct symtable *st, expr_ty e)
 {
+    if (++st->recursion_depth > st->recursion_limit) {
+        PyErr_SetString(PyExc_RuntimeError,
+                        "maximum recursion depth exceeded while compiling an expression");
+        --st->recursion_depth;
+        return 0;
+    }
     switch (e->kind) {
     case BoolOp_kind:
         VISIT_SEQ(st, expr, e->v.BoolOp.values);
@@ -1280,8 +1306,10 @@
         VISIT(st, expr, e->v.UnaryOp.operand);
         break;
     case Lambda_kind: {
-        if (!GET_IDENTIFIER(lambda))
+        if (!GET_IDENTIFIER(lambda)) {
+            --st->recursion_depth;
             return 0;
+        }
         if (e->v.Lambda.args->defaults)
             VISIT_SEQ(st, expr, e->v.Lambda.args->defaults);
         if (e->v.Lambda.args->kw_defaults)
@@ -1289,12 +1317,16 @@
                                  e->v.Lambda.args->kw_defaults);
         if (!symtable_enter_block(st, lambda,
                                   FunctionBlock, (void *)e, e->lineno,
-                                  e->col_offset))
+                                  e->col_offset)) {
+            --st->recursion_depth;
             return 0;
+        }
         VISIT(st, arguments, e->v.Lambda.args);
         VISIT(st, expr, e->v.Lambda.body);
-        if (!symtable_exit_block(st, (void *)e))
+        if (!symtable_exit_block(st, (void *)e)) {
+            --st->recursion_depth;
             return 0;
+        }
         break;
     }
     case IfExp_kind:
@@ -1310,20 +1342,28 @@
         VISIT_SEQ(st, expr, e->v.Set.elts);
         break;
     case GeneratorExp_kind:
-        if (!symtable_visit_genexp(st, e))
+        if (!symtable_visit_genexp(st, e)) {
+            --st->recursion_depth;
             return 0;
+        }
         break;
     case ListComp_kind:
-        if (!symtable_visit_listcomp(st, e))
+        if (!symtable_visit_listcomp(st, e)) {
+            --st->recursion_depth;
             return 0;
+        }
         break;
     case SetComp_kind:
-        if (!symtable_visit_setcomp(st, e))
+        if (!symtable_visit_setcomp(st, e)) {
+            --st->recursion_depth;
             return 0;
+        }
         break;
     case DictComp_kind:
-        if (!symtable_visit_dictcomp(st, e))
+        if (!symtable_visit_dictcomp(st, e)) {
+            --st->recursion_depth;
             return 0;
+        }
         break;
     case Yield_kind:
     case YieldFrom_kind: {
@@ -1366,15 +1406,19 @@
         break;
     case Name_kind:
         if (!symtable_add_def(st, e->v.Name.id,
-                              e->v.Name.ctx == Load ? USE : DEF_LOCAL))
+                              e->v.Name.ctx == Load ? USE : DEF_LOCAL)) {
+            --st->recursion_depth;
             return 0;
+        }
         /* Special-case super: it counts as a use of __class__ */
         if (e->v.Name.ctx == Load &&
             st->st_cur->ste_type == FunctionBlock &&
             !PyUnicode_CompareWithASCIIString(e->v.Name.id, "super")) {
             if (!GET_IDENTIFIER(__class__) ||
-                !symtable_add_def(st, __class__, USE))
+                !symtable_add_def(st, __class__, USE)) {
+                --st->recursion_depth;
                 return 0;
+            }
         }
         break;
     /* child nodes of List and Tuple will have expr_context set */
@@ -1385,6 +1429,7 @@
         VISIT_SEQ(st, expr, e->v.Tuple.elts);
         break;
     }
+    --st->recursion_depth;
     return 1;
 }
 

From report at bugs.python.org  Sat Jul  7 15:31:14 2012
From: report at bugs.python.org (Andrea Griffini)
Date: Sat, 07 Jul 2012 13:31:14 +0000
Subject: [issue5765] stack overflow evaluating eval("()" * 30000)
In-Reply-To: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za>
Message-ID: <1341667874.77.0.0246247163794.issue5765@psf.upfronthosting.co.za>


Andrea Griffini <agriff at tin.it> added the comment:

This is a fix for this issue.

The solution was to add two fields (recursion_depth and
recursion_limit) to the symbol table object and just increment and
check the depth in symtable_visit_expr raising a RuntimeError in case
the limit is exceeded.

The test case added also covers other similar cases (a.b.b.b.b.b...
and a[0][0][0][0]....)

There is no depth check in when visiting statement because I cannot
think to a way to nesting statements too much without getting other
errors before. If there is a way to do it, it would be trivial to also
cover that part.

The patch uses the current depth and current recursion limit but
multiplies them for a factor because I suppose that the amount of C
stack used by the compiler per recursion is smaller than the amount
used by the interpreter; the constant in the patch is 4. Using a
constant of 1 (i.e. just using the normal recursion limit) doesn't
allow a previously existing test about big expressions to pass.

----------
keywords: +patch
nosy: +ag6502
Added file: http://bugs.python.org/file26293/compiler_recursion_limit_check.patch

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

From report at bugs.python.org  Sat Jul  7 15:35:25 2012
From: report at bugs.python.org (Andrea Griffini)
Date: Sat, 07 Jul 2012 13:35:25 +0000
Subject: [issue15274] Patch for issue 5765: stack overflow evaluating
	eval("()" * 30000)
In-Reply-To: <CALy7ODsifKfYpqVvCcnGh1_wkeHhZvc7ks2qPMt4U+PN6-W1ew@mail.gmail.com>
Message-ID: <1341668125.76.0.181536231673.issue15274@psf.upfronthosting.co.za>


Andrea Griffini <agriff at tin.it> added the comment:

I sent an email because I was not able to log in. The patch has been submitted to the correct issue (6765).

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Sat Jul  7 15:38:19 2012
From: report at bugs.python.org (Manuel de la Pena)
Date: Sat, 07 Jul 2012 13:38:19 +0000
Subject: [issue15275] isinstance is called a more times that needed in ntpath
Message-ID: <1341668298.8.0.671820953585.issue15275@psf.upfronthosting.co.za>


New submission from Manuel de la Pena <manuel at canonical.com>:

The problem is simple, the code that allows to use binary strings and unicode is making more calls that needed to isinstance(path, bytes) since the result of the code is not shared. For example, the following calls are present in the module:

def _get_empty(path):
    if isinstance(path, bytes):
        return b'' 
    else:
        return ''

def _get_sep(path):
    if isinstance(path, bytes):
        return b'\\'
    else:
        return '\\'

def _get_altsep(path):
    if isinstance(path, bytes):
        return b'/'
    else:
        return '/'

def _get_bothseps(path):
    if isinstance(path, bytes):
        return b'\\/'
    else:
        return '\\/'

def _get_dot(path):
    if isinstance(path, bytes):
        return b'.'
    else:
        return '.'

...

And then something similar to the following is found in the code:

def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    sep = _get_sep(path)
    dotdot = _get_dot(path) * 2
    special_prefixes = _get_special(path)
    if path.startswith(special_prefixes):
        # in the case of paths with these prefixes:
        # \\.\ -> device names
        # \\?\ -> literal paths
        # do not do any normalization, but return the path unchanged
        return path
    path = path.replace(_get_altsep(path), sep)
    prefix, path = splitdrive(path)

As you can see the isinstance call is performed more than needed which certainly affects the performance of the path operations. 

The attached patch removes the number of calls to isinstance(obj, bytes) and also ensures that the function that returns the correct literal is as fast as possible by using a dict.

----------
components: Windows
files: less_isinstance.patch
hgrepos: 140
keywords: patch
messages: 164842
nosy: mandel
priority: normal
severity: normal
status: open
title: isinstance is called a more times that needed in ntpath
versions: Python 3.3
Added file: http://bugs.python.org/file26294/less_isinstance.patch

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

From report at bugs.python.org  Sat Jul  7 15:38:21 2012
From: report at bugs.python.org (Roy Smith)
Date: Sat, 07 Jul 2012 13:38:21 +0000
Subject: [issue15265] random.sample() docs unclear on k < len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341668301.45.0.373785328924.issue15265@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

The docs describe population as a "sequence".  Your patch describes it as a "list".  I would go with:

If *len(population)* is less than *k*, raises :exc:`ValueError`.

----------

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

From report at bugs.python.org  Sat Jul  7 15:40:14 2012
From: report at bugs.python.org (Manuel de la Pena)
Date: Sat, 07 Jul 2012 13:40:14 +0000
Subject: [issue15275] isinstance is called a more times that needed in ntpath
In-Reply-To: <1341668298.8.0.671820953585.issue15275@psf.upfronthosting.co.za>
Message-ID: <1341668414.84.0.884681932277.issue15275@psf.upfronthosting.co.za>


Changes by Manuel de la Pena <manuel at canonical.com>:


Added file: http://bugs.python.org/file26295/f5c57ba1124b.diff

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

From report at bugs.python.org  Sat Jul  7 15:40:47 2012
From: report at bugs.python.org (Ariel Ben-Yehuda)
Date: Sat, 07 Jul 2012 13:40:47 +0000
Subject: [issue15276] unicode format does not really work in Python 2.x
Message-ID: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za>


New submission from Ariel Ben-Yehuda <arielb1 at mail.tau.ac.il>:

unicode formats (u'{:n}'.format) in python 2.x assume that the thousands seperator is in ascii, so this fails:

>>> import locale
>>> locale.setlocale(locale.LC_NUMERIC, 'fra') # or fr_FR on UNIX
>>> u'{:n}'.format(10000)
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    u'{:n}'.format(10000)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa0 in position 2: ordinal not in range(128)

However, it works correctly in python 3, properly returning '10\xA00000' (the \xA0 is a nbsp)

----------
messages: 164844
nosy: Ariel.Ben-Yehuda
priority: normal
severity: normal
status: open
title: unicode format does not really work in Python 2.x
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul  7 15:41:22 2012
From: report at bugs.python.org (Manuel de la Pena)
Date: Sat, 07 Jul 2012 13:41:22 +0000
Subject: [issue15275] isinstance is called a more times that needed in ntpath
In-Reply-To: <1341668298.8.0.671820953585.issue15275@psf.upfronthosting.co.za>
Message-ID: <1341668482.72.0.71515140638.issue15275@psf.upfronthosting.co.za>


Changes by Manuel de la Pena <manuel at canonical.com>:


Removed file: http://bugs.python.org/file26295/f5c57ba1124b.diff

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

From report at bugs.python.org  Sat Jul  7 15:45:13 2012
From: report at bugs.python.org (Eugenio Minardi)
Date: Sat, 07 Jul 2012 13:45:13 +0000
Subject: [issue15265] random.sample() docs unclear on k < len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341668713.99.0.502612572085.issue15265@psf.upfronthosting.co.za>


Eugenio Minardi <eugenio.minardi at gmail.com> added the comment:

Ok, I have updated the patch

----------
Added file: http://bugs.python.org/file26296/issue15265-fix-docs-update.patch

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

From report at bugs.python.org  Sat Jul  7 15:46:20 2012
From: report at bugs.python.org (Andrea Griffini)
Date: Sat, 07 Jul 2012 13:46:20 +0000
Subject: [issue1616125] Cached globals+builtins lookup optimization
Message-ID: <1341668780.42.0.274705987769.issue1616125@psf.upfronthosting.co.za>


Andrea Griffini <agriff at tin.it> added the comment:

Closing as it was a partial implementation of a bad idea with questionable gains.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Jul  7 15:54:31 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 13:54:31 +0000
Subject: [issue15276] unicode format does not really work in Python 2.x
In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za>
Message-ID: <1341669271.91.0.937670722218.issue15276@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Cf. the related issue 7300: "Unicode arguments in str.format()".

----------
nosy: +cjerdonek

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

From report at bugs.python.org  Sat Jul  7 16:02:55 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 14:02:55 +0000
Subject: [issue10248] Fix resource warnings in test_xmlrpclib
In-Reply-To: <1288444648.27.0.0542551809175.issue10248@psf.upfronthosting.co.za>
Message-ID: <1341669775.26.0.749199833829.issue10248@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

Looks like someone else has already fixed this.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Sat Jul  7 16:03:22 2012
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 07 Jul 2012 14:03:22 +0000
Subject: [issue14241] io.UnsupportedOperation.__new__(io.UnsupportedOperation)
	fails
In-Reply-To: <1331296756.01.0.329340447456.issue14241@psf.upfronthosting.co.za>
Message-ID: <1341669802.73.0.612072752068.issue14241@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

>>> io.UnsupportedOperation.__new__(io.UnsupportedOperation)
behaves correctly now (rev d9c98730e2e8)

This bug was (I believe) caused somehow by an error in OSError_new() which did not initialize self->args if OSError_init() was not called.

Here is a crash which exploited the lack of initialization:
(Works on rev 2a142141e5fd)

>>> class C(ValueError, OSError):pass
... 
>>> c = OSError.__new__(C)
>>> str(c)
Segmentation fault (core dumped)

This has already been fixed, so I'm closing this issue.

----------
assignee:  -> eric.araujo
components: +Distutils2 -Interpreter Core
nosy: +alexis, tarek
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Jul  7 16:03:37 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 14:03:37 +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: <1341669817.71.0.858039072248.issue13248@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Do we agree to remove the "max_buffer_size" from the "io" module in 3.3?

This argument is unused, and deprecated. Just dead code.
See attachment.

----------
Added file: http://bugs.python.org/file26297/issue13248_io_max_buffer_size.diff

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

From report at bugs.python.org  Sat Jul  7 16:03:59 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 14:03:59 +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: <1341669839.26.0.381040714351.issue13248@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file23928/issue13248_argparse_io_lib2to3.diff

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

From report at bugs.python.org  Sat Jul  7 16:05:59 2012
From: report at bugs.python.org (Greg Roodt)
Date: Sat, 07 Jul 2012 14:05:59 +0000
Subject: [issue8823] urllib2 does not catch httplib.BadStatusLine
In-Reply-To: <1274881450.55.0.827580135846.issue8823@psf.upfronthosting.co.za>
Message-ID: <1341669959.45.0.322992179931.issue8823@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

I've made a small change to urllib2 to catch the httplib.BadStatusLine and raise as URLError. This exception should rarely happen as it means the server is returning invalid responses. Nevertheless, I've added a test and hopefully fixed the issue.

Patch is attached. I will check if this needs to be added to newer versions of Python.

----------
keywords: +patch
nosy: +groodt
Added file: http://bugs.python.org/file26298/bad_status_urlerror.diff

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

From report at bugs.python.org  Sat Jul  7 16:06:51 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 14:06: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: <1341670011.74.0.00258460042273.issue13248@psf.upfronthosting.co.za>


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

> Do we agree to remove the "max_buffer_size" from the "io" module in 3.3?

Yes!

----------

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

From report at bugs.python.org  Sat Jul  7 16:08:35 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 07 Jul 2012 14:08:35 +0000
Subject: [issue7651] Python3: guess text file charset using the BOM
In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>
Message-ID: <1341670115.29.0.474687558568.issue7651@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

After reading the mailing list thread at

  http://mail.python.org/pipermail/python-dev/2010-January/097102.html

and waging on other concerns (e.g. how to behave on write-only and read-write modes), it looks like a PEP might be necessary to solve this once and for all.

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

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

From report at bugs.python.org  Sat Jul  7 16:08:50 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 07 Jul 2012 14:08:50 +0000
Subject: [issue7651] Python3: guess text file charset using the BOM
In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>
Message-ID: <1341670130.94.0.341571227604.issue7651@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Sat Jul  7 16:11:21 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 07 Jul 2012 14:11:21 +0000
Subject: [issue11786] ConfigParser.[Raw]ConfigParser optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <1341670281.15.0.37378651998.issue11786@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
status: pending -> closed

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

From report at bugs.python.org  Sat Jul  7 16:13:21 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 14:13:21 +0000
Subject: [issue7651] Python3: guess text file charset using the BOM
In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>
Message-ID: <1341670401.57.0.726678598181.issue7651@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

For the implementation part, there's something which already plays with the BOM in the tokenize module.

See tokenize.open(), which uses tokenize.detect_encoding() to read the BOM in some cases.

----------
nosy: +flox

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

From report at bugs.python.org  Sat Jul  7 16:16:02 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 14:16:02 +0000
Subject: [issue15277] Fix resource leak in support.py:_is_ipv6_enabled
Message-ID: <1341670562.42.0.543646268304.issue15277@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

I'm running Ubuntu Precise and have net.ipv6.conf.all.disable_ipv6 = 1 in my sysctl.conf. With this configuration at head there's a fd leak in 
_is_ipv6_enabled in support.py when the bind fails, which the attached patch should fix.

----------
components: Tests
files: ipv6-enabled-fd-leak-fix.patch
keywords: patch
messages: 164855
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource leak in support.py:_is_ipv6_enabled
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26299/ipv6-enabled-fd-leak-fix.patch

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

From report at bugs.python.org  Sat Jul  7 16:27:50 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 07 Jul 2012 14:27:50 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341671270.56.0.648598127195.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I need to pass a "--with-dtrace" to the buildbot configure. How can I do it, beside faking it manipulating the pushed "configure" script?.

----------

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

From report at bugs.python.org  Sat Jul  7 16:31:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 14:31:54 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1341671270.56.0.648598127195.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341671437.3394.5.camel@localhost.localdomain>


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

> I need to pass a "--with-dtrace" to the buildbot configure. How can I
> do it, beside faking it manipulating the pushed "configure" script?.

This is done on the buildmaster. I just did the change, can you try
again?

----------

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

From report at bugs.python.org  Sat Jul  7 16:32:24 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Jul 2012 14:32:24 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
In-Reply-To: <1341544176.33.0.68602278946.issue1767933@psf.upfronthosting.co.za>
Message-ID: <1341671554.2458.24.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Serhiy, note that _SimpleElementPath is now gone in 3.3, since ElementPath.py is always there in stdlib. Could you update the patch to reflect this?

Don't worry, _SimpleElementPath is not used in changes.

> Another thing. I'm trying really hard to phase out the doctest tests of etree, replacing them with unittest-based tests as much as possible. The doctests are causing all kinds of trouble with parametrized testing for both the Python and the C implementations. Please don't add new doctests. If you add tests, add them to existing TestCase classes, or create new ones.

Done. I replaced the encoding doctest by unittest-based tests and merge
it with StringIOTest and user IO tests in one IOTest class. Added test
for StringIO writing.

Also I've improved support of unbuffered file objects (as for
issue1470548).

----------
Added file: http://bugs.python.org/file26300/etree_write_utf16_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________
-------------- next part --------------
diff -r d03dbc324b60 Lib/test/test_xml_etree.py
--- a/Lib/test/test_xml_etree.py	Sat Jul 07 22:15:22 2012 +1000
+++ b/Lib/test/test_xml_etree.py	Sat Jul 07 17:23:00 2012 +0300
@@ -888,65 +888,6 @@
     """
     ET.XML("<?xml version='1.0' encoding='%s'?><xml />" % encoding)
 
-def encoding():
-    r"""
-    Test encoding issues.
-
-    >>> elem = ET.Element("tag")
-    >>> elem.text = "abc"
-    >>> serialize(elem)
-    '<tag>abc</tag>'
-    >>> serialize(elem, encoding="utf-8")
-    b'<tag>abc</tag>'
-    >>> serialize(elem, encoding="us-ascii")
-    b'<tag>abc</tag>'
-    >>> serialize(elem, encoding="iso-8859-1")
-    b"<?xml version='1.0' encoding='iso-8859-1'?>\n<tag>abc</tag>"
-
-    >>> elem.text = "<&\"\'>"
-    >>> serialize(elem)
-    '<tag>&lt;&amp;"\'&gt;</tag>'
-    >>> serialize(elem, encoding="utf-8")
-    b'<tag>&lt;&amp;"\'&gt;</tag>'
-    >>> serialize(elem, encoding="us-ascii") # cdata characters
-    b'<tag>&lt;&amp;"\'&gt;</tag>'
-    >>> serialize(elem, encoding="iso-8859-1")
-    b'<?xml version=\'1.0\' encoding=\'iso-8859-1\'?>\n<tag>&lt;&amp;"\'&gt;</tag>'
-
-    >>> elem.attrib["key"] = "<&\"\'>"
-    >>> elem.text = None
-    >>> serialize(elem)
-    '<tag key="&lt;&amp;&quot;\'&gt;" />'
-    >>> serialize(elem, encoding="utf-8")
-    b'<tag key="&lt;&amp;&quot;\'&gt;" />'
-    >>> serialize(elem, encoding="us-ascii")
-    b'<tag key="&lt;&amp;&quot;\'&gt;" />'
-    >>> serialize(elem, encoding="iso-8859-1")
-    b'<?xml version=\'1.0\' encoding=\'iso-8859-1\'?>\n<tag key="&lt;&amp;&quot;\'&gt;" />'
-
-    >>> elem.text = '\xe5\xf6\xf6<>'
-    >>> elem.attrib.clear()
-    >>> serialize(elem)
-    '<tag>\xe5\xf6\xf6&lt;&gt;</tag>'
-    >>> serialize(elem, encoding="utf-8")
-    b'<tag>\xc3\xa5\xc3\xb6\xc3\xb6&lt;&gt;</tag>'
-    >>> serialize(elem, encoding="us-ascii")
-    b'<tag>&#229;&#246;&#246;&lt;&gt;</tag>'
-    >>> serialize(elem, encoding="iso-8859-1")
-    b"<?xml version='1.0' encoding='iso-8859-1'?>\n<tag>\xe5\xf6\xf6&lt;&gt;</tag>"
-
-    >>> elem.attrib["key"] = '\xe5\xf6\xf6<>'
-    >>> elem.text = None
-    >>> serialize(elem)
-    '<tag key="\xe5\xf6\xf6&lt;&gt;" />'
-    >>> serialize(elem, encoding="utf-8")
-    b'<tag key="\xc3\xa5\xc3\xb6\xc3\xb6&lt;&gt;" />'
-    >>> serialize(elem, encoding="us-ascii")
-    b'<tag key="&#229;&#246;&#246;&lt;&gt;" />'
-    >>> serialize(elem, encoding="iso-8859-1")
-    b'<?xml version=\'1.0\' encoding=\'iso-8859-1\'?>\n<tag key="\xe5\xf6\xf6&lt;&gt;" />'
-    """
-
 def methods():
     r"""
     Test serialization methods.
@@ -2166,16 +2107,129 @@
         self.assertEqual(self._subelem_tags(e), ['a1'])
 
 
-class StringIOTest(unittest.TestCase):
+class IOTest(unittest.TestCase):
+    def test_encoding(self):
+        # Test encoding issues.
+        elem = ET.Element("tag")
+        elem.text = "abc"
+        self.assertEqual(serialize(elem), '<tag>abc</tag>')
+        self.assertEqual(serialize(elem, encoding="utf-8"),
+                b'<tag>abc</tag>')
+        self.assertEqual(serialize(elem, encoding="us-ascii"),
+                b'<tag>abc</tag>')
+        for enc in ("iso-8859-1", "utf-16", "utf-32"):
+            self.assertEqual(serialize(elem, encoding=enc),
+                    ("<?xml version='1.0' encoding='%s'?>\n"
+                     "<tag>abc</tag>" % enc).encode(enc))
+
+        elem = ET.Element("tag")
+        elem.text = "<&\"\'>"
+        self.assertEqual(serialize(elem), '<tag>&lt;&amp;"\'&gt;</tag>')
+        self.assertEqual(serialize(elem, encoding="utf-8"),
+                b'<tag>&lt;&amp;"\'&gt;</tag>')
+        self.assertEqual(serialize(elem, encoding="us-ascii"),
+                b'<tag>&lt;&amp;"\'&gt;</tag>')
+        for enc in ("iso-8859-1", "utf-16", "utf-32"):
+            self.assertEqual(serialize(elem, encoding=enc),
+                    ("<?xml version='1.0' encoding='%s'?>\n"
+                     "<tag>&lt;&amp;\"'&gt;</tag>" % enc).encode(enc))
+
+        elem = ET.Element("tag")
+        elem.attrib["key"] = "<&\"\'>"
+        self.assertEqual(serialize(elem), '<tag key="&lt;&amp;&quot;\'&gt;" />')
+        self.assertEqual(serialize(elem, encoding="utf-8"),
+                b'<tag key="&lt;&amp;&quot;\'&gt;" />')
+        self.assertEqual(serialize(elem, encoding="us-ascii"),
+                b'<tag key="&lt;&amp;&quot;\'&gt;" />')
+        for enc in ("iso-8859-1", "utf-16", "utf-32"):
+            self.assertEqual(serialize(elem, encoding=enc),
+                    ("<?xml version='1.0' encoding='%s'?>\n"
+                     "<tag key=\"&lt;&amp;&quot;'&gt;\" />" % enc).encode(enc))
+
+        elem = ET.Element("tag")
+        elem.text = '\xe5\xf6\xf6<>'
+        self.assertEqual(serialize(elem), '<tag>\xe5\xf6\xf6&lt;&gt;</tag>')
+        self.assertEqual(serialize(elem, encoding="utf-8"),
+                b'<tag>\xc3\xa5\xc3\xb6\xc3\xb6&lt;&gt;</tag>')
+        self.assertEqual(serialize(elem, encoding="us-ascii"),
+                b'<tag>&#229;&#246;&#246;&lt;&gt;</tag>')
+        for enc in ("iso-8859-1", "utf-16", "utf-32"):
+            self.assertEqual(serialize(elem, encoding=enc),
+                    ("<?xml version='1.0' encoding='%s'?>\n"
+                     "<tag>??????&lt;&gt;</tag>" % enc).encode(enc))
+
+        elem = ET.Element("tag")
+        elem.attrib["key"] = '\xe5\xf6\xf6<>'
+        self.assertEqual(serialize(elem), '<tag key="\xe5\xf6\xf6&lt;&gt;" />')
+        self.assertEqual(serialize(elem, encoding="utf-8"),
+                b'<tag key="\xc3\xa5\xc3\xb6\xc3\xb6&lt;&gt;" />')
+        self.assertEqual(serialize(elem, encoding="us-ascii"),
+                b'<tag key="&#229;&#246;&#246;&lt;&gt;" />')
+        for enc in ("iso-8859-1", "utf-16", "utf-32"):
+            self.assertEqual(serialize(elem, encoding=enc),
+                    ("<?xml version='1.0' encoding='%s'?>\n"
+                     "<tag key=\"??????&lt;&gt;\" />" % enc).encode(enc))
+
     def test_read_from_stringio(self):
         tree = ET.ElementTree()
+        stream = io.StringIO('''<?xml version="1.0"?><site></site>''')
+        tree.parse(stream)
+        self.assertEqual(tree.getroot().tag, 'site')
+
+    def test_write_to_stringio(self):
         stream = io.StringIO()
-        stream.write('''<?xml version="1.0"?><site></site>''')
-        stream.seek(0)
-        tree.parse(stream)
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        tree.write(stream, encoding='unicode')
+        self.assertEqual(stream.getvalue(), '''<site />''')
 
+    def test_read_from_bytesio(self):
+        tree = ET.ElementTree()
+        raw = io.BytesIO(b'''<?xml version="1.0"?><site></site>''')
+        tree.parse(raw)
         self.assertEqual(tree.getroot().tag, 'site')
 
+    def test_write_to_bytesio(self):
+        raw = io.BytesIO()
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        tree.write(raw)
+        self.assertEqual(raw.getvalue(), b'''<site />''')
+
+    class dummy:
+        pass
+
+    def test_read_from_user_text_reader(self):
+        stream = io.StringIO('''<?xml version="1.0"?><site></site>''')
+        reader = self.dummy()
+        reader.read = stream.read
+        tree = ET.ElementTree()
+        tree.parse(reader)
+        self.assertEqual(tree.getroot().tag, 'site')
+
+    def test_write_to_user_text_writer(self):
+        stream = io.StringIO()
+        writer = self.dummy()
+        writer.write = stream.write
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        tree.write(writer, encoding='unicode')
+        self.assertEqual(stream.getvalue(), '''<site />''')
+
+    def test_read_from_user_binary_reader(self):
+        raw = io.BytesIO(b'''<?xml version="1.0"?><site></site>''')
+        reader = self.dummy()
+        reader.read = raw.read
+        tree = ET.ElementTree()
+        tree.parse(reader)
+        self.assertEqual(tree.getroot().tag, 'site')
+        tree = ET.ElementTree()
+
+    def test_write_to_user_binary_writer(self):
+        raw = io.BytesIO()
+        writer = self.dummy()
+        writer.write = raw.write
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        tree.write(writer)
+        self.assertEqual(raw.getvalue(), b'''<site />''')
+
 
 class ParseErrorTest(unittest.TestCase):
     def test_subclass(self):
@@ -2299,7 +2353,7 @@
     test_classes = [
         ElementSlicingTest,
         BasicElementTest,
-        StringIOTest,
+        IOTest,
         ParseErrorTest,
         XincludeTest,
         ElementTreeTest,
diff -r d03dbc324b60 Lib/xml/etree/ElementTree.py
--- a/Lib/xml/etree/ElementTree.py	Sat Jul 07 22:15:22 2012 +1000
+++ b/Lib/xml/etree/ElementTree.py	Sat Jul 07 17:23:00 2012 +0300
@@ -100,6 +100,7 @@
 import sys
 import re
 import warnings
+import io
 
 from . import ElementPath
 
@@ -814,20 +815,32 @@
             encoding = encoding.lower()
         if hasattr(file_or_filename, "write"):
             file = file_or_filename
+            if encoding != "unicode":
+                if not isinstance(file, io.BufferedIOBase):
+                    if isinstance(file, io.RawIOBase):
+                        file = io.BufferedWriter(file)
+                    else:
+                        file = io.BufferedIOBase()
+                        file.writable = lambda: True
+                        file.write = file_or_filename.write
+                        try:
+                            # Required to write BOM
+                            file.seekable = file_or_filename.seekable
+                            file.tell = file_or_filename.tell
+                        except AttributeError:
+                            pass
+                file = io.TextIOWrapper(file, encoding=encoding,
+                                        errors="xmlcharrefreplace",
+                                        newline="\n")
+            close_file = False
         else:
             if encoding != "unicode":
-                file = open(file_or_filename, "wb")
+                file = open(file_or_filename, "w", encoding=encoding,
+                            errors="xmlcharrefreplace")
             else:
                 file = open(file_or_filename, "w")
-        if encoding != "unicode":
-            def write(text):
-                try:
-                    return file.write(text.encode(encoding,
-                                                  "xmlcharrefreplace"))
-                except (TypeError, AttributeError):
-                    _raise_serialization_error(text)
-        else:
-            write = file.write
+            close_file = True
+        write = file.write
         if method == "xml" and (xml_declaration or
                 (xml_declaration is None and
                  encoding not in ("utf-8", "us-ascii", "unicode"))):
@@ -843,8 +856,11 @@
             qnames, namespaces = _namespaces(self._root, default_namespace)
             serialize = _serialize[method]
             serialize(write, self._root, qnames, namespaces)
-        if file_or_filename is not file:
+        if close_file:
             file.close()
+        elif file_or_filename is not file:
+            file.flush()
+            file.detach()
 
     def write_c14n(self, file):
         # lxml.etree compatibility.  use output method instead
@@ -1134,10 +1150,9 @@
 # @defreturn string
 
 def tostring(element, encoding=None, method=None):
-    class dummy:
-        pass
     data = []
-    file = dummy()
+    file = io.BufferedIOBase()
+    file.writable = lambda: True
     file.write = data.append
     ElementTree(element).write(file, encoding, method=method)
     if encoding in (str, "unicode"):
@@ -1161,10 +1176,9 @@
 # @since 1.3
 
 def tostringlist(element, encoding=None, method=None):
-    class dummy:
-        pass
     data = []
-    file = dummy()
+    file = io.BufferedIOBase()
+    file.writable = lambda: True
     file.write = data.append
     ElementTree(element).write(file, encoding, method=method)
     # FIXME: merge small fragments into larger parts

From report at bugs.python.org  Sat Jul  7 16:34:35 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 14:34:35 +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: <1341671675.95.0.386067941776.issue13248@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file23929/issue13248_obsolescence_v2.diff

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

From report at bugs.python.org  Sat Jul  7 16:34:46 2012
From: report at bugs.python.org (Greg Roodt)
Date: Sat, 07 Jul 2012 14:34:46 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1341671686.04.0.0611988238554.issue5815@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

Bumping this as part of a bug scrub at EuroPython. Is this still an issue? Should we fix in docs or in code?

----------
nosy: +groodt

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

From report at bugs.python.org  Sat Jul  7 16:35:36 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 14:35:36 +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: <1341671736.7.0.329909451675.issue13248@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Added file: http://bugs.python.org/file26301/issue13248_obsolescence_v3.diff

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

From report at bugs.python.org  Sat Jul  7 16:45:45 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 14:45:45 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WTwbD4qHFzNWF@mail.python.org>


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

New changeset 9b359b6c9a39 by Nick Coghlan in branch 'default':
Issue 14814: Ensure ordering semantics across all 3 entity types in ipaddress are consistent and well-defined
http://hg.python.org/cpython/rev/9b359b6c9a39

----------

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

From report at bugs.python.org  Sat Jul  7 16:47:50 2012
From: report at bugs.python.org (Stephen Thorne)
Date: Sat, 07 Jul 2012 14:47:50 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
	'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1341672470.08.0.201036755073.issue14905@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

Here is a patch that synthesises the directory names at the point where file names are read in. The unit test now passes, and has had the expected failure removed.

Patch collaboration with Diarmuid Bourke <diarmuidbourke at gmail.com> at the europython sprint.

----------
keywords: +patch
nosy: +jerub
Added file: http://bugs.python.org/file26302/zipimport-issue14905.patch

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

From report at bugs.python.org  Sat Jul  7 16:47:57 2012
From: report at bugs.python.org (Greg Roodt)
Date: Sat, 07 Jul 2012 14:47:57 +0000
Subject: [issue5931] Python runtime name hardcoded in wsgiref.simple_server
In-Reply-To: <1241478665.1.0.327455115942.issue5931@psf.upfronthosting.co.za>
Message-ID: <1341672477.32.0.670116824811.issue5931@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

Bumping as part of bug scrub at EuroPython. Patch seems sensible to me. Obvious options to me are to either accept patch, close bug or write docs. Bug has not seen activity in years, so can probably be closed.

----------
nosy: +groodt

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

From report at bugs.python.org  Sat Jul  7 16:48:49 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 07 Jul 2012 14:48:49 +0000
Subject: [issue14241] io.UnsupportedOperation.__new__(io.UnsupportedOperation)
	fails
In-Reply-To: <1331296756.01.0.329340447456.issue14241@psf.upfronthosting.co.za>
Message-ID: <1341672529.42.0.583328367321.issue14241@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution: fixed -> out of date

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

From report at bugs.python.org  Sat Jul  7 16:50:12 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Jul 2012 14:50:12 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1341672612.56.0.451144562623.issue14814@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Should do _version and _max_prefixlen be instance members? Or they can be class members as _HEX_DIGITS?

----------
nosy: +storchaka

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

From report at bugs.python.org  Sat Jul  7 16:58:48 2012
From: report at bugs.python.org (=?utf-8?b?SW9udcibIEFyyJvEg3JpyJlp?=)
Date: Sat, 07 Jul 2012 14:58:48 +0000
Subject: [issue15271] argparse: repeatedly specifying the same argument
	ignores the previous ones
In-Reply-To: <1341650741.0.0.256570615986.issue15271@psf.upfronthosting.co.za>
Message-ID: <1341673128.13.0.485965286522.issue15271@psf.upfronthosting.co.za>


Ionu? Ar??ri?i <ionut at artarisi.eu> added the comment:

So I was looking into this and it seems that there are (at least) two contradicting test cases. When inheriting a parser from two parents, there are two different behaviours for positionals and for options.

In the case of positionals, there is this test:

def test_same_argument_name_parents(self):
        parents = [self.wxyz_parent, self.z_parent]
        parser = ErrorRaisingArgumentParser(parents=parents)
        self.assertEqual(parser.parse_args('1 2'.split()),
                         NS(w=None, y=None, z='2'))

and this is the context from higher up:

self.wxyz_parent.add_argument('z')
...
self.z_parent.add_argument('z')

So the tests don't expect an error when two parents provide the same argument. Instead, the eating up of the first argument (in this case '1') seems to be condoned?


When I tried to change the conflict_handler during parent action merging to 'resolve' I got another test failing:

def test_conflicting_parents(self):
        self.assertRaises(
            argparse.ArgumentError,
            argparse.ArgumentParser,
            parents=[self.w_parent, self.wxyz_parent])

context:

self.wxyz_parent.add_argument('--w')
...
self.w_parent.add_argument('--w')

This tests that two parents which provide the exact same option will raise an error.


So I think the first test is wrong and should be modified to expect an error in the case where two arguments with the same name are provided. Or is there some use case where this behaviour makes sense?

----------

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

From report at bugs.python.org  Sat Jul  7 17:04:32 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 15:04:32 +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: <3WTx0v4n3pzMQf@mail.python.org>


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

New changeset 5393382c1b1d by Florent Xicluna in branch 'default':
Issue #13248: argparse: Remove obsolete argument "version" of ArgumentParser.
http://hg.python.org/cpython/rev/5393382c1b1d

New changeset 700f989afbad by Florent Xicluna in branch 'default':
Issue #13248: io: Remove obsolete argument "max_buffer_size" of BufferedWriter and BufferedRWPair.
http://hg.python.org/cpython/rev/700f989afbad

----------

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

From report at bugs.python.org  Sat Jul  7 17:06:22 2012
From: report at bugs.python.org (=?utf-8?b?SW9udcibIEFyyJvEg3JpyJlp?=)
Date: Sat, 07 Jul 2012 15:06:22 +0000
Subject: [issue15271] argparse: repeatedly specifying the same argument
	ignores the previous ones
In-Reply-To: <1341650741.0.0.256570615986.issue15271@psf.upfronthosting.co.za>
Message-ID: <1341673582.93.0.730377081966.issue15271@psf.upfronthosting.co.za>


Ionu? Ar??ri?i <ionut at artarisi.eu> added the comment:

Here's a stab at a patch to consider conflicts between positionals. Right now conflict resolution is handled the same as in the case of options.

----------
keywords: +patch
Added file: http://bugs.python.org/file26303/disallow_duplicate_positionals.diff

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

From report at bugs.python.org  Sat Jul  7 17:07:00 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 07 Jul 2012 15:07:00 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341673620.46.0.760393874328.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Antoine, thanks.

----------

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

From report at bugs.python.org  Sat Jul  7 17:12:28 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 15:12:28 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1341673948.94.0.970601689751.issue14814@psf.upfronthosting.co.za>


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

My guess would be that they're intended as a micro-optimisation (instance lookups should be faster than class attribute lookups). You do lose on the memory front though, since they make the instances bigger.

Without a micro benchmark of any kind, I'm not inclined to mess with them at this point.

----------

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

From report at bugs.python.org  Sat Jul  7 17:18:39 2012
From: report at bugs.python.org (lovelylain)
Date: Sat, 07 Jul 2012 15:18:39 +0000
Subject: [issue15278] UnicodeDecodeError when readline in codecs.py
Message-ID: <1341674319.29.0.269195397783.issue15278@psf.upfronthosting.co.za>


New submission from lovelylain <lovelylain at keju.tk>:

This is an example, `for line in fp` will raise UnicodeDecodeError:
#! -*- coding: utf-8 -*-
import codecs

text = u'\u6731' + u'\U0002a6a5' * 18
print repr(text)

with codecs.open('test.txt', 'wb', 'utf-16-le') as fp:
    fp.write(text)

with codecs.open('test.txt', 'rb', 'utf-16-le') as fp:
    print repr(fp.read())

with codecs.open('test.txt', 'rb', 'utf-16-le') as fp:
    for line in fp:
        print repr(line)

I read code in codecs.py:
    def read(self, size=-1, chars=-1, firstline=False):

        """ Decodes data from the stream self.stream and returns the
            resulting object.
...
            If firstline is true, and a UnicodeDecodeError happens
            after the first line terminator in the input only the first line
            will be returned, the rest of the input will be kept until the
            next call to read().

        """
...
            try:
                newchars, decodedbytes = self.decode(data, self.errors)
            except UnicodeDecodeError, exc:
                if firstline:
                    newchars, decodedbytes = self.decode(data[:exc.start], self.errors)
                    lines = newchars.splitlines(True)
                    if len(lines)<=1:
                        raise
                else:
                    raise
...

It seems that the firstline argument is not consistent with its doc description.
I don't konw why this argument was added and why lines count was checked.
If it was added for readline function to fix some decode errors, we may have no EOLs in data readed, so it caused UnicodeDecodeError too.
Maybe we should write code like below to support codecs readline.

    def read(self, size=-1, chars=-1, autotruncate=False):
...
            try:
                newchars, decodedbytes = self.decode(data, self.errors)
            except UnicodeDecodeError, exc:
                if autotruncate and exc.start:
                    newchars, decodedbytes = self.decode(data[:exc.start], self.errors)
                else:
                    raise
...

----------
components: Library (Lib)
messages: 164869
nosy: lovelylain
priority: normal
severity: normal
status: open
title: UnicodeDecodeError when readline in codecs.py
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/issue15278>
_______________________________________

From report at bugs.python.org  Sat Jul  7 17:20:40 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 15:20:40 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1341674440.9.0.409408783953.issue14814@psf.upfronthosting.co.za>


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

FWIW, if we *were* going to micro-optimise ipaddress, one of the first places I'd start is using __slots__ to try to bring the instance size down (since any application using the module is likely to end up creating a *lot* of these objects). There are more significant things to worry about at this stage, though.

----------

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

From report at bugs.python.org  Sat Jul  7 17:20:51 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 15:20:51 +0000
Subject: [issue11796] Comprehensions in a class definition mostly cannot
	access class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1341674451.88.0.344757712611.issue11796@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It looks as a duplicate of issue 13557.
I close this one, because a doc patch is attached on the other.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> exec of list comprehension fails on NameError

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

From report at bugs.python.org  Sat Jul  7 17:21:17 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 15:21:17 +0000
Subject: [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1341674477.63.0.37277184183.issue13557@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +Trundle, anikom15, daniel.urban, flox, jonathan.hartley, josmiley, michael.foord, mjs0, rhettinger

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

From report at bugs.python.org  Sat Jul  7 17:22:25 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 07 Jul 2012 15:22:25 +0000
Subject: [issue15279] Spurious unittest warnings
Message-ID: <1341674545.77.0.716203051696.issue15279@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

On Mac OS X 10.7 64-bit unittest regression tests fail:


    ======================================================================
    FAIL: test_warnings (unittest.test.test_runner.Test_TextTestRunner)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/ambv/Documents/Projekty/Python/cpython/py33/Lib/unittest/test/test_runner.py", line 269, in test_warnings
        self.assertEqual(len(out), 12)
    AssertionError: 15 != 12

    ----------------------------------------------------------------------
    Ran 568 tests in 24.441s

    FAILED (failures=1, skipped=1)
    test test_unittest failed


It looks like warnings generated by unittest aren't properly limited to one for each distinct warning. Running _test_warnings.py directly shows that:

    $ ./python.exe Lib/unittest/test/_test_warnings.py
    .......
    ----------------------------------------------------------------------
    Ran 7 tests in 0.002s

    OK
    Please use assertEqual instead.
    Please use assertEqual instead.
    Please use assertEqual instead.
    dw
    dw
    dw
    Please use assertTrue instead.
    Please use assertTrue instead.
    rw
    iw
    iw
    iw
    uw
    uw
    uw
    [61188 refs]

The expected behaviour would be for each kind of the "Please use" warnings to only appear once.

----------
assignee: michael.foord
components: Library (Lib)
messages: 164872
nosy: lukasz.langa, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: Spurious unittest warnings
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul  7 17:24:22 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 Jul 2012 15:24:22 +0000
Subject: [issue15272] pkgutil.find_loader accepts invalid module names
In-Reply-To: <1341656387.47.0.245292094882.issue15272@psf.upfronthosting.co.za>
Message-ID: <1341674662.25.0.0899910532373.issue15272@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 2.7

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

From report at bugs.python.org  Sat Jul  7 17:25:43 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 15:25:43 +0000
Subject: [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1341674743.35.0.255662528306.issue13557@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Issue #11796 marked as duplicate of this one.

However the issue described in #11796 does not involve exec/execfile.
It is about scopes for list comprehension like this one.

Another doc patch should probably be written to cover the case described in #11796 too.

----------

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

From report at bugs.python.org  Sat Jul  7 17:26:12 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Jul 2012 15:26:12 +0000
Subject: [issue15279] Spurious unittest warnings
In-Reply-To: <1341674545.77.0.716203051696.issue15279@psf.upfronthosting.co.za>
Message-ID: <1341674772.0.0.0910018047572.issue15279@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/issue15279>
_______________________________________

From report at bugs.python.org  Sat Jul  7 17:33:07 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 15:33:07 +0000
Subject: [issue15280] Don't use builtins as variable names in urllib.request
Message-ID: <1341675187.35.0.731342856867.issue15280@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

See attached patch, there's still self.type in places. I also converted one map to a list comprehension.

----------
components: Library (Lib)
files: urllib-request-cleanup-builtin-names.patch
keywords: patch
messages: 164874
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Don't use builtins as variable names in urllib.request
versions: Python 3.4
Added file: http://bugs.python.org/file26304/urllib-request-cleanup-builtin-names.patch

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

From report at bugs.python.org  Sat Jul  7 17:34:01 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 Jul 2012 15:34:01 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1341675241.63.0.793496673621.issue3786@psf.upfronthosting.co.za>


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

+                # work around for assumption on line 128 of Modules/_cursesmodule.c

Is it impossible to fix the offending code instead of working around it in setup.py?

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Jul  7 17:36:30 2012
From: report at bugs.python.org (Stephen Thorne)
Date: Sat, 07 Jul 2012 15:36:30 +0000
Subject: [issue11319] Command line option -t (and -tt) does not work for a
	particular case
In-Reply-To: <1298642459.32.0.849604846008.issue11319@psf.upfronthosting.co.za>
Message-ID: <1341675390.25.0.195750228805.issue11319@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

In discussion with GvR, we've decided we're not interested in intentionally rejecting code that is valid for tab width values between 1 and 8 inclusive.

Thanks for the bug report!

----------
nosy: +jerub

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

From report at bugs.python.org  Sat Jul  7 17:36:44 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 Jul 2012 15:36:44 +0000
Subject: [issue15259] "Helping with Documentation" references missing
	dailybuild.py
In-Reply-To: <1341529306.29.0.594209420115.issue15259@psf.upfronthosting.co.za>
Message-ID: <1341675404.49.0.369007047216.issue15259@psf.upfronthosting.co.za>


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

BTW Chris, if you intend on making code patches, could you submit a contributor agreement?  http://www.python.org/psf/contrib/  (Ignore if someone already asked that.)  Thanks!

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Jul  7 17:37:16 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 Jul 2012 15:37:16 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1341675436.12.0.347301047367.issue14814@psf.upfronthosting.co.za>


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

Any reason for not using functools.total_ordering?

----------

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

From report at bugs.python.org  Sat Jul  7 17:37:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 15:37:22 +0000
Subject: [issue15281] pyvenv --symlinks option is a no-op?
Message-ID: <1341675442.68.0.329348823606.issue15281@psf.upfronthosting.co.za>


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


----------
nosy: pitrou
priority: normal
severity: normal
status: open
title: pyvenv --symlinks option is a no-op?

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

From report at bugs.python.org  Sat Jul  7 17:38:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 15:38:30 +0000
Subject: [issue15281] pyvenv --symlinks option is a no-op?
Message-ID: <1341675510.24.0.416671411372.issue15281@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It seems that, regardless of whether I specify --symlinks or not, pyvenv always creates symlinks:

$ pyvenv-3.3 env 
$ tree env/
env/
|-- bin
|   |-- activate
|   |-- pydoc
|   |-- pysetup3
|   |-- python -> python3.3
|   |-- python3 -> python3.3
|   `-- python3.3 -> /home/antoine/opt/bin/python3.3
|-- include
|-- lib
|   `-- python3.3
|       `-- site-packages
`-- pyvenv.cfg

5 directories, 7 files

----------
components: +Library (Lib)
nosy: +vinay.sajip
type:  -> behavior
versions: +Python 3.3

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

From report at bugs.python.org  Sat Jul  7 17:40:02 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 Jul 2012 15:40:02 +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: <1341675602.29.0.995992946536.issue13248@psf.upfronthosting.co.za>


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

Flox, could you put versionchanged (or versiondeprecated-removed, which could also go into 3.2) to note the removals in the doc?

----------

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

From report at bugs.python.org  Sat Jul  7 17:41:02 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 15:41:02 +0000
Subject: [issue15279] Spurious unittest warnings
In-Reply-To: <1341674545.77.0.716203051696.issue15279@psf.upfronthosting.co.za>
Message-ID: <1341675662.07.0.234267872923.issue15279@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I cannot reproduce with 3.3 on Snow Leopard (default options, default compiler).

$ ./python.exe -m test.regrtest test_unittest
[1/1] test_unittest
1 test OK.
[158600 refs]


== CPython 3.3.0b1 (tip:9807de61191c, Jul 7 2012, 10:54:30) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
==   Darwin-10.8.0-i386-64bit little-endian

----------
nosy: +flox

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

From report at bugs.python.org  Sat Jul  7 17:43:12 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Jul 2012 15:43:12 +0000
Subject: [issue11319] Command line option -t (and -tt) does not work for a
	particular case
In-Reply-To: <1298642459.32.0.849604846008.issue11319@psf.upfronthosting.co.za>
Message-ID: <1341675792.79.0.618569861497.issue11319@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The -t feature is not technically about rejecting all code that mixes tabs and spaces.  It is only about detecting code that mixes tabs and spaces IN SUCH A WAY THAT THE TAB SIZE AFFECTS THE VALIDITY OR MEANING OF THE CODE.

The sample program is only invalid if the tab size is >= 12 (or zero).

I don't think we should care about people who set their tab size > 8 -- realistically what people do is set it to values <= 8 (but >= 1), and their mistakes will be adequately caught.

----------
nosy: +gvanrossum
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sat Jul  7 17:43:27 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 07 Jul 2012 15:43:27 +0000
Subject: [issue15279] Spurious unittest warnings
In-Reply-To: <1341674545.77.0.716203051696.issue15279@psf.upfronthosting.co.za>
Message-ID: <1341675807.81.0.845635534822.issue15279@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Additional info that might help:

1. The command I'm using to build:

  MACOSX_DEPLOYMENT_TARGET=10.7 ./configure CC=gcc-apple-4.2 --with-pydebug

2. The test header in -v output:

  == CPython 3.3.0b1 (default:2e9cba1d1554, Jul 7 2012, 16:17:21) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_7)]
  ==   Darwin-11.4.0-x86_64-i386-64bit little-endian
  ==   /Users/ambv/Documents/Projekty/Python/cpython/py33/build/test_python_3894
  Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)

----------

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

From report at bugs.python.org  Sat Jul  7 17:45:06 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 15:45:06 +0000
Subject: [issue14982] pkgutil.walk_packages seems to not work properly on
	Python 3.3a
In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za>
Message-ID: <1341675906.32.0.142440683476.issue14982@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

As someone who isn't an expert on Python's import mechanisms, I'm confused by this comment at the end of pkgutil.walk_packages():

"Note: Only works for importers which define a iter_modules() method, which is non-standard but implemented by classes defined in this module."

I'm confused because importers aren't mentioned anywhere in the context of walk_packages() (in particular, `importer` is not a parameter to the function), so it's not clear to me how the note comes into play.

For example, is "importers" in reference to the import statements inside the modules in the package that one is trying to walk, or is it a reference to whether or not the user has overridden Python's standard import with a custom import function?

In particular, does this mean that the normal case of trying to walk a directory using `pkgutil.walk_packages(['my_dir'])` won't work without doing something special, and if so, can that special thing be added?

I think it would help if this were made clearer.  I came to this after trying to start working on issue 14787.

----------

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

From report at bugs.python.org  Sat Jul  7 17:49:01 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 07 Jul 2012 15:49:01 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341676141.65.0.0960925585387.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Antoine, the Solaris 11 custum buildbot is not getting the "--with-dtrace" configure parameter. Check which configuration have you changed :-?

"""
/configure --with-pydebug --with-system-ffi
 in dir /home/bpython/buildarea/custom.venus-solaris/build (timeout 1200 secs)
 watching logfiles {}
 argv: ['./configure', '--with-pydebug', '--with-system-ffi']
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sat Jul  7 17:49:39 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 07 Jul 2012 15:49:39 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341676179.6.0.895913225574.issue13405@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
nosy:  -larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sat Jul  7 17:50:54 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 15:50:54 +0000
Subject: [issue15259] "Helping with Documentation" references missing
	dailybuild.py
In-Reply-To: <1341529306.29.0.594209420115.issue15259@psf.upfronthosting.co.za>
Message-ID: <1341676254.38.0.927989906435.issue15259@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Hi ?ric, I did a couple days ago.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15259>
_______________________________________

From report at bugs.python.org  Sat Jul  7 17:51:42 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 07 Jul 2012 15:51:42 +0000
Subject: [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1341676302.62.0.893181277589.issue14787@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/issue14787>
_______________________________________

From report at bugs.python.org  Sat Jul  7 17:52:26 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 15:52:26 +0000
Subject: [issue15282] pysetup still installed
Message-ID: <1341676346.69.0.778811662054.issue15282@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It seems to have eschewed the packaging removal.

$ rm /home/antoine/opt/bin/pysetup3.3 
$ make altinstall > /dev/null
$ pysetup3.3 
Traceback (most recent call last):
  File "/home/antoine/opt/bin/pysetup3.3", line 3, in <module>
    from packaging.run import main
  File "<frozen importlib._bootstrap>", line 1294, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1245, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1294, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1258, in _find_and_load_unlocked
ImportError: No module named 'packaging'

----------
components: Build, Library (Lib)
messages: 164887
nosy: eric.araujo, georg.brandl, pitrou
priority: release blocker
severity: normal
status: open
title: pysetup still installed
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15282>
_______________________________________

From report at bugs.python.org  Sat Jul  7 17:52:53 2012
From: report at bugs.python.org (Greg Roodt)
Date: Sat, 07 Jul 2012 15:52:53 +0000
Subject: [issue1076515] shutil.move clobbers read-only files.
Message-ID: <1341676373.87.0.145034806329.issue1076515@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

I believe this can be closed.

shutil.copyfile attempts to copy file contents from src to dst, so it makes sense for this to fail if dst is read-only.

shutil.move replaces the dst, which is permitted based on directory permissions.

----------
nosy: +groodt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1076515>
_______________________________________

From report at bugs.python.org  Sat Jul  7 17:53:02 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 15:53:02 +0000
Subject: [issue15194] libffi-3.0.11 update
In-Reply-To: <1340723218.62.0.173444932066.issue15194@psf.upfronthosting.co.za>
Message-ID: <1341676382.05.0.113047884482.issue15194@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Few warnings when building trunk (on 10.6):

./Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:49: warning: function declaration isn?t a prototype
./Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:379: warning: function declaration isn?t a prototype

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15194>
_______________________________________

From report at bugs.python.org  Sat Jul  7 17:53:19 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 15:53:19 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341676399.0.0.209380430469.issue13405@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, the Solaris 11 custum buildbot is not getting the "--with-
> dtrace" configure parameter. Check which configuration have you changed 
> :-?

Well, I thought you meant the new FreeBSD buildbots. I'm gonna change the Solaris bb too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sat Jul  7 17:55:17 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 15:55:17 +0000
Subject: [issue15283] pyvenv says nothing on success
Message-ID: <1341676517.75.0.848646137047.issue15283@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

$ pyvenv-3.3 env
$

It could tell me that I need to go into the directory and type "source bin/activate" (this is probably platform-dependent :-)).

----------
components: Demos and Tools, Library (Lib)
messages: 164891
nosy: pitrou, vinay.sajip
priority: normal
severity: normal
status: open
title: pyvenv says nothing on success
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sat Jul  7 17:57:34 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 07 Jul 2012 15:57:34 +0000
Subject: [issue15276] unicode format does not really work in Python 2.x
In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za>
Message-ID: <1341676654.86.0.544631800478.issue15276@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ariel: would you like to provide a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15276>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:01:44 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 16:01:44 +0000
Subject: [issue15284] Handle ipv6 not being enabled in test_socket
Message-ID: <1341676904.33.0.668096531532.issue15284@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

If ipv6 is compiled in but disabled in the kernel then test_socket attempts to bind to ports and gets lots of stack traces. The attached patch skips the relevant tests.

----------
components: Tests
files: ipv6-disabled-test-socket.patch
keywords: patch
messages: 164893
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Handle ipv6 not being enabled in test_socket
versions: Python 3.4
Added file: http://bugs.python.org/file26305/ipv6-disabled-test-socket.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15284>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:04:22 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 07 Jul 2012 16:04:22 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341676517.75.0.848646137047.issue15283@psf.upfronthosting.co.za>
Message-ID: <1341677062.05.0.439351214287.issue15283@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It should produce any output. Command line utilities typically don't provide a success report. Would you want "mkdir env" to say "created env directory; you can now cd into it", or "cat /etc/passwd" append "successfully displayed text file"???

There are exceptions, of course, such as make(1). They may be reasonable in cases where the user might not be certain what constitutes a successful operation. In this case, it's fairly clear what you wanted to happen. In case you don't know in detail what is in the venv, you can look for yourself.

Whether "source activate" is good advise or not, I'm not so sure - I'd typically run  env/bin/python instead.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:06:28 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 07 Jul 2012 16:06:28 +0000
Subject: [issue15281] pyvenv --symlinks option is a no-op?
In-Reply-To: <1341675510.24.0.416671411372.issue15281@psf.upfronthosting.co.za>
Message-ID: <1341677188.14.0.940739543976.issue15281@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Try --no-symlinks.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15281>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:07:16 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 Jul 2012 16:07:16 +0000
Subject: [issue15282] pysetup still installed
In-Reply-To: <1341676346.69.0.778811662054.issue15282@psf.upfronthosting.co.za>
Message-ID: <1341677236.37.0.231030601684.issue15282@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

grep only finds one reference to pysetup, in the MSI code.  Are you sure you built from a clean checkout?  (i.e. no build dir with a leftover pysetup script)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15282>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:08:20 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 Jul 2012 16:08:20 +0000
Subject: [issue1076515] shutil.move clobbers read-only files.
Message-ID: <1341677300.17.0.133547530443.issue1076515@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Would a doc clarification be useful?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1076515>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:08:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 16:08:29 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341676517.75.0.848646137047.issue15283@psf.upfronthosting.co.za>
Message-ID: <1341677309.58.0.529604166121.issue15283@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Command line utilities typically don't provide a success report.

It depends which ones. Even Mercurial doesn't always abide by that rule (e.g. "hg clone" will tell you that it updates to the default branch).

> Whether "source activate" is good advise or not, I'm not so sure - I'd 
> typically run  env/bin/python instead.

That's good if you only want to use the interpreter directly, but not if you want to call any scripts.

Also, the reason I think "source activate" is good advice is that it's easy to type instead "./bin/activate" which silently succeeds (but is actually a no-op, from the caller's point of view).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:09:11 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 16:09:11 +0000
Subject: [issue15281] pyvenv --symlinks option is a no-op?
In-Reply-To: <1341675510.24.0.416671411372.issue15281@psf.upfronthosting.co.za>
Message-ID: <1341677351.66.0.00792260558487.issue15281@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

$ pyvenv-3.3 --no-symlinks env
usage: venv [-h] [--system-site-packages] [--symlinks] [--clear] [--upgrade]
            ENV_DIR [ENV_DIR ...]
venv: error: unrecognized arguments: --no-symlinks


:-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15281>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:09:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 Jul 2012 16:09:56 +0000
Subject: [issue15282] pysetup still installed
In-Reply-To: <1341676346.69.0.778811662054.issue15282@psf.upfronthosting.co.za>
Message-ID: <1341677396.18.0.308837409891.issue15282@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

An older Makefile* can also explain this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15282>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:11:07 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 16:11:07 +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: <1341677467.68.0.776912617455.issue13248@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Eric, I will check but I thought they were not documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:11:08 2012
From: report at bugs.python.org (Ariel Ben-Yehuda)
Date: Sat, 07 Jul 2012 16:11:08 +0000
Subject: [issue15276] unicode format does not really work in Python 2.x
In-Reply-To: <1341676654.86.0.544631800478.issue15276@psf.upfronthosting.co.za>
Message-ID: <CAENm7teUV9o9Fj+t6vM-Q+8dYRjfxGzf9yHer_vNL8Q9Jkbqxw@mail.gmail.com>


Ariel Ben-Yehuda <arielb1 at mail.tau.ac.il> added the comment:

I don't work on CPython

On Sat, Jul 7, 2012 at 6:57 PM, Martin v. L?wis <report at bugs.python.org>wrote:

>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Ariel: would you like to provide a patch?
>
> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue15276>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15276>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:11:19 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 16:11:19 +0000
Subject: [issue15282] pysetup still installed
In-Reply-To: <1341676346.69.0.778811662054.issue15282@psf.upfronthosting.co.za>
Message-ID: <1341677479.73.0.960554451944.issue15282@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Are you sure you built from a clean checkout?  (i.e. no build dir with 
> a leftover pysetup script)

Ach, that was it. Sorry for the false alarm.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15282>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:12:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 16:12:02 +0000
Subject: [issue15276] unicode format does not really work in Python 2.x
In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za>
Message-ID: <1341677522.64.0.551893748559.issue15276@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15276>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:17:38 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 16:17:38 +0000
Subject: [issue15228] os.utime() docs not clear on behavior on nonexistant
	files
In-Reply-To: <1341086123.85.0.135321380132.issue15228@psf.upfronthosting.co.za>
Message-ID: <1341677858.11.0.780541678947.issue15228@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

Here's a patch that should clarify this.

----------
keywords: +patch
nosy: +bbrazil
Added file: http://bugs.python.org/file26306/issue15228-utime-touch-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15228>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:18:01 2012
From: report at bugs.python.org (Justin Venus)
Date: Sat, 07 Jul 2012 16:18:01 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1341675241.63.0.793496673621.issue3786@psf.upfronthosting.co.za>
Message-ID: <CACL=7asEfCEZnUgvNaBV8Ye-a_JwcoxfgO-_OGrTZ5u0J1T-OQ@mail.gmail.com>


Justin Venus <justin.venus at gmail.com> added the comment:

I am sure that macro object is there for good reason, it just doesn't apply
for Solaris 11.
On Jul 7, 2012 10:34 AM, "?ric Araujo" <report at bugs.python.org> wrote:

>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> +                # work around for assumption on line 128 of
> Modules/_cursesmodule.c
>
> Is it impossible to fix the offending code instead of working around it in
> setup.py?
>
> ----------
> nosy: +eric.araujo
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3786>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3786>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:27:03 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 16:27:03 +0000
Subject: [issue15285] test_timeout failure on OSX
Message-ID: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

I have this repeatable failure on OSX.


$ time ./python.exe -m test.regrtest -uall -W test_timeout
[1/1] test_timeout
testBlockingThenTimeout (test.test_timeout.CreationTestCase) ... ok
testFloatReturnValue (test.test_timeout.CreationTestCase) ... ok
testObjectCreation (test.test_timeout.CreationTestCase) ... ok
testRangeCheck (test.test_timeout.CreationTestCase) ... ok
testReturnType (test.test_timeout.CreationTestCase) ... ok
testTimeoutThenBlocking (test.test_timeout.CreationTestCase) ... ok
testTypeCheck (test.test_timeout.CreationTestCase) ... ok
testAcceptTimeout (test.test_timeout.TCPTimeoutTestCase) ... ok
testConnectTimeout (test.test_timeout.TCPTimeoutTestCase) ... ERROR
testRecvTimeout (test.test_timeout.TCPTimeoutTestCase) ... ok
testSend (test.test_timeout.TCPTimeoutTestCase) ... ok
testSendall (test.test_timeout.TCPTimeoutTestCase) ... ok
testSendto (test.test_timeout.TCPTimeoutTestCase) ... ok
testRecvfromTimeout (test.test_timeout.UDPTimeoutTestCase) ... ok

======================================================================
ERROR: testConnectTimeout (test.test_timeout.TCPTimeoutTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_timeout.py", line 148, in testConnectTimeout
    self._sock_operation(1, 0.001, 'connect', addr)
  File "./Lib/test/test_timeout.py", line 119, in _sock_operation
    method(*args)
PermissionError: [Errno 13] Permission denied

----------------------------------------------------------------------
Ran 14 tests in 9.406s

FAILED (errors=1)
test test_timeout failed
1 test failed:
    test_timeout
[105213 refs]

real	0m9.907s
user	0m0.432s
sys	0m0.038s

----------
components: Library (Lib)
messages: 164906
nosy: flox
priority: normal
severity: normal
status: open
title: test_timeout failure on OSX
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:27:14 2012
From: report at bugs.python.org (Stephen Thorne)
Date: Sat, 07 Jul 2012 16:27:14 +0000
Subject: [issue1508475] transparent gzip compression in urllib
Message-ID: <1341678434.13.0.0143798365791.issue1508475@psf.upfronthosting.co.za>


Changes by Stephen Thorne <stephen at thorne.id.au>:


----------
nosy: +jerub

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1508475>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:44:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 16:44:01 +0000
Subject: [issue15277] Fix resource leak in support.py:_is_ipv6_enabled
In-Reply-To: <1341670562.42.0.543646268304.issue15277@psf.upfronthosting.co.za>
Message-ID: <3WTzCg5x1xzMxB@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c9299edf1f67 by Ross Lagerwall in branch 'default':
#15277: Fix a resource leak in support.py when IPv6 is disabled.
http://hg.python.org/cpython/rev/c9299edf1f67

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15277>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:47:16 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 07 Jul 2012 16:47:16 +0000
Subject: [issue15277] Fix resource leak in support.py:_is_ipv6_enabled
In-Reply-To: <1341670562.42.0.543646268304.issue15277@psf.upfronthosting.co.za>
Message-ID: <1341679636.11.0.163009313928.issue15277@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Thanks.

test_socket seems to be broken in all branches when running with net.ipv6.conf.all.disable_ipv6 = 1 but I'll open a new issue for that.

----------
assignee:  -> rosslagerwall
nosy: +rosslagerwall
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15277>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:47:22 2012
From: report at bugs.python.org (Manuel de la Pena)
Date: Sat, 07 Jul 2012 16:47:22 +0000
Subject: [issue15286] normpath does not work with local literal paths
Message-ID: <1341679642.43.0.277228630346.issue15286@psf.upfronthosting.co.za>


New submission from Manuel de la Pena <manuel at canonical.com>:

Local literal paths are those paths that do use the \\?\ that allows to have paths longer that the MAX_PATH set by Windows (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#short_vs._long_names).

While UNC (http://en.wikipedia.org/wiki/Path_%28computing%29) paths should not be normalized, local paths that do use the \\?\ prefix should so that developers that use such a trink to allow longer paths on windows do not have to wrapp the call in the following way:

LONG_PATH_PREFIX = '\\?\'
path = path.replace(LONG_PATH_PREFIX, '')
result = LONG_PATH_PREFIX + os.path.normpath(path)

The possible solution would be for the normalization to work and return the path normalized with the prefix added.

----------
components: Windows
files: literal-normpath.patch
hgrepos: 141
keywords: patch
messages: 164909
nosy: mandel
priority: normal
severity: normal
status: open
title: normpath does not work with local literal paths
versions: Python 3.3
Added file: http://bugs.python.org/file26307/literal-normpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15286>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:49:09 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 07 Jul 2012 16:49:09 +0000
Subject: [issue15277] Fix resource leak in support.py:_is_ipv6_enabled
In-Reply-To: <1341679636.11.0.163009313928.issue15277@psf.upfronthosting.co.za>
Message-ID: <4FF86880.5080105@gmail.com>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Ah, I see you've already opened a new issue for that (issue15284).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15277>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:50:33 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 16:50:33 +0000
Subject: [issue15285] test_timeout failure on OSX
In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>
Message-ID: <1341679833.69.0.683119414818.issue15285@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Sat Jul  7 18:59:17 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jul 2012 16:59:17 +0000
Subject: [issue14590] ConfigParser doesn't strip inline comment when delimiter
	occurs earlier without preceding space.
In-Reply-To: <1334541468.07.0.833607995836.issue14590@psf.upfronthosting.co.za>
Message-ID: <3WTzYJ028NzN1h@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5257bb466d18 by ?ukasz Langa in branch 'default':
Fixes #14590: ConfigParser doesn't strip inline comment when delimiter occurs
http://hg.python.org/cpython/rev/5257bb466d18

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14590>
_______________________________________

From report at bugs.python.org  Sat Jul  7 19:00:08 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 07 Jul 2012 17:00:08 +0000
Subject: [issue14590] ConfigParser doesn't strip inline comment when delimiter
	occurs earlier without preceding space.
In-Reply-To: <1334541468.07.0.833607995836.issue14590@psf.upfronthosting.co.za>
Message-ID: <1341680408.23.0.865605859604.issue14590@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14590>
_______________________________________

From report at bugs.python.org  Sat Jul  7 19:05:37 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 17:05:37 +0000
Subject: [issue15287] support.TESTFN was modified by test_builtin
Message-ID: <1341680737.17.0.537689488226.issue15287@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

There's a warning running test_builtin


$ ./python.exe -m test.regrtest -u all -v test_builtin
== CPython 3.3.0b1 (default:5b71f5891c54, Jul 7 2012, 17:47:30) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
==   Darwin-10.8.0-i386-64bit little-endian
==   ./build/test_python_77737
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[1/1] test_builtin
...

----------------------------------------------------------------------
Ran 59 tests in 0.114s

OK
Warning -- support.TESTFN was modified by test_builtin
1 test altered the execution environment:
    test_builtin
[115658 refs]

----------
assignee: ronaldoussoren
components: Macintosh, Tests
messages: 164912
nosy: flox, ronaldoussoren
priority: normal
severity: normal
status: open
title: support.TESTFN was modified by test_builtin
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15287>
_______________________________________

From report at bugs.python.org  Sat Jul  7 19:10:54 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 07 Jul 2012 17:10:54 +0000
Subject: [issue14982] pkgutil.walk_packages seems to not work properly on
	Python 3.3a
In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za>
Message-ID: <1341681054.2.0.880429176101.issue14982@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Importers are a PEP 302 API.  In the context of pkgutil, they are path hooks (see http://www.python.org/dev/peps/pep-0302/#id24), aka path importers.  A path hook is a callable that takes a path and returns a finder.  Path hooks are stored in sys.path_hooks and the finder resulting from a matching path importer is stored in sys.path_importer_cache.

pkgutil also refers to PEP 302 finders as "importers".  To be honest, the import-related nomenclature is a mess.

While you can use pkgutil.ImpImporter as a path hook, instances can also be used as metapath hooks; if you don't pass anything to ImpImporter, the resulting object acts more like a PEP 302 metapath hook that wraps the "default" import process.

(See Lib/pkgutil.py)

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14982>
_______________________________________

From report at bugs.python.org  Sat Jul  7 19:24:56 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Jul 2012 17:24:56 +0000
Subject: [issue15285] test_timeout failure on OSX
In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>
Message-ID: <1341681896.36.0.540153858393.issue15285@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

What version of OS X?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Sat Jul  7 19:38:38 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 17:38:38 +0000
Subject: [issue15286] normpath does not work with local literal paths
In-Reply-To: <1341679642.43.0.277228630346.issue15286@psf.upfronthosting.co.za>
Message-ID: <1341682718.16.0.28393620547.issue15286@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, tim.golden
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15286>
_______________________________________

From report at bugs.python.org  Sat Jul  7 19:39:24 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 17:39:24 +0000
Subject: [issue15284] Handle ipv6 not being enabled in test_socket
In-Reply-To: <1341676904.33.0.668096531532.issue15284@psf.upfronthosting.co.za>
Message-ID: <1341682764.74.0.544935353761.issue15284@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
type:  -> behavior
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15284>
_______________________________________

From report at bugs.python.org  Sat Jul  7 19:47:09 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 17:47:09 +0000
Subject: [issue14790] use packaging in setup.py
In-Reply-To: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za>
Message-ID: <1341683229.81.0.422659923545.issue14790@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14790>
_______________________________________

From report at bugs.python.org  Sat Jul  7 19:47:47 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 17:47:47 +0000
Subject: [issue14791] setup.py only adds /prefix/lib, not /prefix/lib64
In-Reply-To: <1336840843.09.0.565460268003.issue14791@psf.upfronthosting.co.za>
Message-ID: <1341683267.3.0.0135492285993.issue14791@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14791>
_______________________________________

From report at bugs.python.org  Sat Jul  7 20:00:48 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 18:00:48 +0000
Subject: [issue14982] pkgutil.walk_packages seems to not work properly on
	Python 3.3a
In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za>
Message-ID: <1341684048.14.0.509906209059.issue14982@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks a lot, Eric.  I'm going to create a new issue to clarify the note a bit, if that's okay.  At minimum, I feel like enough information should be given to let one run the examples given.

By the way, your comment, "While you can use pkgutil.ImpImporter as a path hook, instances can also be used as metapath hooks" seems to contradict the pkgutil documentation, which says, "Note that ImpImporter does not currently support being used by placement on sys.meta_path."  (According to PEP 302, "To register a meta hook, simply add the finder object to sys.meta_path.")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14982>
_______________________________________

From report at bugs.python.org  Sat Jul  7 20:15:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 18:15:57 +0000
Subject: [issue15288] Clarify the pkgutil.walk_packages() note
Message-ID: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The note at the end of the pkgutil.walk_packages() (and iter_modules()) documentation can be improved somewhat:

http://docs.python.org/dev/library/pkgutil.html#pkgutil.walk_packages

For example, "importers" aren't referenced earlier in the documentation of the function, so it's not immediately clear what they are referring to.  I also think that enough information should be given so that one can run the examples given and have them work.  They currently don't.

I can put together proposed wording.  See the issue 14982 discussion for background.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164916
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: Clarify the pkgutil.walk_packages() note
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15288>
_______________________________________

From report at bugs.python.org  Sat Jul  7 20:18:23 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 18:18:23 +0000
Subject: [issue14982] pkgutil.walk_packages seems to not work properly on
	Python 3.3a
In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za>
Message-ID: <1341685103.92.0.589679434875.issue14982@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I created issue 15288 to improve the documentation around this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14982>
_______________________________________

From report at bugs.python.org  Sat Jul  7 20:20:49 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 07 Jul 2012 18:20:49 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1341685249.94.0.991030946369.issue1767933@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Thanks for your work on this, Serhiy. I made some comments in the code-review tool, mainly about the complexity of the resulting code. 

Great work on switching the tests to unittest, much appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Sat Jul  7 20:37:10 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Jul 2012 18:37:10 +0000
Subject: [issue5931] Python runtime name hardcoded in wsgiref.simple_server
In-Reply-To: <1241478665.1.0.327455115942.issue5931@psf.upfronthosting.co.za>
Message-ID: <1341686230.7.0.146912296163.issue5931@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Phillip, this is a trivial wsgiref patch. Do you have any opinion?

----------
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5931>
_______________________________________

From report at bugs.python.org  Sat Jul  7 20:42:37 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 Jul 2012 18:42:37 +0000
Subject: [issue12927] test_ctypes: segfault with suncc
In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za>
Message-ID: <1341686557.59.0.574069718051.issue12927@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Given that --with-system-ffi works, I don't think we need the additional
burden of maintaining patches for libffi/suncc.

----------
resolution:  -> wont fix
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12927>
_______________________________________

From report at bugs.python.org  Sat Jul  7 21:10:32 2012
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 07 Jul 2012 19:10:32 +0000
Subject: [issue15286] normpath does not work with local literal paths
In-Reply-To: <1341679642.43.0.277228630346.issue15286@psf.upfronthosting.co.za>
Message-ID: <1341688232.89.0.0719553116082.issue15286@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Hi mandel :)

With the exception of the "import string" inside of _get_letters (policy is to do all imports at the top), it looks ok just by reading.

Assigning to myself to complete it after I return from holiday in a few days (unless someone beats me).

----------
assignee:  -> brian.curtin
keywords: +needs review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15286>
_______________________________________

From report at bugs.python.org  Sat Jul  7 21:16:01 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 19:16:01 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341688561.35.0.0353313178051.issue15110@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch with tests. Brett, what do you think?

----------
stage:  -> patch review
Added file: http://bugs.python.org/file26308/trim_tb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sat Jul  7 21:18:42 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 19:18:42 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341688722.44.0.327802335729.issue15110@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, it has to be done in C since tb_next can't be modified from Python code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sat Jul  7 21:29:20 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Jul 2012 19:29:20 +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: <1341689360.07.0.812248273752.issue13248@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

We do not document removals after they are done as they are not an issue for back-compatibility (unlike changes and additions).

Deprecation Warnings are optionally available for checking forward-compatibility. Deprecations are sometimes noted in the regular text flow with things like "encodestring is a deprecated alias", but they are not set off with separate versionchanged: notices, as nothing has changed yet. Some deprecated features are not even documented.

The 'version' arg of class ArgumentParser is already not documented in 3.2, which is why the patch does not change argparse.rst.

"A third argument, max_buffer_size, is supported, but unused and deprecated." and "A fourth argument, max_buffer_size, is supported, but unused and deprecated." is enough for that parameter (and the patch removes those lines -- the param was already left out of the signature).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Sat Jul  7 21:36:19 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 19:36:19 +0000
Subject: [issue15286] normpath does not work with local literal paths
In-Reply-To: <1341679642.43.0.277228630346.issue15286@psf.upfronthosting.co.za>
Message-ID: <1341689779.21.0.817497298162.issue15286@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think this is wrong. The MSDN doc says:

?Because it turns off automatic expansion of the path string, the "\\?\" prefix also allows the use of ".." and "." in the path names, which can be useful if you are attempting to perform operations on a file with these otherwise reserved relative path specifiers as part of the fully qualified path.?

(from http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx#namespaces)

So by "normalizing" the extended path, you are actually changing its meaning.

Furthermore, normpath() is generally wrong in the face of symlinks, meaning it shouldn't be used at all.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15286>
_______________________________________

From report at bugs.python.org  Sat Jul  7 21:47:57 2012
From: report at bugs.python.org (samwyse)
Date: Sat, 07 Jul 2012 19:47:57 +0000
Subject: [issue15289] Adding __getitem__ as a class method doesn't work as
	expected
Message-ID: <1341690477.89.0.147882600288.issue15289@psf.upfronthosting.co.za>


New submission from samwyse <samwyse at gmail.com>:

I'm using a class as a decorator, and saving information in a class variable.  I wanted to access the information via a __getitem__ class method, but using conventional syntax doesn't work on a class.  The following exception is thrown when the attached script is run.

Traceback (most recent call last):
  File "/Users/sam/Documents/forth.py", line 34, in <module>
    print Alias["f'"]
TypeError: 'type' object has no attribute '__getitem__'

----------
components: None
files: 20120607.py
messages: 164926
nosy: samwyse
priority: normal
severity: normal
status: open
title: Adding __getitem__ as a class method doesn't work as expected
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26309/20120607.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15289>
_______________________________________

From report at bugs.python.org  Sat Jul  7 21:52:58 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 07 Jul 2012 19:52:58 +0000
Subject: [issue15281] pyvenv --symlinks option is a no-op?
In-Reply-To: <1341675510.24.0.416671411372.issue15281@psf.upfronthosting.co.za>
Message-ID: <1341690778.9.0.0405111856993.issue15281@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Following discussions on python-dev, the default is always to symlink, except on Windows (no support for true symlinks on XP and older) and Mac OS X (problems with framework builds). The --symlinks indicates, on those platforms where symlinks is not the default, to use symlinks anyway. This will most likely only be useful on Windows Vista, Windows 7 and Mac OS X with a non-framework build of Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15281>
_______________________________________

From report at bugs.python.org  Sat Jul  7 22:00:15 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 20:00:15 +0000
Subject: [issue15281] pyvenv --symlinks option is a no-op?
In-Reply-To: <1341690778.9.0.0405111856993.issue15281@psf.upfronthosting.co.za>
Message-ID: <1341691137.3394.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Following discussions on python-dev, the default is always to symlink,
> except on Windows (no support for true symlinks on XP and older) and
> Mac OS X (problems with framework builds). The --symlinks indicates,
> on those platforms where symlinks is not the default, to use symlinks
> anyway. This will most likely only be useful on Windows Vista, Windows
> 7 and Mac OS X with a non-framework build of Python.

Ok, then it might be nice to make the usage string (which is printed
with pyvenv --help) clearer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15281>
_______________________________________

From report at bugs.python.org  Sat Jul  7 22:04:41 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 07 Jul 2012 20:04:41 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341676517.75.0.848646137047.issue15283@psf.upfronthosting.co.za>
Message-ID: <1341691481.24.0.249794348568.issue15283@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The reason it says nothing on success is that it follows the general philosophy of programs on Unix. Of course, there are exceptions, but it's not obvious that pyvenv should say anything, and what it should presume is the user's next likely step. As well as running the venv's Python, any script in the venv should be immediately invokable (and call up the venv's interpreter). At the moment, that's just pydoc - but that might change over time (I originally had pysetup in there, before packaging got pulled).

AFAIK the activate script shouldn't have the executable bit set, so it shouldn't show up in e.g. autocomplete results. Note also that the activate script is bash-specific, so it may not be wise to mention it in cases where the user's shell may not be bash or a compatible shell.

It's assumed that third party tools will build on top of the existing venv support - for example, in the absence of packaging, venvs will need distribute/pip in order for users to be able to install stuff into them. These will likely provide the visual feedback required (e.g. before merging into CPython, the pythonv version of pyvenv installed Distribute in the venv, which showed that something was happening).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sat Jul  7 22:07:16 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 07 Jul 2012 20:07:16 +0000
Subject: [issue15281] pyvenv --symlinks option is a no-op?
In-Reply-To: <1341675510.24.0.416671411372.issue15281@psf.upfronthosting.co.za>
Message-ID: <1341691636.19.0.516773275602.issue15281@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Ok, then it might be nice to make the usage string (which is printed
with pyvenv --help) clearer.

Fair point, I'll update the help text to be clearer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15281>
_______________________________________

From report at bugs.python.org  Sat Jul  7 22:14:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 20:14:36 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341691481.24.0.249794348568.issue15283@psf.upfronthosting.co.za>
Message-ID: <1341691997.3394.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The reason it says nothing on success is that it follows the general
> philosophy of programs on Unix. Of course, there are exceptions, but
> it's not obvious that pyvenv should say anything, and what it should
> presume is the user's next likely step.

Well, having to run "source bin/activate" is not obvious (unless you've
already used virtualenv), so it's quite helpful to mention it. It's not
about being the next step, it's simply about informating the user.
Creating a venv is useless if you don't ever activate it, right.

If it's not in the pyvenv output, then perhaps it should be in the
"pyvenv --help" output. This way, users have an easy way to remind
themselves how to do. Having to context-switch to a browser and find the
module docs is too tedious.

> AFAIK the activate script shouldn't have the executable bit set, so it
> shouldn't show up in e.g. autocomplete results.

It does:

$ pyvenv-3.3 env
$ ls -la env/bin/activate 
-rwxr-xr-x 1 antoine antoine 2133 juil.  7 22:06 env/bin/activate*

> Note also that the activate script is bash-specific, so it may not be
> wise to mention it in cases where the user's shell may not be bash or
> a compatible shell.

Then the help output can be bash-specific too :)

> These will likely provide the visual feedback required (e.g. before
> merging into CPython, the pythonv version of pyvenv installed
> Distribute in the venv, which showed that something was happening).

Uh, I disagree with the idea that you should install something else to
make pyvenv useful. We should provide useful functionality out of the
box. Especially when doing so isn't particularly difficult or brittle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sat Jul  7 22:24:00 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 07 Jul 2012 20:24:00 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341691997.3394.13.camel@localhost.localdomain>
Message-ID: <20120707222359.Horde.Z5B0RbuWis5P_JrfIRTHGTA@webmail.df.eu>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Well, having to run "source bin/activate" is not obvious (unless you've
> already used virtualenv)

Using venv is not obvious in the first place. so presumably, the user has
read some documentation telling him what it is and how it's used. Presumably,
that documentation then mentions the activate script (with pros and cons).

I remain -1 on printing anything by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sat Jul  7 22:26:44 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 07 Jul 2012 20:26:44 +0000
Subject: [issue15266] Perform the same checks as PyPI for Description field
In-Reply-To: <1341615747.31.0.901910888303.issue15266@psf.upfronthosting.co.za>
Message-ID: <20120707222643.Horde.6x_TV7uWis5P_JuDwoAnHPA@webmail.df.eu>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> One maintenance issue is the possible discrepancy between PyPI?s  
> checks and distutils2?s; if the PyPI maintainers agree to announce  
> all changes to catalog-sig it could work (just like for classifiers).

We can certainly try to remember, but I expect this is prone to fail:
the next change may well be five years from now, at which point nobody
remembers that distutils2 also has such a check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15266>
_______________________________________

From report at bugs.python.org  Sat Jul  7 22:29:57 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 20:29:57 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <20120707222359.Horde.Z5B0RbuWis5P_JrfIRTHGTA@webmail.df.eu>
Message-ID: <1341692918.3394.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Well, having to run "source bin/activate" is not obvious (unless you've
> > already used virtualenv)
> 
> Using venv is not obvious in the first place.

Well, why couldn't it *become* obvious. It's not supposed to be a
complicated piece of software. It does one single thing and it has only
a handful of options (one of which is a no-op :-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sat Jul  7 22:32:32 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 07 Jul 2012 20:32:32 +0000
Subject: [issue15289] Adding __getitem__ as a class method doesn't work as
	expected
In-Reply-To: <1341690477.89.0.147882600288.issue15289@psf.upfronthosting.co.za>
Message-ID: <1341693152.9.0.467360663514.issue15289@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

This appears to be a misunderstanding about special-method lookup which, honestly, isn't super obvious at first.  It helps to remember that classes are objects like everything else in Python and thus are instances of some type (their metaclass).

Anyway, here's the key point regarding special-method lookup.  As far as Python is concerned, the following are equivalent:

  value = obj[key]

and 

  value = type(obj).__getitem__(obj, key)

Thus Alias()["f'"] will give you your answer, but Alias["f'"] tries to call type(Alias).__getitem__(Alias, key).  Since Alias is a class, it is an instance of the built-in type class, so type(alias) is type, which does not have a __getitem__() method.

Check out the following resources:

http://docs.python.org/py3k/reference/datamodel.html#special-method-names
http://docs.python.org/py3k/library/inspect.html#fetching-attributes-statically

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15289>
_______________________________________

From report at bugs.python.org  Sat Jul  7 22:37:42 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 07 Jul 2012 20:37:42 +0000
Subject: [issue15289] Adding __getitem__ as a class method doesn't work as
	expected
In-Reply-To: <1341690477.89.0.147882600288.issue15289@psf.upfronthosting.co.za>
Message-ID: <1341693462.58.0.894643055748.issue15289@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
components: +Interpreter Core -None
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15289>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:00:23 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 07 Jul 2012 21:00:23 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341694823.28.0.574496504811.issue15110@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Does it work for extension modules?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:03:41 2012
From: report at bugs.python.org (Stephen Thorne)
Date: Sat, 07 Jul 2012 21:03:41 +0000
Subject: [issue14988] _elementtree: Raise ImportError when importing of
	pyexpat fails
In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za>
Message-ID: <1341695021.73.0.60803386797.issue14988@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

With the attached patch, with python3.3(trunk) I instead get: 

./python.exe  -c 'import _elementtree'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 1294, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1261, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 432, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 347, in set_package_wrapper
  File "<frozen importlib._bootstrap>", line 360, in set_loader_wrapper
  File "<frozen importlib._bootstrap>", line 872, in load_module
ImportError: PyCapsule_Import could not import module "pyexpat"

(I have deleted pyexpat.so out of the build for the purposes of testing)

RuntimeError will continue to be raised in the case the version is wrong.

----------
keywords: +patch
nosy: +jerub
Added file: http://bugs.python.org/file26310/elementtree_importerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14988>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:06:03 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 21:06:03 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1341694823.28.0.574496504811.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341695085.3394.19.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Does it work for extension modules?

What do you mean?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:15:12 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 07 Jul 2012 21:15:12 +0000
Subject: [issue15228] os.utime() docs not clear on behavior on nonexistant
	files
In-Reply-To: <1341086123.85.0.135321380132.issue15228@psf.upfronthosting.co.za>
Message-ID: <1341695712.23.0.390588305846.issue15228@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15228>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:15:12 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 07 Jul 2012 21:15:12 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341695712.97.0.076889392944.issue15110@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I added to _ssl.c:

    PyErr_SetString(PyExc_ValueError, "Just a test");
    return NULL;

Then I tried to import the module:

~/python/cpython3.x$ ./python -c "import ssl"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/amauryfa/python/cpython3.x/Lib/ssl.py", line 60, in <module>
    import _ssl             # if we can't import it, let the error propagate
  File "<frozen importlib._bootstrap>", line 1300, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1267, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 432, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 347, in set_package_wrapper
  File "<frozen importlib._bootstrap>", line 360, in set_loader_wrapper
  File "<frozen importlib._bootstrap>", line 878, in load_module
ValueError: Just a test

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:17:04 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 07 Jul 2012 21:17:04 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341695824.81.0.443587308061.issue15110@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

See also msg164937

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:24:34 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 07 Jul 2012 21:24:34 +0000
Subject: [issue15194] libffi-3.0.11 update
In-Reply-To: <1340723218.62.0.173444932066.issue15194@psf.upfronthosting.co.za>
Message-ID: <1341696274.37.0.714662895229.issue15194@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

libffi_osx wasn't (yet) updated. so this seems to be unrelated to the 3.0.11 update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15194>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:33:20 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 07 Jul 2012 21:33:20 +0000
Subject: [issue5931] Python runtime name hardcoded in wsgiref.simple_server
In-Reply-To: <1241478665.1.0.327455115942.issue5931@psf.upfronthosting.co.za>
Message-ID: <1341696800.78.0.0702976544571.issue5931@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I have fixed this in the changeset 34e705fa4da4.

SERVER_SOFTWARE term can be made more specific to note the implementation as various suggestions say. I personally think, it is worthy to make change in 3.3 itself as its been open from a long time and it is strictly not a feature as such.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5931>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:41:07 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 07 Jul 2012 21:41:07 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341692918.3394.15.camel@localhost.localdomain>
Message-ID: <20120707234106.Horde.qHPaQklCcOxP_Kzyal5VhOA@webmail.df.eu>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> Using venv is not obvious in the first place.
>
> Well, why couldn't it *become* obvious.

Because the notion of a "virtual environment" is inherently
non-obvious. Is it like a virtual machine (and if so, like
VMWare or like Java, both with virtual machines - doesn't
Python have a virtual machine already)? Is it like a virtual
host in Apache? I asked people, and even after explaining what
it is, it was not clear to them what it is good for. You really
need to have the problem that it solves, or else you can't
comprehend what it does. Please trust me on that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:42:17 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Jul 2012 21:42:17 +0000
Subject: [issue15279] Spurious unittest warnings
In-Reply-To: <1341674545.77.0.716203051696.issue15279@psf.upfronthosting.co.za>
Message-ID: <1341697337.1.0.222854567127.issue15279@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

That's an odd failure.  I've not seen it nor can I reproduce it on 10.7 using the standard Apple Xcode 4.3.3 clang nor on 10.6 using the Apple Xcode 3.2.6 gcc-4.2.  You appear to be using a MacPorts-built gcc-4.2.  Can you try with an Apple-supplied compiler (./configure will now use clang by default for 10.7, avoid the use of Apple's llvm-gcc)?  Anything else in your environment that might be non-standard?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15279>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:55:02 2012
From: report at bugs.python.org (Stephen Thorne)
Date: Sat, 07 Jul 2012 21:55:02 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <1341698102.96.0.608685379927.issue14826@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

Here is a patch that uses the same quoting logic in urllib.request.Request.__init__ as is used by urllib.request.URLopener.open()

----------
keywords: +patch
nosy: +jerub
versions: +Python 3.3 -Python 2.7
Added file: http://bugs.python.org/file26311/urllib-quote-14826.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:56:40 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 21:56:40 +0000
Subject: [issue15285] test_timeout failure on OSX
In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>
Message-ID: <1341698200.83.0.433397398094.issue15285@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

happened on 10.6, 64 bits, with a fresh build.

== CPython 3.3.0b1 (default:5b71f5891c54, Jul 7 2012, 17:47:30) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
==   Darwin-10.8.0-i386-64bit little-endian

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Sun Jul  8 00:02:27 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 22:02:27 +0000
Subject: [issue15285] test_timeout failure on OSX
In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>
Message-ID: <1341698547.18.0.858219328763.issue15285@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

probably a temporary network issue: i cannot reproduce it now.

----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Sun Jul  8 00:06:40 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 22:06:40 +0000
Subject: [issue15285] test_timeout failure on OSX
In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>
Message-ID: <1341698800.73.0.00496691720624.issue15285@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This was this test which was failing:


    def testConnectTimeout(self):
        # Choose a private address that is unlikely to exist to prevent
        # failures due to the connect succeeding before the timeout.
        # Use a dotted IP address to avoid including the DNS lookup time
        # with the connect time.  This avoids failing the assertion that
        # the timeout occurred fast enough.
        addr = ('10.0.0.0', 12345)
        with support.transient_internet(addr[0]):
            self._sock_operation(1, 0.001, 'connect', addr)


I suspect a conflicting configuration of the EuroPython network ;)
Let's close it.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Sat Jul  7 23:58:21 2012
From: report at bugs.python.org (Phillip J. Eby)
Date: Sat, 07 Jul 2012 21:58:21 +0000
Subject: [issue5931] Python runtime name hardcoded in wsgiref.simple_server
In-Reply-To: <1341686230.7.0.146912296163.issue5931@psf.upfronthosting.co.za>
Message-ID: <CALeMXf6AZXRABf+4BgP=Miwbgwj0eN1hOCg-zXB+t+E7nPnypQ@mail.gmail.com>


Phillip J. Eby <pje at telecommunity.com> added the comment:

On Sat, Jul 7, 2012 at 2:37 PM, Terry J. Reedy wrote:

> Phillip, this is a trivial wsgiref patch. Do you have any opinion?
>

Nope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5931>
_______________________________________

From report at bugs.python.org  Sun Jul  8 00:18:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 22:18:02 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341699482.45.0.365834578317.issue15110@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, right, here is an updated patch which also handles extension modules and frozen ones.

----------
Added file: http://bugs.python.org/file26312/trim_tb2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sun Jul  8 00:28:58 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 07 Jul 2012 22:28:58 +0000
Subject: [issue13797] Allow objects implemented in pure Python to export PEP
	3118 buffers
In-Reply-To: <1326709751.32.0.965094376059.issue13797@psf.upfronthosting.co.za>
Message-ID: <1341700138.19.0.904297735432.issue13797@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/issue13797>
_______________________________________

From report at bugs.python.org  Sun Jul  8 00:55:04 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 22:55:04 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1341675436.12.0.347301047367.issue14814@psf.upfronthosting.co.za>
Message-ID: <CADiSq7deBf8j-u-f2QyH0bayG40zogDFn3UWYgVVR8x1WKsGoQ@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yup, it's broken (doesn't handle NotImplemented correctly) and Raymond
isn't keen on fixing it. I should add a link to the relevant tracker issue
in a comment, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Sun Jul  8 01:17:51 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 07 Jul 2012 23:17:51 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341676517.75.0.848646137047.issue15283@psf.upfronthosting.co.za>
Message-ID: <1341703071.32.0.509539447011.issue15283@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> It does one single thing and it has only a handful of options
> (one of which is a no-op :-)).

Perhaps it's a no-op only on your preferred operating system - that doesn't mean it's a no-op for everyone :-)

I don't mind clarifying/expanding the help output, but I also feel there's no need to print anything by default when a venv is created.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sun Jul  8 01:20:44 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Jul 2012 23:20:44 +0000
Subject: [issue15285] test_timeout failure when system on IPv4 10.0.x.x subnet
In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>
Message-ID: <1341703244.28.0.749547017485.issue15285@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Actually this is a real test case error.  The problem is observed when the system under test is connected to subnet "10.0.x.x".  The requested address (10.0.0.0) is then a broadcast address for the subnet.  On OS X and (I believe) BSD networking systems, the connect system call checks for this (see man 3 connect) and is documented to fail with:

   [EACCES]  The destination address is a broadcast address and the
             socket option SO_BROADCAST is not set.

When running on a testing Debian Linux 3.2.0 kernel in a VM, the same connect fails with: Errno 113] No route to host, which results in the test being skipped with:
Resource '10.0.0.0' is not available

The test could be changed to pick a (hopefully unused) non-broadcast address or support.transient_internet could add EACCES to its default_errnos, possibly just for BSD/OSX platforms.

----------
assignee: ronaldoussoren -> 
components: +Tests -Macintosh
nosy: +pitrou -ronaldoussoren
resolution: works for me -> 
stage:  -> needs patch
status: closed -> open
title: test_timeout failure on OSX -> test_timeout failure when system on IPv4 10.0.x.x subnet
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Sun Jul  8 01:32:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 23:32:44 +0000
Subject: [issue15290] setAttribute() can fail
Message-ID: <1341703964.25.0.272780923096.issue15290@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is a regression from 3.2:

Traceback (most recent call last):
  File "/home/antoine/3sted/twisted/lore/test/test_lore.py", line 542, in test_setTitle
    secondTitle.setAttribute('class', 'title')
  File "/home/antoine/opt/lib/python3.3/xml/dom/minidom.py", line 743, in setAttribute
    attr.ownerDocument = self.ownerDocument
builtins.AttributeError: ownerDocument

----------
components: Library (Lib)
messages: 164954
nosy: loewis, pitrou
priority: high
severity: normal
status: open
title: setAttribute() can fail
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15290>
_______________________________________

From report at bugs.python.org  Sun Jul  8 01:33:57 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 07 Jul 2012 23:33:57 +0000
Subject: [issue5931] Python runtime name hardcoded in wsgiref.simple_server
In-Reply-To: <1241478665.1.0.327455115942.issue5931@psf.upfronthosting.co.za>
Message-ID: <1341704037.01.0.313865980795.issue5931@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5931>
_______________________________________

From report at bugs.python.org  Sun Jul  8 02:15:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 00:15:08 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <3WV9D71zZ8zNdL@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 01c8d800efd2 by Senthil Kumaran in branch '3.2':
Fix issue14826 - make urllib.request.Request quoted url consistent with URLOpener open method.
http://hg.python.org/cpython/rev/01c8d800efd2

New changeset e6bb919b2623 by Senthil Kumaran in branch 'default':
Fix issue14826 - make urllib.request.Request quoted url consistent with URLOpener open method.
http://hg.python.org/cpython/rev/e6bb919b2623

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 02:24:13 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 08 Jul 2012 00:24:13 +0000
Subject: [issue14791] setup.py only adds /prefix/lib, not /prefix/lib64
In-Reply-To: <1336840843.09.0.565460268003.issue14791@psf.upfronthosting.co.za>
Message-ID: <1341707053.59.0.665137787059.issue14791@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

using sys.maxsize isn't safe for cross builds. it should at least guarded by 'if not cross_compiling'.

I still think that the preferred way to get the library dirs is to ask the compiler (patch attached), however this will add "incompatible" library dirs as well, at least for multilib'd gcc builds, and leading to linker warnings when building the extensions. At least when using gcc this should address the issue finding the lib32 and libx32 dirs.

----------
Added file: http://bugs.python.org/file26313/setup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14791>
_______________________________________

From report at bugs.python.org  Sun Jul  8 02:37:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 00:37:14 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <3WV9jj0mvlzNfP@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d931a3b64fd6 by Senthil Kumaran in branch '2.7':
Fix issue14826 - make urllib.request.Request quoted url consistent with URLOpener open method.
http://hg.python.org/cpython/rev/d931a3b64fd6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 02:38:10 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 08 Jul 2012 00:38:10 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <1341707890.8.0.781735792363.issue14826@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 02:38:38 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 08 Jul 2012 00:38:38 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <1341707918.87.0.117764429695.issue14826@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for the patch, Stephen.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 03:44:19 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Jul 2012 01:44:19 +0000
Subject: [issue15288] Clarify the pkgutil.walk_packages() note
In-Reply-To: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>
Message-ID: <1341711859.62.0.614879638362.issue15288@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Probably linking the term "importers" into the glossary should be enough.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15288>
_______________________________________

From report at bugs.python.org  Sun Jul  8 03:44:53 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Jul 2012 01:44:53 +0000
Subject: [issue15256] Typo in error message
In-Reply-To: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>
Message-ID: <1341711893.78.0.44246688965.issue15256@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Patch looks fine. Next time I have python-dev time I will commit it.

----------
assignee:  -> brett.cannon
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15256>
_______________________________________

From report at bugs.python.org  Sun Jul  8 03:48:53 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Jul 2012 01:48:53 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341712133.42.0.0226393773114.issue15110@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Looks good to me. Go ahead and commit it.

----------
assignee: brett.cannon -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sun Jul  8 03:48:59 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Jul 2012 01:48:59 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341712139.47.0.390180260556.issue15110@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sun Jul  8 04:54:52 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 08 Jul 2012 02:54:52 +0000
Subject: [issue15275] isinstance is called a more times that needed in ntpath
In-Reply-To: <1341668298.8.0.671820953585.issue15275@psf.upfronthosting.co.za>
Message-ID: <1341716092.7.0.331135971179.issue15275@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/issue15275>
_______________________________________

From report at bugs.python.org  Sun Jul  8 06:05:23 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Jul 2012 04:05:23 +0000
Subject: [issue15270] "Economy of Expression" section outdated
In-Reply-To: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za>
Message-ID: <1341720323.06.0.0757723017784.issue15270@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The point was that the docs shouldn't "write a book" where briefer explanations suffice.  The mention of super() may not be the best example because many "experts" still don't get what it is all about regardless of how much or how little much is written.

FWIW, the original two short paragraphs led to a good deal of confusion resulting in people declaring super() to be either inscrutable, unusable, or both.

----------
assignee: docs at python -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15270>
_______________________________________

From report at bugs.python.org  Sun Jul  8 06:16:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 08 Jul 2012 04:16:56 +0000
Subject: [issue14590] ConfigParser doesn't strip inline comment when delimiter
	occurs earlier without preceding space.
In-Reply-To: <1334541468.07.0.833607995836.issue14590@psf.upfronthosting.co.za>
Message-ID: <1341721016.89.0.199739556055.issue14590@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If this is a bugfix, can you backport it to stable branches?  If it?s a new, incompatible behavior change, then it was committed too late for 3.3 in theory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14590>
_______________________________________

From report at bugs.python.org  Sun Jul  8 06:30:34 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 08 Jul 2012 04:30:34 +0000
Subject: [issue15252] Delivery reports about your e-mail
In-Reply-To: <1341464098.25.0.322461682765.issueNone@psf.upfronthosting.co.za>
Message-ID: <1341721834.15.0.194746837639.issue15252@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file26259/transcript.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15252>
_______________________________________

From report at bugs.python.org  Sun Jul  8 06:30:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 08 Jul 2012 04:30:39 +0000
Subject: [issue15252] Delivery reports about your e-mail
In-Reply-To: <1341464098.25.0.322461682765.issueNone@psf.upfronthosting.co.za>
Message-ID: <1341721839.61.0.913746378055.issue15252@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file26260/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15252>
_______________________________________

From report at bugs.python.org  Sun Jul  8 06:37:53 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 08 Jul 2012 04:37:53 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1341722273.52.0.264239758231.issue9788@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Reopened as #15233.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Sun Jul  8 06:38:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 08 Jul 2012 04:38:23 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341722303.63.0.0942554660362.issue15233@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +benjamin.peterson, giampaolo.rodola, meador.inge, python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15233>
_______________________________________

From report at bugs.python.org  Sun Jul  8 06:44:30 2012
From: report at bugs.python.org (Ned Deily)
Date: Sun, 08 Jul 2012 04:44:30 +0000
Subject: [issue14791] setup.py only adds /prefix/lib, not /prefix/lib64
In-Reply-To: <1336840843.09.0.565460268003.issue14791@psf.upfronthosting.co.za>
Message-ID: <1341722670.11.0.1844491877.issue14791@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Also OS X universal builds have many of the characteristics of a cross-build.  In particular, one executable (like the python interpreter) can contain both 32-bit and 64-bit architecture files.  So tests for 32-bit vs 64-bit at build time using the running compiler's arch are problematic.  Another issue is the support for building with an OS X SDK.  Basically, all /usr include and lib file paths used for searching in setup.py need to be prefixed by the SDK path if configured.  There are some holes in this right now.  I plan to fix them soon; it would better to have this issue resolved and applied first.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14791>
_______________________________________

From report at bugs.python.org  Sun Jul  8 08:17:30 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 08 Jul 2012 06:17:30 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <1341728250.67.0.911709260757.issue14826@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

It looks like this broke the build bots:
http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%202.7/builds/66/steps/test/logs/stdio

----------
assignee:  -> orsenthil
nosy: +rosslagerwall
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 08:42:27 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Jul 2012 06:42:27 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1341729747.23.0.289902482076.issue7897@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As another in-the-standard-library uses case: my additions to the ipaddress test suite are really crying out for parameterised test support.

My current solution is adequate for coverage and debugging purposes (a custom assert applied to multiple values in a test case), but has the known limitations of that approach (specifically, only the first failing case gets reported rather than all failing cases, which can sometimes slow down the debugging process).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Sun Jul  8 08:50:41 2012
From: report at bugs.python.org (Nicu Stiurca)
Date: Sun, 08 Jul 2012 06:50:41 +0000
Subject: [issue15125] argparse: positional arguments containing - in name not
	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1341730241.26.0.983353173372.issue15125@psf.upfronthosting.co.za>


Nicu Stiurca <supernic2002 at gmail.com> added the comment:

Florent, there are several reasons I think this is a valid use case. First, for optional arguments, '-' gets automatically replaced with '_' as the destination. I don't see any reason why optional and positional arguments should be treated differently when deciding the destination. This inconveniences the programmer who could naturally be inclined to follow some hyphenated optional arguments

a.add_argument("--option-one")
a.add_argument("--option-two")
a.add_argument("--option-three")

with hyphenated positional argument

a.add_argument("positional-args")

The programmer shouldn't have to pause and think about different naming requirements for optional and positional arguments.

Second, persuading programmers to use underscores for positional args (eg, via proposed documentation patch) would have user-visible changes. Specifically, the automatically generated help/usage message would contain underscores instead of hyphens. Admittedly, this is fairly minor and inconsequential, but most programs use hyphens (not underscores) as delimiters in long options. I think it would be poor form to break user expectations in this regard.

Last, I was apparently wrong (as Florent points out) that positional arguments whose names are invalid identifiers are impossible to retrieve. That's good to know, but that solution strikes me as just an ugly workaround. :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15125>
_______________________________________

From report at bugs.python.org  Sun Jul  8 09:02:40 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Jul 2012 07:02:40 +0000
Subject: [issue10042] functools.total_ordering fails to handle NotImplemented
	correctly
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1341730960.71.0.751977062726.issue10042@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: total_ordering -> functools.total_ordering fails to handle NotImplemented correctly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Sun Jul  8 09:24:53 2012
From: report at bugs.python.org (Stephen Thorne)
Date: Sun, 08 Jul 2012 07:24:53 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <1341732293.1.0.299829652408.issue14826@psf.upfronthosting.co.za>


Stephen Thorne <stephen at thorne.id.au> added the comment:

Here's a followup patch that fixes the trunk build for me.

This will unbreak the builds as well as fixing this bug, but it should be investigated why URLopener calls to_bytes() and Request does not. Ideally this interface should be consistent.

----------
Added file: http://bugs.python.org/file26314/urllib-request.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 09:36:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 07:36:35 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WVM1Z1GW8zNg4@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 18c1d4d60bdf by Nick Coghlan in branch 'default':
Issue 14814: Further error case testing coverage and cleanups
http://hg.python.org/cpython/rev/18c1d4d60bdf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Sun Jul  8 10:01:47 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 08:01:47 +0000
Subject: [issue15284] Handle ipv6 not being enabled in test_socket
In-Reply-To: <1341676904.33.0.668096531532.issue15284@psf.upfronthosting.co.za>
Message-ID: <3WVMZd3794zNj8@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b71dc2e9e00d by Ross Lagerwall in branch 'default':
#15284: Skip {send,recv}msg tests with disabled IPv6
http://hg.python.org/cpython/rev/b71dc2e9e00d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15284>
_______________________________________

From report at bugs.python.org  Sun Jul  8 10:11:20 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 08 Jul 2012 08:11:20 +0000
Subject: [issue5931] Python runtime name hardcoded in wsgiref.simple_server
In-Reply-To: <1241478665.1.0.327455115942.issue5931@psf.upfronthosting.co.za>
Message-ID: <1341735080.92.0.0141427293279.issue5931@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You need to indent the block after the versionchanged directive.  Also, I believe only bug fixes should go into 3.3 now that we are in beta.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5931>
_______________________________________

From report at bugs.python.org  Sun Jul  8 10:13:00 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 08 Jul 2012 08:13:00 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1341732293.1.0.299829652408.issue14826@psf.upfronthosting.co.za>
Message-ID: <CAPOVWORycRLhqRUgFdWyLJHRsibHHT-6PO_n_D2bzBz1trXDfw@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

It seems to me that toBytes in urllib was introduce to restrict the
allowance of urls which were sent as unicode strings. We wanted urls
to be ascii strings in Python2.

http://mail.python.org/pipermail/python-bugs-list/2000-November/002779.html

And quoting to toBytes / to_bytes is actually the problem here, as
cookielib test cases is sending a unicode character which ascii
encoding fails to operate on. I am thinking that we should arrive at a
solution which brings consistency and fixes any previous mistakes.  In
3.3, I think, rework of to_bytes may also be a good solution, in 2.7
and 3.2, I think stephen's attached patch is in good lines.
Practically, the quote is more important than the failure at toBytes
by sending an unicode url.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 10:13:30 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 08 Jul 2012 08:13:30 +0000
Subject: [issue15285] test_timeout failure when system on IPv4 10.0.x.x subnet
In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>
Message-ID: <1341735210.85.0.799965574815.issue15285@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

actually, this is the mapping table I have, when it fails with [Errno 13] Permission denied:


$ ifconfig |grep inet
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	inet 127.0.0.1 netmask 0xff000000 
	inet 10.20.24.208 netmask 0xfffff000 broadcast 10.20.31.255

$ netstat -r
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            10.20.16.1         UGSc           44        0     en1
10.20.16/20        link#6             UCS            11        0     en1
10.20.16.1         0:c:42:7:1d:80     UHLWI          50      198     en1   1200
10.20.20.29        3c:d0:f8:79:2c:78  UHLWI           0        0     en1    903
10.20.20.77        e4:ce:8f:3c:8f:c8  UHLWI           0        0     en1    816
10.20.20.170       4:54:53:6d:cc:54   UHLWI           0        0     en1    946
10.20.24.3         0:26:bb:6:58:31    UHLWI           0        0     en1   1015
10.20.24.191       3c:d0:f8:a5:76:dc  UHLWI           0        0     en1   1021
10.20.24.208       localhost          UHS             0        0     lo0
10.20.25.89        0:26:8:73:e7:ab    UHLWI           0        0     en1   1190
10.20.25.159       18:3d:a2:10:5e:24  UHLWI           0        0     en1   1146
10.20.25.219       ac:72:89:2e:c9:17  UHLWI           0       78     en1   1142
10.20.29.78        0:1f:3b:3a:6c:8f   UHLWI           0        0     en1   1025
10.20.31.17        68:a8:6d:80:70:de  UHLWI           0        0     en1   1080
127                localhost          UCS             0        0     lo0
localhost          localhost          UH              3   106290     lo0
169.254            link#6             UCS             0        0     en1

Internet6:
Destination        Gateway            Flags         Netif Expire
localhost          localhost          UH              lo0
fe80::%lo0         localhost          Uc              lo0
localhost          link#1             UHL             lo0
fe80::%en0         link#4             UC              en0
ff01::             localhost          Um              lo0
ff02::             localhost          UmC             lo0
ff02::             link#4             UmC             en0
ff02::fb           link#4             UHmLW           en0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Sun Jul  8 10:14:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 08 Jul 2012 08:14:06 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <1341735246.11.0.754052555149.issue14826@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure urllib should accept invalid (non-escaped) URLs; a higher-level application can do so, but for the low-level stdlib module it is more debatable.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 10:18:06 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 08 Jul 2012 08:18:06 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1341735246.11.0.754052555149.issue14826@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOSKVB0o5cKPvKK8eWfsdD=yzDGv8R0ogb4JXdCO2o3UgQ@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Yeah, I am thinking so as well in that case, the test_cookielib.py
test case may need a change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 10:45:14 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 08 Jul 2012 08:45:14 +0000
Subject: [issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet
In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>
Message-ID: <1341737114.75.0.344524078651.issue15285@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Something like 127.42.42.42 might be more reliable, because it does not depend on the LAN configuration, only on the local loopback settings.
It is in 127.0.0.0/8 but not in 127.0.0.0/32.
Tested OK here.


127.0.0.0/8 - This block is assigned for use as the Internet host
   loopback address.  A datagram sent by a higher-level protocol to an
   address anywhere within this block loops back inside the host.  This
   is ordinarily implemented using only 127.0.0.1/32 for loopback.  As
   described in [RFC1122], Section 3.2.1.3, addresses within the entire
   127.0.0.0/8 block do not legitimately appear on any network anywhere.

http://tools.ietf.org/html/rfc5735#section-3

----------
title: test_timeout failure when system on IPv4 10.0.x.x subnet -> test_timeout failure when system on IPv4 10.x.x.x subnet

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Sun Jul  8 10:51:38 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Jul 2012 08:51:38 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1341737498.39.0.272015837565.issue14814@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

_get_prefix_length now used only in test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Sun Jul  8 11:05:26 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 08 Jul 2012 09:05:26 +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: <1341738326.13.0.128791190863.issue13248@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file26297/issue13248_io_max_buffer_size.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Sun Jul  8 11:16:33 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 08 Jul 2012 09:16:33 +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: <1341738993.79.0.0203054386487.issue13248@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The other changes are in the patch "issue13248_obsolescence_v3.diff".
AFAIU, they will not be removed in 3.3, in order to facilitate transition from Python 2.


*asyncore*
  shortcut "dispatcher.*" for "dispatcher.socket.*" attributes

*base64*
  functions "encodestring" and "decodestring"

*cgi*
  functions "parse_qs" and "parse_qsl"

*gzip*
  "GzipFile.filename"

*http.client*
  argument "strict" of HTTPResponse and HTTPConnection

*mailbox*
  argument of type "StringIO" or "text mode files"

*ntpath*
  function "splitunc"

*tarfile*
  argument "exclude" of "TarFile.add"

*trace*
  old API

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Sun Jul  8 11:22:19 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 09:22:19 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <3WVPMZ4bLyzNPx@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ee1828dc3bf6 by Senthil Kumaran in branch '3.2':
issue 14826 - Address the buildbot failure ( explanation msg164973)
http://hg.python.org/cpython/rev/ee1828dc3bf6

New changeset dc30111a5d7e by Senthil Kumaran in branch 'default':
issue 14826 - Address the buildbot failure quote of url is the required change ( explanation msg164973)
http://hg.python.org/cpython/rev/dc30111a5d7e

New changeset 224b27a8d9be by Senthil Kumaran in branch '2.7':
revert the changes done in d931a3b64fd6  - buildbot failure.
http://hg.python.org/cpython/rev/224b27a8d9be

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 11:25:16 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 08 Jul 2012 09:25:16 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <3WVPMZ4bLyzNPx@mail.python.org>
Message-ID: <CAPOVWORAfUG-SEAYQdqBKG0_vwtih8uNwv0eNOwtps-AS3h5qg@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The last change should settle the buildbots, But I would like to come
back to this issue again tomorrow with focus - 3.3    to see if we can
deal with removing to_bytes and then in 2.7 to see if something can
done to test_cookielib.py test case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 11:30:32 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 09:30:32 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <1341739832.34.0.366414803172.issue14826@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Senthil, do you read python-dev? I think this change was prematurate from the start (nevermind the fact that you didn't run the test suite before committing).

For example, if you have an URL with a non-ASCII domain name such as "http://?????-?????????.???/", the domain name should IDNA-encoded, not %-encoded like the rest.

Furthermore, some people are certainly already quoting their URLs to workaround this issue, so "fixing" it will break their code by double-escaping the URLs. You've got to be more careful.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 11:35:25 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 08 Jul 2012 09:35:25 +0000
Subject: [issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet
In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>
Message-ID: <1341740125.89.0.0294918371162.issue15285@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

I don't think anything in 127/8 is going to work, all Debian/Ubuntu systems I'm aware of have all of 127/8 equivalent to 127.0.0.1.

Maybe 192.0.2.0/24 per RFC 5737?

A better solution might be to chose some host/port on a python.org server and set it to DROP tcp syn packets.

----------
nosy: +bbrazil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Sun Jul  8 11:44:33 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 08 Jul 2012 09:44:33 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1341740673.78.0.987927808538.issue13378@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Do we merge the patch for 3.3?
I'm +1 on this (patch submitted 8 months ago, backward compatible and reviewed).

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Sun Jul  8 11:58:57 2012
From: report at bugs.python.org (Manuel de la Pena)
Date: Sun, 08 Jul 2012 09:58:57 +0000
Subject: [issue15286] normpath does not work with local literal paths
In-Reply-To: <1341679642.43.0.277228630346.issue15286@psf.upfronthosting.co.za>
Message-ID: <1341741537.6.0.462204428683.issue15286@psf.upfronthosting.co.za>


Manuel de la Pena <manuel at canonical.com> added the comment:

Antoine,

What the MSDN is stating is that the Windows functions from COM will not normalize the path if it is prefixed by \\?\. That is, if a user wanted to do:

path = r'\\?\C:\Users\mandel\..\Desktop\test'
with open(path, 'w') as fd:
    fd.write('hello!')

he will get the following:

[Errorno 22] Invalid argument. r'\\?\C:\Users\mandel\..\Desktop\test'

The same think would happen if a C function is used, that is, open is doing the right thing. On the other hand, the same code without the \\?\ works.

This makes it even more important to allow the normpath users to normalize such paths, that is, a developer knows that the path has more than 260 chars and wants to make sure that the path can be written in the system:

May I ask you why you mention the symbolic links? I know that if one of the segments of the path is a symbolic link there are problems but this is not related to \\?\ or am I confused? Just curious :)

Brian,

The ntpath module is a little mess (look at my other patch http://bugs.python.org/issue15275) and I think there are more performance problems hidden there somewhere...

I imported string within the function because the same is done in expandvars (around line 430) and wanted to follow the style that was already in use in the file. I do agree that imports at the top are the way to go :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15286>
_______________________________________

From report at bugs.python.org  Sun Jul  8 11:59:58 2012
From: report at bugs.python.org (Manuel de la Pena)
Date: Sun, 08 Jul 2012 09:59:58 +0000
Subject: [issue15275] isinstance is called a more times that needed in ntpath
In-Reply-To: <1341668298.8.0.671820953585.issue15275@psf.upfronthosting.co.za>
Message-ID: <1341741598.78.0.964776607696.issue15275@psf.upfronthosting.co.za>


Changes by Manuel de la Pena <manuel at canonical.com>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15275>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:02:21 2012
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 08 Jul 2012 10:02:21 +0000
Subject: [issue15276] unicode format does not really work in Python 2.x
In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za>
Message-ID: <1341741741.79.0.435981599302.issue15276@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I can't reproduce this with Python 2.7.3.

berker at wakefield ~[master*]$ python
Python 2.7.3 (default, Apr 20 2012, 22:39:59) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_NUMERIC, 'fr_FR')
'fr_FR'
>>> u'{:n}'.format(10000)
u'10 000'

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15276>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:02:54 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 10:02:54 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <3WVQGN60H6zNtV@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8c877ad00bc4 by Antoine Pitrou in branch 'default':
Issue #15110: Fix the tracebacks generated by "import xxx" to not show the importlib stack frames.
http://hg.python.org/cpython/rev/8c877ad00bc4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:08:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 10:08:58 +0000
Subject: [issue15287] support.TESTFN was modified by test_builtin
In-Reply-To: <1341680737.17.0.537689488226.issue15287@psf.upfronthosting.co.za>
Message-ID: <3WVQPP229YzNJV@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6651c932d014 by Florent Xicluna in branch 'default':
Issue #11022 and #15287: correctly remove the TESTFN file in test_builtin.
http://hg.python.org/cpython/rev/6651c932d014

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15287>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:08:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 10:08:59 +0000
Subject: [issue11022] locale.getpreferredencoding() must not set temporary
	LC_CTYPE
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <3WVQPQ0PvrzNJV@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6651c932d014 by Florent Xicluna in branch 'default':
Issue #11022 and #15287: correctly remove the TESTFN file in test_builtin.
http://hg.python.org/cpython/rev/6651c932d014

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:10:05 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 08 Jul 2012 10:10:05 +0000
Subject: [issue15287] support.TESTFN was modified by test_builtin
In-Reply-To: <1341680737.17.0.537689488226.issue15287@psf.upfronthosting.co.za>
Message-ID: <1341742205.21.0.137295575208.issue15287@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
assignee: ronaldoussoren -> 
components:  -Macintosh
nosy:  -ronaldoussoren
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15287>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:11:19 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 10:11:19 +0000
Subject: [issue15286] normpath does not work with local literal paths
In-Reply-To: <1341741537.6.0.462204428683.issue15286@psf.upfronthosting.co.za>
Message-ID: <1341742198.3358.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> May I ask you why you mention the symbolic links? I know that if one
> of the segments of the path is a symbolic link there are problems but
> this is not related to \\?\ or am I confused? Just curious :)

No, it is not related with "\\?\" but I'm pointing out that normpath()
isn't very useful because of that. And Windows has symlink support
nowadays :-)

For the record, I'm trying to build a saner path-handling library at
http://pypi.python.org/pypi/pathlib/ . I hope to propose it for
inclusion in 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15286>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:15:40 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 08 Jul 2012 10:15:40 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1341742540.42.0.270450826372.issue13378@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Can this be honestly classified as a bugfix though? If it's a feature it will have to be postponed to 3.4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:18:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 10:18:05 +0000
Subject: [issue15291] test_ast leaks memory a lot
Message-ID: <1341742685.49.0.71637329292.issue15291@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

On the default branch, if you run test_ast in a loop:

./python -E -m test -F test_ast

you will see that the process memory use grows very quickly. This doesn't happen on 3.2.
I'm not a Valgrind expert so perhaps someone else can take a look. Otherwise I'll try to bisect.

----------
components: Interpreter Core
messages: 164992
nosy: neologix, pitrou, skrah
priority: critical
severity: normal
status: open
title: test_ast leaks memory a lot
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15291>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:24:06 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 08 Jul 2012 10:24:06 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1341743046.78.0.430426870467.issue13378@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Looks like a new feature to me.

----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:26:43 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 10:26:43 +0000
Subject: [issue15291] test_ast leaks memory a lot
In-Reply-To: <1341742685.49.0.71637329292.issue15291@psf.upfronthosting.co.za>
Message-ID: <1341743203.6.0.431708112416.issue15291@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So, the culprit is:

changeset:   75542:3877bf2e3235
user:        Benjamin Peterson <benjamin at python.org>
date:        Mon Mar 12 09:46:44 2012 -0700
summary:     give the AST class a __dict__

----------
nosy: +benjamin.peterson, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15291>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:27:08 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 10:27:08 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341743228.61.0.743220497427.issue15110@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks, Brett!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:27:49 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 08 Jul 2012 10:27:49 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1341743269.65.0.656313783527.issue13378@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Well, it fixes the behavior of ElementTree in some multi-threaded cases, provided you pass the namespace map as an argument of the serializer call.

The fix implements an optional argument for this use case.
As a side effect, it makes it easier to work with custom namespaces.

If the consensus is to wait for next version, I'm fine with that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:36:06 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 10:36:06 +0000
Subject: [issue15291] test_ast leaks memory a lot
In-Reply-To: <1341742685.49.0.71637329292.issue15291@psf.upfronthosting.co.za>
Message-ID: <1341743766.25.0.205202922983.issue15291@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Strangely, the reference leak was fixed in:

changeset:   75686:9e7f6ddc0d76
user:        Benjamin Peterson <benjamin at python.org>
date:        Wed Mar 14 21:50:29 2012 -0500
summary:     free AST's dict

But it didn't fix the memory leak.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15291>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:38:20 2012
From: report at bugs.python.org (Anders Hammarquist)
Date: Sun, 08 Jul 2012 10:38:20 +0000
Subject: [issue15292] import hook behavior documentation improvement
Message-ID: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>


New submission from Anders Hammarquist <iko at iko.pp.se>:

When testing Eutaxia on PyPy (1.9) I discovered a discrepancy in the path_hooks import hook implementation. In CPython (2.7), if the find_module() method raises ImportError (as imp.find_module() does when it does not find a module in the given path), will cause the search to continue, whereas PyPy would propagate the ImportError.

PyPy has now been changed to behave like CPython.

The documentation is not entirely clear, but it does not explicitly document the import hook mechanism as eating an ImportError in find_module(). It should probably be made explicit, which ever way it should be. It is not obvious what is the correct behaviour, given the implicit relative imports, where the ImportError simply means that the import hook cannot find the module.

Quick testing on CPython 3.3 indicates that it behaves like PyPy did, but as it doesn't do implicit relative imports my test case didn't work as it was. For 3.3, without implicit relative imports, propagating the ImportError feels like the correct behaviour.

The attached demonstration needs a file /tmp/test/foo.py that does a top-level import, e.g. "import errno" to demonstrate the discrepancy.

----------
assignee: docs at python
components: Documentation
files: testimport.py
messages: 164998
nosy: docs at python, iko
priority: normal
severity: normal
status: open
title: import hook behavior documentation improvement
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26315/testimport.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15292>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:43:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 10:43:13 +0000
Subject: [issue15292] import hook behavior documentation improvement
In-Reply-To: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>
Message-ID: <1341744193.06.0.192651969669.issue15292@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brett.cannon, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15292>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:45:24 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 10:45:24 +0000
Subject: [issue15291] test_ast leaks memory a lot
In-Reply-To: <1341742685.49.0.71637329292.issue15291@psf.upfronthosting.co.za>
Message-ID: <3WVRCR4MkTzNhK@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 048d8d9aecf1 by Antoine Pitrou in branch 'default':
Issue #15291: Fix a memory leak where AST nodes where not properly deallocated.
http://hg.python.org/cpython/rev/048d8d9aecf1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15291>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:45:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 10:45:48 +0000
Subject: [issue15291] test_ast leaks memory a lot
In-Reply-To: <1341742685.49.0.71637329292.issue15291@psf.upfronthosting.co.za>
Message-ID: <1341744348.95.0.599965124115.issue15291@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, that was easy :)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15291>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:47:34 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 10:47:34 +0000
Subject: [issue15293] AST nodes do not support garbage collection
Message-ID: <1341744454.01.0.740763019773.issue15293@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Add the following to test_ast:

diff --git a/Lib/test/test_ast.py b/Lib/test/test_ast.py
--- a/Lib/test/test_ast.py
+++ b/Lib/test/test_ast.py
@@ -199,6 +199,7 @@ class AST_Tests(unittest.TestCase):
         x.foobar = 42
         self.assertEqual(x.foobar, 42)
         self.assertEqual(x.__dict__["foobar"], 42)
+        x.x = x
 
         with self.assertRaises(AttributeError):
             x.vararg


and you'll get a reference leak.

----------
assignee: benjamin.peterson
components: Interpreter Core
messages: 165001
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: AST nodes do not support garbage collection
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15293>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:56:28 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 08 Jul 2012 10:56:28 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1341743269.65.0.656313783527.issue13378@psf.upfronthosting.co.za>
Message-ID: <4FF9675B.4040008@users.sourceforge.net>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Florent, what you describe is exactly the definition of a new feature.
Users even have to change their code in order to make use of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Sun Jul  8 12:58:09 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 08 Jul 2012 10:58:09 +0000
Subject: [issue15284] Handle ipv6 not being enabled in test_socket
In-Reply-To: <1341676904.33.0.668096531532.issue15284@psf.upfronthosting.co.za>
Message-ID: <1341745089.35.0.0753976347176.issue15284@psf.upfronthosting.co.za>


Changes by Brian Brazil <brian.brazil at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15284>
_______________________________________

From report at bugs.python.org  Sun Jul  8 13:23:39 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Jul 2012 11:23:39 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
In-Reply-To: <1341685249.94.0.991030946369.issue1767933@psf.upfronthosting.co.za>
Message-ID: <1341746651.2458.58.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Here is a patch with using context management (as Eli advised). This
makes error handling much safer and probably makes the code a little
easier. Several new tests are added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Sun Jul  8 13:33:22 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Jul 2012 11:33:22 +0000
Subject: [issue15292] import hook behavior documentation improvement
In-Reply-To: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>
Message-ID: <1341747202.2.0.101298880199.issue15292@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The PyPy and 3.3 behaviour are actually correct according to the spec, but it's *really* unclear in PEP 302.

sys.meta_path accepts finder objects. These are explicitly documented as returning "None" from find_module() to indicate "try the next one" and raising exceptions solely to report problems.

However, for reasons that are unknown to me, sys.path_hooks entries (which occupy most of the section on registering hooks) use a different protocol to indicate "try the next one": raising ImportError.

Since meta_path and path_hooks are described in the same section, and the meta_path description just says "add finder objects", it's understandable that implementors take the path_hooks protocol description as applying to finders in general :(

I would chalk the 2.x (and likely 3.x for x < 3) behaviour up to the only partial implementation of PEP 302 in CPython (until Brett's success in bootstrapping importlib for 3.3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15292>
_______________________________________

From report at bugs.python.org  Sun Jul  8 13:38:24 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 11:38:24 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WVSNZ6Hl6zNcR@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 45265ecaa3e4 by Nick Coghlan in branch 'default':
Issue 14814: Remove dead function (noticed by Serhiy Storchaka)
http://hg.python.org/cpython/rev/45265ecaa3e4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Sun Jul  8 13:44:30 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Jul 2012 11:44:30 +0000
Subject: [issue15276] unicode format does not really work in Python 2.x
In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za>
Message-ID: <1341747870.07.0.398892730114.issue15276@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

I confirm the bug on 2.7.

$ ./python 
Python 2.7.3+ (2.7:ab9d6c4907e7+, Apr 25 2012, 20:02:36) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_NUMERIC, 'uk_UA.UTF-8')
'uk_UA.UTF-8'
>>> u'{:n}'.format(10000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 2: ordinal not in range(128)
>>> '{:n}'.format(10000)
'10\xc2\xa0000'

----------
components: +Interpreter Core, Unicode
nosy: +ezio.melotti, storchaka
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15276>
_______________________________________

From report at bugs.python.org  Sun Jul  8 13:52:41 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Jul 2012 11:52:41 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1341748361.95.0.380832160139.issue1767933@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26316/etree_write_utf16_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Sun Jul  8 13:57:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 11:57:44 +0000
Subject: [issue15290] setAttribute() can fail
In-Reply-To: <1341703964.25.0.272780923096.issue15290@psf.upfronthosting.co.za>
Message-ID: <1341748664.01.0.0305202221868.issue15290@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Trivial reproducer:

>>> e = minidom.Element("span")
>>> e.setAttribute("class", "version")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/default/Lib/xml/dom/minidom.py", line 743, in setAttribute
    attr.ownerDocument = self.ownerDocument
AttributeError: ownerDocument

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15290>
_______________________________________

From report at bugs.python.org  Sun Jul  8 14:09:08 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 12:09:08 +0000
Subject: [issue15290] setAttribute() can fail
In-Reply-To: <1341703964.25.0.272780923096.issue15290@psf.upfronthosting.co.za>
Message-ID: <1341749348.56.0.367456755478.issue15290@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file26317/minidom_setattribute.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15290>
_______________________________________

From report at bugs.python.org  Sun Jul  8 14:29:12 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 08 Jul 2012 12:29:12 +0000
Subject: [issue15290] setAttribute() can fail
In-Reply-To: <1341703964.25.0.272780923096.issue15290@psf.upfronthosting.co.za>
Message-ID: <1341750552.34.0.24550352932.issue15290@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That's invalid usage. You are supposed to create new element nodes through the document's createElement method. "unattached" nodes are not supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15290>
_______________________________________

From report at bugs.python.org  Sun Jul  8 14:31:01 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 12:31:01 +0000
Subject: [issue15290] setAttribute() can fail
In-Reply-To: <1341750552.34.0.24550352932.issue15290@psf.upfronthosting.co.za>
Message-ID: <1341750580.3358.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That's invalid usage. You are supposed to create new element nodes
> through the document's createElement method. "unattached" nodes are
> not supported.

Well, I don't know how many third-party application rely on this, but
Twisted does it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15290>
_______________________________________

From report at bugs.python.org  Sun Jul  8 14:58:32 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 08 Jul 2012 12:58:32 +0000
Subject: [issue15290] setAttribute() can fail
In-Reply-To: <1341703964.25.0.272780923096.issue15290@psf.upfronthosting.co.za>
Message-ID: <1341752312.95.0.260457555005.issue15290@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Then Twisted will have to change. From

http://docs.python.org/library/xml.dom.minidom.html

"Applications should not instantiate the classes themselves; they should use the creator functions available on the Document object."

If they insist on not using createElement, they use internal API, and need to adjust that to new Python versions.

Closing as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15290>
_______________________________________

From report at bugs.python.org  Sun Jul  8 15:07:16 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 08 Jul 2012 13:07:16 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341752836.66.0.543191806418.issue15110@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I really like the "_exec_module" trick, but it should be applied to builtin modules as well. I hacked _sre.c and got:

~/python/cpython3.x$ ./python 
Traceback (most recent call last):
  File "/home/amauryfa/python/cpython3.x/Lib/site.py", line 70, in <module>
    import re
  File "/home/amauryfa/python/cpython3.x/Lib/re.py", line 122, in <module>
    import sre_compile
  File "/home/amauryfa/python/cpython3.x/Lib/sre_compile.py", line 13, in <module>
    import _sre, sys
  File "<frozen importlib._bootstrap>", line 1318, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1285, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 347, in set_package_wrapper
  File "<frozen importlib._bootstrap>", line 360, in set_loader_wrapper
  File "<frozen importlib._bootstrap>", line 443, in _requires_builtin_wrapper
  File "<frozen importlib._bootstrap>", line 493, in load_module
ValueError: Just a test


This change correctly hides importlib frames:


diff -r 9afdd8c25bf2 Lib/importlib/_bootstrap.py
--- a/Lib/importlib/_bootstrap.py	Sun Jul 08 14:00:06 2012 +0200
+++ b/Lib/importlib/_bootstrap.py	Sun Jul 08 15:03:27 2012 +0200
@@ -490,12 +490,15 @@
         """Load a built-in module."""
         is_reload = fullname in sys.modules
         try:
-            return _imp.init_builtin(fullname)
+            return self._exec_module(fullname)
         except:
             if not is_reload and fullname in sys.modules:
                 del sys.modules[fullname]
             raise
 
+    def _exec_module(self, fullname):
+        return _imp.init_builtin(fullname)
+
     @classmethod
     @_requires_builtin
     def get_code(cls, fullname):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sun Jul  8 15:14:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 13:14:16 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WVVWB456YzNt6@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7aa75ea4116d by Nick Coghlan in branch 'default':
Issue 14814: The new systematic tests aren't just about error reporting any more - change names accordingly. Added and tweaked some example to ensure they were covering the intended code paths
http://hg.python.org/cpython/rev/7aa75ea4116d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Sun Jul  8 15:16:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 13:16:05 +0000
Subject: [issue15294] regression with nested namespace packages
Message-ID: <1341753365.82.0.907088897601.issue15294@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Legacy namespace packages (handled with pkgutil) do not work anymore when they are nested. The attached test file passes under 3.2 but fails under 3.3.

----------
components: Interpreter Core
files: test_nested_nspackage.py
messages: 165014
nosy: brett.cannon, eric.snow, ncoghlan, pitrou
priority: high
severity: normal
status: open
title: regression with nested namespace packages
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26318/test_nested_nspackage.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15294>
_______________________________________

From report at bugs.python.org  Sun Jul  8 15:40:59 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Jul 2012 13:40:59 +0000
Subject: [issue15292] import hook behavior documentation improvement
In-Reply-To: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>
Message-ID: <1341754859.24.0.400322303359.issue15292@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Everything Nick said is right: PyPy did it properly according to the spec and CPython 2.7 got it wrong. Unfortunately fixing this now would break code and so it will simply have to stay a Python 2.7 quirk with Python 3.3 and later doing it correctly.

So documenting the screw-up would be good so that people know that the solution they use in Python 2.7 won't work in Python 3.3 and later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15292>
_______________________________________

From report at bugs.python.org  Sun Jul  8 15:42:07 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Jul 2012 13:42:07 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341754927.72.0.826679284689.issue15110@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Re-opening so Antoine can look at Amaury's proposed fix for builtin modules.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sun Jul  8 15:44:43 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Jul 2012 13:44:43 +0000
Subject: [issue15295] Document PEP 420 namespace packages
Message-ID: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

I believe Barry said he was going to handle the documentation for PEP 420.

----------
assignee: barry
components: Documentation
messages: 165017
nosy: barry, brett.cannon
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Document PEP 420 namespace packages
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sun Jul  8 15:48:29 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Jul 2012 13:48:29 +0000
Subject: [issue15295] Document PEP 420 namespace packages
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1341755309.45.0.0237442783269.issue15295@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

One request I would like to make is that while the docs are being written, to please look at importlib.find_loader() and let me know if the name no longer applies (it's new in Python 3.3 so it can easily be renamed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sun Jul  8 16:09:00 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Jul 2012 14:09:00 +0000
Subject: [issue15292] import hook behavior documentation improvement
In-Reply-To: <1341754859.24.0.400322303359.issue15292@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fh1rfq8xSH4NsudwCvSc3aDea3G=uzPPr1EV-3K5_g6Q@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Perhaps the porting section in the 3.3 What's New?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15292>
_______________________________________

From report at bugs.python.org  Sun Jul  8 17:31:04 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Jul 2012 15:31:04 +0000
Subject: [issue15296] Minidom can't create ASCII representation
Message-ID: <1341761464.17.0.485570736364.issue15296@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Minidom can parse ASCII-encoded XML data, but can't create it.

>>> from xml.dom.minidom import parseString
>>> doc = parseString(b'<?xml version="1.0" encoding="us-ascii"?><foo>&#x20ac;</foo>')
>>> doc.toxml('us-ascii')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 47, in toxml
    return self.toprettyxml("", "", encoding)
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 56, in toprettyxml
    self.writexml(writer, "", indent, newl, encoding)
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 1798, in writexml
    node.writexml(writer, indent, addindent, newl)
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 868, in writexml
    self.childNodes[0].writexml(writer, '', '', '')
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 1090, in writexml
    _write_data(writer, "%s%s%s" % (indent, self.data, newl))
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 304, in _write_data
    writer.write(data)
  File "/home/serhiy/py/cpython/Lib/codecs.py", line 355, in write
    data, consumed = self.encode(object, self.errors)
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in position 0: ordinal not in range(128)

Same for other non-unicode encodings.

Suggested simple patch solves this issue.

----------
components: Library (Lib), Unicode, XML
files: minidom_toxml_encoding.patch
keywords: patch
messages: 165020
nosy: ezio.melotti, storchaka
priority: normal
severity: normal
status: open
title: Minidom can't create ASCII representation
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26319/minidom_toxml_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15296>
_______________________________________

From report at bugs.python.org  Sun Jul  8 17:31:10 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 15:31:10 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1341752836.66.0.543191806418.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341761389.3397.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I really like the "_exec_module" trick, but it should be applied to
> builtin modules as well. I hacked _sre.c and got:

I hadn't thought about this one. Can you apply your patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sun Jul  8 17:42:28 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 08 Jul 2012 15:42:28 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1341762148.48.0.620749432714.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Justin, I can compile and run the tests fine in my Solaris 11 virtual machine, both in 32 and 64 bits and both static and dynamic.

I am using GCC, and you are using Sun Studio.

http://buildbot.python.org/all/builders/x86%20Solaris%2011%20custom/builds/17/steps/compile/logs/stdio

I was wondering if you have Jabber/XMPP (mine: jcea at jabber.org) so we can talk about this in realtime, and do some "remote keyboard" test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sun Jul  8 18:42:19 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 Jul 2012 16:42:19 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <1341765739.74.0.0644608019897.issue14826@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The docs [1] state that `url should be a string containing a valid URL.` An URL with a space ' ' is not a valid URL as the space must be quoted as %20. The brackets may also cause problems as they are not valid xs:anyURI chars.

I vote for reverting the chances as they break the API. You could improve the docs and emphasize that URLs must be quoted correctly as the module doesn't implement browser magic.

[1] http://docs.python.org/py3k/library/urllib.request.html#urllib.request.Request

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Sun Jul  8 18:51:05 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 16:51:05 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341676517.75.0.848646137047.issue15283@psf.upfronthosting.co.za>
Message-ID: <3WVbKN4Pl3zNnj@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9c345b4bd97e by Vinay Sajip in branch 'default':
Closes #15281, #15283: Don't make venv scripts executable, but copy source mode instead, and provide better help for pyvenv.
http://hg.python.org/cpython/rev/9c345b4bd97e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sun Jul  8 18:51:05 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 16:51:05 +0000
Subject: [issue15281] pyvenv --symlinks option is a no-op?
In-Reply-To: <1341675510.24.0.416671411372.issue15281@psf.upfronthosting.co.za>
Message-ID: <3WVbKM60SGzM3h@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9c345b4bd97e by Vinay Sajip in branch 'default':
Closes #15281, #15283: Don't make venv scripts executable, but copy source mode instead, and provide better help for pyvenv.
http://hg.python.org/cpython/rev/9c345b4bd97e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15281>
_______________________________________

From report at bugs.python.org  Sun Jul  8 18:52:19 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 08 Jul 2012 16:52:19 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341676517.75.0.848646137047.issue15283@psf.upfronthosting.co.za>
Message-ID: <1341766339.9.0.50138564518.issue15283@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sun Jul  8 19:15:44 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Jul 2012 17:15:44 +0000
Subject: [issue15273] Remove unnecessarily random behavior from test_unparse.py
In-Reply-To: <1341664153.44.0.16452834514.issue15273@psf.upfronthosting.co.za>
Message-ID: <1341767744.16.0.0355137790159.issue15273@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I thought we had other tests that did this as well (pickle?).  If you need reproducibility you check the random seed and reuse it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15273>
_______________________________________

From report at bugs.python.org  Sun Jul  8 19:18:56 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 08 Jul 2012 17:18:56 +0000
Subject: [issue15294] regression with nested namespace packages
In-Reply-To: <1341753365.82.0.907088897601.issue15294@psf.upfronthosting.co.za>
Message-ID: <1341767936.06.0.488757771407.issue15294@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15294>
_______________________________________

From report at bugs.python.org  Sun Jul  8 19:24:15 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 08 Jul 2012 17:24:15 +0000
Subject: [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1341768255.01.0.860378041286.issue12081@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Matthias recently updated libffi to 3.0.11 (issue15194).  It would seem that we intend to keep a local copy of the libffi sources for now and that this issue can be closed.  Does anyone see a reason to keep this open?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12081>
_______________________________________

From report at bugs.python.org  Sun Jul  8 19:30:06 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 08 Jul 2012 17:30:06 +0000
Subject: [issue15262] Idle does not show traceback in other threads
In-Reply-To: <1341563293.08.0.285980110052.issue15262@psf.upfronthosting.co.za>
Message-ID: <1341768606.45.0.0883137613044.issue15262@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Unless this could have been just as easily fixed in IDLE as in the core (Roger?), no, don't hold your breath ;-).

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15262>
_______________________________________

From report at bugs.python.org  Sun Jul  8 19:39:49 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 08 Jul 2012 17:39:49 +0000
Subject: [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1341769189.1.0.372596144043.issue12081@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing as a duplicate. The original issue is resolved: we are not distributing an old copy of libffi anymore.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> libffi-3.0.11 update

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12081>
_______________________________________

From report at bugs.python.org  Sun Jul  8 20:03:53 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 18:03:53 +0000
Subject: [issue15293] AST nodes do not support garbage collection
In-Reply-To: <1341744454.01.0.740763019773.issue15293@psf.upfronthosting.co.za>
Message-ID: <3WVcxN5QS0zNnh@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 85cccc38d01c by Benjamin Peterson in branch 'default':
add gc support to the AST base type (closes #15293)
http://hg.python.org/cpython/rev/85cccc38d01c

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15293>
_______________________________________

From report at bugs.python.org  Sun Jul  8 20:40:53 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 08 Jul 2012 18:40:53 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341676517.75.0.848646137047.issue15283@psf.upfronthosting.co.za>
Message-ID: <1341772853.22.0.731130240972.issue15283@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Creating a venv is useless if you don't ever activate it, right.
This is a common misconception.  Shell activation is only about putting the venv?s bin directory on the beginning of the PATH.  It?s a purely optional convenience.  Using a virtualenv can be done fully with explicit paths like Martin mentioned.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sun Jul  8 20:59:30 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 18:59:30 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <3WVf9Y4mqBzNkm@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 37e68da59047 by Amaury Forgeot d'Arc in branch 'default':
Issue #15110: Also hide importlib frames when importing a builtin module fails.
http://hg.python.org/cpython/rev/37e68da59047

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sun Jul  8 21:03:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 19:03:12 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <3WVfFq1pdDzNlN@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5d43154d68a8 by Amaury Forgeot d'Arc in branch 'default':
Issue #15110: Copy same docstring as other '_exec_module' methods.
http://hg.python.org/cpython/rev/5d43154d68a8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sun Jul  8 21:03:33 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 08 Jul 2012 19:03:33 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1341774213.69.0.249786688292.issue15110@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sun Jul  8 22:36:21 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 20:36:21 +0000
Subject: [issue15296] Minidom can't create ASCII representation
In-Reply-To: <1341761464.17.0.485570736364.issue15296@psf.upfronthosting.co.za>
Message-ID: <1341779781.17.0.279272547466.issue15296@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eli.bendersky
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15296>
_______________________________________

From report at bugs.python.org  Sun Jul  8 22:52:15 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 08 Jul 2012 20:52:15 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341772853.22.0.731130240972.issue15283@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOQ9GUsm5nbsBPHyS4p-b=hrPuEazXo88ds54LyBfX29dw@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I think, the ``source bin/activate`` should be mentioned in the Docs
at least. It should not require that a person carries this knowledge
from somewhere else. At the moment, I do not see mention of it in the
docs either -

http://docs.python.org/dev/library/venv.html

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Sun Jul  8 23:13:00 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 08 Jul 2012 21:13:00 +0000
Subject: [issue15297] pkgutil.iter_importers() includes an ImpImporter
Message-ID: <1341781980.93.0.099189257301.issue15297@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I'm not sure if this should be fixed in the code or in the documentation, but the pkgutil.iter_importers() documentation says that pkgutil.iter_importers(name) should yield the "importers for sys.meta_path, sys.path, and Python?s ?classic? import machinery, in that order" when name does not include a ".":

http://docs.python.org/dev/library/pkgutil.html#pkgutil.iter_importers

However, the function appends a "non-classic" pkgutil.ImpImporter at the end of all that:

Python 3.3.0b1 (default:5d43154d68a8, Jul  8 2012, 13:54:45) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
>>> from pkgutil import iter_importers
>>> list(iter_importers())[-1]
<pkgutil.ImpImporter object at 0x1035fa840>

----------
components: Library (Lib)
messages: 165035
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: pkgutil.iter_importers() includes an ImpImporter
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15297>
_______________________________________

From report at bugs.python.org  Sun Jul  8 23:26:16 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 08 Jul 2012 21:26:16 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
Message-ID: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

_sysconfigdata is generated in srcdir, not builddir, so if you do two consecutive differently builds in different builddirs and using the same srcdir, then the _sysconfigdata of the second build wins. _sysconfigdata.py has to be built in the builddir, not the srcdir.

----------
components: Build
messages: 165036
nosy: doko
priority: release blocker
severity: normal
status: open
title: _sysconfigdata is generated in srcdir, not builddir
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15298>
_______________________________________

From report at bugs.python.org  Sun Jul  8 23:41:14 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 21:41:14 +0000
Subject: [issue15294] regression with nested namespace packages
In-Reply-To: <1341753365.82.0.907088897601.issue15294@psf.upfronthosting.co.za>
Message-ID: <1341783674.99.0.0520738783256.issue15294@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file26320/nestednspkg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15294>
_______________________________________

From report at bugs.python.org  Sun Jul  8 23:45:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 21:45:02 +0000
Subject: [issue15294] regression with nested namespace packages
In-Reply-To: <1341753365.82.0.907088897601.issue15294@psf.upfronthosting.co.za>
Message-ID: <1341783902.1.0.363264548583.issue15294@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file26321/nestednspkg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15294>
_______________________________________

From report at bugs.python.org  Sun Jul  8 23:45:08 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 21:45:08 +0000
Subject: [issue15294] regression with nested namespace packages
In-Reply-To: <1341753365.82.0.907088897601.issue15294@psf.upfronthosting.co.za>
Message-ID: <1341783908.89.0.276230573834.issue15294@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file26320/nestednspkg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15294>
_______________________________________

From report at bugs.python.org  Sun Jul  8 23:48:07 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 08 Jul 2012 21:48:07 +0000
Subject: [issue15299] ImpImporter(None).iter_modules() does not search sys.path
Message-ID: <1341784087.15.0.754005593473.issue15299@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The pkgutil.ImpImporter documentation says that if dirname is None, ImpImporter(dirname) should create a PEP 302 importer that searches the current sys.path, plus any modules that are frozen or built-in:

http://docs.python.org/dev/library/pkgutil.html#pkgutil.ImpImporter

However, the iter_modules() method of an ImpImporter instance doesn't search sys.path if dirname is None.  It returns a generator that always yields nothing.  For example--

Python 3.3.0b1 (default:5d43154d68a8, Jul  8 2012, 13:54:45) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
>>> from pkgutil import ImpImporter
>>> importer = ImpImporter()
>>> list(importer.iter_modules())
[]

Strictly speaking, one could say the documentation only applies to the find_module() method since that's the only method covered by the PEP 302 API  However, iter_modules() is a public method.  So I think that either iter_modules() should be fixed, made private, or else the documentation clarified by saying that searching sys.path does not apply to iter_modules().

I'm pretty sure though that iter_modules() should be fixed.  This is because there are other functions in pkgutil that seem not to work because ImpImporter.iter_modules() behaves the way it does (specifically calling pkgutil.iter_modules() with path=None).

----------
components: Library (Lib)
messages: 165038
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: ImpImporter(None).iter_modules() does not search sys.path
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15299>
_______________________________________

From report at bugs.python.org  Sun Jul  8 23:49:04 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 08 Jul 2012 21:49:04 +0000
Subject: [issue15299] pkgutil.ImpImporter(None).iter_modules() does not search
	sys.path
In-Reply-To: <1341784087.15.0.754005593473.issue15299@psf.upfronthosting.co.za>
Message-ID: <1341784144.59.0.00445925410517.issue15299@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
title: ImpImporter(None).iter_modules() does not search sys.path -> pkgutil.ImpImporter(None).iter_modules() does not search sys.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15299>
_______________________________________

From report at bugs.python.org  Sun Jul  8 23:51:10 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 08 Jul 2012 21:51:10 +0000
Subject: [issue15294] regression with nested namespace packages
In-Reply-To: <1341753365.82.0.907088897601.issue15294@psf.upfronthosting.co.za>
Message-ID: <1341784270.7.0.604285743721.issue15294@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/issue15294>
_______________________________________

From report at bugs.python.org  Sun Jul  8 23:53:50 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 21:53:50 +0000
Subject: [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <3WVk2j0b81zNPF@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ab22ffa6fb2e by Terry Jan Reedy in branch '2.7':
Issue #13557: Clarify effect of giving two different namespaces to exec or
http://hg.python.org/cpython/rev/ab22ffa6fb2e

New changeset ea670d71a36d by Terry Jan Reedy in branch '3.2':
Issue #13557: Clarify effect of giving two different namespaces to exec or
http://hg.python.org/cpython/rev/ea670d71a36d

New changeset b47ae7a9e685 by Terry Jan Reedy in branch 'default':
Merge 3.2 closes issue 13557
http://hg.python.org/cpython/rev/b47ae7a9e685

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13557>
_______________________________________

From report at bugs.python.org  Mon Jul  9 00:18:39 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 08 Jul 2012 22:18:39 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341785919.05.0.264787274992.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Martin, FYI, Pat processed my contrib form.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Mon Jul  9 00:38:09 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 08 Jul 2012 22:38:09 +0000
Subject: [issue14982] pkgutil.walk_packages seems to not work properly on
	Python 3.3a
In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za>
Message-ID: <1341787089.33.0.399597290487.issue14982@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

FYI, I created issue 15299 and issue 15297 which also relate to pkgutil.walk_packages() not working correctly in Python 3.3 -- even with the caveat added by Brett.  These two issues are in pkgutil.walk_packages()'s code path when passed path=None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14982>
_______________________________________

From report at bugs.python.org  Mon Jul  9 00:51:10 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 08 Jul 2012 22:51:10 +0000
Subject: [issue15294] regression with nested namespace packages
In-Reply-To: <1341753365.82.0.907088897601.issue15294@psf.upfronthosting.co.za>
Message-ID: <1341787870.84.0.548828628396.issue15294@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

The patch looks good to me. I haven't run the tests, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15294>
_______________________________________

From report at bugs.python.org  Mon Jul  9 01:02:02 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 23:02:02 +0000
Subject: [issue15265] random.sample() docs unclear on k < len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <3WVlYP0FwmzNLp@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 72174d8af3ba by Raymond Hettinger in branch 'default':
Issue 15265: document the exception raised for invalid sample sizes.
http://hg.python.org/cpython/rev/72174d8af3ba

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15265>
_______________________________________

From report at bugs.python.org  Mon Jul  9 01:02:27 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Jul 2012 23:02:27 +0000
Subject: [issue15265] random.sample() docs unclear on k < len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341788547.73.0.276501237428.issue15265@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks, I've added a note.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15265>
_______________________________________

From report at bugs.python.org  Mon Jul  9 01:36:31 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 08 Jul 2012 23:36:31 +0000
Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za>
Message-ID: <1341790591.03.0.487891717339.issue4130@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

This is still broken after the libffi update (issue15194).  The errors are the same as Alex mentioned when he tested libffi-3.0.11.  The right way to go is to get this fixed in upstream libffi and backport the patch.

----------
assignee: theller -> 
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4130>
_______________________________________

From report at bugs.python.org  Mon Jul  9 01:49:34 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 08 Jul 2012 23:49:34 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1341739832.34.0.366414803172.issue14826@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOTvn-LANn+ScqZnnoRD2fsr_zo1rr-BM4de0+pWnQBopA@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Sun, Jul 8, 2012 at 2:30 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Senthil, do you read python-dev? I think this change was prematurate from the start (nevermind the fact that you didn't run the test suite before committing).

I  thought that the other legacy URLOpen was quoting it correct and
then I wanted to see it can be made consistent.
It did get me thinking that why it was different for so long. I
realize that committing soon was a mistake.

> For example, if you have an URL with a non-ASCII domain name such as "http://?????-?????????.???/", the domain name should IDNA-encoded, not %-encoded like the rest.

Agreed and understood.

> Furthermore, some people are certainly already quoting their URLs to workaround this issue, so "fixing" it will break their code by double-escaping the URLs. You've got to be more careful.

Oh. yes, the change may break an already quoted URL. I think, I shall
revert this back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Mon Jul  9 01:52:06 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 08 Jul 2012 23:52:06 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1341765739.74.0.0644608019897.issue14826@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOQDVwb4+MfvRTBaHUawDPB67SHNpCsCsECoSSgog_7UMg@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Sun, Jul 8, 2012 at 9:42 AM, Christian Heimes <report at bugs.python.org> wrote:

> I vote for reverting the chances as they break the API. You could improve the docs and emphasize that URLs must be quoted correctly as the module doesn't implement browser magic.

Okay. But I do realize that in 3.3, we may have a FancyURLOpener /
URLOpener 's open method, which is not directly called by the apis,
but they seem to have quote behavior. I guess, I approached this
change as to making them consistent, but realize it is mistake, for
the reasons that you state and Antoine state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Mon Jul  9 01:58:49 2012
From: report at bugs.python.org (Ali Rahmjoo)
Date: Sun, 08 Jul 2012 23:58:49 +0000
Subject: [issue12988] Tkinter File Dialog crashes on Win7 when saving to
	Documents Library
In-Reply-To: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za>
Message-ID: <1341791929.93.0.833931786968.issue12988@psf.upfronthosting.co.za>


Ali Rahmjoo <ali_rahmjoo at yahoo.com> added the comment:

I have exactly the same problem mentioned by Brian Gernhardt for 32-bit Python 3.2.3 on Win7.

----------
nosy: +alirahmjoo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12988>
_______________________________________

From report at bugs.python.org  Mon Jul  9 01:59:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 08 Jul 2012 23:59:28 +0000
Subject: [issue14715] test.support.DirsOnSysPath should be replaced by
	importlib.test.util.import_state
In-Reply-To: <1336079069.84.0.625762752869.issue14715@psf.upfronthosting.co.za>
Message-ID: <1341791968.15.0.0595331743105.issue14715@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14715>
_______________________________________

From report at bugs.python.org  Mon Jul  9 02:59:11 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 00:59:11 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <3WVp8Z0TFPzNBf@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ebd37273e0fe by Senthil Kumaran in branch '3.2':
revert the changes done for issue14826 - quoting witin Request is not desirable.
http://hg.python.org/cpython/rev/ebd37273e0fe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Mon Jul  9 03:00:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 01:00:08 +0000
Subject: [issue14826] urllib2.urlopen fails to load URL
In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>
Message-ID: <3WVp9g435rzNR7@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a4bdb637d818 by Senthil Kumaran in branch 'default':
revert the changes done for issue14826 - quoting witin Request is not desirable.
http://hg.python.org/cpython/rev/a4bdb637d818

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14826>
_______________________________________

From report at bugs.python.org  Mon Jul  9 03:04:37 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 09 Jul 2012 01:04:37 +0000
Subject: [issue15262] Idle does not show traceback in other threads
In-Reply-To: <1341563293.08.0.285980110052.issue15262@psf.upfronthosting.co.za>
Message-ID: <1341795877.59.0.29756459703.issue15262@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Mark, I ran your example against 2.7.1 and did not receive a traceback. I then ran it against the latest 2.7.3+ and receive a traceback in IDLE. Here's the entire Shell contents:


Python 2.7.3+ (2.7:97445ca895d5, Jul  8 2012, 19:58:43) 
[GCC 4.5.2] on linux2
Type "copyright", "credits" or "license()" for more information.
>>> from thread import start_new
>>> def f(): typo

>>> start_new(f, ())
139804918241024Unhandled exception in thread started by 
<function f at 0x1e36050>
>>> 
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in f
NameError: global name 'typo' is not defined

>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15262>
_______________________________________

From report at bugs.python.org  Mon Jul  9 03:09:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 01:09:26 +0000
Subject: [issue15300] test directory doubly-nested running tests with
	-j/--multiprocess
Message-ID: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

Running tests using the -j/--multiprocess option doubly-nests the test working directory:

$ ./python.exe -m test -j3 
-->cpython/build/test_python_63955/build/test_python_63956 
$ ./python.exe -m test
-->cpython/build/test_python_63957

It seems like the test directories for different processes should be siblings when running in multiprocessing mode as opposed to doubly-nesting under a new build directory.

----------
components: Tests
messages: 165052
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: test directory doubly-nested running tests with -j/--multiprocess
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15300>
_______________________________________

From report at bugs.python.org  Mon Jul  9 04:15:40 2012
From: report at bugs.python.org (do1)
Date: Mon, 09 Jul 2012 02:15:40 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
Message-ID: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>


New submission from do1 <do1 at yandex.ru>:

os.chown() can not change uid/gid to valid but high number.

# chown 4294967294.4294967294 a
# ls -l a
-rw-r--r-- 1 4294967294 4294967294 0 Jul  9 05:22 a

# python
Python 2.7.3 (default, Jun 24 2012, 06:19:44)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.chown("a", 4294967294, 4294967294)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long

----------
components: None
messages: 165053
nosy: do1
priority: normal
severity: normal
status: open
title: os.chown: OverflowError: Python int too large to convert to C long
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Mon Jul  9 04:26:36 2012
From: report at bugs.python.org (do1)
Date: Mon, 09 Jul 2012 02:26:36 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1341800796.54.0.830094728869.issue15301@psf.upfronthosting.co.za>


do1 <do1 at yandex.ru> added the comment:

I can add that system is x86_32. Same code in x86_64 result in no error even on older Python version 2.6.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Mon Jul  9 05:11:33 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 03:11:33 +0000
Subject: [issue15300] test directory doubly-nested running tests with
	-j/--multiprocess
In-Reply-To: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>
Message-ID: <1341803493.19.0.296261126985.issue15300@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching a small refactoring patch to eliminate some cut-and-paste, prior to fixing this issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file26322/issue-15300-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15300>
_______________________________________

From report at bugs.python.org  Mon Jul  9 05:17:19 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Jul 2012 03:17:19 +0000
Subject: [issue15262] Idle does not show traceback in other threads
In-Reply-To: <1341563293.08.0.285980110052.issue15262@psf.upfronthosting.co.za>
Message-ID: <1341803839.44.0.60528519455.issue15262@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks Roger. So this should be fixed in the upcoming 2.7.4 and probably 3.2.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15262>
_______________________________________

From report at bugs.python.org  Mon Jul  9 06:15:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 04:15:58 +0000
Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples
In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za>
Message-ID: <3WVtWd19vWzNQB@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset eea379307efa by Terry Jan Reedy in branch '3.2':
Issue 12510: Delete actual first param name for all methods; revise tests.
http://hg.python.org/cpython/rev/eea379307efa

New changeset 464c6a50b0ce by Terry Jan Reedy in branch 'default':
Merge with 3.2 Issue 12510
http://hg.python.org/cpython/rev/464c6a50b0ce

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12510>
_______________________________________

From report at bugs.python.org  Mon Jul  9 06:17:32 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Jul 2012 04:17:32 +0000
Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples
In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za>
Message-ID: <1341807452.43.0.635732107393.issue12510@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for the 'positive lookbehind assertion' for anchoring the match after '('. That is what I was missing. '[^,]' is too broad as, in particular, it matches the ')' in 'a(self)'. We don't want the ')' removed. The tests passed with a faulty re because the method test was faulty in that it only tested that something is removed, but not that the removal is correct. I fixed the tests also to really test proper removal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12510>
_______________________________________

From report at bugs.python.org  Mon Jul  9 06:43:32 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Jul 2012 04:43:32 +0000
Subject: [issue1757057] Unexpected "maximum recursion depth exceeded" in IDLE
	shell with objects that cannot be pickled
Message-ID: <1341809012.84.0.614469527205.issue1757057@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/issue1757057>
_______________________________________

From report at bugs.python.org  Mon Jul  9 06:56:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Jul 2012 04:56:52 +0000
Subject: [issue11176] give more meaningful argument names in argparse
	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1341809812.38.0.37035834031.issue11176@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yep, this is still open.  Thanks for the patch, I did a review (if you did not get a mail, follow the link in the list of files).

----------
assignee: eric.araujo -> 
nosy: +ezio.melotti, sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Mon Jul  9 07:00:02 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Jul 2012 05:00:02 +0000
Subject: [issue15125] argparse: positional arguments containing - in name not
	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1341810002.23.0.567167247433.issue15125@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Isn?t the obvious workaround to pass a dest argument which is a valid identifier?  add_argument('spam-eggs', dest='spam_eggs')

Maybe argparse in 3.4 could do this transformation automatically (see how namedtuple converts anything to valid identifiers).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15125>
_______________________________________

From report at bugs.python.org  Mon Jul  9 07:00:48 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Jul 2012 05:00:48 +0000
Subject: [issue15270] "Economy of Expression" section outdated
In-Reply-To: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za>
Message-ID: <1341810048.1.0.187091990551.issue15270@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/issue15270>
_______________________________________

From report at bugs.python.org  Mon Jul  9 07:01:50 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Jul 2012 05:01:50 +0000
Subject: [issue15295] Document PEP 420 namespace packages
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1341810110.43.0.552598742778.issue15295@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/issue15295>
_______________________________________

From report at bugs.python.org  Mon Jul  9 07:03:42 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Jul 2012 05:03:42 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>
Message-ID: <1341810222.03.0.411564396377.issue15298@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, pitrou
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15298>
_______________________________________

From report at bugs.python.org  Mon Jul  9 07:06:16 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 05:06:16 +0000
Subject: [issue15300] test directory doubly-nested running tests with
	-j/--multiprocess
In-Reply-To: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>
Message-ID: <1341810376.17.0.294303781313.issue15300@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

And here is the second part.  Combining this with the first patch provides a fix.

----------
Added file: http://bugs.python.org/file26323/issue-15300-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15300>
_______________________________________

From report at bugs.python.org  Mon Jul  9 07:09:46 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Jul 2012 05:09:46 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341810586.54.0.511451378772.issue13532@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The patch (to my production Idle, with name fix) prevents crashing and raises an error instead when an object *can* be pickled, so I will apply before 3.3 if no problems appear and we cannot do better.

But written objects are still pickled, so sys.stdout.write(sys) still raises the PicklingError instead of (as in CP interpreter)
  TypeError: must be str, not module

It seems to me that the type check should be done in the subprocess before the object (which should be a string) is pickled. (I also wonder if it is really necessary to pickle a string or the encoded bytes to send it back. The pickle is just a stream of bytes.)

----------
title: In IDLE,	sys.stdout.write and sys.stderr can write any pickleable object -> In IDLE,	sys.stdout and sys.stderr can write any pickleable object

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Mon Jul  9 07:11:33 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 09 Jul 2012 05:11:33 +0000
Subject: [issue15273] Remove unnecessarily random behavior from test_unparse.py
In-Reply-To: <1341664153.44.0.16452834514.issue15273@psf.upfronthosting.co.za>
Message-ID: <1341810693.56.0.302748098021.issue15273@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

test_grammar should be that file, though, people often forget to update it.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15273>
_______________________________________

From report at bugs.python.org  Mon Jul  9 07:26:24 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 05:26:24 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
Message-ID: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think it would be an improvement to switch from using getopt to argparse in test.regrtest.  The code would be easier to maintain, it would give us more powerful options going forward, and it would improve the usability of the test command (e.g. nicer command-line help).

----------
components: Tests
keywords: easy
messages: 165064
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Use argparse instead of getopt in test.regrtest
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Mon Jul  9 07:28:10 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 05:28:10 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>
Message-ID: <1341811690.27.0.183398253226.issue15302@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

It is also in the spirit of dogfooding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Mon Jul  9 07:47:17 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 05:47:17 +0000
Subject: [issue15300] test directory doubly-nested running tests with
	-j/--multiprocess
In-Reply-To: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>
Message-ID: <1341812837.31.0.251044643115.issue15300@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Here is a single combined patch.  I gather this is preferred.

----------
Added file: http://bugs.python.org/file26324/issue-15300-combined.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15300>
_______________________________________

From report at bugs.python.org  Mon Jul  9 07:55:08 2012
From: report at bugs.python.org (Nicu Stiurca)
Date: Mon, 09 Jul 2012 05:55:08 +0000
Subject: [issue15125] argparse: positional arguments containing - in name not
	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1341813308.99.0.290405321146.issue15125@psf.upfronthosting.co.za>


Nicu Stiurca <supernic2002 at gmail.com> added the comment:

Eric:
I agree, that would be the obvious workaround. However, it turns that the way dest is set differs for optional and positional arguments. I alluded to this in my earlier message http://bugs.python.org/issue15125#msg163456

Specifically, it turns out that when the first argument to add_argument() starts with '-', it is interpreted as an optional argument and dest in _inferred_ from the first argument (eg, by stripping leading '-', and replacing remaining '-' with '_'). So supplying dest= to add_argument() overrides this heuristic.

But when the first argument to add_argument() does not start with a '-', dest becomes exactly the first argument, and supplying dest as a keyword argument like you suggest yields the exception I reported earlier.

Revisiting the documentation on dest (http://docs.python.org/dev/library/argparse.html#dest), this behavior is briefly and un-enlighteningly addressed in the first paragraph. The problem is that the paragraph suggests that dest can be explicitly set using keyword argument even for positional arguments; instead a ValueError is thrown as I have already mentioned.

I suppose that patching argparse to replace '-' with '_' for positional arguments may break existing code for anyone that has figured out they can get hyphenated positional arguments with getattr(), which would make it a risky patch. But patching the module to allow explicitly setting dest via keyword argument shouldn't hurt anybody.

For clarity, I recommend adding """(This conversion does NOT take place for positional arguments.)""" before the last sentence of paragraph 2 in the dest documentation.

Since I had no idea about using getattr, I bet others wouldn't figure it out either. I suggest also adding a simple example in the documentation for anybody that wants to use an invalid Python identifier as an argument. (Please don't say this is an invalid use case because eg, ssh has options -1, -2, -4, and -6.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15125>
_______________________________________

From report at bugs.python.org  Mon Jul  9 08:11:34 2012
From: report at bugs.python.org (David Lam)
Date: Mon, 09 Jul 2012 06:11:34 +0000
Subject: [issue11176] give more meaningful argument names in argparse
	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1341814294.43.0.316991903348.issue11176@psf.upfronthosting.co.za>


David Lam <d at dlam.me> added the comment:

haha wow, I was working on this bug too!  maybe we can work on the final patch together

I got through about 2/3's of the docs, so I thought it might help to upload what I got so far.  I basically just made stuff up so I'm totally winning to change anything (or everything)

I made a little effort to make the examples mildly amusing, since novelty sorta helps in retention.  So one of the recurring examples I used involves that of a pizza-making-program... hopefully this helps in some way!

----------
nosy: +dlam
Added file: http://bugs.python.org/file26325/issue11165-doc-fix-up-to-section-15.4.4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Mon Jul  9 09:42:47 2012
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 09 Jul 2012 07:42:47 +0000
Subject: [issue15189] tkinter.messagebox does not use the application's icon
In-Reply-To: <1340695188.66.0.13086714969.issue15189@psf.upfronthosting.co.za>
Message-ID: <1341819767.89.0.480554513093.issue15189@psf.upfronthosting.co.za>


Mark Summerfield <mark at qtrac.eu> added the comment:

On Linux & Windows every top-level window (including dialogs) normally has an icon at the left of the title bar. Typically this icon is the application's icon. But tkinter doesn't provide such an icon and so a system default icon is used instead. For one's own code this can be fixed by using the iconbitmap() function, but for the tkinter convenience dialogs (e.g., askyesno()), this cannot be done. So, my suggestion is to make the convenience dialogs use the same icon as the application (if the application has one).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15189>
_______________________________________

From report at bugs.python.org  Mon Jul  9 10:25:50 2012
From: report at bugs.python.org (Drew French)
Date: Mon, 09 Jul 2012 08:25:50 +0000
Subject: [issue15303] Minor revision to the <BaseWidget._setup> method in
	Tkinter
Message-ID: <1341822350.55.0.995662615633.issue15303@psf.upfronthosting.co.za>


New submission from Drew French <rectangletangle at gmail.com>:

In the <BaseWidget._setup> method, <master> is evaluated as a Boolean (when Tkinter attempts to find a parent for the widget). I think it should really be evaluated against <None>, seeing as that is the default <master> keyword argument value for most widgets. I ran into problems with this when making a container widget class that inherited from the <Canvas>, then implementing the <__len__> magic method. When the length was zero the widget would evaluate as false, which would prevented me from packing widgets inside my container widget.

I attached a revised version of the method.

----------
components: Tkinter
files: tkbugfix.py
messages: 165070
nosy: Drew.French
priority: normal
severity: normal
status: open
title: Minor revision to the <BaseWidget._setup> method in Tkinter
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26326/tkbugfix.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15303>
_______________________________________

From report at bugs.python.org  Mon Jul  9 10:25:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 08:25:58 +0000
Subject: [issue15283] pyvenv says nothing on success
In-Reply-To: <1341676517.75.0.848646137047.issue15283@psf.upfronthosting.co.za>
Message-ID: <3WW0451Jc5zNcM@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset baf5ed391a7f by Vinay Sajip in branch 'default':
Issue #15283: Updated pyvenv documentation to expand on activation.
http://hg.python.org/cpython/rev/baf5ed391a7f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15283>
_______________________________________

From report at bugs.python.org  Mon Jul  9 10:26:08 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Jul 2012 08:26:08 +0000
Subject: [issue15279] Spurious unittest warnings
In-Reply-To: <1341674545.77.0.716203051696.issue15279@psf.upfronthosting.co.za>
Message-ID: <1341822368.64.0.469113891732.issue15279@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Unfortunately, exactly the same thing happens with

    == CPython 3.3.0b1 (default:464c6a50b0ce, Jul 9 2012, 09:26:07) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61)]
    ==   Darwin-11.4.0-x86_64-i386-64bit little-endian
    ==   /Users/ambv/Documents/Projekty/Python/cpython/py33/build/test_python_37987
    Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)

What's interesting is that test_warnings itself works as advertised and it's only Lib/unittest/test/_test_warnings.py that misbehaves.

On my friend's 10.7 machine everything runs fine with a little older Clang:

    == CPython 3.3.0b1 (default, Jul 9 2012, 09:52:57) [GCC 4.2.1 Compatible Apple Clang 3.0 (tags/Apple/clang-211.12)]
    ==   Darwin-11.4.0-x86_64-i386-64bit little-endian
    ==   /Users/sheep/dev/python/cpython-464c6a50b0ce/build/test_python_7695
    Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)

Will investigate further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15279>
_______________________________________

From report at bugs.python.org  Mon Jul  9 10:42:52 2012
From: report at bugs.python.org (Drew French)
Date: Mon, 09 Jul 2012 08:42:52 +0000
Subject: [issue15189] tkinter.messagebox does not use the application's icon
In-Reply-To: <1340695188.66.0.13086714969.issue15189@psf.upfronthosting.co.za>
Message-ID: <1341823372.5.0.857933937015.issue15189@psf.upfronthosting.co.za>


Drew French <rectangletangle at gmail.com> added the comment:

This is also true for some of the other dialogs (such as the file dialogs). 

Does anyone know if this behavior can be changed in Tk itself?

----------
nosy: +Drew.French

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15189>
_______________________________________

From report at bugs.python.org  Mon Jul  9 12:31:53 2012
From: report at bugs.python.org (Tim Golden)
Date: Mon, 09 Jul 2012 10:31:53 +0000
Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility
In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za>
Message-ID: <1341829913.08.0.635003156859.issue15267@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

Could you create a failing test, please, Tim S?

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15267>
_______________________________________

From report at bugs.python.org  Mon Jul  9 12:55:54 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 10:55:54 +0000
Subject: [issue15279] Spurious unittest warnings
In-Reply-To: <1341674545.77.0.716203051696.issue15279@psf.upfronthosting.co.za>
Message-ID: <1341831354.92.0.227055878393.issue15279@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15279>
_______________________________________

From report at bugs.python.org  Mon Jul  9 13:27:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 11:27:20 +0000
Subject: [issue15304] Wrong path in test.support.temp_cwd() error message
Message-ID: <1341833239.95.0.652006223487.issue15304@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

test.support.temp_cwd() has a typo (s/name/path/):

try:
    os.chdir(path)
except OSError:
    if not quiet:
        raise
    warnings.warn('tests may fail, unable to change the CWD to ' + name,
                  RuntimeWarning, stacklevel=3)

----------
components: Tests
keywords: easy
messages: 165075
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Wrong path in test.support.temp_cwd() error message
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15304>
_______________________________________

From report at bugs.python.org  Mon Jul  9 13:36:20 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 09 Jul 2012 11:36:20 +0000
Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility
In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za>
Message-ID: <1341833780.21.0.95901470556.issue15267@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

BTW, type(0) should be replaced with int in the code.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15267>
_______________________________________

From report at bugs.python.org  Mon Jul  9 13:45:51 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 11:45:51 +0000
Subject: [issue15305] Test harness unnecessarily disambiguating twice
Message-ID: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

It seems like our test harness is disambiguating more than it needs to for parallel testing.

In Lib/test/regrtest.py, we do this--

# Define a writable temp dir that will be used as cwd while running
# the tests. The name of the dir includes the pid to allow parallel
# testing (see the -j option).
TESTCWD = 'test_python_{}'.format(os.getpid())
...
with support.temp_cwd(TESTCWD, quiet=True):
    main()

And then in Lib/test/support.py, we are doing this--

# Disambiguate TESTFN for parallel testing, while letting it remain a valid
# module name.
TESTFN = "{}_{}_tmp".format(TESTFN, os.getpid())

with uses like--

with open(TESTFN, "wb") as f:
    # Do stuff with f.

It seems like only one of these measures should be necessary (a single working directory for all parallel tests using a disambiguated TESTFN, or one working directory for each process with a non-disambiguated TESTFN).

----------
components: Tests
keywords: easy
messages: 165077
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Test harness unnecessarily disambiguating twice
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15305>
_______________________________________

From report at bugs.python.org  Mon Jul  9 13:51:00 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 11:51:00 +0000
Subject: [issue15305] Test harness unnecessarily disambiguating twice
In-Reply-To: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>
Message-ID: <1341834660.99.0.315603842426.issue15305@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

The former option seems to make more sense to me (a single working directory for all parallel tests using a disambiguated TESTFN).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15305>
_______________________________________

From report at bugs.python.org  Mon Jul  9 14:11:53 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 12:11:53 +0000
Subject: [issue15300] test directory doubly-nested running tests with
	-j/--multiprocess
In-Reply-To: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>
Message-ID: <1341835913.5.0.503512302671.issue15300@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

After this patch, it's clear that TEMPDIR and TESTCWD no longer have to be global variables.

I can make that a separate issue after this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15300>
_______________________________________

From report at bugs.python.org  Mon Jul  9 15:04:30 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 13:04:30 +0000
Subject: [issue15304] Wrong path in test.support.temp_cwd() error message
In-Reply-To: <1341833239.95.0.652006223487.issue15304@psf.upfronthosting.co.za>
Message-ID: <1341839070.2.0.92286362323.issue15304@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Adding failing test.

----------
keywords: +patch
stage:  -> needs patch
Added file: http://bugs.python.org/file26327/issue-15304-failing-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15304>
_______________________________________

From report at bugs.python.org  Mon Jul  9 15:15:33 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 13:15:33 +0000
Subject: [issue15304] Wrong path in test.support.temp_cwd() error message
In-Reply-To: <1341833239.95.0.652006223487.issue15304@psf.upfronthosting.co.za>
Message-ID: <1341839733.49.0.906789784012.issue15304@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching fix.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26328/issue-15304-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15304>
_______________________________________

From report at bugs.python.org  Mon Jul  9 15:16:45 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 09 Jul 2012 13:16:45 +0000
Subject: [issue15297] pkgutil.iter_importers() includes an ImpImporter
In-Reply-To: <1341781980.93.0.099189257301.issue15297@psf.upfronthosting.co.za>
Message-ID: <1341839805.48.0.971629350214.issue15297@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/issue15297>
_______________________________________

From report at bugs.python.org  Mon Jul  9 15:17:09 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 09 Jul 2012 13:17:09 +0000
Subject: [issue15299] pkgutil.ImpImporter(None).iter_modules() does not search
	sys.path
In-Reply-To: <1341784087.15.0.754005593473.issue15299@psf.upfronthosting.co.za>
Message-ID: <1341839829.02.0.375758897442.issue15299@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/issue15299>
_______________________________________

From report at bugs.python.org  Mon Jul  9 15:18:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 13:18:35 +0000
Subject: [issue15299] pkgutil.ImpImporter(None).iter_modules() does not search
	sys.path
In-Reply-To: <1341784087.15.0.754005593473.issue15299@psf.upfronthosting.co.za>
Message-ID: <1341839915.39.0.869601953577.issue15299@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I'm working on a test for this.

----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15299>
_______________________________________

From report at bugs.python.org  Mon Jul  9 16:10:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 14:10:18 +0000
Subject: [issue15299] pkgutil.ImpImporter(None).iter_modules() does not search
	sys.path
In-Reply-To: <1341784087.15.0.754005593473.issue15299@psf.upfronthosting.co.za>
Message-ID: <1341843018.29.0.0402601068339.issue15299@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Add failing tests.

----------
keywords: +patch
stage: test needed -> needs patch
Added file: http://bugs.python.org/file26329/issue-15299-failing-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15299>
_______________________________________

From report at bugs.python.org  Mon Jul  9 16:35:49 2012
From: report at bugs.python.org (Ztatik Light)
Date: Mon, 09 Jul 2012 14:35:49 +0000
Subject: [issue15306] Python3 segfault? (works in Python2)
Message-ID: <1341844549.14.0.695574663066.issue15306@psf.upfronthosting.co.za>


New submission from Ztatik Light <ztatik.light at gmail.com>:

I think I've found a bug ...

The issue is that it works fine on Python2 but segfaults on Python3.. (The second to last line causes the crash)

Tested on v2.6.6 and 3.1.3:

(Must have libfreetype6 and the TTF specified on 5th to last line [if on Windows, simple download libfreetype6 here: http://tinyurl.com/7dvgffw and replace the '.ttf' string with any existing .ttf file])

[File attached as 'test.py']

----------
components: IO, Interpreter Core, Library (Lib), None, ctypes
files: test.py
messages: 165084
nosy: Ztatik.Light
priority: normal
severity: normal
status: open
title: Python3 segfault? (works in Python2)
type: crash
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file26330/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15306>
_______________________________________

From report at bugs.python.org  Mon Jul  9 16:40:26 2012
From: report at bugs.python.org (Mark)
Date: Mon, 09 Jul 2012 14:40:26 +0000
Subject: [issue15262] Idle does not show traceback in other threads
In-Reply-To: <1341563293.08.0.285980110052.issue15262@psf.upfronthosting.co.za>
Message-ID: <1341844826.35.0.690610001731.issue15262@psf.upfronthosting.co.za>


Mark <myagna01 at students.poly.edu> added the comment:

Yay!  I can't wait :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15262>
_______________________________________

From report at bugs.python.org  Mon Jul  9 17:00:02 2012
From: report at bugs.python.org (Ztatik Light)
Date: Mon, 09 Jul 2012 15:00:02 +0000
Subject: [issue15306] Python3 segfault? (works in Python2)
In-Reply-To: <1341844549.14.0.695574663066.issue15306@psf.upfronthosting.co.za>
Message-ID: <1341846002.37.0.745974231629.issue15306@psf.upfronthosting.co.za>


Ztatik Light <ztatik.light at gmail.com> added the comment:

Crash happens in FT_Request_Size and seems to have been addressed by someone working at SFML:

http://en.sfml-dev.org/forums/index.php?topic=2208.0

[Backtrace attached as 'backtrace.txt']

----------
Added file: http://bugs.python.org/file26331/backtrace.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15306>
_______________________________________

From report at bugs.python.org  Mon Jul  9 17:13:41 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 09 Jul 2012 15:13:41 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
Message-ID: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The attached patch ensures that "python3.3 -mvenv --symlinks myenv" works with framework builds.

There are two functional changes:
1) don't call 'realpath' in pythonw.c because realpath resolves
   symlinks and that breaks the '--symlinks' options because the
   python command is a symlink with that option (and resolving that
   gives the path to the python executable in the framework)

2) Look for the __PYVENV_LAUNCHER__ environment variable in
   Modules/getpath.c and use that in preference on the already
   calculated value of argv0_path. That code is only active for
   framework builds

I'm not happy with the following line in this patch:

+            wcsncpy(argv0_path, (wchar_t*)pyvenv_launcher, MAXPATHLEN);

That mirrors a similar cast of the result of NSLibraryNameForModule earlier in Modules/getpath.c, but in both cases the input stream is a narrow character string ("char", not "wchar_t") and wcsncpy expects a "wchar_t". The the cast seems to paper over a real problem here.

Shouldn't both lines use "_Py_char2wchar" to convert the char* buffer to a wchar_t* one?

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
files: venv-symlinks.txt
keywords: needs review, patch
messages: 165087
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: Patch for --symlink support in pyvenv with framework python
versions: Python 3.3
Added file: http://bugs.python.org/file26332/venv-symlinks.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Mon Jul  9 17:14:54 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 09 Jul 2012 15:14:54 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1341846894.86.0.792737664928.issue15307@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ned.deily, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Mon Jul  9 17:15:53 2012
From: report at bugs.python.org (Ztatik Light)
Date: Mon, 09 Jul 2012 15:15:53 +0000
Subject: [issue15306] Python3 segfault? (works in Python2)
In-Reply-To: <1341844549.14.0.695574663066.issue15306@psf.upfronthosting.co.za>
Message-ID: <1341846953.48.0.559442386453.issue15306@psf.upfronthosting.co.za>


Ztatik Light <ztatik.light at gmail.com> added the comment:

I think this is the related SFML fix patch commit:

https://github.com/LaurentGomila/SFML/commit/da5ac8a9512885c5b245a24915733c3b26f689b7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15306>
_______________________________________

From report at bugs.python.org  Mon Jul  9 17:21:16 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 09 Jul 2012 15:21:16 +0000
Subject: [issue15306] Python3 segfault? (works in Python2)
In-Reply-To: <1341844549.14.0.695574663066.issue15306@psf.upfronthosting.co.za>
Message-ID: <1341847276.84.0.230747448054.issue15306@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

How is the fix related to Python?

Also, you pass a unicode string to freetype.FT_New_Face.
You should probably pass a bytes string there, and in any case set the "argtypes" and "restypes" attributes to ctypes functions, to prevent such failures.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15306>
_______________________________________

From report at bugs.python.org  Mon Jul  9 17:37:13 2012
From: report at bugs.python.org (Ztatik Light)
Date: Mon, 09 Jul 2012 15:37:13 +0000
Subject: [issue15306] Python3 segfault? (works in Python2)
In-Reply-To: <1341844549.14.0.695574663066.issue15306@psf.upfronthosting.co.za>
Message-ID: <1341848233.38.0.426868176104.issue15306@psf.upfronthosting.co.za>


Ztatik Light <ztatik.light at gmail.com> added the comment:

Mmmm. The fix isn't necessary related to python at all but I figured might potentially AIDE in a python fix. Also, I'm not passing a unicode string... that says '/u' not '\u' ... Also, I tried setting res/argtypes but to no avail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15306>
_______________________________________

From report at bugs.python.org  Mon Jul  9 17:40:04 2012
From: report at bugs.python.org (Ztatik Light)
Date: Mon, 09 Jul 2012 15:40:04 +0000
Subject: [issue15306] Python3 segfault? (works in Python2)
In-Reply-To: <1341844549.14.0.695574663066.issue15306@psf.upfronthosting.co.za>
Message-ID: <1341848404.4.0.452706431109.issue15306@psf.upfronthosting.co.za>


Ztatik Light <ztatik.light at gmail.com> added the comment:

Ooohhhh ... using bytes() DID seem to help. HAHA?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15306>
_______________________________________

From report at bugs.python.org  Mon Jul  9 17:43:23 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 09 Jul 2012 15:43:23 +0000
Subject: [issue15306] Python3 segfault? (works in Python2)
In-Reply-To: <1341844549.14.0.695574663066.issue15306@psf.upfronthosting.co.za>
Message-ID: <1341848603.55.0.399644566094.issue15306@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

In Python2, strings are bytes; in Python3, they are unicode.  You need to use the b'' syntax.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15306>
_______________________________________

From report at bugs.python.org  Mon Jul  9 18:19:53 2012
From: report at bugs.python.org (Tim Smith)
Date: Mon, 09 Jul 2012 16:19:53 +0000
Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility
In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za>
Message-ID: <1341850793.81.0.176061555511.issue15267@psf.upfronthosting.co.za>


Tim Smith <tzs at tzs.net> added the comment:

Here is a program that demonstrates the problem:

    import httplib
    import tempfile

    f = tempfile.TemporaryFile()
    f.write("Hello, Temporary File!")
    f.seek(0)

    c = httplib.HTTPConnection('bugs.python.org')
    c.request('POST', '/', f, {'Content-type' : 'application/octet-stream'})

    r = c.getresponse()
    print r.status, r.reason

The expected output is "200 OK", and that's what happens on Mac and almost certainly on Linux. On Windows, this is the result:

    Traceback (most recent call last):
      File "bad.py", line 9, in <module>
        c.request('POST', '/', f, {'Content-type' : 'application/octet
      File "C:\Python27\lib\httplib.py", line 958, in request
        self._send_request(method, url, body, headers)
      File "C:\Python27\lib\httplib.py", line 989, in _send_request
        self._set_content_length(body)
      File "C:\Python27\lib\httplib.py", line 964, in _set_content_len
        thelen = str(len(body))
      File "C:\Python27\lib\tempfile.py", line 383, in __getattr__
        a = getattr(file, name)
    AttributeError: 'file' object has no attribute '__len__'

Changing the lines:

    f = tempfile.TemporaryFile()
    f.write("Hello, Temporary File!")
    f.seek(0)

to:

    f = open("temp.file", "w+")
    f.write("Hello, Less Temporary File!")
    f.seek(0)

makes it work on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15267>
_______________________________________

From report at bugs.python.org  Mon Jul  9 18:25:06 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Jul 2012 16:25:06 +0000
Subject: [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1341851106.88.0.449535598854.issue14787@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So the lack of output in 3.3 is not surprising as walk_packages() won't work with the new import implementation as it relies on a non-standard method on loaders that import does not provide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14787>
_______________________________________

From report at bugs.python.org  Mon Jul  9 18:30:43 2012
From: report at bugs.python.org (Ronan Lamy)
Date: Mon, 09 Jul 2012 16:30:43 +0000
Subject: [issue15297] pkgutil.iter_importers() includes an ImpImporter
In-Reply-To: <1341781980.93.0.099189257301.issue15297@psf.upfronthosting.co.za>
Message-ID: <1341851443.17.0.0891631524355.issue15297@psf.upfronthosting.co.za>


Ronan Lamy <ronan.lamy at gmail.com> added the comment:

AFAICT, the intent of this function was to help provide a fully PEP-302 compliant import process wrapping the builtin C-implemented import mechanism. Nowadays, I believe that iterating over sys.meta_path should probably be enough.

----------
nosy: +Ronan.Lamy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15297>
_______________________________________

From report at bugs.python.org  Mon Jul  9 19:08:48 2012
From: report at bugs.python.org (Ronan Lamy)
Date: Mon, 09 Jul 2012 17:08:48 +0000
Subject: [issue15288] Clarify the pkgutil.walk_packages() note
In-Reply-To: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>
Message-ID: <1341853728.25.0.938105204849.issue15288@psf.upfronthosting.co.za>


Ronan Lamy <ronan.lamy at gmail.com> added the comment:

It seems that most, if not all, uses of "importer" in pkgutil refer to finders, e.g. ImpImporter is a actually only a finder, not an importer. So s/importer/finder/ is needed, and perhaps also a note explaining that ImpImporter isn't in fact an importer, in addition to glossary links.

----------
nosy: +Ronan.Lamy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15288>
_______________________________________

From report at bugs.python.org  Mon Jul  9 19:24:43 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 17:24:43 +0000
Subject: [issue15256] Typo in error message
In-Reply-To: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>
Message-ID: <3WWD1k0BF8zNdW@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 75831951a6b5 by Brett Cannon in branch 'default':
Issue #15256: Re-use the ImportError exception message as defined by
http://hg.python.org/cpython/rev/75831951a6b5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15256>
_______________________________________

From report at bugs.python.org  Mon Jul  9 19:25:04 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Jul 2012 17:25:04 +0000
Subject: [issue15256] Typo in error message
In-Reply-To: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>
Message-ID: <1341854704.98.0.201590571756.issue15256@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the patch, Marc!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15256>
_______________________________________

From report at bugs.python.org  Mon Jul  9 19:44:02 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 17:44:02 +0000
Subject: [issue15297] pkgutil.iter_importers() includes an ImpImporter
In-Reply-To: <1341781980.93.0.099189257301.issue15297@psf.upfronthosting.co.za>
Message-ID: <1341855842.22.0.812428773462.issue15297@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Marking this a documentation issue because the same behavior is also present in 2.7:

Python 2.7.3 (default, Apr 19 2012, 00:55:09) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
>>> from pkgutil import iter_importers
>>> list(iter_importers())[-1]
<pkgutil.ImpImporter instance at 0x10517b710>

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +easy
nosy: +docs at python
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15297>
_______________________________________

From report at bugs.python.org  Mon Jul  9 19:58:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 17:58:16 +0000
Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError
	when cache tag not available
In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za>
Message-ID: <3WWDmR47lfzMgC@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e86330669bb5 by Brett Cannon in branch 'default':
Issue #15056: imp.cache_from_source() and source_from_cache() raise
http://hg.python.org/cpython/rev/e86330669bb5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15056>
_______________________________________

From report at bugs.python.org  Mon Jul  9 19:59:21 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Jul 2012 17:59:21 +0000
Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError
	when cache tag not available
In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za>
Message-ID: <1341856761.65.0.437586004507.issue15056@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I released Pranav's patch and fleshed it out with docs, tests, and changes to importlib's use of cache_from_source().

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15056>
_______________________________________

From report at bugs.python.org  Mon Jul  9 20:10:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 18:10:31 +0000
Subject: [issue15288] Clarify the pkgutil.walk_packages() note
In-Reply-To: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>
Message-ID: <3WWF2Y6yKMzNxY@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 96f7926ea444 by Brett Cannon in branch 'default':
Issue #15288: Clarify that pkgutil.walk_packages() and friends will no
http://hg.python.org/cpython/rev/96f7926ea444

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15288>
_______________________________________

From report at bugs.python.org  Mon Jul  9 20:11:21 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Jul 2012 18:11:21 +0000
Subject: [issue15288] Clarify the pkgutil.walk_packages() note
In-Reply-To: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>
Message-ID: <1341857481.12.0.794147585021.issue15288@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I changed to term to "loader" and linked to the glossary. I also added a versionchanged note for Python 3.3 so people are not too surprised that pkgutil no longer does what it did in Python 3.2.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15288>
_______________________________________

From report at bugs.python.org  Mon Jul  9 20:22:20 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 18:22:20 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <3WWFJC0f3lzP1S@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ee01fd98b5b0 by Brett Cannon in branch 'default':
Issue #15242: Have PyImport_GetMagicTag() return a const char *
http://hg.python.org/cpython/rev/ee01fd98b5b0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15242>
_______________________________________

From report at bugs.python.org  Mon Jul  9 20:23:24 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Jul 2012 18:23:24 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <1341858204.55.0.013785951208.issue15242@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I went ahead and committed Eric's patch. Amaury, if you want to move the macros to a header file I see no reason not to, but I also don't see a need so I didn't want to spend the time doing it myself.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15242>
_______________________________________

From report at bugs.python.org  Mon Jul  9 20:48:42 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Jul 2012 18:48:42 +0000
Subject: [issue15288] Clarify the pkgutil.walk_packages() note
In-Reply-To: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>
Message-ID: <1341859722.71.0.947464308372.issue15288@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Ronan is right that it is all about finders, not importers per-se. I fixed the docs to not say "loader".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15288>
_______________________________________

From report at bugs.python.org  Mon Jul  9 20:48:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Jul 2012 18:48:53 +0000
Subject: [issue15300] test directory doubly-nested running tests with
	-j/--multiprocess
In-Reply-To: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>
Message-ID: <1341859733.46.0.264596514666.issue15300@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox, r.david.murray
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15300>
_______________________________________

From report at bugs.python.org  Mon Jul  9 20:53:18 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 18:53:18 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <3WWFzw4ZdZzNtF@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 422242dbce30 by Martin v. L?wis in branch '3.2':
Issue #13532: Check that arguments to sys.stdout.write are strings.
http://hg.python.org/cpython/rev/422242dbce30

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Mon Jul  9 21:02:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 19:02:01 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <3WWGB0066xzNtv@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 58189e37331c by Martin v. L?wis in branch '2.7':
- Issue #13532: Check that arguments to sys.stdout.write are strings.
http://hg.python.org/cpython/rev/58189e37331c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Mon Jul  9 21:02:47 2012
From: report at bugs.python.org (Greg Roodt)
Date: Mon, 09 Jul 2012 19:02:47 +0000
Subject: [issue11176] give more meaningful argument names in argparse
	documentation
In-Reply-To: <1341814294.43.0.316991903348.issue11176@psf.upfronthosting.co.za>
Message-ID: <CAAD3oiKgbNB-Ne9i0_OCZST6GW=iu-DcoPqh3Lmwf62dBgndQw@mail.gmail.com>


Greg Roodt <groodt at gmail.com> added the comment:

Hi David

Ok, I like the idea of working on a solution together. I like your idea of
the pizza-making more than the current "foo bar" examples.

Should we collaborate outside of the bug tracker?

Greg

On 9 July 2012 07:11, David Lam <report at bugs.python.org> wrote:

>
> David Lam <d at dlam.me> added the comment:
>
> haha wow, I was working on this bug too!  maybe we can work on the final
> patch together
>
> I got through about 2/3's of the docs, so I thought it might help to
> upload what I got so far.  I basically just made stuff up so I'm totally
> winning to change anything (or everything)
>
> I made a little effort to make the examples mildly amusing, since novelty
> sorta helps in retention.  So one of the recurring examples I used involves
> that of a pizza-making-program... hopefully this helps in some way!
>
> ----------
> nosy: +dlam
> Added file:
> http://bugs.python.org/file26325/issue11165-doc-fix-up-to-section-15.4.4.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11176>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Mon Jul  9 21:05:06 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 09 Jul 2012 19:05:06 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341860706.98.0.965924549866.issue13532@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

All problems in computer science can be solved by another indirection...

I've added another wrapper around the RPC proxy to cause the type error. (A variant of) Roger's patch is still included to support the -n case.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Mon Jul  9 21:18:43 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 09 Jul 2012 19:18:43 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <1341861523.46.0.208064144234.issue15242@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's not necessary.  The fix looks good as is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15242>
_______________________________________

From report at bugs.python.org  Mon Jul  9 21:26:59 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 09 Jul 2012 19:26:59 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341862019.06.0.288761443015.issue13532@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I just pulled Martin's patches and they fix the issue. Indirection to the rescue!

There is one very slight problem though with the error message raised on 2.7 since it is different than 3.3. Attached is a patch to fix it.

----------
Added file: http://bugs.python.org/file26333/issue13532_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Mon Jul  9 21:27:37 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 19:27:37 +0000
Subject: [issue15294] regression with nested namespace packages
In-Reply-To: <1341753365.82.0.907088897601.issue15294@psf.upfronthosting.co.za>
Message-ID: <3WWGlX0b4FzP2X@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a7b8c3323db9 by Antoine Pitrou in branch 'default':
Issue #15294: Fix a regression in pkgutil.extend_path()'s handling of nested namespace packages.
http://hg.python.org/cpython/rev/a7b8c3323db9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15294>
_______________________________________

From report at bugs.python.org  Mon Jul  9 21:28:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Jul 2012 19:28:20 +0000
Subject: [issue15294] regression with nested namespace packages
In-Reply-To: <1341753365.82.0.907088897601.issue15294@psf.upfronthosting.co.za>
Message-ID: <1341862100.92.0.760244228852.issue15294@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed! I also backported the test to 3.2.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15294>
_______________________________________

From report at bugs.python.org  Mon Jul  9 21:53:24 2012
From: report at bugs.python.org (Greg Roodt)
Date: Mon, 09 Jul 2012 19:53:24 +0000
Subject: [issue11176] give more meaningful argument names in argparse
	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1341863604.02.0.531803281566.issue11176@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

I've made the minor edits required after the review to my simplification of the first example.

David, perhaps we combine our efforts? Use my simple first example to explain the very basics, then continue the explanation with the pizza example?

Im happy either way, I quite like your example using the system dictionary.

----------
Added file: http://bugs.python.org/file26334/1176_minor_edits.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:09:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 20:09:35 +0000
Subject: [issue13959] Re-implement parts of imp in pure Python
In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za>
Message-ID: <3WWHgy328rzP25@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset efb5e6ab10f4 by Brett Cannon in branch 'default':
Issue #15167 (as part of #13959): imp.get_magic() is no implemented in
http://hg.python.org/cpython/rev/efb5e6ab10f4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13959>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:09:36 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 20:09:36 +0000
Subject: [issue15167] Re-implement imp.get_magic() in pure Python
In-Reply-To: <1340567486.25.0.718240162307.issue15167@psf.upfronthosting.co.za>
Message-ID: <3WWHgz1sMrzP25@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset efb5e6ab10f4 by Brett Cannon in branch 'default':
Issue #15167 (as part of #13959): imp.get_magic() is no implemented in
http://hg.python.org/cpython/rev/efb5e6ab10f4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15167>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:10:11 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Jul 2012 20:10:11 +0000
Subject: [issue15167] Re-implement imp.get_magic() in pure Python
In-Reply-To: <1340567486.25.0.718240162307.issue15167@psf.upfronthosting.co.za>
Message-ID: <1341864611.41.0.603396336007.issue15167@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, finally in. Thanks for the hard work on this, Eric.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15167>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:10:51 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Jul 2012 20:10:51 +0000
Subject: [issue13959] Re-implement parts of imp in pure Python
In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za>
Message-ID: <1341864651.56.0.831519184337.issue13959@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Since the final issue is just a nicety, I am considering this issue closed.

----------
dependencies:  -Deprecate imp.find_module()/load_module()
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13959>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:14:48 2012
From: report at bugs.python.org (Greg Roodt)
Date: Mon, 09 Jul 2012 20:14:48 +0000
Subject: [issue1076515] shutil.move clobbers read-only files.
Message-ID: <1341864888.32.0.238642745808.issue1076515@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

I can add some more info to the docs if anybody feels they are required, but I think they are sufficient. It already mentions that it copies file contents and that the correct permissions are required.

This is mentioned in the docs for shutil.copyfile:

The destination location must be writable; otherwise, an OSError exception will be raised. If dst already exists, it will be replaced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1076515>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:23:48 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Jul 2012 20:23:48 +0000
Subject: [issue13959] Re-implement parts of imp in pure Python
In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za>
Message-ID: <1341865428.02.0.534734765963.issue13959@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13959>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:24:51 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 09 Jul 2012 20:24:51 +0000
Subject: [issue15308] IDLE - add an "Interrupt Execution" to shell menu
Message-ID: <1341865491.11.0.0892141451607.issue15308@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

Add an "Interrupt Execution" to the Shell menu, per issue13504, annoyance #3 - "PROBLEM: There?s no obvious way to stop a running program. (Don?t expect them to know Ctrl-C)"

----------
components: IDLE
keywords: easy
messages: 165122
nosy: serwy, terry.reedy
priority: low
severity: normal
status: open
title: IDLE - add an "Interrupt Execution" to shell menu
type: enhancement
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15308>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:27:29 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 09 Jul 2012 20:27:29 +0000
Subject: [issue15308] IDLE - add an "Interrupt Execution" to shell menu
In-Reply-To: <1341865491.11.0.0892141451607.issue15308@psf.upfronthosting.co.za>
Message-ID: <1341865649.12.0.952106490678.issue15308@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file26335/issue15308.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15308>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:27:59 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 09 Jul 2012 20:27:59 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1341865679.51.0.239770343355.issue13504@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
dependencies: +IDLE - add an "Interrupt Execution" to shell menu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:28:36 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 09 Jul 2012 20:28:36 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341865716.34.0.338135046528.issue13532@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ah, this indicates that we should support any buffer object...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:45:14 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Jul 2012 20:45:14 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341866714.49.0.704249949017.issue13532@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks Martin. I was thinking of adding special-casing inside the rpcproxy class, but the wrapping is pretty clean and clear. Works great in 3.3 Win7-64.

The 2.7 message 'expected a character buffer object' is technically correct*, but opaque, especially to beginners. I actually prefer the 3.x style message, except that 'str' should be expanded to 'string'. (We especially should not say 'character buffer object' until we test for exactly that.)

*My impression is that 2.7 unicode is not a character buffer object, but gets auto converted to str/bytes, which is.

On the technically correct front, bytearray in 2.7 is a character buffer object that .write() can write, but it is not a subclass of basestring. So the widened test in the followup patch
http://hg.python.org/cpython/rev/2993f566c82e
should be widened further.

-        if not isinstance(s, basestring):
-             raise TypeError('must be str, not ' + type(s).__name__)

+        if not isinstance(s, (basestring, bytearray)):
+             raise TypeError('must be string, not ' + type(s).__name__)

Are there any other 'character buffer' classes that should be included? What *is* the test that 2.7 .write() uses to determine what is such? Can it even be written in Python (rather than C)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Mon Jul  9 22:48:50 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 09 Jul 2012 20:48:50 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341866930.89.0.052825310408.issue13532@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm losing interest in this issue. It already got more attention than it deserves. Terry, feel free to make whatever change you consider desirable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Mon Jul  9 23:12:51 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 09 Jul 2012 21:12:51 +0000
Subject: [issue1757057] Unexpected "maximum recursion depth exceeded" in IDLE
	shell with objects that cannot be pickled
Message-ID: <1341868371.52.0.49154335103.issue1757057@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I think that issue13532 fixes this issue, as only strings are now pickled from the subprocess to the IDLE front-end for writing to stdout and stderr. This should address the pickling vulnerability.

I downloaded BeautifulSoup 3.0.4 and did not see this problem when using IDLE 2.7.1, and then against the latest dev version from the repo.

I am closing this issue as being out of date.

----------
nosy: +serwy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757057>
_______________________________________

From report at bugs.python.org  Mon Jul  9 23:15:30 2012
From: report at bugs.python.org (Alexis Metaireau)
Date: Mon, 09 Jul 2012 21:15:30 +0000
Subject: [issue1596321] KeyError at exit after 'import threading' in other
	thread
Message-ID: <1341868530.22.0.0460454361131.issue1596321@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <alexis at notmyidea.org>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1596321>
_______________________________________

From report at bugs.python.org  Mon Jul  9 23:21:54 2012
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Mon, 09 Jul 2012 21:21:54 +0000
Subject: [issue15309] buffer/memoryview slice assignment uses only memcpy
Message-ID: <1341868914.24.0.978840322443.issue15309@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com>:

thats broken for assigning overlaping regions, the memcpy docs explicitly state that memmove should be used in overlap cases

----------
messages: 165127
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: buffer/memoryview slice assignment uses only memcpy
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/issue15309>
_______________________________________

From report at bugs.python.org  Mon Jul  9 23:48:25 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 09 Jul 2012 21:48:25 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1341870505.74.0.250776663338.issue4832@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

issue4832_rev1.patch is a complete patch against 3.3.

This is also part of issue13504, "7) ANNOYANCE: It?s too easy to forget the .py extension when saving a file."

----------
stage:  -> patch review
Added file: http://bugs.python.org/file26336/issue4832_rev1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Mon Jul  9 23:48:36 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 09 Jul 2012 21:48:36 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1341870516.75.0.413495257954.issue13504@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
dependencies: +idle filename extension

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Mon Jul  9 23:58:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 21:58:16 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <3WWL5M3jlXzPCm@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4f891f44ec15 by Terry Jan Reedy in branch '2.7':
Issue 13532: Allow bytearrays to be written also.
http://hg.python.org/cpython/rev/4f891f44ec15

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Tue Jul 10 00:01:01 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Jul 2012 22:01:01 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341871261.73.0.00918003049314.issue13532@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I tested and pushed the change to allow bytestrings. If anyone is printing other character buffer objects in 2.7 with Idle, they can explicitly convert to str/bytes, patch run.py, and/or post here or on a new issue for further expansion. I am otherwise done with this too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Tue Jul 10 00:29:00 2012
From: report at bugs.python.org (Thomas Parslow)
Date: Mon, 09 Jul 2012 22:29:00 +0000
Subject: [issue11153] urllib2 basic auth parser handle unquoted realm in
	WWW-Authenticate header
In-Reply-To: <1297197679.85.0.254643170537.issue11153@psf.upfronthosting.co.za>
Message-ID: <1341872940.02.0.898164766072.issue11153@psf.upfronthosting.co.za>


Thomas Parslow <tom at almostobsolete.net> added the comment:

This is already fixed in the current code, unquoted realms are allowed with a warning.

----------
nosy: +almost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11153>
_______________________________________

From report at bugs.python.org  Tue Jul 10 00:40:50 2012
From: report at bugs.python.org (Thomas Parslow)
Date: Mon, 09 Jul 2012 22:40:50 +0000
Subject: [issue15310] urllib: Support for multiple WWW-Authenticate headers
	and/or multiple challenges per header
Message-ID: <1341873649.53.0.673715238265.issue15310@psf.upfronthosting.co.za>


New submission from Thomas Parslow <tom at almostobsolete.net>:

The HTTP spec specifies that the 401 (Unauthorized) response can be accompanied by multiple challenges, either as separate WWW-Authenticate headers or in a single WWW-Authenticate header separated by commas. The client should always pick the strongest supported which in the case of urllib is "digest". Unknown challenge types (for urllib that's anything but "basic" and "digest") should be ignored as long as there is a known one as well.

This is my first patch submission to cpython so please do point out anything I've done wrong! I'd like do more work on cpython so best to nip any bad habits in the bud!

In this patch I've re-written the parsing code to support this. I've tried to re-use existing code as much as possible, so I've based the new parser on the existing parse_http_list which I had to extend so that it can be used to parse single quoted strings. These single quoted strings are not valid for the HTTP spec but apparently they do appear in the wild and the existing implementation allowed them so I've continued to allow them. I've also kept the existing behaviour with regards to unquoted realm values, a warning is raised but otherwise they are allowed. The requirement of raising the warning added a slightly awkward bit to the code, but I assumed there was a good reason for that warning being there so I kept it in.

----------
components: Library (Lib)
files: urllib-multi-authenticate-challenges.patch
keywords: patch
messages: 165132
nosy: almost
priority: normal
severity: normal
status: open
title: urllib: Support for multiple WWW-Authenticate headers and/or multiple challenges per header
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file26337/urllib-multi-authenticate-challenges.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15310>
_______________________________________

From report at bugs.python.org  Tue Jul 10 00:41:58 2012
From: report at bugs.python.org (Thomas Parslow)
Date: Mon, 09 Jul 2012 22:41:58 +0000
Subject: [issue15310] urllib: Support for multiple WWW-Authenticate headers
	and/or multiple challenges per header
In-Reply-To: <1341873649.53.0.673715238265.issue15310@psf.upfronthosting.co.za>
Message-ID: <1341873718.93.0.308109254351.issue15310@psf.upfronthosting.co.za>


Thomas Parslow <tom at almostobsolete.net> added the comment:

I should mention, this fixes the same issue mentioned in #13323 but more comprehensively and for python 3 (the old issue refers to urllib2 in python2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15310>
_______________________________________

From report at bugs.python.org  Tue Jul 10 00:56:54 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 09 Jul 2012 22:56:54 +0000
Subject: [issue11153] urllib2 basic auth parser handle unquoted realm in
	WWW-Authenticate header
In-Reply-To: <1297197679.85.0.254643170537.issue11153@psf.upfronthosting.co.za>
Message-ID: <1341874614.41.0.855313306476.issue11153@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Yes, this is fixed as part of issue12541

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11153>
_______________________________________

From report at bugs.python.org  Tue Jul 10 01:29:18 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Jul 2012 23:29:18 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1341876558.66.0.53727569812.issue4832@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I tested with defaultextension='' on Windows and it works well. If no extension is entered (no '.' in name), .py or .txt is added for the .py/w and .txt filetype choices. If there is a . in the name, nothing is added. If one wants x.y.py, one must type the whole name. So typing x.pyw does not get .py added on top of it. This needs to be documented in the Idle help file.

Should the change only be made to 3.3, or also to 3.2/2.7? The old behavior of typing .py still works, so that does not break. Typing no . to get no extension (rare) will break unless one selects '*.* all files' (which one should do anyway as it is standard Windows behavior). I think uniform across versions is better so people who learn leaving out .py on 3.3 can also leave it out in future 2.7 and 3.2, which should come out about the same time as 3.3.0.

Whether just one or two or three versions, how do people used to the old (buggy in my opinion) behavior find out about the change. A splash line on startup "See help for new 'save as' behavior" ?

Anything I should know about *nix or mac behavior, at least for the doc? Ned, does this change work on macs?

----------
assignee:  -> terry.reedy
nosy: +ned.deily
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Tue Jul 10 01:49:43 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Jul 2012 23:49:43 +0000
Subject: [issue15308] IDLE - add an "Interrupt Execution" to shell menu
In-Reply-To: <1341865491.11.0.0892141451607.issue15308@psf.upfronthosting.co.za>
Message-ID: <1341877783.11.0.0579232427618.issue15308@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would like to broaden this to add other missing features to the menus. I have no need for this, but I would like history-next/prev added (to shell, as they only apply there). I never learned them because at first I did not know about them and now it is more bother to select options/configure/keys/scroll-down to find the key binding than to click/return. When I get a new program, I often look through the menus to see what is available, so if things are hidden, how do I find out about them?

Does IDle or tkinter or tk automatically add the key shortcuts?

I notice that some key bindings include lower and upper case, some do not. (History next/prev do not.) Is there a reason to not make all cntl/alt bindings case insensitive, and is there an issue for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15308>
_______________________________________

From report at bugs.python.org  Tue Jul 10 01:52:56 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Jul 2012 23:52:56 +0000
Subject: [issue15308] IDLE - add an "Interrupt Execution" to shell menu
In-Reply-To: <1341865491.11.0.0892141451607.issue15308@psf.upfronthosting.co.za>
Message-ID: <1341877976.12.0.0532360410566.issue15308@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I was thinking about #12387 about caps lock and shortcuts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15308>
_______________________________________

From report at bugs.python.org  Tue Jul 10 02:10:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Jul 2012 00:10:54 +0000
Subject: [issue15309] buffer/memoryview slice assignment uses only memcpy
In-Reply-To: <1341868914.24.0.978840322443.issue15309@psf.upfronthosting.co.za>
Message-ID: <1341879054.53.0.00995903714776.issue15309@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15309>
_______________________________________

From report at bugs.python.org  Tue Jul 10 02:40:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 00:40:20 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
Message-ID: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The Dev Guide says that it is "managed using the same process as is used for the main Python documentation":

http://docs.python.org/devguide/docquality.html#helping-with-the-developer-s-guide

However, it looks the Dev Guide might not be on the same schedule of getting updated once a day as it says for the main Python documentation:

http://docs.python.org/devguide/docquality.html#helping-with-documentation

It would help to say something about the mechanism by which the Dev Guide gets updated if that mechanism is different from the main Python documentation.

----------
components: Devguide
keywords: easy
messages: 165138
nosy: cjerdonek, ezio.melotti
priority: normal
severity: normal
status: open
title: Developer Guide doesn't get updated once a day
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Tue Jul 10 02:43:08 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 10 Jul 2012 00:43:08 +0000
Subject: [issue15310] urllib: Support for multiple WWW-Authenticate headers
	and/or multiple challenges per header
In-Reply-To: <1341873649.53.0.673715238265.issue15310@psf.upfronthosting.co.za>
Message-ID: <1341880988.65.0.0952857637796.issue15310@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15310>
_______________________________________

From report at bugs.python.org  Tue Jul 10 03:37:37 2012
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 10 Jul 2012 01:37:37 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>
Message-ID: <1341884257.64.0.838265186202.issue15298@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

looks like the module can be put into $builddir/`cat pybuilddir.txt`. However pybuilddir.txt is written/computed by the just built python. So either

 - implement distutils.util.get_platform in configure.ac

 - or write a temporary pybuilddir.txt, call the just built
   python -c 'print("build/lib.%s-%" % (distutils.util.get_platform(), sys.version[:3]))' to write the final pybuilddir.txt, move the _sysconfigdata.py to this location.
   and remove the pybuilddir.txt writing in setup.py

----------
stage: needs patch -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15298>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:07:23 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 Jul 2012 02:07:23 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1341886043.17.0.439932581838.issue15311@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think there's an hook the rebuilds the devguide whenever someone pushes something.

----------
nosy: +georg.brandl, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:09:51 2012
From: report at bugs.python.org (Julius)
Date: Tue, 10 Jul 2012 02:09:51 +0000
Subject: [issue15312] Serial library not found
Message-ID: <1341886191.07.0.139059548156.issue15312@psf.upfronthosting.co.za>


New submission from Julius <julius.miller at bravo-zulu.us>:

I'm running ver 2.7 and added the serial library from source forge. here is the error I get:

Traceback (most recent call last):
  File "C:\Python27\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py", line 326, in RunScript
    exec codeObject in __main__.__dict__
  File "C:\Documents and Settings\Administrator\My Documents\WTF.py", line 3, in <module>
    import serial
ImportError: No module named serial

here is my code:
# Echo client program
import socket
import serial

HOST = '216.240.155.229'    # The remote host
PORT = 9090              # The same port as used by the server
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
ser = serial.Serial('USB0', timeout=3)
x = 0
#while x < 5:
while True:
    msg = ser.readline()
    s.send(msg)
    x += 1
s.close()

----------
components: Extension Modules, IDLE, Windows
messages: 165141
nosy: JuliusMiller
priority: normal
severity: normal
status: open
title: Serial library not found
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15312>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:10:05 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 Jul 2012 02:10:05 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>
Message-ID: <1341886205.44.0.480238938349.issue15302@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Do you want to propose a patch?
regrtest has no tests, so switching to argparse might cause more harm than good right now.

----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:21:34 2012
From: report at bugs.python.org (Aaron)
Date: Tue, 10 Jul 2012 02:21:34 +0000
Subject: =?utf-8?q?=5Bissue4640=5D_optparse_doesn=E2=80=99t_disallow_adding_one-da?=
	=?utf-8?b?c2ggbG9uZyBvcHRpb25zICjigJwtb3B0aW9u4oCdKQ==?=
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <1341886894.27.0.162690091532.issue4640@psf.upfronthosting.co.za>


Aaron <hacman0 at gmail.com> added the comment:

I came across this bug report and was unable to reproduce the described behavior.  I wrote a few test cases demonstrating that the behavior is indeed correct.  It passes both against 2.5.2 (the version described in the report) and the lastest 2.7.

The relevant code is line 602 of optparse.py in the function Option._set_opt_strings().

I believe this bug can be closed.

----------
keywords: +patch
nosy: +hac.man
Added file: http://bugs.python.org/file26338/test_optparse.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4640>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:21:45 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 Jul 2012 02:21:45 +0000
Subject: [issue15312] Serial library not found
In-Reply-To: <1341886191.07.0.139059548156.issue15312@psf.upfronthosting.co.za>
Message-ID: <1341886905.64.0.389150373659.issue15312@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This bug tracker is for reporting CPython bugs, so it's not the right place where to ask this kind of questions.
Anyway make sure that the "serial" module is in a directory that Python can see, e.g. the same dir where you have your script.

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: resource usage -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15312>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:27:04 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 02:27:04 +0000
Subject: [issue15313] IDLE - remove all bare excepts
Message-ID: <1341887224.3.0.873205918404.issue15313@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
components: IDLE
nosy: serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - remove all bare excepts
type: enhancement
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15313>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:29:31 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 02:29:31 +0000
Subject: [issue15313] IDLE - remove all bare excepts
Message-ID: <1341887371.61.0.0302814737095.issue15313@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

There are a lot of bare exceptions in IDLE. Here's the output of "grep -n 'except:' *.py"

AutoComplete.py:184:        except:
AutoComplete.py:209:                    except:
Debugger.py:172:                except:
Debugger.py:344:            except:
EditorWindow.py:999:            except:
ObjectBrowser.py:38:        except:
ObjectBrowser.py:100:        except:
PyShell.py:133:        except: # but debugger may not be active right now....
PyShell.py:154:        except:
PyShell.py:161:        except:
PyShell.py:176:            except:
PyShell.py:433:            except:
PyShell.py:742:        except:
PyShell.py:869:        except:
PyShell.py:1043:        except:
PyShell.py:1096:        except:
PyShell.py:1193:        except:
PyShell.py:1214:        except:
PyShell.py:1245:        except:
rpc.py:106:        except:
rpc.py:206:        except:
run.py:88:    except:
run.py:120:        except:
run.py:125:            except:
run.py:248:        except:
run.py:332:        except:
SearchEngine.py:72:            except:
StackViewer.py:66:        except:
WindowList.py:47:            except:


Slowly, these exceptions should be refined to include the exact exception being caught.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15313>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:38:23 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 Jul 2012 02:38:23 +0000
Subject: [issue15167] Re-implement imp.get_magic() in pure Python
In-Reply-To: <1340567486.25.0.718240162307.issue15167@psf.upfronthosting.co.za>
Message-ID: <1341887903.69.0.675231718495.issue15167@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Yay!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15167>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:44:17 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 02:44:17 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1341876558.66.0.53727569812.issue4832@psf.upfronthosting.co.za>
Message-ID: <4FFB96FD.1030303@gmail.com>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Your description applied to the behavior on Ubuntu 11.04.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:48:03 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 Jul 2012 02:48:03 +0000
Subject: [issue13959] Re-implement parts of imp in pure Python
In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za>
Message-ID: <1341888483.86.0.614080330889.issue13959@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

hurray!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13959>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:50:28 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 02:50:28 +0000
Subject: [issue15308] IDLE - add an "Interrupt Execution" to shell menu
In-Reply-To: <1341877783.11.0.0579232427618.issue15308@psf.upfronthosting.co.za>
Message-ID: <4FFB9870.5020508@gmail.com>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I'm ok with broadening the scope of this issue to include other items. 
If we decide to deprecate running IDLE without a subprocess 
(http://mail.python.org/pipermail/idle-dev/2012-June/003124.html), then 
the history-next/prev would fit nicely under the Shell menu.
> Does IDle or tkinter or tk automatically add the key shortcuts?
IDLE adds the key shortcuts. It's broken for extensions if those 
shortcuts are changed. See Issue6092.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15308>
_______________________________________

From report at bugs.python.org  Tue Jul 10 04:59:27 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 02:59:27 +0000
Subject: [issue15308] IDLE - add an "Interrupt Execution" to shell menu
In-Reply-To: <1341865491.11.0.0892141451607.issue15308@psf.upfronthosting.co.za>
Message-ID: <1341889167.28.0.710554540477.issue15308@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The help.txt file needs to be modified as well. See interrupt_execution.patch.

----------
Added file: http://bugs.python.org/file26339/interrupt_execution.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15308>
_______________________________________

From report at bugs.python.org  Tue Jul 10 05:30:36 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 03:30:36 +0000
Subject: [issue7883] CallTips.py _find_constructor does not work
In-Reply-To: <1265631103.87.0.399117397925.issue7883@psf.upfronthosting.co.za>
Message-ID: <1341891036.42.0.0648442024663.issue7883@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Issue12510 fixes the issues listed here. I am leaving this issue open for discussing the test provided by Bernt.

----------
nosy: +terry.reedy
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7883>
_______________________________________

From report at bugs.python.org  Tue Jul 10 05:50:15 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 03:50:15 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>
Message-ID: <1341892215.27.0.104268992597.issue15302@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Sure, if someone is open to reviewing it.

The parsing code doesn't seem to be doing anything too fancy right now.  I can decouple the parsing code and begin adding tests around parts that may need it more.  Increasing coverage will be easier going forward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Tue Jul 10 05:50:37 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Jul 2012 03:50:37 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
Message-ID: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

There's some lingering weirdness in runpy due to its reliance on pkgutil's import emulation (see #15272).

For 3.3, I'd like to explicitly switch runpy over to using importlib. This was supposed to happen automatically, but the relevant API is "importlib.find_loader" rather than the "imp.get_loader" that runpy is currently looking for.

----------
assignee: ncoghlan
messages: 165153
nosy: georg.brandl, ncoghlan
priority: high
severity: normal
stage: needs patch
status: open
title: Use importlib instead of pkgutil in runpy
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15314>
_______________________________________

From report at bugs.python.org  Tue Jul 10 05:52:37 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 Jul 2012 03:52:37 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1341892357.27.0.566032584401.issue4832@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

As usual, there seem to be small but significant differences among the implementations.  Testing with the three OS X Tk implementations shows that currently:
1. Aqua Tk 8.5 and Aqua Tk 8.4 do not supply a default extension
when saving.  With patch issue4832.diff applied, they still incorrectly do not supply a default extension. (Note, Aqua Tk's do not supply a file type filter in the Save File dialog box.)
2. X11 Tk 8.5 behaves like other Unix X11 Tk's: a default based on the selected File Type filter is used, i.e. .py for "Python files, .txt for "Text file".  Applying the patch does not change that correct behavior.

I tested a variation of Guilherme's patch which supplies a defaultextension of '.py' but only for OS X (rather than Windows).  With that patch (issue4832_rev2.patch):
1. Aqua Tk 8.5 now correctly supplies a default extension of '.py' on saves if the user does not enter an extension as part of the file name.
2. Aqua Tk 8.4 behavior is unchanged: it still incorrectly does not supply an extension if the user does not.  I don't see how to fix that but the use of Aqua Tk 8.4 is diminishing.
3. X11 Tk 8.5 behavior is unchanged: it still correctly supplies a default based on the selected File Type.

Since Aqua Tk 8.5 is the major Tk for OS X these days (it has been the system default since OS X 10.6) and the patch improves things for it, I'd like to see this go in.  I did test it on a Debian Linux X11.  It should behave the same on Windows as Roger's previous patch but it would be good to test it again.

As far as documentation changes, I don't see the need to have anything more than the usual IDLE/NEWS.txt file entry.

----------
Added file: http://bugs.python.org/file26340/issue4832_rev2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Tue Jul 10 05:54:31 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Jul 2012 03:54:31 +0000
Subject: [issue15272] pkgutil.find_loader accepts invalid module names
In-Reply-To: <1341656387.47.0.245292094882.issue15272@psf.upfronthosting.co.za>
Message-ID: <1341892471.22.0.606701133761.issue15272@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I've taken 3.2 and 2.7 off the list - no doubt someone, somewhere is relying on this particular piece of missing input validation, so it's not worth risking breakage in a point release.

I think it's worth fixing for 3.3, though.

----------
nosy: +georg.brandl
stage:  -> needs patch
type:  -> behavior
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15272>
_______________________________________

From report at bugs.python.org  Tue Jul 10 05:54:43 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 03:54:43 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1341892483.0.0.899026177171.issue15311@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

This commit from 2 days ago--

http://hg.python.org/devguide/rev/d1958a94d0ff

doesn't seem to be reflected in the published version as of yet:

http://docs.python.org/devguide/docquality.html

So maybe there is just a problem with the hook.  If it does get rebuilt right away, that would be worth mentioning, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Tue Jul 10 06:17:06 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Jul 2012 04:17:06 +0000
Subject: [issue15313] IDLE - remove all bare excepts
In-Reply-To: <1341887371.61.0.0302814737095.issue15313@psf.upfronthosting.co.za>
Message-ID: <1341893826.72.0.616115060955.issue15313@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

And possibly change the except clause. The except clause at PyShell 1245 was 'pass', which masked the issue of #13532 and was changed to 'raise' to effectively remove the try: except: to make the unknown problem more visible. It should perhaps be really removed if and when all calls to PyShell.write(s) are properly guarded to make sure 's' is writable.

----------
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15313>
_______________________________________

From report at bugs.python.org  Tue Jul 10 06:35:18 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 Jul 2012 04:35:18 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1341894918.3.0.590991155674.issue15311@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The web update hook is broken at the moment:

http://article.gmane.org/gmane.comp.python.devel/134057

----------
nosy: +ned.deily
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Tue Jul 10 06:52:03 2012
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 10 Jul 2012 04:52:03 +0000
Subject: [issue15315] Can't build Python extension with mingw32 on Windows
Message-ID: <1341895923.16.0.599445307566.issue15315@psf.upfronthosting.co.za>


New submission from Craig McQueen <python at craig.mcqueen.id.au>:

I'm trying this with my 'cobs' Python package:

    c:\Python33\python.exe setup.py build --compiler=mingw32 bdist_msi

With Python 3.3 beta, it fails with an exception:

    ValueError: Unknown MS Compiler version 1600

It works with Python 3.2.

----------
components: Extension Modules
messages: 165159
nosy: cmcqueen1975
priority: normal
severity: normal
status: open
title: Can't build Python extension with mingw32 on Windows
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15315>
_______________________________________

From report at bugs.python.org  Tue Jul 10 07:07:33 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Jul 2012 05:07:33 +0000
Subject: [issue15315] Can't build Python extension with mingw32 on Windows
In-Reply-To: <1341895923.16.0.599445307566.issue15315@psf.upfronthosting.co.za>
Message-ID: <3WWWcg3B2lzNyZ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset eee92b9ac4ad by Martin v. L?wis in branch 'default':
Issue #15315: Support VS 2010 in distutils cygwincompiler.
http://hg.python.org/cpython/rev/eee92b9ac4ad

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15315>
_______________________________________

From report at bugs.python.org  Tue Jul 10 07:08:23 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 10 Jul 2012 05:08:23 +0000
Subject: [issue15315] Can't build Python extension with mingw32 on Windows
In-Reply-To: <1341895923.16.0.599445307566.issue15315@psf.upfronthosting.co.za>
Message-ID: <1341896903.38.0.461415925042.issue15315@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This should now be fixed in the repository. It would be good if you could manually apply the change to your installation, and report whether it works.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15315>
_______________________________________

From report at bugs.python.org  Tue Jul 10 07:18:47 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 05:18:47 +0000
Subject: [issue15313] IDLE - remove all bare excepts
In-Reply-To: <1341887371.61.0.0302814737095.issue15313@psf.upfronthosting.co.za>
Message-ID: <1341897527.28.0.473543515286.issue15313@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Line 1245 is part of this code (in time, these line numbers will change.)

        try:
            self.text.mark_gravity("iomark", "right")
            OutputWindow.write(self, s, tags, "iomark")
            self.text.mark_gravity("iomark", "left")
        except:
            raise ###pass  # ### 11Aug07 KBK if we are expecting exceptions
                           # let's find out what they are and be specific.
   

The delegator chain that sits between OutputWindow.write and the Tkinter text.insert method can raise any error. (The ColorDelegator would raise a TypeError when "s" was not a string). I'd rather not replace this with "except Exception:" since the delegators should catch their own errors. 

I suggest removing this try/catch block.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15313>
_______________________________________

From report at bugs.python.org  Tue Jul 10 07:20:38 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 05:20:38 +0000
Subject: [issue15313] IDLE - remove all bare excepts
In-Reply-To: <1341887371.61.0.0302814737095.issue15313@psf.upfronthosting.co.za>
Message-ID: <1341897638.85.0.67091698794.issue15313@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Also, issue13582 will become relevant on Windows since modifying the bare excepts may let uncaught exceptions be written to stderr, causing IDLE to crash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15313>
_______________________________________

From report at bugs.python.org  Tue Jul 10 07:21:02 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 Jul 2012 05:21:02 +0000
Subject: [issue15242] PyImport_GetMagicTag() should use the same const char *
	as sys.implementation.cache_tag
In-Reply-To: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>
Message-ID: <1341897662.37.0.886855126008.issue15242@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15242>
_______________________________________

From report at bugs.python.org  Tue Jul 10 07:25:54 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 Jul 2012 05:25:54 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1341897954.16.0.492274374275.issue13475@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Your plan sounds good, Nick.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Tue Jul 10 07:26:59 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 05:26:59 +0000
Subject: [issue13657] IDLE doesn't support sys.ps1 and sys.ps2.
In-Reply-To: <1324640742.58.0.860347532783.issue13657@psf.upfronthosting.co.za>
Message-ID: <1341898019.53.0.456786834174.issue13657@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

For reference, IDLE-DEV is discussing the prompt: http://mail.python.org/pipermail/idle-dev/2012-June/003129.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13657>
_______________________________________

From report at bugs.python.org  Tue Jul 10 07:39:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 05:39:18 +0000
Subject: [issue15316] runpy swallows ImportError information with relative
	imports
Message-ID: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

With the following package directory structure--

foo/
    __init__.py
    __main__.py
        from foo import bar
    bar.py
        print('***')
        raise ImportError('test...')

Running--

$ ./python.exe -m foo

Yields--

***
Traceback (most recent call last):
  File ".../python/cpython/cpython/Lib/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File ".../python/cpython/cpython/Lib/runpy.py", line 75, in _run_code
    exec(code, run_globals)
  File "./foo/__main__.py", line 1, in <module>
    from foo import bar
ImportError: cannot import name bar
$

The exception text gets swallowed.

Changing the relative import "from foo import bar" to "import foo.bar" does show the exception text.

----------
components: Library (Lib)
messages: 165166
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: runpy swallows ImportError information with relative imports
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15316>
_______________________________________

From report at bugs.python.org  Tue Jul 10 08:37:10 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 10 Jul 2012 06:37:10 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341892215.27.0.104268992597.issue15302@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOSgL=AVgFWcJPKDZ5-7KDLKoJ3=1QVxR0c8SjTgSrgJJA@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Mon, Jul 9, 2012 at 8:50 PM, Chris Jerdonek <report at bugs.python.org> wrote:>
> Sure, if someone is open to reviewing it.

Yes, please go ahead. I can review it and I believe others should be
able to as well. As a first short,  I think, it may be a good idea to
just replacing the short opt and long opt handling behavior and not
dwell too much into argparse features (just to ascertain that we are
not going through a new code-path. this I believe, may help assuage
Ezio's concern a bit  that regrtest.py lacks test and changes to them
should be carefully done at this point in time in release).  Or the
other idea is you may submit the patch and if it is significant, it
may go in early in 3.4

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Tue Jul 10 08:40:13 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Jul 2012 06:40:13 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341902413.95.0.0183864428853.issue13532@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> +        sys.stdin = self.console = _RPCFile(self.get_remote_proxy("stdin"))

write to sys.stdin?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Tue Jul 10 08:45:31 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 06:45:31 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>
Message-ID: <1341902731.18.0.457049358217.issue15302@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks, Senthil.  That is my plan.  I should be able to have code with tests in no later than a week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Tue Jul 10 09:02:32 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 07:02:32 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1341903752.67.0.43667102568.issue15311@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Patch attached.

I also added a note about building the Dev Guide documentation.  Unlike the main Python documentation, `make html` for the Dev Guide doesn't seem to install Sphinx automatically.

----------
keywords: +patch
Added file: http://bugs.python.org/file26341/issue-15311-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Tue Jul 10 09:04:17 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 07:04:17 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1341903857.21.0.36182281057.issue15311@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Tue Jul 10 09:05:06 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 Jul 2012 07:05:06 +0000
Subject: [issue15310] urllib: Support for multiple WWW-Authenticate headers
	and/or multiple challenges per header
In-Reply-To: <1341873649.53.0.673715238265.issue15310@psf.upfronthosting.co.za>
Message-ID: <1341903906.23.0.203090959945.issue15310@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/issue15310>
_______________________________________

From report at bugs.python.org  Tue Jul 10 09:21:17 2012
From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=)
Date: Tue, 10 Jul 2012 07:21:17 +0000
Subject: [issue15317] Source installation sets incorrect permissions for
	Grammar3.2.3.final.0.pickle
Message-ID: <1341904877.85.0.287783743443.issue15317@psf.upfronthosting.co.za>


New submission from Tomi Pievil?inen <tomi.pievilainen+launchpad at iki.fi>:

/usr/local/lib/python3.2/lib2to3/Grammar3.2.3.final.0.pickle is readable only by root after installing with make install from the source package. This makes at least installing distribute fail, and thus makes virtualenv, tox etc. unusable.

----------
components: Installation
messages: 165171
nosy: tpievila
priority: normal
severity: normal
status: open
title: Source installation sets incorrect permissions for Grammar3.2.3.final.0.pickle
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15317>
_______________________________________

From report at bugs.python.org  Tue Jul 10 09:25:28 2012
From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=)
Date: Tue, 10 Jul 2012 07:25:28 +0000
Subject: [issue15317] Source installation sets incorrect permissions for
	Grammar3.2.3.final.0.pickle
In-Reply-To: <1341904877.85.0.287783743443.issue15317@psf.upfronthosting.co.za>
Message-ID: <1341905128.52.0.0210888513009.issue15317@psf.upfronthosting.co.za>


Tomi Pievil?inen <tomi.pievilainen+launchpad at iki.fi> added the comment:

Also PatternGrammar3.2.3.final.0.pickle is missing the read permissions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15317>
_______________________________________

From report at bugs.python.org  Tue Jul 10 09:36:14 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 07:36:14 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>
Message-ID: <1341905774.3.0.30494205642.issue15302@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

By the way, issue 15300 has a related patch that is ready to review today.

Assuming that one is okay, it would make sense to commit first because it overlaps with the changes I'll be doing here.

Issue 15305 is another related issue (also overlapping) that is probably worth discussing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Tue Jul 10 09:54:07 2012
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 10 Jul 2012 07:54:07 +0000
Subject: [issue15315] Can't build Python extension with mingw32 on Windows
In-Reply-To: <1341895923.16.0.599445307566.issue15315@psf.upfronthosting.co.za>
Message-ID: <1341906847.96.0.435968107374.issue15315@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

That's definitely an improvement. It gets further, but on my PC, the compile fails:

...
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: cannot find -lmsvcr100
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

I'll have to see if I can get the required library I guess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15315>
_______________________________________

From report at bugs.python.org  Tue Jul 10 09:54:49 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 10 Jul 2012 07:54:49 +0000
Subject: [issue15316] runpy swallows ImportError information with relative
	imports
In-Reply-To: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za>
Message-ID: <1341906889.51.0.778425540151.issue15316@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Looks very similar to issue15111.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> Wrong ImportError message with importlib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15316>
_______________________________________

From report at bugs.python.org  Tue Jul 10 09:57:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 07:57:41 +0000
Subject: [issue15111] Wrong ImportError message with importlib
In-Reply-To: <1340151446.59.0.121813331775.issue15111@psf.upfronthosting.co.za>
Message-ID: <1341907061.53.0.676012261422.issue15111@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15111>
_______________________________________

From report at bugs.python.org  Tue Jul 10 10:13:00 2012
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 10 Jul 2012 08:13:00 +0000
Subject: [issue15315] Can't build Python extension with mingw32 on Windows
In-Reply-To: <1341895923.16.0.599445307566.issue15315@psf.upfronthosting.co.za>
Message-ID: <1341907980.16.0.550084974714.issue15315@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

I downloaded the latest MinGW, and now it tells me:

...
c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\Python33\include -IC:\Python33\PC -c python3/src/_cobs_ext.c -o bui
ld\temp.win32-3.3\Release\python3\src\_cobs_ext.o
cc1.exe: error: unrecognized command line option '-mno-cygwin'
error: command 'gcc' failed with exit status 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15315>
_______________________________________

From report at bugs.python.org  Tue Jul 10 10:17:20 2012
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 10 Jul 2012 08:17:20 +0000
Subject: [issue15315] Can't build Python extension with mingw32 on Windows
In-Reply-To: <1341895923.16.0.599445307566.issue15315@psf.upfronthosting.co.za>
Message-ID: <1341908240.08.0.581015420684.issue15315@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

It sounds as though the option '-mno-cygwin' is related to issue #12641.

Does that mean I need to find a version of MinGW that is old enough to support the option '-mno-cygwin', but new enough to include a library for msvcr100?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15315>
_______________________________________

From report at bugs.python.org  Tue Jul 10 10:20:16 2012
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 10 Jul 2012 08:20:16 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1341908416.1.0.814160117061.issue12641@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

I've come across this issue when trying to build extensions for Python 3.3 on Windows, needing a recent enough MinGW to provide a library for msvcr100. See issue #15315.

----------
nosy: +cmcqueen1975

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Jul 10 11:09:45 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 10 Jul 2012 09:09:45 +0000
Subject: [issue15315] Can't build Python extension with mingw32 on Windows
In-Reply-To: <1341895923.16.0.599445307566.issue15315@psf.upfronthosting.co.za>
Message-ID: <1341911385.19.0.616988244707.issue15315@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm not a Cygwin user myself, so it would be good if you could figure this out somehow. Feel free to ask on Cygwin lists how this is supposed to work. Our requirement is that the resulting pyd needs to link with msvcr100.dll. It may well be that *no* version of Cygwin ever supported this, in which case we should drop Cygwin support from Python 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15315>
_______________________________________

From report at bugs.python.org  Tue Jul 10 11:17:24 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 10 Jul 2012 09:17:24 +0000
Subject: [issue15309] buffer/memoryview slice assignment uses only memcpy
In-Reply-To: <1341868914.24.0.978840322443.issue15309@psf.upfronthosting.co.za>
Message-ID: <1341911844.74.0.967593774202.issue15309@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Could you please state the Python version and line numbers in
memoryobject.c?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15309>
_______________________________________

From report at bugs.python.org  Tue Jul 10 11:30:29 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 10 Jul 2012 09:30:29 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1341912629.2.0.266673250466.issue12641@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have gcc 3.4.4 in my cygwin installation, and it still needs the -mno-cygwin option, else the resulting binary will link with cygwin1.dll (which is undesired).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Jul 10 12:11:18 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 10 Jul 2012 10:11:18 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1341915078.62.0.283231291833.issue12641@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I just installed the cygwin gcc4 package; this gives me gcc 4.5.3. In this version, -mno-cygwin is still recognized, and gives this error message:

gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler.

So it seems that removing the -mno-cygwin flag is definitely incorrect, as it will result in a cygwin binary.

I then installed the mingw-gcc-core package, which gave me the utility  i686-pc-mingw32-gcc, which indeed is able to create a (nearly) correct binary.

So I think we should check whether i686-pc-mingw32-gcc exists in the path, and if so, use it (without a -mno-cygwin flag). If it doesn't exist, we should continue to use gcc -mno-cygwin.

My remaining concern with i686-pc-mingw32-gcc is that it still links with msvcrt.dll in addition to linking with msvcrXY.dll; this is incorrect.

There is another concern that this applies to 32-bit mode only; in 64-bit mode,  i686-w64-mingw32-gcc should be used. However, this is issue 4709.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Jul 10 12:14:23 2012
From: report at bugs.python.org (Tim Golden)
Date: Tue, 10 Jul 2012 10:14:23 +0000
Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility
In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za>
Message-ID: <1341915263.03.0.268339247759.issue15267@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

I can confirm that this isn't a problem for 3.x. No-one's listed in the experts list for the httplib module but Senthil appears to be the de factor maintainer so I've added him to the call for his opinion. My feeling would be to do the simplest thing possible and add AttributeError to the list of trapped exceptions.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15267>
_______________________________________

From report at bugs.python.org  Tue Jul 10 12:19:13 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 10 Jul 2012 10:19:13 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1341915553.92.0.524720140703.issue12641@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The 64-bit compiler is actually called  x86_64-w64-mingw32-gcc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Jul 10 14:11:24 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Jul 2012 12:11:24 +0000
Subject: [issue15300] test directory doubly-nested running tests with
	-j/--multiprocess
In-Reply-To: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>
Message-ID: <1341922284.19.0.75775207304.issue15300@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't really like the "pre-parsed option" hack. Can't we think of something simpler? For example, why would the child be involved, rather than simply the parent setting the right cwd?

Also, I don't think there's any point in _OPTION_CWD_PARENT_DIR. Just hard-code the literal, it will be more readable.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15300>
_______________________________________

From report at bugs.python.org  Tue Jul 10 15:08:00 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Jul 2012 13:08:00 +0000
Subject: [issue15111] Wrong ImportError message with importlib
In-Reply-To: <1340151446.59.0.121813331775.issue15111@psf.upfronthosting.co.za>
Message-ID: <1341925680.4.0.472277266343.issue15111@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

That "cannot import name" message seems to only come from Python/ceval.c:import_from() which raises that exception when an AttributeError is raised by an 'import from' statement (I think). This happens when an 'import from' asks for a name on the package/module that doesn't exist.

Looking at importlib, I found the code that captures the ImportErrorof a submodule, which allows the import to continue and then fail as an AttributeError at the bytecode level. I'm running the test suite now with that try/except removed to see if this was just a mis-interpretation on my part of how to handle this situation. As of right now the only failures I have continue my belief that import * is evil.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15111>
_______________________________________

From report at bugs.python.org  Tue Jul 10 15:11:14 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Jul 2012 13:11:14 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <1341925874.73.0.214506546513.issue15314@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Ooh, first "customer" of importlib.find_loader()! Obviously if the API doesn't work for you let me know since it's a 3.3 addition and can be tweaked to meet your needs.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15314>
_______________________________________

From report at bugs.python.org  Tue Jul 10 16:05:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Jul 2012 14:05:09 +0000
Subject: [issue15111] Wrong ImportError message with importlib
In-Reply-To: <1340151446.59.0.121813331775.issue15111@psf.upfronthosting.co.za>
Message-ID: <3WWlY01kBBzN98@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset dc18a2a66d16 by Brett Cannon in branch 'default':
Issue #15111: When a module was imported using a 'from import'
http://hg.python.org/cpython/rev/dc18a2a66d16

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15111>
_______________________________________

From report at bugs.python.org  Tue Jul 10 16:05:35 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Jul 2012 14:05:35 +0000
Subject: [issue15111] Wrong ImportError message with importlib
In-Reply-To: <1340151446.59.0.121813331775.issue15111@psf.upfronthosting.co.za>
Message-ID: <1341929135.79.0.680328294066.issue15111@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15111>
_______________________________________

From report at bugs.python.org  Tue Jul 10 16:10:02 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 14:10:02 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341929402.0.0.555795205797.issue13532@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

sys.stdin has a write method, but it should raise "io.UnsupportedOperation: not writable" when passed a string. It looks like IDLE has allowed writes to stdin even before Martin's patch. I'll open a separate issue for this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Tue Jul 10 16:13:24 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 14:13:24 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
Message-ID: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

This is a follow-up to issue13532 which fixed problems with IDLE's sys.stdout and sys.stderr implementation.

Presently, sys.stdin has a write method, but does not raise "io.UnsupportedOperation: not writable" when passed a string. Instead, it writes to the IDLE shell.

----------
components: IDLE
messages: 165190
nosy: serwy, storchaka, terry.reedy
priority: low
severity: normal
status: open
title: IDLE - sys.stdin is writeable
type: behavior
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Tue Jul 10 16:38:02 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 14:38:02 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341931082.27.0.57273465677.issue13532@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Running "input" from IDLE now raises an error. Attached is a fix to _RPCFile to allow readline (and isatty) to function properly.

----------
priority: normal -> high
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file26342/stdin_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Tue Jul 10 16:48:09 2012
From: report at bugs.python.org (samwyse)
Date: Tue, 10 Jul 2012 14:48:09 +0000
Subject: [issue15289] Adding __getitem__ as a class method doesn't work as
	expected
In-Reply-To: <1341690477.89.0.147882600288.issue15289@psf.upfronthosting.co.za>
Message-ID: <1341931689.67.0.108346440697.issue15289@psf.upfronthosting.co.za>


samwyse <samwyse at gmail.com> added the comment:

Thanks, Eric.  Based on what you said, I was able to get the desired behavior by creating a metaclass.

----------
Added file: http://bugs.python.org/file26343/Issue15289.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15289>
_______________________________________

From report at bugs.python.org  Tue Jul 10 17:10:13 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 15:10:13 +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: <1341933013.42.0.198356072592.issue12967@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Issue13532 has an applied patch (422242dbce30) for the subprocess that makes the stdout, stderr, and stdin inherit from io.TextIOBase. This includes the "errors" attribute, albeit set to ''.

The fix does not apply when running IDLE without a subprocess, so the .errors attribute will still be missing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12967>
_______________________________________

From report at bugs.python.org  Tue Jul 10 17:36:51 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Jul 2012 15:36:51 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341934611.21.0.277099810786.issue13532@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

>>> sys.stdin.readable()
False
>>> sys.stdout.writable()
False

I think the issue is far from a solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Tue Jul 10 18:15:07 2012
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Cruz?=)
Date: Tue, 10 Jul 2012 16:15:07 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1341936907.28.0.113674432991.issue1346874@psf.upfronthosting.co.za>


Andr? Cruz <andre at cabine.org> added the comment:

Can anyone confirm what is missing for this patch to be committed?

Is it just test and documentation changes or is something wrong with the code changes as well?

----------
nosy: +edevil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346874>
_______________________________________

From report at bugs.python.org  Tue Jul 10 18:20:50 2012
From: report at bugs.python.org (Carl Nobile)
Date: Tue, 10 Jul 2012 16:20:50 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
In-Reply-To: <1341936907.28.0.113674432991.issue1346874@psf.upfronthosting.co.za>
Message-ID: <CAGQqDQ+gMNKfbMAJLh5P=griYuH0NP1pEJqXaxgTV0XGe_6PjA@mail.gmail.com>


Carl Nobile <carl.nobile at gmail.com> added the comment:

I was told some time ago that it was documentation changes. And, if I
remember correctly CONTINUE (100) was not ignored, it was actually broken.
Data was being read from stdin when a CONTINUE was received and this should
never happen based on RFC 2616, because there will never be any data to
read.

~Carl

On Tue, Jul 10, 2012 at 12:15 PM, Andr? Cruz <report at bugs.python.org> wrote:

>
> Andr? Cruz <andre at cabine.org> added the comment:
>
> Can anyone confirm what is missing for this patch to be committed?
>
> Is it just test and documentation changes or is something wrong with the
> code changes as well?
>
> ----------
> nosy: +edevil
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1346874>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346874>
_______________________________________

From report at bugs.python.org  Tue Jul 10 20:38:57 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 10 Jul 2012 18:38:57 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1341945537.01.0.597943345404.issue13532@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Folks: one issue at a time - pretty pretty please.

This issue was "In IDLE, sys.stdout and sys.stderr can write any pickleable object". Will anybody dispute that this issue is fixed?

Roger: please create a new issue for input being broken now. Your patch "shouldn't" be necessary, as __getattr__ should deal with this.

Serhiy: please create a new issue for readable and writable returning an incorrect result.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Tue Jul 10 21:28:48 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 19:28:48 +0000
Subject: [issue15319] IDLE - input() is broken.
Message-ID: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

Per Martin's request in msg165197, this issue has been separated from Issue13532.

The newly introduced _RPCFile object in run.py (422242dbce30) inherits from io.TextIOBase which has "readline" as one of its methods. As a result, IDLE's internal call readline are not handled properly.

The stdin_fix.patch provides a fix for readline and isatty.

----------
components: IDLE
files: stdin_fix.patch
keywords: patch
messages: 165198
nosy: loewis, ned.deily, serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - input() is broken.
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file26344/stdin_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Tue Jul 10 21:36:53 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 19:36:53 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1341949013.88.0.0519997615668.issue4832@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I tried issue4832_rev2.patch on Ubuntu 11.04 with Tk 8.5 and it still behaves as Terry described.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Tue Jul 10 22:04:03 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Jul 2012 20:04:03 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>
Message-ID: <1341950643.41.0.357426715712.issue15302@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As mentioned, the first step is to create some tests that can validate the current behavior, so that changes don't break things.  This is a non-trivial task.  I know from experience with a similar refactoring that even seemingly simple changes can have unexpected consequences, and that getting good functional test coverage (not code-line test coverage) is hard.  This is complicated by the fact that regrtest is an over-evolved mess.  My ideal is to move appropriate pieces of the functionality into unittest and make regrtest a wrapper around that, but obviously I haven't spent much time actually doing that.

I don't think that regrtest tests need to be run as part of the standard python test run, by the way, though I suppose they could be.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Tue Jul 10 22:11:22 2012
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 10 Jul 2012 20:11:22 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>
Message-ID: <1341951082.46.0.795484826939.issue15298@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

proposed patch, tested with configure, build and install

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file26345/sysconfigdata.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15298>
_______________________________________

From report at bugs.python.org  Tue Jul 10 22:26:37 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Jul 2012 20:26:37 +0000
Subject: [issue15319] IDLE - input() is broken.
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341951997.98.0.302907176394.issue15319@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

There is a simpler solution of this issue.

----------
nosy: +storchaka
type:  -> behavior
Added file: http://bugs.python.org/file26346/idle_stdin_no_rpcfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Tue Jul 10 22:50:37 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 20:50:37 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
Message-ID: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

My understanding is that generators are not thread-safe.  For example, see

http://stackoverflow.com/a/1131458/262819

However, regrtest.main() seems to access a generator from multiple threads when run in multiprocess mode:

def work():
    # A worker thread.
    try:
        while True:
            try:
                test, args_tuple = next(pending)
            except StopIteration:
                output.put((None, None, None, None))
                return

http://hg.python.org/cpython/file/2ecdda96f970/Lib/test/regrtest.py#l632

----------
components: Tests
keywords: easy
messages: 165203
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: thread-safety issue in regrtest.main()
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Tue Jul 10 23:20:56 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 21:20:56 +0000
Subject: [issue15319] IDLE - input() is broken.
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341955256.84.0.816232062136.issue15319@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I like Serhiy's patch. It works for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Tue Jul 10 23:32:26 2012
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Cruz?=)
Date: Tue, 10 Jul 2012 21:32:26 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1341955946.51.0.672592918452.issue1346874@psf.upfronthosting.co.za>


Andr? Cruz <andre at cabine.org> added the comment:

As far as I can see, the patch does add some documentation changes. What exactly is missing?

As for the bug, if I understood correctly, what you are saying is that when "ignore_continue" is True, and the server sends a 100 Continue response, the code will continue to try to read data from the server even though none is expected, is that right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346874>
_______________________________________

From report at bugs.python.org  Tue Jul 10 23:57:51 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Jul 2012 21:57:51 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>
Message-ID: <1341957471.66.0.656001693342.issue15298@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is rather ugly, I think. You should arrange for sysconfigdata to be generated directly at the right place instead (not sure how, perhaps it should be done from setup.py).

Also, there's no need for this to be a release blocker.

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15298>
_______________________________________

From report at bugs.python.org  Wed Jul 11 00:14:50 2012
From: report at bugs.python.org (Carl Nobile)
Date: Tue, 10 Jul 2012 22:14:50 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
In-Reply-To: <1341955946.51.0.672592918452.issue1346874@psf.upfronthosting.co.za>
Message-ID: <CAGQqDQLa-=sZfbNVBADwt5Y60_epZu=vWnd_it7=KnGpEww+5w@mail.gmail.com>


Carl Nobile <carl.nobile at gmail.com> added the comment:

Yes, exactly. I was not the one who posted the original bug report, but I
found it when I ran into the same problem. I was not exactly sure if the
original poster had the same issues as I had. I do know that my fix to the
code eliminated some code making the code a bit simpler. I could try to dig
up my fix and send it to you if you want.

~Carl

On Tue, Jul 10, 2012 at 5:32 PM, Andr? Cruz <report at bugs.python.org> wrote:

>
> Andr? Cruz <andre at cabine.org> added the comment:
>
> As far as I can see, the patch does add some documentation changes. What
> exactly is missing?
>
> As for the bug, if I understood correctly, what you are saying is that
> when "ignore_continue" is True, and the server sends a 100 Continue
> response, the code will continue to try to read data from the server even
> though none is expected, is that right?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1346874>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346874>
_______________________________________

From report at bugs.python.org  Wed Jul 11 00:24:26 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 10 Jul 2012 22:24:26 +0000
Subject: [issue15309] buffer/memoryview slice assignment uses only memcpy
In-Reply-To: <1341868914.24.0.978840322443.issue15309@psf.upfronthosting.co.za>
Message-ID: <1341959066.76.0.949960410787.issue15309@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I see nothing wrong in memory_ass_sub(). In 2.7:

    if (destbuf + bytelen < srcbuf || srcbuf + bytelen < destbuf)
        /* No overlapping */
        memcpy(destbuf, srcbuf, bytelen);
    else
        memmove(destbuf, srcbuf, bytelen);


Other versions use similar idioms.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15309>
_______________________________________

From report at bugs.python.org  Wed Jul 11 01:09:54 2012
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Cruz?=)
Date: Tue, 10 Jul 2012 23:09:54 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1341961794.95.0.636443087077.issue1346874@psf.upfronthosting.co.za>


Andr? Cruz <andre at cabine.org> added the comment:

Carl: that would be great. Do you use it regularly? Any other problems?

Python devs: can anyone confirm me what still needs to be done so that this patch can be considered for merging into trunk? Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346874>
_______________________________________

From report at bugs.python.org  Wed Jul 11 01:31:38 2012
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 10 Jul 2012 23:31:38 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1341963098.86.0.936626963114.issue12641@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

It would be great if this could be sorted out in time for Python 3.3. Otherwise I don't think we'll be able to use MinGW to build extensions in Windows. Unless there is a version of MinGW which supports the -mno-cygwin option, as well as libmsvcr100.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Jul 11 01:43:24 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Jul 2012 23:43:24 +0000
Subject: [issue15317] Source installation sets incorrect permissions for
	Grammar3.2.3.final.0.pickle
In-Reply-To: <1341904877.85.0.287783743443.issue15317@psf.upfronthosting.co.za>
Message-ID: <1341963804.44.0.594084163368.issue15317@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15317>
_______________________________________

From report at bugs.python.org  Wed Jul 11 01:46:06 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 10 Jul 2012 23:46:06 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1341963966.73.0.438761741767.issue1346874@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The patch seems good. I apologize that this has been sitting stale for a long time. Since this is a new feature, I am not sure if putting to 3.3 might be a good idea. This is a feature for httplib, so it may not make it to 2.7.x, but can make it to 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346874>
_______________________________________

From report at bugs.python.org  Wed Jul 11 01:48:19 2012
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 10 Jul 2012 23:48:19 +0000
Subject: [issue15315] Can't build Python extension with mingw32 on Windows
In-Reply-To: <1341895923.16.0.599445307566.issue15315@psf.upfronthosting.co.za>
Message-ID: <1341964099.37.0.832776195451.issue15315@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

I've succeeded in building an extension for Python 3.3 (at least, on Windows XP, 32-bit; haven't tried any 64-bit), by the hack of copying libmsvcr100.a from a recent MinGW release (20120426) into an older MinGW release (20101030).

I haven't looked at MinGW releases to see if I can find one that supports both the -mno-cygwin option and msvcr100.

I guess the best solution for this is to resolve issue #12641 for Python 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15315>
_______________________________________

From report at bugs.python.org  Wed Jul 11 02:08:29 2012
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 11 Jul 2012 00:08:29 +0000
Subject: [issue15321] bdist_wininst installers may terminate with "close
	failed in file object destructor:\nsys.excepthook is
	missing\nlost sys.stderr"
Message-ID: <1341965309.27.0.878027505194.issue15321@psf.upfronthosting.co.za>


New submission from Mark Hammond <skippy.hammond at gmail.com>:

Note the error message in the title is only for Python 2.x - Python 3.x shows an empty string instead, but otherwise seems identical.

This was first brought to my attention via http://sourceforge.net/tracker/?func=detail&aid=3528888&group_id=78018&atid=551954.  I can reproduce it (see below) with the pywin32 installer but believe the problem will exist with any such installer.  All tests done on a Win7x64 VM.  Symptoms are:

* Run the installer with UAC enabled - reliably works.  All "print" statements from the post-install script are shown in the final dialog.

* Disable UAC.  The installation reliably ends with the "close failed..." message shown in the final dialog.  No print output is shown.  The installation did actually complete (but is likely to fail if the output fills stdout buffering).  The UAC is probably relevant as when UAC is enabled, the installer re-spawns itself with elevation.

* The problem with UAC disabled can be reproduced running in the VS debugger.  The problem is that Python sees stdout and stderr with a FILE object that has a fileno of -2 (ie, of _NO_CONSOLE_FILENO).  Then, when Python is finalizing it tries to close these handles and fails due to the invalid fileno.  The other messages are a consequence of the fact stderr itself is what is being closed (ie, Python is trying to report a problem closing stderr to stderr.)  Python 3 seems to handle this case better courtesy of issue 1415, but the fact the output is lost remains in both versions.

* Looking over the installer code, I notice that Python is initialized and terminated twice to compile .pyc/.pyo, then initialized a third time in preparation to run the install script - the handles are redirected prior to initializing the 3rd time.  On a hunch, I hacked the code to perform the redirection *before* Python is initialized for the first time.  This solved the problem when run under the debugger but still failed when run stand-alone (*sigh*).  I fiddled with some params to CreateFile in the redirection code but could not get things working.  Note that avoiding the multiple init/finalize calls may be problematic as Py_OptimizeFlag is set differently between runs.

* I looked over the CRT init code to try and determine why _NO_CONSOLE_FILENO was being used.  It appears the CRT attempts to use the process STARTUPINFO and only falls back to GetStdHandle if that STARTUPINFO doesn't provide valid handles.  So I tried both using GetStartupInfo and putting the redirect handles in the result, and explicitly closing the old std handles, but neither of them worked.

Next step is probably to arrange to step through the CRT init code to see what is going on there.  I doubt I will get back to this any time soon, so this is my attempt at detailing what I've discovered to date incase someone else has a look...

----------
assignee: eric.araujo
components: Distutils
messages: 165213
nosy: eric.araujo, mhammond, tarek
priority: normal
severity: normal
status: open
title: bdist_wininst installers may terminate with "close failed in file object destructor:\nsys.excepthook is missing\nlost sys.stderr"
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/issue15321>
_______________________________________

From report at bugs.python.org  Wed Jul 11 02:09:28 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Jul 2012 00:09:28 +0000
Subject: [issue15321] bdist_wininst installers may terminate with "close
	failed in file object destructor:\nsys.excepthook is
	missing\nlost sys.stderr"
In-Reply-To: <1341965309.27.0.878027505194.issue15321@psf.upfronthosting.co.za>
Message-ID: <1341965368.96.0.86611526679.issue15321@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/issue15321>
_______________________________________

From report at bugs.python.org  Wed Jul 11 03:13:52 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Jul 2012 01:13:52 +0000
Subject: [issue15319] IDLE - input() is broken.
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341969232.53.0.366299555449.issue15319@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that the _RPCFile wrapping of the stdin proxy should be undone unless and until there is a positive reason for it -- it solves a problem -- and it is better tested. But reversion does not solve pre-existing problems. As noted by Roger, sys.stdin writes, which it should not do. Worse, when directly used, it does not read, which it should do.

>>> sys.stdin
<idlelib.rpc.RPCProxy object at 0x0000000003282470>
>>> dir(sys.stdin)
['_RPCProxy__attributes', '_RPCProxy__getattributes', '_RPCProxy__getmethods', '_RPCProxy__methods', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattr__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__qualname__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'encoding', 'oid', 'sockio']
>>> sys.stdin.write('abc')
abc
>>> sys.stdin.read()
Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    sys.stdin.read()
AttributeError: read

versus, in command interpreter (Win7,3.3.0b0)

>>> sys.stdin.read()
abcdefg
^Z
'abcdefg\n'
>>> sys.stdin.write('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: not writable

Same difference for readlines and writelines. I wonder how input works if it does not call sys.stdin.read()

I found this in rpc.py:
# XXX KBK 09Sep03  We need a proper unit test for this module.
# Previously existing test code was removed at Rev 1.27 (r34098).

----------
stage:  -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 03:25:44 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Jul 2012 01:25:44 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1341969944.12.0.490097660778.issue15318@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To me, this is part of #15319. sys.stdin is broken in being writable but not readable. Unwrapping is just the first, trivial step to fixing it. So I think we should close this in favor of the other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 03:42:30 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 11 Jul 2012 01:42:30 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1341970950.73.0.871459733577.issue15318@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I agree. I'll close it.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 03:43:46 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 11 Jul 2012 01:43:46 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1341971026.4.0.068583782782.issue15318@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
superseder:  -> IDLE - input() is broken.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 03:44:38 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 11 Jul 2012 01:44:38 +0000
Subject: [issue15319] IDLE - input() is broken.
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341971078.21.0.441670374177.issue15319@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Including issue15318 where stdin is writable. The proper solution to that issue and this one are likely the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 03:47:26 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 11 Jul 2012 01:47:26 +0000
Subject: [issue15319] IDLE - input() is broken.
In-Reply-To: <1341969232.53.0.366299555449.issue15319@psf.upfronthosting.co.za>
Message-ID: <4FFCDB2A.70802@gmail.com>


Roger Serwy <roger.serwy at gmail.com> added the comment:

> Same difference for readlines and writelines. I wonder how input works if it does not call sys.stdin.read()
>

Eventually IDLE makes a call to PyShell's readline.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 04:08:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 02:08:28 +0000
Subject: [issue15322] sysconfig.get_config_var('srcdir') returns unexpected
	value
Message-ID: <1341972508.31.0.0905523614322.issue15322@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

sysconfig.get_config_var('srcdir') seems to return the current working directory rather than a directory related to the source directory.

For example (starting from the repository root)--

$ mkdir foo
$ cd foo
$ ../python.exe 
Python 3.3.0b1 (default:5d43154d68a8, Jul  8 2012, 18:23:20) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
>>> import sysconfig
>>> sysconfig.get_config_vars('srcdir')
['/.../cpython/foo']
>>> import sys
>>> sys.executable
'/.../cpython/foo/../python.exe'

This may be the cause or related to issue 15300: "test directory doubly-nested running tests with -j/--multiprocess".

----------
messages: 165219
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: sysconfig.get_config_var('srcdir') returns unexpected value
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15322>
_______________________________________

From report at bugs.python.org  Wed Jul 11 04:08:53 2012
From: report at bugs.python.org (Carl Nobile)
Date: Wed, 11 Jul 2012 02:08:53 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
In-Reply-To: <1341963966.73.0.438761741767.issue1346874@psf.upfronthosting.co.za>
Message-ID: <CAGQqDQL-uPV9VXSVp3gvnmAJnDLN8OX1ubejYAGYhPwyyo=qug@mail.gmail.com>


Carl Nobile <carl.nobile at gmail.com> added the comment:

Andr?,

As I said I'm not sure if I am fixing the same thing that this bug was
originally posted for. However, after looking at my code I realized that I
just did a quick work around for my situation and it shouldn't be put into
any python release.

This issue is that after a client receives a CONTINUE the client needs to
send the balance of the data. My issue is that the client wouldn't always
do that and the server would hang. So there seems to be a bug
with regard to a reasonable timeout.

When I write RESTful web services I often need to implement CONTINUE, but
this status is rarely used, so I guess I don't use it too regularly.

~Carl

On Tue, Jul 10, 2012 at 7:46 PM, Senthil Kumaran <report at bugs.python.org>wrote:

>
> Senthil Kumaran <senthil at uthcode.com> added the comment:
>
> The patch seems good. I apologize that this has been sitting stale for a
> long time. Since this is a new feature, I am not sure if putting to 3.3
> might be a good idea. This is a feature for httplib, so it may not make it
> to 2.7.x, but can make it to 3.4.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1346874>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346874>
_______________________________________

From report at bugs.python.org  Wed Jul 11 05:02:21 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 03:02:21 +0000
Subject: [issue15300] test directory doubly-nested running tests with
	-j/--multiprocess
In-Reply-To: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>
Message-ID: <1341975741.56.0.241627721205.issue15300@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks for your feedback, Antoine, and for causing me to rethink the patch.  This patch is drastically simpler.

Incidentally, I found a reason for this issue in issue 15322.

regrtest calculates the "build" folder relative to sysconfig.get_config_var('srcdir').  Because the latter returns the current working directory instead of the source directory, the build folders were getting nested.

----------
Added file: http://bugs.python.org/file26347/issue-15300-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15300>
_______________________________________

From report at bugs.python.org  Wed Jul 11 05:11:12 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Jul 2012 03:11:12 +0000
Subject: [issue15319] IDLE - input() is broken.
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341976272.16.0.0588233627683.issue15319@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ah, sys.stdin.readline() works. So the object being proxied has readline (and write and writelines) but not read and readlines. I presume the proxy is in the user process and the actual stdin/out/err objects are in the idle process, interacting with the screen and keyboard via tkinter. Do you know what and where it is, so that we could look at it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 05:12:16 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Jul 2012 03:12:16 +0000
Subject: [issue15319] IDLE - sys.stdin is broken.
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341976336.38.0.306723220513.issue15319@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: IDLE - input() is broken. -> IDLE - sys.stdin is broken.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 05:19:21 2012
From: report at bugs.python.org (Brian Jones)
Date: Wed, 11 Jul 2012 03:19:21 +0000
Subject: [issue15323] Provide target name in output message when
	Mock.assert_called_once_with fails
Message-ID: <1341976761.94.0.831856606531.issue15323@psf.upfronthosting.co.za>


New submission from Brian Jones <bkjones at gmail.com>:

In Python 3.3.0b1, if the number of calls to a mock is, say, zero, and you call assert_called_once_with() on that mock, it will throw an exception which says "Expected to be called once. Called 0 times."

This is nice, but it would be nicer if the output message actually told the end user *what* it expected to be called once. I've supplied a patch and documentation update that makes this change by adding _mock_name to the output message using the variable interpolation method already being used in that message to output the call count. 

The result looks like this (for the case in the documentation): 

Python 3.3.0b1 (default:2ecdda96f970+, Jul 10 2012, 22:45:18) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from unittest.mock import Mock
[103576 refs]
>>> mock = Mock(return_value=None)
[103641 refs]
>>> mock('foo', bar='baz')
[103679 refs]
>>> mock.assert_called_once_with('foo', bar='baz')
[103680 refs]
>>> mock('foo', bar='baz')
[103703 refs]
>>> mock.assert_called_once_with('foo', bar='baz')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/brianj/Dropbox/Source/Python/cpython/Lib/unittest/mock.py", line 736, in assert_called_once_with
    raise AssertionError(msg)
AssertionError: Expected 'mock' to be called once. Called 2 times.
[103758 refs]

In the above case, the mock was never given a name, and wasn't instantiated with any particular target. Here's an example using a patch on 'time.time' to show the effect: 

Python 3.3.0b1 (default:2ecdda96f970+, Jul 10 2012, 22:45:18) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from unittest.mock import patch
[106009 refs]
>>> with patch('time.time') as foo:
...     foo.assert_called_once_with()
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/Users/brianj/Dropbox/Source/Python/cpython/Lib/unittest/mock.py", line 736, in assert_called_once_with
    raise AssertionError(msg)
AssertionError: Expected 'time' to be called once. Called 0 times.
[106621 refs]

----------
components: Library (Lib)
files: mock_assert_called_once_with_output_update.patch
keywords: patch
messages: 165223
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: Provide target name in output message when Mock.assert_called_once_with fails
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file26348/mock_assert_called_once_with_output_update.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15323>
_______________________________________

From report at bugs.python.org  Wed Jul 11 05:20:29 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 11 Jul 2012 03:20:29 +0000
Subject: [issue15230] runpy.run_path doesn't set __package__ correctly
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <1341976829.27.0.0628738245205.issue15230@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/issue15230>
_______________________________________

From report at bugs.python.org  Wed Jul 11 05:21:02 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 11 Jul 2012 03:21:02 +0000
Subject: [issue15272] pkgutil.find_loader accepts invalid module names
In-Reply-To: <1341656387.47.0.245292094882.issue15272@psf.upfronthosting.co.za>
Message-ID: <1341976862.3.0.767753706446.issue15272@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/issue15272>
_______________________________________

From report at bugs.python.org  Wed Jul 11 05:21:46 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 11 Jul 2012 03:21:46 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <1341976906.1.0.395237479956.issue15314@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/issue15314>
_______________________________________

From report at bugs.python.org  Wed Jul 11 05:55:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 03:55:18 +0000
Subject: [issue15323] Provide target name in output message when
	Mock.assert_called_once_with fails
In-Reply-To: <1341976761.94.0.831856606531.issue15323@psf.upfronthosting.co.za>
Message-ID: <1341978918.62.0.685001682584.issue15323@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I have a minor suggestion.  I would suggest--

+ msg = ("Expected %s to be called once. Called %s times." %
+        (repr(self._mock_name) or 'mock', self.call_count))

so that one can distinguish between self._mock_name not being defined and self._mock_name being equal to 'mock'.

----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15323>
_______________________________________

From report at bugs.python.org  Wed Jul 11 06:18:42 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 11 Jul 2012 04:18:42 +0000
Subject: [issue14797] Deprecate imp.find_module()/load_module()
In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za>
Message-ID: <1341980322.77.0.882483391085.issue14797@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/issue14797>
_______________________________________

From report at bugs.python.org  Wed Jul 11 06:34:02 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 11 Jul 2012 04:34:02 +0000
Subject: [issue15319] IDLE - sys.stdin is broken.
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341981242.86.0.183583427962.issue15319@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 07:33:42 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 11 Jul 2012 05:33:42 +0000
Subject: [issue15319] IDLE - sys.stdin is broken.
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341984822.66.0.85061064922.issue15319@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

PyShell.py's PyShell object has the readline method, at line 1080 in the most recent code. It's meant for use with and without a subprocess. (See also Issue14254)

The IDLEfork project long ago created the subprocess and the RPC plumbing for the subprocess interaction with the *existing* PyShell(OutputWindow) object as stdin/stdout/stderr. This RPC, found in rpc.py, is used in run.py and PyShell's ModifiedInterpreter. The start_subprocess method connects the stdin/stdout/stderr from the IDLE front-end to the subprocess in run.py. The stdout/stderr objects are the PyShell(OutputWindow) object wrapped by PseudoFile. Stdin is not wrapped, but it should be.

I know that this issue deals with stdin specifically, but I hope that the additional stdout/stderr information places the problem into a greater context.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 08:15:23 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 06:15:23 +0000
Subject: [issue15319] IDLE - readline, isatty, and input broken
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341987323.59.0.508851504958.issue15319@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the issue is grossly underspecified. The title of the issue is "sys.stdin is broken" which says nothing about the way in which it is broken. Taking Roger's literal description, and his msg165191, the complaint is that input() no longer works, as doesn't readline and isatty.

Since this was what Roger opened the issue for, I declare this to be the issue being dealt with here. I agree that Serhiy's patch is a proper resolution of the issue.

Roger, please refrain from trying to put issues in a broader scope, unless you make an explicit specification what exactly is in scope and what is out of scope. I readily agree that there are many issues with stdin and stdout in IDLE; I don't agree that easily that they all deserve being resolved. I entirely, completely, absolutely disagree that they are related to what you originally submitted as this issue, as I firmly, deeply convinced believe that the fixes to the other issues will be different from the proper fix to this issue. So please, please, please don't mix issues.

----------
title: IDLE - sys.stdin is broken. -> IDLE - readline, isatty, and input broken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 08:30:54 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Jul 2012 06:30:54 +0000
Subject: [issue15319] IDLE - readline, isatty, and input broken
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <3WX9QN5JgzzMlD@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b90482742ee0 by Martin v. L?wis in branch '3.2':
Issue #15319: Revert wrapping of sys.stdin. Patch by Serhiy Storchaka.
http://hg.python.org/cpython/rev/b90482742ee0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 08:30:55 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 06:30:55 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>
Message-ID: <1341988255.91.0.855085379161.issue15302@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Here is a patch that creates some unit tests for the existing getopt argument parsing code.

In response to the comments, I'm thinking of a less invasive approach that involves wrapping argparse's parse_args() to return getopt-like output (and in particular, to match test expectations).

In this way, we will be able to keep main() mostly unaffected while still being able to use argparse.

----------
keywords: +patch
Added file: http://bugs.python.org/file26349/issue-15302-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Wed Jul 11 08:32:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Jul 2012 06:32:16 +0000
Subject: [issue15319] IDLE - readline, isatty, and input broken
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <3WX9Rz4Kq2zNgj@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 42424c1f605c by Martin v. L?wis in branch '2.7':
Issue #15319: Revert wrapping of sys.stdin. Patch by Serhiy Storchaka.
http://hg.python.org/cpython/rev/42424c1f605c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 08:32:52 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 06:32:52 +0000
Subject: [issue15319] IDLE - readline, isatty, and input broken
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341988372.78.0.33321561415.issue15319@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 08:35:05 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 06:35:05 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1341988505.99.0.548336828575.issue15318@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's *clearly* not a duplicate. While #15319 is fixed, this issue remains - so it can't possibly be a duplicate.

----------
nosy: +loewis
resolution: duplicate -> 
superseder: IDLE - readline, isatty, and input broken -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 08:50:36 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 06:50:36 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1341989436.16.0.777924680509.issue15318@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 09:24:16 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 07:24:16 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1341991456.28.0.750001309261.issue15318@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I propose the attached patch to block write() calls.

----------
keywords: +patch
Added file: http://bugs.python.org/file26350/blockwrite.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 09:38:15 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 07:38:15 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1341992295.63.0.264355009555.issue15318@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Revised

----------
Added file: http://bugs.python.org/file26351/blockwrite.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 10:09:54 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 11 Jul 2012 08:09:54 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1341994194.3.0.158168470127.issue15320@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

There is indeed a race condition here.  Fortunately unit tests take much more time than the generator loop.

Is it enough to turn the generator into a fixed list? Or is the "late binding" behavior of args_tuple important? (For example, if the main thread changes the timeout variable, subsequent tests would see the modified value)

----------
nosy: +amaury.forgeotdarc, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Wed Jul 11 10:29:58 2012
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 11 Jul 2012 08:29:58 +0000
Subject: [issue3405] Add support for the new data option supported by event
	generate (Tk 8.5)
In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>
Message-ID: <1341995398.44.0.157683413459.issue3405@psf.upfronthosting.co.za>


Mark Summerfield <mark at qtrac.eu> added the comment:

According to the Tcl/Tk docs the 'data' field is a string (i.e., for any user data) and the 'detail' field contains some internal data (so shouldn't be messed with); see http://www.tcl.tk/man/tcl8.5/TkCmd/event.htm#M16

Anyway, I hope you add a data field for user created virtual events.

----------
nosy: +mark

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3405>
_______________________________________

From report at bugs.python.org  Wed Jul 11 10:42:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 08:42:47 +0000
Subject: [issue15324] --match does not work for regrtest
Message-ID: <1341996167.29.0.670319499131.issue15324@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The long form of the -m/--match option does not work with regrtest because it does not accept an argument.  For example (observe the lack of an error in the second invocation)--

$ ./python.exe -m test -m 
option -m requires argument
Use --help for usage
$ ./python.exe -m test --match
== CPython 3.3.0b1 (default:5d43154d68a8, Jul 8 2012, 13:54:45) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)]
...

----------
keywords: easy
messages: 165235
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: --match does not work for regrtest
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15324>
_______________________________________

From report at bugs.python.org  Wed Jul 11 10:51:57 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jul 2012 08:51:57 +0000
Subject: [issue15319] IDLE - sys.stdin, sys.stdout, etc are broken
In-Reply-To: <1341976336.43.0.822226950941.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341996740.4993.3.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> title: IDLE - input() is broken. -> IDLE - sys.stdin is broken.

Well, now, with the modified header, I'm not going to open a separate
issue. Here is a patch that fixes almost all IDLE sys.std* issues.

----------
title: IDLE - readline, isatty, and input broken -> IDLE - sys.stdin, sys.stdout, etc are broken
Added file: http://bugs.python.org/file26352/idle_stdstreams.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________
-------------- next part --------------
diff -r 2ecdda96f970 Lib/idlelib/PyShell.py
--- a/Lib/idlelib/PyShell.py	Tue Jul 10 18:27:54 2012 +0200
+++ b/Lib/idlelib/PyShell.py	Wed Jul 11 11:47:48 2012 +0300
@@ -1,6 +1,7 @@
 #! /usr/bin/env python3
 
 import getopt
+import io
 import os
 import os.path
 import re
@@ -410,7 +411,8 @@
         except socket.timeout as err:
             self.display_no_subprocess_error()
             return None
-        self.rpcclt.register("stdin", self.tkconsole)
+        self.rpcclt.register("console", self.tkconsole)
+        self.rpcclt.register("stdin", self.tkconsole.stdin)
         self.rpcclt.register("stdout", self.tkconsole.stdout)
         self.rpcclt.register("stderr", self.tkconsole.stderr)
         self.rpcclt.register("flist", self.tkconsole.flist)
@@ -854,13 +856,14 @@
         self.save_stderr = sys.stderr
         self.save_stdin = sys.stdin
         from idlelib import IOBinding
-        self.stdout = PseudoFile(self, "stdout", IOBinding.encoding)
-        self.stderr = PseudoFile(self, "stderr", IOBinding.encoding)
-        self.console = PseudoFile(self, "console", IOBinding.encoding)
+        self.stdout = OutputPseudoFile(self, "stdout", IOBinding.encoding)
+        self.stderr = OutputPseudoFile(self, "stderr", IOBinding.encoding)
+        self.console = OutputPseudoFile(self, "console", IOBinding.encoding)
+        self.stdin = InputPseudoFile(self, "stdin", IOBinding.encoding)
         if not use_subprocess:
             sys.stdout = self.stdout
             sys.stderr = self.stderr
-            sys.stdin = self
+            sys.stdin = self.stdin
         try:
             # page help() text to shell.
             import pydoc # import must be done here to capture i/o rebinding.
@@ -1250,28 +1253,68 @@
             if not use_subprocess:
                 raise KeyboardInterrupt
 
-class PseudoFile(object):
+class PseudoFile(io.TextIOBase):
 
     def __init__(self, shell, tags, encoding=None):
         self.shell = shell
         self.tags = tags
-        self.encoding = encoding
+        self._encoding = encoding
+
+    @property
+    def encoding(self):
+        return self._encoding
+
+    def isatty(self):
+        return True
+
+    def close(self):
+        return self.shell.close()
+
+
+class InputPseudoFile(PseudoFile):
+
+    _line_buffer = ''
+
+    def readable(self):
+        return True
+
+    def read(self, n=-1):
+        if n is None:
+            n = -1
+        result = self._line_buffer
+        self._line_buffer = ''
+        if n < 0:
+            while True:
+                line = self.readline()
+                if not line: break
+                result += line
+        else:
+            while len(result) < n:
+                line = self.readline()
+                if not line: break
+                result += line
+            self._line_buffer = result[n:]
+            result = result[:n]
+        return result
+
+    def readline(self):
+        if self._line_buffer:
+            line = self._line_buffer
+            self._line_buffer = ''
+            return line
+        return self.shell.readline()
+
+
+class OutputPseudoFile(PseudoFile):
+
+    def writable(self):
+        return True
 
     def write(self, s):
         if not isinstance(s, str):
             raise TypeError('must be str, not ' + type(s).__name__)
         self.shell.write(s, self.tags)
 
-    def writelines(self, lines):
-        for line in lines:
-            self.write(line)
-
-    def flush(self):
-        pass
-
-    def isatty(self):
-        return True
-
 
 usage_msg = """\
 
diff -r 2ecdda96f970 Lib/idlelib/run.py
--- a/Lib/idlelib/run.py	Tue Jul 10 18:27:54 2012 +0200
+++ b/Lib/idlelib/run.py	Wed Jul 11 11:47:48 2012 +0300
@@ -258,23 +258,15 @@
             quitting = True
             thread.interrupt_main()
 
-class _RPCFile(io.TextIOBase):
-    """Wrapper class for the RPC proxy to typecheck arguments
-    that may not support pickling."""
-
-    def __init__(self, rpc):
-        super.__setattr__(self, 'rpc', rpc)
-
-    def __getattr__(self, name):
-        return getattr(self.rpc, name)
-
-    def __setattr__(self, name, value):
-        return setattr(self.rpc, name, value)
-
-    def write(self, s):
+def _checked_text_writer(writer):
+    # Wrap the RPC proxy to typecheck arguments that may not support pickling.
+    oldwrite = writer.write
+    def write(s):
         if not isinstance(s, str):
             raise TypeError('must be str, not ' + type(s).__name__)
-        return self.rpc.write(s)
+        return oldwrite(s)
+    writer.write = write
+    return writer
 
 class MyHandler(rpc.RPCHandler):
 
@@ -282,9 +274,10 @@
         """Override base method"""
         executive = Executive(self)
         self.register("exec", executive)
-        sys.stdin = self.console = _RPCFile(self.get_remote_proxy("stdin"))
-        sys.stdout = _RPCFile(self.get_remote_proxy("stdout"))
-        sys.stderr = _RPCFile(self.get_remote_proxy("stderr"))
+        sys.stdin = self.get_remote_proxy("stdin")
+        sys.stdout = _checked_text_writer(self.get_remote_proxy("stdout"))
+        sys.stderr = _checked_text_writer(self.get_remote_proxy("stderr"))
+        self.console = _checked_text_writer(self.get_remote_proxy("console"))
         sys.displayhook = rpc.displayhook
         # page help() text to shell.
         import pydoc # import must be done here to capture i/o binding

From report at bugs.python.org  Wed Jul 11 10:53:52 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 08:53:52 +0000
Subject: [issue15319] IDLE - sys.stdin, sys.stdout, etc are broken
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341996832.11.0.0952965797956.issue15319@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Serhiy: this issue is closed, so your patch won't be considered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 11:00:21 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jul 2012 09:00:21 +0000
Subject: [issue15319] IDLE - readline, isatty, and input broken
In-Reply-To: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>
Message-ID: <1341997221.78.0.0170628868416.issue15319@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Sorry, I missed the morning's discussion.

----------
title: IDLE - sys.stdin, sys.stdout, etc are broken -> IDLE - readline, isatty, and input broken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15319>
_______________________________________

From report at bugs.python.org  Wed Jul 11 11:02:32 2012
From: report at bugs.python.org (Michael Foord)
Date: Wed, 11 Jul 2012 09:02:32 +0000
Subject: [issue15323] Provide target name in output message when
	Mock.assert_called_once_with fails
In-Reply-To: <1341976761.94.0.831856606531.issue15323@psf.upfronthosting.co.za>
Message-ID: <1341997352.33.0.895948444262.issue15323@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Looks good, thanks.

----------
assignee:  -> michael.foord
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15323>
_______________________________________

From report at bugs.python.org  Wed Jul 11 11:13:10 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jul 2012 09:13:10 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1341997990.94.0.22525015051.issue15318@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

sys.std* streams have many other issues.

>>> sys.stdin.readable()
Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    sys.stdin.readable()
AttributeError: readable
>>> sys.stdout.writable()
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    sys.stdout.writable()
AttributeError: writable
>>> sys.stdout.newlines
Traceback (most recent call last):
  File "<pyshell#8>", line 1, in <module>
    sys.stdout.newlines
AttributeError: newlines
>>> sys.stdin.read(1)
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    sys.stdin.read(1)
AttributeError: read

And some other.

Here is a patch that fixes almost all IDLE sys.std* issues.

----------
Added file: http://bugs.python.org/file26353/idle_stdstreams-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 11:35:16 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jul 2012 09:35:16 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341997990.94.0.22525015051.issue15318@psf.upfronthosting.co.za>
Message-ID: <1341999344.4993.5.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Added getvar method to PyShell.console.

----------
Added file: http://bugs.python.org/file26354/idle_stdstreams-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________
-------------- next part --------------
diff -r 300e2bbd413c Lib/idlelib/PyShell.py
--- a/Lib/idlelib/PyShell.py	Wed Jul 11 09:17:54 2012 +0200
+++ b/Lib/idlelib/PyShell.py	Wed Jul 11 12:33:10 2012 +0300
@@ -1,6 +1,7 @@
 #! /usr/bin/env python3
 
 import getopt
+import io
 import os
 import os.path
 import re
@@ -410,7 +411,8 @@
         except socket.timeout as err:
             self.display_no_subprocess_error()
             return None
-        self.rpcclt.register("stdin", self.tkconsole)
+        self.rpcclt.register("console", self.tkconsole)
+        self.rpcclt.register("stdin", self.tkconsole.stdin)
         self.rpcclt.register("stdout", self.tkconsole.stdout)
         self.rpcclt.register("stderr", self.tkconsole.stderr)
         self.rpcclt.register("flist", self.tkconsole.flist)
@@ -854,13 +856,15 @@
         self.save_stderr = sys.stderr
         self.save_stdin = sys.stdin
         from idlelib import IOBinding
-        self.stdout = PseudoFile(self, "stdout", IOBinding.encoding)
-        self.stderr = PseudoFile(self, "stderr", IOBinding.encoding)
-        self.console = PseudoFile(self, "console", IOBinding.encoding)
+        self.stdout = OutputPseudoFile(self, "stdout", IOBinding.encoding)
+        self.stderr = OutputPseudoFile(self, "stderr", IOBinding.encoding)
+        self.console = OutputPseudoFile(self, "console", IOBinding.encoding)
+        self.console.getvar = self.getvar
+        self.stdin = InputPseudoFile(self, "stdin", IOBinding.encoding)
         if not use_subprocess:
             sys.stdout = self.stdout
             sys.stderr = self.stderr
-            sys.stdin = self
+            sys.stdin = self.stdin
         try:
             # page help() text to shell.
             import pydoc # import must be done here to capture i/o rebinding.
@@ -1250,28 +1254,68 @@
             if not use_subprocess:
                 raise KeyboardInterrupt
 
-class PseudoFile(object):
+class PseudoFile(io.TextIOBase):
 
     def __init__(self, shell, tags, encoding=None):
         self.shell = shell
         self.tags = tags
-        self.encoding = encoding
+        self._encoding = encoding
+
+    @property
+    def encoding(self):
+        return self._encoding
+
+    def isatty(self):
+        return True
+
+    def close(self):
+        return self.shell.close()
+
+
+class InputPseudoFile(PseudoFile):
+
+    _line_buffer = ''
+
+    def readable(self):
+        return True
+
+    def read(self, n=-1):
+        if n is None:
+            n = -1
+        result = self._line_buffer
+        self._line_buffer = ''
+        if n < 0:
+            while True:
+                line = self.readline()
+                if not line: break
+                result += line
+        else:
+            while len(result) < n:
+                line = self.readline()
+                if not line: break
+                result += line
+            self._line_buffer = result[n:]
+            result = result[:n]
+        return result
+
+    def readline(self):
+        if self._line_buffer:
+            line = self._line_buffer
+            self._line_buffer = ''
+            return line
+        return self.shell.readline()
+
+
+class OutputPseudoFile(PseudoFile):
+
+    def writable(self):
+        return True
 
     def write(self, s):
         if not isinstance(s, str):
             raise TypeError('must be str, not ' + type(s).__name__)
         self.shell.write(s, self.tags)
 
-    def writelines(self, lines):
-        for line in lines:
-            self.write(line)
-
-    def flush(self):
-        pass
-
-    def isatty(self):
-        return True
-
 
 usage_msg = """\
 
diff -r 300e2bbd413c Lib/idlelib/run.py
--- a/Lib/idlelib/run.py	Wed Jul 11 09:17:54 2012 +0200
+++ b/Lib/idlelib/run.py	Wed Jul 11 12:33:10 2012 +0300
@@ -258,29 +258,15 @@
             quitting = True
             thread.interrupt_main()
 
-class _RPCFile(io.TextIOBase):
-    """Wrapper class for the RPC proxy to typecheck arguments
-    that may not support pickling. The base class is there only
-    to support type tests; all implementations come from the remote
-    object."""
-
-    def __init__(self, rpc):
-        super.__setattr__(self, 'rpc', rpc)
-
-    def __getattribute__(self, name):
-        # When accessing the 'rpc' attribute, or 'write', use ours
-        if name in ('rpc', 'write'):
-            return io.TextIOBase.__getattribute__(self, name)
-        # Else only look into the remote object only
-        return getattr(self.rpc, name)
-
-    def __setattr__(self, name, value):
-        return setattr(self.rpc, name, value)
-
-    def write(self, s):
+def _checked_text_writer(writer):
+    # Wrap the RPC proxy to typecheck arguments that may not support pickling.
+    oldwrite = writer.write
+    def write(s):
         if not isinstance(s, str):
             raise TypeError('must be str, not ' + type(s).__name__)
-        return self.rpc.write(s)
+        return oldwrite(s)
+    writer.write = write
+    return writer
 
 class MyHandler(rpc.RPCHandler):
 
@@ -288,9 +274,10 @@
         """Override base method"""
         executive = Executive(self)
         self.register("exec", executive)
-        sys.stdin = self.console = self.get_remote_proxy("stdin")
-        sys.stdout = _RPCFile(self.get_remote_proxy("stdout"))
-        sys.stderr = _RPCFile(self.get_remote_proxy("stderr"))
+        sys.stdin = self.get_remote_proxy("stdin")
+        sys.stdout = _checked_text_writer(self.get_remote_proxy("stdout"))
+        sys.stderr = _checked_text_writer(self.get_remote_proxy("stderr"))
+        self.console = _checked_text_writer(self.get_remote_proxy("console"))
         sys.displayhook = rpc.displayhook
         # page help() text to shell.
         import pydoc # import must be done here to capture i/o binding

From report at bugs.python.org  Wed Jul 11 11:51:12 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 09:51:12 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342000272.94.0.456241847246.issue15318@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Serhiy: can you please explicitly list what issues your patch fixes?

I can think of many *more* issues that your patch doesn't fix, e.g. sys.stdin.read(sys) and sys.stdout.read().

I'm quite opposed to monkey-patching, so I won't commit any patch that involves monkey-patching (i.e. _checked_text_writer). I'm also unsure what problem this change to monkey-patching solves: I believe the current code is fine in this respect as it stands.

Before you grow the patch to add many more lines of code, please try to stick to the "one issue at a time" principle. As a guideline: if you need to write additional lines of code, it's a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 12:05:32 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 10:05:32 +0000
Subject: [issue15325] --fromfile does not work for regrtest
Message-ID: <1342001132.43.0.639678860969.issue15325@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The long form of the -f/--fromfile option does not work.  It does not read its required argument.  For example (observe that the second invocation raises no error)--

$ ./python.exe -m test -f
option -f requires argument
Use --help for usage
$ ./python.exe -m test --fromfile
== CPython 3.3.0b1 (default:5d43154d68a8, Jul 8 2012, 13:54:45) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)]

Note that issue 15302 will fix this.

----------
keywords: easy
messages: 165243
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: --fromfile does not work for regrtest
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15325>
_______________________________________

From report at bugs.python.org  Wed Jul 11 12:06:05 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 10:06:05 +0000
Subject: [issue15324] --match does not work for regrtest
In-Reply-To: <1341996167.29.0.670319499131.issue15324@psf.upfronthosting.co.za>
Message-ID: <1342001165.03.0.070717194764.issue15324@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Note that issue 15302 will fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15324>
_______________________________________

From report at bugs.python.org  Wed Jul 11 12:10:20 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 10:10:20 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342001420.19.0.0283961540817.issue15318@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As an additional note: the change to monkey-patching breaks the test 

isinstance(sys.stdout, io.TextIOBase)

which currently succeeds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 12:15:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 10:15:11 +0000
Subject: [issue15326] --random does not work for regrtest
Message-ID: <1342001711.01.0.48203802237.issue15326@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The long form of the -r/--random option does not work:

$ ./python.exe -m test --random
No handler for option --random.  Please report this as a bug at http://bugs.python.org.

Note that issue 15302 will fix this.

----------
components: Tests
keywords: easy
messages: 165246
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: --random does not work for regrtest
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15326>
_______________________________________

From report at bugs.python.org  Wed Jul 11 12:52:58 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 10:52:58 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>
Message-ID: <1342003978.29.0.454907107197.issue15302@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attached is a first version of a complete patch.

Note that I found three bugs in the current argument parsing code in the course of working on this patch: issue 15324, issue 15325, and issue 15326 (because of various typos in the getopt configuration).  All of these should be fixed by the current patch.

----------
Added file: http://bugs.python.org/file26355/issue-15302-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Wed Jul 11 13:05:30 2012
From: report at bugs.python.org (Ingo Fischer)
Date: Wed, 11 Jul 2012 11:05:30 +0000
Subject: [issue15327] Argparse: main arguments and subparser arguments
	indistinguishable
Message-ID: <1342004730.08.0.363281774737.issue15327@psf.upfronthosting.co.za>


New submission from Ingo Fischer <fredistdurstig at googlemail.com>:

I have an argument called '--verbose' in the main parser. 
Then I add a subparser called 'command', to which I add an argument with the same name '--verbose' (See attached script).

When I process these args, I cannot decide afterwards if the user called 'myscript --verbose command' or 'myscript command --verbose'. I always get the same Namespace object returned from parse_args.

IMHO the Namespace object should also provide informations about the source parser, to make main parser args and subparser args distinguishable. Also if I call 'myscript --verbose command --verbose', I should get both args in the resulting Namespace object.

----------
components: Library (Lib)
files: argparsetest.py
messages: 165248
nosy: Ingo.Fischer
priority: normal
severity: normal
status: open
title: Argparse: main arguments and subparser arguments indistinguishable
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file26356/argparsetest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15327>
_______________________________________

From report at bugs.python.org  Wed Jul 11 13:16:09 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jul 2012 11:16:09 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1342000272.94.0.456241847246.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342005291.6314.35.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Serhiy: can you please explicitly list what issues your patch fixes?

issue12967. And sys.std* in IDLE lacks other common sys.std* methods and
attributes.

> I can think of many *more* issues that your patch doesn't fix, e.g. sys.stdin.read(sys) and sys.stdout.read().

sys.stdin.read(sys) and sys.stdout.read() should not work.

> I'm quite opposed to monkey-patching, so I won't commit any patch that involves monkey-patching (i.e. _checked_text_writer). I'm also unsure what problem this change to monkey-patching solves: I believe the current code is fine in this respect as it stands.

I introduced _checked_text_writer, because the implementation of
_RPCFile was broken (I wrote this patch last evening and debug it this
morning). In addition, _RPCFile is a wrapper around RPCFile, which
itself is a wrapper. There are too many layers for me. If you are sure
that the current implementation of _RPCFile is correct, it is not
necessary.

> Before you grow the patch to add many more lines of code, please try to stick to the "one issue at a time" principle.

In IDLE sys.std* bad mimic text streams -- this is one issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 13:17:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 11:17:56 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342005476.38.0.530545268125.issue15320@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I don't think the late binding is necessary. But it looks like late binding could be preserved simply by constructing args_tuple inside the worker thread instead of in the generator. Really, only "test" needs to be yielded. Nothing else varies in the loop.

Is popping from a list thread safe, or were you thinking of another queue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Wed Jul 11 13:23:40 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jul 2012 11:23:40 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1342001420.19.0.0283961540817.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342005853.6314.39.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> As an additional note: the change to monkey-patching breaks the test 
> 
> isinstance(sys.stdout, io.TextIOBase)
> 
> which currently succeeds.

Agree, this is a regression. However isinstance(sys.stdout,
io.TextIOBase) is False now in no-subprocess mode. This should be fixed
also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 13:32:52 2012
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Cruz?=)
Date: Wed, 11 Jul 2012 11:32:52 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1342006372.07.0.308072039577.issue1346874@psf.upfronthosting.co.za>


Andr? Cruz <andre at cabine.org> added the comment:

Attached is an updated patch against 2.7.3. It solves a bug in the tests and implements Carl's suggestion. The new tests pass and it updates the documentation as well.

As for inclusion in 2.7, as this is in fact solving a bug, I would vote for it. Right now, if the client sends an "Expect" header, httplib will send the body of the request along, which is against the RFC. It is backwards-compatible.

----------
Added file: http://bugs.python.org/file26357/issue1346874-273.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346874>
_______________________________________

From report at bugs.python.org  Wed Jul 11 13:44:32 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 11 Jul 2012 11:44:32 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342007072.23.0.733577158771.issue15320@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I was about to say "yes, listiter.__next__ is atomic" (it should, really), but that's not true (Hint: there is a Py_DECREF in the code...).

The script below crashes with:
    Fatal Python error: Objects/listobject.c:2774 object at 0x7f66b7a6c600 has negative ref count -1
Attached patch fixes it.


import threading
class C:
    def __del__(self):
        print("DEL")
ITER = iter([C() for x in range(100)])
def f():
    for obj in ITER:
        pass
for x in range(10):
    t = threading.Thread(target=f)
    t.start()

----------
keywords: +patch
Added file: http://bugs.python.org/file26358/listiter_next_atomic.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Wed Jul 11 14:13:48 2012
From: report at bugs.python.org (O.C.)
Date: Wed, 11 Jul 2012 12:13:48 +0000
Subject: [issue3405] Add support for the new data option supported by event
	generate (Tk 8.5)
In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>
Message-ID: <1342008828.78.0.914943702367.issue3405@psf.upfronthosting.co.za>


O.C. <oc-spam66 at laposte.net> added the comment:

I don't agree with this comment.

1) The 'detail' field also contains a string, one of the following: "NotifyAncestor", "NotifyNonlinearVirtual",...

2) When an event is received, the 'detail' and 'user_data' fields are de facto mixed up. Indeed, the "%d" field contains "the detail or user_data field from the event".

This information comes form the documentation I cited, http://www.tcl.tk/man/tcl8.5/TkCmd/bind.htm#M24 :

* The "%d" field contains "the detail or user_data field from the event".
* They are both strings:
* "the %d is replaced by a string identifying the detail"
* "For virtual events, the string will be whatever value is stored in the user_data field when the event was created (typically with event generate), or the empty string if the field is NULL"

>From the document cited in msg165234 (http://www.tcl.tk/man/tcl8.5/TkCmd/event.htm#M16), my understanding is:

* For virtual events, the "data" string parameter given to "event generate" will be stored in the "user_data field" for the event. This string will then be available from the event through the "%d" substitution.

* For events "Enter", "Leave", "FocusIn" and "FocusOut", the "detail" field will store a string among "NotifyAncestor", etc. This string will then be available from the event through the "%d" substitution.

So, from the point of view of the guy who receives the event, the "%d" field can EITHER be a "detail" string like "NotifyAncestor" if event was "Enter"/"Leave"/"FocusIn"/"FocusOut" OR a "user_data" string in the case of a virtual event. It seems sensible that the Python interface provides both names. As a consequence, I think the patch should read:

+                # value passed to the data option is not a widget, take it
+                # as the detail field
+                e.data = None
+                e.detail = d
+                e.user_data = d

I hope I understood the doc correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3405>
_______________________________________

From report at bugs.python.org  Wed Jul 11 15:05:55 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 11 Jul 2012 13:05:55 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>
Message-ID: <1342011955.88.0.615312849561.issue15302@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Wed Jul 11 15:13:43 2012
From: report at bugs.python.org (Greg Roodt)
Date: Wed, 11 Jul 2012 13:13:43 +0000
Subject: [issue8823] urllib2 does not catch httplib.BadStatusLine
In-Reply-To: <1274881450.55.0.827580135846.issue8823@psf.upfronthosting.co.za>
Message-ID: <1342012423.05.0.0581008960558.issue8823@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

By the way, the issue can be recreated by running the following:

netcat -l -p 9999 -e "echo HTTP/1.1 1000 OK" &
python -c "import urllib2; urllib2.urlopen('http://localhost:9999')"

This happens on 2.6, 2.7 and 3 by the looks of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8823>
_______________________________________

From report at bugs.python.org  Wed Jul 11 16:00:21 2012
From: report at bugs.python.org (Lars Nordin)
Date: Wed, 11 Jul 2012 14:00:21 +0000
Subject: [issue15328] datetime.strptime slow
Message-ID: <1342015221.25.0.0683472526459.issue15328@psf.upfronthosting.co.za>


New submission from Lars Nordin <lars.nordin at gmail.com>:

The datetime.strptime works well enough for me it is just slow.

I recently added a comparison to a log parsing script to skip log lines earlier than a set date. After doing so my script ran much slower.
I am processing 4,784,212 log lines in 1,746 files.

Using Linux "time", the measured run time is:
real    5m12.884s
user    4m54.330s
sys     0m2.344s

Altering the script to cache the datetime object if the date string is the same, reduces the run time to: 
real    1m3.816s
user    0m49.635s
sys     0m1.696s

# --- code snippet ---
# start_dt calculated at script start
...
day_dt = datetime.datetime.strptime(day_str, "%Y-%m-%d")
if day_dt < start_dt:
...


$ python
import platform
print 'Version      :', platform.python_version()
print 'Version tuple:', platform.python_version_tuple()
print 'Compiler     :', platform.python_compiler()
print 'Build        :', platform.python_build()

Version      : 2.7.2+
Version tuple: ('2', '7', '2+')
Compiler     : GCC 4.6.1
Build        : ('default', 'Oct  4 2011 20:03:08')

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 11.10
Release:        11.10
Codename:       oneiric

----------
components: None
messages: 165256
nosy: Lars.Nordin
priority: normal
severity: normal
status: open
title: datetime.strptime slow
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15328>
_______________________________________

From report at bugs.python.org  Wed Jul 11 16:09:10 2012
From: report at bugs.python.org (Lars Nordin)
Date: Wed, 11 Jul 2012 14:09:10 +0000
Subject: [issue15328] datetime.strptime slow
In-Reply-To: <1342015221.25.0.0683472526459.issue15328@psf.upfronthosting.co.za>
Message-ID: <1342015750.6.0.418375798093.issue15328@psf.upfronthosting.co.za>


Lars Nordin <lars.nordin at gmail.com> added the comment:

Running the script without any timestamp comparison (and parsing more log lines), gives these performance numbers:

log lines: 7,173,101

time output:
real    1m9.892s
user    0m53.563s
sys     0m1.592s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15328>
_______________________________________

From report at bugs.python.org  Wed Jul 11 16:12:27 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Jul 2012 14:12:27 +0000
Subject: [issue15328] datetime.strptime slow
In-Reply-To: <1342015221.25.0.0683472526459.issue15328@psf.upfronthosting.co.za>
Message-ID: <1342015947.36.0.112798382444.issue15328@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the report.  However, do you have a patch to propose?  Otherwise I'm not sure there is a reason to keep this issue open...one can always say various things are slow; that by itself is not a bug.  Performance enhancement patches are welcome, though.

If you are proposing adding an LRU cache, I think it may be that that should be left up to the application, as you did in your case.  I'm not convinced there would be enough general benefit to make it worth adding to the stdlib, since the characteristics of date parsing workloads probably vary widely.

----------
nosy: +belopolsky, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15328>
_______________________________________

From report at bugs.python.org  Wed Jul 11 16:58:33 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jul 2012 14:58:33 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342018713.8.0.278116802715.issue15318@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

issue9290 also has relation to this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 17:00:58 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jul 2012 15:00:58 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342018858.78.0.970505837448.issue15318@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

issue7163 is another PseudoFile-related issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 17:04:01 2012
From: report at bugs.python.org (florian-rathgeber)
Date: Wed, 11 Jul 2012 15:04:01 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1342019041.18.0.0804294222443.issue7897@psf.upfronthosting.co.za>


Changes by florian-rathgeber <florian.rathgeber at gmail.com>:


----------
nosy: +florian-rathgeber

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 11 17:04:15 2012
From: report at bugs.python.org (florian-rathgeber)
Date: Wed, 11 Jul 2012 15:04:15 +0000
Subject: [issue12600] Add example of using load_tests to parameterise Test
	Cases
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1342019055.69.0.0290501973369.issue12600@psf.upfronthosting.co.za>


Changes by florian-rathgeber <florian.rathgeber at gmail.com>:


----------
nosy: +florian-rathgeber

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12600>
_______________________________________

From report at bugs.python.org  Wed Jul 11 18:06:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Jul 2012 16:06:07 +0000
Subject: [issue15322] sysconfig.get_config_var('srcdir') returns unexpected
	value
In-Reply-To: <1341972508.31.0.0905523614322.issue15322@psf.upfronthosting.co.za>
Message-ID: <1342022767.26.0.420139390801.issue15322@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eric.araujo, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15322>
_______________________________________

From report at bugs.python.org  Wed Jul 11 18:07:38 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Jul 2012 16:07:38 +0000
Subject: [issue15300] test directory doubly-nested running tests with
	-j/--multiprocess
In-Reply-To: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>
Message-ID: <1342022858.8.0.27729092605.issue15300@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks, Chris. I haven't tested the patch but it looks fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15300>
_______________________________________

From report at bugs.python.org  Wed Jul 11 18:08:41 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 11 Jul 2012 16:08:41 +0000
Subject: [issue15322] sysconfig.get_config_var('srcdir') returns unexpected
	value
In-Reply-To: <1341972508.31.0.0905523614322.issue15322@psf.upfronthosting.co.za>
Message-ID: <1342022921.96.0.97943695265.issue15322@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks like a duplicate; I can?t search right now (try sysconfig + build).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15322>
_______________________________________

From report at bugs.python.org  Wed Jul 11 18:11:28 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jul 2012 16:11:28 +0000
Subject: [issue7163] IDLE suppresses sys.stdout.write() return value
In-Reply-To: <1255819083.11.0.568760312973.issue7163@psf.upfronthosting.co.za>
Message-ID: <1342023088.44.0.914755733523.issue7163@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7163>
_______________________________________

From report at bugs.python.org  Wed Jul 11 18:13:03 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Jul 2012 16:13:03 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342023183.21.0.485500030226.issue15320@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Amaury's patch looks obviously fine.

As for the original issue: yes, I thought I saw a traceback once due to that. Using list.pop() (or deque.pop()) instead would probably be good enough.

----------
stage:  -> patch review
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Wed Jul 11 18:17:33 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 11 Jul 2012 16:17:33 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342023453.7.0.871043979732.issue15320@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/issue15320>
_______________________________________

From report at bugs.python.org  Wed Jul 11 18:22:17 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 11 Jul 2012 16:22:17 +0000
Subject: [issue14797] Deprecate imp.find_module()/load_module()
In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za>
Message-ID: <1342023737.84.0.695947327178.issue14797@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/issue14797>
_______________________________________

From report at bugs.python.org  Wed Jul 11 18:45:39 2012
From: report at bugs.python.org (rg3)
Date: Wed, 11 Jul 2012 16:45:39 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1342025139.16.0.0940746846594.issue5815@psf.upfronthosting.co.za>


rg3 <sarbalap+freshmeat at gmail.com> added the comment:

I don't know if the behavior is considered a bug or just undocumented, but under Python 2.7.3 it's still the same. locale.getpreferredencoding() does return UTF-8, but the second element in the tuple locale.getdefaultlocale() is "utf_8_valencia", which is not a valid encoding despite the documentation saying it's supposed to be an encoding name.

>From my terminal:

$ python -V
Python 2.7.3

$ LANG=ca_ES.UTF-8 at valencia python -c 'import locale; print locale.getpreferredencoding()'
UTF-8

$ LANG=ca_ES.UTF-8 at valencia python -c 'import locale; print locale.getdefaultlocale()'
('ca_ES', 'utf_8_valencia')

$ LANG=ca_ES.UTF-8 python -c 'import locale; print locale.getpreferredencoding()'
UTF-8

$ LANG=ca_ES.UTF-8 python -c 'import locale; print locale.getdefaultlocale()'
('ca_ES', 'UTF-8')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Wed Jul 11 19:23:28 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Jul 2012 17:23:28 +0000
Subject: [issue15300] test directory doubly-nested running tests with
	-j/--multiprocess
In-Reply-To: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>
Message-ID: <3WXRvM0mdNzNCJ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 724a6e0e35f0 by Antoine Pitrou in branch '3.2':
Issue #15300: Ensure the temporary test working directories are in the same parent folder when running tests in multiprocess mode from a Python build.
http://hg.python.org/cpython/rev/724a6e0e35f0

New changeset 4752fafb579d by Antoine Pitrou in branch 'default':
Issue #15300: Ensure the temporary test working directories are in the same parent folder when running tests in multiprocess mode from a Python build.
http://hg.python.org/cpython/rev/4752fafb579d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15300>
_______________________________________

From report at bugs.python.org  Wed Jul 11 19:26:57 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Jul 2012 17:26:57 +0000
Subject: [issue15300] test directory doubly-nested running tests with
	-j/--multiprocess
In-Reply-To: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>
Message-ID: <1342027617.36.0.649725236338.issue15300@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
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15300>
_______________________________________

From report at bugs.python.org  Wed Jul 11 21:11:01 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jul 2012 19:11:01 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1342033861.49.0.999717444347.issue5815@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

The patch is not work for "ca_ES at valencia" locale.

And there are issues for such locales: "ks_in at devanagari", "ks_IN at devanagari.UTF-8", "sd", "sd_IN at devanagari.UTF-8" ("ks_in at devanagari" in locale_alias maps to "ks_IN at devanagari.UTF-8" and "sd" to "sd_IN at devanagari.UTF-8").

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Wed Jul 11 21:36:43 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 19:36:43 +0000
Subject: [issue15322] sysconfig.get_config_var('srcdir') returns unexpected
	value
In-Reply-To: <1341972508.31.0.0905523614322.issue15322@psf.upfronthosting.co.za>
Message-ID: <1342035403.92.0.748945178665.issue15322@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I searched a little before.  There is issue 12141, "sysconfig.get_config_vars('srcdir') fails in specific cases," but that issue is closed.

In the comments there, Antoine seems to be describing the bug I describe here, but I'm not sure an issue was filed:

http://bugs.python.org/issue12141#msg136493

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15322>
_______________________________________

From report at bugs.python.org  Wed Jul 11 21:51:34 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 19:51:34 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342036294.62.0.943279862937.issue15318@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

"implements textio badly" is *not* a well-defined issue.

First it is a personal judgement: some think it's really bad, some think it's quite ok.

More importantly, such issue has no clear success criterion: how do we know we are done - can we hope to EVER close such an issue? No, because somebody might still find bad behavior. An issue absolutely needs anobjective test to determine whether it is resolved, and to reproduce it, this is not negotiable. "it behaves badly" provides no test.

In any case,*this* issue is about sys.stdin being writable.

Any objection to checking in my patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 22:17:25 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 20:17:25 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342037845.48.0.440882925166.issue15320@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching a patch for the original issue using deque.

----------
Added file: http://bugs.python.org/file26359/issue-15320-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Wed Jul 11 22:32:42 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jul 2012 20:32:42 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1342036294.62.0.943279862937.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342038796.6314.63.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> In any case,*this* issue is about sys.stdin being writable.

I already got confused with all these closing/reopening/renaming of
issues and floating code. Should I open my own issue even if it
duplicates and supersedes some other?

> Any objection to checking in my patch?

It does not fixes the issue. sys.stdin.writelines does not raise
exception.

Inheritance input file from output file looks very strange.
_RPCInputFile unnecessary, if redirect stdin not on PyShell self, but on
PyShell.stdin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 22:34:45 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Jul 2012 20:34:45 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342038885.4.0.159694342803.issue15320@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, actually the patch is not ok, because of the -F option which uses an infinite iterator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Wed Jul 11 23:21:05 2012
From: report at bugs.python.org (jin)
Date: Wed, 11 Jul 2012 21:21:05 +0000
Subject: [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>
Message-ID: <1342041665.56.0.784989429184.issue13866@psf.upfronthosting.co.za>


jin <jin at mediatomb.cc> added the comment:

I just ran into exactly the same problem and was quite disappointed to see that urlencode does not provide an option to use percent encoding.

My use case: I'm preparing some metadata on the server side that is stored as an url encoded string, the processing is done in python.

The metadata is then deocded by a JavaScript web UI.

So I end up with:
urllib.urlencode({ 'key': 'val with space'}) which produces "key=val+with+space" which of course stays that way after processing it with JavaScript's decodeURI().

So basically I seem to be forced to implement my own urlencode function... Most thing I like about python that it always seems to have exactly what one needs, unfortunately not in this specific case.

IMHO Stephen's suggestion #3 makes a lot of sense, while '+' maybe correct for forms, it's simply not useful for a number of other situations and I was really surprised by the fact that there's no standard function that would url-encode with percentage encoding.

----------
nosy: +jin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________

From report at bugs.python.org  Wed Jul 11 23:29:27 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 21:29:27 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342042167.25.0.0255034837696.issue15318@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Added file: http://bugs.python.org/file26360/blockfile-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 23:30:10 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 21:30:10 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342042210.87.0.459179600286.issue15318@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file26360/blockfile-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 23:32:10 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 21:32:10 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342042330.98.0.425374520761.issue15318@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Added file: http://bugs.python.org/file26361/blockfile-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 11 23:34:40 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 Jul 2012 21:34:40 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1342038796.6314.63.camel@raxxla>
Message-ID: <4FFDF16E.8070102@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I already got confused with all these closing/reopening/renaming of
> issues and floating code. Should I open my own issue even if it
> duplicates and supersedes some other?

I personally think it would be best if these issues where closed
*first*, and only then you submit a patch to fix any remaining issues.

>> Any objection to checking in my patch?
> 
> It does not fixes the issue. sys.stdin.writelines does not raise
> exception.

Ah. See blockfiles-3.diff then.

> Inheritance input file from output file looks very strange.

Where do you see that? In my patch, _RPCInputFile inherits from
_RPCFile, which is neither output nor input. Instead, _RPCOutputFile
also inherits from _RPCFile.

> _RPCInputFile unnecessary, if redirect stdin not on PyShell self, but on
> PyShell.stdin.

It is necessary, as rpc will not communicate the exceptions properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Thu Jul 12 00:10:44 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 22:10:44 +0000
Subject: [issue15329] clarify which deque methods are thread-safe
Message-ID: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think it would help to clarify which collections.deque methods are thread-safe:

http://docs.python.org/dev/library/collections.html?highlight=deque#collections.deque

Currently, the documentation says that "Deques support thread-safe, memory efficient appends and pops from either side...," but it isn't obvious if this is meant to apply to all methods, or just the methods named append*() and pop*().

For example, is rotate() thread-safe?  The illustration given of d.appendleft(d.pop()) seems like it could be interleaved.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 165275
nosy: cjerdonek, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: clarify which deque methods are thread-safe
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15329>
_______________________________________

From report at bugs.python.org  Thu Jul 12 00:20:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 22:20:38 +0000
Subject: [issue15330] allow deque to act as a thread-safe circular buffer
Message-ID: <1342045238.04.0.281063005128.issue15330@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

It seems like it would be useful if collections.deque had a thread-safe method that could rotate(1) and return the rotated value.

This would let deque to act as a thread-safe circular buffer (e.g. if serving jobs to multiple threads in a loop, like `python -m test --forever`).

----------
components: Library (Lib)
messages: 165276
nosy: cjerdonek, rhettinger
priority: normal
severity: normal
status: open
title: allow deque to act as a thread-safe circular buffer
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15330>
_______________________________________

From report at bugs.python.org  Thu Jul 12 02:33:26 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 12 Jul 2012 00:33:26 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342053206.78.0.533392752216.issue15318@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I tested blockfile-3.diff against the latest code in the repository.

sys.stdin.write returns the wrong error message when passed a non-string. Presently it returns io.UnsupportedOperation instead of TypeError: must be str, not ...

The attached blockfile-4.diff incorporates blockfile-3 and creates a decorator in _RPCFile to ensure the argument is a string and applies it to the _RPCInputFile and _RPCOutputFile write methods.

A simpler alternative would be duplicating the string check code in _RPCInputFile before the raise statement.

----------
Added file: http://bugs.python.org/file26362/blockfile-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Thu Jul 12 03:29:24 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 01:29:24 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342056564.66.0.975465249169.issue15320@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Good catch.  Here is a patch that takes --forever mode into account.

I wrote this patch with the assumption that it shouldn't hurt if multiple threads call deque.extend() at the same time.

----------
Added file: http://bugs.python.org/file26363/issue-15320-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Thu Jul 12 07:23:32 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 05:23:32 +0000
Subject: [issue15330] allow deque to act as a thread-safe circular buffer
In-Reply-To: <1342045238.04.0.281063005128.issue15330@psf.upfronthosting.co.za>
Message-ID: <1342070612.92.0.181783854775.issue15330@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
priority: normal -> low
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15330>
_______________________________________

From report at bugs.python.org  Thu Jul 12 07:27:02 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 05:27:02 +0000
Subject: [issue15330] allow deque to act as a thread-safe circular buffer
In-Reply-To: <1342045238.04.0.281063005128.issue15330@psf.upfronthosting.co.za>
Message-ID: <1342070822.59.0.4183377982.issue15330@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

By thread-safe you mean that the operation should be atomic?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15330>
_______________________________________

From report at bugs.python.org  Thu Jul 12 07:29:21 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 05:29:21 +0000
Subject: [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342070961.76.0.478069560807.issue15329@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/issue15329>
_______________________________________

From report at bugs.python.org  Thu Jul 12 07:37:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 05:37:56 +0000
Subject: [issue15330] allow deque to act as a thread-safe circular buffer
In-Reply-To: <1342045238.04.0.281063005128.issue15330@psf.upfronthosting.co.za>
Message-ID: <1342071476.96.0.0156991195654.issue15330@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Yes, atomic. I was under the impression that the existing deque.rotate() is atomic, in which case deque.rotate(1) almost provides what I'm suggesting (lacking only the return value).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15330>
_______________________________________

From report at bugs.python.org  Thu Jul 12 07:47:01 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 05:47:01 +0000
Subject: [issue15330] allow deque to act as a thread-safe circular buffer
In-Reply-To: <1342045238.04.0.281063005128.issue15330@psf.upfronthosting.co.za>
Message-ID: <1342072021.2.0.258514779346.issue15330@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We make almost no guarantees about atomicity.  If something in CPython happens to be atomic, it is not guaranteed to hold in other implementations.   The recommendation is to use locks anywhere you need a critical section of code.

FWIW, the term thread-safe is taken to mean, "won't break in a multi-threaded environment".  That is a bit different from atomic.  For example, the decimal module was designed with thread local contexts, but there are no atomic decimal operations.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15330>
_______________________________________

From report at bugs.python.org  Thu Jul 12 08:04:48 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 06:04:48 +0000
Subject: [issue15330] allow deque to act as a thread-safe circular buffer
In-Reply-To: <1342045238.04.0.281063005128.issue15330@psf.upfronthosting.co.za>
Message-ID: <1342073088.8.0.684923361697.issue15330@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks for the info.  A couple questions: what does "won't break" mean -- that it won't throw an exception of a type that it wouldn't normally throw in a single-threaded environment?  And does this mean that not even deque.pop() is atomic?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15330>
_______________________________________

From report at bugs.python.org  Thu Jul 12 08:17:05 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 06:17:05 +0000
Subject: [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342073825.15.0.242851356401.issue15329@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I think some of the information in the issue 15330 comments would be very helpful to add as well (what thread-safe means in Python, distinction between thread-safe and atomic, and which deque methods are thread-safe and/or atomic).

If some of that information is too general for the collections library, perhaps some of it can go in a section of the Python documentation about multithreading (the glossary?), and then be linked to there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15329>
_______________________________________

From report at bugs.python.org  Thu Jul 12 09:21:42 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Jul 2012 07:21:42 +0000
Subject: [issue15188] test_ldshared_value failure on OS X using python.org
	Pythons
In-Reply-To: <1340693547.43.0.234356884387.issue15188@psf.upfronthosting.co.za>
Message-ID: <1342077702.42.0.222346405545.issue15188@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The resolution of this test failure is dependent on the resolution of Issue15298, which will change the approach needed.  Since this is a relatively minor issue, I don't think there is a need for a interim fix.

----------
components: +Tests
priority: high -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15188>
_______________________________________

From report at bugs.python.org  Thu Jul 12 09:27:52 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Jul 2012 07:27:52 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>
Message-ID: <1342078072.95.0.438995939196.issue15298@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Once this issue is resolved, a permanent fix for the minor OS X test case failure of Issue15188 can be developed and applied.)

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15298>
_______________________________________

From report at bugs.python.org  Thu Jul 12 09:30:00 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Jul 2012 07:30:00 +0000
Subject: [issue15188] test_ldshared_value failure on OS X using python.org
	Pythons
In-Reply-To: <1340693547.43.0.234356884387.issue15188@psf.upfronthosting.co.za>
Message-ID: <1342078200.34.0.405493472467.issue15188@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
dependencies: +_sysconfigdata is generated in srcdir, not builddir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15188>
_______________________________________

From report at bugs.python.org  Thu Jul 12 09:46:43 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 12 Jul 2012 07:46:43 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342079203.68.0.315626540829.issue15320@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> I wrote this patch with the assumption that it shouldn't hurt
> if multiple threads call deque.extend() at the same time.

By looking at the implementation, I found that if multiple threads call dequeue.extend() at the same time, all items will be added, but the order is not deterministic.
It probably does not matter for tests.

In any case, I think we should not rely on this specific implementation.  We should document which functions are safe to use in a multithreading environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Thu Jul 12 09:46:53 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 12 Jul 2012 07:46:53 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>
Message-ID: <1342079213.38.0.923766495741.issue15302@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please leave this for Python 3.4 -- it is not a bugfix.

----------
nosy: +georg.brandl
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Thu Jul 12 10:28:15 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 08:28:15 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342081695.91.0.394472775508.issue15320@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

That sounds fine.  And thanks for investigating.

By the way, I created issue 15329 earlier today to clarify what guarantees deque provides with respect to multithreading.  For example, the distinction between thread-safe and atomic is not currently mentioned.  As you observed, deque.extend() is not atomic but I'm guessing is probably considered safe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Thu Jul 12 10:57:19 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Jul 2012 08:57:19 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342083439.2.0.676926398585.issue15307@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I think you're right that the casts are incorrect.  I think the existing cast ia a day one bug in Python 3.  The question is why hasn't it been a problem?  That area needs fixing up since NSModuleForSymbol, NSLookupAndBindSymbol, and NSLibraryNameForModule are now deprecated interfaces.  Also, in the patch, shouldn't the wcsncpy be followed by a wcscpy(tmpbuffer, argv0_path) as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Thu Jul 12 11:06:51 2012
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 12 Jul 2012 09:06:51 +0000
Subject: [issue15189] tkinter.messagebox does not use the application's icon
In-Reply-To: <1340695188.66.0.13086714969.issue15189@psf.upfronthosting.co.za>
Message-ID: <1342084011.17.0.175871135986.issue15189@psf.upfronthosting.co.za>


Mark Summerfield <mark at qtrac.eu> added the comment:

I think there is a solution to this that can be applied in one's own code:

app = tkinter.Tk()
icon = tkinter.PhotoImage(file="icon.gif")
app.tk.call("wm", "iconphoto", app, "-default", icon)

According to the docs (and it seems to be true), the icon thus set will be used for *all* the applications top-level windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15189>
_______________________________________

From report at bugs.python.org  Thu Jul 12 11:13:19 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Jul 2012 09:13:19 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <4FFDF16E.8070102@v.loewis.de>
Message-ID: <1342084428.14309.33.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Ah. See blockfiles-3.diff then.

Well, I have no objections. Patch fixes this issue.

> Where do you see that? In my patch, _RPCInputFile inherits from
> _RPCFile, which is neither output nor input. Instead, _RPCOutputFile
> also inherits from _RPCFile.

I made a mistake. I mean PseudoInputFile, but it just monkey-patched.

> > _RPCInputFile unnecessary, if redirect stdin not on PyShell self, but on
> > PyShell.stdin.
> It is necessary, as rpc will not communicate the exceptions properly.

Yes, this is yet another issue. Rpc not communicates properly only
OSError. Remove "except socket.error: raise" in SocketIO.localcall in
Lib/idlelib/rpc.py and io.UnsupportedOperation will transparently
transfered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Thu Jul 12 11:13:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Jul 2012 09:13:45 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1342053206.78.0.533392752216.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342084453.14309.35.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> sys.stdin.write returns the wrong error message when passed a non-string. Presently it returns io.UnsupportedOperation instead of TypeError: must be str, not ...

It's not a bug. sys.stdin.write raises io.UnsupportedOperation in
standard interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Thu Jul 12 11:44:26 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Jul 2012 09:44:26 +0000
Subject: [issue7163] IDLE suppresses sys.stdout.write() return value
In-Reply-To: <1255819083.11.0.568760312973.issue7163@psf.upfronthosting.co.za>
Message-ID: <1342086266.59.0.454698051115.issue7163@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Reply to Roger's emailed answer to my Rietveld comment.

> On 07/11/2012 11:10 AM, storchaka at gmail.com wrote:
> > http://bugs.python.org/review/7163/diff/4367/Lib/idlelib/OutputWindow.py
> > File Lib/idlelib/OutputWindow.py (right):
> >
> > http://bugs.python.org/review/7163/diff/4367/Lib/idlelib/OutputWindow.py#newcode43
> > Lib/idlelib/OutputWindow.py:43: return len(s)
> > write() should return count of bytes if argument is bytes.
> Only strings should be passed into the write method in 3.3. The  code 
> for decoding bytes is a historical artifact that should be removed. You 
> can witness this evolution by using hgtk datamine.

We can ask the author.

Martin, why OutputWindow.write accepts bytes in a724279fc931? Should it be deleted if it is deprecated artifact or should OutputWindow.write return bytes count for bytes if it will return character count for string?

> On 2.7, byte counts (AFAIK)  are not returned for sys.stdout.write.

On Python2 sys.stdout.write does not returns any count.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7163>
_______________________________________

From report at bugs.python.org  Thu Jul 12 12:22:13 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 12 Jul 2012 10:22:13 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342088533.35.0.963892747906.issue15307@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The current code works, and I don't understand why it does.

I'd love to get rid of the long deprecated APIs like NSModuleForSymbol as well, but we'll have to ask the RM if that is an acceptable change at this point in the 3.3 release process.

BTW. Is adding symlink support on OSX a bug fix or a new feature? I'd prefer to treat this a bug fix, framework builds currently don't support the --symlinks option while they easily could do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Thu Jul 12 13:04:34 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 12 Jul 2012 11:04:34 +0000
Subject: [issue15331] Missing codec aliases for bytes-bytes codecs
Message-ID: <1342091074.63.0.386956250979.issue15331@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

In writing a post looking at a potentially different way of handling codec pipelines that is source compatible across both Python 2 and 3, I noticed that the bytes-bytes codec aliases are all missing but are still listed in the documentation as being supported:

base64_codec 	base64, base-64
bz2_codec 	bz2
hex_codec 	hex

quopri_codec 	quopri, quoted-printable, quotedprintable
uu_codec 	uu
zlib_codec 	zip, zlib

The canonical names (i.e. *_codec) all work as expected, though.

----------
messages: 165295
nosy: ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Missing codec aliases for bytes-bytes codecs
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15331>
_______________________________________

From report at bugs.python.org  Thu Jul 12 13:21:35 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 12 Jul 2012 11:21:35 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <1342092095.14.0.231651886537.issue15238@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

The patch looks good enough. Not sure if we should write Linux though. I sincerely hope we?ll support xattrs on other OSes soonish.

Did you catch Georg somewhere whether this can still go in? Would be nice as xattrs are new to 3.3. Changing this in 3.4 would be rather unfortunate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Thu Jul 12 13:25:16 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 12 Jul 2012 11:25:16 +0000
Subject: [issue15180] Cryptic traceback from os.path.join when mixing str &
	bytes
In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za>
Message-ID: <1342092316.06.0.229710691944.issue15180@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

I didn?t, because I pulled an Antoine and enjoyed weather, people and Florence. :)

I understand it?s okay to apply this towards 3.2 & 3.3 (with the proposed fixes)?

2.7 is not necessary because this problem doesn?t exist there:

> os.path.join(b'foo', u'bar')
u'foo/bar'

Introducing explicit sanity checks there would cause people wanting to eat our hearts. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15180>
_______________________________________

From report at bugs.python.org  Thu Jul 12 13:36:15 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 12 Jul 2012 11:36:15 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <1342092975.79.0.369175094527.issue15238@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yeah, good to go.  But please re-insert a blank line in the test suite changes after the end of the method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Thu Jul 12 13:47:35 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 12 Jul 2012 11:47:35 +0000
Subject: [issue7163] IDLE suppresses sys.stdout.write() return value
In-Reply-To: <1342086266.59.0.454698051115.issue7163@psf.upfronthosting.co.za>
Message-ID: <20120712134734.Horde.IT1iUUlCcOxP-rlWbzvET8A@webmail.df.eu>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> We can ask the author.
>
> Martin, why OutputWindow.write accepts bytes in a724279fc931?

That change was to add support for str8, a type that no longer exists.

> Should it be deleted if it is deprecated artifact or should  
> OutputWindow.write return bytes count for bytes if it will return  
> character count for string?

The general design guideline apparently is that sys.stdout in IDLE
should work the same as the interactive shell.

Since the interactive shell doesn't support bytes (and gives a TypeError),
so should IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7163>
_______________________________________

From report at bugs.python.org  Thu Jul 12 14:30:35 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Jul 2012 12:30:35 +0000
Subject: [issue7163] IDLE suppresses sys.stdout.write() return value
In-Reply-To: <20120712134734.Horde.IT1iUUlCcOxP-rlWbzvET8A@webmail.df.eu>
Message-ID: <1342096267.14596.24.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> That change was to add support for str8, a type that no longer exists.

str8 was renamed to bytes in 0d462d789b18.

> The general design guideline apparently is that sys.stdout in IDLE
> should work the same as the interactive shell.
> 
> Since the interactive shell doesn't support bytes (and gives a TypeError),
> so should IDLE.

Now OutputWindow is not sys.stdout and sys.stdout has own argument
check. If someone uses OutputWindow directly (not sys.stdout) as output
_binary_ file (because OutputWindow supports binary output), then he
would be expected that write will return the number of written bytes.
Can we break those expectations?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7163>
_______________________________________

From report at bugs.python.org  Thu Jul 12 14:56:20 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 Jul 2012 12:56:20 +0000
Subject: [issue15328] datetime.strptime slow
In-Reply-To: <1342015221.25.0.0683472526459.issue15328@psf.upfronthosting.co.za>
Message-ID: <1342097780.17.0.682926699067.issue15328@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15328>
_______________________________________

From report at bugs.python.org  Thu Jul 12 15:50:11 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 12 Jul 2012 13:50:11 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342101011.39.0.776604439246.issue15307@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've attached a new version of the patch:

* copy to tmp buffer instead of argv0_buffer (see comment by Ned)

* add include in pythonw.c to avoid compiler warning

* use _Py_char2wchar instead of blindly casting a char* to a wchar_t*


The behavior is not perfect yet, sys.executable is set to the wrong value (both with and without --symlinks).  I haven't checked yet if the value is correct without my patch.

----------
Added file: http://bugs.python.org/file26364/venv-symlinks-v2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Thu Jul 12 16:28:02 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Jul 2012 14:28:02 +0000
Subject: [issue15331] Missing codec aliases for bytes-bytes codecs
In-Reply-To: <1342091074.63.0.386956250979.issue15331@psf.upfronthosting.co.za>
Message-ID: <1342103282.83.0.0890657558557.issue15331@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Don't you have to resolve issue 7475 before you can add them, though?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15331>
_______________________________________

From report at bugs.python.org  Thu Jul 12 16:44:43 2012
From: report at bugs.python.org (Jakub Wilk)
Date: Thu, 12 Jul 2012 14:44:43 +0000
Subject: [issue15332] 2to3 should fix bad indentation (or warn about it)
Message-ID: <1342104283.46.0.0298718422519.issue15332@psf.upfronthosting.co.za>


New submission from Jakub Wilk <jwilk at jwilk.net>:

Python 3 is more rigid about mixing tabs and spaces within a single file. 2to3 should either fix indentation that would become a syntax error in Python 3.X, or maybe issue a warning about it (or both).

Example:

$ python badtabs.py && echo okay
okay

$ 2to3 badtabs.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: No files need to be modified.

$ python3 badtabs.py && echo okay
  File "badtabs.py", line 3
    'b'
      ^
TabError: inconsistent use of tabs and spaces in indentation

----------
components: 2to3 (2.x to 3.x conversion tool)
files: badtabs.py
messages: 165303
nosy: jwilk
priority: normal
severity: normal
status: open
title: 2to3 should fix bad indentation (or warn about it)
Added file: http://bugs.python.org/file26365/badtabs.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15332>
_______________________________________

From report at bugs.python.org  Thu Jul 12 16:47:01 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 12 Jul 2012 14:47:01 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342104421.98.0.940140499192.issue15307@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

based on code inspection I'd say that sys.executable was broken without my patch as well. The code that sets that value is unchanged from Python 3.2, and that points to the executable inside the Python.app application bundle.

I've attached v3 of my patch, that ensures that sys.executable is the path used to start the executable. This gives points to the right executable when using venv and is a nicer (and arguably better) result outside of vent's as well.

There should probably be new tests as well that test that sys.executable has the right value in a venv.

----------
Added file: http://bugs.python.org/file26366/venv-symlinks-v3.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Thu Jul 12 17:03:02 2012
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 12 Jul 2012 15:03:02 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <1342105382.36.0.717697587722.issue15238@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Georg: done.

Hynek: You must forgive me, I'm a recovering Windows programmer.  I thought extended attributes were a Linux-only thing.  Can you tell me what other platforms they are available on?  And/or suggest some alternate language?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Thu Jul 12 17:03:34 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 15:03:34 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342105414.98.0.440261205596.issue15320@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Why not use locks to guard critical sections rather than relying on implementation details regarding atomicity?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Thu Jul 12 17:05:19 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 12 Jul 2012 15:05:19 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1342084453.14309.35.camel@raxxla>
Message-ID: <4FFEE7AA.1060101@gmail.com>


Roger Serwy <roger.serwy at gmail.com> added the comment:

On 07/12/2012 04:13 AM, Serhiy Storchaka wrote:
> Serhiy Storchaka<storchaka at gmail.com>  added the comment:
>
>> sys.stdin.write returns the wrong error message when passed a non-string. Presently it returns io.UnsupportedOperation instead of TypeError: must be str, not ...
> It's not a bug. sys.stdin.write raises io.UnsupportedOperation in
> standard interpreter.

Here's what I get from the standard interpreter:

     Python 3.3.0b1 (default:4752fafb579d, Jul 11 2012, 22:05:03)
     [GCC 4.5.2] on linux
     Type "help", "copyright", "credits" or "license" for more information.
 >>> import sys
 >>> sys.stdin.write(123)
     Traceback (most recent call last):
       File "<stdin>", line 1, in <module>
     TypeError: must be str, not int
 >>>

> ----------
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue15318>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Thu Jul 12 17:10:49 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 15:10:49 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342105849.2.0.665345798915.issue15320@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Yes, that is what I took Amaury's comment to mean.  I started working on a patch that incorporates a lock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Thu Jul 12 17:32:21 2012
From: report at bugs.python.org (Andrew MacKeith)
Date: Thu, 12 Jul 2012 15:32:21 +0000
Subject: [issue15333] import on Windows will recompile a pyc file created on
	Unix
Message-ID: <1342107141.38.0.530565804719.issue15333@psf.upfronthosting.co.za>


New submission from Andrew MacKeith <andrew at mackeith.net>:

In certain cases, a compiled Python file (.pyc) created on Unix will be recompiled when imported on Windows, despite the original code file (.py) being the same.
The cause is the use of the c fstat function in import.c.

This behavior is contrary to the stated Python behavior that a precompiled Python file is portable between platforms.

The fix to this bug would be to use the posixmodule stat implementation in place of fstat in import.c.

An example is the following, in Python 2.6.2:

This was tested on July 11th, 2012, USA EDT 
(i.e. DST is in effect, and local time is GMT - 6 hours). 
Lib/re.py has a mtime of 01/01/2009  11:46 AM according to Windows DIR.

Windows fstat st_mtime returns 1230828370 (0x495cf352) 16:46 GMT
Linux   fstat st_mtime returns 1230824770 (0x495ce542) 15:46 GMT

The effect of this is that when import opens the .pyc file and reads the mtime (the 2nd 4-byte field of the .pyc file) it sees it as "bad" and therefore recompiles the file.

The Python os.stat function works correctly on both Windows and Unix. There is a note in posixmodule.c that warns of a problem with Windows fstat:
"""
#ifdef MS_WINDOWS
/* The CRT of Windows has a number of flaws wrt. its stat() implementation:
   - time stamps are restricted to second resolution
   - file modification times suffer from forth-and-back conversions between
     UTC and local time
   Therefore, we implement our own stat, based on the Win32 API directly.
*/
"""

A Python file can also be precompiled using py_compile.compile; this uses os.stat to get the mtime of the .py file, and writes that to the .pyc file. 
This has the Unix behavior, and is "correct".

Output from time functions on Linux:
(The results are the same on Windows)

>>> print time.gmtime(0x495ce542)
time.struct_time(tm_year=2009, tm_mon=1, tm_mday=1, tm_hour=15, tm_min=46, tm_sec=10, tm_wday=3, tm_yday=1, tm_isdst=0)

>>> print time.localtime(0x495ce542)
time.struct_time(tm_year=2009, tm_mon=1, tm_mday=1, tm_hour=10, tm_min=46, tm_sec=10, tm_wday=3, tm_yday=1, tm_isdst=0)

>>> print time.gmtime(0x495cf352)
time.struct_time(tm_year=2009, tm_mon=1, tm_mday=1, tm_hour=16, tm_min=46, tm_sec=10, tm_wday=3, tm_yday=1, tm_isdst=0)

>>> print time.localtime(0x495cf352)
time.struct_time(tm_year=2009, tm_mon=1, tm_mday=1, tm_hour=11, tm_min=46, tm_sec=10, tm_wday=3, tm_yday=1, tm_isdst=0)

>>>

There has been no change in the relevant import.c code between Python-2.6 and Python-3.3.

X:\work\testimportmtime>c:\python26\python
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> print platform.platform()
Windows-post2008Server-6.1.7601-SP1
>>> print platform.architecture()
('64bit', 'WindowsPE')
>>> print platform.python_compiler()
MSC v.1500 64 bit (AMD64)

----------
components: Interpreter Core
files: testImportRe.py
messages: 165309
nosy: mackeith
priority: normal
severity: normal
status: open
title: import on Windows will recompile a pyc file created on Unix
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26367/testImportRe.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15333>
_______________________________________

From report at bugs.python.org  Thu Jul 12 17:37:00 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 12 Jul 2012 15:37:00 +0000
Subject: [issue15333] import on Windows will recompile a pyc file created on
	Unix
In-Reply-To: <1342107141.38.0.530565804719.issue15333@psf.upfronthosting.co.za>
Message-ID: <1342107420.8.0.654801255272.issue15333@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Is this the same issue as issue #13863?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15333>
_______________________________________

From report at bugs.python.org  Thu Jul 12 17:37:18 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 15:37:18 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342107438.16.0.632790017457.issue15320@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, that is what I took Amaury's comment to mean. I started working on a patch that incorporates a lock.

For the sake of clarity, I think Raymond suggests using a lock in regrtest, not in deque.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Thu Jul 12 17:40:55 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 15:40:55 +0000
Subject: [issue15333] import on Windows will recompile a pyc file created on
	Unix
In-Reply-To: <1342107141.38.0.530565804719.issue15333@psf.upfronthosting.co.za>
Message-ID: <1342107655.95.0.46996324182.issue15333@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is this the same issue as issue #13863?

Judging by Andrew's diagnosis, I think so.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> import.c sometimes generates incorrect timestamps on Windows + NTFS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15333>
_______________________________________

From report at bugs.python.org  Thu Jul 12 17:42:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 15:42:13 +0000
Subject: [issue13863] import.c sometimes generates incorrect timestamps on
	Windows + NTFS
In-Reply-To: <1327519681.79.0.252690630069.issue13863@psf.upfronthosting.co.za>
Message-ID: <1342107733.05.0.858914732854.issue13863@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It shouldn't affect 3.3 anymore (importlib using the os module rather than direct C calls to msvcrt). Could someone check?

----------
nosy: +mackeith
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13863>
_______________________________________

From report at bugs.python.org  Thu Jul 12 17:45:47 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 15:45:47 +0000
Subject: [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342107947.01.0.0483144600568.issue15329@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think you're over-reaching.   We make almost no guarantees about atomicity.  Having multiple implementations of Python makes that an even harder task.  

In general, critical sections need to be guarded with locks.  If an object claims to be thread-safe, it means that it has used locks (perhaps relying on the GIL) to guard its own critical sections.  

Almost any pure Python class with complex state and without locks is not thread-safe (for example, an insertion into an OrderedDict needs to update the two dicts and a doubly-linked list).

Classes written in C are necessarily thread-safe (they rely on the GIL) or else they would risk segfaulting.  Other implementations are free to make different decisions about which classes are thread-safe. Pypy tends to make fewer guarantees because it implements more classes in pure python.  Jython tends to make strong guarantees because it uses Java's concurrent mappings and other such tools.

For the most part, the docs have done the right thing by not making any promises.  It might be helpful though to have a HOWTO guide explaining the facts-of-life when doing multi-threading (i.e. don't assume anything is atomic or thread-safe unless explicitly promised and don't expect many such promises).

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15329>
_______________________________________

From report at bugs.python.org  Thu Jul 12 17:58:39 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 15:58:39 +0000
Subject: [issue15330] allow deque to act as a thread-safe circular buffer
In-Reply-To: <1342045238.04.0.281063005128.issue15330@psf.upfronthosting.co.za>
Message-ID: <1342108719.54.0.72520302035.issue15330@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> A couple questions: what does "won't break" mean 

That means that its internal invariants always survive in a multi-threaded environment.

> that it won't throw an exception of a type that it 
> wouldn't normally throw in a single-threaded environment? 

Unless that exception is being raised to indicate that a resource is in  use (much that same as a database notifying you that it can't make a change because the DB is currently locked).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15330>
_______________________________________

From report at bugs.python.org  Thu Jul 12 18:04:38 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Jul 2012 16:04:38 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1342109078.31.0.0954900336147.issue15318@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

>>> sys.stdin.write('qwe')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: not writable

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Thu Jul 12 18:05:12 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 12 Jul 2012 16:05:12 +0000
Subject: [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342109112.94.0.31529022692.issue15329@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Pypy tends to make fewer guarantees because it implements 
> more classes in pure python.

This is not exactly true; in PyPy the _collection module was rewritten in RPython (which is translated to C) for this very reason: to make dequeue.append atomic and thus thread-safe.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15329>
_______________________________________

From report at bugs.python.org  Thu Jul 12 18:10:45 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 16:10:45 +0000
Subject: [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342109445.59.0.192734743932.issue15329@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Classes written in C are necessarily thread-safe (they rely on the GIL)

That's not really true. A single Py_DECREF() can release the GIL by way of executing a Python __del__ method (or a weakref callback, or even the tp_dealloc of a file object that happens to release the GIL when close()ing the underlying file descriptor) somewhere along the reference chain, as evidenced by Amaury in http://bugs.python.org/issue15320#msg165253

I think that if the deque documentation makes the claim that some methods are thread-safe, they should be *really* thread-safe (which doesn't necessarily imply a lock, but implies being extra careful). Otherwise it's better to remove the claim from the docs.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15329>
_______________________________________

From report at bugs.python.org  Thu Jul 12 18:14:13 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 12 Jul 2012 16:14:13 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1342109078.31.0.0954900336147.issue15318@psf.upfronthosting.co.za>
Message-ID: <4FFEF7D1.7080003@gmail.com>


Roger Serwy <roger.serwy at gmail.com> added the comment:

>>>> sys.stdin.write('qwe')
> Traceback (most recent call last):
>    File "<stdin>", line 1, in<module>
> io.UnsupportedOperation: not writable
>
> ----------

I'm passing a number, *not* a string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Thu Jul 12 18:24:12 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Thu, 12 Jul 2012 16:24:12 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
Message-ID: <1342110252.89.0.365330670645.issue15334@psf.upfronthosting.co.za>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

The registry key HKEY_PERFORMANCE_DATA is not accessible for non-interactive users (e.g., buildbot as a service).

The following patches skip the offending test when the tests unless the they are run from an interactive session.

----------
components: Tests, Windows
files: winreg-2.x.diff
keywords: patch
messages: 165320
nosy: jkloth
priority: normal
severity: normal
status: open
title: access denied for HKEY_PERFORMANCE_DATA
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26368/winreg-2.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Thu Jul 12 18:24:38 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Thu, 12 Jul 2012 16:24:38 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
In-Reply-To: <1342110252.89.0.365330670645.issue15334@psf.upfronthosting.co.za>
Message-ID: <1342110278.27.0.594686284919.issue15334@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


Added file: http://bugs.python.org/file26369/winreg-3.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Thu Jul 12 18:29:15 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 16:29:15 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
In-Reply-To: <1342110252.89.0.365330670645.issue15334@psf.upfronthosting.co.za>
Message-ID: <1342110555.97.0.206661936226.issue15334@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, stutzbach, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Thu Jul 12 18:42:54 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 12 Jul 2012 16:42:54 +0000
Subject: [issue15335] IDLE - debugger steps through run.py internals
Message-ID: <1342111374.05.0.899363686539.issue15335@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

The IDLE debugger steps through the internals of _RPCFile.

To reproduce this bug, create a new .py file with a few print statements, enable the debugger, and then run the file. Stepping through the print statement enters into _RPCFile.

----------
components: IDLE
messages: 165321
nosy: loewis, serwy, storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - debugger steps through run.py internals
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15335>
_______________________________________

From report at bugs.python.org  Thu Jul 12 18:54:34 2012
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 12 Jul 2012 16:54:34 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>
Message-ID: <1342112074.56.0.51154464225.issue15298@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

while I appreciate the fix for #13150, it's the patch for #13150 which introduces the ugliness to build the file in the srcdir in the first place.

re-setting the bug severity. the current behaviour can result in a bogus installation; please let the release manager decide on it.

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15298>
_______________________________________

From report at bugs.python.org  Thu Jul 12 18:58:08 2012
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 12 Jul 2012 16:58:08 +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: <1342112288.19.0.260712002497.issue13150@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

the current ability to cross-build python now relies on being able to run the build python with the host library, using the _sysconfigdata.py from the host.

if somebody decides to implement _sysconfigdata as a C extension, please ensure that this information still can be passed to the build python.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13150>
_______________________________________

From report at bugs.python.org  Thu Jul 12 19:18:06 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 17:18:06 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>
Message-ID: <1342113486.53.0.174289221036.issue15298@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/issue15298>
_______________________________________

From report at bugs.python.org  Thu Jul 12 19:18:22 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 12 Jul 2012 17:18:22 +0000
Subject: [issue15335] IDLE - debugger steps through run.py internals
In-Reply-To: <1342111374.05.0.899363686539.issue15335@psf.upfronthosting.co.za>
Message-ID: <1342113502.72.0.820398778953.issue15335@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Debugger.py has a method "in_rpc_code" which ultimately prevents stepping though code from rpc.py. (Presently an external file named "rpc.py" can not be debugged using IDLE.)

Adding "run.py" to the check would prevent run.py from being stepped, but it applies to *any* "run.py" in the filename string:

        elif frame.f_code.co_filename.count('run.py'):
            return True

Or, you could check the name:

        elif frame.f_globals.get('__name__','') == 'idlelib.run':
            return True

Any additional logic for "in_rpc_code" can slow down code performance when debugging.

Another possible approach is to move the _RPCFile into rpc.py add additional methods to RPCHandler, like "get_remote_stdout_proxy".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15335>
_______________________________________

From report at bugs.python.org  Thu Jul 12 19:31:32 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 12 Jul 2012 17:31:32 +0000
Subject: [issue15335] IDLE - debugger steps through run.py internals
In-Reply-To: <1342111374.05.0.899363686539.issue15335@psf.upfronthosting.co.za>
Message-ID: <1342114292.14.0.860034476995.issue15335@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I suggest to add a decorator @Debugger.internal for all methods that the debugger should not step into. It should set a function attribute that the debugger then checks for.

OTOH, I fail to see the problem. Stepping through the standard library may be useful, and if you don't want to do that, you can choose to step over still.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15335>
_______________________________________

From report at bugs.python.org  Thu Jul 12 19:36:19 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 12 Jul 2012 17:36:19 +0000
Subject: [issue15332] 2to3 should fix bad indentation (or warn about it)
In-Reply-To: <1342104283.46.0.0298718422519.issue15332@psf.upfronthosting.co.za>
Message-ID: <1342114579.12.0.445880437195.issue15332@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You can already find this using "python -tt" and fix it using reindent.py.

----------
nosy: +benjamin.peterson
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15332>
_______________________________________

From report at bugs.python.org  Thu Jul 12 20:39:30 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Jul 2012 18:39:30 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <1342118370.99.0.0684975193558.issue15238@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

See open Issue12978.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Thu Jul 12 20:54:21 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 12 Jul 2012 18:54:21 +0000
Subject: [issue6858] This is a python file, apply syntax highlighting
In-Reply-To: <1252364873.43.0.809885579905.issue6858@psf.upfronthosting.co.za>
Message-ID: <1342119261.88.0.173821554089.issue6858@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Attached is a patch to allow toggling of the ColorDelegator. It can be toggled using the existing, but undocumented, Control-/ binding. 

The patch modifies the "toggle_colorize_event" to fully remove coloring or fully recolorize the text rather than its existing behavior of disabling/enabling the coloring "thread." It also ensures that a ColorDelegator instance exists in every editor window instead of only those where ispythonsource returns True.

Toggling also works in the shell, but turning highlighting off fails if you start typing again. This is due to issue13495.

The crashing of IDLE described by Tal is likely due to pythonw.exe and is addressed in issue13582.

----------
keywords: +patch
nosy: +serwy
stage:  -> patch review
versions: +Python 3.3
Added file: http://bugs.python.org/file26370/issue6858.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6858>
_______________________________________

From report at bugs.python.org  Thu Jul 12 21:18:54 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Jul 2012 19:18:54 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <3WY6Q54FwMzP6k@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset afdb0e1a9dac by Stefan Krah in branch 'default':
Issue #7652: Clean up _mpd_qinvroot() and mark it LIBMPDEC_ONLY. Use the
http://hg.python.org/cpython/rev/afdb0e1a9dac

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Jul 12 21:40:12 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 12 Jul 2012 19:40:12 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1342122012.27.0.48067597802.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I switched the algorithm in mpd_qsqrt() to the one from decimal.py.
Previously the square root was calculated in terms of 1/invsqrt(x).

Curiously enough this scheme _always_ seems to produce exact results
when expected, but I don't have a proof. I remember I left this in because the specification gives some leeway with respect to exact
results:


"Square-root can also be calculated by using the power operation (with a second operand of 0.5). The result in that case will not be exact in most cases, and may not be correctly rounded."


Anyway, the algorithm from decimal.py gives the desired guarantees
and is also faster.


Since we're almost in beta-2 stage, would someone be able to do a
post commit review of mpd_qsqrt()? It should be a direct translation
from the function in decimal.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Jul 12 21:43:34 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 19:43:34 +0000
Subject: [issue15336] Argparse required arguments incorrectly displayed as
	optional arguments
Message-ID: <1342122214.84.0.306915245284.issue15336@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

In this script, '-x' is required argument:
------------------------------------------
import argparse
p = argparse.ArgumentParser()
p.add_argument('-x', required=True)
p.print_help()

However, the automatically generated help shows it as optional:
---------------------------------------------------------------
usage: ap_demo.py [-h] -x X

optional arguments:
  -h, --help  show this help message and exit
  -x X

----------
components: Library (Lib)
messages: 165331
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Argparse required arguments incorrectly displayed as optional arguments
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15336>
_______________________________________

From report at bugs.python.org  Thu Jul 12 21:48:11 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 19:48:11 +0000
Subject: [issue15337] The cmd module incorrectly lists "help" as an undocument
	command
Message-ID: <1342122491.31.0.595399950091.issue15337@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The following minimal script:
-----------------------------
import cmd
class C(cmd.Cmd): pass
C().cmdloop()

Creates the following help display:
-----------------------------------
(Cmd) help

Undocumented commands:
======================
help

For people who are consistently documenting their other commands, it is annoying to have anything at all listed in the "undocumented section".  So, help should have it's own default help message.

----------
components: Library (Lib)
keywords: easy
messages: 165332
nosy: rhettinger
priority: normal
severity: normal
status: open
title: The cmd module incorrectly lists "help" as an undocument command
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15337>
_______________________________________

From report at bugs.python.org  Thu Jul 12 22:42:41 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 20:42:41 +0000
Subject: [issue15338] test_UNC_path failure in test_import
Message-ID: <1342125761.76.0.749174282002.issue15338@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

On the Win64 buildbot, trying to access an UNC path raises PermissionError, which makes a test fail:

======================================================================
ERROR: test_UNC_path (test.test_import.PathsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_import.py", line 469, in test_UNC_path
    os.listdir(unc)
PermissionError: [Error 5] Access is denied: '\\\\hades\\D$\\buildbot.python.org\\3.x.kloth-win64\\build\\build\\test_python_3612\\@test_3612_tmp\\*.*'


If this is expected or normal, maybe we should simply skip the test when the listdir() call above fails.

----------
components: Library (Lib), Tests, Windows
messages: 165333
nosy: brian.curtin, jeremy.kloth, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: test_UNC_path failure in test_import
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Thu Jul 12 22:43:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 20:43:20 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <1342125761.76.0.749174282002.issue15338@psf.upfronthosting.co.za>
Message-ID: <1342125800.57.0.295004012114.issue15338@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Example URL for the aforementioned failure:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/282/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Thu Jul 12 23:02:50 2012
From: report at bugs.python.org (=?utf-8?q?Daniel_Neuh=C3=A4user?=)
Date: Thu, 12 Jul 2012 21:02:50 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1342126970.7.0.457732802793.issue9867@psf.upfronthosting.co.za>


Changes by Daniel Neuh?user <dasdasich at googlemail.com>:


----------
nosy: +DasIch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Jul 12 23:35:34 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 21:35:34 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1342128934.26.0.961396590309.issue9867@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This has been fixed in issue #10956 (Python 3 and the io module) and issue #12268 (Python 2's file objects).

----------
components: +Interpreter Core
resolution:  -> out of date
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Jul 12 23:36:23 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 21:36:23 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1342128983.26.0.251033545235.issue9867@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution: out of date -> duplicate
superseder:  -> file readline, readlines & readall methods can lose data on EINTR
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Fri Jul 13 00:00:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 22:00:35 +0000
Subject: [issue15339] document the threading "facts of life" in Python
Message-ID: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think it would be helpful if the Python documentation included certain high-level information about multi-threading in Python.

At minimum, I think it would help for the documentation to provide a definition that can be linked to of what it means when some part of the Python documentation says something is "thread-safe".  In particular, such a definition could clarify that this is different from being atomic.  This might best be addressed by an entry in the glossary for the term "thread-safe".
  
Other documentation possibilities include stating what guarantees one should or should not expect regarding thread-safety, both within and across implementations, and providing centralized guidance on how to approach multi-threaded programming in Python.  A HOWTO is one possibility for addressing these other possibilities.

This issue stems from the discussion in issue 15329, which is more specific.

----------
assignee: docs at python
components: Documentation
messages: 165336
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: document the threading "facts of life" in Python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15339>
_______________________________________

From report at bugs.python.org  Fri Jul 13 00:06:40 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 22:06:40 +0000
Subject: [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342130800.3.0.4304190219.issue15329@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I created issue 15339 to document the multi-threading "facts of life" in Python (independent of any particular module or package, including this one), along the lines suggested by Raymond.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15329>
_______________________________________

From report at bugs.python.org  Fri Jul 13 00:11:16 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 22:11:16 +0000
Subject: [issue15339] document the threading "facts of life" in Python
In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>
Message-ID: <1342131076.29.0.0918025694107.issue15339@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This sounds like a good idea. Either a HOWTO or a FAQ would sound appropriate.

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15339>
_______________________________________

From report at bugs.python.org  Fri Jul 13 00:17:12 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 12 Jul 2012 22:17:12 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1342131432.44.0.0396068529873.issue7652@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I compared both implementations, and they are the same.

I noticed that on line 7537, the call to mpd_qshiftl() may "goto malloc_error;".  I think there is a memory leak in this case, "mpd_del(&c)" and 2 others lines are skipped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Fri Jul 13 00:30:29 2012
From: report at bugs.python.org (Ian Wienand)
Date: Thu, 12 Jul 2012 22:30:29 +0000
Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't
	exist (regression from 2.6)
Message-ID: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za>


New submission from Ian Wienand <ian at wienand.org>:

Hi,

Lib/random.py has a fallback if os.urandom() returns NotImplementedError

---
from os import urandom as _urandom
...
   def seed(self, a=None):
        if a is None:
            try:
                a = long(_hexlify(_urandom(16)), 16)
            except NotImplementedError:
                import time
                a = long(time.time() * 256) # use fractional seconds
---

In 2.6, this is indeed what happens in Lib/os.py where "import urandom from os" gets [2]:

---
if not _exists("urandom"):
    def urandom(n):
...
      try:
            _urandomfd = open("/dev/urandom", O_RDONLY)
        except (OSError, IOError):
            raise NotImplementedError("/dev/urandom (or equivalent) not found")
---

however, in 2.7, things have shuffled around as a result of issue Issue #13703 and now _PyOS_URandom will return an OSError if it can't find /dev/urandom [3].

This means if you "import random" without "/dev/urandom" available it crashes trying to seed

I'm not sure if this is intentional?  One easy solution would be to catch OSError in random.py and fall back then too

[1] http://hg.python.org/cpython/file/70274d53c1dd/Python/random.c#l227
[2] http://hg.python.org/cpython/file/9f8771e09052/Lib/os.py#l746
[3] http://hg.python.org/cpython/file/70274d53c1dd/Lib/random.py#l111

----------
components: Library (Lib)
messages: 165340
nosy: iwienand
priority: normal
severity: normal
status: open
title: OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6)
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15340>
_______________________________________

From report at bugs.python.org  Fri Jul 13 00:40:18 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 12 Jul 2012 22:40:18 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1342131432.44.0.0396068529873.issue7652@psf.upfronthosting.co.za>
Message-ID: <20120712224018.GA2478@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Thanks, Amaury! -- "goto malloc_error" should not leak, because there's always
a jump to the "out" label in line 7563.

I use this idiom a lot ever since I saw it in several places in the Linux
kernel. Of course it's a matter of taste.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Fri Jul 13 01:08:20 2012
From: report at bugs.python.org (moras moorshed)
Date: Thu, 12 Jul 2012 23:08:20 +0000
Subject: [issue15341] Cplex and python
Message-ID: <1342134500.28.0.386653890414.issue15341@psf.upfronthosting.co.za>


New submission from moras moorshed <moorshed_k at yahoo.com>:

Im beginner with python, and I want to connect python to Cplex, IBM optimizer, I installed the python on this path:
'C:\Program Files\IBM\ILOG\CPLEX_Studio123\cplex\python\x86_win32\cplex'>
but when i want to create new file using cplex.Cplex() it gives me this error:
AttributeError: 'module' object has no attribute 'cplex'

so what is wrong?
please help me.

----------
components: Library (Lib)
messages: 165342
nosy: moorshed
priority: normal
severity: normal
status: open
title: Cplex and python
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15341>
_______________________________________

From report at bugs.python.org  Fri Jul 13 02:03:30 2012
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 13 Jul 2012 00:03:30 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>
Message-ID: <1342137810.05.0.903947957993.issue15298@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

like other platform dependent files _sysconfigdata.py should be installed in plat-*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15298>
_______________________________________

From report at bugs.python.org  Fri Jul 13 02:13:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Jul 2012 00:13:29 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1342137810.05.0.903947957993.issue15298@psf.upfronthosting.co.za>
Message-ID: <1342138314.3411.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> like other platform dependent files _sysconfigdata.py should be installed in plat-*

What are you talking about? plat-* files are only OS-specific, while
_sysconfigdata also depends on configure options and other stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15298>
_______________________________________

From report at bugs.python.org  Fri Jul 13 02:22:25 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 13 Jul 2012 00:22:25 +0000
Subject: [issue15341] Cplex and python
In-Reply-To: <1342134500.28.0.386653890414.issue15341@psf.upfronthosting.co.za>
Message-ID: <1342138945.76.0.702602457351.issue15341@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Hi, the bug tracker is not designed to get help.
Please ask questions on the python-list forum, or the comp.lang.python newsgroup.  There are many friendly people there...
Be ready to come with a short script showing the error.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15341>
_______________________________________

From report at bugs.python.org  Fri Jul 13 02:39:07 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Jul 2012 00:39:07 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1342139947.57.0.414683654026.issue4832@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Terry, are you planning to commit this?  If not, I can do it. It would be good to get this into 3.3.0b2 since it does fix an important usability issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Fri Jul 13 03:19:11 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Jul 2012 01:19:11 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1342142351.71.0.114790720058.issue4832@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree. Go ahead. But what do you think of applying to 2.7 and or 3.2?

I want to add a sentence to Idle help, which I want to edit for the tooltips issue also. But that is not a rush.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Fri Jul 13 03:45:30 2012
From: report at bugs.python.org (Pan Yongzhi)
Date: Fri, 13 Jul 2012 01:45:30 +0000
Subject: [issue15342] os.path.join behavior
Message-ID: <1342143930.94.0.174584687761.issue15342@psf.upfronthosting.co.za>


New submission from Pan Yongzhi <fossilet at users.sourceforge.net>:

I am constructing a source directory argument to rsync. It has to end with slash due to rsync behavior. I use:

os.path.join('/src/dir', os.path.sep)

And run it and realized the source directory becomes '/'. Luckily it is not the destination.

Why should join discard all previous path components if any component is an absoulute path? This is such a surprise and renders this function useless.

----------
messages: 165348
nosy: fossilet
priority: normal
severity: normal
status: open
title: os.path.join behavior
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15342>
_______________________________________

From report at bugs.python.org  Fri Jul 13 05:18:33 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 13 Jul 2012 03:18:33 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342149513.64.0.839958392877.issue15320@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Here is another patch -- this one making no implementation assumptions about thread-safety or atomicity.

----------
Added file: http://bugs.python.org/file26371/issue-15320-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Fri Jul 13 05:41:16 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 03:41:16 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1342150876.73.0.223135950651.issue1767933@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Thanks, this looks much better. I've reviewed the _4 patch with some minor comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Fri Jul 13 05:53:39 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Jul 2012 03:53:39 +0000
Subject: [issue15336] Argparse required arguments incorrectly displayed as
	optional arguments
In-Reply-To: <1342122214.84.0.306915245284.issue15336@psf.upfronthosting.co.za>
Message-ID: <1342151619.93.0.374779344812.issue15336@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +bethard, ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15336>
_______________________________________

From report at bugs.python.org  Fri Jul 13 06:16:20 2012
From: report at bugs.python.org (umedoblock)
Date: Fri, 13 Jul 2012 04:16:20 +0000
Subject: [issue10614] ZipFile: add a filename_encoding argument
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1342152980.94.0.788851158213.issue10614@psf.upfronthosting.co.za>


umedoblock <umedoblock at gmail.com> added the comment:

I fixed this problem.
I make new methos _decode_filename().

----------
keywords: +patch
nosy: +umedoblock
Added file: http://bugs.python.org/file26372/zipfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10614>
_______________________________________

From report at bugs.python.org  Fri Jul 13 06:31:44 2012
From: report at bugs.python.org (Christopher the Magnificent)
Date: Fri, 13 Jul 2012 04:31:44 +0000
Subject: [issue15343] "pydoc -w <package>" write out page with empty "package
	contents" section
Message-ID: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>


New submission from Christopher the Magnificent <ultimate.mac.fanatic at gmail.com>:

Let there be a folder "testpkg" contained in $SOME_DIR with three empty files: "__init__.py", "bob.py", and "sally.py

If I run "pydoc3.2 -w testpkg" inside $SOME_DIR, it will output the file $SOME_DIR/testpkg.html

In testpkg.html there will be a section called "Package Contents" with two links named "bob" and "sally".

If I instead run "pydoc3.3 -w testpkg" inside $SOME_DIR, it will still output the file $SOME_DIR/testpkg.html

Only this time, in testpkg.html the section called "Package Contents" will be empty when there should be links named "bob" and "sally"

----------
messages: 165352
nosy: christopherthemagnificent
priority: normal
severity: normal
status: open
title: "pydoc -w <package>" write out page with empty "package contents" section
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Fri Jul 13 06:32:01 2012
From: report at bugs.python.org (Christopher the Magnificent)
Date: Fri, 13 Jul 2012 04:32:01 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "package
	contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342153921.75.0.90227720115.issue15343@psf.upfronthosting.co.za>


Changes by Christopher the Magnificent <ultimate.mac.fanatic at gmail.com>:


----------
title: "pydoc -w <package>" write out page with empty "package contents" section -> "pydoc -w <package>" writes out page with empty "package contents" section

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Fri Jul 13 06:32:37 2012
From: report at bugs.python.org (Christopher the Magnificent)
Date: Fri, 13 Jul 2012 04:32:37 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342153957.33.0.0762909779767.issue15343@psf.upfronthosting.co.za>


Changes by Christopher the Magnificent <ultimate.mac.fanatic at gmail.com>:


----------
title: "pydoc -w <package>" writes out page with empty "package contents" section -> "pydoc -w <package>" writes out page with empty "Package Contents" section

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Fri Jul 13 06:32:44 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 04:32:44 +0000
Subject: [issue15296] Minidom can't create ASCII representation
In-Reply-To: <1341761464.17.0.485570736364.issue15296@psf.upfronthosting.co.za>
Message-ID: <1342153964.58.0.294187943971.issue15296@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Serhiy - why did you remove that documentation bit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15296>
_______________________________________

From report at bugs.python.org  Fri Jul 13 06:49:05 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Jul 2012 04:49:05 +0000
Subject: [issue15344] devinabox: failure when running make_a_box multiple times
Message-ID: <1342154945.64.0.517159061832.issue15344@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

When running make_a_box.py:

Fetching Mercurial ...
make_a_box.py:197: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=6>
  file_url = self._download_url()
Traceback (most recent call last):
  File "make_a_box.py", line 323, in <module>
    ins.create()
  File "make_a_box.py", line 219, in create
    self._create_mercurial()
  File "make_a_box.py", line 200, in _create_mercurial
    with open(os.path.join(self.directory, file_name), 'wb') as file:
IsADirectoryError: [Errno 21] Is a directory: 'Mercurial/'

Apparently running it more than once requires that you delete some things first.

----------
messages: 165354
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
status: open
title: devinabox: failure when running make_a_box multiple times
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15344>
_______________________________________

From report at bugs.python.org  Fri Jul 13 06:49:41 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Jul 2012 04:49:41 +0000
Subject: [issue15344] devinabox: failure when running make_a_box multiple times
In-Reply-To: <1342154945.64.0.517159061832.issue15344@psf.upfronthosting.co.za>
Message-ID: <1342154981.95.0.695268079312.issue15344@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I'm re-running it from a clean directory one more time just to make sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15344>
_______________________________________

From report at bugs.python.org  Fri Jul 13 07:07:52 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 05:07:52 +0000
Subject: [issue14790] use packaging in setup.py
In-Reply-To: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za>
Message-ID: <1342156072.16.0.195584312802.issue14790@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
priority:  -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14790>
_______________________________________

From report at bugs.python.org  Fri Jul 13 07:29:09 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 05:29:09 +0000
Subject: [issue14600] Change ImportError reference handling, naming
In-Reply-To: <1334610869.36.0.563738930515.issue14600@psf.upfronthosting.co.za>
Message-ID: <1342157349.77.0.834661713118.issue14600@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Eric: your note appears to be fixed in the code.
Can this issue be closed?

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14600>
_______________________________________

From report at bugs.python.org  Fri Jul 13 07:46:06 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Jul 2012 05:46:06 +0000
Subject: [issue13238] Add shell command helpers to subprocess module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1342158366.76.0.0599331195022.issue13238@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/issue13238>
_______________________________________

From report at bugs.python.org  Fri Jul 13 08:11:31 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Jul 2012 06:11:31 +0000
Subject: [issue15344] devinabox: failure when running make_a_box multiple times
In-Reply-To: <1342154945.64.0.517159061832.issue15344@psf.upfronthosting.co.za>
Message-ID: <1342159892.0.0.0964978078884.issue15344@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I just got the same error with a clean install.  I'll have to poke at it some other time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15344>
_______________________________________

From report at bugs.python.org  Fri Jul 13 08:27:24 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Jul 2012 06:27:24 +0000
Subject: [issue15296] Minidom can't create ASCII representation
In-Reply-To: <1342153964.58.0.294187943971.issue15296@psf.upfronthosting.co.za>
Message-ID: <1342160872.2493.4.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Serhiy - why did you remove that documentation bit?

Because it's not relevant anymore. With patch you will never get
UnicodeError exceptions in case of unrepresentable text data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15296>
_______________________________________

From report at bugs.python.org  Fri Jul 13 08:45:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 06:45:48 +0000
Subject: [issue13686] Some notes on the docs of multiprocessing
In-Reply-To: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>
Message-ID: <3WYPff6CQBzPCJ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset caea3c64442b by Eli Bendersky in branch 'default':
Some fixes for the documentation of multiprocessing (per issue #13686)
http://hg.python.org/cpython/rev/caea3c64442b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13686>
_______________________________________

From report at bugs.python.org  Fri Jul 13 08:46:35 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 06:46:35 +0000
Subject: [issue13686] Some notes on the docs of multiprocessing
In-Reply-To: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>
Message-ID: <1342161995.12.0.764927236856.issue13686@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Switching this to 3.3 only

Fixes for 1-3 committed in caea3c64442b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13686>
_______________________________________

From report at bugs.python.org  Fri Jul 13 08:52:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 06:52:56 +0000
Subject: [issue15296] Minidom can't create ASCII representation
In-Reply-To: <1341761464.17.0.485570736364.issue15296@psf.upfronthosting.co.za>
Message-ID: <3WYPpt5wDKzP5w@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7b97cea795d8 by Eli Bendersky in branch 'default':
Issue #15296: Fix minidom.toxml/toprettyxml for non-unicode encodings.  Patch by Serhiy Storchaka, with some minor style adjustments by me.
http://hg.python.org/cpython/rev/7b97cea795d8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15296>
_______________________________________

From report at bugs.python.org  Fri Jul 13 08:53:34 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 06:53:34 +0000
Subject: [issue15296] Minidom can't create ASCII representation
In-Reply-To: <1341761464.17.0.485570736364.issue15296@psf.upfronthosting.co.za>
Message-ID: <1342162414.0.0.369832169799.issue15296@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Fixed in 3.3

Thanks for the patch

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15296>
_______________________________________

From report at bugs.python.org  Fri Jul 13 08:58:36 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Jul 2012 06:58:36 +0000
Subject: [issue15342] os.path.join behavior
In-Reply-To: <1342143930.94.0.174584687761.issue15342@psf.upfronthosting.co.za>
Message-ID: <1342162716.69.0.894901896863.issue15342@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

os.path.join is working as documented. See http://docs.python.org/library/os.path.html#os.path.join

"If any component is an absolute path, all previous components (on Windows, including the previous drive letter, if there was one) are thrown away, and joining continues." ... "This means that an empty last part will result in a path that ends with a separator."  So, to have the path end with a separator, use an empty string rather than '/' as the last component.

>>> import os
>>> os.path.join('/','Users', 'nad')
'/Users/nad'
>>> os.path.join('/','Users', 'nad', '')
'/Users/nad/'

----------
nosy: +ned.deily
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15342>
_______________________________________

From report at bugs.python.org  Fri Jul 13 09:10:23 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 07:10:23 +0000
Subject: [issue13686] Some notes on the docs of multiprocessing
In-Reply-To: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>
Message-ID: <3WYQBz5lR0zP87@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1110692aac71 by Eli Bendersky in branch 'default':
Additional fixes to multiprocessing docs (for issue #13686)
http://hg.python.org/cpython/rev/1110692aac71

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13686>
_______________________________________

From report at bugs.python.org  Fri Jul 13 09:11:11 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 07:11:11 +0000
Subject: [issue13686] Some notes on the docs of multiprocessing
In-Reply-To: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>
Message-ID: <1342163471.57.0.167934321422.issue13686@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Done (except 5 and 6, which are non-issues on a second look)

----------
status: open -> closed
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13686>
_______________________________________

From report at bugs.python.org  Fri Jul 13 09:22:18 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 07:22:18 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1342164138.37.0.199954305289.issue1767933@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Serhiy, can you also take a look at #9458 - it may be related?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Fri Jul 13 09:23:42 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 07:23:42 +0000
Subject: [issue14190] Minor C API documentation bugs
In-Reply-To: <1330841228.13.0.736937779561.issue14190@psf.upfronthosting.co.za>
Message-ID: <1342164222.92.0.0383868616154.issue14190@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Closing, as I don't think it's terribly important to backport this.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14190>
_______________________________________

From report at bugs.python.org  Fri Jul 13 09:32:19 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Jul 2012 07:32:19 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342164739.41.0.616761640927.issue15307@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Fixing sys.executable to point to the stub launcher instead of the interpreter in the fw will also fix other unrelated issues, like making python3-32 work properly in 64-/32-bit builds for IDLE and for tests that spawn interpreters in subprocesses.  Today, while the main process is 32-bit,  the interpreters in subprocesses are 64-bit.

I did a little clean up and fixed up the documentation somewhat; see the revised patch.  But building a stock installer and running the tests showed two issues:
1) test_osx_env fails at line 28, checking PYTHONEXECUTABLE
2) when running the tests within a venv, test_venv now fails at line 95;
sys.baseprefix != sys.prefix.  This did not fail previously

Also, I saw another test failure when building and running with a test framework environment that included a relative link.  It appeared that _NSGetExecutablePath in pythonw.c returned an unnormalized path:
>>> sys.executable
'/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/./root/bin/python3.3'
which caused a test_venv failure.  I probably won't have time to look at this again for a few days.

----------
Added file: http://bugs.python.org/file26373/venv-symlinks-v4.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Fri Jul 13 09:34:23 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Fri, 13 Jul 2012 07:34:23 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1342105382.36.0.717697587722.issue15238@psf.upfronthosting.co.za>
Message-ID: <4FFFCF7B.40300@ox.cx>


Hynek Schlawack <hs at ox.cx> added the comment:

> Hynek: You must forgive me, I'm a recovering Windows programmer.  I thought extended attributes were a Linux-only thing.  Can you tell me what other platforms they are available on?  And/or suggest some alternate language?

http://en.wikipedia.org/wiki/Xattr has a list. The question what?s most
user friendly. The best way for the user would be your text. However
we?ll have to dig through the docs once we support xattr on more platforms.

However as I see it, we?re deep down this path already anyway
(http://docs.python.org/dev/library/os.html?highlight=xattr#linux-extended-attributes),
so I guess we can keep your docs.

One nit: I?d swap your quoted "extended attributes" to unquoted but
linked to the doc above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Fri Jul 13 09:42:31 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 13 Jul 2012 07:42:31 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342165351.26.0.539029242085.issue15307@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I removed the call to realpath from pythonw because resolving symlinks breaks the feature. Realpath also converts relative paths to absolute paths, and that probably explains the new failure you're having.

I'll try to find a solution for this, possibly by calling realpath on dirname(argv[0]) instead of the whole path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Fri Jul 13 09:45:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 07:45:38 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <3WYQzj3x27zPDN@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 677a9326b4d4 by Ned Deily in branch 'default':
Issue #4832: Modify IDLE to save files with .py extension by
http://hg.python.org/cpython/rev/677a9326b4d4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Fri Jul 13 09:50:31 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Jul 2012 07:50:31 +0000
Subject: [issue4832] IDLE does not supply a default ext of .py on Windows or
	OS X for new file saves
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1342165831.0.0.350364179295.issue4832@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Committed for 3.3.  I'm +0.5 for 2.7 and 3.2.  It seems like a bug to me.  Terry, I'll leave it up to you to handle that and any further doc updates you want to make.

----------
title: idle filename extension -> IDLE does not supply a default ext of .py on Windows or OS X for new file saves

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Fri Jul 13 10:00:51 2012
From: report at bugs.python.org (Pan Yongzhi)
Date: Fri, 13 Jul 2012 08:00:51 +0000
Subject: [issue15342] os.path.join behavior
In-Reply-To: <1342143930.94.0.174584687761.issue15342@psf.upfronthosting.co.za>
Message-ID: <1342166451.36.0.0723540065985.issue15342@psf.upfronthosting.co.za>


Pan Yongzhi <fossilet at users.sourceforge.net> added the comment:

I know this is working as documented. But working as documented does not mean it is not a bug.

I cannot deduce that it will append a separator if joining with an empty string from the documentation. Also, this behavior is implicit, and have to guess. Either the document or the behaivor have to be changed.

I think it is not only me:

http://stackoverflow.com/questions/1945920/os-path-join-python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15342>
_______________________________________

From report at bugs.python.org  Fri Jul 13 10:20:06 2012
From: report at bugs.python.org (Eduardo Cereto Carvalho)
Date: Fri, 13 Jul 2012 08:20:06 +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: <1342167606.75.0.341640020073.issue11445@psf.upfronthosting.co.za>


Changes by Eduardo Cereto Carvalho <eduardocereto at gmail.com>:


----------
nosy: +Eduardo.Cereto.Carvalho

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11445>
_______________________________________

From report at bugs.python.org  Fri Jul 13 14:29:37 2012
From: report at bugs.python.org (Tim Golden)
Date: Fri, 13 Jul 2012 12:29:37 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <1342125761.76.0.749174282002.issue15338@psf.upfronthosting.co.za>
Message-ID: <500014AE.3080809@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Well os.listdir doesn't fail to access a UNC path on Windows x64 in
general. So presumably this particular path is not accessible by the
buildbot process owner?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Fri Jul 13 14:33:58 2012
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 13 Jul 2012 12:33:58 +0000
Subject: [issue11624] distutils should support a custom list of exported
	symbols for Windows dlls.
In-Reply-To: <1300728706.6.0.163969255982.issue11624@psf.upfronthosting.co.za>
Message-ID: <1342182838.25.0.6964198406.issue11624@psf.upfronthosting.co.za>


Daniel Holth <dholth at fastmail.fm> added the comment:

I must have missed the export_symbols keyword argument to Extension(), or it was added.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11624>
_______________________________________

From report at bugs.python.org  Fri Jul 13 14:36:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Jul 2012 12:36:53 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <1342125761.76.0.749174282002.issue15338@psf.upfronthosting.co.za>
Message-ID: <1342183013.39.0.529200298468.issue15338@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, this particular path is the build directory itself, so it's certainly accessible through the normal (non-UNC) path. There has to be something else :-) 

Jeremy told me his buildbot process runs as a service, perhaps that is related?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Fri Jul 13 14:40:00 2012
From: report at bugs.python.org (Tim Golden)
Date: Fri, 13 Jul 2012 12:40:00 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <1342183013.39.0.529200298468.issue15338@psf.upfronthosting.co.za>
Message-ID: <5000171D.5060904@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

It's using an administrative share (\\server\d$) and those are usually
restricted with share permissions -- different from NTFS permissions.
That the process runs as a service is likely to have an effect since
services are conventionally run with minimum-privilege accounts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Fri Jul 13 14:40:04 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Jul 2012 12:40:04 +0000
Subject: [issue9458] xml.etree.ElementTree.ElementTree.write(): encoding
	handling problems
In-Reply-To: <1280782925.67.0.136452249646.issue9458@psf.upfronthosting.co.za>
Message-ID: <1342183204.97.0.45497311864.issue9458@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

ElementTree write works with two kinds of output -- binary and text. The difference between them is only determined by encoding argument. If encoding is "unicode", then output is text, else it is binary. There is no other way for filename or general file-like object to determine kind of output. If these are not explained in the documentation, then the documentation should be improved.

The patch can cause data corruption because direct writing to underlying file by fileno conflicts with TextIOBase/BufferedIOBase internal buffering. And not every file-like object have fileno. With patch the behavior becomes less obvious and will lead to confusion.

I don't see a behavior bug which should be fixed.

Only one thing can be enhanced -- error diagnostic in some corner cases. When we can determines that file object is instance of RawIOBase or TextIOBase and it is conflicts with encoding argument value, it will be helpful for novices to raise a descriptive exception. This is of course not eliminate all causes for confusing.

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9458>
_______________________________________

From report at bugs.python.org  Fri Jul 13 14:46:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Jul 2012 12:46:02 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <5000171D.5060904@timgolden.me.uk>
Message-ID: <1342183467.3385.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It's using an administrative share (\\server\d$) and those are usually
> restricted with share permissions -- different from NTFS permissions.
> That the process runs as a service is likely to have an effect since
> services are conventionally run with minimum-privilege accounts.

Ok, so I guess skipping the test in this case would be appropriate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Fri Jul 13 15:08:34 2012
From: report at bugs.python.org (Tim Golden)
Date: Fri, 13 Jul 2012 13:08:34 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <1342183467.3385.0.camel@localhost.localdomain>
Message-ID: <50001D80.8050801@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

For this particular buildbot setup, maybe yes. But it would be possible
in principle to have a buildbot configuration which could allow the test
to execute. (eg one running under a user account which can access the
path via an admin share). Does the buildbot owner have anything to say
on the account and share permissions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Fri Jul 13 15:11:11 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Jul 2012 13:11:11 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <1342125761.76.0.749174282002.issue15338@psf.upfronthosting.co.za>
Message-ID: <1342185071.22.0.941866573302.issue15338@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Fri Jul 13 15:18:27 2012
From: report at bugs.python.org (Simon Hayward)
Date: Fri, 13 Jul 2012 13:18:27 +0000
Subject: [issue15345] HOWTOs Argparse tutorial - code example raises
	SyntaxError
Message-ID: <1342185507.58.0.724353170011.issue15345@psf.upfronthosting.co.za>


New submission from Simon Hayward <simonhayward at gmail.com>:

HOWTOs - Argparse Tutorial, the code example will raise a syntax error when run. A trailing python3 reference (if called as a function): 'end=""', to suppresses a newline remains.

print "{}^{} == ".format(args.x, args.y), end=""

Should read:

print "{}^{} ==".format(args.x, args.y),

----------
assignee: docs at python
components: Documentation
files: argparse-howto.patch
keywords: patch
messages: 165381
nosy: docs at python, simon.hayward
priority: normal
severity: normal
status: open
title: HOWTOs Argparse tutorial - code example raises SyntaxError
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26374/argparse-howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15345>
_______________________________________

From report at bugs.python.org  Fri Jul 13 15:57:27 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 13 Jul 2012 13:57:27 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342187847.01.0.763242808682.issue15307@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

v5 adds test cases for sys.executable and calls realpath on dirname(argv[0]) in pythonw.c and also has the changes in Ned's v4.

The test failure for test_venv is expected, the note in <http://docs.python.org/dev/library/venv.html> explains that "sys.base_prefix and sys.base_exec_prefix point to the non-venv Python installation which was used to create the venv". The test fails because it assumes that sys.base_prefix of the created venv is same as sys.prefix of the running python, which is not true when you create a venv in a venv.

In particular line 95 of test_venv explicitly tests that sys.prefix == sys.base_prefix, which should fail when running the test within a virtual env. Tweaking the test suite to avoid that failure is beyond the scope of this issue.

----------
Added file: http://bugs.python.org/file26375/venv-symlinks-v5.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Fri Jul 13 16:00:02 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 13 Jul 2012 14:00:02 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <50001D80.8050801@timgolden.me.uk>
Message-ID: <CAGvrs3L_jtCt9ThdmOUS+6zVgD2+BG331Np3M=m7SWd_18omWQ@mail.gmail.com>


Jeremy Kloth <jeremy.kloth at gmail.com> added the comment:

The buildbot service account is a standard user (per the buildbot
servce installation directions).  When logged on, the user can access
the share.  Just when logged on as a service is when it cannot.

After much searching, I still cannot find any information on how to
get that user to access to those shares.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Fri Jul 13 16:02:39 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 13 Jul 2012 14:02:39 +0000
Subject: [issue10614] ZipFile: add a filename_encoding argument
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1342188159.69.0.328776483368.issue10614@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

umedoblock: your patch is incorrect, as it produces moji-bake. if there is a file name b'f\x94n', it will decode as sjis under your patch (to u'f\u99ac'), even though it was meant as cp437 (i.e. u'f\xf6n').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10614>
_______________________________________

From report at bugs.python.org  Fri Jul 13 16:05:00 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Jul 2012 14:05:00 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342188300.51.0.981800290225.issue15320@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I find the patch complicated. If you are using a Lock, surely you don't need a deque, you can keep the original iterator (which is also more readable since it mirrors the semantics quite closely)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Fri Jul 13 16:44:19 2012
From: report at bugs.python.org (umedoblock)
Date: Fri, 13 Jul 2012 14:44:19 +0000
Subject: [issue10614] ZipFile: add a filename_encoding argument
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1342190659.58.0.996688880368.issue10614@psf.upfronthosting.co.za>


umedoblock <umedoblock at gmail.com> added the comment:

Hi, Martin.
I tried your test case with attached file.
And I got below result.

p3 ./encodings.py
encoding: sjis, filename: f?
encoding: cp437, filename: f?n
sjis_filename = f?
cp437_filename = f?n

There are two success cases.
So I think that the patch needs to change default_encoding
before or in _decode_filename().

But I have no idea about how to change a default_encoding.

----------
Added file: http://bugs.python.org/file26376/encodings.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10614>
_______________________________________

From report at bugs.python.org  Fri Jul 13 16:47:38 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Jul 2012 14:47:38 +0000
Subject: [issue15342] os.path.join behavior
In-Reply-To: <1342143930.94.0.174584687761.issue15342@psf.upfronthosting.co.za>
Message-ID: <1342190858.38.0.261162782829.issue15342@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Whatever the good or bad points of the API design, it is what it is and has been for a very long time.  It is not something that is going to change, because the break in backward compatibility would be too large.

What is unclear about the documentation that Ned quoted ("This means that an empty last part will result in a path that ends with a separator.")?  How would you suggest improving the documentation?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15342>
_______________________________________

From report at bugs.python.org  Fri Jul 13 17:22:41 2012
From: report at bugs.python.org (Tim Golden)
Date: Fri, 13 Jul 2012 15:22:41 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <CAGvrs3L_jtCt9ThdmOUS+6zVgD2+BG331Np3M=m7SWd_18omWQ@mail.gmail.com>
Message-ID: <50003CAE.5000909@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

My guess is that it's to do with Service Hardening. I did a quick dump
of my token in an interactive session and as the owner of a service.
Quite a few differences. I haven't read up on this area yet so I'm not
sure what options there are / how easy to get the necessary privs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Fri Jul 13 17:26:27 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 15:26:27 +0000
Subject: [issue15053] imp.lock_held() "Changed in Python 3.3" mention
	accidentally one function up
In-Reply-To: <1339532446.32.0.0402768881162.issue15053@psf.upfronthosting.co.za>
Message-ID: <3WYdCQ25LHzNb7@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c09f454af2c6 by Brett Cannon in branch 'default':
Issue #15053: Make sure all functions related to the import lock have
http://hg.python.org/cpython/rev/c09f454af2c6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15053>
_______________________________________

From report at bugs.python.org  Fri Jul 13 17:27:19 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Jul 2012 15:27:19 +0000
Subject: [issue15053] imp.lock_held() "Changed in Python 3.3" mention
	accidentally one function up
In-Reply-To: <1339532446.32.0.0402768881162.issue15053@psf.upfronthosting.co.za>
Message-ID: <1342193239.59.0.0462657886584.issue15053@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15053>
_______________________________________

From report at bugs.python.org  Fri Jul 13 17:32:05 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Jul 2012 15:32:05 +0000
Subject: [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342193525.66.0.00547670893224.issue15151@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +Yury.Selivanov, larry, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15151>
_______________________________________

From report at bugs.python.org  Fri Jul 13 17:32:14 2012
From: report at bugs.python.org (Tim Golden)
Date: Fri, 13 Jul 2012 15:32:14 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <1342125761.76.0.749174282002.issue15338@psf.upfronthosting.co.za>
Message-ID: <1342193534.57.0.341868708015.issue15338@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

Simplest solution might be to catch PermissionError and call skipTest from within. This would allow buildbots to run the test which had access through the relevant share.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Fri Jul 13 17:32:42 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Jul 2012 15:32:42 +0000
Subject: [issue15169] Clear C code under PyImport_ExecCodeModuleObject()
In-Reply-To: <1340567956.17.0.18413889062.issue15169@psf.upfronthosting.co.za>
Message-ID: <1342193562.36.0.810363592365.issue15169@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15169>
_______________________________________

From report at bugs.python.org  Fri Jul 13 17:37:25 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Jul 2012 15:37:25 +0000
Subject: [issue15169] Clear C code under PyImport_ExecCodeModuleObject()
In-Reply-To: <1340567956.17.0.18413889062.issue15169@psf.upfronthosting.co.za>
Message-ID: <1342193845.83.0.163066510356.issue15169@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15169>
_______________________________________

From report at bugs.python.org  Fri Jul 13 18:15:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 Jul 2012 16:15:59 +0000
Subject: [issue14600] Change ImportError reference handling, naming
In-Reply-To: <1334610869.36.0.563738930515.issue14600@psf.upfronthosting.co.za>
Message-ID: <1342196159.08.0.0856338808313.issue14600@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yep, bf23a6c215f6 fixed it, thanks for the ping.  Brian or Antoine, can you close this or was there something else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14600>
_______________________________________

From report at bugs.python.org  Fri Jul 13 18:47:27 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Fri, 13 Jul 2012 16:47:27 +0000
Subject: [issue15346] Tkinter dnd has no documentation
Message-ID: <1342198047.2.0.619885102312.issue15346@psf.upfronthosting.co.za>


New submission from Daniel Swanson <popcorn.tomato.dude at gmail.com>:

The title should be self explanatory.
I needed Drag-and-drop for a project I was working on, (maybe I shouldn't be refering to it in the past tense as I haven't started yet) so I checked the documentation for tkinter and found:
3.3.0 b1
tkinter.dnd 
Drag-and-drop support for tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND.

3.2.2 (and .2.3)
tkinter.dnd 
Drag-and-drop support for tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND. 

2.7.3
Tkdnd 
Drag-and-drop support for Tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND.

I think that tkinter.dnd needs some documentation, whether or not it is replaced with Tk DND.

----------
assignee: docs at python
components: Documentation
messages: 165392
nosy: docs at python, weirdink13
priority: normal
severity: normal
status: open
title: Tkinter dnd has no documentation
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15346>
_______________________________________

From report at bugs.python.org  Fri Jul 13 18:58:36 2012
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 13 Jul 2012 16:58:36 +0000
Subject: [issue14600] Change ImportError reference handling, naming
In-Reply-To: <1334610869.36.0.563738930515.issue14600@psf.upfronthosting.co.za>
Message-ID: <1342198716.15.0.790499036042.issue14600@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14600>
_______________________________________

From report at bugs.python.org  Fri Jul 13 19:57:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 17:57:12 +0000
Subject: [issue15169] Clear C code under PyImport_ExecCodeModuleObject()
In-Reply-To: <1340567956.17.0.18413889062.issue15169@psf.upfronthosting.co.za>
Message-ID: <3WYhYM0q85zNkq@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9e164b404983 by Brett Cannon in branch 'default':
Issues #15169, #14599: Make PyImport_ExecCodeModuleWithPathnames() use
http://hg.python.org/cpython/rev/9e164b404983

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15169>
_______________________________________

From report at bugs.python.org  Fri Jul 13 19:57:13 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 17:57:13 +0000
Subject: [issue14599] Windows test_import failure thanks to ImportError.path
In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za>
Message-ID: <3WYhYM6VhRzP2C@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9e164b404983 by Brett Cannon in branch 'default':
Issues #15169, #14599: Make PyImport_ExecCodeModuleWithPathnames() use
http://hg.python.org/cpython/rev/9e164b404983

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14599>
_______________________________________

From report at bugs.python.org  Fri Jul 13 19:58:30 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Jul 2012 17:58:30 +0000
Subject: [issue15169] Clear C code under PyImport_ExecCodeModuleObject()
In-Reply-To: <1340567956.17.0.18413889062.issue15169@psf.upfronthosting.co.za>
Message-ID: <1342202310.63.0.781608617869.issue15169@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15169>
_______________________________________

From report at bugs.python.org  Fri Jul 13 19:58:39 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Jul 2012 17:58:39 +0000
Subject: [issue14599] Windows test_import failure thanks to ImportError.path
In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za>
Message-ID: <1342202319.91.0.704500713915.issue14599@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

MAXPATHLEN no longer shows up in Python/import.c.

----------
dependencies: +Clear C code under PyImport_ExecCodeModuleObject()
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14599>
_______________________________________

From report at bugs.python.org  Fri Jul 13 20:09:08 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 13 Jul 2012 18:09:08 +0000
Subject: [issue15339] document the threading "facts of life" in Python
In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>
Message-ID: <1342202948.31.0.603217981786.issue15339@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If no one gets to it first, I'll write-up a draft when I get a chance.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15339>
_______________________________________

From report at bugs.python.org  Fri Jul 13 20:19:50 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 13 Jul 2012 18:19:50 +0000
Subject: [issue15345] HOWTOs Argparse tutorial - code example raises
	SyntaxError
In-Reply-To: <1342185507.58.0.724353170011.issue15345@psf.upfronthosting.co.za>
Message-ID: <1342203590.41.0.428550705273.issue15345@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15345>
_______________________________________

From report at bugs.python.org  Fri Jul 13 20:27:50 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 13 Jul 2012 18:27:50 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342204070.6.0.586370941227.issue15307@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> In particular line 95 of test_venv explicitly tests that
> sys.prefix == sys.base_prefix, which should fail when running the
> test within a virtual env. Tweaking the test suite to avoid that
> failure is beyond the scope of this issue.

The first part of the test which includes line 95 (commented as "check our prefixes") checks the Python running the test, which is not running in a venv. The next part ("check a venv's prefixes") *does* run in a venv (using a subprocess to invoke the venv's Python), and the test compares the venv's prefixes to expected values. So, this test isn't wrong AFAICT, and has worked fine both on source builds and installed builds - so if it doesn't work after applying the patch, ISTM something else must be wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Fri Jul 13 20:41:01 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 13 Jul 2012 18:41:01 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342204861.59.0.195562780591.issue15307@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned mentioned that test_venv fails on line 95 when you run test_venv *in* a virtualenv, that is:

$ pyvenv testenv
$ testenv/bin/python3 -m test.test_venv

This fails because sys.prefix != sys.base_prefix for testenv/bin/python3, and that's expected. 

Unless I'm mistaken nothing is wrong here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Fri Jul 13 20:50:47 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Jul 2012 18:50:47 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342205447.72.0.626386228444.issue15307@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

That's correct, the failing test was being run from a venv.  I see now that what had changed is that the fixes for Issue15241 recently added the test_prefixes test case to test_venv and that fails when the test is run from within a venv.  Without that new test case, test_venv didn't fail at 3.3.0b1 when run from a venv.  Whether it should is another matter and is out of scope for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Fri Jul 13 20:52:34 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 13 Jul 2012 18:52:34 +0000
Subject: [issue15339] document the threading "facts of life" in Python
In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>
Message-ID: <1342205554.95.0.777903191607.issue15339@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15339>
_______________________________________

From report at bugs.python.org  Fri Jul 13 20:54:00 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 13 Jul 2012 18:54:00 +0000
Subject: [issue15328] datetime.strptime slow
In-Reply-To: <1342015221.25.0.0683472526459.issue15328@psf.upfronthosting.co.za>
Message-ID: <1342205640.28.0.0147937024931.issue15328@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15328>
_______________________________________

From report at bugs.python.org  Fri Jul 13 20:54:58 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 13 Jul 2012 18:54:58 +0000
Subject: [issue15327] Argparse: main arguments and subparser arguments
	indistinguishable
In-Reply-To: <1342004730.08.0.363281774737.issue15327@psf.upfronthosting.co.za>
Message-ID: <1342205698.42.0.36464501001.issue15327@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +bethard, tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15327>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:00:09 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 13 Jul 2012 19:00:09 +0000
Subject: [issue15302] Use argparse instead of getopt in test.regrtest
In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>
Message-ID: <1342206009.53.0.960747727532.issue15302@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15302>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:00:50 2012
From: report at bugs.python.org (=?utf-8?b?VsOtY3RvciBUZXJyw7Nu?=)
Date: Fri, 13 Jul 2012 19:00:50 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1342206050.65.0.341455315847.issue10716@psf.upfronthosting.co.za>


V?ctor Terr?n <quintanar at gmail.com> added the comment:

I would like to take on this issue if, as it seems, Ron is no longer working on it. I'm thinking of using HTML5 and maybe replicating the default output of Sphinx.

----------
nosy: +vterron

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:01:23 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 19:01:23 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <1342125761.76.0.749174282002.issue15338@psf.upfronthosting.co.za>
Message-ID: <3WYjzP5vgszNWx@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4d480a2a6296 by Antoine Pitrou in branch '3.2':
Issue #15338: skip test_UNC_path when the current user doesn't have enough permissions to access the path.
http://hg.python.org/cpython/rev/4d480a2a6296

New changeset 7d5e84a44b82 by Antoine Pitrou in branch 'default':
Issue #15338: skip test_UNC_path when the current user doesn't have enough permissions to access the path.
http://hg.python.org/cpython/rev/7d5e84a44b82

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:01:43 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 13 Jul 2012 19:01:43 +0000
Subject: [issue15270] "Economy of Expression" section outdated
In-Reply-To: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za>
Message-ID: <1342206103.17.0.325451643642.issue15270@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15270>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:08:02 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 19:08:02 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <1342125761.76.0.749174282002.issue15338@psf.upfronthosting.co.za>
Message-ID: <3WYk750BFWzNb7@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7eac87fa7a06 by Antoine Pitrou in branch '2.7':
Issue #15338: skip test_UNC_path when the current user doesn't have enough permissions to access the path.
http://hg.python.org/cpython/rev/7eac87fa7a06

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:11:43 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 19:11:43 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
In-Reply-To: <1342110252.89.0.365330670645.issue15334@psf.upfronthosting.co.za>
Message-ID: <3WYkCK57ZqzP68@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ec2caf810e5e by Antoine Pitrou in branch '3.2':
Issue #15334: skip test_dynamic_key when run in non-interactive mode.
http://hg.python.org/cpython/rev/ec2caf810e5e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:11:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 19:11:59 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
In-Reply-To: <1342110252.89.0.365330670645.issue15334@psf.upfronthosting.co.za>
Message-ID: <3WYkCf2YHNzP68@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1242ed59573e by Antoine Pitrou in branch 'default':
Issue #15334: skip test_dynamic_key when run in non-interactive mode.
http://hg.python.org/cpython/rev/1242ed59573e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:12:48 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Jul 2012 19:12:48 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1342206768.9.0.510062217217.issue10716@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Using an HTML5 doctype is ok, but I'm not sure it's a good idea to use new HTML5 elements/features yet (those shouldn't be necessary anyway, so basically you should end up with valid HTML 4 strict with an HTML5 doctype).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:15:47 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 19:15:47 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
In-Reply-To: <1342110252.89.0.365330670645.issue15334@psf.upfronthosting.co.za>
Message-ID: <3WYkJ22wDrzP9M@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9bbc4900301c by Antoine Pitrou in branch '2.7':
Issue #15334: skip test_dynamic_key when run in non-interactive mode.
http://hg.python.org/cpython/rev/9bbc4900301c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:19:57 2012
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 13 Jul 2012 19:19:57 +0000
Subject: [issue15335] IDLE - debugger steps through run.py internals
In-Reply-To: <1342111374.05.0.899363686539.issue15335@psf.upfronthosting.co.za>
Message-ID: <1342207197.29.0.133434448777.issue15335@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

> I suggest to add a decorator @Debugger.internal for all methods that the debugger should not step into. It should set a function attribute that the debugger then checks for.


The decorator idea may work. I'll need to see how to make it work with the existing debugging code.


> OTOH, I fail to see the problem. Stepping through the standard library may be useful, and if you don't want to do that, you can choose to step over still.


I'm not sure why stepping through an IDE's internals is desirable when debugging one's own program. As it stands, the _RPCFile patch represents an unintended behavior change to the debugger. That needs to be either corrected or documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15335>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:25:44 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Jul 2012 19:25:44 +0000
Subject: [issue15275] isinstance is called a more times that needed in ntpath
In-Reply-To: <1341668298.8.0.671820953585.issue15275@psf.upfronthosting.co.za>
Message-ID: <1342207544.47.0.536903569464.issue15275@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Have you tried doing some benchmarks before and after the patch?
If this patch is applied I think it would be good to change posixpath too.
Also make sure that the changes you made are covered by the tests.

----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> performance
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15275>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:28:01 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Jul 2012 19:28:01 +0000
Subject: [issue15324] --match does not work for regrtest
In-Reply-To: <1341996167.29.0.670319499131.issue15324@psf.upfronthosting.co.za>
Message-ID: <1342207681.33.0.741829547785.issue15324@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review
superseder:  -> Use argparse instead of getopt in test.regrtest
type:  -> enhancement
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15324>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:29:02 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Jul 2012 19:29:02 +0000
Subject: [issue15325] --fromfile does not work for regrtest
In-Reply-To: <1342001132.43.0.639678860969.issue15325@psf.upfronthosting.co.za>
Message-ID: <1342207742.18.0.554207286149.issue15325@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review
superseder:  -> Use argparse instead of getopt in test.regrtest
type:  -> enhancement
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15325>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:29:21 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Jul 2012 19:29:21 +0000
Subject: [issue15326] --random does not work for regrtest
In-Reply-To: <1342001711.01.0.48203802237.issue15326@psf.upfronthosting.co.za>
Message-ID: <1342207761.61.0.507466789332.issue15326@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review
superseder:  -> Use argparse instead of getopt in test.regrtest
type:  -> enhancement
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15326>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:30:01 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Jul 2012 19:30:01 +0000
Subject: [issue15331] Missing codec aliases for bytes-bytes codecs
In-Reply-To: <1342091074.63.0.386956250979.issue15331@psf.upfronthosting.co.za>
Message-ID: <1342207801.85.0.82312911015.issue15331@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/issue15331>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:32:43 2012
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 13 Jul 2012 19:32:43 +0000
Subject: [issue15347] IDLE - does not close if the debugger was active
Message-ID: <1342207963.58.0.539607447258.issue15347@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

IDLE fails to close if the debugger was active.

Steps to reproduce:

1) Start IDLE with only a shell.
2) Enable debugger.
3) Press enter in the shell. (Causes debugger to activate)
4) Close the shell window. (File->Exit or click X)
5) Click "OK" in the dialog box.

IDLE keeps running despite all windows being closed.

----------
components: IDLE
messages: 165410
nosy: serwy
priority: normal
severity: normal
status: open
title: IDLE - does not close if the debugger was active
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15347>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:38:10 2012
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 13 Jul 2012 19:38:10 +0000
Subject: [issue15348] IDLE - shell becomes unresponsive if debugger windows is
	closed while active.
Message-ID: <1342208290.25.0.778184843655.issue15348@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

The IDLE shell does not respond to commands if the debugger window is closed by clicking "X". This is due to PyShell's "executing" flag not being reset.

Steps to reproduce:

1) Start IDLE with a shell.
2) Enable debugger.
3) Press enter in the shell. (activates the debugger)
4) Close the debugger by clicking "X".

The shell is no longer responsive to new commands. Selecting "Restart Shell" does not fix the problem either.

----------
components: IDLE
messages: 165411
nosy: serwy
priority: normal
severity: normal
status: open
title: IDLE - shell becomes unresponsive if debugger windows is closed while active.
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15348>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:38:40 2012
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 13 Jul 2012 19:38:40 +0000
Subject: [issue15348] IDLE - shell becomes unresponsive if debugger windows is
	closed while active.
In-Reply-To: <1342208290.25.0.778184843655.issue15348@psf.upfronthosting.co.za>
Message-ID: <1342208320.76.0.159379209091.issue15348@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15348>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:40:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 19:40:48 +0000
Subject: [issue15345] HOWTOs Argparse tutorial - code example raises
	SyntaxError
In-Reply-To: <1342185507.58.0.724353170011.issue15345@psf.upfronthosting.co.za>
Message-ID: <3WYkrv44tqzNHC@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset de18c4470ff1 by Ezio Melotti in branch '2.7':
#15345: fix SyntaxError in argparse tutorial example.  Patch by Simon Hayward.
http://hg.python.org/cpython/rev/de18c4470ff1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15345>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:41:51 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Jul 2012 19:41:51 +0000
Subject: [issue15345] HOWTOs Argparse tutorial - code example raises
	SyntaxError
In-Reply-To: <1342185507.58.0.724353170011.issue15345@psf.upfronthosting.co.za>
Message-ID: <1342208511.56.0.626554306114.issue15345@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for 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/issue15345>
_______________________________________

From report at bugs.python.org  Fri Jul 13 21:43:06 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Jul 2012 19:43:06 +0000
Subject: [issue15327] Argparse: main arguments and subparser arguments
	indistinguishable
In-Reply-To: <1342004730.08.0.363281774737.issue15327@psf.upfronthosting.co.za>
Message-ID: <1342208586.2.0.339767485547.issue15327@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> test needed
type: enhancement -> behavior
versions: +Python 3.3, Python 3.4 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15327>
_______________________________________

From report at bugs.python.org  Fri Jul 13 22:03:30 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 13 Jul 2012 20:03:30 +0000
Subject: [issue15324] --match does not work for regrtest
In-Reply-To: <1341996167.29.0.670319499131.issue15324@psf.upfronthosting.co.za>
Message-ID: <1342209810.97.0.705055803518.issue15324@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

This and the two similar issues can be fixed without waiting for the enhancement patch by correcting the typos in the getopt invocation. I would be happy to file patches or a combined patch to fix just the typos.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15324>
_______________________________________

From report at bugs.python.org  Fri Jul 13 22:25:34 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Jul 2012 20:25:34 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
In-Reply-To: <1342150876.73.0.223135950651.issue1767933@psf.upfronthosting.co.za>
Message-ID: <1342211161.2506.2.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Patch updated with some comments.

----------
Added file: http://bugs.python.org/file26377/etree_write_utf16_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________
-------------- next part --------------
diff -r 677a9326b4d4 Lib/test/test_xml_etree.py
--- a/Lib/test/test_xml_etree.py	Mon Jul 09 18:16:11 2012 -0700
+++ b/Lib/test/test_xml_etree.py	Fri Jul 13 23:23:04 2012 +0300
@@ -21,7 +21,7 @@
 import weakref
 
 from test import support
-from test.support import findfile, import_fresh_module, gc_collect
+from test.support import TESTFN, findfile, unlink, import_fresh_module, gc_collect
 
 pyET = None
 ET = None
@@ -888,65 +888,6 @@
     """
     ET.XML("<?xml version='1.0' encoding='%s'?><xml />" % encoding)
 
-def encoding():
-    r"""
-    Test encoding issues.
-
-    >>> elem = ET.Element("tag")
-    >>> elem.text = "abc"
-    >>> serialize(elem)
-    '<tag>abc</tag>'
-    >>> serialize(elem, encoding="utf-8")
-    b'<tag>abc</tag>'
-    >>> serialize(elem, encoding="us-ascii")
-    b'<tag>abc</tag>'
-    >>> serialize(elem, encoding="iso-8859-1")
-    b"<?xml version='1.0' encoding='iso-8859-1'?>\n<tag>abc</tag>"
-
-    >>> elem.text = "<&\"\'>"
-    >>> serialize(elem)
-    '<tag>&lt;&amp;"\'&gt;</tag>'
-    >>> serialize(elem, encoding="utf-8")
-    b'<tag>&lt;&amp;"\'&gt;</tag>'
-    >>> serialize(elem, encoding="us-ascii") # cdata characters
-    b'<tag>&lt;&amp;"\'&gt;</tag>'
-    >>> serialize(elem, encoding="iso-8859-1")
-    b'<?xml version=\'1.0\' encoding=\'iso-8859-1\'?>\n<tag>&lt;&amp;"\'&gt;</tag>'
-
-    >>> elem.attrib["key"] = "<&\"\'>"
-    >>> elem.text = None
-    >>> serialize(elem)
-    '<tag key="&lt;&amp;&quot;\'&gt;" />'
-    >>> serialize(elem, encoding="utf-8")
-    b'<tag key="&lt;&amp;&quot;\'&gt;" />'
-    >>> serialize(elem, encoding="us-ascii")
-    b'<tag key="&lt;&amp;&quot;\'&gt;" />'
-    >>> serialize(elem, encoding="iso-8859-1")
-    b'<?xml version=\'1.0\' encoding=\'iso-8859-1\'?>\n<tag key="&lt;&amp;&quot;\'&gt;" />'
-
-    >>> elem.text = '\xe5\xf6\xf6<>'
-    >>> elem.attrib.clear()
-    >>> serialize(elem)
-    '<tag>\xe5\xf6\xf6&lt;&gt;</tag>'
-    >>> serialize(elem, encoding="utf-8")
-    b'<tag>\xc3\xa5\xc3\xb6\xc3\xb6&lt;&gt;</tag>'
-    >>> serialize(elem, encoding="us-ascii")
-    b'<tag>&#229;&#246;&#246;&lt;&gt;</tag>'
-    >>> serialize(elem, encoding="iso-8859-1")
-    b"<?xml version='1.0' encoding='iso-8859-1'?>\n<tag>\xe5\xf6\xf6&lt;&gt;</tag>"
-
-    >>> elem.attrib["key"] = '\xe5\xf6\xf6<>'
-    >>> elem.text = None
-    >>> serialize(elem)
-    '<tag key="\xe5\xf6\xf6&lt;&gt;" />'
-    >>> serialize(elem, encoding="utf-8")
-    b'<tag key="\xc3\xa5\xc3\xb6\xc3\xb6&lt;&gt;" />'
-    >>> serialize(elem, encoding="us-ascii")
-    b'<tag key="&#229;&#246;&#246;&lt;&gt;" />'
-    >>> serialize(elem, encoding="iso-8859-1")
-    b'<?xml version=\'1.0\' encoding=\'iso-8859-1\'?>\n<tag key="\xe5\xf6\xf6&lt;&gt;" />'
-    """
-
 def methods():
     r"""
     Test serialization methods.
@@ -2166,16 +2107,185 @@
         self.assertEqual(self._subelem_tags(e), ['a1'])
 
 
-class StringIOTest(unittest.TestCase):
+class IOTest(unittest.TestCase):
+    def tearDown(self):
+        unlink(TESTFN)
+
+    def test_encoding(self):
+        # Test encoding issues.
+        elem = ET.Element("tag")
+        elem.text = "abc"
+        self.assertEqual(serialize(elem), '<tag>abc</tag>')
+        self.assertEqual(serialize(elem, encoding="utf-8"),
+                b'<tag>abc</tag>')
+        self.assertEqual(serialize(elem, encoding="us-ascii"),
+                b'<tag>abc</tag>')
+        for enc in ("iso-8859-1", "utf-16", "utf-32"):
+            self.assertEqual(serialize(elem, encoding=enc),
+                    ("<?xml version='1.0' encoding='%s'?>\n"
+                     "<tag>abc</tag>" % enc).encode(enc))
+
+        elem = ET.Element("tag")
+        elem.text = "<&\"\'>"
+        self.assertEqual(serialize(elem), '<tag>&lt;&amp;"\'&gt;</tag>')
+        self.assertEqual(serialize(elem, encoding="utf-8"),
+                b'<tag>&lt;&amp;"\'&gt;</tag>')
+        self.assertEqual(serialize(elem, encoding="us-ascii"),
+                b'<tag>&lt;&amp;"\'&gt;</tag>')
+        for enc in ("iso-8859-1", "utf-16", "utf-32"):
+            self.assertEqual(serialize(elem, encoding=enc),
+                    ("<?xml version='1.0' encoding='%s'?>\n"
+                     "<tag>&lt;&amp;\"'&gt;</tag>" % enc).encode(enc))
+
+        elem = ET.Element("tag")
+        elem.attrib["key"] = "<&\"\'>"
+        self.assertEqual(serialize(elem), '<tag key="&lt;&amp;&quot;\'&gt;" />')
+        self.assertEqual(serialize(elem, encoding="utf-8"),
+                b'<tag key="&lt;&amp;&quot;\'&gt;" />')
+        self.assertEqual(serialize(elem, encoding="us-ascii"),
+                b'<tag key="&lt;&amp;&quot;\'&gt;" />')
+        for enc in ("iso-8859-1", "utf-16", "utf-32"):
+            self.assertEqual(serialize(elem, encoding=enc),
+                    ("<?xml version='1.0' encoding='%s'?>\n"
+                     "<tag key=\"&lt;&amp;&quot;'&gt;\" />" % enc).encode(enc))
+
+        elem = ET.Element("tag")
+        elem.text = '\xe5\xf6\xf6<>'
+        self.assertEqual(serialize(elem), '<tag>\xe5\xf6\xf6&lt;&gt;</tag>')
+        self.assertEqual(serialize(elem, encoding="utf-8"),
+                b'<tag>\xc3\xa5\xc3\xb6\xc3\xb6&lt;&gt;</tag>')
+        self.assertEqual(serialize(elem, encoding="us-ascii"),
+                b'<tag>&#229;&#246;&#246;&lt;&gt;</tag>')
+        for enc in ("iso-8859-1", "utf-16", "utf-32"):
+            self.assertEqual(serialize(elem, encoding=enc),
+                    ("<?xml version='1.0' encoding='%s'?>\n"
+                     "<tag>??????&lt;&gt;</tag>" % enc).encode(enc))
+
+        elem = ET.Element("tag")
+        elem.attrib["key"] = '\xe5\xf6\xf6<>'
+        self.assertEqual(serialize(elem), '<tag key="\xe5\xf6\xf6&lt;&gt;" />')
+        self.assertEqual(serialize(elem, encoding="utf-8"),
+                b'<tag key="\xc3\xa5\xc3\xb6\xc3\xb6&lt;&gt;" />')
+        self.assertEqual(serialize(elem, encoding="us-ascii"),
+                b'<tag key="&#229;&#246;&#246;&lt;&gt;" />')
+        for enc in ("iso-8859-1", "utf-16", "utf-16le", "utf-16be", "utf-32"):
+            self.assertEqual(serialize(elem, encoding=enc),
+                    ("<?xml version='1.0' encoding='%s'?>\n"
+                     "<tag key=\"??????&lt;&gt;\" />" % enc).encode(enc))
+
+    def test_write_to_filename(self):
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        tree.write(TESTFN)
+        with open(TESTFN, 'rb') as f:
+            self.assertEqual(f.read(), b'''<site />''')
+
+    def test_write_to_text_file(self):
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        with open(TESTFN, 'w', encoding='utf-8') as f:
+            tree.write(f, encoding='unicode')
+            self.assertFalse(f.closed)
+        with open(TESTFN, 'rb') as f:
+            self.assertEqual(f.read(), b'''<site />''')
+
+    def test_write_to_binary_file(self):
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        with open(TESTFN, 'wb') as f:
+            tree.write(f)
+            self.assertFalse(f.closed)
+        with open(TESTFN, 'rb') as f:
+            self.assertEqual(f.read(), b'''<site />''')
+
+    def test_write_to_binary_file_with_bom(self):
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        # test BOM writing to buffered file
+        with open(TESTFN, 'wb') as f:
+            tree.write(f, encoding='utf-16')
+            self.assertFalse(f.closed)
+        with open(TESTFN, 'rb') as f:
+            self.assertEqual(f.read(),
+                    '''<?xml version='1.0' encoding='utf-16'?>\n'''
+                    '''<site />'''.encode("utf-16"))
+        # test BOM writing to non-buffered file
+        with open(TESTFN, 'wb', buffering=0) as f:
+            tree.write(f, encoding='utf-16')
+            self.assertFalse(f.closed)
+        with open(TESTFN, 'rb') as f:
+            self.assertEqual(f.read(),
+                    '''<?xml version='1.0' encoding='utf-16'?>\n'''
+                    '''<site />'''.encode("utf-16"))
+
     def test_read_from_stringio(self):
         tree = ET.ElementTree()
+        stream = io.StringIO('''<?xml version="1.0"?><site></site>''')
+        tree.parse(stream)
+        self.assertEqual(tree.getroot().tag, 'site')
+
+    def test_write_to_stringio(self):
+        tree = ET.ElementTree(ET.XML('''<site />'''))
         stream = io.StringIO()
-        stream.write('''<?xml version="1.0"?><site></site>''')
-        stream.seek(0)
-        tree.parse(stream)
+        tree.write(stream, encoding='unicode')
+        self.assertEqual(stream.getvalue(), '''<site />''')
 
+    def test_read_from_bytesio(self):
+        tree = ET.ElementTree()
+        raw = io.BytesIO(b'''<?xml version="1.0"?><site></site>''')
+        tree.parse(raw)
         self.assertEqual(tree.getroot().tag, 'site')
 
+    def test_write_to_bytesio(self):
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        raw = io.BytesIO()
+        tree.write(raw)
+        self.assertEqual(raw.getvalue(), b'''<site />''')
+
+    class dummy:
+        pass
+
+    def test_read_from_user_text_reader(self):
+        stream = io.StringIO('''<?xml version="1.0"?><site></site>''')
+        reader = self.dummy()
+        reader.read = stream.read
+        tree = ET.ElementTree()
+        tree.parse(reader)
+        self.assertEqual(tree.getroot().tag, 'site')
+
+    def test_write_to_user_text_writer(self):
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        stream = io.StringIO()
+        writer = self.dummy()
+        writer.write = stream.write
+        tree.write(writer, encoding='unicode')
+        self.assertEqual(stream.getvalue(), '''<site />''')
+
+    def test_read_from_user_binary_reader(self):
+        raw = io.BytesIO(b'''<?xml version="1.0"?><site></site>''')
+        reader = self.dummy()
+        reader.read = raw.read
+        tree = ET.ElementTree()
+        tree.parse(reader)
+        self.assertEqual(tree.getroot().tag, 'site')
+        tree = ET.ElementTree()
+
+    def test_write_to_user_binary_writer(self):
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        raw = io.BytesIO()
+        writer = self.dummy()
+        writer.write = raw.write
+        tree.write(writer)
+        self.assertEqual(raw.getvalue(), b'''<site />''')
+
+    def test_write_to_user_binary_writer_with_bom(self):
+        tree = ET.ElementTree(ET.XML('''<site />'''))
+        raw = io.BytesIO()
+        writer = self.dummy()
+        writer.write = raw.write
+        writer.seekable = lambda: True
+        writer.tell = raw.tell
+        tree.write(writer, encoding="utf-16")
+        self.assertEqual(raw.getvalue(),
+                '''<?xml version='1.0' encoding='utf-16'?>\n'''
+                '''<site />'''.encode("utf-16"))
+
 
 class ParseErrorTest(unittest.TestCase):
     def test_subclass(self):
@@ -2299,7 +2409,7 @@
     test_classes = [
         ElementSlicingTest,
         BasicElementTest,
-        StringIOTest,
+        IOTest,
         ParseErrorTest,
         XincludeTest,
         ElementTreeTest,
diff -r 677a9326b4d4 Lib/xml/etree/ElementTree.py
--- a/Lib/xml/etree/ElementTree.py	Mon Jul 09 18:16:11 2012 -0700
+++ b/Lib/xml/etree/ElementTree.py	Fri Jul 13 23:23:04 2012 +0300
@@ -100,6 +100,8 @@
 import sys
 import re
 import warnings
+import io
+import contextlib
 
 from . import ElementPath
 
@@ -812,39 +814,22 @@
             encoding = "unicode"
         else:
             encoding = encoding.lower()
-        if hasattr(file_or_filename, "write"):
-            file = file_or_filename
-        else:
-            if encoding != "unicode":
-                file = open(file_or_filename, "wb")
+        with _get_writer(file_or_filename, encoding) as write:
+            if method == "xml" and (xml_declaration or
+                    (xml_declaration is None and
+                     encoding not in ("utf-8", "us-ascii", "unicode"))):
+                declared_encoding = encoding
+                if encoding == "unicode":
+                    # Retrieve the default encoding for the xml declaration
+                    import locale
+                    declared_encoding = locale.getpreferredencoding()
+                write("<?xml version='1.0' encoding='%s'?>\n" % declared_encoding)
+            if method == "text":
+                _serialize_text(write, self._root)
             else:
-                file = open(file_or_filename, "w")
-        if encoding != "unicode":
-            def write(text):
-                try:
-                    return file.write(text.encode(encoding,
-                                                  "xmlcharrefreplace"))
-                except (TypeError, AttributeError):
-                    _raise_serialization_error(text)
-        else:
-            write = file.write
-        if method == "xml" and (xml_declaration or
-                (xml_declaration is None and
-                 encoding not in ("utf-8", "us-ascii", "unicode"))):
-            declared_encoding = encoding
-            if encoding == "unicode":
-                # Retrieve the default encoding for the xml declaration
-                import locale
-                declared_encoding = locale.getpreferredencoding()
-            write("<?xml version='1.0' encoding='%s'?>\n" % declared_encoding)
-        if method == "text":
-            _serialize_text(write, self._root)
-        else:
-            qnames, namespaces = _namespaces(self._root, default_namespace)
-            serialize = _serialize[method]
-            serialize(write, self._root, qnames, namespaces)
-        if file_or_filename is not file:
-            file.close()
+                qnames, namespaces = _namespaces(self._root, default_namespace)
+                serialize = _serialize[method]
+                serialize(write, self._root, qnames, namespaces)
 
     def write_c14n(self, file):
         # lxml.etree compatibility.  use output method instead
@@ -853,6 +838,54 @@
 # --------------------------------------------------------------------
 # serialization support
 
+ at contextlib.contextmanager
+def _get_writer(file_or_filename, encoding):
+    # returns text write method and release all resourses after using
+    try:
+        write = file_or_filename.write
+    except AttributeError:
+        # file_or_filename is a file name
+        if encoding == "unicode":
+            file = open(file_or_filename, "w")
+        else:
+            file = open(file_or_filename, "w", encoding=encoding,
+                        errors="xmlcharrefreplace")
+        with file:
+            yield file.write
+    else:
+        # file_or_filename is a file-like object
+        # encoding determines if it is a text or binary writer
+        if encoding == "unicode":
+            # use a text writer as is
+            yield write
+        else:
+            # wrap a binary writer with TextIOWrapper
+            with contextlib.ExitStack() as stack:
+                if isinstance(file_or_filename, io.BufferedIOBase):
+                    file = file_or_filename
+                elif isinstance(file_or_filename, io.RawIOBase):
+                    file = io.BufferedWriter(file_or_filename)
+                    # keep the original file open when the BufferedWriter is destroyed
+                    stack.callback(file.detach)
+                else:
+                    file = io.BufferedIOBase()
+                    file.writable = lambda: True
+                    file.write = write
+                    try:
+                        # TextIOWrapper uses this methods to determine
+                        # if BOM (for UTF-16, etc) should be added
+                        file.seekable = file_or_filename.seekable
+                        file.tell = file_or_filename.tell
+                    except AttributeError:
+                        pass
+                file = io.TextIOWrapper(file,
+                                        encoding=encoding,
+                                        errors="xmlcharrefreplace",
+                                        newline="\n")
+                # keep the original file open when the TextIOWrapper is destroyed
+                stack.callback(file.detach)
+                yield file.write
+
 def _namespaces(elem, default_namespace=None):
     # identify namespaces used in this tree
 
@@ -1134,10 +1167,9 @@
 # @defreturn string
 
 def tostring(element, encoding=None, method=None):
-    class dummy:
-        pass
     data = []
-    file = dummy()
+    file = io.BufferedIOBase()
+    file.writable = lambda: True
     file.write = data.append
     ElementTree(element).write(file, encoding, method=method)
     if encoding in (str, "unicode"):
@@ -1161,10 +1193,9 @@
 # @since 1.3
 
 def tostringlist(element, encoding=None, method=None):
-    class dummy:
-        pass
     data = []
-    file = dummy()
+    file = io.BufferedIOBase()
+    file.writable = lambda: True
     file.write = data.append
     ElementTree(element).write(file, encoding, method=method)
     # FIXME: merge small fragments into larger parts

From report at bugs.python.org  Fri Jul 13 22:29:58 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 13 Jul 2012 20:29:58 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342211398.64.0.879380440438.issue15307@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

As the test is constructed now, that test will fail if run from a venv. It will be a simple matter to skip it if test_venv being run from a venv - I can add that at some point, but I agree it's orthogonal to the crux of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Fri Jul 13 22:30:12 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Jul 2012 20:30:12 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
In-Reply-To: <1342110252.89.0.365330670645.issue15334@psf.upfronthosting.co.za>
Message-ID: <1342211412.02.0.485828795412.issue15334@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently the patch didn't work:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/290/steps/test/logs/stdio

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Fri Jul 13 22:40:41 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Jul 2012 20:40:41 +0000
Subject: [issue15328] datetime.strptime slow
In-Reply-To: <1342015221.25.0.0683472526459.issue15328@psf.upfronthosting.co.za>
Message-ID: <1342212041.54.0.52519111248.issue15328@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If someone wants to propose a patch we can reopen the issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15328>
_______________________________________

From report at bugs.python.org  Fri Jul 13 22:40:51 2012
From: report at bugs.python.org (Tim Golden)
Date: Fri, 13 Jul 2012 20:40:51 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
In-Reply-To: <1342211412.02.0.485828795412.issue15334@psf.upfronthosting.co.za>
Message-ID: <500087D3.2050102@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Take the other approach and catch ACCESS_DENIED and skip?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Fri Jul 13 22:48:24 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 20:48:24 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
In-Reply-To: <1342110252.89.0.365330670645.issue15334@psf.upfronthosting.co.za>
Message-ID: <3WYmLv30TwzM2W@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 814927ff4ef2 by Antoine Pitrou in branch '2.7':
Try other approach to fix issue #15334.
http://hg.python.org/cpython/rev/814927ff4ef2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Fri Jul 13 22:49:52 2012
From: report at bugs.python.org (Tim Golden)
Date: Fri, 13 Jul 2012 20:49:52 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
In-Reply-To: <500087D3.2050102@timgolden.me.uk>
Message-ID: <500089F0.7030401@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

(I just ran up a service and its environ does include PROMPT, at least 
on an XP machine)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Fri Jul 13 22:51:39 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 20:51:39 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
In-Reply-To: <1342110252.89.0.365330670645.issue15334@psf.upfronthosting.co.za>
Message-ID: <3WYmQf3SRQzP7r@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset dad89e7479e8 by Antoine Pitrou in branch '3.2':
Try other approach to fix issue #15334.
http://hg.python.org/cpython/rev/dad89e7479e8

New changeset b4e4c57637cf by Antoine Pitrou in branch 'default':
Try other approach to fix issue #15334.
http://hg.python.org/cpython/rev/b4e4c57637cf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Fri Jul 13 23:07:22 2012
From: report at bugs.python.org (Cesar Mello)
Date: Fri, 13 Jul 2012 21:07:22 +0000
Subject: [issue14458] Non-admin installation fails
In-Reply-To: <1333198651.39.0.792037554974.issue14458@psf.upfronthosting.co.za>
Message-ID: <1342213642.12.0.627539460493.issue14458@psf.upfronthosting.co.za>


Cesar Mello <cmello at gmail.com> added the comment:

Just as a note: the following command line with /q instead of /qb works without the need for elevation:

msiexec /q /i python-2.7.3.amd64.msi MSIFASTINSTALL=7 TARGETDIR=C:\Users\Mello\Python27

And it is pretty fast! This was on a Windows 7 machine.

But if I install in a clean Windows XP, I can't get it to work. It seems something is not right with the CRT using this command line.

----------
nosy: +Cesar.Mello

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14458>
_______________________________________

From report at bugs.python.org  Sat Jul 14 00:33:04 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Jul 2012 22:33:04 +0000
Subject: [issue15338] test_UNC_path failure in test_import
In-Reply-To: <1342125761.76.0.749174282002.issue15338@psf.upfronthosting.co.za>
Message-ID: <1342218784.94.0.505646843413.issue15338@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15338>
_______________________________________

From report at bugs.python.org  Sat Jul 14 00:42:40 2012
From: report at bugs.python.org (samwyse)
Date: Fri, 13 Jul 2012 22:42:40 +0000
Subject: [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>
Message-ID: <1342219360.88.0.259035607343.issue13866@psf.upfronthosting.co.za>


Changes by samwyse <samwyse at gmail.com>:


----------
nosy: +samwyse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________

From report at bugs.python.org  Sat Jul 14 00:49:18 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 22:49:18 +0000
Subject: [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
In-Reply-To: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>
Message-ID: <3WYq2P0rblzPBD@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0dbffd3c1317 by Ned Deily in branch 'default':
Issue #15241: Fix test_prefixes failure in test_venv due to symlink in
http://hg.python.org/cpython/rev/0dbffd3c1317

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15241>
_______________________________________

From report at bugs.python.org  Sat Jul 14 01:22:08 2012
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 13 Jul 2012 23:22:08 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1342221728.55.0.686733505587.issue15301@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Larry, you're the expert on this.

Looks to me like the format character in PyArg_ParseTuple in posix_fchown and kin should be 'k' (unsigned long) rather than 'l' (signed long).

----------
nosy: +Mark.Shannon, larry
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sat Jul 14 01:23:21 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Jul 2012 23:23:21 +0000
Subject: [issue15334] access denied for HKEY_PERFORMANCE_DATA
In-Reply-To: <1342110252.89.0.365330670645.issue15334@psf.upfronthosting.co.za>
Message-ID: <1342221801.04.0.127653833223.issue15334@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It worked!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15334>
_______________________________________

From report at bugs.python.org  Sat Jul 14 01:25:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Jul 2012 23:25:05 +0000
Subject: [issue14458] Non-admin installation fails
In-Reply-To: <1333198651.39.0.792037554974.issue14458@psf.upfronthosting.co.za>
Message-ID: <1342221905.7.0.603142616806.issue14458@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/issue14458>
_______________________________________

From report at bugs.python.org  Sat Jul 14 01:34:22 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Jul 2012 23:34:22 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1342222462.89.0.953716928215.issue15301@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Possible duplicate of Issue4591?

----------
nosy: +haypo, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sat Jul 14 01:40:11 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Jul 2012 23:40:11 +0000
Subject: [issue15275] isinstance is called a more times that needed in ntpath
In-Reply-To: <1341668298.8.0.671820953585.issue15275@psf.upfronthosting.co.za>
Message-ID: <1342222811.72.0.812444598929.issue15275@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/issue15275>
_______________________________________

From report at bugs.python.org  Sat Jul 14 02:11:26 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Jul 2012 00:11:26 +0000
Subject: [issue15280] Don't use builtins as variable names in urllib.request
In-Reply-To: <1341675187.35.0.731342856867.issue15280@psf.upfronthosting.co.za>
Message-ID: <1342224686.5.0.666555838309.issue15280@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15280>
_______________________________________

From report at bugs.python.org  Sat Jul 14 02:15:51 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 14 Jul 2012 00:15:51 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1342224951.75.0.494917785196.issue15301@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I don't think "k" is the right answer.

POSIX defines the user and group parameters as uid_t and gid_t respectively; in turn, uid_t and gid_t are defined as "integers", pointedly omitting the either of the words "signed" or "unsigned".  So POSIX makes no guarantee that uid_t and gid_t are unsigned.

On the other hand: chown takes special values defined as "(uid_t)-1" and "(gid_t)-1" to indicate "don't change this value".  If we change chown to use "k" for uid and gid, then in order to use this value you'd have to pass in the equivalent unsigned value.  And that'd require you to know the size of an int on the local platform.  Yuck!

If this is a genuine problem, then I think we have to take "O" (or "O!") and convert the long by hand.  If it's -1, use "(uid_t)-1" (etc), otherwise convert as unsigned.  On the other hand, if this is only a theoretical problem then I'd prefer to wontfix and keep the code simple.

p.s. find uid_t / gid_t here: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html
chown here:
http://pubs.opengroup.org/onlinepubs/009695399/functions/chown.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sat Jul 14 02:22:01 2012
From: report at bugs.python.org (do1)
Date: Sat, 14 Jul 2012 00:22:01 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1342225321.49.0.798375877566.issue15301@psf.upfronthosting.co.za>


do1 <do1 at yandex.ru> added the comment:

Problem emerged when well-known backup software (rdiff-backup) is 'crashed' (as in no backups). So I think this is not that theoretical.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sat Jul 14 02:29:46 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 14 Jul 2012 00:29:46 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1342225786.03.0.33503090014.issue15301@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/issue15301>
_______________________________________

From report at bugs.python.org  Sat Jul 14 02:37:53 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 14 Jul 2012 00:37:53 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1342226273.7.0.150482536489.issue15301@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Thinking about it some more, maybe we need to be smart about whether uid_t/gid_t are signed or unsigned.

I'm no good with configure hackery--could anyone here enhance the configure script so it could tell us whether or not uid_t and gid_t were signed or unsigned?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sat Jul 14 02:40:01 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 14 Jul 2012 00:40:01 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1342226401.18.0.6584883965.issue15301@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

There is a proposed patch by haypo with Issue4591.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sat Jul 14 03:07:00 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 14 Jul 2012 01:07:00 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342228020.91.0.986121894954.issue15307@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

v5 fixes the non normalized path issue.  However, the PYTHONEXECUTABLE env var -> argv processing is still broken, as detected by the test_osx_env failure.  It's definitely caused by interaction between pythonw.c and the main interpreter; if the interpreter is launched directly (not via pythonw), PYTHONEXECUTABLE works correctly.

Also, the patch needs to be tab-free: no more tabs for C files!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Sat Jul 14 08:17:24 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 14 Jul 2012 06:17:24 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1342246644.01.0.10853210858.issue15301@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

That patch from Victor looks pretty good.  I'll try to get it in for beta 2, however I'm on the road right now.  I'm back Sunday night and will try to do it then.

If someone else wants to jump in that's fine with me.

----------
assignee:  -> larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sat Jul 14 09:19:11 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Jul 2012 07:19:11 +0000
Subject: [issue15331] Codecs docs should explain that the bytes-bytes
	shorthand aliases are missing
In-Reply-To: <1342091074.63.0.386956250979.issue15331@psf.upfronthosting.co.za>
Message-ID: <1342250351.73.0.994637545781.issue15331@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

While you're right about that, the docs shouldn't be claiming they're available as long as that is the case.

Updated the issue to make it clear this is a problem with the current docs and the change in the nature of the encode() and decode() methods for Python 3.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage: test needed -> needs patch
title: Missing codec aliases for bytes-bytes codecs -> Codecs docs should explain that the bytes-bytes shorthand aliases are missing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15331>
_______________________________________

From report at bugs.python.org  Sat Jul 14 09:36:42 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Jul 2012 07:36:42 +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: <1342251402.78.0.0152149184069.issue7475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

FWIW it's, I've been thinking further about this recently and I think implementing this feature as builtin methods is the wrong way to approach it.

Instead, I propose the addition of codecs.encode and codecs.decode methods that are type neutral (leaving any type checks entirely up to the codecs themselves), while the str.encode and bytes.decode methods retain their current strict test model related type restrictions.

Also, I now think my previous proposal for nice error messages was massively over-engineered. A much simpler approach is to just replace the status quo:

>>> "".encode("bz2_codec")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ncoghlan/devel/py3k/Lib/encodings/bz2_codec.py", line 17, in bz2_encode
    return (bz2.compress(input), len(input))
  File "/home/ncoghlan/devel/py3k/Lib/bz2.py", line 443, in compress
    return comp.compress(data) + comp.flush()
TypeError: 'str' does not support the buffer interface

with a better error with more context like:

UnicodeEncodeError: encoding='bz2_codec', errors='strict', codec_error="TypeError: 'str' does not support the buffer interface"

A similar change would be straightforward on the decoding side.

This would be a good use case for __cause__, but the codec error should still be included in the string representation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Sat Jul 14 09:38:57 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Jul 2012 07:38:57 +0000
Subject: [issue15339] document the threading "facts of life" in Python
In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>
Message-ID: <1342251537.64.0.965891381169.issue15339@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given the scope of the issue, a concurrent programming howto that lists some of the available options and the caveats associated with each of them seems worthwhile.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15339>
_______________________________________

From report at bugs.python.org  Sat Jul 14 11:41:04 2012
From: report at bugs.python.org (Ztatik Light)
Date: Sat, 14 Jul 2012 09:41:04 +0000
Subject: [issue15349] SyntaxError b0rked grammar
Message-ID: <1342258864.48.0.924428948709.issue15349@psf.upfronthosting.co.za>


New submission from Ztatik Light <ztatik.light at gmail.com>:

SyntaxError: import * is not allowed in function '__init__' because it is contains a nested function with free variables


^ .... /s/"because it is contains"/"because it contains"

----------
components: Interpreter Core
messages: 165437
nosy: Ztatik.Light
priority: normal
severity: normal
status: open
title: SyntaxError b0rked grammar
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15349>
_______________________________________

From report at bugs.python.org  Sat Jul 14 11:46:54 2012
From: report at bugs.python.org (d9pouces)
Date: Sat, 14 Jul 2012 09:46:54 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1342259214.3.0.638000997495.issue14455@psf.upfronthosting.co.za>


d9pouces <python at 19pouces.net> added the comment:

The plutil (Apple's command-line tool to convert plist files from a format to another) returns an error if you try to convert a XML plist with dates to JSON.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14455>
_______________________________________

From report at bugs.python.org  Sat Jul 14 12:51:15 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Jul 2012 10:51:15 +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: <1342263075.05.0.306376728238.issue7475@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/issue7475>
_______________________________________

From report at bugs.python.org  Sat Jul 14 12:52:16 2012
From: report at bugs.python.org (samwyse)
Date: Sat, 14 Jul 2012 10:52:16 +0000
Subject: [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>
Message-ID: <1342263136.52.0.34303332808.issue13866@psf.upfronthosting.co.za>


samwyse <samwyse at gmail.com> added the comment:

Since no one else seems willing to do it, here's a patch that adds a 'quote_via' keyword parameter to the urlencode function.

>>> import urllib.parse
>>> query={"foo": "+ "}
>>> urllib.parse.urlencode(query)
'foo=%2B+'
>>> urllib.parse.urlencode(query, quote_via=urllib.parse.quote)
'foo=%2B%20'

----------
keywords: +patch
Added file: http://bugs.python.org/file26378/urllib_parse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________

From report at bugs.python.org  Sat Jul 14 13:05:34 2012
From: report at bugs.python.org (samwyse)
Date: Sat, 14 Jul 2012 11:05:34 +0000
Subject: [issue15350] {urllib,urllib.parse}.urlencode.__doc__ is unclear
Message-ID: <1342263934.43.0.385544849615.issue15350@psf.upfronthosting.co.za>


New submission from samwyse <samwyse at gmail.com>:

The doc string for url encode states:

    The query arg may be either a string or a bytes type. When query arg is a
    string, the safe, encoding and error parameters are sent to the quote_via
    function for encoding

IMHO, this implies that the argument can be a string.  Note that the preceding paragraphs starts out with "If the query arg is a sequence of two-element tuples". I think that it should read:

    The components of the query arg may be either a string or a bytes
    type. When query arg is a string, the safe, encoding and error
    parameters are sent to the quote_via function for encoding.

----------
components: Library (Lib)
messages: 165440
nosy: samwyse
priority: normal
severity: normal
status: open
title: {urllib,urllib.parse}.urlencode.__doc__ is unclear
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/issue15350>
_______________________________________

From report at bugs.python.org  Sat Jul 14 13:24:07 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Jul 2012 11:24:07 +0000
Subject: [issue15350] {urllib,urllib.parse}.urlencode.__doc__ is unclear
In-Reply-To: <1342263934.43.0.385544849615.issue15350@psf.upfronthosting.co.za>
Message-ID: <1342265047.38.0.279884472352.issue15350@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch
type: behavior -> enhancement
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15350>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:05:16 2012
From: report at bugs.python.org (samwyse)
Date: Sat, 14 Jul 2012 12:05:16 +0000
Subject: [issue15327] Argparse: main arguments and subparser arguments
	indistinguishable
In-Reply-To: <1342004730.08.0.363281774737.issue15327@psf.upfronthosting.co.za>
Message-ID: <1342267516.88.0.973697180146.issue15327@psf.upfronthosting.co.za>


samwyse <samwyse at gmail.com> added the comment:

The Namespace object contains a combined list of all of the arguments, from both the main parser and the subparser.  I don't see any way to resolve identically name augments without breaking a lot of code that relies on the current behavior.  I would instead propose that anyone needing to distinguish between identically named args in nested parsers use distinct names as the primary name of the argument, and the non-distictive name as an alias.  For example:
    parser.add_argument('--verbose(main)', '--verbose', ...)

Running the attached file produces the following output.

# using non-distinctive args
['--verbose', 'command'] => Namespace(command='command', verbose=True)
['command', '--verbose'] => Namespace(command='command', verbose=True)
['--verbose', 'command', '--verbose'] => Namespace(command='command', verbose=True)

# using distinctive args
['--verbose', 'command'] => Namespace(command='command', verbose(main)=True, verbose(subcommand)=False)
['command', '--verbose'] => Namespace(command='command', verbose(main)=False, verbose(subcommand)=True)
['--verbose', 'command', '--verbose'] => Namespace(command='command', verbose(main)=True, verbose(subcommand)=True)

----------
nosy: +samwyse
Added file: http://bugs.python.org/file26379/argparsetest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15327>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:34:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 12:34:05 +0000
Subject: [issue15280] Don't use builtins as variable names in urllib.request
In-Reply-To: <1341675187.35.0.731342856867.issue15280@psf.upfronthosting.co.za>
Message-ID: <1342269245.72.0.72645963925.issue15280@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We don?t do code cleanups for their own sake, but rather as part of a bug fix or feature addition.  Please see #15137 for a longer explanation.

----------
nosy: +eric.araujo, r.david.murray, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15280>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:42:32 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 12:42:32 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1342269752.97.0.686926134978.issue15311@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/issue15311>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:43:10 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 12:43:10 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <1342269790.35.0.555637372231.issue15314@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/issue15314>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:44:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 12:44:46 +0000
Subject: [issue15317] Source installation sets incorrect permissions for
	Grammar3.2.3.final.0.pickle
In-Reply-To: <1341904877.85.0.287783743443.issue15317@psf.upfronthosting.co.za>
Message-ID: <1342269886.84.0.680553830262.issue15317@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

How did you configure and build?  If you ran make as root it may explain this.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15317>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:47:00 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 14 Jul 2012 12:47:00 +0000
Subject: [issue15280] Don't use builtins as variable names in urllib.request
In-Reply-To: <1342269245.72.0.72645963925.issue15280@psf.upfronthosting.co.za>
Message-ID: <CAOMb=Fu2kzD9rmDWZuxqbWDQWnz6MzgkiodQ6UqBn-6n44NYdQ@mail.gmail.com>


Brian Brazil <brian.brazil at gmail.com> added the comment:

This patch is a result of frustration encountered when debugging #15002.
Not being able to use 'type' directly is rather annoying, so after figuring
that bug out I set some time aside to make it easier for the next person.

This could be considered a bug that urllib is hard to debug and breaks
vim's syntax highlighting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15280>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:48:17 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 12:48:17 +0000
Subject: [issue15323] Provide target name in output message when
	Mock.assert_called_once_with fails
In-Reply-To: <1341976761.94.0.831856606531.issue15323@psf.upfronthosting.co.za>
Message-ID: <1342270097.97.0.816600935877.issue15323@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nice idea!  A small question: Why print 'time' in the message and not 'time.time'?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15323>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:50:28 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 12:50:28 +0000
Subject: [issue15328] datetime.strptime slow
In-Reply-To: <1342015221.25.0.0683472526459.issue15328@psf.upfronthosting.co.za>
Message-ID: <1342270228.08.0.383685584246.issue15328@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Extension Modules -None
versions: +Python 3.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15328>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:55:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 12:55:12 +0000
Subject: [issue15336] Argparse required arguments incorrectly displayed as
	optional arguments
In-Reply-To: <1342122214.84.0.306915245284.issue15336@psf.upfronthosting.co.za>
Message-ID: <1342270512.9.0.316714211164.issue15336@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/issue15336>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:56:11 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 12:56:11 +0000
Subject: [issue15337] The cmd module incorrectly lists "help" as an
	undocumented command
In-Reply-To: <1342122491.31.0.595399950091.issue15337@psf.upfronthosting.co.za>
Message-ID: <1342270571.28.0.703151101021.issue15337@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
title: The cmd module incorrectly lists "help" as an undocument command -> The cmd module incorrectly lists "help" as an undocumented command

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15337>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:57:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 12:57:39 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342270659.55.0.081132842157.issue15343@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +brett.cannon, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:58:15 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 12:58:15 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342270695.65.0.496536388553.issue15343@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sounds like a pkgutil-related issue to me.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sat Jul 14 14:59:49 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 12:59:49 +0000
Subject: [issue15299] pkgutil.ImpImporter(None).iter_modules() does not search
	sys.path
In-Reply-To: <1341784087.15.0.754005593473.issue15299@psf.upfronthosting.co.za>
Message-ID: <1342270789.95.0.297786152603.issue15299@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +brett.cannon, eric.araujo, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15299>
_______________________________________

From report at bugs.python.org  Sat Jul 14 15:25:44 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Jul 2012 13:25:44 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1342272344.78.0.527055195318.issue5815@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Here is yet some inconsistency:

$ LANG=uk_ua.microsoftcp1251 ./python -c "import locale; print(locale.getdefaultlocale())"
('uk_UA', 'CP1251')
$ LANG=uk_ua.microsoft-cp1251 ./python -c "import locale; print(locale.getdefaultlocale())"
('uk_UA', 'microsoft_cp1251')

$ ./python -c "import locale; print(locale.normalize('ka_ge.georgianacademy'))"
ka_GE.GEORGIAN-ACADEMY
$ ./python -c "import locale; print(locale.normalize('ka_GE.GEORGIAN-ACADEMY'))"
ka_GE.georgian_academy

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Sat Jul 14 15:27:21 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Jul 2012 13:27:21 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1342272441.92.0.695162078058.issue5815@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Here is a complex patch for more careful locale parsing.

----------
Added file: http://bugs.python.org/file26380/locale_parse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Sat Jul 14 15:55:56 2012
From: report at bugs.python.org (samwyse)
Date: Sat, 14 Jul 2012 13:55:56 +0000
Subject: [issue15327] Argparse: main arguments and subparser arguments
	indistinguishable
In-Reply-To: <1342004730.08.0.363281774737.issue15327@psf.upfronthosting.co.za>
Message-ID: <1342274156.96.0.333256233646.issue15327@psf.upfronthosting.co.za>


samwyse <samwyse at gmail.com> added the comment:

One change and one minor problem with my suggestion.

First, you don't need the second alias, since it's a prefix of the argument name.  Also, HelpFormatter._format_actions_usage ends with a bit of code labeled "clean up separators for mutually exclusive groups"; it removes matched parentheses from the argument names.  :(  I'd recommend that you instead use one of the following (all of which I've tested):

    parser.add_argument('--verbose[main]', ...)
    parser.add_argument('--verbose{main}', ...)
    parser.add_argument('--verbose<main>', ...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15327>
_______________________________________

From report at bugs.python.org  Sat Jul 14 16:08:04 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Jul 2012 14:08:04 +0000
Subject: [issue15230] runpy.run_path doesn't set __package__ correctly
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <3WZCQV3z4VzPGh@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3b05cf877124 by Nick Coghlan in branch '3.2':
Close #15230: runpy.run_path now sets __package__ correctly. Also refactored the runpy tests to use a more systematic approach
http://hg.python.org/cpython/rev/3b05cf877124

New changeset 8a44e7c0fa30 by Nick Coghlan in branch 'default':
Merge fix for #15230 from 3.2
http://hg.python.org/cpython/rev/8a44e7c0fa30

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15230>
_______________________________________

From report at bugs.python.org  Sat Jul 14 16:14:54 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Sat, 14 Jul 2012 14:14:54 +0000
Subject: [issue14935] PEP 384 Refactoring applied to _csv module
In-Reply-To: <1338222171.68.0.797250497291.issue14935@psf.upfronthosting.co.za>
Message-ID: <1342275294.83.0.459636939362.issue14935@psf.upfronthosting.co.za>


Robin Schreiber <robin.schreiber at me.com> added the comment:

Added missing INCREF and DECREF inside the dealloc, and new methods of the types.

----------
Added file: http://bugs.python.org/file26381/csv_pep384_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14935>
_______________________________________

From report at bugs.python.org  Sat Jul 14 16:38:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Jul 2012 14:38:59 +0000
Subject: [issue15230] runpy.run_path doesn't set __package__ correctly
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <3WZD696vKnzPDQ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4880aac5c665 by Nick Coghlan in branch '3.2':
Issue #15230: Update runpy docs to clarify a couple of points that came up in this issue
http://hg.python.org/cpython/rev/4880aac5c665

New changeset 416cd57d38cf by Nick Coghlan in branch 'default':
Merge #15230 doc updates from 3.2
http://hg.python.org/cpython/rev/416cd57d38cf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15230>
_______________________________________

From report at bugs.python.org  Sat Jul 14 16:54:34 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Jul 2012 14:54:34 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342277674.32.0.764119493486.issue15343@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Indeed, pydoc relies on pkgutil.walk_packages to work out what to document, and that's broken currently due to the reliance on a non-standard importer API that isn't in PEP 302 (not even as an optional extension, like the get_filename() used by runpy)

I'm not seeing any way out other than to add an API to the importlib importers that pkgutil can use. My preference is to call that method "_iter_modules" right now, and then we can look at making it (or something like it) public for 3.4.

----------
nosy: +georg.brandl
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sat Jul 14 17:33:52 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 14 Jul 2012 15:33:52 +0000
Subject: [issue15351] Add to unittest.TestCase support for using context
	managers
Message-ID: <1342280032.27.0.345733068822.issue15351@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The setUp() and tearDown() methods of unittest.TestCase are of course extremely useful.  But sometimes one has set up and tear down functionality that one would like to apply in the form of an existing context manager (and that may be from an outside source).

There is currently no clear or clean way to do this.  It would be nice if unittest exposed a way to do this.

The closest I have been able to come is overriding TestCase.run() as follows:

class MyTest(unittest.TestCase):

    def run(self, result=None):
        with my_context_manager() as foo:
            # Do stuff.
            super(MyTest, self).run(result)

But this is not ideal because the context manager is surrounding more than it should (various test initialization code internal to unittest, etc).  Also, ideally the API would let one apply a context manager either before or after setUp() and tearDown(), or both.

Here is one idea for an API.  unittest.TestCase could expose a setUpContext() context manager that wraps the user-defined setUp() and tearDown(), and also a runTestMethod() method that runs the test method code by itself (i.e. currently the following line of unittest/case.py: `self._executeTestPart(testMethod, outcome, isTest=True)`).

To use the API, the user could override a simple method called something like runTest():

    def runTest(self):
        with setUpContext():
            self.runTestMethod()

The user would, in the override, be free to insert additional context managers before or after setUpContext(), or both.

----------
components: Library (Lib)
messages: 165454
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Add to unittest.TestCase support for using context managers
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15351>
_______________________________________

From report at bugs.python.org  Sat Jul 14 17:57:01 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 14 Jul 2012 15:57:01 +0000
Subject: [issue15299] pkgutil.ImpImporter(None).iter_modules() does not search
	sys.path
In-Reply-To: <1341784087.15.0.754005593473.issue15299@psf.upfronthosting.co.za>
Message-ID: <1342281421.67.0.353259872975.issue15299@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

In addition, before changing ImpImporter.iter_modules(), we should probably also add some tests of the method for values of self.path that do work (i.e. for when self.path is not None).  The method is currently untested.

I can work on adding tests for that over the next few days.

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15299>
_______________________________________

From report at bugs.python.org  Sat Jul 14 18:38:26 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 14 Jul 2012 16:38:26 +0000
Subject: [issue15299] pkgutil.ImpImporter(None).iter_modules() does not search
	sys.path
In-Reply-To: <1341784087.15.0.754005593473.issue15299@psf.upfronthosting.co.za>
Message-ID: <1342283906.47.0.21833823085.issue15299@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15299>
_______________________________________

From report at bugs.python.org  Sat Jul 14 19:06:19 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 14 Jul 2012 17:06:19 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342285579.39.0.754909521902.issue15343@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Ugh, I don't exactly love the idea of adding a method to any of importlib's finders simply because PJE didn't try to make this non-standard API part of PEP 302 or something. But basically pkgutil is worthless without doing something about this damn iter_modules() method that the module keeps expecting.

Nick's proposal of adding importlib._bootstrap.FileFinder._iter_modules() is probably the best we can do with the timeline we have. But if we do this then I want to deprecate pkgutil in Python 3.4 and we can then get a proper API that is documented for module discovery and can have whatever helper code is needed in importlib (since namespace packages take care of the need for extend_path() and the only other use for pkgutil). That's the only deal I'm willing to strike here if we are going to keep pkgutil working in Python 3.3 as people expect.

----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sat Jul 14 19:14:34 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 14 Jul 2012 17:14:34 +0000
Subject: [issue15228] os.utime() docs not clear on behavior on nonexistant
	files
In-Reply-To: <1341086123.85.0.135321380132.issue15228@psf.upfronthosting.co.za>
Message-ID: <1342286074.1.0.43572270194.issue15228@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I don't think this needs clarifying.  If you think the reference to "touch" currently only muddles the issue, let's remove it entirely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15228>
_______________________________________

From report at bugs.python.org  Sat Jul 14 19:32:00 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 14 Jul 2012 17:32:00 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342287120.09.0.615553503099.issue15343@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not great, but that sounds reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sat Jul 14 19:38:45 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 14 Jul 2012 17:38:45 +0000
Subject: [issue15337] The cmd module incorrectly lists "help" as an
	undocumented command
In-Reply-To: <1342122491.31.0.595399950091.issue15337@psf.upfronthosting.co.za>
Message-ID: <1342287525.79.0.9550420596.issue15337@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

On 3.3.0b1 and 3.2 I get:


(Cmd) help

Documented commands (type help <topic>):
========================================
help


I only see help under "Undocumented" with 2.7.


It looks like this changeset f8c896ad787f never got backported to 2.7. This involves adding a doc string to do_help. Manually applying this doc_string fixes the problem on 2.7

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15337>
_______________________________________

From report at bugs.python.org  Sat Jul 14 19:42:16 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 14 Jul 2012 17:42:16 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342287736.51.0.641483531734.issue15343@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I agree pkgutil is pretty much useless right now and deprecation worth considering.  But isn't another option simply to change pkgutil's internals to provide its own iter_modules whenever it finds that method missing?  This seems to be what it has done in the past for some code paths when it made its own ImpImporter wrappers (in pkgutil.get_importer()):

http://hg.python.org/cpython/file/416cd57d38cf/Lib/pkgutil.py#l363

It seems this would at least work for FileFinders, though I haven't thought this through to know for sure one way or the other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sat Jul 14 19:58:58 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 14 Jul 2012 17:58:58 +0000
Subject: [issue15280] Don't use builtins as variable names in urllib.request
In-Reply-To: <1341675187.35.0.731342856867.issue15280@psf.upfronthosting.co.za>
Message-ID: <1342288738.91.0.221898571567.issue15280@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Not being able to use 'type' directly is rather annoying, so after figuring that bug out I set
> some time aside to make it easier for the next person.
If you make a patch for #15002 then by all means rename ?type? to ?filetype? so that you can use the type function without jumping through hoops.  Or see if using isinstance can avoid the need for type.

Note that Python lets you override a built-in name, it?s only a PEP 8 convention that recommends to avoid doing so.  In many cases it makes a lot of sense to name something ?type? (typically a class attribute), ?file? (like in the print function in 3.x) or ?open? (see tarfile, gzip, tokenize, etc.).

> This could be considered a bug that urllib is hard to debug
I don?t think so; we prefer keeping the code similar between branches so that patches are easier to port.

> and breaks vim's syntax highlighting.
I am a Vim user and think there are great things (like the fact that string delimiters are not highlighted as string contents) and debatable things (like the special color for self and built-in functions).

Your help with fixing bugs is very appreciated, but I think this patch will be rejected.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15280>
_______________________________________

From report at bugs.python.org  Sat Jul 14 20:16:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 14 Jul 2012 18:16:29 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342289789.75.0.972786505299.issue15343@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

In Python 2.7, I just did this test:

>>> import sys, pkgutil
>>> for path in sys.path:
...   print pkgutil.get_importer(path)

And got only pkgutil.ImpImporter instances and imp.NullImporter objects.

So even before, at least in the most common case, it looks like pkgutil may have been relying on its "wrapped" importers for access to an iter_modules() method.

When I do the same test in Python 3.3, I get only FileFinder instances.  So in Python 3.3, pkgutil just isn't getting to the lines that would otherwise create ImpImporter instances that would work for our purposes (presumably because sys.path_hooks is populated differently in Python 3.3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sat Jul 14 20:35:22 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 14 Jul 2012 18:35:22 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342290922.17.0.458625828848.issue15343@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Right, you aren't getting ImpImporters because they are only used when a module doesn't define __loader__. But in Python 3.3, by default *all* modules get that attribute defined.

And yes, we could either tweak pkgutil to recognize FileFinder and special-case it or we can add the method and tweak the probably two or three places the method is called. It's a matter of effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sat Jul 14 20:48:49 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Jul 2012 18:48:49 +0000
Subject: [issue9522] xml.etree.ElementTree forgets the encoding
In-Reply-To: <1281000730.31.0.804989593298.issue9522@psf.upfronthosting.co.za>
Message-ID: <1342291729.5.0.176044256023.issue9522@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9522>
_______________________________________

From report at bugs.python.org  Sat Jul 14 21:41:05 2012
From: report at bugs.python.org (Meador Inge)
Date: Sat, 14 Jul 2012 19:41:05 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
Message-ID: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

Today I was hacking on a patch that changes the marshaling format for Code objects.  When building the patch I was met with:

   ValueError: bad marshal data (unknown type code)
   make: *** [Lib/_sysconfigdata.py] Abort trap: 6

This is because the frozen importlib was not rebuilt with the new marshaling format.

----------
components: Build
messages: 165464
nosy: meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: importlib.h should be regenerated when the marshaling code changes
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Sat Jul 14 21:44:02 2012
From: report at bugs.python.org (Meador Inge)
Date: Sat, 14 Jul 2012 19:44:02 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
In-Reply-To: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za>
Message-ID: <1342295042.73.0.432787365109.issue15352@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Patch attached.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26382/issue15352-v0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Sat Jul 14 22:05:56 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Jul 2012 20:05:56 +0000
Subject: [issue15351] Add to unittest.TestCase support for using context
	managers
In-Reply-To: <1342280032.27.0.345733068822.issue15351@psf.upfronthosting.co.za>
Message-ID: <1342296356.23.0.510790929915.issue15351@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, if you want to invoke the context in setup/teardown for some reason (as opposed to in the test methods themselves), you can do this:

  def setUp(self):
      self.foo = MyContextManager.__enter__()
      self.addCleanup(MyContextManager.__exit__())

Personally I rarely do this (except occasionally the mock equivalent, see below), preferring to call the context manager explicitly in the test method itself, often factored out into a test helper.

I think we as a community are still learning how best to use context managers and what the optimum design of context manager is.  There is some thought that a context manager should always provide a non-context way of getting at the functionality of the enter and exit methods.  For example, the mock context managers have start() and stop() methods.  There has also been a small amount of discussion of making more use of context managers in unittest itself, possibly along the lines you suggest.

I think this may be an area in which we are not yet ready to settle on an API.  Michael may have a different opinion, of course ;)

----------
nosy: +michael.foord, r.david.murray
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15351>
_______________________________________

From report at bugs.python.org  Sat Jul 14 22:08:23 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Jul 2012 20:08:23 +0000
Subject: [issue15351] Add to unittest.TestCase support for using context
	managers
In-Reply-To: <1342280032.27.0.345733068822.issue15351@psf.upfronthosting.co.za>
Message-ID: <1342296503.08.0.416262003703.issue15351@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That should have been

   self.addCleanup(MyContextManager.__exit__)

You could alternatively call __exit__() explicitly in tearDown, of course, but I believe addCleanup is a more reliable cleanup than tearDown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15351>
_______________________________________

From report at bugs.python.org  Sat Jul 14 22:11:56 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Jul 2012 20:11:56 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
In-Reply-To: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za>
Message-ID: <1342296716.04.0.751609500531.issue15352@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good to me. It probably won't cover all cases (such as e.g. changing the bytecode format), but it's a good step forward.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Sat Jul 14 22:30:31 2012
From: report at bugs.python.org (Jerry Jacobs)
Date: Sat, 14 Jul 2012 20:30:31 +0000
Subject: [issue15353] ld: library not found for -lpython3.3m because of wrong
	LDFLAGS_PYTHON
Message-ID: <1342297831.17.0.252581659185.issue15353@psf.upfronthosting.co.za>


New submission from Jerry Jacobs <jerry at xor-gate.org>:

Dear all,

I'm using python in a application (sigrok.org) and want to ship it as a framework with a .app folder. 

I'm building python-3.3b1 from source to a .framework. It is correctly compiled and installed in the given directory. Only the python-3.3.pc is incorrect because it has not the name python-3.3m.pc and includes the following library entries: Libs: -L${libdir} -lpython3.3m

So this results in:
ld: library not found for -lpython3.3m
because of the deployment of the wrong .pc Libs directive:
build/decoders/nunchuk/Makefile
127:CPPFLAGS_PYTHON = -I/Users/jerry/Sigrok/Python.framework/Versions/3.3/include/python3.3m -I/Users/jerry/Sigrok/Python.framework/Versions/3.3/include/python3.3m
159:LDFLAGS_PYTHON = -L/Users/jerry/Sigrok/Python.framework/Versions/3.3/lib/python3.3/config-3.3m -ldl -framework CoreFoundation -lpython3.3m -framework CoreFoundation Python.framework/Versions/3.3/Python
187:PYTHON3_CONFIG = python3.3m-config

Kind regards,
Jerry

----------
assignee: ronaldoussoren
components: Macintosh
messages: 165469
nosy: Jerry.Jacobs, ronaldoussoren
priority: normal
severity: normal
status: open
title: ld: library not found for -lpython3.3m because of wrong LDFLAGS_PYTHON
type: compile error
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15353>
_______________________________________

From report at bugs.python.org  Sat Jul 14 22:31:24 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Jul 2012 20:31:24 +0000
Subject: [issue15353] ld: library not found for -lpython3.3m because of wrong
	LDFLAGS_PYTHON
In-Reply-To: <1342297831.17.0.252581659185.issue15353@psf.upfronthosting.co.za>
Message-ID: <1342297884.03.0.496326277078.issue15353@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +hynek, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15353>
_______________________________________

From report at bugs.python.org  Sat Jul 14 22:47:48 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 14 Jul 2012 20:47:48 +0000
Subject: [issue15353] ld: library not found for -lpython3.3m because of wrong
	LDFLAGS_PYTHON
In-Reply-To: <1342297831.17.0.252581659185.issue15353@psf.upfronthosting.co.za>
Message-ID: <1342298868.99.0.851866358696.issue15353@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee: ronaldoussoren -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15353>
_______________________________________

From report at bugs.python.org  Sat Jul 14 22:51:55 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 14 Jul 2012 20:51:55 +0000
Subject: [issue15351] Add to unittest.TestCase support for using context
	managers
In-Reply-To: <1342280032.27.0.345733068822.issue15351@psf.upfronthosting.co.za>
Message-ID: <1342299115.22.0.757057344065.issue15351@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks for the interesting background and feedback. I was aware of the __enter__/__exit__ option but not the other information. And yes, I agree on the importance of trying and discussing any API before settling on it. The one I suggested was merely a point of departure. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15351>
_______________________________________

From report at bugs.python.org  Sat Jul 14 23:12:50 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Jul 2012 21:12:50 +0000
Subject: [issue14340] Update embedded copy of expat - fix security & crash
	issues
In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za>
Message-ID: <3WZNrd4F0TzPDN@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e4dc8be9a72f by Gregory P. Smith in branch 'default':
Update the embedded copy of the expat XML parser to 2.1.0.  It brings
http://hg.python.org/cpython/rev/e4dc8be9a72f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14340>
_______________________________________

From report at bugs.python.org  Sat Jul 14 23:18:31 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 14 Jul 2012 21:18:31 +0000
Subject: [issue14340] Update embedded copy of expat - fix security & crash
	issues
In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za>
Message-ID: <1342300711.76.0.38767339549.issue14340@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Updated in 3.3 for beta2.

I'll leave it up to release managers to decide if they want to apply these updates for future 2.7 and 3.2 releases (trivial, just be sure to keep our one local modification adding the "#define XML_HAS_SET_HASH_SALT" to expat.h when you do it).

I'm leaving it as a release blocker for 2.7.4 and 3.2.4 so that they see it.

----------
versions: +Python 2.7, Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14340>
_______________________________________

From report at bugs.python.org  Sat Jul 14 23:39:34 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 14 Jul 2012 21:39:34 +0000
Subject: [issue14340] Update embedded copy of expat - fix security & crash
	issues
In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za>
Message-ID: <1342301974.37.0.460593575348.issue14340@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Reasons why it is a good idea to apply this change to 2.7.4 and 3.2.4:

* Memory leak in poolGrow (CVE-2012-1148)
* Resource leak in readfilemap.c (CVE-2012-1147)
* Buffer over-read and crash in big2_toUtf8 (CVE-2009-3560)
* Parser crash with special UTF-8 sequences (CVE-2009-3270)
* Dangling positionPtr after error (2855609) - http://sourceforge.net/tracker/?func=detail&aid=2855609&group_id=10127&atid=110127 - Specifically reported by a pyexpat user.
* Unitialized memory returned from XML_Parse (3206497) - http://sourceforge.net/tracker/?func=detail&aid=3206497&group_id=10127&atid=110127

The features 2.1.0 adds over 2.0.x are not exposed to pyexpat or Python users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14340>
_______________________________________

From report at bugs.python.org  Sun Jul 15 02:14:40 2012
From: report at bugs.python.org (Philip Jenvey)
Date: Sun, 15 Jul 2012 00:14:40 +0000
Subject: [issue15354] _PyObject_LengthHint only accepts longs
Message-ID: <1342311280.51.0.844161517469.issue15354@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at underboss.org>:

The __length_hint__ optimization was broken a while ago for many iterators due to a bug introduced in 44c090c74202. It only accepts longs as valid hints, not ints

This affects 2.6 too (but that's in security-only fix mode), but not 3.x

----------
assignee: pjenvey
messages: 165474
nosy: pjenvey
priority: normal
severity: normal
status: open
title: _PyObject_LengthHint only accepts longs
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15354>
_______________________________________

From report at bugs.python.org  Sun Jul 15 02:28:53 2012
From: report at bugs.python.org (Philip Jenvey)
Date: Sun, 15 Jul 2012 00:28:53 +0000
Subject: [issue15354] _PyObject_LengthHint only accepts longs
In-Reply-To: <1342311280.51.0.844161517469.issue15354@psf.upfronthosting.co.za>
Message-ID: <1342312133.33.0.798840847297.issue15354@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

attached a fix for review

----------
keywords: +patch
Added file: http://bugs.python.org/file26383/lengthhint-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15354>
_______________________________________

From report at bugs.python.org  Sun Jul 15 02:31:01 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 15 Jul 2012 00:31:01 +0000
Subject: [issue15355] generator.__next__() docs should mention exception if
	already executing
Message-ID: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think the generator.__next__() documentation should say that it raises an exception if the generator is already executing:

http://docs.python.org/dev/reference/expressions.html#generator.__next__

I don't think this is currently mentioned anywhere in the section on yield expressions.

I think this is worth mentioning because this is different from the general situation for iterators, for example.  One consequence of this is that, unlike for iterators, using a bare generator in a multithreaded situation will always result in a critical section (since an iterator can be made to take care of its own locking, etc).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 165476
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: generator.__next__() docs should mention exception if already executing
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15355>
_______________________________________

From report at bugs.python.org  Sun Jul 15 02:48:09 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Jul 2012 00:48:09 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1342313289.35.0.486871785838.issue15301@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

It looks like #1747858 is another duplicate.  Though arguably all these "dups" aren't really dups because I rewrote chown's argument parsing for 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sun Jul 15 02:53:05 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 15 Jul 2012 00:53:05 +0000
Subject: [issue15354] _PyObject_LengthHint only accepts longs
In-Reply-To: <1342311280.51.0.844161517469.issue15354@psf.upfronthosting.co.za>
Message-ID: <1342313585.29.0.17554518285.issue15354@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It's probably easier just to use PyNumber_Check.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15354>
_______________________________________

From report at bugs.python.org  Sun Jul 15 02:55:28 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 00:55:28 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <3WZTnS2N7GzNRY@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5f62c317c202 by Larry Hastings in branch 'default':
- Issue #15238: shutil.copystat now copies Linux "extended attributes".
http://hg.python.org/cpython/rev/5f62c317c202

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Sun Jul 15 02:57:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 00:57:09 +0000
Subject: [issue15354] _PyObject_LengthHint only accepts longs
In-Reply-To: <1342311280.51.0.844161517469.issue15354@psf.upfronthosting.co.za>
Message-ID: <3WZTqR4MkNzNkq@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 872afada51b0 by Benjamin Peterson in branch '2.7':
allow any number to be returned from __length_hint__ (closes #15354)
http://hg.python.org/cpython/rev/872afada51b0

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15354>
_______________________________________

From report at bugs.python.org  Sun Jul 15 03:00:58 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Jul 2012 01:00:58 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <1342314058.95.0.471379196959.issue15238@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Sun Jul 15 03:14:42 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Jul 2012 01:14:42 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1342314882.17.0.986170689792.issue15301@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Here's a first cut at a patch.  It's really just an update of Victor's patch to #4591 (done with his blessing).  I tweaked it slightly; the parsing functions are now O& converter functions.

I also added a reasonable unit test.  Note however that the unit test is only run if you run the test as root.

I don't think this needs any documentation, just a Misc/NEWS entry.

If someone can give me quick turnaround on a review (or two) maybe we can get this in before beta 2 tomorrow.

I'm adding Antoine and MvL as they were in on the earliest known bug of this class.

----------
keywords: +patch
nosy: +loewis, pitrou
Added file: http://bugs.python.org/file26384/larry.chown.unsigned.uid.gid.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sun Jul 15 03:16:13 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Jul 2012 01:16:13 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1342314973.26.0.376477742012.issue15233@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Okay, I'll remove the ".. note".  Checking in shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15233>
_______________________________________

From report at bugs.python.org  Sun Jul 15 03:21:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 01:21:16 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <3WZVMG6NkfzP42@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f8b520b6f654 by Larry Hastings in branch 'default':
- Issue #15233: Python now guarantees that callables registered with
http://hg.python.org/cpython/rev/f8b520b6f654

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15233>
_______________________________________

From report at bugs.python.org  Sun Jul 15 03:22:23 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Jul 2012 01:22:23 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1342315343.11.0.329603786914.issue15233@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

So, it's checked in to trunk.  Shall I also backport to 2.7 and 3.2 as the issue suggests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15233>
_______________________________________

From report at bugs.python.org  Sun Jul 15 03:28:54 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Jul 2012 01:28:54 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1342315734.16.0.640481718556.issue15202@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

The .4 patches both LGTM, please commit!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15202>
_______________________________________

From report at bugs.python.org  Sun Jul 15 03:50:27 2012
From: report at bugs.python.org (zoupl)
Date: Sun, 15 Jul 2012 01:50:27 +0000
Subject: [issue15356] '\xa0' isspace returns true while compiling python on
	solaris 10 by users using gcc 3.4.6
Message-ID: <1342317027.18.0.929395647565.issue15356@psf.upfronthosting.co.za>


New submission from zoupl <zoupengli at gmail.com>:

Compile python (from 2.4.6 to version 2.6.8) on solaris 5.10 sparc using gcc 3.4.6. When using UTf-8, the \xa0 is a space. Howeve this is wrong. Version 2.7 is OK.

>>> s = '\xa0'
>>> assert s.strip() == s
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'en_US.UTF-8'
>>> assert s.strip() == s

----------
components: Unicode
messages: 165486
nosy: ezio.melotti, zoupl
priority: normal
severity: normal
status: open
title: '\xa0' isspace returns true while compiling python on solaris 10 by users using gcc 3.4.6
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15356>
_______________________________________

From report at bugs.python.org  Sun Jul 15 04:18:56 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 02:18:56 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342318736.45.0.22222007344.issue15343@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

*sigh* And, of course, there's no meaningful regression test defined for pkgutil.walk_packages, which is why the test suite didn't pick this up :(

Oh well, at least I have a clear place to start.

----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sun Jul 15 04:27:16 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 02:27:16 +0000
Subject: [issue15357] Deprecate redundant pieces of pkgutil
Message-ID: <1342319236.08.0.487526794106.issue15357@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

To set the stage for fixing the regression reported in #15343, I'm going through and clearly marking the parts of pkgutil which should no longer be used now that the default import system is PEP 302 compliant.

----------
assignee: ncoghlan
components: Library (Lib)
messages: 165488
nosy: georg.brandl, ncoghlan
priority: release blocker
severity: normal
status: open
title: Deprecate redundant pieces of pkgutil
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15357>
_______________________________________

From report at bugs.python.org  Sun Jul 15 04:34:13 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 02:34:13 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1342319653.16.0.0360648245542.issue14814@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Unassigning for the moment - I'm busy fighting fires in pkgutil (which is actually broken due to the import changes). If someone else has time to flesh out the method and data attribute documentation for the ipaddress classes, that would be great.

----------
assignee: ncoghlan -> 
components: +Documentation -Library (Lib)
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Sun Jul 15 04:45:07 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Jul 2012 02:45:07 +0000
Subject: [issue15356] '\xa0' isspace returns true while compiling python on
	solaris 10 by users using gcc 3.4.6
In-Reply-To: <1342317027.18.0.929395647565.issue15356@psf.upfronthosting.co.za>
Message-ID: <1342320307.31.0.223139497855.issue15356@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

2.6 only gets security fixes at this point, which this is not.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15356>
_______________________________________

From report at bugs.python.org  Sun Jul 15 04:53:42 2012
From: report at bugs.python.org (zoupl)
Date: Sun, 15 Jul 2012 02:53:42 +0000
Subject: [issue15356] '\xa0' isspace returns true while compiling python on
	solaris 10 by users using gcc 3.4.6
In-Reply-To: <1342317027.18.0.929395647565.issue15356@psf.upfronthosting.co.za>
Message-ID: <1342320822.43.0.502663167085.issue15356@psf.upfronthosting.co.za>


zoupl <zoupengli at gmail.com> added the comment:

Could you please tell me the way to deal with this is version 2.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15356>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:00:04 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Jul 2012 03:00:04 +0000
Subject: [issue12978] Figure out extended attributes on BSDs
In-Reply-To: <1316014526.21.0.982877507813.issue12978@psf.upfronthosting.co.za>
Message-ID: <1342321204.11.0.282429613543.issue12978@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/issue12978>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:02:43 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 03:02:43 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <3WZXcL0NsmzPBJ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6120cf695574 by Eli Bendersky in branch 'default':
Close #1767933: Badly formed XML using etree and utf-16. Patch by Serhiy Storchaka, with some minor fixes by me
http://hg.python.org/cpython/rev/6120cf695574

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:20:03 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 03:20:03 +0000
Subject: [issue9458] xml.etree.ElementTree.ElementTree.write(): encoding
	handling problems
In-Reply-To: <1280782925.67.0.136452249646.issue9458@psf.upfronthosting.co.za>
Message-ID: <3WZY0L53v8zPBM@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 51b5ee7cfa3b by Eli Bendersky in branch 'default':
Issue #9458: clarify the documentation of ElementTree.write with regards to the type of the stream expected for a given encoding
http://hg.python.org/cpython/rev/51b5ee7cfa3b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9458>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:20:58 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:20:58 +0000
Subject: [issue9458] xml.etree.ElementTree.ElementTree.write(): encoding
	handling problems
In-Reply-To: <1280782925.67.0.136452249646.issue9458@psf.upfronthosting.co.za>
Message-ID: <1342322458.93.0.731985565555.issue9458@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I agree with Serhiy that this is more of a documentation/understanding issue than a real bug. I've clarified the doc of ElementTree.write a bit to make it explicit what stream is expected for 'write'.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9458>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:35:40 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:35:40 +0000
Subject: [issue13823] xml.etree.ElementTree.ElementTree.write - argument
	checking
In-Reply-To: <1326963107.43.0.928827185581.issue13823@psf.upfronthosting.co.za>
Message-ID: <1342323340.07.0.267970309887.issue13823@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

About (1):

It's customary for Python to accept "truthful" values (like non-empty strings) as True. I see no harm in that. Strict type-checking to boolean True in each and every place is not necessary.

About (2):

Similarly, this isn't productive. ET may not know about all encodings underlying the system. The warning is clearly documented - it's up for the user to make sure it's valid.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13823>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:39:49 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:39:49 +0000
Subject: [issue13378] ET: add custom namespaces to serialization methods
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1342323589.73.0.491680583592.issue13378@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I'm changing the issue name to reflect the direction it's taken. Florent, once 3.3 is branched, could you please refresh the patch vs. head for 3.4 (don't forget the "what's new") and I'll review it for commit.

----------
title: Change the variable "nsmap" from global to instance (xml.etree.ElementTree) -> ET: add custom namespaces to serialization methods

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:42:41 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:42:41 +0000
Subject: [issue13378] ET: add custom namespaces to serialization methods
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1342323761.83.0.396205989931.issue13378@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I'd also expand the doc of register_namespace to note what it should and shouldn't be used for (once this feature is added).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:43:06 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 03:43:06 +0000
Subject: [issue15299] pkgutil.ImpImporter(None).iter_modules() does not search
	sys.path
In-Reply-To: <1341784087.15.0.754005593473.issue15299@psf.upfronthosting.co.za>
Message-ID: <1342323786.26.0.423413734767.issue15299@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The pkgutil import emulation is being deprecated in 3.3

However, I'll use this as useful input for any new walk_packages tests added while resolving #15343

----------
resolution:  -> wont fix
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15299>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:45:22 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 03:45:22 +0000
Subject: [issue15272] pkgutil.find_loader accepts invalid module names
In-Reply-To: <1341656387.47.0.245292094882.issue15272@psf.upfronthosting.co.za>
Message-ID: <1342323922.28.0.514025575121.issue15272@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'll add a regression test for this as part of my purge of any internal usage of the pkgutil import emulation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15272>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:45:24 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:45:24 +0000
Subject: [issue14988] _elementtree: Raise ImportError when importing of
	pyexpat fails
In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za>
Message-ID: <1342323924.78.0.150850266203.issue14988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I agree, but this will now be delayed to 3.4, since it's not a bug-fixing change in functionality.

P.S. is there any way to create a test for it?

----------
assignee:  -> eli.bendersky
priority: normal -> low
type:  -> behavior
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14988>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:45:42 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:45:42 +0000
Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way
In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za>
Message-ID: <1342323942.8.0.00452133601063.issue15083@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15083>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:48:03 2012
From: report at bugs.python.org (Eric Snow)
Date: Sun, 15 Jul 2012 03:48:03 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
In-Reply-To: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za>
Message-ID: <1342324083.16.0.986314122682.issue15352@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI: the .pyc magic number is now built/kept in Lib/importlib/_bootstrap.py, so updates to it will trigger a rebuild of frozen importlib during make.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:49:07 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Jul 2012 03:49:07 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342324147.36.0.966656033667.issue15343@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/issue15343>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:53:40 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:53:40 +0000
Subject: [issue10908] Improvements to trace._Ignore
In-Reply-To: <1295020376.03.0.967767300509.issue10908@psf.upfronthosting.co.za>
Message-ID: <1342324420.76.0.691149551859.issue10908@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/issue10908>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:53:59 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:53:59 +0000
Subject: [issue9914] trace/profile conflict with the use of
	sys.modules[__name__]
In-Reply-To: <1285093065.41.0.819526070425.issue9914@psf.upfronthosting.co.za>
Message-ID: <1342324439.54.0.907165346963.issue9914@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/issue9914>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:54:18 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:54:18 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1342324458.63.0.673897197447.issue10342@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/issue10342>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:55:15 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:55:15 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
	as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1342324515.22.0.0381746905713.issue9325@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/issue9325>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:56:05 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:56:05 +0000
Subject: [issue14332] Better explain "junk" concept in difflib doc
In-Reply-To: <1331877125.66.0.103153393744.issue14332@psf.upfronthosting.co.za>
Message-ID: <1342324565.22.0.672693876009.issue14332@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

ping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14332>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:56:18 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:56:18 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1342324578.83.0.834674352776.issue13386@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/issue13386>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:56:24 2012
From: report at bugs.python.org (Eric Snow)
Date: Sun, 15 Jul 2012 03:56:24 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
In-Reply-To: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za>
Message-ID: <1342324584.62.0.90663253369.issue15352@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

What I mean is, shouldn't changes to marshal have an accompanying bump to the pyc magic number?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:56:38 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:56:38 +0000
Subject: [issue10685] trace does not ignore --ignore-module
In-Reply-To: <1292157270.73.0.200325030661.issue10685@psf.upfronthosting.co.za>
Message-ID: <1342324598.63.0.337948881457.issue10685@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/issue10685>
_______________________________________

From report at bugs.python.org  Sun Jul 15 05:58:19 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:58:19 +0000
Subject: [issue13997] Clearly explain the bare minimum Python 3 users should
	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1342324699.44.0.624709458678.issue13997@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/issue13997>
_______________________________________

From report at bugs.python.org  Sun Jul 15 06:03:03 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 04:03:03 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <1342324983.22.0.0352403047176.issue15314@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, the way I plan to tackle this is to actually redirect the pkgutil APIs to importlib (rather than using the private import emulation).

The reason I'm going to tackle it like this is that there are some assumptions pkgutil deals with that importlib doesn't. Specifically, runpy expects find_loader() to take care of importing the parent package. In addition, importlib is prone to throwing AttributeError or TypeError for problems where pkgutil consistently throws ImportError. By using pkgutil as a compatibility shim, most code (including runpy itself) will be able to transition to importlib without actually needing any changes.

This approach also brings test_runpy and test_cmd_line_script more fully to bear on the importlib implementation, which is a nice bonus :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15314>
_______________________________________

From report at bugs.python.org  Sun Jul 15 06:17:33 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 04:17:33 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <1342325853.67.0.610987698538.issue15314@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oh, special - importlib.find_loader() currently expects every module to have a __loader__ attribute, but there's at least one that doesn't: __main__.

Guess I'll be tweaking it to handle that case more gracefully after all :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15314>
_______________________________________

From report at bugs.python.org  Sun Jul 15 07:21:23 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Jul 2012 05:21:23 +0000
Subject: [issue14332] Better explain "junk" concept in difflib doc
In-Reply-To: <1331877125.66.0.103153393744.issue14332@psf.upfronthosting.co.za>
Message-ID: <1342329683.64.0.0242776304007.issue14332@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I guess I should try to come up with something that is an improvement, even if not perfect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14332>
_______________________________________

From report at bugs.python.org  Sun Jul 15 07:41:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 05:41:25 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <1342330885.13.0.047091028897.issue15314@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, __main__, thou art such a special beast.

Here's my current plan:

1. __main__ will be initialised with __loader__ set to BuiltinImporter. This covers cases like the interactive prompt or execution of stdin where there is no source code available for __main__

2. When executing a script (either directly or via runpy), __main__.__loader__ will be *changed* at a later point to refer to the appropriate kind of loader object.

----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15314>
_______________________________________

From report at bugs.python.org  Sun Jul 15 09:02:39 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Jul 2012 07:02:39 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1342335759.61.0.225517200005.issue1767933@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Thank you, Eli.

However changes to tostring() and tostringlist() break the invariant b"".join(tostringlist(element, 'utf-16')) == tostring(element, 'utf-16'). You should add followed methods to DataStream:

        def seekable(self):
            return True

        def tell(self):
            return len(data)

Note, that monkey-patched version is faster.

    stream = io.BufferedIOBase()
    stream.writable = lambda: True
    stream.write = data.append
    stream.seekable = lambda: True
    stream.tell = data.__len__

Benchmark results:

tostring() with BytesIO:
$ ./python -m timeit -s "import xml.etree.ElementTree as ET; e=ET.XML('<root/>')"  "ET.tostring(e, 'utf-16')"
1000 loops, best of 3: 268 usec per loop
$ ./python -m timeit -s "import xml.etree.ElementTree as ET; e=ET.XML('<root>'+'<child/>'*100+'</root>' )"  "ET.tostring(e, 'utf-16')"
100 loops, best of 3: 4.63 msec per loop

tostring() with monkey-patching:
$ ./python -m timeit -s "import xml.etree.ElementTree as ET; e=ET.XML('<root/>')"  "ET.tostring(e, 'utf-16')"
1000 loops, best of 3: 263 usec per loop
$ ./python -m timeit -s "import xml.etree.ElementTree as ET; e=ET.XML('<root>'+'<child/>'*100+'</root>' )"  "ET.tostring(e, 'utf-16')"
100 loops, best of 3: 3.84 msec per loop

tostringlist() with DataStream class:
$ ./python -m timeit -s "import xml.etree.ElementTree as ET; e=ET.XML('<root/>')"  "ET.tostringlist(e, 'utf-16')"
1000 loops, best of 3: 624 usec per loop
$ ./python -m timeit -s "import xml.etree.ElementTree as ET; e=ET.XML('<root>'+'<child/>'*100+'</root>' )"  "ET.tostringlist(e, 'utf-16')"
100 loops, best of 3: 4.09 msec per loop

tostringlist() with monkey-patching:
$ ./python -m timeit -s "import xml.etree.ElementTree as ET; e=ET.XML('<root/>')"  "ET.tostringlist(e, 'utf-16')"1000 loops, best of 3: 259 usec per loop
$ ./python -m timeit -s "import xml.etree.ElementTree as ET; e=ET.XML('<root>'+'<child/>'*100+'</root>' )"  "ET.tostringlist(e, 'utf-16')"
100 loops, best of 3: 3.81 msec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Sun Jul 15 09:08:12 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Jul 2012 07:08:12 +0000
Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Message-ID: <1342336092.73.0.788522290037.issue1470548@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Here is updated patch with more careful handling of closing (as for issue1767933) and added comments.

----------
nosy: +eli.bendersky
Added file: http://bugs.python.org/file26385/XMLGenerator-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1470548>
_______________________________________

From report at bugs.python.org  Sun Jul 15 09:38:28 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Jul 2012 07:38:28 +0000
Subject: [issue4997] xml.sax.saxutils.XMLGenerator should write to
	io.RawIOBase.
In-Reply-To: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>
Message-ID: <1342337908.81.0.308511797849.issue4997@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

This issue will be fixed by patch for issue1470548.

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4997>
_______________________________________

From report at bugs.python.org  Sun Jul 15 10:10:05 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 08:10:05 +0000
Subject: [issue15357] Deprecate redundant pieces of pkgutil
In-Reply-To: <1342319236.08.0.487526794106.issue15357@psf.upfronthosting.co.za>
Message-ID: <3WZgQz5BxvzPCQ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3987667bf98f by Nick Coghlan in branch 'default':
Take the first step in resolving the messy pkgutil vs importlib edge cases by basing pkgutil explicitly on importlib, deprecating its internal import emulation and setting __main__.__loader__ correctly so that runpy still works (Affects #15343, #15314, #15357)
http://hg.python.org/cpython/rev/3987667bf98f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15357>
_______________________________________

From report at bugs.python.org  Sun Jul 15 10:10:05 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 08:10:05 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <3WZgR03fxhzPCQ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3987667bf98f by Nick Coghlan in branch 'default':
Take the first step in resolving the messy pkgutil vs importlib edge cases by basing pkgutil explicitly on importlib, deprecating its internal import emulation and setting __main__.__loader__ correctly so that runpy still works (Affects #15343, #15314, #15357)
http://hg.python.org/cpython/rev/3987667bf98f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sun Jul 15 10:10:06 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 08:10:06 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <3WZgR124YRzPCQ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3987667bf98f by Nick Coghlan in branch 'default':
Take the first step in resolving the messy pkgutil vs importlib edge cases by basing pkgutil explicitly on importlib, deprecating its internal import emulation and setting __main__.__loader__ correctly so that runpy still works (Affects #15343, #15314, #15357)
http://hg.python.org/cpython/rev/3987667bf98f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15314>
_______________________________________

From report at bugs.python.org  Sun Jul 15 10:48:14 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 08:48:14 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <1342342094.23.0.874674048156.issue15314@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, I think runpy and __main__.__loader__ are all sorted now. The relevant runpy and command line script tests all check for the expected values, and I added a couple of new tests to cover the "-c" and "reading from stdin" cases.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15314>
_______________________________________

From report at bugs.python.org  Sun Jul 15 11:33:54 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 09:33:54 +0000
Subject: [issue15272] pkgutil.find_loader accepts invalid module names
In-Reply-To: <1341656387.47.0.245292094882.issue15272@psf.upfronthosting.co.za>
Message-ID: <1342344834.64.0.404641987867.issue15272@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15272>
_______________________________________

From report at bugs.python.org  Sun Jul 15 11:43:52 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 09:43:52 +0000
Subject: [issue15272] pkgutil.find_loader accepts invalid module names
In-Reply-To: <1341656387.47.0.245292094882.issue15272@psf.upfronthosting.co.za>
Message-ID: <1342345432.19.0.476346175747.issue15272@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, this one is trickier than I thought - the exact behaviour depends on how you traverse the code, and I believe a PEP 302 importer is technically allowed to accept "/" in module names. (Unless there's a module names "must be valid identifiers" in there somewhere that I have forgotten about)

Punting on it for the moment.

----------
assignee: ncoghlan -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15272>
_______________________________________

From report at bugs.python.org  Sun Jul 15 11:54:31 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 09:54:31 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
Message-ID: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Created to record the egregious hack of relying on the test_runpy infrastructure in order to test pkgutil.walk_packages.

It gets the job done, but is a really messy way of going about it. Worth cleaning up by factoring the support code out to a helper module when there isn't a release deadline looming.

----------
components: Tests
messages: 165516
nosy: ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Test pkgutil.walk_packages in test_pkgutil instead of test_runpy
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Sun Jul 15 12:12:10 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 10:12:10 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>
Message-ID: <1342347130.04.0.998673194869.issue15358@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
dependencies: +"pydoc -w <package>" writes out page with empty "Package Contents" section

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Sun Jul 15 13:16:20 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Jul 2012 11:16:20 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is
	too	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1342350980.84.0.790128667272.issue11322@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> I don't know who changed the encoding's package normalize_encoding() function (wasn't me), but it's a really slow implementation.

See changeset 54ef645d08e4.

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Sun Jul 15 13:19:29 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 11:19:29 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <3WZldX1T80zPH1@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9101eab6178c by Nick Coghlan in branch 'default':
Issue #15343: Handle importlib.machinery.FileFinder instances in pkgutil.walk_packages (et al)
http://hg.python.org/cpython/rev/9101eab6178c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sun Jul 15 13:25:43 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 11:25:43 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>
Message-ID: <1342351543.37.0.910955312989.issue15358@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Also, a second test case should be added to cover the zipimporter.zipimporter component.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Sun Jul 15 13:25:50 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 11:25:50 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>
Message-ID: <1342351550.45.0.339491923567.issue15358@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Sun Jul 15 13:53:50 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 11:53:50 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342353230.14.0.266892291536.issue15343@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fixing this has uncovered another issue: the old import emulation in PEP 302 ignored encoding cookies, thus merrily decoding everything as utf-8 in "get_source()". importlib is smarter about this, which means the pydoc tests started failing as they tried to load the files with invalid encoding cookies.

I plan to tackle this in two parts:

- move get_source() and get_code() in importlib towards consistently raising ImportError, regardless of the reason the result couldn't be provided (chaining the exceptions to ensure details aren't lost)

- update pydoc to tolerate ImportError from get_source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sun Jul 15 14:12:28 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 12:12:28 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <3WZmpg3zDXzPJQ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7d202353a728 by Nick Coghlan in branch 'default':
Issue #15343: A lot more than just unicode decoding can go wrong when retrieving a source file
http://hg.python.org/cpython/rev/7d202353a728

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sun Jul 15 14:17:18 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 12:17:18 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <3WZmwF0dxVzPJQ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ce0687a8383b by Nick Coghlan in branch 'default':
Issue #9319: Remove the workaround for this since fixed problem from pydoc
http://hg.python.org/cpython/rev/ce0687a8383b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Sun Jul 15 14:19:17 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 12:19:17 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342354757.5.0.675595730854.issue15343@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Main change in that last commit is really the one to make pydoc ignore just about *any* exception from get_source(). This should make it more robust against buggy loaders, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sun Jul 15 14:24:53 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 12:24:53 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342355093.24.0.57017070775.issue15343@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

And a manual check confirms the higher level issue is also fixed. (I believe there's already a meta issue somewhere about the lack of automated tests for pydoc's emitted HTML)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Sun Jul 15 14:45:43 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 12:45:43 +0000
Subject: [issue15357] Deprecate redundant pieces of pkgutil
In-Reply-To: <1342319236.08.0.487526794106.issue15357@psf.upfronthosting.co.za>
Message-ID: <1342356343.91.0.561833526579.issue15357@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm pretty sure I got them all while fixing #15343

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15357>
_______________________________________

From report at bugs.python.org  Sun Jul 15 14:59:44 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Jul 2012 12:59:44 +0000
Subject: [issue15356] '\xa0' isspace returns true while compiling python on
	solaris 10 by users using gcc 3.4.6
In-Reply-To: <1342317027.18.0.929395647565.issue15356@psf.upfronthosting.co.za>
Message-ID: <1342357184.71.0.763739093458.issue15356@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm sorry, It looks like you said it was working as you expected in 2.7, and you marked it for version 2.6.  So what is the bug that you see in 2.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15356>
_______________________________________

From report at bugs.python.org  Sun Jul 15 15:10:56 2012
From: report at bugs.python.org (Brian Thorne)
Date: Sun, 15 Jul 2012 13:10:56 +0000
Subject: [issue15359] Sockets support for CAN_BCM
Message-ID: <1342357855.99.0.608670333225.issue15359@psf.upfronthosting.co.za>


New submission from Brian Thorne <hardbyte at gmail.com>:

In addition to CAN_RAW introduced in Python 3.3, it would be really useful to expose the CAN_BCM protocol. Effectively it hands off as much  to the kernel as possible which gives Python programs the ability to send and receive many periodic messages with little additional jitter or overhead.

I've attached an early stab at a patch to see if there is interest.

I'll be putting more examples of using BCM sockets at https://bitbucket.org/hardbyte/python-socket-examples

----------
components: Library (Lib)
files: python_bcm.patch
keywords: patch
messages: 165527
nosy: Thorney, pitrou
priority: normal
severity: normal
status: open
title: Sockets support for CAN_BCM
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26386/python_bcm.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15359>
_______________________________________

From report at bugs.python.org  Sun Jul 15 15:18:03 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Jul 2012 13:18:03 +0000
Subject: [issue15359] Sockets support for CAN_BCM
In-Reply-To: <1342357855.99.0.608670333225.issue15359@psf.upfronthosting.co.za>
Message-ID: <1342358283.43.0.453584407808.issue15359@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15359>
_______________________________________

From report at bugs.python.org  Sun Jul 15 15:18:19 2012
From: report at bugs.python.org (zoupl)
Date: Sun, 15 Jul 2012 13:18:19 +0000
Subject: [issue15356] '\xa0' isspace returns true while compiling python on
	solaris 10 by users using gcc 3.4.6
In-Reply-To: <1342317027.18.0.929395647565.issue15356@psf.upfronthosting.co.za>
Message-ID: <1342358299.03.0.847773614121.issue15356@psf.upfronthosting.co.za>


zoupl <zoupengli at gmail.com> added the comment:

No, i mean it works ok on version 2.7. However, what I want to know is the way that works in version2.7, because I want to try to fix it in version 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15356>
_______________________________________

From report at bugs.python.org  Sun Jul 15 16:47:57 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 14:47:57 +0000
Subject: [issue15180] Cryptic traceback from os.path.join when mixing str &
	bytes
In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za>
Message-ID: <3WZrG40Z2DzPF2@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cf1ac0c9e753 by Hynek Schlawack in branch '3.2':
#15180: Clarify posixpath.join() error message when mixing str & bytes
http://hg.python.org/cpython/rev/cf1ac0c9e753

New changeset 1462b963e5ce by Hynek Schlawack in branch 'default':
#15180: Clarify posixpath.join() error message when mixing str & bytes
http://hg.python.org/cpython/rev/1462b963e5ce

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15180>
_______________________________________

From report at bugs.python.org  Sun Jul 15 17:04:25 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 15 Jul 2012 15:04:25 +0000
Subject: [issue15180] Cryptic traceback from os.path.join when mixing str &
	bytes
In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za>
Message-ID: <1342364665.25.0.881816118915.issue15180@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Fixed for 3.2 & default.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15180>
_______________________________________

From report at bugs.python.org  Sun Jul 15 17:13:07 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 15:13:07 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <3WZrq46CqbzN5m@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f954ee489896 by Vinay Sajip in branch 'default':
Issue #15307: Skipped test_venv:test_prefixes when run from a venv.
http://hg.python.org/cpython/rev/f954ee489896

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Sun Jul 15 17:18:50 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Jul 2012 15:18:50 +0000
Subject: [issue15356] '\xa0' isspace returns true while compiling python on
	solaris 10 by users using gcc 3.4.6
In-Reply-To: <1342317027.18.0.929395647565.issue15356@psf.upfronthosting.co.za>
Message-ID: <1342365530.9.0.327579735237.issue15356@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah.  I have no idea.  I did a search and could not find an issue about it being fixed...that doesn't mean there wasn't one, though.

Does the problem occur *only* solaris?  Because if it isn't solaris specific it might be this one: issue 1571184.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15356>
_______________________________________

From report at bugs.python.org  Sun Jul 15 17:34:40 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 15 Jul 2012 15:34:40 +0000
Subject: [issue15349] SyntaxError b0rked grammar
In-Reply-To: <1342258864.48.0.924428948709.issue15349@psf.upfronthosting.co.za>
Message-ID: <1342366480.65.0.907665313919.issue15349@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Thank you for the bug report, Ztatik.

Since 2.6 is now in security-fix-only mode, this issue will not be fixed. See http://www.python.org/getit/releases/2.6.8/

This grammar issue was fixed in 2.7 with revision 386922b629c3, but was not applied to the 2.6 series at the time.

If you find any more errors, please report them.

----------
nosy: +serwy
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15349>
_______________________________________

From report at bugs.python.org  Sun Jul 15 18:12:08 2012
From: report at bugs.python.org (Michael Foord)
Date: Sun, 15 Jul 2012 16:12:08 +0000
Subject: [issue15351] Add to unittest.TestCase support for using context
	managers
In-Reply-To: <1342280032.27.0.345733068822.issue15351@psf.upfronthosting.co.za>
Message-ID: <1342368728.72.0.862793429343.issue15351@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

A method on TestCase that *just* executes the test method - allowing for overriding in subclasses - is an interesting idea. Including setUp and tearDown would be harder because TestCase necessarily does a bunch of bookkeeping between each of these steps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15351>
_______________________________________

From report at bugs.python.org  Sun Jul 15 18:55:58 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Jul 2012 16:55:58 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1342371358.56.0.748827955732.issue15233@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Shall I also backport to 2.7 and 3.2 as the issue suggests?

If the tests are there, yes!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15233>
_______________________________________

From report at bugs.python.org  Sun Jul 15 18:58:39 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Jul 2012 16:58:39 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1342371519.45.0.964122477248.issue15202@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The .4 patches both LGTM, please commit!

You're the one with commit rights here ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15202>
_______________________________________

From report at bugs.python.org  Sun Jul 15 19:20:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 15 Jul 2012 17:20:26 +0000
Subject: [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1342372826.76.0.318396420765.issue14787@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

For the record, this issue is still present after Nick's pkgutil changes documented in issue 15343 (not that I expected it to be resolved since this issue is a bit different).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14787>
_______________________________________

From report at bugs.python.org  Sun Jul 15 19:21:10 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 15 Jul 2012 17:21:10 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>
Message-ID: <1342372870.78.0.107372906461.issue15358@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Sun Jul 15 19:25:06 2012
From: report at bugs.python.org (Davide Rizzo)
Date: Sun, 15 Jul 2012 17:25:06 +0000
Subject: [issue15360] Behavior of assigning to __dict__ is not documented
Message-ID: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>


New submission from Davide Rizzo <sorcio at gmail.com>:

The documentation (at least the obvious places, see Doc/reference/datamodel.rst) says classes and class instances have the '__dict__' attribute, but nothing is said about what happens when assigning to it (like obj.__dict__ = something).

As far as I understand that's undefined behavior and other implementations may not work the same as CPython (and CPython itself behaves differently between versions).

I'd submit a documentation patch if I knew how to specify this matter. Maybe just say the behavior is not defined?

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 165538
nosy: davide.rizzo, docs at python
priority: normal
severity: normal
status: open
title: Behavior of assigning to __dict__ is not documented
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15360>
_______________________________________

From report at bugs.python.org  Sun Jul 15 19:25:17 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 15 Jul 2012 17:25:17 +0000
Subject: [issue15297] pkgutil.iter_importers() includes an ImpImporter
In-Reply-To: <1341781980.93.0.099189257301.issue15297@psf.upfronthosting.co.za>
Message-ID: <1342373117.33.0.262559679512.issue15297@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Closing as this is no longer an issue after Nick's pkgutil changes documented in issue 15343.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15297>
_______________________________________

From report at bugs.python.org  Sun Jul 15 19:33:59 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 15 Jul 2012 17:33:59 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>
Message-ID: <1342373639.73.0.41133645421.issue15358@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Such helper functionality could also be used in the tests of unittest.TestLoader.loadTestsFromName().  See, for example, the tests proposed for issue 7559.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Sun Jul 15 19:39:29 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 15 Jul 2012 17:39:29 +0000
Subject: [issue8229] Interpreter crash on application shutdown
In-Reply-To: <1269507058.23.0.138728346212.issue8229@psf.upfronthosting.co.za>
Message-ID: <1342373969.58.0.486590507403.issue8229@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

tb220, is this still a bug? Python 2.6 is now in security-fix-only mode.

----------
nosy: +serwy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8229>
_______________________________________

From report at bugs.python.org  Sun Jul 15 19:58:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 17:58:09 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <3WZwTV5kmSzPH1@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 758a9023d836 by Larry Hastings in branch 'default':
Issue #15202: Consistently use the name "follow_symlinks" for
http://hg.python.org/cpython/rev/758a9023d836

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15202>
_______________________________________

From report at bugs.python.org  Sun Jul 15 20:34:15 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Jul 2012 18:34:15 +0000
Subject: [issue14988] _elementtree: Raise ImportError when importing of
	pyexpat fails
In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za>
Message-ID: <1342377255.66.0.267147322737.issue14988@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

IMHO wrong exception could be treated as a bug, which could be fixed in 3.2 and 3.3.
Benjamin Peterson and Georg Brandl: What do you think?

> P.S. is there any way to create a test for it?

You can set sys.modules["pyexpat"]=None and test exception type when trying to import _elementtree.

----------
nosy: +benjamin.peterson, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14988>
_______________________________________

From report at bugs.python.org  Sun Jul 15 20:55:43 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 15 Jul 2012 18:55:43 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
In-Reply-To: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za>
Message-ID: <1342378543.69.0.238492849946.issue15352@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Eric, that is a good point, but if someone forgets (like I did) or just hasn't gotten around to bumping the number yet, then the build breaks because the interpreter crashes.  I think we should always try to avoid building an interpreter that is in an inconsistent state.

Anyway, I am hitting another problem now -- _freeze_importlib is *not* idempotent.  Thus adding this rule might cause some noise in the builds because importlib.h is different when nothing has actually changed.  I am still investigating that problem.

Assuming I can fix the idempotency problem, then maybe _freeze_importlib should just be always run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Sun Jul 15 21:02:40 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 15 Jul 2012 19:02:40 +0000
Subject: [issue15361] venv's Activate.ps1 causes broken prompt with powershell
Message-ID: <1342378960.04.0.994385989883.issue15361@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

If I create a venv on Windows called "py3" then py3/Scripts/Activate.ps1 defines the prompt to be

    function prompt {
        Write-Host -NoNewline -ForegroundColor Green [(py3) ]
        _OLD_VIRTUAL_PROMPT
    }

However this prompt function does not work properly, and running

    Write-Host -NoNewline -ForegroundColor Green [(py3) ]

on its own produces an error because of the lack of quotes around (py3).  Adding quotes as shown in the patch seems to fix the problem.

----------
components: Library (Lib)
files: prompt.patch
keywords: patch
messages: 165545
nosy: sbt, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: venv's Activate.ps1 causes broken prompt with powershell
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26387/prompt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15361>
_______________________________________

From report at bugs.python.org  Sun Jul 15 22:06:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 15 Jul 2012 20:06:39 +0000
Subject: [issue9374] urlparse should parse query and fragment for arbitrary
	schemes
In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za>
Message-ID: <1342382799.91.0.477596568926.issue9374@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Removing the module attributes causes third-party code to break.  See one example here: http://lists.idyll.org/pipermail/testing-in-python/2012-July/005082.html

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9374>
_______________________________________

From report at bugs.python.org  Sun Jul 15 22:07:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 15 Jul 2012 20:07:21 +0000
Subject: [issue9374] urlparse should parse query and fragment for arbitrary
	schemes
In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za>
Message-ID: <1342382841.85.0.491943401308.issue9374@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Better link: https://github.com/pypa/pip/issues/552

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9374>
_______________________________________

From report at bugs.python.org  Sun Jul 15 22:29:41 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 15 Jul 2012 20:29:41 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1342384181.67.0.757433296885.issue15202@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There are versionadded notes in the doc that still use the old names (e.g. symlinks for shutil.copyfile).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15202>
_______________________________________

From report at bugs.python.org  Sun Jul 15 22:58:24 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 20:58:24 +0000
Subject: [issue15361] venv's Activate.ps1 causes broken prompt with powershell
In-Reply-To: <1342378960.04.0.994385989883.issue15361@psf.upfronthosting.co.za>
Message-ID: <3Wb0TW0HFLzP8g@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0b4d0c2173ad by Vinay Sajip in branch 'default':
Closes #15361: Corrected venv prompt in PowerShell activation script.
http://hg.python.org/cpython/rev/0b4d0c2173ad

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15361>
_______________________________________

From report at bugs.python.org  Sun Jul 15 23:19:22 2012
From: report at bugs.python.org (John Schneider)
Date: Sun, 15 Jul 2012 21:19:22 +0000
Subject: [issue15362] pyport.h includes antiquated UTF handling for FreeBSD
Message-ID: <1342387162.35.0.975176855172.issue15362@psf.upfronthosting.co.za>


New submission from John Schneider <js at jschneider.com>:

Revision 36793 introduced a libc wrapper for FreeBSD 5.x which addressed some UTF issues. Unfortunately, this causes C compilation errors for certain ports.

Also reference issues 10910, 1455641

This change is no longer applicable for FreeBSD 9.  I'm not sure what version of FreeBSD made it not longer applicable, but there were reports of it still being necessary for FreebSD 7. FreeBSD 6 - 8 should be tested with this test script:
------------------------
#!/usr/bin/env python

from ctypes import *

cdll.LoadLibrary("libc.so.7")
libc = CDLL("libc.so.7")

assert libc.isspace(0xa0) == 0
------------------------

I've also attached a patch for python 2.7.3.

----------
components: Unicode, ctypes
files: patch-pyport.h
messages: 165550
nosy: JohnSchneider, ezio.melotti
priority: normal
severity: normal
status: open
title: pyport.h includes antiquated UTF handling for FreeBSD
versions: Python 2.7
Added file: http://bugs.python.org/file26388/patch-pyport.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15362>
_______________________________________

From report at bugs.python.org  Sun Jul 15 23:46:27 2012
From: report at bugs.python.org (koobs)
Date: Sun, 15 Jul 2012 21:46:27 +0000
Subject: [issue12978] Figure out extended attributes on BSDs
In-Reply-To: <1316014526.21.0.982877507813.issue12978@psf.upfronthosting.co.za>
Message-ID: <1342388787.12.0.572860183353.issue12978@psf.upfronthosting.co.za>


koobs <koobs.freebsd at gmail.com> added the comment:

FreeBSD (at least on 7.x, 8.x and 9.x) has the following syscalls available in its API:

extattr_{get,set,list,delete}_{fd,file,link}

And also has: EXTATTR_MAXNAMELEN

http://www.freebsd.org/cgi/man.cgi?query=extattr&sektion=2&manpath=FreeBSD+9.0-RELEASE

----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12978>
_______________________________________

From report at bugs.python.org  Mon Jul 16 01:02:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 15 Jul 2012 23:02:28 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1342393348.96.0.326392259048.issue15320@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks a lot for the feedback.  The thinking was to use a stand-alone (even testable) construct with dependencies made explicit.  For example, it wasn't obvious that the current iterator depended on forever, or whether the args_tuple parameter was a necessary part of it.  But I agree it should be simplified.

Here is a simpler patch, keeping iterator semantics.  My preference is to avoid adding lock semantics and additional complexity directly to main(), even though doing so would permit a smaller patch.

----------
Added file: http://bugs.python.org/file26389/issue-15320-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Mon Jul 16 01:17:23 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Jul 2012 23:17:23 +0000
Subject: [issue15363] Idle/tkinter ~x.py 'save as' fails. closes idle
Message-ID: <1342394243.7.0.336788716257.issue15363@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

I have (had ;-) a project file ~template.py with common boilerplate.
To start a new project file, I want to open the above and save as xyz.py. I can edit and 'save' the template to update it just fine. But trying to do a 'save as' to a new name, in Idle editor, on all three current versions, I get (when starting Idle from command window)

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Programs\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "C:\Programs\Python33\lib\idlelib\IOBinding.py", line 347, in save_as
    filename = self.asksavefile()
  File "C:\Programs\Python33\lib\idlelib\IOBinding.py", line 514, in asksavefile

    filename = self.savedialog.show(initialdir=dir, initialfile=base)
  File "C:\Programs\Python33\lib\tkinter\commondialog.py", line 48, in show
    s = w.tk.call(self.command, *w._options(self.options))
_tkinter.TclError: user "template.py" doesn't exist

When starting Idle normally, this causes it to silently close. When run from the cp interpreter, the edit window blinks but continues while the trackback is printed in the cp window.

Just saving does not bring up a dialog; hence no problem. And I understand that '~' has special meaning on *nix, but I am running on Windows.

I changed '~' to '@' and the file still sorts at the top (though above __init__.py rather than below) and save as now works as it should. I know that save as worked for this file last October, but while I think it had the same ~name then, I cannot be sure. Maybe I added '~' after the last time I successfully used the file.

As near as I can tell, asksavefile() passes initialfile = base = '~template.py' to savedialog.show which passes it unchanged and unexamined to tk.call. So the special casing of ~ seems to happen in tcl/tk out of our control. I am not sure if doing this on Windows is a tcl/tk bug or not.

For Windows, just removing '~' or even blanking the name before the .show() might be sensible, but maybe not for *nix.

Instead, we could catch the error instead of letting it crash Idle and put up a message box to the effect that one cannot 'save as' when editing a file named '~xxxx'. More specifically, in IOBinding.py, line 514 or so, replace

filename = self.savedialog.show(initialdir=dir, initialfile=base)

with

try:
    filename = self.savedialog.show(initialdir=dir, initialfile=base)
except TclError as e:
    if e.args[0].startswith('user'):
        xxx display message, click ok
    filename = None

I am assuming the None is the return from canceled dialogs. Certainly, None caused the file save code back up in saveas() (346) to skip the save.

The message could be something like "tcl/tk gives special treatment to file names starting with '~' and returned this error message {}".format(e.args[0])

We could also add "else: message('unanticipated tclerror prevented save as dialog <message>)"

----------
components: IDLE
messages: 165553
nosy: serwy, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle/tkinter ~x.py 'save as' fails. closes idle
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15363>
_______________________________________

From report at bugs.python.org  Mon Jul 16 01:24:21 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Jul 2012 23:24:21 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <1342394661.67.0.31009149529.issue15202@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Sorry; the patch didn't apply cleanly, and it looks like I bungled doing it manually.  Fixing now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15202>
_______________________________________

From report at bugs.python.org  Mon Jul 16 01:59:10 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 23:59:10 +0000
Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification
In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>
Message-ID: <3Wb4V46b2TzP52@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e26113f17309 by Larry Hastings in branch 'default':
Issue #15202: Additional documentation fixes inadvertently omitted
http://hg.python.org/cpython/rev/e26113f17309

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15202>
_______________________________________

From report at bugs.python.org  Mon Jul 16 02:07:48 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 16 Jul 2012 00:07:48 +0000
Subject: [issue15363] Idle/tkinter ~x.py 'save as' fails. closes idle
In-Reply-To: <1342394243.7.0.336788716257.issue15363@psf.upfronthosting.co.za>
Message-ID: <1342397268.01.0.106367831602.issue15363@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

IDLE silently closing is due to issue13582.

On Linux (Ubuntu 11.04, Tk8.5) I can not specify "~template.py" for a filename for opening or saving a file. Clicking on either open or save produces no action. However, I can specify "~/template.py".

On Win7 I see there error Terry describes. This is due to "Tilde Substitution" described here: http://www.tcl.tk/man/tcl/TclCmd/filename.htm#M20

Attached is a patch against 3.3 that escapes the initial tilde on Windows. The patch should be identical against 3.2 and 2.7.

----------
keywords: +patch
Added file: http://bugs.python.org/file26390/tilde_escape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15363>
_______________________________________

From report at bugs.python.org  Mon Jul 16 02:12:54 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jul 2012 00:12:54 +0000
Subject: =?utf-8?q?=5Bissue4640=5D_optparse_doesn=E2=80=99t_disallow_adding_one-da?=
	=?utf-8?b?c2ggbG9uZyBvcHRpb25zICjigJwtb3B0aW9u4oCdKQ==?=
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <3Wb4nv1F1bzP9n@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 844bb753570f by R David Murray in branch 'default':
#4640: Add optparse tests for '-xxx' invalid when defining options.
http://hg.python.org/cpython/rev/844bb753570f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4640>
_______________________________________

From report at bugs.python.org  Mon Jul 16 02:15:42 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Jul 2012 00:15:42 +0000
Subject: =?utf-8?q?=5Bissue4640=5D_optparse_doesn=E2=80=99t_disallow_adding_one-da?=
	=?utf-8?b?c2ggbG9uZyBvcHRpb25zICjigJwtb3B0aW9u4oCdKQ==?=
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <1342397742.52.0.411551967909.issue4640@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Re-reading the issue I think the OP was not trying to define '-debug', but was indeed reporting the behavior when -debug was passed to the parser.  I've committed your tests (thanks).  

So we now have tests for both cases, and this issue can be closed as invalid.

----------
resolution: accepted -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4640>
_______________________________________

From report at bugs.python.org  Mon Jul 16 02:34:33 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 16 Jul 2012 00:34:33 +0000
Subject: [issue7957] Tutorial issue regarding the sys module
In-Reply-To: <1266505107.41.0.314960086696.issue7957@psf.upfronthosting.co.za>
Message-ID: <1342398873.07.0.882403485242.issue7957@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

IDLE supporting sys.ps1 and sys.ps2 is discussed in issue13657. I am closing this issue in favor of that one.

----------
nosy: +serwy
resolution:  -> duplicate
status: open -> closed
superseder:  -> IDLE doesn't support sys.ps1 and sys.ps2.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7957>
_______________________________________

From report at bugs.python.org  Mon Jul 16 02:37:02 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 16 Jul 2012 00:37:02 +0000
Subject: [issue6171] IDLE - Class Browser selection in Ubuntu
In-Reply-To: <1243903612.81.0.195499978214.issue6171@psf.upfronthosting.co.za>
Message-ID: <1342399022.73.0.941809875735.issue6171@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
nosy: +serwy
title: Class Browser selection in Ubuntu -> IDLE - Class Browser selection in Ubuntu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6171>
_______________________________________

From report at bugs.python.org  Mon Jul 16 02:39:39 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 16 Jul 2012 00:39:39 +0000
Subject: [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342399179.8.0.483854185627.issue15151@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Is anyone working on this?  I could possibly take a stab at it tonight, if I get the evening to myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15151>
_______________________________________

From report at bugs.python.org  Mon Jul 16 02:49:15 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 16 Jul 2012 00:49:15 +0000
Subject: [issue6804] IDLE: Detect Python files even if name doesn't end in .py
In-Reply-To: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>
Message-ID: <1342399755.62.0.782722922347.issue6804@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This is related to issue6858. I assume that the point of this issue is to enable syntax highlighting by relying on the Windows registry?

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6804>
_______________________________________

From report at bugs.python.org  Mon Jul 16 03:02:02 2012
From: report at bugs.python.org (zoupl)
Date: Mon, 16 Jul 2012 01:02:02 +0000
Subject: [issue15356] '\xa0' isspace returns true while compiling python on
	solaris 10 by users using gcc 3.4.6
In-Reply-To: <1342317027.18.0.929395647565.issue15356@psf.upfronthosting.co.za>
Message-ID: <1342400522.1.0.989250679397.issue15356@psf.upfronthosting.co.za>


zoupl <zoupengli at gmail.com> added the comment:

I have just tried on solaris. I will try the solution of issue 1571184, thanks a lot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15356>
_______________________________________

From report at bugs.python.org  Mon Jul 16 03:26:44 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 16 Jul 2012 01:26:44 +0000
Subject: [issue14988] _elementtree: Raise ImportError when importing of
	pyexpat fails
In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za>
Message-ID: <1342402004.57.0.625507306105.issue14988@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

IMHO, it can be fixed as people were relying on the old behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14988>
_______________________________________

From report at bugs.python.org  Mon Jul 16 04:25:36 2012
From: report at bugs.python.org (Brian Thorne)
Date: Mon, 16 Jul 2012 02:25:36 +0000
Subject: [issue15359] Sockets support for CAN_BCM
In-Reply-To: <1342357855.99.0.608670333225.issue15359@psf.upfronthosting.co.za>
Message-ID: <1342405536.3.0.616423511029.issue15359@psf.upfronthosting.co.za>


Brian Thorne <hardbyte at gmail.com> added the comment:

Once I've got more complete examples, I can update the patch to include a testcase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15359>
_______________________________________

From report at bugs.python.org  Mon Jul 16 06:29:29 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Mon, 16 Jul 2012 04:29:29 +0000
Subject: [issue15342] os.path.join behavior
In-Reply-To: <1342143930.94.0.174584687761.issue15342@psf.upfronthosting.co.za>
Message-ID: <1342412969.0.0.823048433274.issue15342@psf.upfronthosting.co.za>


Yongzhi Pan <fossilet at users.sourceforge.net> added the comment:

I suggest append "An empty last part will result in a path that ends with a separator" or something similar to the docstring, though it is already in the HTML documentation. 

Suppose someone does this like me:

In [10]: join('a', sep)
Out[10]: '/'

He must be surprised. He has to guess how to append a separator if he does not look at the code, or fiddle around until he finds the soultion. 

Given it explained in the docstring, after he sees:

In [10]: join('a', sep)
Out[10]: '/'

He will probably look at the docstring:

In [16]: join?
Type:       function
Base Class: <type 'function'>
String Form:<function join at 0x7f053fc93ed8>
Namespace:  Interactive
File:       /usr/lib/python2.7/posixpath.py
Definition: join(a, *p)
Docstring:
Join two or more pathname components, inserting '/' as needed.
If any component is an absolute path, all previous path components
will be discarded. An empty last part will result in a path that
ends with a separator.

Ok, he immediately knows he has to supply an empty string instead of a separator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15342>
_______________________________________

From report at bugs.python.org  Mon Jul 16 06:31:36 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jul 2012 04:31:36 +0000
Subject: [issue13590] extension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <3WbBXP3DWPzNwj@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6a1e983647bd by Ned Deily in branch 'default':
Issue #13590: Improve support for OS X Xcode 4:
http://hg.python.org/cpython/rev/6a1e983647bd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Mon Jul 16 06:56:26 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 16 Jul 2012 04:56:26 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1342414586.93.0.408246161863.issue15233@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I have been meditating on this, and I'm not sure we should change 2.7.  3.2 might be okay.

The thing is, I fear we're not just talking about CPython implementation details, we're talking about the Python Standard Library.  The existing documentation clearly gives alternative implementations free license to call atexit registered functions in any order they like.  So it's conceivable that other implementations don't guarantee reverse order.

I don't know what the right thing is to do here.  It seems like we could define atexit's behavior for 2.7 *if* all the major alternative implementations happily also implicitly guarantee reverse order.  Failing that we probably shouldn't touch it.  Or we could just document that reverse order is guaranteed in CPython only.

Of course, there are no alternative implementations that support 3.2.  That's why I think 3.2 might be okay.  It does seem strange to redefine part of the implicit language spec more than a year after the release shipped though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15233>
_______________________________________

From report at bugs.python.org  Mon Jul 16 07:17:17 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 16 Jul 2012 05:17:17 +0000
Subject: [issue14635] telnetlib uses select instead of poll - limited to
	FD_SETSIZE fds
In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za>
Message-ID: <1342415837.06.0.714695400375.issue14635@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

looking at this now.  2.7 commit first; then i'll forward port to 3.2/3.3.

----------
assignee: jackdied -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14635>
_______________________________________

From report at bugs.python.org  Mon Jul 16 07:17:55 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jul 2012 05:17:55 +0000
Subject: [issue14635] telnetlib uses select instead of poll - limited to
	FD_SETSIZE fds
In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za>
Message-ID: <3WbCYs6X8zzP26@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c53e3aacb816 by Gregory P. Smith in branch '2.7':
Fixes Issue #14635: telnetlib will use poll() rather than select() when possible
http://hg.python.org/cpython/rev/c53e3aacb816

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14635>
_______________________________________

From report at bugs.python.org  Mon Jul 16 07:18:27 2012
From: report at bugs.python.org (David Lam)
Date: Mon, 16 Jul 2012 05:18:27 +0000
Subject: [issue11698] Improve repr for structseq objects to show named,
	but unindexed fields
In-Reply-To: <1301264097.04.0.982421975108.issue11698@psf.upfronthosting.co.za>
Message-ID: <1342415907.47.0.746868977892.issue11698@psf.upfronthosting.co.za>


David Lam <d at dlam.me> added the comment:

hi hi,  found this bug after clicking the "Easy issues" link

i basically just took Ray's hint to look at the __reduce__ method, and applied it to the __repr__ method in this patch

also updated is the test_repr() unittest

----------
keywords: +patch
nosy: +dlam
Added file: http://bugs.python.org/file26391/issue11698.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11698>
_______________________________________

From report at bugs.python.org  Mon Jul 16 07:42:29 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 16 Jul 2012 05:42:29 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
In-Reply-To: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za>
Message-ID: <1342417349.55.0.821069275525.issue15352@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Hmmm, I guess the idempotency issue is no worse than it already is -- the
same thing can still happen with trivial changes to the other prerequisites 
for importlib.h.

Consider this small example (you might have to run sample program multiple 
times to see a difference):

$ cat dis-closure.py
import dis

def adder(a, b):
    def add():
        return a + b
    return add

print(dis.dis(adder(1, 2).__code__))

$  ./python.exe dis-closure.py
  5           0 LOAD_DEREF               0 (a) 
              3 LOAD_DEREF               1 (b) 
              6 BINARY_ADD           
              7 RETURN_VALUE         
None
$  ./python.exe dis-closure.py
  5           0 LOAD_DEREF               1 (a) 
              3 LOAD_DEREF               0 (b) 
              6 BINARY_ADD           
              7 RETURN_VALUE         
None

The order of 'co_cellvars', 'co_varnames', and 'co_freevars' can be
different from compile to compile, thus the bytecode can be different
from compile to compile (I am not sure if this is worth fixing).

Thus there may be times where importlib.h is regenerated, but the changes 
in the bytecode aren't significant.

I will just commit this patch as is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Mon Jul 16 08:25:06 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 16 Jul 2012 06:25:06 +0000
Subject: [issue7171] Add inet_ntop and inet_pton support for Windows
In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za>
Message-ID: <1342419906.76.0.0597992997233.issue7171@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Implementation of inet_pton and inet_ntop by WSAAddressToStringA and
WSAStringToAddressA for Windows.

Conversion of IPv6 address might fail if IPv6 is 
not installed.

Tested on Windows XP SP3 and Windows7.

----------
keywords: +patch
nosy: +ishimoto
Added file: http://bugs.python.org/file26392/issue7171.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7171>
_______________________________________

From report at bugs.python.org  Mon Jul 16 08:38:52 2012
From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=)
Date: Mon, 16 Jul 2012 06:38:52 +0000
Subject: [issue15317] Source installation sets incorrect permissions for
	Grammar3.2.3.final.0.pickle
In-Reply-To: <1342269886.84.0.680553830262.issue15317@psf.upfronthosting.co.za>
Message-ID: <20120716063849.GH27657@hilla.kapsi.fi>


Tomi Pievil?inen <tomi.pievilainen+launchpad at iki.fi> added the comment:

On Sat, Jul 14, 2012 at 12:44:46PM +0000, ?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> How did you configure and build?  If you ran make as root it may explain this.

Indeed I did do it as root for all steps. The umask for root was 022,
however.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15317>
_______________________________________

From report at bugs.python.org  Mon Jul 16 08:42:36 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 16 Jul 2012 06:42:36 +0000
Subject: [issue15337] The cmd module incorrectly lists "help" as an
	undocumented command
In-Reply-To: <1342122491.31.0.595399950091.issue15337@psf.upfronthosting.co.za>
Message-ID: <1342420956.74.0.932642448863.issue15337@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15337>
_______________________________________

From report at bugs.python.org  Mon Jul 16 08:45:00 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jul 2012 06:45:00 +0000
Subject: [issue14635] telnetlib uses select instead of poll - limited to
	FD_SETSIZE fds
In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za>
Message-ID: <3WbFVM4jmWzP5R@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset de229dde486b by Gregory P. Smith in branch '3.2':
Fixes Issue #14635: telnetlib will use poll() rather than select() when possible
http://hg.python.org/cpython/rev/de229dde486b

New changeset 558e5ed678c3 by Gregory P. Smith in branch 'default':
Fixes Issue #14635: telnetlib will use poll() rather than select() when possible
http://hg.python.org/cpython/rev/558e5ed678c3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14635>
_______________________________________

From report at bugs.python.org  Mon Jul 16 08:50:39 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 16 Jul 2012 06:50:39 +0000
Subject: [issue14790] use packaging in setup.py
In-Reply-To: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za>
Message-ID: <1342421439.34.0.808131155384.issue14790@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

At the moment, it seems that this just won't happen. If a new attempt is made to integrate packaging with Python, this may or may not become an issue (e.g. whoever is doing the integration the next time might adapt setup.py from the beginning).

So closing this as "won't fix".

----------
priority: deferred blocker -> 
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14790>
_______________________________________

From report at bugs.python.org  Mon Jul 16 08:58:05 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 16 Jul 2012 06:58:05 +0000
Subject: [issue14635] telnetlib uses select instead of poll - limited to
	FD_SETSIZE fds
In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za>
Message-ID: <1342421885.36.0.537458098576.issue14635@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14635>
_______________________________________

From report at bugs.python.org  Mon Jul 16 09:01:15 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 16 Jul 2012 07:01:15 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1342422075.65.0.47753663475.issue15233@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1 for backport.  There's no benefit to leaving ambiguity floating about, nor was there ever any intention for the behavior to have been different.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15233>
_______________________________________

From report at bugs.python.org  Mon Jul 16 09:08:15 2012
From: report at bugs.python.org (Brian Thorne)
Date: Mon, 16 Jul 2012 07:08:15 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>
Message-ID: <1342422495.1.0.302964673729.issue12428@psf.upfronthosting.co.za>


Changes by Brian Thorne <hardbyte at gmail.com>:


----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12428>
_______________________________________

From report at bugs.python.org  Mon Jul 16 09:11:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jul 2012 07:11:12 +0000
Subject: [issue15337] The cmd module incorrectly lists "help" as an
	undocumented command
In-Reply-To: <1342122491.31.0.595399950091.issue15337@psf.upfronthosting.co.za>
Message-ID: <3WbG4b2xmjzP8V@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 076ae30e5dd0 by Raymond Hettinger in branch '2.7':
Issue 15337: help() shown as undocumented
http://hg.python.org/cpython/rev/076ae30e5dd0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15337>
_______________________________________

From report at bugs.python.org  Mon Jul 16 09:11:37 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 16 Jul 2012 07:11:37 +0000
Subject: [issue15337] The cmd module incorrectly lists "help" as an
	undocumented command
In-Reply-To: <1342122491.31.0.595399950091.issue15337@psf.upfronthosting.co.za>
Message-ID: <1342422697.89.0.324706044126.issue15337@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/issue15337>
_______________________________________

From report at bugs.python.org  Mon Jul 16 10:20:33 2012
From: report at bugs.python.org (koobs)
Date: Mon, 16 Jul 2012 08:20:33 +0000
Subject: [issue12978] Figure out extended attributes on BSDs
In-Reply-To: <1316014526.21.0.982877507813.issue12978@psf.upfronthosting.co.za>
Message-ID: <1342426833.92.0.705381036036.issue12978@psf.upfronthosting.co.za>


koobs <koobs.freebsd at gmail.com> added the comment:

And to clarify the no-follow-symlinks case on FreeBSD:

extattr_{get,set,list,delete}_link "system calls behave in the same way as their _file counterparts, except that they do not follow sym-links." as per the man page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12978>
_______________________________________

From report at bugs.python.org  Mon Jul 16 11:39:25 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 Jul 2012 09:39:25 +0000
Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za>
Message-ID: <1342431565.06.0.576387530135.issue4130@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I agree with Meador that this should be fixed upstream first.
There's a thread here on libffi-discuss, with a patch but no
conclusive answer:


http://sourceware.org/ml/libffi-discuss/2012/msg00168.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4130>
_______________________________________

From report at bugs.python.org  Mon Jul 16 11:53:36 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 Jul 2012 09:53:36 +0000
Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za>
Message-ID: <1342432416.64.0.83193886737.issue4130@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Ah, forget that: Alex has apparently already tested that patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4130>
_______________________________________

From report at bugs.python.org  Mon Jul 16 12:01:39 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 10:01:39 +0000
Subject: [issue15364] sysconfig confused by relative paths
Message-ID: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

With unix, and a source build, sysconfig.get_config_var('srcdir') and sysconfig.get_path('include') misbehave:

  user at mint-vm ~/Repos/cpython $ cd /
  user at mint-vm / $ ~/Repos/cpython/python 
  Python 3.3.0b1 (default:671894ae19a2, Jul 16 2012, 10:43:27) 
  [GCC 4.5.2] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import sysconfig
  >>> sysconfig.get_config_var('srcdir')
  '/'
  >>> sysconfig.get_path('include')
  '//Include'

The problem seems to be the else clause of

        if 'srcdir' not in _CONFIG_VARS:
            _CONFIG_VARS['srcdir'] = _PROJECT_BASE
        else:
            _CONFIG_VARS['srcdir'] = _safe_realpath(_CONFIG_VARS['srcdir'])

The else clause (in slightly modified form) was introduced in 356d0ea8ea34, and it turns a relative path into an absolute path, using the current working directory as a base.

For me, simply removing the line allows the absolute path to be calculated correctly a few lines later on.

I don't know what problem 356d0ea8ea34 was intended to fix.

----------
messages: 165581
nosy: sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: sysconfig confused by relative paths
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Mon Jul 16 12:17:36 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 Jul 2012 10:17:36 +0000
Subject: [issue15170] Fix 64-bit building for buildbot scripts (2.7)
In-Reply-To: <1340569734.61.0.00630889671182.issue15170@psf.upfronthosting.co.za>
Message-ID: <1342433856.88.0.931752311595.issue15170@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Closing, since all 2.7 buildbots compile.

----------
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15170>
_______________________________________

From report at bugs.python.org  Mon Jul 16 12:20:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 10:20:48 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
In-Reply-To: <1342378543.69.0.238492849946.issue15352@psf.upfronthosting.co.za>
Message-ID: <1342378882.3324.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Anyway, I am hitting another problem now -- _freeze_importlib is *not* idempotent.

What do you mean with "idempotent"? Deterministic?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Mon Jul 16 12:21:17 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 Jul 2012 10:21:17 +0000
Subject: [issue15170] Fix 64-bit building for buildbot scripts (2.7)
In-Reply-To: <1340569734.61.0.00630889671182.issue15170@psf.upfronthosting.co.za>
Message-ID: <1342434077.59.0.750677328765.issue15170@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15170>
_______________________________________

From report at bugs.python.org  Mon Jul 16 12:23:32 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 Jul 2012 10:23:32 +0000
Subject: [issue15171] Fix 64-bit building for buildbot scripts (3.2)
In-Reply-To: <1340569808.6.0.680025468258.issue15171@psf.upfronthosting.co.za>
Message-ID: <1342434212.99.0.337530173811.issue15171@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

David, do you have an idea why the XP-4 3.2 machine fails the compile?
I can't reproduce this and I don't know if it's related to
334ff92a8483 or 177f93f0f5b9.

----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15171>
_______________________________________

From report at bugs.python.org  Mon Jul 16 12:25:08 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 16 Jul 2012 10:25:08 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342434308.13.0.840369192034.issue15364@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Mon Jul 16 12:28:15 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 16 Jul 2012 10:28:15 +0000
Subject: [issue15365] Traceback reporting can fail if IO cannot be imported
Message-ID: <1342434495.02.0.347473954517.issue15365@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Reporting an error early in the python startup, before importing is properly initialized, can be tricky.
For example, here:

if (PyImport_ImportFrozenModule("_frozen_importlib") <= 0) {
  Py_FatalError("Py_Initialize: can't import _frozen_importlib");

The problem is, that _Py_DisplaySourceLine will set an exception because it cannot import the io module.  And this will terminate the traceback output.

The attached patch aims to rectify it by ignoring errors from this api in traceback.c

----------
components: Interpreter Core
files: traceback.patch
keywords: patch
messages: 165585
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Traceback reporting can fail if IO cannot be imported
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26393/traceback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15365>
_______________________________________

From report at bugs.python.org  Mon Jul 16 12:28:56 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 16 Jul 2012 10:28:56 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1342434536.97.0.0604815619671.issue1492704@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Cleaned up the patch.

Gennadiy added a test of shutil.move(), but SameFileError 
will be raised only if shutil.copy() was called. 

Am I missing something?

----------
nosy: +ishimoto
Added file: http://bugs.python.org/file26394/issue1492704_new.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 12:56:25 2012
From: report at bugs.python.org (Alex Leach)
Date: Mon, 16 Jul 2012 10:56:25 +0000
Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
In-Reply-To: <1342432416.64.0.83193886737.issue4130@psf.upfronthosting.co.za>
Message-ID: <1952762.J6nqVplv6z@metabuntu>


Alex Leach <beamesleach at gmail.com> added the comment:

I hadn't tried the `long long` substitution before, but unfortunately I don't 
think that simple fix quite does the trick.

I just checked out libffi from git, and made the following patch:-
#$ diff -u ffi64.c ffi64.c.orig 

--- ffi64.c     2012-07-16 11:38:44.237255615 +0100
+++ ffi64.c.orig        2012-07-16 11:38:34.681045084 +0100
@@ -38,7 +38,7 @@
 #define MAX_SSE_REGS 8

 #ifdef __INTEL_COMPILER
-#define UINT128 long long
+#define UINT128 __m128
 #else
 #define UINT128 __int128_t
 #endif

It compiles fine, but `make check` returns a lot of FAIL's, and a quite a few 
of the tests timeout. e.g.
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ execution test
WARNING: program timed out.

It's probably also worth mentioning that I'm now using icc version 12.1.4

Cheers,
Alex

On Monday 16 Jul 2012 09:53:36 Stefan Krah wrote:
 > Stefan Krah <stefan-usenet at bytereef.org> added the comment:
> 
> Ah, forget that: Alex has apparently already tested that patch.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4130>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4130>
_______________________________________

From report at bugs.python.org  Mon Jul 16 13:26:36 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 Jul 2012 11:26:36 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <1342437996.65.0.365654930646.issue15238@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The new test fails on the Fedora bot:

http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/2881/steps/test/logs/stdio

======================================================================
FAIL: test_copyxattr (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_shutil.py", line 420, in test_copyxattr
    self.assertEqual(os.listxattr(src), ['user.the_value'])
AssertionError: Lists differ: ['security.selinux', 'user.the... != ['user.the_value']

First differing element 0:
security.selinux
user.the_value

First list contains 1 additional elements.
First extra element 1:
user.the_value

- ['security.selinux', 'user.the_value']
+ ['user.the_value']

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Mon Jul 16 13:30:11 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 11:30:11 +0000
Subject: [issue15366] venv assumes header files in sys._home + '/Include'
Message-ID: <1342438211.61.0.183367325622.issue15366@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

For Unix I follow the practice suggested in README of running configure from a subdir of the main python directory, eg

    mkdir release
    cd release
    ../configure
    make

But if I create a venv then I cannot use it to compile C extensions because the include dirs are wrong, eg

    running build
    running build_ext
    building 'demo' extension
    gcc -pthread -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/user/Repos/cpython/release/Include -I/home/user/Repos/cpython/release -c demo.c -o build/temp.linux-i686-3.3/demo.o
    demo.c:1:20: fatal error: Python.h: No such file or directory
    compilation terminated.
    error: command 'gcc' failed with exit status 1

The problem seems to be that distutils.sysconfig.get_python_inc() assumes that if sys._home is set (as it is in a virtual env) then the standard header files can be found in sys._home + '/Include'.

But for my venv this is wrong, since sys._home is "/home/user/Repos/cpython/release" and "/home/user/Repos/cpython/release/Include" is empty.  Instead get_python_inc() should return "/home/user/Repos/cpython/Include".

BTW, a seperate issue seems to be that ${venv}/include is not added to the list of include dirs used when compiling.

----------
components: Library (Lib)
messages: 165589
nosy: sbt, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: venv assumes header files in sys._home + '/Include'
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15366>
_______________________________________

From report at bugs.python.org  Mon Jul 16 13:46:41 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 11:46:41 +0000
Subject: [issue15367] build_ext in a venv on Windows assumes pyconfig.h in
	sys.exec_prefix + '\PC'
Message-ID: <1342439201.04.0.23455949432.issue15367@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

On Windows I can't use a source build of Python to create a venv which will compile C extensions because pyconfig.h cannot be found.  For example

    running build
    running build_ext
    building 'demo' extension
    creating build
    creating build\temp.win32-3.3
    creating build\temp.win32-3.3\Release
    c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -IC:\Repos\cpython\include -IC:\Users\oudkerk\myenv\PC /Tcdemo.c /Fobuild\temp.win32-3.3\Release\demo.obj
demo.c
    C:\Repos\cpython\include\Python.h(8) : fatal error C1083: Cannot open include file: 'pyconfig.h': No such file or directory
    error: command '"c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\cl.exe"' failed with exit status 2

The problem seems to be with the following line in distutils/command/build_ext.py:

            self.include_dirs.append(os.path.join(sys.exec_prefix, 'PC'))

Inside a venv, sys.exec_prefix is the venv directory.

----------
messages: 165590
nosy: sbt, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: build_ext in a venv on Windows assumes pyconfig.h in sys.exec_prefix + '\PC'
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15367>
_______________________________________

From report at bugs.python.org  Mon Jul 16 14:00:31 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 16 Jul 2012 12:00:31 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1342437996.65.0.365654930646.issue15238@psf.upfronthosting.co.za>
Message-ID: <5004025A.6060605@ox.cx>


Hynek Schlawack <hs at ox.cx> added the comment:

You can?t just compare the xattr because some (like security.*) can be
only copied as root. IIRC they come from SELinux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Mon Jul 16 14:13:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 12:13:07 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
In-Reply-To: <1342417349.55.0.821069275525.issue15352@psf.upfronthosting.co.za>
Message-ID: <1342440682.3396.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le lundi 16 juillet 2012 ? 05:42 +0000, Meador Inge a ?crit :
> The order of 'co_cellvars', 'co_varnames', and 'co_freevars' can be
> different from compile to compile, thus the bytecode can be different
> from compile to compile (I am not sure if this is worth fixing).

I don't know, but you could open an issue just for the record.
People may be surprised if bytecode generation isn't deterministic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Mon Jul 16 14:14:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 12:14:20 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1342440860.17.0.202691926774.issue1492704@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 14:22:53 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 12:22:53 +0000
Subject: [issue15367] build_ext in a venv on Windows assumes pyconfig.h in
	sys.exec_prefix + '\PC'
In-Reply-To: <1342439201.04.0.23455949432.issue15367@psf.upfronthosting.co.za>
Message-ID: <1342441373.83.0.04036453318.issue15367@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

The attached patch works for me.

----------
keywords: +patch
Added file: http://bugs.python.org/file26395/build_ext.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15367>
_______________________________________

From report at bugs.python.org  Mon Jul 16 14:31:48 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 16 Jul 2012 12:31:48 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342441908.81.0.636882963859.issue15307@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The test failure in test_osx_env is in itself fairly harmless because PYTHONEXECUTABLE is only used to ensure IDLE.app works correct, and IDLE.app doesn't use the pythonw executable and hence won't hit the code that special-cases the venv location.

That said, the failure should be removed and points to a real issue in my patch: with my patch calculate_path replaces the value set by Py_SetProgramName and that is a real problem that could break 3th-party code without a good reason.

I've attached v5 of the patch, this fixes the test_osx_env failure by moving the the code that uses __PYVENV_LAUNCHER__ to main.c (where Py_SetProgramName is called)

----------
Added file: http://bugs.python.org/file26396/venv-symlinks-v6.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Mon Jul 16 14:42:04 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 16 Jul 2012 12:42:04 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
In-Reply-To: <1342378882.3324.1.camel@localhost.localdomain>
Message-ID: <CAK1QoooeWQJMCCcxyX=r1wOzZzjD0ma7_REPg7F9QZATFRh+=Q@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Mon, Jul 16, 2012 at 5:20 AM, Antoine Pitrou <report at bugs.python.org> wrote:

>> Anyway, I am hitting another problem now -- _freeze_importlib is *not* idempotent.
>
> What do you mean with "idempotent"? Deterministic?

Whoops, yeah, deterministic.  I got mixed up with my terminology.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Mon Jul 16 14:52:36 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 16 Jul 2012 12:52:36 +0000
Subject: [issue15368] bytecode generation is not deterministic
Message-ID: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

Consider this small example (you might have to run sample program multiple 
times to see a difference):

$ cat dis-closure.py
import dis

def adder(a, b):
    def add():
        return a + b
    return add

print(dis.dis(adder(1, 2).__code__))

$  ./python.exe dis-closure.py
  5           0 LOAD_DEREF               0 (a) 
              3 LOAD_DEREF               1 (b) 
              6 BINARY_ADD           
              7 RETURN_VALUE         
None
$  ./python.exe dis-closure.py
  5           0 LOAD_DEREF               1 (a) 
              3 LOAD_DEREF               0 (b) 
              6 BINARY_ADD           
              7 RETURN_VALUE         
None

The order of 'co_cellvars' and 'co_freevars' can be different from compile to 
compile, thus the bytecode can be different from compile to compile.

This is due to the fact that these variable sets are managed with hashes and
the ordering may come out different when the names in the hashes are given
indexes (via 'dictbytype' in 'compile.c').

I am not sure if these are the only areas that causes bytecode generation
to be non-deterministic.  I found this behavior surprising.

----------
components: Interpreter Core
messages: 165596
nosy: meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: bytecode generation is not deterministic
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Mon Jul 16 14:54:04 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 16 Jul 2012 12:54:04 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
In-Reply-To: <1342440682.3396.0.camel@localhost.localdomain>
Message-ID: <CAK1Qooo2J1tUc3e6-Ks-YqzPGp5FjRhXh6k00Un3kpe9MmMxKA@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Mon, Jul 16, 2012 at 7:13 AM, Antoine Pitrou <report at bugs.python.org> wrote:

> I don't know, but you could open an issue just for the record.
> People may be surprised if bytecode generation isn't deterministic.

Yeah, I was somewhat surprised and it took some digging to figure
out exactly what was changing.  Opened issue15368 to track this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15352>
_______________________________________

From report at bugs.python.org  Mon Jul 16 14:55:26 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 12:55:26 +0000
Subject: [issue15366] venv assumes header files in sys._home + '/Include'
In-Reply-To: <1342438211.61.0.183367325622.issue15366@psf.upfronthosting.co.za>
Message-ID: <1342443326.66.0.406451195222.issue15366@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

The attached patch seems to fix the problem.

----------
keywords: +patch
Added file: http://bugs.python.org/file26397/distutils-sysconfig.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15366>
_______________________________________

From report at bugs.python.org  Mon Jul 16 15:10:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 16 Jul 2012 13:10:24 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1342444224.93.0.538052244926.issue1492704@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks.  Can you clarify what behavior changed compared to the previous patch?  From the doc it looks like shutil.move now always raises SameFileError, whereas the previous patch said that on Unix it depended on the semantics of os.rename.

The patch has some very minor issues like extraneous whitespace in the docs, but they can be fixed by the person committing.

----------
assignee: eric.araujo -> 
keywords: +needs review
stage: test needed -> patch review
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 15:11:02 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 16 Jul 2012 13:11:02 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342444262.55.0.582630357406.issue15368@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I might come to regret asking this, but so what? Is this actually causing you issues, or are you literally just finding "this behavior surprising" and that's it? I mean we could simply sort the tuples, but I don't know what kind of performance hit that would cause.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Mon Jul 16 15:26:36 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 16 Jul 2012 13:26:36 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342444262.55.0.582630357406.issue15368@psf.upfronthosting.co.za>
Message-ID: <CAK1QoooHd4TSUYrA9WF8Tz9qqoeU54pLQA8c7h-f5O028-GtRw@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Mon, Jul 16, 2012 at 8:11 AM, Brett Cannon <report at bugs.python.org> wrote:

> I might come to regret asking this, but so what? Is this actually causing you issues,
> or are you literally just finding "this behavior surprising" and that's it?

I noticed it in the context of working on issue15352.  There are still
a few issue in the
build system where 'importlib.h' isn't regenerated when it needs to be
(e.g. when
the marshaling code is changed).  When investigating that issue I noticed that
trivial changes (e.g. `touch _bootstrap.py`) can cause differences in
'importlib.h'.
Those differences are mainly due to the cell and free var indexes being
reordered.

Since the bytecode generation isn't deterministic, there can be some noisy diffs
in your working copy when mucking around with the files related to the frozen
importlib.  Thus if we ever wanted to just always generate importlib.h because
we can't be sure which changed source files should cause importlib.h to be
regenerated, then the non-determinism would be a real annoyance.

That is the only concrete issue I currently am aware of.  This issue may not
actually be worth addressing, but I felt it was worthy of discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Mon Jul 16 15:31:29 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 16 Jul 2012 13:31:29 +0000
Subject: [issue14644] test_logging failure on OS X Tiger
In-Reply-To: <1335097784.55.0.606093462856.issue14644@psf.upfronthosting.co.za>
Message-ID: <1342445489.15.0.122464685761.issue14644@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I get failures for the same test on my machine running OSX 10.7, the machine is fairly overloaded right now because I'm running a large VM in the background.

Increasing the timeout from 5.0 to 15.0 seconds ensures that the test passes.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14644>
_______________________________________

From report at bugs.python.org  Mon Jul 16 15:34:24 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 16 Jul 2012 13:34:24 +0000
Subject: [issue9102] pybench: Cannot compare 2.x and 3.x benchmarks
In-Reply-To: <1277739722.07.0.677340784013.issue9102@psf.upfronthosting.co.za>
Message-ID: <1342445664.32.0.11030031866.issue9102@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9102>
_______________________________________

From report at bugs.python.org  Mon Jul 16 15:41:45 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 16 Jul 2012 13:41:45 +0000
Subject: [issue15369] pybench and test.pystone poorly documented
Message-ID: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The benchmarking tools "pystones" and "pybench" which are shipped with the Python standard distribution are not documented.

The only information is in the what's-new for Python 2.5:
http://docs.python.org/dev/whatsnew/2.5.html?highlight=pybench#new-improved-and-removed-modules

IMHO, they should be mentioned somewhere in the HOWTOs, the FAQ or the standard library documentation ("Development Tools" or "Debugging and Profiling")

----------
assignee: docs at python
components: Benchmarks, Documentation
messages: 165603
nosy: docs at python, flox
priority: normal
severity: normal
status: open
title: pybench and test.pystone poorly documented
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15369>
_______________________________________

From report at bugs.python.org  Mon Jul 16 15:47:25 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 16 Jul 2012 13:47:25 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1342446445.49.0.246537401376.issue1492704@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Behavior is not changed at all.

I fixed test_shutil.py to test if SameFileError is raised in
shutil.copy() instead of shutil.move().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 15:53:44 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 13:53:44 +0000
Subject: [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1342446824.19.0.825979597694.issue14787@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Right, this is a separate bug in pkgutil. Specifically, when it goes to import a package in order to check it for submodules, it invokes the global import system via __import__() rather than constraining the import to the path argument supplied to walk_packages.

This means that it will only find it if the path being walked is already on sys.path. In the case of your example, it isn't (it's on a subdirectory).

The reason my new tests didn't pick this up is that they're built on the test_runpy infrastructure, and one of the steps in that infrastructure is to add the new package path to sys.path so it can be imported.

This isn't an easy one to fix - you basically need something along the lines of a PEP 406 style import engine API in order to do the import without having potentially adverse effects on the state in the sys module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14787>
_______________________________________

From report at bugs.python.org  Mon Jul 16 15:55:00 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 16 Jul 2012 13:55:00 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1342446900.26.0.0840806228675.issue1492704@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

If nobody else, I?ll review it tomorrow at the latest.

On a first glance I realized our shutil Exceptions are all derived from EnvironmentError which is just a compatibility alias for OSError since 3.3.

Quick poll before I open a dedicated ticket, change that for 3.4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 15:56:13 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 16 Jul 2012 13:56:13 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1342446973.98.0.361028990494.issue1492704@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

So, the title of this issue is misleading.

The patch originally proposed by Zooko does not raise SameFileError in
shutil.move(). If source and destination is same file, shutil.move() may
raise exception, but the exception is NOT SameFileError but OSError or something.

shutil.copy() raises SameFileError if source and destination is same file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:00:37 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 16 Jul 2012 14:00:37 +0000
Subject: [issue1492704] distinct error type from shutil.move()
In-Reply-To: <1342446973.98.0.361028990494.issue1492704@psf.upfronthosting.co.za>
Message-ID: <50041E80.5010208@ox.cx>


Hynek Schlawack <hs at ox.cx> added the comment:

Well, then fix is for shutil.move() too please, otherwise we can?t close
this ticket which is a pity after over 6 years. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:09:54 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 16 Jul 2012 14:09:54 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1342447794.14.0.488343151787.issue1492704@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Well, I happy to improve patch. 

But, on Linux and Windows, shutil.move() does not raise any exception if source and destination are identical. If we change the behavior, I'm afraid we would break a lot of existing applications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:18:25 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Jul 2012 14:18:25 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342448305.08.0.480004676999.issue15368@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/issue15368>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:19:21 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 16 Jul 2012 14:19:21 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <1342448361.85.0.883673421244.issue1492704@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Sorry, I didn?t look at zooko?s patch which was also just about copyfile. I presume it?s all about the copy fallback that happens when os.rename didn?t work out.

Will look at your code more closely later.

----------
title: distinct error type from shutil.move() -> distinct error type if shutil.copyfile() fails because of src and dst are the same file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:19:43 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 16 Jul 2012 14:19:43 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <1342448383.22.0.599807272767.issue1492704@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Ooops, shutil.move() will raise SameFileError if destination is directory. I'll investigate the patch further more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:22:20 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 14:22:20 +0000
Subject: [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1342448540.74.0.192563878944.issue14787@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

At the very least, the pkgutil docs need to state clearly that walk_packages only works properly with sys.path entries, and the constraint feature may not descend into packages correctly if an entry is shadowed by a sys.modules entry or an entry earlier on sys.meta_path or sys.path.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14787>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:26:11 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 14:26:11 +0000
Subject: [issue15370] test_runpy should include namespace package tests
Message-ID: <1342448771.76.0.81603722524.issue15370@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

test_runpy doesn't currently check that code can be correctly executed from namespace packages

----------
components: Tests
messages: 165613
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_runpy should include namespace package tests
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15370>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:27:57 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 14:27:57 +0000
Subject: [issue15371] test_cmd_line_script should include namespace package
	tests
Message-ID: <1342448877.31.0.875625357245.issue15371@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

test_cmd_line_script doesn't currently check that namespace packages and submodules of namespace packages can be executed via the -m switch

----------
components: Library (Lib)
messages: 165614
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_cmd_line_script should include namespace package tests
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15371>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:28:02 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 16 Jul 2012 14:28:02 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342448882.79.0.771416843801.issue15307@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

And a final update: don't use TAB characters

----------
Added file: http://bugs.python.org/file26398/venv-symlinks-v7.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:31:32 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 16 Jul 2012 14:31:32 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342449092.49.0.490429021918.issue15368@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/issue15368>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:31:48 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 14:31:48 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>
Message-ID: <1342449108.3.0.650992767317.issue15358@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The walk_packages tests should also be enhanced to ensure correctly handling of namespace packages

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:33:49 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 14:33:49 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>
Message-ID: <1342449229.31.0.40585390717.issue15358@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note that the problem described in #14787 will limit the scope of what can be tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:35:18 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 14:35:18 +0000
Subject: [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1342449318.01.0.316117733042.issue14787@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I just realised this is going to behave strangely with namespace packages as well: the __import__ step will pick up *every* portion of the namespace package, not just those defined in the identified subset of sys.path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14787>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:43:07 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 14:43:07 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342449787.3.0.722144360358.issue15368@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

At least we know the hash randomisation is working :)

Spurious changes when freezing modules seems like a legitimate reason to fix it - the import benchmarks would probably give the compiler enough of a workout to highlight if the sorting is excessively time consuming.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:43:29 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 16 Jul 2012 14:43:29 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342449809.52.0.434006303946.issue15364@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't recall what the issue was the resulted in the check-in that you mention. Sadly enough it is not-trivial to find that check-in I mention due to the migration from Subversion to Mercurial.

How was python itself configured (configure command line)? What OS are you running on? Given the shell prompt I'd say Mint Linux. And finally, is '~/Repos/cpython/python' a checkout or installed location (that is, did you run 'make install')?

Based on code inspection I'd say that your change is correct, and my change only works when running from the build directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:46:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 14:46:13 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342449973.27.0.313349475036.issue15368@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ditto. I think predictability of bytecode generation is useful, e.g. for make-like tools that examine content, or for unit testing.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:51:55 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 16 Jul 2012 14:51:55 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <1342450315.31.0.6732897712.issue15238@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Hynek, it's clear you understand this far better than I do.  Could I get you to fix the Fedora buildbot problem, etc, etc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Mon Jul 16 16:58:35 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 Jul 2012 14:58:35 +0000
Subject: [issue15352] importlib.h should be regenerated when the marshaling
	code changes
In-Reply-To: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za>
Message-ID: <1342450715.94.0.0675961683057.issue15352@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/issue15352>
_______________________________________

From report at bugs.python.org  Mon Jul 16 17:01:47 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 Jul 2012 15:01:47 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342450907.69.0.867630772514.issue15368@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/issue15368>
_______________________________________

From report at bugs.python.org  Mon Jul 16 17:03:12 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 Jul 2012 15:03:12 +0000
Subject: [issue11698] Improve repr for structseq objects to show named,
	but unindexed fields
In-Reply-To: <1301264097.04.0.982421975108.issue11698@psf.upfronthosting.co.za>
Message-ID: <1342450992.56.0.271384653431.issue11698@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/issue11698>
_______________________________________

From report at bugs.python.org  Mon Jul 16 17:15:25 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jul 2012 15:15:25 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <3WbSqJ01c4zP2y@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 265e36e277f3 by Hynek Schlawack in branch 'default':
#15238: Fix xattr related shutil.copystat tests
http://hg.python.org/cpython/rev/265e36e277f3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Mon Jul 16 17:17:19 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 15:17:19 +0000
Subject: [issue15366] venv assumes header files in sys._home + '/Include'
In-Reply-To: <1342438211.61.0.183367325622.issue15366@psf.upfronthosting.co.za>
Message-ID: <1342451839.3.0.877632186304.issue15366@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Updated patch.  Old one broke test_distutils...

----------
Added file: http://bugs.python.org/file26399/distutils-sysconfig.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15366>
_______________________________________

From report at bugs.python.org  Mon Jul 16 17:19:47 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 15:19:47 +0000
Subject: [issue15367] build_ext in a venv on Windows assumes pyconfig.h in
	sys.exec_prefix + '\PC'
In-Reply-To: <1342439201.04.0.23455949432.issue15367@psf.upfronthosting.co.za>
Message-ID: <1342451987.96.0.0164868926822.issue15367@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Updated patch which does not fail test_distutils.

----------
Added file: http://bugs.python.org/file26400/build_ext.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15367>
_______________________________________

From report at bugs.python.org  Mon Jul 16 17:37:12 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 16 Jul 2012 15:37:12 +0000
Subject: [issue15238] shutil.copystat should copy Linux extended attributes
In-Reply-To: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>
Message-ID: <1342453032.75.0.288882350314.issue15238@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

I removed the check for good as we check for the existence of the xattr in the next line. However we check the destination now whether the xattrs have been copied. ;) Fedora is green again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15238>
_______________________________________

From report at bugs.python.org  Mon Jul 16 17:39:22 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 16 Jul 2012 15:39:22 +0000
Subject: [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1342453162.64.0.655246850951.issue14787@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

> This isn't an easy one to fix - you basically need something along the lines of a PEP 406 style import engine API in order to do the import without having potentially adverse effects on the state in the sys module.

By adverse, do you just mean side effects? If so, since the documentation doesn't explicitly say so, is there any reason for the user to think there shouldn't be side effects?  For example, I tried this in Python 2.7:

>>> import os, sys, pkgutil, unittest
>>> len(sys.modules)
86
>>> g = pkgutil.walk_packages([os.path.dirname(unittest.__file__)])
>>> len(sys.modules)
86
>>> for i in g:
...   pass
... 
>>> len(sys.modules)
95

Or maybe this isn't what you mean. If not, can you provide an example?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14787>
_______________________________________

From report at bugs.python.org  Mon Jul 16 17:47:36 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 15:47:36 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342453656.77.0.456168925803.issue15364@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

> I don't recall what the issue was the resulted in the check-in that you
> mention.

I think it was http://bugs.python.org/issue8577.  The issue was about having srcdir != builddir.  The initial patch caused a test failure, and 356d0ea8ea34 fixed (or at least silenced) the failure.

> How was python itself configured (configure command line)?

I tried it with both

   ./configure
   make

and

   mdkir release
   cd release
   ../configure
   make

It fails with both.

> What OS are you running on? Given the shell prompt I'd say Mint Linux. 

Yes (in a VM).

> And finally, is '~/Repos/cpython/python' a checkout or installed 
> location (that is, did you run 'make install')?

It is a checkout.

The argument passed to _safe_realpath() (either "." or ".." in my case) should be interpreted relative to the directory containing the Makefile.  But os.path.realpath() assumes that its argument is either absolute or relative to os.getcwd().  It therefore returns the wrong absolute path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Mon Jul 16 17:59:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 15:59:05 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342454345.83.0.638031392316.issue15364@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Mon Jul 16 18:03:22 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 16 Jul 2012 16:03:22 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <1342454602.04.0.694031244146.issue1492704@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Patch updated.

- SameFileError is now derived from EnvironmentError.
- Fixed documentation.
- Fixed test method name.

I investigated this patch:

- shutil.copyfile() and shutil.copy() raises SameFileError if source and destination are same file.

- shutil.move() never raises SameFileError. shutil.move() may raise exception if source and dest are same file, but it depends on underlying implementation of platform. Linux and Windows don't raise exception in this case.

- I am opposed to change shutil.move() to raise SameFileError, because such incompatible change can break existing applilcations.

----------
Added file: http://bugs.python.org/file26401/issue1492704_new_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 18:04:22 2012
From: report at bugs.python.org (Luca Fabbri)
Date: Mon, 16 Jul 2012 16:04:22 +0000
Subject: [issue15372] Python is missing alternative for common quoting
	character
Message-ID: <1342454662.71.0.490144532965.issue15372@psf.upfronthosting.co.za>


New submission from Luca Fabbri <lucafbb at gmail.com>:

Using the unicodedata.decomposition function on characters like \u201c and \u201d I didn't get back the classic quote character (").

This is a very common error when text is taken from Microsoft Word (where in italian language a couple of quoting character in a sentence like "foo" is automatically changed to ?foo?).

----------
components: Unicode
messages: 165630
nosy: ezio.melotti, keul
priority: normal
severity: normal
status: open
title: Python is missing alternative for common quoting character
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15372>
_______________________________________

From report at bugs.python.org  Mon Jul 16 18:08:58 2012
From: report at bugs.python.org (Hartmut Goebel)
Date: Mon, 16 Jul 2012 16:08:58 +0000
Subject: [issue15373] copy.copy() does not properly copy os.environment
Message-ID: <1342454937.95.0.386630033182.issue15373@psf.upfronthosting.co.za>


New submission from Hartmut Goebel <h.goebel at crazy-compilers.com>:

Wehn copying os.environ usinf copy.copy(), any manipulation on the copied object will change os.environment, too.

$ python
Python 2.7.3 (default, Apr 22 2012, 07:46:58) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import copy, os
>>> os.environ['TITI']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/UserDict.py", line 23, in __getitem__
    raise KeyError(key)
KeyError: 'TITI'
>>> env = copy.copy(os.environ)
>>> env['TITI'] = 'in den Ferien'
>>> os.environ['TITI']
'in den Ferien'
>>> 

Strictly speaking, this is correct, as the os.environment class is meant to manipulate the environment in the background. But user's expectation is different: he thinks, manipulating the copied object is save and does not effect the environment.

----------
messages: 165631
nosy: htgoebel
priority: normal
severity: normal
status: open
title: copy.copy() does not properly copy os.environment
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15373>
_______________________________________

From report at bugs.python.org  Mon Jul 16 18:23:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 16 Jul 2012 16:23:05 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342455785.66.0.898368012647.issue15364@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It is actually simple to find the revision: http://hg.python.org/lookup/r81999 :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Mon Jul 16 18:25:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 16 Jul 2012 16:25:24 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342455924.27.0.334446430831.issue15364@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have to add that I?m quite confused by srcdir vs. projectbase.  There are a handful of open bugs related to sysconfig and built but uninstalled Pythons, and many commits changing code to use srcdir or projectbase after empirical testing or buildbot failures. :/

----------
nosy: +fdrake, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Mon Jul 16 18:41:59 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 16 Jul 2012 16:41:59 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342456919.14.0.183162193117.issue15364@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

srcdir vs. project base is quite easy: srcdir is the directory containing the source files, the project base is where you ran configure. These are the same if you run configure in the root of a checkout, but don't have to be, for example when you do:

$ mkdir buildroot
$ cd buildroot
$ ../configure # ...

Now de base directory is the 'buildroot' directory, while srcdir is its parent directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Mon Jul 16 18:42:39 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 16 Jul 2012 16:42:39 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
In-Reply-To: <1342454602.04.0.694031244146.issue1492704@psf.upfronthosting.co.za>
Message-ID: <12146D8E-CA1A-4241-B237-1F4A22541A84@ox.cx>


Hynek Schlawack <hs at ox.cx> added the comment:

> - SameFileError is now derived from EnvironmentError.

Why?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 18:43:43 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Jul 2012 16:43:43 +0000
Subject: [issue15372] Python is missing alternative for common quoting
	character
In-Reply-To: <1342454662.71.0.490144532965.issue15372@psf.upfronthosting.co.za>
Message-ID: <1342457023.21.0.271875977165.issue15372@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't understand why you would expect to get a ".  The unicode characters aren't "s.  As far as I can see (from, for example, http://codepoints.net/U+201C), Python is behaving as expected here.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15372>
_______________________________________

From report at bugs.python.org  Mon Jul 16 18:53:36 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Jul 2012 16:53:36 +0000
Subject: [issue15373] copy.copy() does not properly copy os.environment
In-Reply-To: <1342454937.95.0.386630033182.issue15373@psf.upfronthosting.co.za>
Message-ID: <1342457616.3.0.297384280498.issue15373@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

os.environ is not a dictionary, so it isn't all that surprising that a shallow copy doesn't behave like a shallow copy of a dictionary.  deepcopy does what you'd expect, as does os.environ.copy().

Perhaps it is worth improving this by adding a __copy__ method to os.environ.  Someone would need to propose a patch, and it would be an enhancement.

----------
nosy: +r.david.murray
type: behavior -> enhancement
versions: +Python 3.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15373>
_______________________________________

From report at bugs.python.org  Mon Jul 16 18:55:14 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 16 Jul 2012 16:55:14 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <1342457714.99.0.789438439389.issue1492704@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

>> - SameFileError is now derived from EnvironmentError.
>
>Why?

oh, sorry, I misunderstood you suggested to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 19:07:09 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 16 Jul 2012 17:07:09 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
In-Reply-To: <1342457714.99.0.789438439389.issue1492704@psf.upfronthosting.co.za>
Message-ID: <8760ED1D-334F-49DA-A85A-B1CE8A6F7491@ox.cx>


Hynek Schlawack <hs at ox.cx> added the comment:

No, sorry if my ramblings confused you. I'm pondering about deriving Error from OSError in 3.4. That has nothing to do with this ticket. I just saw it while glancing over your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Mon Jul 16 19:16:21 2012
From: report at bugs.python.org (Karl Chen)
Date: Mon, 16 Jul 2012 17:16:21 +0000
Subject: [issue504714] hasattr catches only AttributeError
Message-ID: <1342458981.14.0.401668335639.issue504714@psf.upfronthosting.co.za>


Karl Chen <quarl at 09e0.clgubaohtf.z.quarl.org> added the comment:

For the record, this was eventually fixed for Python 3.2.  See 
http://bugs.python.org/issue9666.

Adding this here because issue504714 comes up earlier than issue9666 in many web searches.

----------
nosy: +quarl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue504714>
_______________________________________

From report at bugs.python.org  Mon Jul 16 19:23:52 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 16 Jul 2012 17:23:52 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342459432.76.0.564362272659.issue15368@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, so it sounds like we need to do the equivalent of sorting those tuples when generating the bytecode. That would suggest that probably need to tweak Python/compile.c to make it deterministic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Mon Jul 16 19:25:07 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jul 2012 17:25:07 +0000
Subject: [issue15366] venv assumes header files in sys._home + '/Include'
In-Reply-To: <1342438211.61.0.183367325622.issue15366@psf.upfronthosting.co.za>
Message-ID: <3WbWhy2nK1zPK5@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 998c8a8f2aea by Vinay Sajip in branch 'default':
Closes #15366: Corrected computation of include location for source builds. Thanks to Richard Oudkerk for the bug report and patch.
http://hg.python.org/cpython/rev/998c8a8f2aea

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15366>
_______________________________________

From report at bugs.python.org  Mon Jul 16 19:30:21 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jul 2012 17:30:21 +0000
Subject: [issue15367] build_ext in a venv on Windows assumes pyconfig.h in
	sys.exec_prefix + '\PC'
In-Reply-To: <1342439201.04.0.23455949432.issue15367@psf.upfronthosting.co.za>
Message-ID: <3WbWq01hCdzPKZ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a970054a93fb by Vinay Sajip in branch 'default':
Closes #15367: Corrected computation of include locations for source builds on Windows. Thanks to Richard Oudkerk for the bug report and patch.
http://hg.python.org/cpython/rev/a970054a93fb

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15367>
_______________________________________

From report at bugs.python.org  Mon Jul 16 19:48:27 2012
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 16 Jul 2012 17:48:27 +0000
Subject: [issue15372] Python is missing alternative for common quoting
	character
In-Reply-To: <1342454662.71.0.490144532965.issue15372@psf.upfronthosting.co.za>
Message-ID: <1342460907.23.0.746212060197.issue15372@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

A codepoint such as "?" ("\N{LATIN SMALL LETTER E WITH ACUTE}") can be decomposed to "\u0065\u0301" ("\N{LATIN SMALL LETTER E}\N{COMBINING ACUTE ACCENT"), but "\u201c" ("\N{LEFT DOUBLE QUOTATION MARK}") and "\u201d" ("\N{RIGHT DOUBLE QUOTATION MARK}") cannot be decomposed.

----------
nosy: +mrabarnett
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15372>
_______________________________________

From report at bugs.python.org  Mon Jul 16 19:49:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 17:49:29 +0000
Subject: [issue15372] Python is missing alternative for common quoting
	character
In-Reply-To: <1342454662.71.0.490144532965.issue15372@psf.upfronthosting.co.za>
Message-ID: <1342460969.92.0.160847960107.issue15372@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15372>
_______________________________________

From report at bugs.python.org  Mon Jul 16 20:01:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 18:01:22 +0000
Subject: [issue15374] venv environment variable should follow the conventions
Message-ID: <1342461682.61.0.267332995554.issue15374@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

pyvenv's environment variable is currently named VIRTUAL_ENV (it seems).
It would be better if it followed the trend of other Python environment variables such as PYTHONHOME, PYTHONSTARTUP, etc.
(so, PYTHONVENV ?)

Setting as deferred blocker, since it would be better for existing venvs not to be made useless.

----------
components: Library (Lib)
messages: 165645
nosy: georg.brandl, pitrou, vinay.sajip
priority: deferred blocker
severity: normal
status: open
title: venv environment variable should follow the conventions
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15374>
_______________________________________

From report at bugs.python.org  Mon Jul 16 21:13:34 2012
From: report at bugs.python.org (Erik Johansson)
Date: Mon, 16 Jul 2012 19:13:34 +0000
Subject: [issue14201] Documented caching for shared library's __getattr__ and
	__getitem__ is incorrect
In-Reply-To: <1330957421.08.0.5889949548.issue14201@psf.upfronthosting.co.za>
Message-ID: <1342466014.45.0.104279671475.issue14201@psf.upfronthosting.co.za>


Erik Johansson <erik at ejohansson.se> added the comment:

Document the difference between __getattr__ and __getitem__.

----------
keywords: +patch
Added file: http://bugs.python.org/file26402/issue14201.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14201>
_______________________________________

From report at bugs.python.org  Mon Jul 16 21:13:50 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 16 Jul 2012 19:13:50 +0000
Subject: [issue15373] copy.copy() does not properly copy os.environment
In-Reply-To: <1342454937.95.0.386630033182.issue15373@psf.upfronthosting.co.za>
Message-ID: <1342466030.77.0.512746902754.issue15373@psf.upfronthosting.co.za>


Anton Barkovsky <swarmer.pm at gmail.com> added the comment:

Here's a patch.

----------
keywords: +patch
nosy: +anton.barkovsky
Added file: http://bugs.python.org/file26403/environcopy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15373>
_______________________________________

From report at bugs.python.org  Mon Jul 16 21:18:22 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 16 Jul 2012 19:18:22 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342466302.16.0.473593509182.issue15307@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

v7 looks good to me

----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Mon Jul 16 21:26:59 2012
From: report at bugs.python.org (David Bolen)
Date: Mon, 16 Jul 2012 19:26:59 +0000
Subject: [issue15171] Fix 64-bit building for buildbot scripts (3.2)
In-Reply-To: <1340569808.6.0.680025468258.issue15171@psf.upfronthosting.co.za>
Message-ID: <1342466819.31.0.851200792575.issue15171@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

It seems really unlikely to be related to this issue since I'm pretty sure build-amd64 doesn't get used on XP-4.

>From the log it looks like it couldn't clean out and reuse the VS temporary build directory.  Manually cleaning it out and restarting the last build appears to have at least gotten past compiling.

I can't really explain why this was a problem, when I was able to manually remove the directory without error, and couldn't find any stray processes that may have been holding references to the files in that temporary directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15171>
_______________________________________

From report at bugs.python.org  Mon Jul 16 21:27:45 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 19:27:45 +0000
Subject: [issue14635] telnetlib uses select instead of poll - limited to
	FD_SETSIZE fds
In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za>
Message-ID: <1342466865.13.0.540782712512.issue14635@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This broke the buildbots without poll() (Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14635>
_______________________________________

From report at bugs.python.org  Mon Jul 16 21:31:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 19:31:25 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <1342467085.52.0.746959803358.issue15314@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A test fails on the XP buildbots:



======================================================================
FAIL: test_get_importer_avoids_emulation (test.test_pkgutil.ImportlibMigrationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pkgutil.py", line 289, in test_get_importer_avoids_emulation
    self.assertIsNotNone(pkgutil.get_importer(sys.path[0]))
AssertionError: unexpectedly None

----------
nosy: +pitrou
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15314>
_______________________________________

From report at bugs.python.org  Mon Jul 16 21:39:02 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 16 Jul 2012 19:39:02 +0000
Subject: [issue15373] copy.copy() does not properly copy os.environment
In-Reply-To: <1342454937.95.0.386630033182.issue15373@psf.upfronthosting.co.za>
Message-ID: <1342467542.13.0.773432511854.issue15373@psf.upfronthosting.co.za>


Anton Barkovsky <swarmer.pm at gmail.com> added the comment:

A new patch with tests.

----------
Added file: http://bugs.python.org/file26404/environcopy_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15373>
_______________________________________

From report at bugs.python.org  Mon Jul 16 22:19:06 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 20:19:06 +0000
Subject: [issue15171] Fix 64-bit building for buildbot scripts (3.2)
In-Reply-To: <1340569808.6.0.680025468258.issue15171@psf.upfronthosting.co.za>
Message-ID: <1342469946.77.0.187998305124.issue15171@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

David, since you are here, perhaps you could take a look at why your Windows 7 buildbot doesn't compile?
http://buildbot.python.org/all/builders/x86%20Windows7%203.x

I tried to e-mail you but apparently you didn't receive the message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15171>
_______________________________________

From report at bugs.python.org  Mon Jul 16 22:36:49 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 16 Jul 2012 20:36:49 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342471009.53.0.97608457778.issue15364@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Issue 15322 is a recently filed bug regarding srcdir: "sysconfig.get_config_var('srcdir') returns unexpected value"

----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Mon Jul 16 22:53:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 16 Jul 2012 20:53:26 +0000
Subject: [issue15351] Add to unittest.TestCase support for using context
	managers
In-Reply-To: <1342280032.27.0.345733068822.issue15351@psf.upfronthosting.co.za>
Message-ID: <1342472006.05.0.466323169441.issue15351@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attached is a patch illustrating the API I suggested for discussion.

To add custom setup and teardown context managers, the user can override the following method:

    def executeTest(self):
        with self.setUpContext():
            self.runTestMethod()

The custom context managers can be placed either before or after the existing setUp/tearDown, or both.

The patch preserves the existing behavior that tearDown() should run only if setUp() was successful, and that doCleanups() should always run.  All tests continue to pass with the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file26405/issue-15351-concept.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15351>
_______________________________________

From report at bugs.python.org  Mon Jul 16 23:23:27 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 21:23:27 +0000
Subject: [issue15230] runpy.run_path doesn't set __package__ correctly
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <1342473807.99.0.410234717786.issue15230@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This broke some 3.2 buildbots, e.g.:
http://buildbot.python.org/all/builders/AMD64%20Lion%203.2/builds/25

----------
nosy: +pitrou
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15230>
_______________________________________

From report at bugs.python.org  Mon Jul 16 23:33:23 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 16 Jul 2012 21:33:23 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342474403.87.0.56325857408.issue15184@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Georg, are you still able to reproduce this? I've subsequently tried on a Debian platform with an installed clang and could not reproduce.  And, after further inspecting the current code, I really don't see how the clang substitution could happen on a non-darwin platform.  My initial speculation about test_unixcompiler was incorrect as well as the proposed patch to preserve config vars in it (that test does not actually affect _config_vars and _config_vars is a dict so has to be deep-copied to be restorable).  I'm proceeding with the _osx_support consolidation but I sure would like to know what was behind the behavior you reported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Mon Jul 16 23:33:40 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 16 Jul 2012 21:33:40 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342474420.98.0.000737771888811.issue15184@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file26163/issue15184_preserve_config_vars.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Mon Jul 16 23:35:52 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Mon, 16 Jul 2012 21:35:52 +0000
Subject: [issue6804] IDLE: Detect Python files even if name doesn't end in .py
In-Reply-To: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>
Message-ID: <1342474552.17.0.354510197338.issue6804@psf.upfronthosting.co.za>


Daniel Swanson <popcorn.tomato.dude at gmail.com> added the comment:

I am also somewhat puzzled by this issue.
The other day I was able to open some .txt files just to see if I could and they opened just fine.
Just now I tryed to open a .jpg file and I got an error message, but then again, why would someone save a python file as a jpeg image?

----------
nosy: +weirdink13

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6804>
_______________________________________

From report at bugs.python.org  Tue Jul 17 00:12:22 2012
From: report at bugs.python.org (HCT)
Date: Mon, 16 Jul 2012 22:12:22 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1342476742.2.0.625702095586.issue6493@psf.upfronthosting.co.za>


HCT <hctamtb at gmail.com> added the comment:

Hirokazu's v3 patch is a clean solution for the issue and works on 3.2 

any update on when it will go into 3.2/3.3? I can help if needed

----------
nosy: +hct

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Tue Jul 17 00:15:12 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 22:15:12 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1342476912.51.0.423845820189.issue6493@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: theller -> 
components: +Library (Lib), Windows
nosy: +meador.inge
stage: commit review -> patch review
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Tue Jul 17 00:16:04 2012
From: report at bugs.python.org (Alex Leach)
Date: Mon, 16 Jul 2012 22:16:04 +0000
Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
In-Reply-To: <1342432416.64.0.83193886737.issue4130@psf.upfronthosting.co.za>
Message-ID: <2121850.oUxmvAAuKI@metabuntu>


Alex Leach <beamesleach at gmail.com> added the comment:

I just had a dig around my cpython build dir, and found an ffi64.c I hacked at a 
while back.
I copied the edits over to the latest libffi git revision, rebuilt, and `make 
check` (of libffi) passes all tests. So as far as I can tell the below patch 
works, but it is a hack, and I'm sure it could be improved..

Regards to submitting it upstream, I've just written to the libffi-
discuss/sourceware.org mailing list, sending them the below patch also. So it 
might work, but you know that GPL clause about coming with no warranty? ;)

HTH,
Alex

libffi-git> diff -u src/x86/ffi64.c.orig src/x86/ffi64.c

--- src/x86/ffi64.c.orig        2012-07-16 11:38:34.681045084 +0100
+++ src/x86/ffi64.c     2012-07-16 22:34:42.959552750 +0100
@@ -38,7 +38,7 @@
 #define MAX_SSE_REGS 8

 #ifdef __INTEL_COMPILER
-#define UINT128 __m128
+typedef struct { int64_t m[2]; } __int128_t;
 #else
 #define UINT128 __int128_t
 #endif
@@ -47,7 +47,7 @@
 {
   /* Registers for argument passing.  */
   UINT64 gpr[MAX_GPR_REGS];
-  UINT128 sse[MAX_SSE_REGS];
+  __int128_t sse[MAX_SSE_REGS];
 };

 extern void ffi_call_unix64 (void *args, unsigned long bytes, unsigned flags,
@@ -477,10 +477,20 @@
                  break;
                case X86_64_SSE_CLASS:
                case X86_64_SSEDF_CLASS:
+#ifdef __INTEL_COMPILER
+                 reg_args->sse[ssecount].m[0] = *(UINT64 *) a;
+                 reg_args->sse[ssecount++].m[1] = 0;
+#else
                  reg_args->sse[ssecount++] = *(UINT64 *) a;
+#endif
                  break;
                case X86_64_SSESF_CLASS:
+#ifdef __INTEL_COMPILER
+                 reg_args->sse[ssecount].m[0] = *(UINT32 *) a;
+                 reg_args->sse[ssecount++].m[1] = 0;
+#else
                  reg_args->sse[ssecount++] = *(UINT32 *) a;
+#endif
                  break;
                default:
                  abort();

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4130>
_______________________________________

From report at bugs.python.org  Tue Jul 17 00:18:31 2012
From: report at bugs.python.org (Alex Leach)
Date: Mon, 16 Jul 2012 22:18:31 +0000
Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
In-Reply-To: <2121850.oUxmvAAuKI@metabuntu>
Message-ID: <1386950.yG6zg5oHoE@metabuntu>


Alex Leach <beamesleach at gmail.com> added the comment:

It skips 55, sorry, passing 1659.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4130>
_______________________________________

From report at bugs.python.org  Tue Jul 17 00:25:50 2012
From: report at bugs.python.org (Alex Leach)
Date: Mon, 16 Jul 2012 22:25:50 +0000
Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
In-Reply-To: <1386950.yG6zg5oHoE@metabuntu>
Message-ID: <11008293.OGPTouHtZQ@metabuntu>


Alex Leach <beamesleach at gmail.com> added the comment:

That's the same patch as I attached before actually, so sorry for the spam..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4130>
_______________________________________

From report at bugs.python.org  Tue Jul 17 01:03:39 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 16 Jul 2012 23:03:39 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <1342479819.87.0.868458230668.issue1492704@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Patch updated.

- SameFileError is reverted to be derived from shutil.Error as original patch.

----------
Added file: http://bugs.python.org/file26406/issue1492704_new_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Tue Jul 17 01:06:12 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 23:06:12 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342479972.22.0.259886073561.issue15364@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

In the attached patch _safe_realpath() is only called after calculating the absolute path for srcdir.

----------
keywords: +patch
Added file: http://bugs.python.org/file26407/sysconf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Tue Jul 17 01:10:39 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 16 Jul 2012 23:10:39 +0000
Subject: [issue14635] telnetlib uses select instead of poll - limited to
	FD_SETSIZE fds
In-Reply-To: <1342466865.13.0.540782712512.issue14635@psf.upfronthosting.co.za>
Message-ID: <CAGE7PN+=13+ZZOdmS0365vCX-hPRzfYaAABevs8wN5NNyXD-Og@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Those should all be fixed as of my most recent commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14635>
_______________________________________

From report at bugs.python.org  Tue Jul 17 01:59:33 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 16 Jul 2012 23:59:33 +0000
Subject: [issue15374] venv environment variable should follow the conventions
In-Reply-To: <1342461682.61.0.267332995554.issue15374@psf.upfronthosting.co.za>
Message-ID: <1342483173.39.0.0381907462733.issue15374@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This name was picked because the virtualenv tool uses it, and keeping the name allows any existing third-party projects and scripts which use it to require minimal, if any, changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15374>
_______________________________________

From report at bugs.python.org  Tue Jul 17 02:15:59 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Jul 2012 00:15:59 +0000
Subject: [issue15374] venv environment variable should follow the conventions
In-Reply-To: <1342483173.39.0.0381907462733.issue15374@psf.upfronthosting.co.za>
Message-ID: <1342484030.3396.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This name was picked because the virtualenv tool uses it, and keeping
> the name allows any existing third-party projects and scripts which
> use it to require minimal, if any, changes.

Which means that these third-party projects are automatically compatible
with pyvenv?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15374>
_______________________________________

From report at bugs.python.org  Tue Jul 17 02:37:32 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 17 Jul 2012 00:37:32 +0000
Subject: [issue6804] IDLE: Detect Python files even if name doesn't end in .py
In-Reply-To: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>
Message-ID: <1342485452.19.0.575766517345.issue6804@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Is the error message a traceback? If so, could you open a separate issue for it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6804>
_______________________________________

From report at bugs.python.org  Tue Jul 17 02:54:05 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 17 Jul 2012 00:54:05 +0000
Subject: [issue15374] venv environment variable should follow the conventions
In-Reply-To: <1342461682.61.0.267332995554.issue15374@psf.upfronthosting.co.za>
Message-ID: <1342486445.2.0.536637747346.issue15374@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Which means that these third-party projects are automatically
> compatible with pyvenv?

I can't speak for them, but it's one less thing for people to have to change. The intention certainly was to minimise friction in this area.

I would be interested in Carl's opinion (as he's a virtualenv maintainer).

----------
nosy: +carljm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15374>
_______________________________________

From report at bugs.python.org  Tue Jul 17 04:05:11 2012
From: report at bugs.python.org (Renato Cunha)
Date: Tue, 17 Jul 2012 02:05:11 +0000
Subject: [issue15375] Trivial for fix in the subprocess documentation
Message-ID: <1342490711.26.0.923529626372.issue15375@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

The word "child" is needlessly repeated in the subprocess documentation. This trivial patch fixes this.

----------
assignee: docs at python
components: Documentation
files: subprocess.diff
keywords: patch
messages: 165670
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: Trivial for fix in the subprocess documentation
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file26408/subprocess.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15375>
_______________________________________

From report at bugs.python.org  Tue Jul 17 04:31:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Jul 2012 02:31:48 +0000
Subject: [issue15375] Trivial for fix in the subprocess documentation
In-Reply-To: <1342490711.26.0.923529626372.issue15375@psf.upfronthosting.co.za>
Message-ID: <3Wblqj5yRPzPJ5@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 227a22288688 by R David Murray in branch '2.7':
#15375: remove duplicated word 'child'
http://hg.python.org/cpython/rev/227a22288688

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15375>
_______________________________________

From report at bugs.python.org  Tue Jul 17 04:32:58 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Jul 2012 02:32:58 +0000
Subject: [issue15375] Trivial for fix in the subprocess documentation
In-Reply-To: <1342490711.26.0.923529626372.issue15375@psf.upfronthosting.co.za>
Message-ID: <1342492378.88.0.081120655622.issue15375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.  (This error existed on only in the 2.7 docs.)

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15375>
_______________________________________

From report at bugs.python.org  Tue Jul 17 04:46:03 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 17 Jul 2012 02:46:03 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1342493163.92.0.0128867696264.issue1767933@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Fixed the invariant violation in changeset 64ff90e07d71

I'll review the performance difference separately

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Tue Jul 17 05:23:21 2012
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 17 Jul 2012 03:23:21 +0000
Subject: [issue15374] venv environment variable should follow the conventions
In-Reply-To: <1342461682.61.0.267332995554.issue15374@psf.upfronthosting.co.za>
Message-ID: <1342495401.13.0.772117709874.issue15374@psf.upfronthosting.co.za>


Carl Meyer <carl at dirtcircle.com> added the comment:

Yes, there are a number of third-party utility packages (and many, many e.g. personal custom bash prompts) that check the value of the $VIRTUAL_ENV variable to detect whether one is currently active, and display its name. Unless there's an overriding reason, it would be nice to not require changing all of this code.

Certainly not all third-party virtualenv-related tools will be compatible with pyvenv unchanged; for instance tools that create envs will need to use the updated pyvenv API. But there is a lot of code using $VIRTUAL_ENV that won't require any other changes, if we can keep using the same env var.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15374>
_______________________________________

From report at bugs.python.org  Tue Jul 17 05:34:48 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 17 Jul 2012 03:34:48 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1342496088.74.0.194915697504.issue1767933@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I posted a message to python-dev about the performance issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Tue Jul 17 05:37:16 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 17 Jul 2012 03:37:16 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342496236.08.0.60071360822.issue15368@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I haven't done any benchmarking (yet), but here is a patch implementing the basic sorting approach.

----------
keywords: +patch
Added file: http://bugs.python.org/file26409/issue15368-v0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Tue Jul 17 05:37:43 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 17 Jul 2012 03:37:43 +0000
Subject: [issue14332] Better explain "junk" concept in difflib doc
In-Reply-To: <1331877125.66.0.103153393744.issue14332@psf.upfronthosting.co.za>
Message-ID: <1342496263.34.0.930916411625.issue14332@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I agree. Any improvement is preferred over just letting this decay in the issue tracker ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14332>
_______________________________________

From report at bugs.python.org  Tue Jul 17 06:07:58 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 17 Jul 2012 04:07:58 +0000
Subject: [issue14988] _elementtree: Raise ImportError when importing of
	pyexpat fails
In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za>
Message-ID: <1342498078.38.0.431542587559.issue14988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I tried blocking the import of 'pyexpat' in a test by using test.support.import_fresh_module, placing 'pyexpat' into the blocked list, but it doesn't work (i.e. pyexpat, if it exists, is still imported)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14988>
_______________________________________

From report at bugs.python.org  Tue Jul 17 06:11:28 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 17 Jul 2012 04:11:28 +0000
Subject: [issue14988] _elementtree: Raise ImportError when importing of
	pyexpat fails
In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za>
Message-ID: <1342498288.7.0.0629296315893.issue14988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Benjamin, what "old behavior"? Did it happen to raise ImportError historically and only recent changes made it RuntimeError? I'm not sure  this is the case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14988>
_______________________________________

From report at bugs.python.org  Tue Jul 17 07:30:06 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 17 Jul 2012 05:30:06 +0000
Subject: [issue14988] _elementtree: Raise ImportError when importing of
	pyexpat fails
In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za>
Message-ID: <1342503006.34.0.870834254816.issue14988@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

> Did it happen to raise ImportError historically and only recent
> changes made it RuntimeError? I'm not sure  this is the case.

ImportError was raised in Python 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14988>
_______________________________________

From report at bugs.python.org  Tue Jul 17 07:31:10 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 17 Jul 2012 05:31:10 +0000
Subject: [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342503070.09.0.989183701483.issue15151@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov.ml at gmail.com> added the comment:

Larry, Brett,

I compiled the documentation from the PEP (attached as inspect.pep362.1.patch).  Please take a look and feel free to add/edit.

----------
keywords: +patch
Added file: http://bugs.python.org/file26410/inspect.pep362.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15151>
_______________________________________

From report at bugs.python.org  Tue Jul 17 09:05:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 17 Jul 2012 07:05:41 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>
Message-ID: <1342508741.77.0.848135458239.issue15358@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I'd like to work on this if that's okay.  I've already written test cases for issue 7559 and issue 15299 that required creating temporary packages, so I understand the need.  And I'd also like to create test cases for issue 14787, which should really be done after this.

I think this should be split into two parts though: (1) refactor the create-package code in test_runpy into a separate helper module, and (2) move the refactored walk_package tests from test_runpy into test_pkgutil (so it's easier to see what has changed).

I can create a new issue for (1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Tue Jul 17 09:10:49 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 17 Jul 2012 07:10:49 +0000
Subject: [issue15376] Refactor the create-package code in test_runpy into a
	helper module
Message-ID: <1342509049.53.0.303616016829.issue15376@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to refactor the create-package code in test_runpy into a helper module, as suggested in issue 15358.

This is a prerequisite to moving the pkgutil.walk_package() tests from test_runpy into test_pkgutil.

----------
components: Tests
keywords: easy
messages: 165683
nosy: cjerdonek, ncoghlan
priority: normal
severity: normal
status: open
title: Refactor the create-package code in test_runpy into a helper module
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15376>
_______________________________________

From report at bugs.python.org  Tue Jul 17 09:11:43 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 17 Jul 2012 07:11:43 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>
Message-ID: <1342509103.07.0.345855041494.issue15358@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
dependencies: +Refactor the create-package code in test_runpy into a helper module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:09:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Jul 2012 08:09:25 +0000
Subject: [issue15374] venv environment variable should follow the conventions
In-Reply-To: <1342495401.13.0.772117709874.issue15374@psf.upfronthosting.co.za>
Message-ID: <1342512456.3389.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, there are a number of third-party utility packages (and many,
> many e.g. personal custom bash prompts) that check the value of the
> $VIRTUAL_ENV variable to detect whether one is currently active, and
> display its name. Unless there's an overriding reason, it would be
> nice to not require changing all of this code.

Ok, it sounds reasonable enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15374>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:11:58 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Jul 2012 08:11:58 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>
Message-ID: <1342512718.1.0.330348393614.issue15358@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

That sounds good, and thanks for working on this - if we can get the tests cleaned up for the 3.3 release, that will make ongoing maintenance a lot easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:11:58 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 17 Jul 2012 08:11:58 +0000
Subject: [issue15377] os.path.join() error misleading with path1=None
Message-ID: <1342512718.53.0.395843871145.issue15377@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The error message for os.path.join() is misleading when the first argument is None.  The message should probably say something about mixing "None" and strings.

Python 3.3.0b1 (default:f954ee489896, Jul 16 2012, 22:42:29) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
>>> import os
>>> os.path.join(None, 'a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../cpython/Lib/posixpath.py", line 89, in join
    "components.") from None
TypeError: Can't mix strings and bytes in path components.

----------
components: Library (Lib)
messages: 165685
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: os.path.join() error misleading with path1=None
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15377>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:15:13 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Jul 2012 08:15:13 +0000
Subject: [issue15378] Underported Tools/unicode/comparecodecs.py
Message-ID: <1342512913.96.0.0337741529294.issue15378@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Tools/unicode/gencodec.py was not properly ported from Python 2 to Python 3. The suggested patch fixes this porting issue.

----------
components: Demos and Tools
files: decode_charmap_maxchar.patch
keywords: patch
messages: 165687
nosy: storchaka
priority: normal
severity: normal
status: open
title: Underported Tools/unicode/comparecodecs.py
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26411/decode_charmap_maxchar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15378>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:15:29 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 17 Jul 2012 08:15:29 +0000
Subject: [issue15377] os.path.join() error misleading with path1=None
In-Reply-To: <1342512718.53.0.395843871145.issue15377@psf.upfronthosting.co.za>
Message-ID: <1342512929.76.0.52585848688.issue15377@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15377>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:15:58 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Jul 2012 08:15:58 +0000
Subject: [issue15379] Charmap decoding of no-BMP characters
Message-ID: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Yet one inconsistency in charmap codec.

>>> import codecs
>>> codecs.charmap_decode(b'\x00', 'strict', '\U0002000B')
('?', 1)
>>> codecs.charmap_decode(b'\x00', 'strict', {0: '\U0002000B'})
('?', 1)
>>> codecs.charmap_decode(b'\x00', 'strict', {0: 0x2000B})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: character mapping must be in range(65536)

The suggested patch removes this unnecessary limitation in charmap decoder.

----------
components: Interpreter Core
files: decode_charmap_maxchar.patch
keywords: patch
messages: 165688
nosy: storchaka
priority: normal
severity: normal
status: open
title: Charmap decoding of no-BMP characters
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26412/decode_charmap_maxchar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15379>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:30:21 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Jul 2012 08:30:21 +0000
Subject: [issue15378] Underported Tools/unicode/comparecodecs.py
In-Reply-To: <1342512913.96.0.0337741529294.issue15378@psf.upfronthosting.co.za>
Message-ID: <1342513821.95.0.889666827691.issue15378@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Oops, wrong message, wrong patch.

Tools/unicode/comparecodecs.py was not properly ported from Python 2 to Python 3. The suggested patch fixes this porting issue.

----------
Added file: http://bugs.python.org/file26413/comparecodecs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15378>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:30:44 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Jul 2012 08:30:44 +0000
Subject: [issue15378] Underported Tools/unicode/comparecodecs.py
In-Reply-To: <1342512913.96.0.0337741529294.issue15378@psf.upfronthosting.co.za>
Message-ID: <1342513844.15.0.712727690621.issue15378@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file26411/decode_charmap_maxchar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15378>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:54:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Jul 2012 08:54:29 +0000
Subject: [issue15379] Charmap decoding of no-BMP characters
In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za>
Message-ID: <1342515269.99.0.615060486306.issue15379@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Could you add a test to your patch?
Is the issue 3.3-specific?

----------
nosy: +benjamin.peterson, ezio.melotti, haypo, lemburg, pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15379>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:54:56 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Jul 2012 08:54:56 +0000
Subject: [issue15378] Underported Tools/unicode/comparecodecs.py
In-Reply-To: <1342512913.96.0.0337741529294.issue15378@psf.upfronthosting.co.za>
Message-ID: <1342515296.53.0.14085457892.issue15378@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ezio.melotti, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15378>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:57:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Jul 2012 08:57:05 +0000
Subject: [issue15373] copy.copy() does not properly copy os.environment
In-Reply-To: <1342454937.95.0.386630033182.issue15373@psf.upfronthosting.co.za>
Message-ID: <1342515425.6.0.928158199751.issue15373@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree with David that copy(os.environ) is rather ambiguous. I think the preferred idiom should be to call dict(os.environ).
As for __copy__, I don't know what it should do: perhaps simply raise an error when copying is attempted?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15373>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:57:51 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Jul 2012 08:57:51 +0000
Subject: [issue15374] venv environment variable should follow the conventions
In-Reply-To: <1342461682.61.0.267332995554.issue15374@psf.upfronthosting.co.za>
Message-ID: <1342515471.84.0.872686810282.issue15374@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15374>
_______________________________________

From report at bugs.python.org  Tue Jul 17 10:58:45 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Jul 2012 08:58:45 +0000
Subject: [issue15365] Traceback reporting can fail if IO cannot be imported
In-Reply-To: <1342434495.02.0.347473954517.issue15365@psf.upfronthosting.co.za>
Message-ID: <1342515525.74.0.140590615039.issue15365@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks simple enough, but you should use spaces, not tabs.

----------
nosy: +amaury.forgeotdarc, pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15365>
_______________________________________

From report at bugs.python.org  Tue Jul 17 11:07:04 2012
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 17 Jul 2012 09:07:04 +0000
Subject: [issue15380] bytes/str mismatch in distribute
Message-ID: <1342516024.25.0.62947980787.issue15380@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

I tried installing CherryPy into my local Python 3.2 build. I don't know if this is a problem with CherryPy's setup.py or with distribute but suspect the latter since I've had similar problems before.

$ /home/mark/opt/python32/bin/python3 setup.py install
running install
running bdist_egg
running egg_info
writing CherryPy.egg-info/PKG-INFO
writing top-level names to CherryPy.egg-info/top_level.txt
writing dependency_links to CherryPy.egg-info/dependency_links.txt
reading manifest file 'CherryPy.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'CherryPy.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
creating build
creating build/lib
creating build/lib/cherrypy
copying cherrypy/_cperror.py -> build/lib/cherrypy
...
byte-compiling build/bdist.linux-x86_64/egg/cherrypy/_cperror.py to _cperror.pyc
...
installing package data to build/bdist.linux-x86_64/egg
running install_data
copying cherrypy/cherryd -> build/bdist.linux-x86_64/egg/cherrypy
...
creating build/bdist.linux-x86_64/egg/EGG-INFO
installing scripts to build/bdist.linux-x86_64/egg/EGG-INFO/scripts
running install_scripts
running build_scripts
creating build/scripts-3.2
copying and adjusting cherrypy/cherryd -> build/scripts-3.2
changing mode of build/scripts-3.2/cherryd from 644 to 755
creating build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-3.2/cherryd -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/cherryd to 755
copying CherryPy.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO
copying CherryPy.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying CherryPy.egg-info/dependency_links.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying CherryPy.egg-info/top_level.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
cherrypy._cpmodpy: module references __file__
...
creating dist
creating 'dist/CherryPy-3.2.2-py3.2.egg' and adding 'build/bdist.linux-x86_64/egg' to it
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing CherryPy-3.2.2-py3.2.egg
creating /home/mark/opt/python32/lib/python3.2/site-packages/CherryPy-3.2.2-py3.2.egg
Extracting CherryPy-3.2.2-py3.2.egg to /home/mark/opt/python32/lib/python3.2/site-packages
Adding CherryPy 3.2.2 to easy-install.pth file
Traceback (most recent call last):
  File "setup.py", line 144, in <module>
    main()
  File "setup.py", line 139, in main
    cmdclass=cmd_class,
  File "/home/mark/opt/python32/lib/python3.2/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/home/mark/opt/python32/lib/python3.2/distutils/dist.py", line 917, in run_commands
    self.run_command(cmd)
  File "/home/mark/opt/python32/lib/python3.2/distutils/dist.py", line 936, in run_command
    cmd_obj.run()
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/install.py", line 73, in run
    self.do_egg_install()
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/install.py", line 101, in do_egg_install
    cmd.run()
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 236, in run
    self.easy_install(spec, not self.no_deps)
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 452, in easy_install
    return self.install_item(None, spec, tmpdir, deps, True)
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 503, in install_item
    self.process_distribution(spec, dist, deps)
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 522, in process_distribution
    self.install_egg_scripts(dist)
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 401, in install_egg_scripts
    dist.get_metadata('scripts/'+script_name)
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 615, in install_script
    script_text = get_script_header(script_text) + (
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 1449, in get_script_header
    match = first_line_re.match(first)
TypeError: can't use a bytes pattern on a string-like object

----------
assignee: eric.araujo
components: Distutils
messages: 165693
nosy: eric.araujo, mark, tarek
priority: normal
severity: normal
status: open
title: bytes/str mismatch in distribute
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15380>
_______________________________________

From report at bugs.python.org  Tue Jul 17 11:46:06 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 17 Jul 2012 09:46:06 +0000
Subject: [issue15377] os.path.join() error misleading with path1=None
In-Reply-To: <1342512718.53.0.395843871145.issue15377@psf.upfronthosting.co.za>
Message-ID: <1342518366.18.0.0949273303459.issue15377@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

I propose the following patch (against 3.2) that does the right thing.

----------
keywords: +patch
nosy: +ncoghlan, pitrou
stage:  -> patch review
Added file: http://bugs.python.org/file26414/nicer-error-for-none.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15377>
_______________________________________

From report at bugs.python.org  Tue Jul 17 11:49:24 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 17 Jul 2012 09:49:24 +0000
Subject: [issue15377] os.path.join() error misleading with path1=None
In-Reply-To: <1342512718.53.0.395843871145.issue15377@psf.upfronthosting.co.za>
Message-ID: <1342518564.5.0.0950646854583.issue15377@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
assignee:  -> hynek
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15377>
_______________________________________

From report at bugs.python.org  Tue Jul 17 12:24:08 2012
From: report at bugs.python.org (Volodymyr Kostyrko)
Date: Tue, 17 Jul 2012 10:24:08 +0000
Subject: [issue9591] kqueue not reporting EOF under certain circumstances
In-Reply-To: <1281725245.42.0.301580096416.issue9591@psf.upfronthosting.co.za>
Message-ID: <1342520648.12.0.792242164307.issue9591@psf.upfronthosting.co.za>


Volodymyr Kostyrko <c.kworr at gmail.com> added the comment:

I was wrong. The current behavior is correct. The difference between execution is a difference between pipe file object and vnode file object. vnode backed file objects doesn't send any signals and care should be taken to detect file position.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9591>
_______________________________________

From report at bugs.python.org  Tue Jul 17 12:25:48 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Jul 2012 10:25:48 +0000
Subject: [issue15377] os.path.join() error misleading with path1=None
In-Reply-To: <1342512718.53.0.395843871145.issue15377@psf.upfronthosting.co.za>
Message-ID: <1342520748.65.0.573430881122.issue15377@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'd be more inclined to tighten up the check for the "can't mix" message to something like:

 valid_types = all(isinstance(s, (str, bytes, bytearray)) for s in (a, ) + p)
 if valid_types:
    # Must have a mixture of text and binary data
    raise TypeError("Can't mix strings and bytes in path components.")
 raise

If people pass in something that isn't a valid argument *at all*, then I'm fine with just letting the underlying exception pass through.

The str/bytes case is just worth special-casing because either on their own *are* valid arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15377>
_______________________________________

From report at bugs.python.org  Tue Jul 17 12:30:48 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Jul 2012 10:30:48 +0000
Subject: [issue15230] runpy.run_path doesn't set __package__ correctly
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <1342521048.58.0.962503399408.issue15230@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

*grumble*grumble*os-x-and-its-crazy-symlink-as-tmp-dir*grumble*grumble*

I'm fairly sure I've tripped over this kind of thing before, so I believe I know how to fix it (add a realpath() call when figuring out the expected path value).

The buildbots will let me know if I'm right, of course :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15230>
_______________________________________

From report at bugs.python.org  Tue Jul 17 12:33:43 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 17 Jul 2012 10:33:43 +0000
Subject: [issue15365] Traceback reporting can fail if IO cannot be imported
In-Reply-To: <1342434495.02.0.347473954517.issue15365@psf.upfronthosting.co.za>
Message-ID: <1342521223.3.0.131350677689.issue15365@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Certainly.  But the submission filter would have caught that.
The question is:  Is it acceptible to simply ignore errors from this api when printing tracebacks?  There are other errors that can be returned as well.
The trouble is, any errors in the traceback reporting will be ignored anyway, since there is no way to report them :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15365>
_______________________________________

From report at bugs.python.org  Tue Jul 17 12:38:27 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Jul 2012 10:38:27 +0000
Subject: [issue15365] Traceback reporting can fail if IO cannot be imported
In-Reply-To: <1342434495.02.0.347473954517.issue15365@psf.upfronthosting.co.za>
Message-ID: <1342521507.74.0.207976436968.issue15365@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The trouble is, any errors in the traceback reporting will be ignored
> anyway, since there is no way to report them :)

Which is a good reason to ignore them, isn't it? ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15365>
_______________________________________

From report at bugs.python.org  Tue Jul 17 12:40:55 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Jul 2012 10:40:55 +0000
Subject: [issue15380] bytes/str mismatch in distribute
In-Reply-To: <1342516024.25.0.62947980787.issue15380@psf.upfronthosting.co.za>
Message-ID: <1342521655.36.0.202440804249.issue15380@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Distribute is not part of Distutils. According to its PyPI page (http://pypi.python.org/pypi/distribute#feedback-and-getting-involved), the project has its own issue tracker at https://bitbucket.org/tarek/distribute/issues/

----------
nosy: +ned.deily
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15380>
_______________________________________

From report at bugs.python.org  Tue Jul 17 12:41:24 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Jul 2012 10:41:24 +0000
Subject: [issue15380] bytes/str mismatch in distribute
In-Reply-To: <1342516024.25.0.62947980787.issue15380@psf.upfronthosting.co.za>
Message-ID: <1342521684.71.0.989703822105.issue15380@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15380>
_______________________________________

From report at bugs.python.org  Tue Jul 17 12:43:54 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Jul 2012 10:43:54 +0000
Subject: [issue15230] runpy.run_path doesn't set __package__ correctly
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <3WbylX6Q4lzPFw@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 07ed744a47f6 by Nick Coghlan in branch '3.2':
Issue #15230: Attempt to make the OS X buildbots happy by resolving the tmp dir symlink in the test suite
http://hg.python.org/cpython/rev/07ed744a47f6

New changeset cb7e8ee489a1 by Nick Coghlan in branch 'default':
Merge Issue #15230 OS X buildbot fix from 3.2
http://hg.python.org/cpython/rev/cb7e8ee489a1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15230>
_______________________________________

From report at bugs.python.org  Tue Jul 17 12:50:04 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Jul 2012 10:50:04 +0000
Subject: [issue15376] Refactor the create-package code in test_runpy into a
	helper module
In-Reply-To: <1342509049.53.0.303616016829.issue15376@psf.upfronthosting.co.za>
Message-ID: <1342522204.56.0.793606017775.issue15376@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

One trap to watch out for: it's best to call os.path.realpath() on any temporary directories created, since the interpreter tends to do that internally.

I'd previously dealt with this in script_helper.temp_dir, but it came up again when I tightened up the runpy.run_module tests to actually check that __file__ ended up with the expected value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15376>
_______________________________________

From report at bugs.python.org  Tue Jul 17 12:50:28 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 17 Jul 2012 10:50:28 +0000
Subject: [issue15377] os.path.join() error misleading with path1=None
In-Reply-To: <1342512718.53.0.395843871145.issue15377@psf.upfronthosting.co.za>
Message-ID: <1342522228.08.0.818816662746.issue15377@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Yeah, we talked about that exact think with Antoine on IRC. New proposal.

----------
Added file: http://bugs.python.org/file26415/nicer-error-for-none-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15377>
_______________________________________

From report at bugs.python.org  Tue Jul 17 12:54:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Jul 2012 10:54:25 +0000
Subject: [issue15377] os.path.join() error misleading with path1=None
In-Reply-To: <1342512718.53.0.395843871145.issue15377@psf.upfronthosting.co.za>
Message-ID: <1342522465.49.0.623820888569.issue15377@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Looks good to me

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15377>
_______________________________________

From report at bugs.python.org  Tue Jul 17 13:10:10 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Jul 2012 11:10:10 +0000
Subject: [issue15230] runpy.run_path doesn't set __package__ correctly
In-Reply-To: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>
Message-ID: <1342523410.16.0.320664963205.issue15230@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Closing again, since the OS X buildbot was happy with the change on 3.2. If trunk fails (which it shouldn't), that should be filed as a new issue (as it would almost certainly relate to the move from the pkgutil emulation to importlib).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15230>
_______________________________________

From report at bugs.python.org  Tue Jul 17 13:10:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Jul 2012 11:10:56 +0000
Subject: [issue15377] os.path.join() error misleading with path1=None
In-Reply-To: <1342512718.53.0.395843871145.issue15377@psf.upfronthosting.co.za>
Message-ID: <3WbzLl3LQmzPBM@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5553a53a230a by Hynek Schlawack in branch '3.2':
#15377: Make posixpath.join() more strict when checking for str/bytes mix
http://hg.python.org/cpython/rev/5553a53a230a

New changeset d087ef80372d by Hynek Schlawack in branch 'default':
#15377: Make posixpath.join() more strict when checking for str/bytes mix
http://hg.python.org/cpython/rev/d087ef80372d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15377>
_______________________________________

From report at bugs.python.org  Tue Jul 17 13:11:41 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 17 Jul 2012 11:11:41 +0000
Subject: [issue15377] os.path.join() error misleading with path1=None
In-Reply-To: <1342512718.53.0.395843871145.issue15377@psf.upfronthosting.co.za>
Message-ID: <1342523501.9.0.18530068769.issue15377@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Fine! :)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15377>
_______________________________________

From report at bugs.python.org  Tue Jul 17 13:25:42 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Jul 2012 11:25:42 +0000
Subject: [issue14988] _elementtree: Raise ImportError when importing of
	pyexpat fails
In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za>
Message-ID: <3Wbzgm3HvyzPLP@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d896fd0a8ba7 by Eli Bendersky in branch '3.2':
ISsue #14988: restore Python 2's behavior of raising ImportError when unable to load pyexpat, instead of a SystemError/RuntimeError
http://hg.python.org/cpython/rev/d896fd0a8ba7

New changeset c8774ff45733 by Eli Bendersky in branch 'default':
Merge for #14988
http://hg.python.org/cpython/rev/c8774ff45733

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14988>
_______________________________________

From report at bugs.python.org  Tue Jul 17 13:26:48 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 17 Jul 2012 11:26:48 +0000
Subject: [issue14988] _elementtree: Raise ImportError when importing of
	pyexpat fails
In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za>
Message-ID: <1342524408.03.0.771007241281.issue14988@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed fixes to raise ImportError in both Python 3.2 and 3.3

At the moment no test added because I'm having trouble using import_fresh_module to avoid re-importing of pyexpat in the etree tests (it gets imported anyway).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14988>
_______________________________________

From report at bugs.python.org  Tue Jul 17 13:36:03 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Jul 2012 11:36:03 +0000
Subject: [issue15379] Charmap decoding of no-BMP characters
In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za>
Message-ID: <1342524963.38.0.423447235636.issue15379@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Fixing for 3.2 and lesser is possible, but expensive, because of narrow build limitation. If necessary, I will give the patch, but it is easier to mark it as "wont fix" for pre-3.3 versions.

Here is a tests for charmap decoding. Tests added not only for this issue, but for all non-covered cases with int2str and int2str mappings.

----------
Added file: http://bugs.python.org/file26416/decode_charmap_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15379>
_______________________________________

From report at bugs.python.org  Tue Jul 17 13:38:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Jul 2012 11:38:59 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <3Wbzz54VdYzPLh@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 16e50e85d684 by Nick Coghlan in branch 'default':
Issue #15314: Tweak a pkgutil test to hopefully be more Windows friendly
http://hg.python.org/cpython/rev/16e50e85d684

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15314>
_______________________________________

From report at bugs.python.org  Tue Jul 17 13:40:18 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Jul 2012 11:40:18 +0000
Subject: [issue15373] copy.copy() does not properly copy os.environment
In-Reply-To: <1342454937.95.0.386630033182.issue15373@psf.upfronthosting.co.za>
Message-ID: <1342525218.91.0.263217139946.issue15373@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, I think the fact that os.environ.copy is explicitly supported (and does indeed do dict(os.environ)) is an argument in favor of giving that same meaning to copy(os.environ).  I think that follows the principle of least surprise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15373>
_______________________________________

From report at bugs.python.org  Tue Jul 17 13:43:36 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Jul 2012 11:43:36 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <1342525416.8.0.433204373054.issue15314@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, I just pushed a tweak to the test that will hopefully resolve the problem. If the tweak works, though, it does suggest we have a bit of weirdness in importlib: it means pkgutil.get_importer("") is returning an importer on POSIX systems, but None on Windows.

The test tweak to get OS X passing for #15230 on 3.2 (where it was already passing on trunk) suggests we may also have a case where 3.2 called os.path.realpath() before setting __file__, while 3.3 does not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15314>
_______________________________________

From report at bugs.python.org  Tue Jul 17 14:10:20 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Jul 2012 12:10:20 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <3Wc0gH2HpbzP36@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 51978f89e5ed by Eli Bendersky in branch 'default':
Optimize tostringlist by taking the stream class outside the function. It's now 2x faster on short calls. Related to #1767933
http://hg.python.org/cpython/rev/51978f89e5ed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Tue Jul 17 14:12:46 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 17 Jul 2012 12:12:46 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
Message-ID: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

>From this pydev thread: http://mail.python.org/pipermail/python-dev/2012-July/120981.html

"BytesIO is actually missing an optimisation that is already used in
StringIO: the StringIO C implementation uses a fragment accumulator
internally, and collapses that into a single string object when
getvalue() is called. BytesIO is still using the old
"resize-the-buffer-as-you-go" strategy, and thus ends up repeatedly
reallocating the buffer as the data sequence grows incrementally.

It should be optimised to work the same way StringIO does (which is
effectively the same way that the monkeypatched version works)"

----------
components: Library (Lib)
messages: 165715
nosy: eli.bendersky, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Optimize BytesIO to so less reallocations when written, similarly to StringIO
type: performance
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Tue Jul 17 14:38:23 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 17 Jul 2012 12:38:23 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342528703.43.0.378320329324.issue15381@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Tue Jul 17 14:49:10 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 17 Jul 2012 12:49:10 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342529350.66.0.728940106073.issue15381@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

This optimization for StringIO was done in issue #13149

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Tue Jul 17 15:02:40 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 17 Jul 2012 13:02:40 +0000
Subject: [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>
Message-ID: <1342530160.43.0.580671138049.issue15369@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I disagree. They are outdated benchmarks and probably should either be removed or left undocumented. Proper testing of performance is with the Unladen Swallow benchmarks.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15369>
_______________________________________

From report at bugs.python.org  Tue Jul 17 15:26:49 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Jul 2012 13:26:49 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342531609.27.0.26310866861.issue15381@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

I am not see that BytesIO is slower than StringIO (both are about 30% slower than append/join).

$ ./python -m timeit -s "import io; d=[b'a'*10,b'bb'*5,b'ccc'*5]*1000"  "b=[]; w=b.append"  "for x in d: w(x)"  "b''.join(b)"
1000 loops, best of 3: 966 usec per loop

$ ./python -m timeit -s "import io; d=['a'*10,'bb'*5,'ccc'*5]*1000"  "b=[]; w=b.append"  "for x in d: w(x)"  "''.join(b)"
1000 loops, best of 3: 918 usec per loop

$ ./python -m timeit -s "import io; d=[b'a'*10,b'bb'*5,b'ccc'*5]*1000"  "b=io.BytesIO(); w=b.write"  "for x in d: w(x)"  "b.getvalue()"
1000 loops, best of 3: 1.22 msec per loop

$ ./python -m timeit -s "import io; d=['a'*10,'bb'*5,'ccc'*5]*1000"  "b=io.StringIO(); w=b.write"  "for x in d: w(x)"  "b.getvalue()"
1000 loops, best of 3: 1.24 msec per loop

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Tue Jul 17 15:36:57 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 17 Jul 2012 13:36:57 +0000
Subject: [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342530160.43.0.580671138049.issue15369@psf.upfronthosting.co.za>
Message-ID: <50056A75.5040407@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Brett Cannon wrote:
> 
> Brett Cannon <brett at python.org> added the comment:
> 
> I disagree. They are outdated benchmarks and probably should either be removed or left undocumented. Proper testing of performance is with the Unladen Swallow benchmarks.

I disagree with your statement. Just like every benchmark, they serve
their purpose in their particular field of use, e.g. pybench may not
be useful for the JIT approach originally taken by the Unladden Swallow
project, but it's still useful to test/check changes in the non-JIT
CPython interpreter and it's extensible to take new developments
into account. pystone is useful to get a quick feel the performance
of Python on a machine.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15369>
_______________________________________

From report at bugs.python.org  Tue Jul 17 15:37:20 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 17 Jul 2012 13:37:20 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342532240.46.0.0647525007627.issue15364@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Updated patch which clarifies that for an installed python on a posix system, get_config_var('srcdir') == get_path('stdlib').

Eg, if sys.executable == '/usr/local/bin/python3.3' then get_config_var('srcdir') == '/usr/local/lib/python3.3'.

This is a little arbitrary, but seems as sensible a value as any other.  (Or maybe it would be better to have get_config_var('srcdir') == None instead.)

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26417/sysconf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Tue Jul 17 15:44:31 2012
From: report at bugs.python.org (John O'Connor)
Date: Tue, 17 Jul 2012 13:44:31 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342532671.06.0.815651881258.issue15381@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/issue15381>
_______________________________________

From report at bugs.python.org  Tue Jul 17 15:50:25 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 17 Jul 2012 13:50:25 +0000
Subject: [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>
Message-ID: <1342533025.73.0.137309811098.issue15369@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Actually, I discovered "python -m test.pystone" during the talk of Mike M?ller at EuroPython. http://is.gd/fasterpy

Even if they are suboptimal for true benchmarks, they should probably be mentioned somewhere.
In the same paragraph, there should be a link to the "Grand Unified Python Benchmark Suite" as best practice:

http://hg.python.org/benchmarks
http://hg.python.org/benchmarks/file/tip
http://hg.python.org/benchmarks/file/tip/README.txt

The last paragraph of this wiki page might be reworded and included in the Python documentation:
http://code.google.com/p/unladen-swallow/wiki/Benchmarks
http://code.google.com/p/unladen-swallow/wiki/Benchmarks#Benchmarks_we_don't_use



BTW, there's also this website which seems not updated anymore?
http://speed.python.org/

----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15369>
_______________________________________

From report at bugs.python.org  Tue Jul 17 15:51:19 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 17 Jul 2012 13:51:19 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342533079.11.0.0584260421009.issue15368@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

New patch that addresses feedback from Brett's code review (thanks!).

----------
Added file: http://bugs.python.org/file26418/issue15368-v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Tue Jul 17 16:33:57 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Jul 2012 14:33:57 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1342535637.57.0.640074642993.issue1767933@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

How about porting this to 3.2? The main difficulty I see with the tests, which significantly differ in 3.2 and 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Tue Jul 17 16:54:36 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 17 Jul 2012 14:54:36 +0000
Subject: [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>
Message-ID: <1342536876.39.0.516670862448.issue15369@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The Unladen Swallow benchmarks are in no way specific to JITs; it is a set of thorough benchmarks for measuring the overall performance of a Python VM.

As for speed.python.org, we know that it is currently not being updated as we are waiting for people to have the time to move it forward and replace speed.pypy.org for all Python VMs.

----------
nosy:  -jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15369>
_______________________________________

From report at bugs.python.org  Tue Jul 17 17:35:11 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 17 Jul 2012 15:35:11 +0000
Subject: [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342539311.43.0.159809876952.issue15151@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov.ml at gmail.com>:


----------
nosy:  -Yury.Selivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15151>
_______________________________________

From report at bugs.python.org  Tue Jul 17 18:34:10 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Jul 2012 16:34:10 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <3Wc6Wj06pZzPJd@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b79d276041a8 by Vinay Sajip in branch 'default':
Closes #15307: symlinks now work on  OS X with framework Python builds. Patch by Ronald Oussoren.
http://hg.python.org/cpython/rev/b79d276041a8

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Tue Jul 17 19:12:24 2012
From: report at bugs.python.org (Christopher the Magnificent)
Date: Tue, 17 Jul 2012 17:12:24 +0000
Subject: [issue15343] "pydoc -w <package>" writes out page with empty "Package
	Contents" section
In-Reply-To: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>
Message-ID: <1342545144.88.0.813023975426.issue15343@psf.upfronthosting.co.za>


Christopher the Magnificent <ultimate.mac.fanatic at gmail.com> added the comment:

ISSUE CONFIRMED FIXED ON MY END, AND MANY THANKS

I downloaded, compiled, and installed the latest Python 3.3 beta on my machine with Mercurial, and can confirm that the problem is no longer presenting itself.

Thank you and great job to you smart people that know the guts of Python and its libraries, who coordinated and coded to get this fixed, especially Mr. Nick Coghlan, who it appears took on the responsibility for resolving this.  My hat is off to you all!

--Christopher

P. S.  I'm fairly new to the bug forums.  If anyone is bothered that I wrote this after the issue closed, just let me know what the policy is so I can learn to adapt to it.  If no one complains, I will assume it was okay in this instance.  :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15343>
_______________________________________

From report at bugs.python.org  Tue Jul 17 20:08:10 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 17 Jul 2012 18:08:10 +0000
Subject: [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342548490.82.0.57969536559.issue15151@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov.ml at gmail.com> added the comment:

The new patch version (inspect.pep362.2.patch) includes more examples and includes recommendations to use the Signature Object instead of 'inspect.getfullargsspec'.  Please review.

----------
Added file: http://bugs.python.org/file26419/inspect.pep362.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15151>
_______________________________________

From report at bugs.python.org  Tue Jul 17 20:48:35 2012
From: report at bugs.python.org (=?utf-8?q?Ilpo_Nyyss=C3=B6nen?=)
Date: Tue, 17 Jul 2012 18:48:35 +0000
Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding
	exception
In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za>
Message-ID: <1342550915.56.0.620065381609.issue15109@psf.upfronthosting.co.za>


Changes by Ilpo Nyyss?nen <iny at iki.fi>:


----------
nosy: +biny

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15109>
_______________________________________

From report at bugs.python.org  Tue Jul 17 22:02:28 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 17 Jul 2012 20:02:28 +0000
Subject: [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342555348.42.0.578378487204.issue15151@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov.ml at gmail.com> added the comment:

New patch version - inspect.pep362.3.patch

I decided to put the new doc section above the "Classes and functions". The new section is now called "Introspecting callables with Signature Object".  Aside from that everything is the same as in the 2nd patch.

----------
Added file: http://bugs.python.org/file26420/inspect.pep362.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15151>
_______________________________________

From report at bugs.python.org  Tue Jul 17 22:36:41 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Jul 2012 20:36:41 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342557401.79.0.922992561506.issue15364@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

> This is a little arbitrary, but seems as sensible a value as any other.
> (Or maybe it would be better to have get_config_var('srcdir') == None
> instead.)

'srcdir' is problematic for any installed build.  Once "make install" has been performed, there is no obligation to keep the original source and build dirs around anymore.  For Pythons installed on other machines via a binary installer, like the python.org OS X ones, some of the paths returned by sysconfig are not meaningful on the installed machine.  For an OS X framework build, the Makefile and friends are copied into a 'config' directory that is created within the installed framework. So, with the patch, the contents of that directory (returned by the patched 'srcdir' value) is:
['Makefile',
 'Setup',
 'Setup.config',
 'Setup.local',
 'config.c',
 'config.c.in',
 'install-sh',
 'libpython3.3.a',
 'libpython3.3.dylib',
 'makesetup',
 'python.o']

Is that a meaningful surrogate for the build 'srcdir'?

Beyond that, I don't understand why the patch behavior depends on whether the srcdir is an absolute path or not.  I often use absolute paths to configure a build.  If not in a build directory, 'srcdir' should always return either the proposed value based on what get_makefile_filename() returns or it should return None.  I don't have a strong opinion at the moment about which.  One factor should be an inspection and running of all of the tests.  A quick grep of Lib/ didn't find many references to 'srcdir'.

One other point: distutils still has its own copy of sysconfig.  Strong consideration should be given to making a similar change there.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Tue Jul 17 22:44:37 2012
From: report at bugs.python.org (Mikhail Korobov)
Date: Tue, 17 Jul 2012 20:44:37 +0000
Subject: [issue15027] Faster UTF-32 encoding
In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za>
Message-ID: <1342557877.15.0.199585871441.issue15027@psf.upfronthosting.co.za>


Changes by Mikhail Korobov <kmike84 at gmail.com>:


----------
nosy: +kmike

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15027>
_______________________________________

From report at bugs.python.org  Tue Jul 17 23:02:38 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 17 Jul 2012 21:02:38 +0000
Subject: [issue15382] os.utime() mishandles some arguments
Message-ID: <1342558958.87.0.656849983066.issue15382@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Contrarily to documentation:

1. os.utime() accepts a tuple with floats passed by ns argument:
>>> os.utime(file, ns=(0.5, 0.5))
>>>

2. os.utime() does not accept explicit ns=None:
>>> os.utime(file, times=None)
>>> os.utime(file, ns=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: utime: 'ns' must be a tuple of two ints
>>>

3. os.utime() does not accept both times and ns when only times is a tuple:
>>> os.utime(file, times=None, ns=(0, 0))
>>> os.utime(file, times=(0, 0), ns=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: utime: you may specify either 'times' or 'ns' but not both
>>>

----------
messages: 165730
nosy: Arfrever, haypo, larry
priority: normal
severity: normal
status: open
title: os.utime() mishandles some arguments
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15382>
_______________________________________

From report at bugs.python.org  Tue Jul 17 23:27:10 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 17 Jul 2012 21:27:10 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342560430.54.0.968185084468.issue15381@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/issue15381>
_______________________________________

From report at bugs.python.org  Tue Jul 17 23:49:51 2012
From: report at bugs.python.org (David Lam)
Date: Tue, 17 Jul 2012 21:49:51 +0000
Subject: [issue11176] give more meaningful argument names in argparse
	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1342561791.33.0.432891402333.issue11176@psf.upfronthosting.co.za>


David Lam <d at dlam.me> added the comment:

yup yup, go for it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Wed Jul 18 00:23:43 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 17 Jul 2012 22:23:43 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342563823.32.0.678498290472.issue15368@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

OK, I ran the Python benchmark suite.  I don't have much experience with the benchmark suite so let me know if I did something wrong or need to do more.  I ran the following:

python perf.py -b 2n3 ../cpython/python.exe ../cpython/python-with-sorting.exe)

which produces:

Report on Darwin quicksilver 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64 i386
Total CPU cores: 4

### call_method_slots ###
Min: 1.925941 -> 1.883251: 1.02x faster
Avg: 1.931082 -> 1.887380: 1.02x faster
Significant (t=39.92)
Stddev: 0.01233 -> 0.00526: 2.3439x smaller
Timeline: http://tinyurl.com/8943trh

### call_simple ###
Min: 1.447890 -> 1.367729: 1.06x faster
Avg: 1.451100 -> 1.371689: 1.06x faster
Significant (t=118.46)
Stddev: 0.00497 -> 0.00654: 1.3168x larger
Timeline: http://tinyurl.com/7j7uppg

### fastpickle ###
Min: 3.313799 -> 3.240090: 1.02x faster
Avg: 3.328812 -> 3.248734: 1.02x faster
Significant (t=44.45)
Stddev: 0.00918 -> 0.00883: 1.0404x smaller
Timeline: http://tinyurl.com/6tsk347

### iterative_count ###
Min: 1.277516 -> 1.240536: 1.03x faster
Avg: 1.280186 -> 1.242743: 1.03x faster
Significant (t=38.46)
Stddev: 0.00534 -> 0.00435: 1.2288x smaller
Timeline: http://tinyurl.com/d7vzqjf

### json_load ###
Min: 2.944439 -> 2.877168: 1.02x faster
Avg: 2.950717 -> 2.889950: 1.02x faster
Significant (t=23.96)
Stddev: 0.00737 -> 0.01635: 2.2179x larger
Timeline: http://tinyurl.com/6onbxzf

### regex_compile ###
Min: 2.354580 -> 2.417407: 1.03x slower
Avg: 2.361253 -> 2.421576: 1.03x slower
Significant (t=-44.01)
Stddev: 0.00780 -> 0.00575: 1.3555x smaller
Timeline: http://tinyurl.com/6wryn9v

### richards ###
Min: 0.905023 -> 0.883842: 1.02x faster
Avg: 0.908634 -> 0.888653: 1.02x faster
Significant (t=18.96)
Stddev: 0.00479 -> 0.00571: 1.1911x larger
Timeline: http://tinyurl.com/chgz4ge

### silent_logging ###
Min: 0.432982 -> 0.462848: 1.07x slower
Avg: 0.434553 -> 0.465406: 1.07x slower
Significant (t=-32.15)
Stddev: 0.00390 -> 0.00556: 1.4256x larger
Timeline: http://tinyurl.com/d3penzy

The following not significant results are hidden, use -v to show them:
call_method, call_method_unknown, fastunpickle, float, formatted_logging, json_dump, nbody, normal_startup, nqueens, pidigits, regex_effbot, regex_v8, simple_logging, startup_nosite, threaded_count, unpack_sequence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 01:08:24 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 17 Jul 2012 23:08:24 +0000
Subject: [issue15382] os.utime() mishandles some arguments
In-Reply-To: <1342558958.87.0.656849983066.issue15382@psf.upfronthosting.co.za>
Message-ID: <1342566504.86.0.213766913379.issue15382@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Attached is a preliminary patch to check ns != Py_None.

----------
components: +Library (Lib)
keywords: +patch
nosy: +serwy
type:  -> behavior
Added file: http://bugs.python.org/file26421/issue15382.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15382>
_______________________________________

From report at bugs.python.org  Wed Jul 18 01:10:39 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Jul 2012 23:10:39 +0000
Subject: [issue15382] os.utime() mishandles some arguments
In-Reply-To: <1342558958.87.0.656849983066.issue15382@psf.upfronthosting.co.za>
Message-ID: <1342566639.71.0.742790468883.issue15382@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

@serwy: can you please write a test for your patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15382>
_______________________________________

From report at bugs.python.org  Wed Jul 18 01:13:44 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 17 Jul 2012 23:13:44 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342566824.06.0.953561917143.issue15364@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

> Beyond that, I don't understand why the patch behavior depends on 
> whether the srcdir is an absolute path or not.

The os.path.isabs() test is actually redundant since os.path.join(base, srcdir) == srcdir if srcdir is an absolute path.  I only added that test to be explicit about what happens if the original value is an absolute path. 

> I often use absolute paths to configure a build.  If not in a build 
> directory, 'srcdir' should always return either the proposed value 
> based on what get_makefile_filename() returns or it should return 
> None.

Removing the isabs() test would not change the calculated value as I indicated above.

Using None would be the sanest option, but I don't know if any current code depends on the value being a string.

> One other point: distutils still has its own copy of sysconfig.  
> Strong consideration should be given to making a similar change there.

For a source build, distutils.sysconfig.get_config_var('srcdir') gives the right answer as an absolute path, *except* when the current working directory contains sys.executable.  I think it should always return an absolute path.  The fact that currently it does not probably explains the "mysteriously" comment below from distutils/test/support.py:

def _get_xxmodule_path():
    srcdir = sysconfig.get_config_var('srcdir')
    candidates = [
        # use installed copy if available
        os.path.join(os.path.dirname(__file__), 'xxmodule.c'),
        # otherwise try using copy from build directory
        os.path.join(srcdir, 'Modules', 'xxmodule.c'),
        # srcdir mysteriously can be $srcdir/Lib/distutils/tests when
        # this file is run from its parent directory, so walk up the
        # tree to find the real srcdir
        os.path.join(srcdir, '..', '..', '..', 'Modules', 'xxmodule.c'),
    ]
    for path in candidates:
        if os.path.exists(path):
            return path

BTW, I was wrong in my earlier message when I claimed that srcdir == get_path('stdlib') for an installed python.  That is only true if the relative srcdir is '..'.  The attached patch removes that check from the unit tests.

----------
Added file: http://bugs.python.org/file26422/sysconf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Wed Jul 18 01:19:45 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 17 Jul 2012 23:19:45 +0000
Subject: [issue15382] os.utime() mishandles some arguments
In-Reply-To: <1342558958.87.0.656849983066.issue15382@psf.upfronthosting.co.za>
Message-ID: <1342567185.38.0.339632631742.issue15382@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

_rev1 has a basic test. Is it sufficient?

----------
Added file: http://bugs.python.org/file26423/issue15382_rev1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15382>
_______________________________________

From report at bugs.python.org  Wed Jul 18 02:03:45 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 Jul 2012 00:03:45 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342569825.85.0.523299655384.issue15364@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Upon further consideration, while it sounds appealing, perhaps returning None is not the better choice. As far as I know, up until now all config vars are either of type str or type int.  Adding None to the mix might be asking for trouble.

With no patch, running from an installed framework build:
>>> sys.executable
'/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/bin/python3.3'
>>> import sysconfig as sc, distutils.sysconfig as dsc
>>> sc.is_python_build()
False
>>> sc.get_config_var('srcdir')
'/py/dev/default/b10.7_t10.7_x4.3_cclang_d'
>>> dsc.get_config_var('srcdir')
'.'

With the latest patch, as above:
>>> sys.executable
'/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/bin/python3.3'
>>> import sysconfig as sc, distutils.sysconfig as dsc
>>> sc.is_python_build()
False
>>> sc.get_config_var('srcdir')
'/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/3.3/lib/python3.3/config-3.3dm'
>>> dsc.get_config_var('srcdir')
'.'

The patched results looks OK except, of course, for the discrepancy with distutils.sysconfig.  I think we should fix that and get this all into 3.3.0.  Otherwise we'll be stuck with the current broken behavior until 3.4 at the earliest.

One nit comment on the currrent patch: s/"will not effect it"/"will not affect it" (one of those gotchas in English).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Wed Jul 18 02:15:09 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 Jul 2012 00:15:09 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342570509.09.0.695478031083.issue15364@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I should have noted that, in the above tests, distutils.sysconfig.get_makefile_filename() is already doing the right thing:

>>> dsc.get_makefile_filename()
'/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/3.3/lib/python3.3/config-3.3dm/Makefile'
[70312 refs]
>>> sc.get_makefile_filename() == dsc.get_makefile_filename()
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Wed Jul 18 02:30:30 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 18 Jul 2012 00:30:30 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342571430.15.0.720414812278.issue15364@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agree on fixing this for 3.3, if it?s not possible to backport to all stable branches.  Will review.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Wed Jul 18 04:32:41 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 18 Jul 2012 02:32:41 +0000
Subject: [issue14513] IDLE icon switched and switches on Windows taskbar
In-Reply-To: <1333654492.57.0.20461784389.issue14513@psf.upfronthosting.co.za>
Message-ID: <1342578761.52.0.872702661043.issue14513@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
components: +IDLE -Installation, Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14513>
_______________________________________

From report at bugs.python.org  Wed Jul 18 04:33:32 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 18 Jul 2012 02:33:32 +0000
Subject: [issue14513] IDLE icon switched and switches on Windows taskbar
In-Reply-To: <1333654492.57.0.20461784389.issue14513@psf.upfronthosting.co.za>
Message-ID: <1342578812.95.0.554344447152.issue14513@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14513>
_______________________________________

From report at bugs.python.org  Wed Jul 18 06:59:33 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 18 Jul 2012 04:59:33 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1342587573.37.0.351834057159.issue1767933@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Frankly, I don't think the problem is serious enough to warrant a backport to 3.2, given that 3.3 gonna be out in a few weeks. The issue was open for 5 years without anyone seriously complaining :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Wed Jul 18 07:08:42 2012
From: report at bugs.python.org (Tyler Crompton)
Date: Wed, 18 Jul 2012 05:08:42 +0000
Subject: [issue15383] Autocompletion crashes Python if the __builtins__ module
	cannot be found.
Message-ID: <1342588122.88.0.602543010606.issue15383@psf.upfronthosting.co.za>


New submission from Tyler Crompton <gtr053 at gmail.com>:

Doing one of the following crashes Python.

    del __builtins__
    a{Tab}

or

    builtins = __builtins__
    del __builtins__
    a{Tab}

If you do a print screen, immediately, you will see the following error:

    *** Internal Error: rpc.py:SocketIO.localcall()

     Object: exec
     Method: <bound method Executive.get_the_completion_list of <idlelib.run.Executive object at 0x0000000002DC2710>>
     Args: ('', 1)

    Traceback (most recent call last):
      File "C:\Python32\lib\idlelib\rpc.py", line 188, in localcall
        ret = method(*args, **kwargs)
      File "C:\Python32\lib\idlelib\run.py", line 327, in get_the_completion_list
        return self.autocomplete.fetch_completions(what, mode)
      File "C:\Python32\lib\idlelib\AutoComplete.py", line 189, in fetch_completions
        namespace.update(__main__.__builtins__.__dict__)
AttributeError: 'module' object has no attribute '__builtins__'

Additionally, when __builtins__ is deleted (in IDLE), __builtins__ becomes a dictionary. If one were to then do __builtins__.clear(), the interpreter stops all interpreting. IDLE moreorless becomes a text editor with syntax highlighting. If you try to use autocomplete, Python hangs before crashing.

I realize that doing such is pointless, but it behaves differently than interactive console interpreters. Interactive console interpreters don't convert __builtins__ to a dictionary upon its deletion. I feel that this error can be handled to prevent crashing.

----------
components: IDLE
messages: 165741
nosy: Tyler.Crompton
priority: normal
severity: normal
status: open
title: Autocompletion crashes Python if the __builtins__ module cannot be found.
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15383>
_______________________________________

From report at bugs.python.org  Wed Jul 18 07:28:41 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 18 Jul 2012 05:28:41 +0000
Subject: [issue14513] IDLE icon switched and switches on Windows taskbar
In-Reply-To: <1333654492.57.0.20461784389.issue14513@psf.upfronthosting.co.za>
Message-ID: <1342589321.25.0.610064572708.issue14513@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

With 3.3.0b1 amd64, I can pin IDLE to the taskbar with the appropriate icon (white page with Python logo). When I unpin IDLE with an editor window focused, the icon becomes the Tk logo. However, re-pinning the app brings back the other icon.

Terry, can you verify that the latest builds work?

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14513>
_______________________________________

From report at bugs.python.org  Wed Jul 18 07:29:23 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jul 2012 05:29:23 +0000
Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after
	error handling
In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za>
Message-ID: <1342589363.86.0.550302017335.issue14579@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Please, can anyone do a final review and commit?

Here are three patches for three Python versions:

2.7: utf16_error_handling-2.7.patch. Fix for one minor bug (overreading) and tests.

3.2: utf16_error_handling-3.2_4.patch. Fix for one critical security bug (CVE-2012-2135) and several minor bugs, tests.

3.3: utf16_error_handling-3.3.patch. Only tests.

----------
Added file: http://bugs.python.org/file26424/utf16_error_handling_tests-3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14579>
_______________________________________

From report at bugs.python.org  Wed Jul 18 07:33:32 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jul 2012 05:33:32 +0000
Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after
	error handling
In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za>
Message-ID: <1342589612.06.0.284188771582.issue14579@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Interpreter Core, Unicode
versions: +Python 2.7 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14579>
_______________________________________

From report at bugs.python.org  Wed Jul 18 08:17:47 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jul 2012 06:17:47 +0000
Subject: [issue14973] restore python2 unicode literals in "ur" strings
In-Reply-To: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za>
Message-ID: <1342592267.54.0.00789363829189.issue14973@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Should it be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14973>
_______________________________________

From report at bugs.python.org  Wed Jul 18 08:19:07 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jul 2012 06:19:07 +0000
Subject: [issue15092] Using enum PyUnicode_Kind
In-Reply-To: <1339924867.59.0.117831113894.issue15092@psf.upfronthosting.co.za>
Message-ID: <1342592347.85.0.321147368898.issue15092@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Please, can anyone do the review of this large but trivial patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15092>
_______________________________________

From report at bugs.python.org  Wed Jul 18 08:49:35 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jul 2012 06:49:35 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1342594175.2.0.500476508965.issue1767933@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Python 3.2 currently shipped in last Ubuntu LTS and will be in production at least next 5 years. I think it will be main Python version for many years.

Here is a compound patch (changesets 6120cf695574, 64ff90e07d71, 51978f89e5ed and 63ba0c32b81a) for Python 3.2 without tests. It is almost same as for 3.3, except using manual finalizing instead ExitStack.

----------
Added file: http://bugs.python.org/file26425/etree_write_utf16_without_tests-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767933>
_______________________________________

From report at bugs.python.org  Wed Jul 18 10:09:36 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 18 Jul 2012 08:09:36 +0000
Subject: [issue14513] IDLE icon switched and switches on Windows taskbar
In-Reply-To: <1333654492.57.0.20461784389.issue14513@psf.upfronthosting.co.za>
Message-ID: <1342598976.71.0.839000199161.issue14513@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In the next alpha release, everything was fine and I though about closing this. When I first installed b1, the problem came back. But in a few days, 3.3.0b1 started working right. I did two things since to my installed idlelib, beside just using it. First was my last 12510 calltips push July 9. Second was Ned's 4832 .py default extension patch about the 12th. I plan to watch more carefully is there is a problem after the next b2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14513>
_______________________________________

From report at bugs.python.org  Wed Jul 18 11:32:43 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 18 Jul 2012 09:32:43 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342603963.23.0.290949025848.issue15381@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I wonder if this is a fair comparison, Serhiy. Strings are unicode underneath, so they have a large overhead per string (more data to copy around). Increasing the length of the strings changes the game because due to PEP 393, the overhead for ASCII-only Unicode strings is constant:

>>> import sys
>>> sys.getsizeof('a')
50
>>> sys.getsizeof(b'a')
34
>>> sys.getsizeof('a' * 1000)
1049
>>> sys.getsizeof(b'a' * 1000)
1033
>>> 

When re-running your tests with larger chunks, the results are quite interesting:

$ ./python -m timeit -s "import io; d=[b'a'*100,b'bb'*50,b'ccc'*50]*1000"  "b=io.BytesIO(); w=b.write"  "for x in d: w(x)"  "b.getvalue()"
1000 loops, best of 3: 509 usec per loop
$ ./python -m timeit -s "import io; d=['a'*100,'bb'*50,'ccc'*50]*1000"  "s=io.StringIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
1000 loops, best of 3: 282 usec per loop

So, it seems to me that BytesIO could use some optimization!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Wed Jul 18 11:36:21 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 18 Jul 2012 09:36:21 +0000
Subject: [issue15171] Fix 64-bit building for buildbot scripts (3.2)
In-Reply-To: <1340569808.6.0.680025468258.issue15171@psf.upfronthosting.co.za>
Message-ID: <1342604181.5.0.330349070699.issue15171@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Thanks, David! I'll close this issue, perhaps the compile failures
on the Windows 7 buildbot can be sorted out separately.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15171>
_______________________________________

From report at bugs.python.org  Wed Jul 18 12:09:58 2012
From: report at bugs.python.org (Timothy Madden)
Date: Wed, 18 Jul 2012 10:09:58 +0000
Subject: [issue14458] Non-admin installation fails
In-Reply-To: <1333198651.39.0.792037554974.issue14458@psf.upfronthosting.co.za>
Message-ID: <1342606198.64.0.266415631726.issue14458@psf.upfronthosting.co.za>


Timothy Madden <terminatorul at gmail.com> added the comment:

The command also worked for me on Windows 7 Professional 64-bit, but pythonw does not start, and I could not check if everything in CLI python.exe works as expected.

As you said, something is not right with it, and it also installs just too fast for a real installation.

It did get my python installed, though. Thank you for the info, you must have played with it quite a while

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14458>
_______________________________________

From report at bugs.python.org  Wed Jul 18 12:26:06 2012
From: report at bugs.python.org (Juan Javier)
Date: Wed, 18 Jul 2012 10:26:06 +0000
Subject: [issue13785] Make concurrent.futures.Future state public
In-Reply-To: <1326560835.55.0.282912980665.issue13785@psf.upfronthosting.co.za>
Message-ID: <1342607166.42.0.496612275143.issue13785@psf.upfronthosting.co.za>


Changes by Juan Javier <jjdominguezm at gmail.com>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13785>
_______________________________________

From report at bugs.python.org  Wed Jul 18 12:33:30 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 Jul 2012 10:33:30 +0000
Subject: [issue15092] Using enum PyUnicode_Kind
In-Reply-To: <1339924867.59.0.117831113894.issue15092@psf.upfronthosting.co.za>
Message-ID: <1342607610.75.0.809390177839.issue15092@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I'd strongly prefer not having "enum" everywhere.  "PyUnicode_Kind" alone is certainly possible, maybe with a typedef?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15092>
_______________________________________

From report at bugs.python.org  Wed Jul 18 12:46:03 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 10:46:03 +0000
Subject: [issue15384] FileFinder.path_hook()("") returns None on Windows
Message-ID: <1342608363.39.0.672383016327.issue15384@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As noted in #15314, one of the pkgutil tests was failing on Windows because pkgutil.get_importer("") was returning None. On my Fedora system it returns FileFinder(".").

I've now tweaked that particular test to use a bogus path string so that None is the expected result on all platforms.

However, the cross-platform discrepancy is a little disturbing - I would have expected the operation to either fail or succeed regardless of platform.

Since pkgutil.get_importer is now just a wrapper that takes care of checking path_importer_cache and then walking sys.path_hooks, I believe the actual culprit is FileFinder.path_hook()("") returning None (I'm currently downloading and installing 3.3b1 on my gaming machine to confirm that)

----------
components: Library (Lib)
messages: 165752
nosy: brett.cannon, georg.brandl, ncoghlan
priority: normal
severity: normal
status: open
title: FileFinder.path_hook()("") returns None on Windows
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15384>
_______________________________________

From report at bugs.python.org  Wed Jul 18 12:48:43 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 10:48:43 +0000
Subject: [issue15384] FileFinder.path_hook()("") returns None on Windows
In-Reply-To: <1342608363.39.0.672383016327.issue15384@psf.upfronthosting.co.za>
Message-ID: <1342608523.26.0.67928848756.issue15384@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15384>
_______________________________________

From report at bugs.python.org  Wed Jul 18 13:02:20 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 Jul 2012 11:02:20 +0000
Subject: [issue15379] Charmap decoding of no-BMP characters
In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za>
Message-ID: <1342609340.13.0.534569661266.issue15379@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

In 3.2, narrow build is also broken when the "charmap" is a string:
>>> codecs.charmap_decode(b'\0', 'strict', '\U0002000B')
returns ('?', 1) with a wide unicode build, but ('\ud840', 1) with a narrow build.

3.2 could be fixed to allow characters up to sys.maxunicode, though.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15379>
_______________________________________

From report at bugs.python.org  Wed Jul 18 13:12:06 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 11:12:06 +0000
Subject: [issue15385] Behaviour change in runpy for __file__ attributes
	between 3.2 and 3.3
Message-ID: <1342609926.32.0.323615194944.issue15385@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Directory setup: linkdir is a symlink to realdir

$ python3 -c "import sys; sys.path.insert(0, 'linkdir'); import runpy; print(runpy.run_module('foo')['__file__'])"
/home/ncoghlan/devel/play/realdir/foo.py
$ ../py3k/python -c "import sys; sys.path.insert(0, 'linkdir'); import runpy; print(runpy.run_module('foo')['__file__'])"
/home/ncoghlan/devel/play/linkdir/foo.py

The culprit is pkgutil - the import emulation includes a realpath() call. Looking at the log, this dates from PJE's consolidation of the various import emulations back in 2006, with no specific rationale given.

Since this was only in the emulation, and nothing else broke when we took it out (indeed, it was the cause of test failures in 3.2, when it altered the __file__ values in ways the test wasn't expecting), I'm just creating and closing this issue to note that yes, I'm aware this has changed, but no, I don't consider it a problem, as it just brings pkgutil into line with the behaviour of normal imports.

----------
messages: 165754
nosy: brett.cannon, georg.brandl, ncoghlan
priority: normal
severity: normal
status: open
title: Behaviour change in runpy for __file__ attributes between 3.2 and 3.3
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15385>
_______________________________________

From report at bugs.python.org  Wed Jul 18 13:12:59 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 11:12:59 +0000
Subject: [issue15385] Behaviour change in runpy for __file__ attributes
	between 3.2 and 3.3
In-Reply-To: <1342609926.32.0.323615194944.issue15385@psf.upfronthosting.co.za>
Message-ID: <1342609979.78.0.33283537368.issue15385@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15385>
_______________________________________

From report at bugs.python.org  Wed Jul 18 13:13:00 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Jul 2012 11:13:00 +0000
Subject: [issue15383] Autocompletion crashes Python if the __builtins__ module
	cannot be found.
In-Reply-To: <1342588122.88.0.602543010606.issue15383@psf.upfronthosting.co.za>
Message-ID: <1342609980.78.0.453644841698.issue15383@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is the same as issue 15113.  If you delete __builtins__, don't expect Python to work.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> IDLE Shell: delattr(__builtins__,"getattr") causes shell to stop working
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15383>
_______________________________________

From report at bugs.python.org  Wed Jul 18 13:15:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 11:15:25 +0000
Subject: [issue15314] Use importlib instead of pkgutil in runpy
In-Reply-To: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>
Message-ID: <1342610125.99.0.164434996265.issue15314@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Buildbots are green (at least as far as this issue goes), so closing again.

I created #15384 for the surprising behaviour of FileFinder on Windows.

#15385 records my investigation into the odd symlink behaviour on 3.2 (it was just a discrepancy between the emulation in pkgutil and the real import system)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15314>
_______________________________________

From report at bugs.python.org  Wed Jul 18 13:17:53 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 18 Jul 2012 11:17:53 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1342610273.7.0.739532717806.issue10399@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/issue10399>
_______________________________________

From report at bugs.python.org  Wed Jul 18 13:31:34 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 11:31:34 +0000
Subject: [issue15386] Still getting two copies of importlib._boostrap
Message-ID: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I haven't worked out how yet, but importlib.machinery is managing to bypass the replacement of importlib._bootstrap with _frozen_importlib:

Python 3.3.0b1 (default:8bf691d0b004+, Jul 15 2012, 23:20:06) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import importlib._bootstrap
[74500 refs]
>>> import importlib.machinery
[74500 refs]
>>> importlib.machinery.FileFinder
<class 'importlib._bootstrap.FileFinder'>
[74505 refs]
>>> importlib._bootstrap.FileFinder
<class '_frozen_importlib.FileFinder'>
[74505 refs]
>>> importlib.machinery.FileFinder.path_hook()("")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ncoghlan/devel/py3k/Lib/importlib/_bootstrap.py", line 1350, in path_hook_for_FileFinder
    if not _path_isdir(path):
  File "/home/ncoghlan/devel/py3k/Lib/importlib/_bootstrap.py", line 117, in _path_isdir
    path = _os.getcwd()
NameError: global name '_os' is not defined
[74566 refs]
>>> importlib._bootstrap.FileFinder.path_hook()("")
FileFinder('.')

----------
messages: 165757
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Still getting two copies of importlib._boostrap

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15386>
_______________________________________

From report at bugs.python.org  Wed Jul 18 13:31:42 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 11:31:42 +0000
Subject: [issue15386] Still getting two copies of importlib._bootstrap
In-Reply-To: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>
Message-ID: <1342611102.45.0.252421886581.issue15386@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: Still getting two copies of importlib._boostrap -> Still getting two copies of importlib._bootstrap

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15386>
_______________________________________

From report at bugs.python.org  Wed Jul 18 13:50:27 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 11:50:27 +0000
Subject: [issue15384] pkgutil.get_importer("") was returning None on Windows
	buildbots
In-Reply-To: <1342608363.39.0.672383016327.issue15384@psf.upfronthosting.co.za>
Message-ID: <1342612227.31.0.640210766594.issue15384@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Well, that's weird. A manual test on my Windows 7 gaming rig indicates that the old test *should* have worked on Windows as well.

I have no idea how to investigate this further. David, are you able to check what pkgutil.get_importer("") returns when running locally on your Windows buildbots?


An example of the error the buildbots were getting: http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/5450/steps/test/logs/stdio

----------
nosy: +db3l
title: FileFinder.path_hook()("") returns None on Windows -> pkgutil.get_importer("") was returning None on Windows buildbots

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15384>
_______________________________________

From report at bugs.python.org  Wed Jul 18 13:56:13 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 11:56:13 +0000
Subject: [issue15387] pkgutil.walk_packages is using a deprecated API
Message-ID: <1342612573.81.0.647626142545.issue15387@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

$ ./python -Wdefault
Python 3.3.0b1 (default:8bf691d0b004+, Jul 15 2012, 23:20:06) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkgutil
>>> list(pkgutil.walk_packages("."))
/home/ncoghlan/devel/py3k/Lib/inspect.py:453: DeprecationWarning: inspect.getmoduleinfo() is deprecated
  info = getmoduleinfo(path)
/home/ncoghlan/devel/py3k/Lib/inspect.py:445: DeprecationWarning: imp.get_suffixes() is deprecated; use the constants defined on importlib.machinery instead
  for suffix, mode, mtype in imp.get_suffixes()]
[(FileFinder('.'), 'foo', False), (FileFinder('.'), 'python-gdb', False), (FileFinder('.'), 'setup', False)]

The problem is the calls to inspect.getmodulename().

Do these APIs really need to be deprecated? Can't they just be redirected to importlib instead?

----------
components: Library (Lib)
messages: 165759
nosy: brett.cannon, georg.brandl, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: pkgutil.walk_packages is using a deprecated API
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15387>
_______________________________________

From report at bugs.python.org  Wed Jul 18 13:58:41 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 18 Jul 2012 11:58:41 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342612721.73.0.0747592138318.issue15381@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I'd like to take a shot at this, if Antoine doesn't mind. I'll prepare a patch for bytesio.c

Question: what set of benchmarks would it be good to run to make sure this doesn't degrade the performance of BytesIO in various cases?

----------
assignee:  -> eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Wed Jul 18 14:21:54 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 18 Jul 2012 12:21:54 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342614114.92.0.273427625137.issue15364@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Here is an updated patch which also modifies distutils.sysconfig.

For "installed" pythons on posix systems it makes

    get_config_var('srcdir') == os.path.dirname(get_makefile_filename())

(The older patches would give the same result only if the relative srcdir was '.')

----------
Added file: http://bugs.python.org/file26426/sysconf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Wed Jul 18 14:28:38 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 18 Jul 2012 12:28:38 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342614518.87.0.32941927947.issue15364@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Forgot to remove some unnecessary code in patch.

----------
Added file: http://bugs.python.org/file26427/sysconf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Wed Jul 18 14:30:59 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 18 Jul 2012 12:30:59 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342614659.4.0.578708268013.issue15364@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'd make get_config_var('srcdir') to be None for installed systems, because the source tree is not available there.

The advantage of making the value None is that this is easy to test for and would quickly break path manipulation code that tries to construct a path to a specific file in the source tree.  

Making the value to be the name of the directory containing Makefile would still break code that tries to access files relative to the source tree, but could that breakage could be harder to track.

BTW. sysconfig really needs a better description of which variables are supposed to be available, it currently exports every definition in the Makefile and pyconfig.h, and not all of those definitions are usable outside of CPython's build process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Wed Jul 18 14:40:52 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 18 Jul 2012 12:40:52 +0000
Subject: [issue15307] Patch for --symlink support in pyvenv with framework
	python
In-Reply-To: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
Message-ID: <1342615252.46.0.588246827627.issue15307@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

There is no NEWS entry, I'll commit one when I get home.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15307>
_______________________________________

From report at bugs.python.org  Wed Jul 18 14:53:14 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Jul 2012 12:53:14 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342615994.82.0.0370791784185.issue15368@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

You ran the benchmarks correctly, but I was more worried about compilation time than execution time (changing which index is for what really shouldn't make a difference in performance, and the benchmarks show that). If you want to test using the importlib benchmarks, run ``./python.exe -m importlib.test.benchmark`` and compare the output (run with -h to see all the options).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 14:59:45 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Jul 2012 12:59:45 +0000
Subject: [issue15387] pkgutil.walk_packages is using a deprecated API
In-Reply-To: <1342612573.81.0.647626142545.issue15387@psf.upfronthosting.co.za>
Message-ID: <1342616385.75.0.631071735621.issue15387@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I think the imp functions do need to go away. They perpetuate an absolutely horrendous API that I'm trying to slowly kill (and the underlying imp code is already reusing importlib). They already are a burden for future API growth as people already rely on imp.find_module() and imp.load_module() in such a way that untangling is right pain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15387>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:00:52 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 18 Jul 2012 13:00:52 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342616452.75.0.673406053711.issue15184@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

I suspect the problem is related to http://bugs.python.org/issue15298.

Basically the global sysconfig module caches the results of parsing Makefile in Lib/_sysconfigdata.py.  This can cause you to get the config vars from an old configure and build.

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:04:05 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Jul 2012 13:04:05 +0000
Subject: [issue15386] Still getting two copies of importlib._bootstrap
In-Reply-To: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>
Message-ID: <1342616645.56.0.57242743276.issue15386@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I would have said that it wasn't because it was just the class type not picking up on the __name__ re-assignment, but that global name failure states otherwise.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15386>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:15:11 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Jul 2012 13:15:11 +0000
Subject: [issue15387] pkgutil.walk_packages is using a deprecated API
In-Reply-To: <1342612573.81.0.647626142545.issue15387@psf.upfronthosting.co.za>
Message-ID: <3Wcf3f51XjzPFw@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset af7961e1c362 by Nick Coghlan in branch 'default':
Close #15387: inspect.getmodulename() now uses a new importlib.machinery.all_suffixes() API rather than the deprecated inspect.getmoduleinfo()
http://hg.python.org/cpython/rev/af7961e1c362

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15387>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:20:40 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 13:20:40 +0000
Subject: [issue15387] pkgutil.walk_packages is using a deprecated API
In-Reply-To: <1342612573.81.0.647626142545.issue15387@psf.upfronthosting.co.za>
Message-ID: <1342617640.44.0.184186406735.issue15387@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The problem turned out to just be inspect.getmodulename() still relying on the deprecated inspect.getmoduleinfo(), so I changed it to be based on importlib.machinery instead.

I did make an importlib API addition to do it though - the all_suffixes() function dynamically adds together all the suffixes relevant for the current process so it will pick up any modification post import, while still allowing code that doesn't care about module types to ignore the details of the different kinds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15387>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:27:01 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 13:27:01 +0000
Subject: [issue15386] Still getting two copies of importlib._bootstrap
In-Reply-To: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>
Message-ID: <1342618021.51.0.789311509687.issue15386@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yup. A simpler demonstration:

Python 3.3.0b1 (default:8bf691d0b004+, Jul 15 2012, 23:20:06) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from importlib import _bootstrap, machinery
>>> _bootstrap.FileFinder is machinery.FileFinder
False

My initial theory (a missing sys.modules entry) failed miserably, as import.__init__ already has the following line:

    sys.modules['importlib._bootstrap'] = _bootstrap

I'm guessing it has to be some weird interaction with the explicit relative import, but I would have expected that to pick up on either the parent module attribute or the sys.modules entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15386>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:35:06 2012
From: report at bugs.python.org (=?utf-8?q?Ilpo_Nyyss=C3=B6nen?=)
Date: Wed, 18 Jul 2012 13:35:06 +0000
Subject: [issue5364] documentation in epub format
In-Reply-To: <1235557178.12.0.454366670328.issue5364@psf.upfronthosting.co.za>
Message-ID: <1342618506.78.0.631683926338.issue5364@psf.upfronthosting.co.za>


Changes by Ilpo Nyyss?nen <iny at iki.fi>:


----------
nosy: +biny

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5364>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:36:05 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 Jul 2012 13:36:05 +0000
Subject: [issue15360] Behavior of assigning to __dict__ is not documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1342618565.86.0.120508197429.issue15360@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What kind of behavior are you referring to?
Are there really differences between versions?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15360>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:39:03 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 18 Jul 2012 13:39:03 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342618743.31.0.107234754942.issue15368@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Oh, cool -- I didn't know about the importlib benchmarks.  Thanks Brett.

Here are the results (OS X 10.7.4, Dual 1.7GHz Core i5, 4 GB RAM):

$ ./python.exe -m importlib.test.benchmark
Measuring imports/second over 1 second, best out of 3
Entire benchmark run should take about 33 seconds
Using <function __import__ at 0x1063bdd40> as __import__

sys.modules [ 41831 41812 40914 ] best is 41,831
Built-in module [ 20327 20441 19775 ] best is 20,441
Source writing bytecode: small [ 2108 2119 2117 ] best is 2,119
Source w/o bytecode: small [ 5093 5075 5106 ] best is 5,106
Source w/ bytecode: small [ 6021 5915 5997 ] best is 6,021
Source writing bytecode: tabnanny [ 379 379 379 ] best is 379
Source w/o bytecode: tabnanny [ 448 453 456 ] best is 456
Source w/ bytecode: tabnanny [ 2270 2279 2279 ] best is 2,279
Source writing bytecode: decimal [ 28 27 28 ] best is 28
Source w/o bytecode: decimal [ 30 30 30 ] best is 30
Source w/ bytecode: decimal [ 256 254 259 ] best is 259

$ ./python-with-sorting.exe -m importlib.test.benchmark
Measuring imports/second over 1 second, best out of 3
Entire benchmark run should take about 33 seconds
Using <function __import__ at 0x104b01d40> as __import__

sys.modules [ 42369 42203 42348 ] best is 42,369
Built-in module [ 17060 16358 20486 ] best is 20,486
Source writing bytecode: small [ 2118 2112 2127 ] best is 2,127
Source w/o bytecode: small [ 5121 5098 5125 ] best is 5,125
Source w/ bytecode: small [ 6015 5652 6046 ] best is 6,046
Source writing bytecode: tabnanny [ 367 368 366 ] best is 368
Source w/o bytecode: tabnanny [ 439 429 439 ] best is 439
Source w/ bytecode: tabnanny [ 2267 2274 2277 ] best is 2,277
Source writing bytecode: decimal [ 27 27 27 ] best is 27
Source w/o bytecode: decimal [ 28 28 28 ] best is 28
Source w/ bytecode: decimal [ 257 259 259 ] best is 259

Pretty similar results either way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:43:52 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 13:43:52 +0000
Subject: [issue15386] Still getting two copies of importlib._bootstrap
In-Reply-To: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>
Message-ID: <1342619032.52.0.350891726771.issue15386@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Checking with importlib.abc and importlib.util (which turned out not to have the problem) put me on the right path: the problem is the import of "imp" in importlib.__init__

What appears to be happening is that the interpreter sees the partially initialised importlib package, considers it good enough, and continues on with importing _bootstrap and machinery from source. Control eventually returns to __init__ and it overwrites the source version with the frozen version.

Changing the __init__ file to do "import _imp" instead (the same as what import_init does in the C code) was enough to fix it.

No patch yet - the actual fix is trivial, but it needs a test.

----------
nosy: +georg.brandl
priority: normal -> release blocker
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15386>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:49:23 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Jul 2012 13:49:23 +0000
Subject: [issue15387] pkgutil.walk_packages is using a deprecated API
In-Reply-To: <1342612573.81.0.647626142545.issue15387@psf.upfronthosting.co.za>
Message-ID: <1342619363.83.0.0396568299699.issue15387@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

RE: the API addition: fine by me if it makes your life easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15387>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:50:33 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Jul 2012 13:50:33 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342619433.84.0.869765088263.issue15368@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Yep, so I consider the performance worry dealt with.

----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:53:00 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Jul 2012 13:53:00 +0000
Subject: [issue15386] Still getting two copies of importlib._bootstrap
In-Reply-To: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>
Message-ID: <1342619580.45.0.479648069557.issue15386@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Nice catch! Obviously that needs a big comment to avoid that problem in the future.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15386>
_______________________________________

From report at bugs.python.org  Wed Jul 18 15:54:17 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 13:54:17 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342619657.48.0.654712366986.issue15368@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Agreed, so definite +1 from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 16:17:30 2012
From: report at bugs.python.org (Matt Hillsdon)
Date: Wed, 18 Jul 2012 14:17:30 +0000
Subject: [issue15388] SAX parse (ExpatParser) leaks file handle when given
	filename input
Message-ID: <1342621050.08.0.170764357594.issue15388@psf.upfronthosting.co.za>


New submission from Matt Hillsdon <mth at corefiling.com>:

The following example uses make_parser / parse to read a trivial XML document by filename and then attempts to delete the file.  On Win32 I can't unlink the file because the parse does not seem to close the file handle.


import os
import tempfile
from xml.sax import make_parser, ContentHandler

(handle, path) = tempfile.mkstemp()
os.write(handle, b"<foo/>")
os.close(handle)

parser = make_parser()
parser.parse(path)

# This unlink fails on win32.  It succeeds if I comment out the call to parse.
os.unlink(path)


As I provide a filename rather than a file object, I would expect the parse call to both open and close it.  I can't see a way to do the clean-up myself.

This issue exists in Python 2.7.3 but I could not reproduce it in 3.2.3.


Windows cmd transcript:

c:\Users\mth>Python2.7.3\python.exe fileleak.py
Traceback (most recent call last):
  File "fileleak.py", line 14, in <module>
    os.unlink(path)
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'c:\\d\\tmpvyqg2c'

c:\Users\mth>Python3.2.3\python.exe fileleak.py

c:\Users\mth>

----------
components: XML
messages: 165779
nosy: mth
priority: normal
severity: normal
status: open
title: SAX parse (ExpatParser) leaks file handle when given filename input
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15388>
_______________________________________

From report at bugs.python.org  Wed Jul 18 16:29:55 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jul 2012 14:29:55 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342603963.23.0.290949025848.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342621828.2473.14.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> I wonder if this is a fair comparison, Serhiy.

I just used your examples.

> When re-running your tests with larger chunks, the results are quite interesting:

Well, now I see, that BytesIO slower StringIO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Wed Jul 18 16:55:51 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Jul 2012 14:55:51 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342623351.8.0.511922415992.issue15368@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So I think that just leaves one other person to verify the patch works as expected and then commit it. I can hopefully later this week, but no sooner than Friday, so if someone can get to it faster that would be great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 17:01:22 2012
From: report at bugs.python.org (Brian Quinlan)
Date: Wed, 18 Jul 2012 15:01:22 +0000
Subject: [issue13785] Make concurrent.futures.Future state public
In-Reply-To: <1326560835.55.0.282912980665.issue13785@psf.upfronthosting.co.za>
Message-ID: <1342623682.05.0.0158748073113.issue13785@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

My current thinking is that adding a "state" property probably isn't worth it given the fact that you can construct this yourself and the requirement for a "history" property is too specialized.

The callback idea seams reasonable and sufficient for your use case. I think that you'd probably want to *not* specify that state change that you want i.e. any state change triggers the function.

What do you think?

(BTW, I'm on leave right now so it might take a while to respond)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13785>
_______________________________________

From report at bugs.python.org  Wed Jul 18 17:03:00 2012
From: report at bugs.python.org (Catalin Iacob)
Date: Wed, 18 Jul 2012 15:03:00 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1342623780.81.0.614653859577.issue8713@psf.upfronthosting.co.za>


Changes by Catalin Iacob <iacobcatalin at gmail.com>:


----------
nosy: +catalin.iacob

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Jul 18 17:06:19 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 18 Jul 2012 15:06:19 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342623979.53.0.655211239586.issue15368@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I can commit today unless you think we need someone else to independently verify the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 17:22:29 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 18 Jul 2012 15:22:29 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342624949.49.0.951602803771.issue15368@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

BTW, I think this should be committed on 2.7 and 3.2 as well since the same issue can happen when throwing -R.  Any objections?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 17:45:24 2012
From: report at bugs.python.org (Michal Zimen)
Date: Wed, 18 Jul 2012 15:45:24 +0000
Subject: [issue15082] [httplib] httplib.BadStatusLine on any HTTPS connection
	in certain unknown cases.
In-Reply-To: <1339811528.79.0.0690651710917.issue15082@psf.upfronthosting.co.za>
Message-ID: <1342626324.02.0.566368213882.issue15082@psf.upfronthosting.co.za>


Michal Zimen <michal.zimen at gmail.com> added the comment:

I can confirm similar behaviour in RHEL 6.3 with python 2.6.6.
This exception with the same https request has random behaviour.

----------
nosy: +Michal.Zimen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15082>
_______________________________________

From report at bugs.python.org  Wed Jul 18 17:48:30 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jul 2012 15:48:30 +0000
Subject: [issue15379] Charmap decoding of no-BMP characters
In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za>
Message-ID: <1342626511.0.0.172690424979.issue15379@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Well, here is a patch for 3.2.

----------
versions: +Python 3.2
Added file: http://bugs.python.org/file26428/decode_charmap_maxchar-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15379>
_______________________________________

From report at bugs.python.org  Wed Jul 18 18:00:39 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Jul 2012 16:00:39 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342627239.04.0.180609899752.issue15368@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Nah, you are a committer and thus qualify as the second review. =)

As for backporting, it only affects regeneration of bytecode, so I don't see any major harm in it (might surprise some people, but there is a legitimate reason for fixing this).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 18:14:07 2012
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 18 Jul 2012 16:14:07 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1342628047.68.0.0676044841066.issue12834@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I think that I run into the same bug today. I've developing a PEP 3118 buffer interface for my wrapper of FreeImage. It returns the data as non-contiguous 3d array with the dimension height, width, color.

I've created a small test image with 5x7 RGB pixels. The first line black, second white, third grey values and the rest are red, green blue and cyan, magenta yellow in little endian (BGR order).

NumPy handles the buffer correctly:
>>> arr = numpy.asarray(img)
>>> print(arr)

[[[  0   0   0]
  [  0   0   0]
  [  0   0   0]
  [  0   0   0]
  [  0   0   0]]

 [[255 255 255]
  [255 255 255]
  [255 255 255]
  [255 255 255]
  [255 255 255]]

 [[ 80  80  80]
  [112 112 112]
  [160 160 160]
  [192 192 192]
  [240 240 240]]

 [[  0   0 255]
  [  0 255   0]
  [255   0   0]
  [  0   0 255]
  [  0 255   0]]

 [[255   0   0]
  [  0   0 255]
  [  0 255   0]
  [255   0   0]
  [  0   0 255]]

 [[  0 255   0]
  [255   0   0]
  [  0   0 255]
  [  0 255   0]
  [255   0   0]]

 [[255 255   0]
  [255   0 255]
  [  0 255 255]
  [255 255   0]
  [255   0 255]]]

but memoryview.tobytes() seems to have an off-by-one error:

>>> m = memoryview(img)
>>> data = m.tobytes()
>>> len(data) ==  5 * 7 * 3
True
>>> for i in range(7):
...     print(" ".join("%3i" % ord(v) for v in data[i * 5 * 3:(i + 1) * 5 * 3]))
  0   0   0   0   0   0   0   0   0   0   0   0   0   0 255
255 255 255 255 255 255 255 255 255 255 255 255 255 255  80
 80  80 112 112 112 160 160 160 192 192 192 240 240 240   0
  0 255   0 255   0 255   0   0   0   0 255   0 255   0 255
  0   0   0   0 255   0 255   0 255   0   0   0   0 255   0
255   0 255   0   0   0   0 255   0 255   0 255   0   0 255
255   0 255   0 255   0 255 255 255 255   0 255   0 255   0

As you can see the first byte is missing.

Python 2.7.3 and Python 3.2.3 with numpy 1.6.1 and https://bitbucket.org/tiran/smc.freeimage/changeset/3134ecee2984 on 64bit Ubuntu.

----------
nosy: +christian.heimes
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Wed Jul 18 18:15:28 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 18 Jul 2012 16:15:28 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1342628128.35.0.491298769009.issue12834@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/issue12834>
_______________________________________

From report at bugs.python.org  Wed Jul 18 18:46:38 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 Jul 2012 16:46:38 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342629998.5.0.199319895471.issue15184@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I don't see how this is related to Issue15298.  In the failure here, sysconfig returns the expected value; the problem is with what distutils.sysconfig returns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Wed Jul 18 18:59:09 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 18 Jul 2012 16:59:09 +0000
Subject: [issue15386] Still getting two copies of importlib._bootstrap
In-Reply-To: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>
Message-ID: <1342630749.43.0.0497578486389.issue15386@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/issue15386>
_______________________________________

From report at bugs.python.org  Wed Jul 18 19:02:58 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 18 Jul 2012 17:02:58 +0000
Subject: [issue15360] Behavior of assigning to __dict__ is not documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1342630977.87.0.245000902195.issue15360@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/issue15360>
_______________________________________

From report at bugs.python.org  Wed Jul 18 19:26:48 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 18 Jul 2012 17:26:48 +0000
Subject: [issue10017] pprint.pprint raises TypeError on dictionaries with
	user-defined types as keys
In-Reply-To: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>
Message-ID: <1342632408.54.0.419673693968.issue10017@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Confirmed on python 3.2 and 3.3.

----------
keywords: +easy
nosy: +flox
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10017>
_______________________________________

From report at bugs.python.org  Wed Jul 18 21:29:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Jul 2012 19:29:58 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <3WcpN037VqzPGT@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7eb0180c1734 by Meador Inge in branch '2.7':
Issue #15368: make bytecode generation deterministic.
http://hg.python.org/cpython/rev/7eb0180c1734

New changeset 79d54fba49b3 by Meador Inge in branch '3.2':
Issue #15368: make bytecode generation deterministic.
http://hg.python.org/cpython/rev/79d54fba49b3

New changeset 578066372485 by Meador Inge in branch 'default':
Issue #15368: make bytecode generation deterministic.
http://hg.python.org/cpython/rev/578066372485

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 21:32:11 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 18 Jul 2012 19:32:11 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342639931.09.0.211179819512.issue15368@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Committed.  Thanks for the reviews y'all.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 21:40:09 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 18 Jul 2012 19:40:09 +0000
Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples
In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za>
Message-ID: <1342640409.77.0.988522415789.issue12510@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Are there any other aspects of the calltip handler that requires fixing? If not, then I can start back-porting the patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12510>
_______________________________________

From report at bugs.python.org  Wed Jul 18 21:53:57 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 18 Jul 2012 19:53:57 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1342641237.08.0.776776521807.issue9998@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

What changed since http://bugs.python.org/issue2936?

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Wed Jul 18 22:06:28 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jul 2012 20:06:28 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342641988.81.0.408709732481.issue15381@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Here is a preliminary version of the patch. I am not sure that it is fully correct.

Microbenchmark results:

$ ./python -m timeit -s "import io; n=100; d=['a'*n,'bb'*n,'ccc'*n]*10000"  "s=io.StringIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
10 loops, best of 3: 25.5 msec per loop
$ ./python -m timeit -s "import io; n=100; d=[b'a'*n,b'bb'*n,b'ccc'*n]*10000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
10 loops, best of 3: 39.9 msec per loop
$ ./python-patched -m timeit -s "import io; n=100; d=[b'a'*n,b'bb'*n,b'ccc'*n]*10000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
10 loops, best of 3: 26.1 msec per loop

$ ./python -m timeit -s "import io; n=1000; d=['a'*n,'bb'*n,'ccc'*n]*1000"  "s=io.StringIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
100 loops, best of 3: 12.1 msec per loop
$ ./python -m timeit -s "import io; n=1000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
10 loops, best of 3: 26.5 msec per loop
$ ./python-patched -m timeit -s "import io; n=1000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
100 loops, best of 3: 13.6 msec per loop

----------
keywords: +patch
Added file: http://bugs.python.org/file26429/bytesio_resized_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Wed Jul 18 22:26:53 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 Jul 2012 20:26:53 +0000
Subject: [issue15379] Charmap decoding of no-BMP characters
In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za>
Message-ID: <1342643213.72.0.0447699383015.issue15379@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

About the patch for 3.2:
   "needed = 6 - extrachars"
Where does this 6 come from?  There is another part which uses this "extrachars".  Why is the allocation strategy different here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15379>
_______________________________________

From report at bugs.python.org  Wed Jul 18 22:27:02 2012
From: report at bugs.python.org (David Bolen)
Date: Wed, 18 Jul 2012 20:27:02 +0000
Subject: [issue15384] pkgutil.get_importer("") was returning None on Windows
	buildbots
In-Reply-To: <1342608363.39.0.672383016327.issue15384@psf.upfronthosting.co.za>
Message-ID: <1342643222.83.0.899411449646.issue15384@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

With a local build on my buildbot of the tip of the default branch, pkgutil.get_importer('') returns FileFilter('.').  The tests also passed.

However, after checking here and realizing the offending code had been removed from the test, I put it back in and it still fails.

I think the problem is that sys.path[0] is not '' when testing in the buildbot environment (though it is when I run the debug interpreter interactively).  Within the buildbot scripts it's a path to the stdlib test zip, so for example in my test tree it's "D:\cygwin\home\db3l\test\build\PCbuild\python33_d.zip".

And if I hand that string to pkgutil.get_importer() I do seem to get None back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15384>
_______________________________________

From report at bugs.python.org  Wed Jul 18 22:33:38 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jul 2012 20:33:38 +0000
Subject: [issue15379] Charmap decoding of no-BMP characters
In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za>
Message-ID: <1342643618.1.0.604427104909.issue15379@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

It's the same strategy.
"needed = (targetsize - extrachars) + (targetsize << 2)". targetsize == 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15379>
_______________________________________

From report at bugs.python.org  Wed Jul 18 22:52:58 2012
From: report at bugs.python.org (Juan Javier)
Date: Wed, 18 Jul 2012 20:52:58 +0000
Subject: [issue13785] Make concurrent.futures.Future state public
In-Reply-To: <1326560835.55.0.282912980665.issue13785@psf.upfronthosting.co.za>
Message-ID: <1342644778.92.0.00632775585342.issue13785@psf.upfronthosting.co.za>


Juan Javier <jjdominguezm at gmail.com> added the comment:

I totally agree, I'm going to take a look at the code and I'll write back with some comments. That will be next week, work is currently very demanding.

----------
status: languishing -> open
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13785>
_______________________________________

From report at bugs.python.org  Wed Jul 18 22:55:23 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jul 2012 20:55:23 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342644923.27.0.472587975267.issue15368@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Meador, you have forgotten to fix the error "PyList_GET_SIZE(src)". src is not list, should be "PyList_GET_SIZE(sorted_keys)".

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:07:57 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 Jul 2012 21:07:57 +0000
Subject: [issue15379] Charmap decoding of no-BMP characters
In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za>
Message-ID: <1342645677.66.0.780884049843.issue15379@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Ah, I was worried by the possible quadratic behavior.  So the other (existing) case is quadratic as well (I was mislead by the <<, which made me think there is something clever there).
That's good enough for 3.2, I guess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15379>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:12:33 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 18 Jul 2012 21:12:33 +0000
Subject: [issue9890] Visual C++ Runtime Library Error is there a fix?
In-Reply-To: <1284774877.07.0.1280459876.issue9890@psf.upfronthosting.co.za>
Message-ID: <1342645953.6.0.406550838181.issue9890@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Is this still a problem? My guess is that this issue is out of date.

----------
nosy: +serwy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9890>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:29:09 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 18 Jul 2012 21:29:09 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1342646949.9.0.107355866241.issue15368@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

D'oh!  Thanks for catching that Serhiy!  Fixing now.  Sorry about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:30:11 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 18 Jul 2012 21:30:11 +0000
Subject: [issue15389] PEP 3121, 384 refactoring applied to curses module
Message-ID: <1342647007.31.0.0527373490627.issue15389@psf.upfronthosting.co.za>


New submission from Robin Schreiber <robin.schreiber at me.com>:

Changes proposed in PEP3121 and PEP384 applied to the curses module. As these Changes do not alter behaviour of the specific modules, I would encourage to see this enhancement as a "bugfix" and consequently include this into the coming Python 3.3 release.

----------
components: Extension Modules
files: _cursesmodule_pep3121-384_v0.patch
keywords: patch
messages: 165804
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to curses module
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file26430/_cursesmodule_pep3121-384_v0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15389>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:33:53 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 18 Jul 2012 21:33:53 +0000
Subject: [issue15390] PEP 3121, 384 refactoring applied to datetime module
Message-ID: <1342647232.82.0.0763290244077.issue15390@psf.upfronthosting.co.za>


New submission from Robin Schreiber <robin.schreiber at me.com>:

Changes proposed in PEP3121 and PEP384 have now been applied to the datetime module!

----------
components: Extension Modules
files: _datetimemodule_pep3121-384_v0.patch
keywords: patch
messages: 165805
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to datetime module
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file26431/_datetimemodule_pep3121-384_v0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15390>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:36:50 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 18 Jul 2012 21:36:50 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1342647409.81.0.939977773415.issue9998@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> What changed since http://bugs.python.org/issue2936?

Well for one thing, #2936 was a bug report ("behavior") but this is an enhancement request. It seems that if you don't know exactly what a library is called, you can't use find_library to locate it even if it happens to be on LD_LIBRARY_PATH - and if you don't have the name, you can't load it using cdll.LoadLibrary.

ISTM LoadLibrary wants the full library name (including extension, on Linux); find_library helps determine that in a cross-platform way (since you can just give it the stem of the library rather than the whole filename).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:40:20 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 18 Jul 2012 21:40:20 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1342647620.8.0.0561688147468.issue9998@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Fair enough. From what I've gathered though, it looks like the window for inclusion in 3.3 is already closed, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:43:48 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 18 Jul 2012 21:43:48 +0000
Subject: [issue15389] PEP 3121, 384 refactoring applied to curses module
In-Reply-To: <1342647007.31.0.0527373490627.issue15389@psf.upfronthosting.co.za>
Message-ID: <1342647828.01.0.0209033395555.issue15389@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

If I understand correctly, it will be hard to justify this as a bugfix. But let's ask the Release Manager.

----------
nosy: +georg.brandl, lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15389>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:50:29 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 18 Jul 2012 21:50:29 +0000
Subject: [issue6257] Idle terminates on source save while debugging
In-Reply-To: <1244652442.36.0.452724625348.issue6257@psf.upfronthosting.co.za>
Message-ID: <1342648229.76.0.121954965855.issue6257@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The only was I get IDLE to crash is if the file has breakpoints enabled. Is this how IDLE is crashing?

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6257>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:50:42 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 18 Jul 2012 21:50:42 +0000
Subject: [issue9803] IDLE closes with save while breakpoint open
In-Reply-To: <1283974949.4.0.785258120567.issue9803@psf.upfronthosting.co.za>
Message-ID: <1342648242.42.0.48404437347.issue9803@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Reopening. I mistakenly closed this issue as a duplicate, but this issue involves breakpoints, unlike 6257.

----------
resolution: duplicate -> 
status: closed -> open
superseder: Idle terminates on source save while debugging -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9803>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:51:21 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Jul 2012 21:51:21 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <3WcsWB04MFzPDV@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 47e074f6ca26 by Meador Inge in branch '2.7':
Issue #15368: fixing variable typo.
http://hg.python.org/cpython/rev/47e074f6ca26

New changeset 1c46f2ede4cb by Meador Inge in branch '3.2':
Issue #15368: fixing variable typo.
http://hg.python.org/cpython/rev/1c46f2ede4cb

New changeset 6502de91610d by Meador Inge in branch 'default':
Issue #15368: fixing variable typo.
http://hg.python.org/cpython/rev/6502de91610d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15368>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:55:49 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jul 2012 21:55:49 +0000
Subject: [issue14596] struct.unpack memory leak
In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za>
Message-ID: <1342648549.02.0.349246974797.issue14596@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Please, can anyone do the review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14596>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:58:07 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 18 Jul 2012 21:58:07 +0000
Subject: [issue9803] IDLE closes with save while breakpoint open
In-Reply-To: <1283974949.4.0.785258120567.issue9803@psf.upfronthosting.co.za>
Message-ID: <1342648687.09.0.145393697287.issue9803@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Attached is a patch to fix the issue. The ranges_to_linenumbers function relies on the results of text.tag_ranges. The returned tuple contains Tk textindex objects. While these objects contain a string, they are not string objects. Its .string value must be used instead.

----------
keywords: +patch
nosy: +terry.reedy
priority: normal -> high
stage:  -> patch review
type: crash -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.1
Added file: http://bugs.python.org/file26432/issue9803.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9803>
_______________________________________

From report at bugs.python.org  Wed Jul 18 23:59:37 2012
From: report at bugs.python.org (Andy Harrington)
Date: Wed, 18 Jul 2012 21:59:37 +0000
Subject: [issue6257] Idle terminates on source save while debugging
In-Reply-To: <1342648229.76.0.121954965855.issue6257@psf.upfronthosting.co.za>
Message-ID: <CAOaxTEJB8RwNX5GnZ4M4B4preEJhxjQbhvR15LAYd02rYn0CnA@mail.gmail.com>


Andy Harrington <aharrin at luc.edu> added the comment:

yes I certainly used breakpoints

On Wed, Jul 18, 2012 at 4:50 PM, Roger Serwy <report at bugs.python.org> wrote:

>
> Roger Serwy <roger.serwy at gmail.com> added the comment:
>
> The only was I get IDLE to crash is if the file has breakpoints enabled.
> Is this how IDLE is crashing?
>
> ----------
> nosy: +serwy
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6257>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6257>
_______________________________________

From report at bugs.python.org  Thu Jul 19 00:02:35 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 18 Jul 2012 22:02:35 +0000
Subject: [issue14596] struct.unpack memory leak
In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za>
Message-ID: <1342648954.97.0.787234070462.issue14596@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/issue14596>
_______________________________________

From report at bugs.python.org  Thu Jul 19 00:09:41 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Wed, 18 Jul 2012 22:09:41 +0000
Subject: [issue10017] pprint.pprint raises TypeError on dictionaries with
	user-defined types as keys
In-Reply-To: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>
Message-ID: <1342649381.75.0.356717874641.issue10017@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


----------
nosy: +anton.barkovsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10017>
_______________________________________

From report at bugs.python.org  Thu Jul 19 00:16:30 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 18 Jul 2012 22:16:30 +0000
Subject: [issue14105] Breakpoints in debug lost if line is inserted; IDLE
In-Reply-To: <1330047327.02.0.291761854329.issue14105@psf.upfronthosting.co.za>
Message-ID: <1342649789.9.0.158166833073.issue14105@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The ColorDelegator is responsible for providing the coloring for the BREAK tag which is used to mark breakpoints. When recoloring, the BREAK tag may be removed (find self.tag_remove in recolorize_main). This is precisely why the breakpoints disappear.

On 2.7, you can use Control-/ to toggle the ColorDelegator. Doing so eliminates the behavior you describe. On 3.x, Control-/ is broken due to two ColorDelegators being loaded. See issue13495.

A possible solution would be to separate the BREAK tags from the color delegator since these tags ought to be part of the debugging code only.

----------
nosy: +serwy
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14105>
_______________________________________

From report at bugs.python.org  Thu Jul 19 00:22:04 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 18 Jul 2012 22:22:04 +0000
Subject: [issue6257] Idle terminates on source save while debugging
In-Reply-To: <1244652442.36.0.452724625348.issue6257@psf.upfronthosting.co.za>
Message-ID: <1342650124.72.0.0524712964783.issue6257@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Thanks Andy for your prompt response. 

This issue is a duplicate with issue9803 which has a patch. I will close this issue in favor of that one. Feel free to add yourself to the nosy list if you wish.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> IDLE closes with save while breakpoint open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6257>
_______________________________________

From report at bugs.python.org  Thu Jul 19 01:24:54 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Wed, 18 Jul 2012 23:24:54 +0000
Subject: [issue10017] pprint.pprint raises TypeError on dictionaries with
	user-defined types as keys
In-Reply-To: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>
Message-ID: <1342653894.06.0.578720867265.issue10017@psf.upfronthosting.co.za>


Anton Barkovsky <swarmer.pm at gmail.com> added the comment:

Here's a patch with fix and tests.

Note that class objects are not comparable and have the same type so they
fall back on sorting by id. Should we sort them by name as a special case instead?

----------
keywords: +patch
Added file: http://bugs.python.org/file26433/pprint_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10017>
_______________________________________

From report at bugs.python.org  Thu Jul 19 01:32:23 2012
From: report at bugs.python.org (anon)
Date: Wed, 18 Jul 2012 23:32:23 +0000
Subject: [issue15391] Add bitlength function to the math module
Message-ID: <1342654343.1.0.00342933769834.issue15391@psf.upfronthosting.co.za>


New submission from anon <UnluckyKitten at mailinator.com>:

Many numeric algorithms require knowing the number of bits an integer has (for instance integer squareroots). For example this simple algorithm using shifts is O(n^2):

def bitl(x):
  x = abs(x)
  n = 0
  while x > 0:
    n = n+1
    x = x>>1
  return n

A simple O(n) algorithm exists:

def bitl(x):
  if x==0: return 0
  return len(bin(abs(x)))-2

It should be possible find the bit-length of an integer in O(1) however. O(n) algorithms with high constants simply don't cut it for many applications.

That's why I would propose adding an inbuilt function bitlength(n) to the math module. bitlength(n) would be the integer satisfying

  bitlength(n) = ceil(log2(abs(n)+1))

Python more than ever with PyPy progressing is becoming a great platform for mathematical computation. This is an important building block for a huge number of algorithms but currently has no elegant or efficient solution in plain Python.

----------
components: Library (Lib)
messages: 165818
nosy: anon
priority: normal
severity: normal
status: open
title: Add bitlength function to the math module
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15391>
_______________________________________

From report at bugs.python.org  Thu Jul 19 01:34:59 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 18 Jul 2012 23:34:59 +0000
Subject: [issue15391] Add bitlength function to the math module
In-Reply-To: <1342654343.1.0.00342933769834.issue15391@psf.upfronthosting.co.za>
Message-ID: <1342654499.17.0.629790941922.issue15391@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

I think what you're looking for already exists: http://docs.python.org/dev/library/stdtypes.html#int.bit_length

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15391>
_______________________________________

From report at bugs.python.org  Thu Jul 19 01:44:27 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Jul 2012 23:44:27 +0000
Subject: [issue9254] __import__ docstring should recommend
	importlib.import_module()
In-Reply-To: <1279057769.02.0.398615806235.issue9254@psf.upfronthosting.co.za>
Message-ID: <3Wcw1j2pJkzPGT@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 751f28564a45 by R David Murray in branch '2.7':
Closes #9254: backport __import__ docstring/doc mentions of importlib.
http://hg.python.org/cpython/rev/751f28564a45

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9254>
_______________________________________

From report at bugs.python.org  Thu Jul 19 02:13:20 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 19 Jul 2012 00:13:20 +0000
Subject: [issue15391] Add bitlength function to the math module
In-Reply-To: <1342654343.1.0.00342933769834.issue15391@psf.upfronthosting.co.za>
Message-ID: <1342656800.05.0.213991367243.issue15391@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/issue15391>
_______________________________________

From report at bugs.python.org  Thu Jul 19 02:17:47 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 19 Jul 2012 00:17:47 +0000
Subject: [issue15391] Add bitlength function to the math module
In-Reply-To: <1342654343.1.0.00342933769834.issue15391@psf.upfronthosting.co.za>
Message-ID: <1342657066.79.0.52972810514.issue15391@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Closing as Invalid. I think that Alex is right.

Anon, if you think this is a mistake, please reopen and argument.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15391>
_______________________________________

From report at bugs.python.org  Thu Jul 19 03:16:10 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 19 Jul 2012 01:16:10 +0000
Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples
In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za>
Message-ID: <1342660570.83.0.258915820467.issue12510@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The original patches were to all 3 versions. The later patches were to both 3.x versions and mostly involved get_argspec and expanding the tests. Get_argspec is somewhat different from get_arg_text, the 2.x function it replaced. The main difference I could see is that the latter attempt to deal with old-style classes (I think) and does not use inspect.

I *think* I am done changing get_argspec until I try making use of the new PEP 362 function signature objects, but that can only affect 3.3+. (This would be to improve calltips for builtins). So if you want to backport further changes to 2.7, so it can pass more of the expanded test suite, now is a good time. Since the TC test class in 2.7 is derived from object, there seems to be no test of old style classes, so I don't know if just replacing get_arg_text with get_argspec would break anything that actually works, assuming that get_argspec does work ;-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12510>
_______________________________________

From report at bugs.python.org  Thu Jul 19 05:44:06 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 19 Jul 2012 03:44:06 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1342669446.05.0.589531180652.issue6068@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I am closing this issue in favor of issue6493.  This patch attached to this issue is incorrect.  The proposed definition of BIT_MASK allows for undefined behavior when the number of bits shifted is 64 for a uint64.  The patch in issue6493 handles this case correctly.

----------
nosy: +meador.inge
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Can not set value for structure members larger than 32 bits

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Thu Jul 19 06:36:36 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 19 Jul 2012 04:36:36 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1342672596.67.0.134985248866.issue6493@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

The problem is with the 'BIT_MASK' macro, which is currently defined as the following for Windows:

   #define BIT_MASK(size) ((1 << NUM_BITS(size))-1)

The C standard says that any attempt to shift left by exactly the bit width is undefined behavior.  For the given test case 'NUM_BITS(size) == 32' and the '1' constant is of type 'int'.  Thus the behavior is undefined.

For x86 Windows with the MSVC++ compiler this ends up as 'SAL edx, CL' and the Intel manuals say that the shift count is masked by 0x1F.  Thus the bit mask ends up as '(1 << 0) - 1 == 0'.  Plug the zero mask into the 'SET' macro and you will see why the reported behavior is being observed.

I tested Hirokazu's last patch on Windows 7 64-bit and OS X 10.7;  I saw no regression.  I will apply the patch shortly.

----------
assignee:  -> meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Thu Jul 19 06:44:41 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 19 Jul 2012 04:44:41 +0000
Subject: [issue15392] Create a unittest framework for IDLE
Message-ID: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Idle needs a unittest framework for module test modules. This means a test directory with at least one test module, a runtest module that successfully runs that test module, any new support functions needed for that test module, and inclusion of test_idle in Lib/test.

I am thinking of something like Lib/tkinter/test, but without subdirectories. I presume there should be something like tkinter/test/runtests, but I do not know if it reflects current best practice, nor whether it should be in idlelib or in idlelib/test.

One feature of runtests and the tkinter framework is separation of tests that do and do not require a gui. This requires cooperation of writers of each test module. Buildbots can only run tests that do not require a gui and nearly everyone else wants the same. On the other hand, we need automated gui tests too. A complete test of idlelib/runtest requires a test module with both kinds of tests.

List/test has test_tk. It runs tests with enable_gui=false unless run directly (and intentionally) as the main module. (Testing test_idle would also require tests in both modes.) It checks that tkinter is available. Should test_idle also check that idle is available? (On Windows, one can install both or neither. I don't know the situation on other systems.)

This issue was inspired by #12510 and is interdependent with it. As part of that issue, I would like to convert the expanded test set to run under unittest. #12510 needs a place to put a test_calltips module. On the other hand, this issue needs a test_x module to test runtests and test_idle.

tkinter/test/support has functions that can be used in idle tests, in particular, simulate_mouse_click(). I believe a needed addition is simulate_text_entry. That is needed to really finish the calltips tests. Currently, complete testing of tooltips requires non-automated hand tests.

Would simulate_mouse_click include selecting menu items, or would that be a separate function?

With such a test framework established, we could start adding tests as part of other issues, as is normal practice.

(Note: tkinter/test is pretty skeletal, and probably could use expansion, but except for support functions immediately needed for test_calltips, that is another issue.)

----------
assignee: terry.reedy
components: IDLE, Tests
messages: 165825
nosy: serwy, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Create a unittest framework for IDLE
type: enhancement
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15392>
_______________________________________

From report at bugs.python.org  Thu Jul 19 06:55:28 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 19 Jul 2012 04:55:28 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1342673728.44.0.177652117766.issue10399@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Thu Jul 19 06:55:41 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 19 Jul 2012 04:55:41 +0000
Subject: [issue11549] Build-out an AST optimizer,
	moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1342673741.3.0.90661204439.issue11549@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Thu Jul 19 07:15:44 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Jul 2012 05:15:44 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <3Wd3Mv1bM0zPLk@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 77401bd4f567 by Meador Inge in branch '2.7':
Issue #6493: Fix handling of c_uint32 bitfields with width of 32 on Windows.
http://hg.python.org/cpython/rev/77401bd4f567

New changeset 153ae76b963e by Meador Inge in branch '3.2':
Issue #6493: Fix handling of c_uint32 bitfields with width of 32 on Windows.
http://hg.python.org/cpython/rev/153ae76b963e

New changeset 3fbfa61634de by Meador Inge in branch 'default':
Issue #6493: Fix handling of c_uint32 bitfields with width of 32 on Windows.
http://hg.python.org/cpython/rev/3fbfa61634de

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Thu Jul 19 07:16:22 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 19 Jul 2012 05:16:22 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1342674981.86.0.966057840626.issue6493@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Thu Jul 19 08:04:04 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 19 Jul 2012 06:04:04 +0000
Subject: [issue15389] PEP 3121, 384 refactoring applied to curses module
In-Reply-To: <1342647007.31.0.0527373490627.issue15389@psf.upfronthosting.co.za>
Message-ID: <1342677844.95.0.906440260276.issue15389@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Definitely.

----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15389>
_______________________________________

From report at bugs.python.org  Thu Jul 19 09:48:22 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 19 Jul 2012 07:48:22 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1342684102.07.0.911527657671.issue9998@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Thu Jul 19 10:03:00 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 19 Jul 2012 08:03:00 +0000
Subject: [issue15389] PEP 3121, 384 refactoring applied to curses module
In-Reply-To: <1342647007.31.0.0527373490627.issue15389@psf.upfronthosting.co.za>
Message-ID: <1342684980.94.0.267310500011.issue15389@psf.upfronthosting.co.za>


Changes by Robin Schreiber <robin.schreiber at me.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15389>
_______________________________________

From report at bugs.python.org  Thu Jul 19 11:47:58 2012
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 19 Jul 2012 09:47:58 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1342691278.63.0.096138139117.issue12834@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

It looks like Stefan has fixed the issue in Python 3.3 a while ago. tobytes() returns the correct values with a fresh build of Python 3.3. 

$ PYTHONPATH="." /home/heimes/dev/python/py3k/python smc/freeimage/tests/test_image.py
test_newbuffer (__main__.TestImageNewBuffer) ... 

  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
 80  80  80 112 112 112 160 160 160 192 192 192 240 240 240
  0   0 255   0 255   0 255   0   0   0   0 255   0 255   0
255   0   0   0   0 255   0 255   0 255   0   0   0   0 255
  0 255   0 255   0   0   0   0 255   0 255   0 255   0   0
255 255   0 255   0 255   0 255 255 255 255   0 255   0 255

However it's still broken in 3.2 (also up to date hg pull).

$ PYTHONPATH="." /home/heimes/dev/python/3.2/python smc/freeimage/tests/test_image.py
test_newbuffer (__main__.TestImageNewBuffer) ... 

  0   0   0   0   0   0   0   0   0   0   0   0   0   0 255
255 255 255 255 255 255 255 255 255 255 255 255 255 255  80
 80  80 112 112 112 160 160 160 192 192 192 240 240 240   0
  0 255   0 255   0 255   0   0   0   0 255   0 255   0 255
  0   0   0   0 255   0 255   0 255   0   0   0   0 255   0
255   0 255   0   0   0   0 255   0 255   0 255   0   0 255
255   0 255   0 255   0 255 255 255 255   0 255   0 255   0


Stefan, could you please port your fix to Python 3.2 and 3.3? Thanks!

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Thu Jul 19 12:09:56 2012
From: report at bugs.python.org (Antti Laine)
Date: Thu, 19 Jul 2012 10:09:56 +0000
Subject: [issue15393] JSONDecoder.raw_decode breaks on leading whitespace
Message-ID: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za>


New submission from Antti Laine <antti.a.laine at iki.fi>:

raw_decode on json.JSONDecoder does not handle leading whitespace. According to RFC 4627, section 2, whitespace can precede an object. With json.loads leading whitespace is handled just fine.

d = json.JSONDecoder()
d.raw_decode(' {}')
ValueError: No JSON object could be decoded

Tested with versions 2.6.7, 2.7.3, 3.1.3 and 3.2.3

----------
components: Library (Lib)
messages: 165829
nosy: Antti Alien
priority: normal
severity: normal
status: open
title: JSONDecoder.raw_decode breaks on leading whitespace
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/issue15393>
_______________________________________

From report at bugs.python.org  Thu Jul 19 12:16:15 2012
From: report at bugs.python.org (Antti Laine)
Date: Thu, 19 Jul 2012 10:16:15 +0000
Subject: [issue15393] JSONDecoder.raw_decode breaks on leading whitespace
In-Reply-To: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za>
Message-ID: <1342692975.08.0.75417270274.issue15393@psf.upfronthosting.co.za>


Antti Laine <antti.a.laine at iki.fi> added the comment:

My coworker just submitted a pull request for a possible fix to simplejson on github.

https://github.com/simplejson/simplejson/pull/38

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15393>
_______________________________________

From report at bugs.python.org  Thu Jul 19 12:25:21 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Jul 2012 10:25:21 +0000
Subject: [issue15393] JSONDecoder.raw_decode breaks on leading whitespace
In-Reply-To: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za>
Message-ID: <1342693521.45.0.453581637065.issue15393@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions: +Python 3.3, Python 3.4 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15393>
_______________________________________

From report at bugs.python.org  Thu Jul 19 12:37:46 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 19 Jul 2012 10:37:46 +0000
Subject: [issue15393] JSONDecoder.raw_decode breaks on leading whitespace
In-Reply-To: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za>
Message-ID: <1342694266.07.0.236553008903.issue15393@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Please, post a patch for 2.7 and 3.2/3.3, with a test. Seems quite easy.

If you hurry, this could go in 3.3.0.

----------
keywords: +easy
nosy: +jcea
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15393>
_______________________________________

From report at bugs.python.org  Thu Jul 19 13:40:55 2012
From: report at bugs.python.org (Antti Laine)
Date: Thu, 19 Jul 2012 11:40:55 +0000
Subject: [issue15393] JSONDecoder.raw_decode breaks on leading whitespace
In-Reply-To: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za>
Message-ID: <1342698055.6.0.000747837129523.issue15393@psf.upfronthosting.co.za>


Antti Laine <antti.a.laine at iki.fi> added the comment:

Suggestion for a patch for 3.3.0. I wasn't quite sure how the testcases were supposed to be loaded. Sorry if I made a mess ;)

----------
keywords: +patch
Added file: http://bugs.python.org/file26434/json-raw-decoder-fix-whitespace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15393>
_______________________________________

From report at bugs.python.org  Thu Jul 19 13:45:39 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jul 2012 11:45:39 +0000
Subject: [issue15392] Create a unittest framework for IDLE
In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za>
Message-ID: <1342698339.42.0.715289800287.issue15392@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

All the tests should run from the standard test runner tool (currently regrtest), with the GUI tests guarded by the GUI resource, which is how it works for TK.  I always run the test suite with -uall before non-trivial commits, so I do in fact run the TK gui tests on a regular basis.  I would do the same with idle.  I hope there are at least a few other developers that run with -uall on a regular basis :)

Whether or not there is value in a separate runner is a separate question.  If there is value in having one to you and the other people working on idle, then make one.  But for those of us who touch it only occasionally, the separate runner is not likely to get used.  I wasn't even aware there was one for tkinter.

There was a push a while back suggesting that best practice would be to have all tests be in the 'test' subdirectory.  I moved email/test into test/test_email, and I prefer having it there.  On the other hand, Michael prefers having unittest/test, and has kept the unittest unit tests there.  So that part is up to you, but I encourage you to consider putting them in the test subdirectory, and if you want to do that I would help out with moving the existing tkinter tests to the 'test' dir.

And yes, either way the tests should test for the presence of idle and skip if idle is not available.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15392>
_______________________________________

From report at bugs.python.org  Thu Jul 19 13:54:19 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 19 Jul 2012 11:54:19 +0000
Subject: [issue15393] JSONDecoder.raw_decode breaks on leading whitespace
In-Reply-To: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za>
Message-ID: <1342698859.59.0.77151504737.issue15393@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Antti, you are changing the signature of "decode()" and that would be a compatibility problem. Can you rewrite the patch to be more "compatible"?

In your test, please, use a bit more complicated object than "{}" :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15393>
_______________________________________

From report at bugs.python.org  Thu Jul 19 13:56:18 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jul 2012 11:56:18 +0000
Subject: [issue15393] JSONDecoder.raw_decode breaks on leading whitespace
In-Reply-To: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za>
Message-ID: <1342698978.25.0.694620244187.issue15393@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

IMO this is not a bug, according to the current documentation it is working as designed.  raw_decode says it decodes a string that *starts with* a json document.

To my understanding, raw_decode is designed to be used when parsing a stream containing more than just one json document, including possibly non-json text, in which case it makes sense that the calling application would be responsible for (and want to) handle the whitespace around any such document.

I recommend closing this as invalid.  If the consensus is otherwise and a change is made, I think it would be an enhancement, not a bug fix.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15393>
_______________________________________

From report at bugs.python.org  Thu Jul 19 14:03:06 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jul 2012 12:03:06 +0000
Subject: [issue15393] JSONDecoder.raw_decode breaks on leading whitespace
In-Reply-To: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za>
Message-ID: <1342699386.63.0.491296716142.issue15393@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I see, you are thinking that "json document" includes the possibility of leading whitespace.  That is a reasonable interpretation...just make sure that we don't break backward compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15393>
_______________________________________

From report at bugs.python.org  Thu Jul 19 14:42:51 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Thu, 19 Jul 2012 12:42:51 +0000
Subject: [issue13907] test_pprint relies on set/dictionary repr() ordering
In-Reply-To: <1327877127.5.0.775790034164.issue13907@psf.upfronthosting.co.za>
Message-ID: <1342701771.75.0.669258292427.issue13907@psf.upfronthosting.co.za>


Anton Barkovsky <swarmer.pm at gmail.com> added the comment:

This test breaks now even in CPython. Remove it and be done with it?

----------
nosy: +anton.barkovsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13907>
_______________________________________

From report at bugs.python.org  Thu Jul 19 15:24:56 2012
From: report at bugs.python.org (Julia Lawall)
Date: Thu, 19 Jul 2012 13:24:56 +0000
Subject: [issue15394] memory leak in PyModule_Create2
Message-ID: <1342704296.69.0.163968791178.issue15394@psf.upfronthosting.co.za>


New submission from Julia Lawall <julia.lawall at lip6.fr>:

In objects/moduleobject.c, in the function PyModule_Create2, it appears that m should be decrefed on all of the failure paths between its allocation and the return from the function.

----------
files: moduleobject.patch
keywords: patch
messages: 165838
nosy: jll
priority: normal
severity: normal
status: open
title: memory leak in PyModule_Create2
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file26435/moduleobject.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15394>
_______________________________________

From report at bugs.python.org  Thu Jul 19 15:47:05 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 19 Jul 2012 13:47:05 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1342705625.34.0.87991207724.issue12834@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

In Python 3.3 memoryobject.c is a complete rewrite. Porting the fix
separately would be quite a bit of work.

PyBuffer_ToContiguous(), which causes the problem in 2.7/3.2 and is
still broken in 3.3, could be fixed by using the recursive copy_buffer() 
function from the new memoryobject.c.


I don't know if I can fix it before the 3.3 release. When are the
next 2.7/3.2 releases?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Thu Jul 19 16:08:35 2012
From: report at bugs.python.org (Julia Lawall)
Date: Thu, 19 Jul 2012 14:08:35 +0000
Subject: [issue15395] memory leaks in selectmodule.c
Message-ID: <1342706915.13.0.364498242377.issue15395@psf.upfronthosting.co.za>


New submission from Julia Lawall <julia.lawall at lip6.fr>:

In Modules/selectmodule.c, in the function seq2set, fast_seq should be decrefd on failure of the initialization of o.  This will make a useless call to DECREF on o, but XDECREF is already used, so it is safe in the NULL case.

In the same file, in the function poll_modify, key should be decrefed on all execution paths that lead out of the function.

----------
files: selectmodule.patch
keywords: patch
messages: 165840
nosy: jll
priority: normal
severity: normal
status: open
title: memory leaks in selectmodule.c
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file26436/selectmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15395>
_______________________________________

From report at bugs.python.org  Thu Jul 19 16:18:23 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 19 Jul 2012 14:18:23 +0000
Subject: [issue14811] decoding_fgets() truncates long lines and fails with a
	SyntaxError("Non-UTF-8 code starting with...")
In-Reply-To: <1337056300.81.0.374626607094.issue14811@psf.upfronthosting.co.za>
Message-ID: <1342707503.14.0.346645955649.issue14811@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Are we going to fix this before 3.3? Any objections to Victor's patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14811>
_______________________________________

From report at bugs.python.org  Thu Jul 19 16:35:26 2012
From: report at bugs.python.org (Julia Lawall)
Date: Thu, 19 Jul 2012 14:35:26 +0000
Subject: [issue15396] memory leak in tkinter
Message-ID: <1342708526.81.0.949567135127.issue15396@psf.upfronthosting.co.za>


New submission from Julia Lawall <julia.lawall at lip6.fr>:

In the file Modules/_tkinter.c, in the function PyInit__tkinter, m should be decrefed on the PyType_Ready error path.

----------
files: tkinter.patch
keywords: patch
messages: 165842
nosy: jll
priority: normal
severity: normal
status: open
title: memory leak in tkinter
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file26437/tkinter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15396>
_______________________________________

From report at bugs.python.org  Thu Jul 19 17:02:36 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 19 Jul 2012 15:02:36 +0000
Subject: [issue15394] memory leak in PyModule_Create2
In-Reply-To: <1342704296.69.0.163968791178.issue15394@psf.upfronthosting.co.za>
Message-ID: <1342710156.1.0.115880736319.issue15394@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

This looks OK to me (I don't see a way to write a test case to cover the leak).  I will commit later today unless I hear some objections.

----------
assignee:  -> meador.inge
nosy: +meador.inge
stage:  -> commit review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15394>
_______________________________________

From report at bugs.python.org  Thu Jul 19 17:16:28 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 19 Jul 2012 15:16:28 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1342710988.56.0.0235861497841.issue15364@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

> I'd make get_config_var('srcdir') to be None for installed systems, 
> because the source tree is not available there.

While playing with a version of the patch which returns None for non-source builds, I found that distutils.support._get_xxmodule_path() depends on get_config_var('srcdir') always returning a string:

def _get_xxmodule_path():
    srcdir = sysconfig.get_config_var('srcdir')
    candidates = [
        os.path.join(os.path.dirname(__file__), 'xxmodule.c'),
        os.path.join(srcdir, 'Modules', 'xxmodule.c'),
        os.path.join(srcdir, '..', '..', '..', 'Modules', 'xxmodule.c'),
    ]
    for path in candidates:
        if os.path.exists(path):
            return path

It is easy enough to modify _get_xxmodule_path() to check for None.  But this does suggest that returning None might break some currently working 3rd party code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Thu Jul 19 19:35:32 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Thu, 19 Jul 2012 17:35:32 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342719332.72.0.452476067442.issue15397@psf.upfronthosting.co.za>


Changes by Stefan Mihaila <mstefanro at gmail.com>:


----------
nosy: +alexandre.vassalotti, ncoghlan, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Thu Jul 19 19:29:06 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Thu, 19 Jul 2012 17:29:06 +0000
Subject: [issue15397] Unbinding of methods
Message-ID: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>


New submission from Stefan Mihaila <mstefanro at gmail.com>:

In order to implement pickling of instance methods, a means of separating
the object and the unbound method is necessary.

This is easily done for Python methods (f.__self__ and f.__func__),
but not all of builtins support __func__. Moreover, there currently
appears to be no good way to distinguish functions from bound methods.

As a first step in solving this issue, I have attached a patch which:
1) adds __func__ for all function types
2) adds a few new definitions in the types module (AllFunctionTypes etc.)
3) adds isanyfunction(), isanyboundfunction(), isanyunboundfunction() in
  inspect (admittedly these are bad names)
4) functools.unbind

In case applying this patch is being considered, serious review is necessary,
as I'm not knowledgeable of cpython internals.

----------
components: Library (Lib)
files: func.patch
keywords: patch
messages: 165845
nosy: mstefanro
priority: normal
severity: normal
status: open
title: Unbinding of methods
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file26438/func.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Thu Jul 19 19:54:27 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 19 Jul 2012 17:54:27 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342720467.4.0.164143115573.issue15397@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/issue15397>
_______________________________________

From report at bugs.python.org  Thu Jul 19 20:06:50 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 19 Jul 2012 18:06:50 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342721210.55.0.661557172876.issue15397@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Thu Jul 19 20:09:31 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 19 Jul 2012 18:09:31 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342721371.7.0.28393685734.issue15397@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Can you push patch in form available for review via Rietveld?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Thu Jul 19 20:11:32 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 19 Jul 2012 18:11:32 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342721492.13.0.403255674566.issue15397@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov.ml at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Thu Jul 19 20:26:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Jul 2012 18:26:38 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <3WdNwX25JxzPCr@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9e94eb39aaad by Hynek Schlawack in branch 'default':
#1492704: Make shutil.copyfile() raise a distinct SameFileError
http://hg.python.org/cpython/rev/9e94eb39aaad

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Thu Jul 19 20:30:07 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 19 Jul 2012 18:30:07 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <1342722607.35.0.646767010896.issue1492704@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

As beta2 has been postponed I have already committed it with some slight modifications.

Re: deriving from Error: It doesn't make any sense to do so but this way we're mostly backward compatible. Changing it to EnvironmentError uncovered the two extra changes I added.

That said, thank you for your contribution and please fill out and send in a contribution form so you get a neat little star next to your name in the bug tracker: http://www.python.org/psf/contrib/

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Thu Jul 19 20:33:57 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Thu, 19 Jul 2012 18:33:57 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
Message-ID: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>


New submission from Fl?vio Ribeiro <email at flavioribeiro.com>:

Found a intermittent test on UnicodeFileTests.test_rename method.

Python Version: Python 3.3.0b1
Hg commit hash: 3fbfa61634de
MacOS X version 10.6.8 

How can be reproduced:

bumblebee:~/dev/cpython[] $ for i in {1..10}; do ./python.exe  -m test test_pep277; done
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
test test_pep277 failed -- Traceback (most recent call last):
  File "/Users/flavio.barbosa/dev/cpython/Lib/test/test_pep277.py", line 172, in test_rename
    os.rename("tmp", name)
FileNotFoundError: [Errno 2] No such file or directory: '@test_51143_tmp/8_???'

1 test failed:
    test_pep277
[103879 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
test test_pep277 failed -- Traceback (most recent call last):
  File "/Users/flavio.barbosa/dev/cpython/Lib/test/test_pep277.py", line 172, in test_rename
    os.rename("tmp", name)
FileNotFoundError: [Errno 2] No such file or directory: '@test_51145_tmp/3_Gr??-Gott'

1 test failed:
    test_pep277
[103879 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
test test_pep277 failed -- Traceback (most recent call last):
  File "/Users/flavio.barbosa/dev/cpython/Lib/test/test_pep277.py", line 172, in test_rename
    os.rename("tmp", name)
FileNotFoundError: [Errno 2] No such file or directory: '@test_51147_tmp/6_???'

1 test failed:
    test_pep277
[103879 refs]

----------
assignee: ronaldoussoren
components: Macintosh
messages: 165849
nosy: flavio.ribeiro, ronaldoussoren
priority: normal
severity: normal
status: open
title: intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Thu Jul 19 20:36:30 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 19 Jul 2012 18:36:30 +0000
Subject: [issue15038] Optimize python Locks on Windows
In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za>
Message-ID: <1342722990.56.0.959289354877.issue15038@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I see dead code here:

Py_LOCAL_INLINE(int)
PyCOND_BROADCAST(PyCOND_T *cv)
{
    if (cv->waiting > 0) {
        return ReleaseSemaphore(cv->sem, cv->waiting, NULL) ? 0 : -1;
		cv->waiting = 0;
    }
    return 0;
}

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15038>
_______________________________________

From report at bugs.python.org  Thu Jul 19 20:37:04 2012
From: report at bugs.python.org (Tatiana Al-Chueyr)
Date: Thu, 19 Jul 2012 18:37:04 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342723024.14.0.0409353053418.issue15398@psf.upfronthosting.co.za>


Tatiana Al-Chueyr <tatiana.alchueyr at gmail.com> added the comment:

I had the same problem here, after running several times...

 $ for i in {1..10}; do ./python.exe  -m test test_pep277; done
[1/1] test_pep277
test test_pep277 failed -- Traceback (most recent call last):
  File "/Users/tatiana/code/cpython/Lib/test/test_pep277.py", line 172, in test_rename
    os.rename("tmp", name)
FileNotFoundError: [Errno 2] No such file or directory: '@test_6002_tmp/2_ascii'

1 test failed:
    test_pep277
[1/1] test_pep277
1 test OK.
[1/1] test_pep277
1 test OK.
[1/1] test_pep277
1 test OK.
[1/1] test_pep277
1 test OK.
[1/1] test_pep277
1 test OK.
[1/1] test_pep277
test test_pep277 failed -- Traceback (most recent call last):
  File "/Users/tatiana/code/cpython/Lib/test/test_pep277.py", line 172, in test_rename
    os.rename("tmp", name)
FileNotFoundError: [Errno 2] No such file or directory: '@test_6033_tmp/6_???'

1 test failed:
    test_pep277
[1/1] test_pep277
1 test OK.
[1/1] test_pep277
test test_pep277 failed -- Traceback (most recent call last):
  File "/Users/tatiana/code/cpython/Lib/test/test_pep277.py", line 172, in test_rename
    os.rename("tmp", name)
FileNotFoundError: [Errno 2] No such file or directory: '@test_6041_tmp/8_???'

1 test failed:
    test_pep277
[1/1] test_pep277
1 test OK.

----------
nosy: +tati_alchueyr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Thu Jul 19 20:40:51 2012
From: report at bugs.python.org (Gunnlaugur Thor Briem)
Date: Thu, 19 Jul 2012 18:40:51 +0000
Subject: [issue15399] processName key is un-/mis-documented in 2.6 and up
Message-ID: <1342723251.3.0.517934021782.issue15399@psf.upfronthosting.co.za>


New submission from Gunnlaugur Thor Briem <gunnlaugur at gmail.com>:

The ``processName`` format mapping key in logging formats works in versions 2.6.*, 2.7.* and 3.1.* onwards; in 2.5 and down and in 3.0.1, ``format`` fails when this key is present in the format.

But in 2.6.8 docs, this mapping key is not documented:

http://docs.python.org/release/2.6.8/library/logging.html
http://docs.python.org/release/3.0.1/library/logging.html

and in 2.7.3 and 3.1.5 and 3.2.3 docs, it is documented but there is no note that it is new in any particular version (unlike ``funcName``, for which there is ?Changed in version 2.5: funcName was added?):

http://docs.python.org/release/2.7.3/library/logging.html
http://docs.python.org/release/3.1.5/library/logging.html
http://docs.python.org/release/3.2.3/library/logging.html

Consistent with (what I think are the) version note conventions, these seem like the actions to take:

- In 2.6 docs, add processName, and insert the note ?Changed in version 2.6: processName was added?

- In 2.7 docs, insert that same note

- In docs for 3.1 and up, insert the note ?Changed in version 3.1: processName was added?

----------
assignee: docs at python
components: Documentation
messages: 165852
nosy: docs at python, gthb
priority: normal
severity: normal
status: open
title: processName key is un-/mis-documented in 2.6 and up
type: enhancement
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/issue15399>
_______________________________________

From report at bugs.python.org  Thu Jul 19 20:52:41 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Jul 2012 18:52:41 +0000
Subject: [issue15394] memory leak in PyModule_Create2
In-Reply-To: <1342704296.69.0.163968791178.issue15394@psf.upfronthosting.co.za>
Message-ID: <3WdPVc1FG9zPMW@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7140d97d36fd by Meador Inge in branch '3.2':
Issue #15394: Fix ref leaks in PyModule_Create.
http://hg.python.org/cpython/rev/7140d97d36fd

New changeset 571777bf5527 by Meador Inge in branch 'default':
Issue #15394: Fix ref leaks in PyModule_Create.
http://hg.python.org/cpython/rev/571777bf5527

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15394>
_______________________________________

From report at bugs.python.org  Thu Jul 19 20:55:28 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 19 Jul 2012 18:55:28 +0000
Subject: [issue15394] memory leak in PyModule_Create2
In-Reply-To: <1342704296.69.0.163968791178.issue15394@psf.upfronthosting.co.za>
Message-ID: <1342724128.8.0.76867101344.issue15394@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Thanks for the patch Julia!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15394>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:07:23 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Thu, 19 Jul 2012 19:07:23 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342724843.62.0.419259506951.issue15397@psf.upfronthosting.co.za>


Stefan Mihaila <mstefanro at gmail.com> added the comment:

Yes, the patch is at http://codereview.appspot.com/6425052/
The code there also contains some tests I've written for functools.unbind.

----------
Added file: http://bugs.python.org/file26439/unbind_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:07:44 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 19 Jul 2012 19:07:44 +0000
Subject: [issue15394] memory leak in PyModule_Create2
In-Reply-To: <1342704296.69.0.163968791178.issue15394@psf.upfronthosting.co.za>
Message-ID: <1342724864.6.0.859460092207.issue15394@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/issue15394>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:14:55 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 19 Jul 2012 19:14:55 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <1342725295.69.0.661694624379.issue1492704@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Did you get an exception from the release manager for this new feature?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:16:18 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jul 2012 19:16:18 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342725378.37.0.065872961755.issue15398@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

By the way, you can use -F to run the test suite until it fails:

  ./python -m test -F test_pep277

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:17:13 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jul 2012 19:17:13 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342725433.14.0.511621671083.issue15398@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Tatiana, are you on a Mac as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:19:10 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Jul 2012 19:19:10 +0000
Subject: [issue15396] memory leak in tkinter
In-Reply-To: <1342708526.81.0.949567135127.issue15396@psf.upfronthosting.co.za>
Message-ID: <3WdQ590VWdzMFl@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b584c58c2286 by Jesus Cea in branch '3.2':
Closes #15396: memory leak in tkinter
http://hg.python.org/cpython/rev/b584c58c2286

New changeset b2dac78db1c9 by Jesus Cea in branch 'default':
MERGE: Closes #15396: memory leak in tkinter
http://hg.python.org/cpython/rev/b2dac78db1c9

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15396>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:19:59 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jul 2012 19:19:59 +0000
Subject: [issue15399] processName key is un-/mis-documented in 2.6 and up
In-Reply-To: <1342723251.3.0.517934021782.issue15399@psf.upfronthosting.co.za>
Message-ID: <1342725599.56.0.833053191652.issue15399@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We only update the docs for the active versions, so only 2.7, 3.2, and default (3.3) are going to get updated.

----------
nosy: +r.david.murray, vinay.sajip
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15399>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:20:58 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 19 Jul 2012 19:20:58 +0000
Subject: [issue15396] memory leak in tkinter
In-Reply-To: <1342708526.81.0.949567135127.issue15396@psf.upfronthosting.co.za>
Message-ID: <1342725658.56.0.492460646743.issue15396@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Thanks for the patch, Julia, and for submitting the contributor form. I have added you too to the "Doc/ACKS.txt" file.

I wonder how you found this...

----------
nosy: +jcea
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15396>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:21:43 2012
From: report at bugs.python.org (Michael Smith)
Date: Thu, 19 Jul 2012 19:21:43 +0000
Subject: [issue15400] int('12345L', 10) raises ValueError
Message-ID: <1342725703.62.0.185151812614.issue15400@psf.upfronthosting.co.za>


New submission from Michael Smith <kojiromike at gmail.com>:

The trailing 'L' in representations of long integers causes the int function to raise a ValueError. This is unexpected because it's reasonable to expect that `int` should be able to parse a number from any string when that string represented as a bare word would be a valid python number. The following all raise ValueError:

int(hex(12345L), 16)
int(oct(12345L), 8)

but not

int('12345', 10)
int(hex(12345), 16)
int(oct(12345), 8)
(and not bin() because of http://bugs.python.org/issue3186)

----------
components: Interpreter Core
messages: 165862
nosy: Michael.Smith
priority: normal
severity: normal
status: open
title: int('12345L', 10) raises ValueError
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15400>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:22:34 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 19 Jul 2012 19:22:34 +0000
Subject: [issue15396] memory leak in tkinter
In-Reply-To: <1342708526.81.0.949567135127.issue15396@psf.upfronthosting.co.za>
Message-ID: <1342725754.21.0.693833353682.issue15396@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15396>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:22:43 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 19 Jul 2012 19:22:43 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <1342725763.34.0.555553146945.issue1492704@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Oh my understanding was that it was pushed to 3.4 only because of the then imminent beta2. Georg, is it okay to keep it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:23:05 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 19 Jul 2012 19:23:05 +0000
Subject: [issue15396] memory leak in tkinter
In-Reply-To: <1342708526.81.0.949567135127.issue15396@psf.upfronthosting.co.za>
Message-ID: <1342725785.71.0.10097753714.issue15396@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15396>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:23:18 2012
From: report at bugs.python.org (Tatiana Al-Chueyr)
Date: Thu, 19 Jul 2012 19:23:18 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342725798.6.0.563743728634.issue15398@psf.upfronthosting.co.za>


Tatiana Al-Chueyr <tatiana.alchueyr at gmail.com> added the comment:

r.david.murray: yes, MacOS X 10.6.8

we managed to reproduce this in other 2 MacBook Pro 8.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:25:46 2012
From: report at bugs.python.org (Hugo Lopes Tavares)
Date: Thu, 19 Jul 2012 19:25:46 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342725946.84.0.778968460656.issue15398@psf.upfronthosting.co.za>


Hugo Lopes Tavares <hltbra at gmail.com> added the comment:

I had no problems after running for a very long time (using -F). I am using Mac OSX 10.6.8.

----------
nosy: +hltbra

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:29:19 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 19 Jul 2012 19:29:19 +0000
Subject: [issue15395] memory leaks in selectmodule.c
In-Reply-To: <1342706915.13.0.364498242377.issue15395@psf.upfronthosting.co.za>
Message-ID: <1342726159.97.0.669053045754.issue15395@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15395>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:31:58 2012
From: report at bugs.python.org (Julia Lawall)
Date: Thu, 19 Jul 2012 19:31:58 +0000
Subject: [issue15396] memory leak in tkinter
In-Reply-To: <1342725658.56.0.492460646743.issue15396@psf.upfronthosting.co.za>
Message-ID: <alpine.DEB.2.02.1207192127010.1980@localhost6.localdomain6>


Julia Lawall <julia.lawall at lip6.fr> added the comment:

On Thu, 19 Jul 2012, Jes?s Cea Avi?n wrote:

>
> Jes?s Cea Avi?n <jcea at jcea.es> added the comment:
>
> Thanks for the patch, Julia, and for submitting the contributor form. I have added you too to the "Doc/ACKS.txt" file.
>
> I wonder how you found this...

My PhD student Suman Saha has developed a tool that finds faults in error 
handling code by checking whether the error handling code within a 
function is self-consistent.  So if one failure branch frees x, and the 
next one does not, there is a problem, unless x was freed along the way.

A preliminary description of the work is in the following paper:

S. Saha, Julia L. Lawall, G. Muller : ?Finding Resource-Release Omission 
Faults in Linux?, 6th Workshop on Programming Languages and Operating 
Systems, Cascais, Portugal (2011)

http://pagesperso-systeme.lip6.fr/Suman.Saha/src/plos11.pdf

That paper just has results for Linux, but we are working on applying it 
to other software, including python.

julia

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15396>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:33:20 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Jul 2012 19:33:20 +0000
Subject: [issue15395] memory leaks in selectmodule.c
In-Reply-To: <1342706915.13.0.364498242377.issue15395@psf.upfronthosting.co.za>
Message-ID: <3WdQPW1sBszPMh@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bc9b2956bb8b by Jesus Cea in branch '3.2':
Closes #15395: memory leaks in selectmodule.c
http://hg.python.org/cpython/rev/bc9b2956bb8b

New changeset 9985b4651436 by Jesus Cea in branch 'default':
MERGE: Closes #15395: memory leaks in selectmodule.c
http://hg.python.org/cpython/rev/9985b4651436

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15395>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:34:27 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 19 Jul 2012 19:34:27 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <1342726467.73.0.14562924817.issue1492704@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sorry, looks like a feature to me.  Please wait for 3.4 with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:38:10 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 19 Jul 2012 19:38:10 +0000
Subject: [issue13888] test_builtin failure when run after test_tk
In-Reply-To: <1327661656.8.0.445863136974.issue13888@psf.upfronthosting.co.za>
Message-ID: <1342726690.98.0.560892770745.issue13888@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is not a problem on Windows because the failing tests are skipped.

test_input_tty (test.test_builtin.BuiltinTest) ... skipped
'the pty and signal modules must be available'
test_input_tty_non_ascii (test.test_builtin.BuiltinTest) ... skipped 'the pty and signal modules must be available'
test_input_tty_non_ascii_unicode_errors (test.test_builtin.BuiltinTest) ... skipped
'the pty and signal modules must be available'

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13888>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:40:49 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 19 Jul 2012 19:40:49 +0000
Subject: [issue15400] int('12345L', 10) raises ValueError
In-Reply-To: <1342725703.62.0.185151812614.issue15400@psf.upfronthosting.co.za>
Message-ID: <1342726849.67.0.870934444388.issue15400@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

This problem is real but 2.7 is open only for bugfixes (no enhancements) and 3.x doesn't generate the "l" suffix anymore.

I am closing this issue as "won't fix". If you think this is a mistake, please reopen and argument it.

----------
nosy: +jcea
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15400>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:43:23 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 19 Jul 2012 19:43:23 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <1342727003.01.0.498456357351.issue1492704@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Ok sorry, backing out.

----------
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:43:40 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Jul 2012 19:43:40 +0000
Subject: [issue1492704] distinct error type if shutil.copyfile() fails because
	of src and dst are the same file
Message-ID: <3WdQdQ5SWszMFl@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3adb4ee4b794 by Hynek Schlawack in branch 'default':
#1492704: Backout and wait for 3.4
http://hg.python.org/cpython/rev/3adb4ee4b794

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:45:38 2012
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 19 Jul 2012 19:45:38 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342727138.03.0.892104310884.issue15397@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +daniel.urban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Thu Jul 19 22:00:56 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 19 Jul 2012 20:00:56 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342728056.57.0.872170090322.issue15397@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Looks like PyCFunction_NewEx is part of Stable API.
If I'm right you have to make stub for this one as simple trampoline to new PyCFunction_NewExEx implementation.

Martin, please confirm.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Thu Jul 19 22:23:25 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 19 Jul 2012 20:23:25 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342729405.27.0.689088466666.issue15397@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Andrew is right: PyCFunction_NewEx must stay, and must continue to get the same parameters as it currently does. This not only applies to extensions already built, but also to extensions that are built against the new header files: they still need to run under old Python releases (if they only use the stable ABI).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Thu Jul 19 22:40:13 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Thu, 19 Jul 2012 20:40:13 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342730413.72.0.464161206908.issue15398@psf.upfronthosting.co.za>


Fl?vio Ribeiro <email at flavioribeiro.com> added the comment:

For doc purposes:

My first shot is that in my machine the os.rename isn't atomic and this could be generating an overhead somehow. Looking at the code, I found decisions being made on posixmodule.c about what `rename` function should be used:

 #ifdef HAVE_RENAMEAT
     if (dir_fd_specified)
         result = renameat(src_dir_fd, src.narrow, dst_dir_fd, dst.narrow);
     else
 #endif
         result = rename(src.narrow, dst.narrow);
     Py_END_ALLOW_THREADS
 

In my machine the second `rename` is being used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Thu Jul 19 22:51:27 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Jul 2012 20:51:27 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342731086.99.0.0543316461986.issue15398@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I haven't been able to reproduce this failure on either 10.6 or 10.7 with or without pydebug and either at 3fbfa61634de or the now slightly more current tip.  What filesystem are you running the test under?  What ./configure options did you use?  What compiler did you use?  What environment variables are defined especially LANG or LC_* ones?

----------
assignee: ronaldoussoren -> 
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Thu Jul 19 23:00:41 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Jul 2012 21:00:41 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342731641.01.0.0773125240595.issue15398@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

And OS X doesn't support the *at system calls so HAVE_RENAMEAT will always be false on OS X.  I don't recall every seeing this test fail before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Thu Jul 19 23:03:00 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Jul 2012 21:03:00 +0000
Subject: [issue15365] Traceback reporting can fail if IO cannot be imported
In-Reply-To: <1342434495.02.0.347473954517.issue15365@psf.upfronthosting.co.za>
Message-ID: <3WdSNx5TjzzNwg@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 54524897fafc by Kristj?n Valur J?nsson in branch 'default':
Issue #15365:  Make traceback reporting ignore any errors when printing out
http://hg.python.org/cpython/rev/54524897fafc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15365>
_______________________________________

From report at bugs.python.org  Thu Jul 19 23:34:26 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jul 2012 21:34:26 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342733666.16.0.502515751072.issue15398@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I found this link:

  http://www.weirdnet.nl/apple/rename.html

in issue 8828, which sounds like it is relevant.  (I thought I remembered something about rename not being atomic on OS X.)  I didn't read it through, but maybe Apple fixed the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Thu Jul 19 23:48:10 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Thu, 19 Jul 2012 21:48:10 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342734490.02.0.19897467921.issue15398@psf.upfronthosting.co.za>


Fl?vio Ribeiro <email at flavioribeiro.com> added the comment:

Hi Ned,

I've used ./configure --with-pydebug && make -j2

$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 Free Software Foundation, Inc.

$ printenv | grep LC_
$ printenv| grep LANG
LANG=en_US.UTF-8

$ mount
/dev/disk0s2 on / (hfs, local, journaled)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Thu Jul 19 23:50:51 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Thu, 19 Jul 2012 21:50:51 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342734651.1.0.846863858026.issue15397@psf.upfronthosting.co.za>


Stefan Mihaila <mstefanro at gmail.com> added the comment:

Doesn't the definition I've added at the end of methodobject.c suffice? (http://codereview.appspot.com/6425052/patch/1/10) Or should the macro be removed altogether?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Fri Jul 20 00:00:23 2012
From: report at bugs.python.org (Juarez Bochi)
Date: Thu, 19 Jul 2012 22:00:23 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1342735223.68.0.747598067772.issue1100942@psf.upfronthosting.co.za>


Juarez Bochi <jbochi at gmail.com> added the comment:

I have updated the patches since they were not applying cleanly and included a pure Python implementation that was missing.

It has the same issues that were mentioned on msg107402.

Do you have any suggestions? I'm planning to block the formats that are not allowed and raise Exceptions like suggested before:

>>> date.strptime('01', '%M')
...
"'%M' is not valid in date format specification."

----------
nosy: +Juarez.Bochi
Added file: http://bugs.python.org/file26440/issue1100942_pure.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Fri Jul 20 00:04:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Jul 2012 22:04:36 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342735476.6.0.0620142669888.issue15381@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Here is a preliminary version of the patch.

I don't understand the purpose of your patch. It just replaces a direct realloc() call with an indirect one (since _PyBytes_Resize() will call realloc() internally).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 00:06:21 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Jul 2012 22:06:21 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342735476.6.0.0620142669888.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342735472.3344.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Here is a preliminary version of the patch.
> 
> I don't understand the purpose of your patch. It just replaces a
> direct realloc() call with an indirect one (since _PyBytes_Resize()
> will call realloc() internally).

Ok, I understand. You're trying to make the getvalue() call cheaper,
right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 00:37:59 2012
From: report at bugs.python.org (Hugo Lopes Tavares)
Date: Thu, 19 Jul 2012 22:37:59 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1342737479.85.0.226805288556.issue13592@psf.upfronthosting.co.za>


Hugo Lopes Tavares <hltbra at gmail.com> added the comment:

Hey, I started the patch under `default` branch, and get the following working:

    >>> import re
    >>> re.compile("foo")
    re.compile("foo", re.UNICODE)
    >>> re.compile("foo", re.DOTALL)
    re.compile("foo", re.DOTALL|re.UNICODE)
    >>> re.compile("foo", re.DOTALL|re.MULTILINE)
    re.compile("foo", re.MULTILINE|re.DOTALL|re.UNICODE)
    >>>

Do you have any comments on it?

I want to adapt the patch to make it work with python 2.7 too. Do you think is it worthful?

The attached patch was done after commit 3fbfa61634de.

----------
keywords: +patch
nosy: +hltbra
Added file: http://bugs.python.org/file26441/issue13592_add_repr_to_regex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Fri Jul 20 00:38:48 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Jul 2012 22:38:48 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342737528.51.0.402065698105.issue15398@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks, Fl?vio.  That configuration looks perfectly normal and what I use so that should not be an issue.

Interesting link, David.  I'm not able to reproduce that failure on 10.6.8 using the procedure in the link but I am running 10.6.8 on a virtual machine so that isn't conclusive.  The author says that the problem is fixed in 10.7' so it's not surprising that I can't reproduce it on a non-virtual 10.7, either.  I guess it would be interesting to know if Fl?vio or Tatiana can duplicate the results of the blog post.  It would also be interesting to know if test_pep277 also fails in the same environment with Python 3.2.

But, assuming the issue is OS-related, I don't see what we should do about it other than possibly adding a comment to the test.  Opinions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Fri Jul 20 00:56:56 2012
From: report at bugs.python.org (Igor Sobreira)
Date: Thu, 19 Jul 2012 22:56:56 +0000
Subject: [issue15010] unittest: _top_level_dir is incorrectly persisted
	between calls to different load_test methods
In-Reply-To: <1338945643.44.0.808523506511.issue15010@psf.upfronthosting.co.za>
Message-ID: <1342738616.86.0.61760024224.issue15010@psf.upfronthosting.co.za>


Igor Sobreira <igor at igorsobreira.com> added the comment:

Hello. I've attached a patch to cleanup self._top_level_dir in the end of discover(). Is that the expected behavior or I'm on the wrong track?

----------
keywords: +patch
nosy: +igorsobreira
Added file: http://bugs.python.org/file26442/restore_top_level_dir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15010>
_______________________________________

From report at bugs.python.org  Fri Jul 20 01:21:51 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 19 Jul 2012 23:21:51 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1342740111.43.0.0586923435631.issue10652@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think this test disabling and failure issue should get some attention.
Do the failures happen on non-Windows systems too?

With installed 3.3.0b1 on Win7, test___all__, test_tcl, test_tk, test_ttk_textonly, and test_ttk_guionly all run if run first (_tk and _ttk_guionly with -ugui). All modify os.environ, resulting in
Warning -- os.environ was modified by test_xxx
and all disable at least one of the other tests run afterward. (test___all__ disables but is not disabled itself.) In standard alphabetic running order, test___all__ 'wins'.

I would like to add test/test_idle, #15392, but I presume it currently would also not run after test___all__ or any of the others.

---
I patched my installation, but without the unneeded temporary (saved_values = self.saved_values is only an optimization for the repeated access in the loop that follows).
        sys.modules.clear()
        sys.modules.update(self.saved_modules)
        del self.saved_modules

With this,
python -m test -ugui test___all__ test_tcl test_tk test_ttk_guionly test_ttk_textonly
runs and passes all five tests instead of two (test___all__ and test_ttk_textonly).

Unfortunately, it causes new failures running the entire test suite:
test_concurrent_futures (ok before)
test_decimal (ok before)
test_email (numberous failures, just one before)
I stopped at test_faulthandler, there might be more but this was enough to reject the patch as is. 

I decided to try the principle of doing the minimum necessary to get the tests to pass. I arrived at the following, which lets all five tests run and pass, at least when run in the given order. 

        try:
            del sys.modules['tkinter']
            del sys.modules['tkinter._fix']
            del sys.modules['tkinter.ttk']
            del sys.modules['tkinter.test']
            del sys.modules['tkinter.test.support']
            del sys.modules['tkinter.test.runtktests']
        except KeyError:
            pass

The only new failure with python -m test is test_multi-processing, which normally does not even give a warning.

[197/368/6] test_multiprocessing
Warning -- multiprocessing.process._dangling was modified by test_multiprocessing
test test_multiprocessing failed -- Traceback (most recent call last):
  File "C:\Programs\Python33\lib\test\test_multiprocessing.py", line 1909, in test_mymanager_context_prestarted
    self.assertEqual(manager._process.exitcode, 0)
AssertionError: -15 != 0

This might be an unrelated, intermittant failure.

Since the exception above will trigger for nearly all tests (costly), and since the above does not guarantee to delete all tkinter.* modules, and since future tkinter tests might expand to test other subpackages and idle tests will import other subpackages, I tried this in __exit__.

        if 'tkinter' in sys.modules:
            sysmod = sys.modules
            tknames = set()
            for name in sysmod:
                if name.startswith('tkinter'):
                    tknames.add(name)
            for name in tknames:
                del sysmod[name]

So aside from the initial test, the extra time is only used when needed. All five tests run and pass and there are no new failures with python -m test. Before:

[368/368/7] test_zlib
316 tests OK.
7 tests failed:
    test_asyncore test_datetime test_distutils test_email test_ftplib
    test_import test_tcl
2 tests altered the execution environment:
    test___all__ test_builtin
43 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_crypt test_curses
    test_dbm_gnu test_dbm_ndbm test_devpoll test_epoll test_fcntl
    test_fork1 test_gdb test_grp test_ioctl test_kqueue test_largefile
    test_nis test_openpty test_ossaudiodev test_pipes test_poll
    test_posix test_pty test_pwd test_readline test_resource
    test_smtpnet test_socketserver test_syslog test_threadsignals
    test_timeout test_tk test_tools test_ttk_guionly test_urllib2net
    test_urllibnet test_wait3 test_wait4 test_winsound test_xmlrpc_net
    test_zipfile64
5 skips unexpected on win32:
    test_gdb test_readline test_tk test_tools test_ttk_guionly

After:
315 tests OK.
6 tests failed:
    test_asyncore test_datetime test_distutils test_email test_ftplib
    test_import
4 tests altered the execution environment:
    test___all__ test_builtin test_tcl test_ttk_textonly
43 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_crypt test_curses
    test_dbm_gnu test_dbm_ndbm test_devpoll test_epoll test_fcntl
    test_fork1 test_gdb test_grp test_ioctl test_kqueue test_largefile
    test_nis test_openpty test_ossaudiodev test_pipes test_poll
    test_posix test_pty test_pwd test_readline test_resource
    test_smtpnet test_socketserver test_syslog test_threadsignals
    test_timeout test_tk test_tools test_ttk_guionly test_urllib2net
    test_urllibnet test_wait3 test_wait4 test_winsound test_xmlrpc_net
    test_zipfile64
3 skips unexpected on win32:
    test_gdb test_readline test_tools

I am puzzled why one less failure and two fewer unexpected skips means one few test ok. Is that because of the two more warnings?

Running with -ugui will cause test_tk and test_ttk_guionly to run instead of skip. So the above patch seems to be a pure win on Windows. What about other systems? And do any of you test experts have anything better?

----------
nosy: +ezio.melotti, michael.foord, pitrou, r.david.murray, terry.reedy
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Fri Jul 20 01:23:25 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 19 Jul 2012 23:23:25 +0000
Subject: [issue15392] Create a unittest framework for IDLE
In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za>
Message-ID: <1342740205.85.0.274796866927.issue15392@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I have not really used unittest, so I only know to blindly copy what has been done. Hence I need help to do better.

Do you actually get gui tests for test_tk? When I run test/test_tk from Idle editor, and hence as __main__, I only get non-gui tests in spite of enable_gui being set True. Or maybe I just did not see them. (This is actually an improvement over the normal failure of test_tk on Windows. See #10652)

Is tkinter/test/runtktests properly called a test runner?
test/test_tk uses it to gather the tests to run:
support.run_unittest(
    *runtktests.get_tests(text=False, packages=['test_tkinter']))
It is used within the ttk tests also. As I suggested above, I do not really know if we really need the equivalent.

I strongly prefer idlelib/test since it will make developing **much** easier for me on Windows. Also, it would be part of the optional install of idlelib, as tkinter/test is for tkinter.

Adding test/test_idle will not be too much use until issue #10652 is resolved so it would actually run with -m test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15392>
_______________________________________

From report at bugs.python.org  Fri Jul 20 01:31:43 2012
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 19 Jul 2012 23:31:43 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1342740703.26.0.153088952868.issue13592@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Python 2.7 is the end of the Python 2 line, and it's closed except for security fixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Fri Jul 20 01:39:42 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 19 Jul 2012 23:39:42 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1342741182.53.0.816702560912.issue13592@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.7 is on extended maintenance for normal bugs, but does not get new features/enhancements. It is too late for 3.3 also.

----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Fri Jul 20 02:27:48 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 00:27:48 +0000
Subject: [issue14596] struct.unpack memory leak
In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za>
Message-ID: <1342744068.34.0.817081620296.issue14596@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I just read through all this and see three separate points be discussed:

  1. The unbounded caching behavior.
  2. A more compact representation for repeat counts.
  3. Correct __sizeof__ support for struct.

For issue (1) I think this is unfortunate, but I don't think any code changes are required because there is already a way to get the cached and uncached behavior by using the free function or a Struct object, respectively.  I do think adjusting the documentation is appropriate.

As a side note, we do have a private function named 'struct._clearcache' that is used by the regression tests.  If others really think the caching is a problem we could make that public.

Issues (2) and (3) are hijacking this issue IMO.  However, since they are being discussed...  I already implemented something like (2) when reworking the struct data structures for PEP 3118 in issue3132.  Hopefully I will get the PEP 3118 patch pushed through one of these days.

I do think issue (3) should be fixed, but a separate issue should be opened for it.  This issue should just address the caching behavior.  Serhiy, if you open another issue for the __sizeof__ change, then I promise to review ASAP.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14596>
_______________________________________

From report at bugs.python.org  Fri Jul 20 03:12:30 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Jul 2012 01:12:30 +0000
Subject: [issue15401] Typo in inspect.getclosurevars docstring
Message-ID: <1342746750.35.0.68261172869.issue15401@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

s/dics/dicts/

http://hg.python.org/cpython/file/default/Lib/inspect.py#l1049

----------
assignee: ncoghlan
messages: 165893
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Typo in inspect.getclosurevars docstring

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15401>
_______________________________________

From report at bugs.python.org  Fri Jul 20 03:17:21 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Jul 2012 01:17:21 +0000
Subject: [issue15384] pkgutil importlib migration test was failing on Windows
	buildbots
In-Reply-To: <1342608363.39.0.672383016327.issue15384@psf.upfronthosting.co.za>
Message-ID: <1342747041.13.0.627382808783.issue15384@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, that makes sense - since the zip file doesn't exist on buildbots, returning None is the correct result.

Mystery explained, thanks :)

----------
resolution:  -> invalid
status: open -> closed
title: pkgutil.get_importer("") was returning None on Windows buildbots -> pkgutil importlib migration test was failing on Windows buildbots

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15384>
_______________________________________

From report at bugs.python.org  Fri Jul 20 03:17:57 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Jul 2012 01:17:57 +0000
Subject: [issue15386] Still getting two copies of importlib._bootstrap
In-Reply-To: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>
Message-ID: <1342747077.47.0.186047041693.issue15386@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15386>
_______________________________________

From report at bugs.python.org  Fri Jul 20 03:54:53 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 01:54:53 +0000
Subject: [issue15386] Still getting two copies of importlib._bootstrap
In-Reply-To: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>
Message-ID: <1342749293.2.0.512503477749.issue15386@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/issue15386>
_______________________________________

From report at bugs.python.org  Fri Jul 20 04:15:13 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 02:15:13 +0000
Subject: [issue15400] int('12345L', 10) raises ValueError
In-Reply-To: <1342725703.62.0.185151812614.issue15400@psf.upfronthosting.co.za>
Message-ID: <1342750513.62.0.441734578376.issue15400@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

It could be argued that this is a bug fix for 2.7.  I find the current behavior odd at best since 'int' already accepts 'long' objects, but not the string representation of a 'long' object:

>>> sys.maxint
9223372036854775807
>>> sys.maxint + 1
9223372036854775808L
>>> int(sys.maxint)
9223372036854775807
>>> int(sys.maxint + 1)
9223372036854775808L
>>> int(9223372036854775807)
9223372036854775807
>>> int('9223372036854775807')
9223372036854775807
>>> int(9223372036854775808L)
9223372036854775808L
>>> int('9223372036854775808L')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '9223372036854775808L'
>>> long('9223372036854775808L')
9223372036854775808L
>>> int(1)
1
>>> int('1L')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '1L'

Let's discuss this a bit before closing it.  What do others think?

----------
nosy: +meador.inge
resolution: wont fix -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15400>
_______________________________________

From report at bugs.python.org  Fri Jul 20 04:33:57 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jul 2012 02:33:57 +0000
Subject: [issue15401] Typo in inspect.getclosurevars docstring
In-Reply-To: <1342746750.35.0.68261172869.issue15401@psf.upfronthosting.co.za>
Message-ID: <3Wdbkq5TSYzPBM@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset abc26b51fbfc by Meador Inge in branch 'default':
Issue #15401: Fix typo in inspect.getclosurevars docstring.
http://hg.python.org/cpython/rev/abc26b51fbfc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15401>
_______________________________________

From report at bugs.python.org  Fri Jul 20 04:36:42 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 02:36:42 +0000
Subject: [issue15401] Typo in inspect.getclosurevars docstring
In-Reply-To: <1342746750.35.0.68261172869.issue15401@psf.upfronthosting.co.za>
Message-ID: <1342751802.53.0.572573342997.issue15401@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Whoops.  Nick, I missed that this was assigned to you when I committed a fix.  Sorry about that.

----------
nosy: +meador.inge
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15401>
_______________________________________

From report at bugs.python.org  Fri Jul 20 05:15:38 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 03:15:38 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342754138.9.0.354120471274.issue15381@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/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 05:42:11 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 03:42:11 +0000
Subject: [issue14201] Documented caching for shared library's __getattr__ and
	__getitem__ is incorrect
In-Reply-To: <1330957421.08.0.5889949548.issue14201@psf.upfronthosting.co.za>
Message-ID: <1342755731.67.0.291058234225.issue14201@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

The general wording and example look good;  thanks.  I reworded things a little.  Updated patch attached.

----------
stage: needs patch -> commit review
Added file: http://bugs.python.org/file26443/issue14201-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14201>
_______________________________________

From report at bugs.python.org  Fri Jul 20 06:11:08 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Jul 2012 04:11:08 +0000
Subject: [issue15401] Typo in inspect.getclosurevars docstring
In-Reply-To: <1342746750.35.0.68261172869.issue15401@psf.upfronthosting.co.za>
Message-ID: <1342757468.33.0.168319677417.issue15401@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No worries - I only did that as a reminder to fix it when I got home tonight. It's bugs like this where I wish we had the infrastructure for Github-style online code editing set up :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15401>
_______________________________________

From report at bugs.python.org  Fri Jul 20 08:12:08 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 20 Jul 2012 06:12:08 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342764728.18.0.00483377862974.issue15398@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Whether or not rename is atomic should be irrelevant for test_rename. Test_rename "just" performs renames in a tight loop and doesn't do concurrent access from another thread.

The test result seems to indicate that rename() sometimes isn't done yet when the sys call returns (or even that it fails silently), which would be even worse than it not being atomic.

That said, I cannot reproduce using Python 3.3.0b1 (default:abc26b51fbfc, Jul 20 2012, 07:50:15) on an OSX 10.7 system.

I'm currently rebuilding for a test run on a OSX 10.5.8 machine on real hardware.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Fri Jul 20 08:42:59 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Jul 2012 06:42:59 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342735472.3344.5.camel@localhost.localdomain>
Message-ID: <201207200942.41130.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Ok, I understand. You're trying to make the getvalue() call cheaper,
> right?

Yes, it saves up to half of time on large data (on Linux). It would be 
interesting to see the results of these microbenchmarks on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 08:49:26 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Jul 2012 06:49:26 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
Message-ID: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Here is a patch that implements __sizeof__ for struct.Struct.

See also issue14596.

----------
components: Library (Lib)
files: struct_sizeof-2.patch
keywords: patch
messages: 165902
nosy: mark.dickinson, meador.inge, storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for struct
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26444/struct_sizeof-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Fri Jul 20 08:50:59 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Jul 2012 06:50:59 +0000
Subject: [issue14596] struct.unpack memory leak
In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za>
Message-ID: <1342767059.71.0.413038762265.issue14596@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> I do think issue (3) should be fixed, but a separate issue should be opened for it.

Issue #15402.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14596>
_______________________________________

From report at bugs.python.org  Fri Jul 20 08:53:36 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 20 Jul 2012 06:53:36 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342767216.14.0.444957251515.issue15381@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
assignee: eli.bendersky -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 08:58:46 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 20 Jul 2012 06:58:46 +0000
Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Message-ID: <1342767526.87.0.561763319751.issue1470548@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/issue1470548>
_______________________________________

From report at bugs.python.org  Fri Jul 20 10:51:37 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jul 2012 08:51:37 +0000
Subject: [issue15399] processName key is un-/mis-documented in 2.6 and up
In-Reply-To: <1342723251.3.0.517934021782.issue15399@psf.upfronthosting.co.za>
Message-ID: <3Wdm6Z3sshzMjJ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 204be25f24bd by Vinay Sajip in branch '2.7':
Issue #15399: Added versionchanged for processName.
http://hg.python.org/cpython/rev/204be25f24bd

New changeset 6b771075cfa3 by Vinay Sajip in branch '3.2':
Issue #15399: Added versionchanged for processName.
http://hg.python.org/cpython/rev/6b771075cfa3

New changeset 4b5e8f7d1ac4 by Vinay Sajip in branch 'default':
Closes #15399: merged documentation fix from 3.2.
http://hg.python.org/cpython/rev/4b5e8f7d1ac4

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15399>
_______________________________________

From report at bugs.python.org  Fri Jul 20 11:09:14 2012
From: report at bugs.python.org (Juarez Bochi)
Date: Fri, 20 Jul 2012 09:09:14 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1342775354.52.0.842185673575.issue1100942@psf.upfronthosting.co.za>


Juarez Bochi <jbochi at gmail.com> added the comment:

I've updated my patch with the tests for datetime.time.strptime that were missing and also its pure Python implementation.

The previous diff also had some issues that I've fixed now: duplicated datetime.strptime method definition in c and the pure python docstring state that date.strpdate was a method and not a constructor.

----------
Added file: http://bugs.python.org/file26445/issue1100942_pure.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Fri Jul 20 11:09:48 2012
From: report at bugs.python.org (Juarez Bochi)
Date: Fri, 20 Jul 2012 09:09:48 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1342775388.87.0.402427471345.issue1100942@psf.upfronthosting.co.za>


Changes by Juarez Bochi <jbochi at gmail.com>:


Removed file: http://bugs.python.org/file26440/issue1100942_pure.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Fri Jul 20 11:19:10 2012
From: report at bugs.python.org (Juarez Bochi)
Date: Fri, 20 Jul 2012 09:19:10 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1342775950.07.0.39603188471.issue1100942@psf.upfronthosting.co.za>


Juarez Bochi <jbochi at gmail.com> added the comment:

Sorry. I updated my patch again to fix the exception message for time.strptime in the pure Python version.

----------
Added file: http://bugs.python.org/file26446/issue1100942_pure.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Fri Jul 20 11:19:23 2012
From: report at bugs.python.org (Juarez Bochi)
Date: Fri, 20 Jul 2012 09:19:23 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1342775963.21.0.136818508947.issue1100942@psf.upfronthosting.co.za>


Changes by Juarez Bochi <jbochi at gmail.com>:


Removed file: http://bugs.python.org/file26445/issue1100942_pure.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Fri Jul 20 11:49:01 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 20 Jul 2012 09:49:01 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342777741.97.0.188932808592.issue15397@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Stefan, you right.
A bit hairy idiom from my perspective, but it works.
Looks like this way used only for PyCFunction_New, all other code follows standard schema with trampoline.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Fri Jul 20 12:24:46 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Jul 2012 10:24:46 +0000
Subject: [issue15400] int('12345L', 10) raises ValueError
In-Reply-To: <1342725703.62.0.185151812614.issue15400@psf.upfronthosting.co.za>
Message-ID: <1342779886.57.0.681504743536.issue15400@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I definitely think this counts as a feature request, and as such should be rejected.

I'd expect the 'long' constructor to be able to parse representations of both ints and longs, but I don't see any reason to expect the 'int' constructor to be able to parse representations of longs.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15400>
_______________________________________

From report at bugs.python.org  Fri Jul 20 12:34:46 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Jul 2012 10:34:46 +0000
Subject: [issue15400] int('12345L', 10) raises ValueError
In-Reply-To: <1342725703.62.0.185151812614.issue15400@psf.upfronthosting.co.za>
Message-ID: <1342780486.15.0.559480492928.issue15400@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Reclosing this:  it's at worst marginally a bug, and not worth the new code that would have to go into 2.7.

@Meador:  consider also that int accepts float objects, but not string representations of float objects...  I don't see any real reason for concern here.

I'm certain this is intentional behaviour, but a little bit disappointed that I couldn't find a test already in Lib/test/test_int.py for it :-(

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15400>
_______________________________________

From report at bugs.python.org  Fri Jul 20 12:40:55 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 20 Jul 2012 10:40:55 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1342780855.26.0.861066966517.issue15402@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/issue15402>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:09:46 2012
From: report at bugs.python.org (Ismail Donmez)
Date: Fri, 20 Jul 2012 11:09:46 +0000
Subject: [issue9687] dbmmodule.c:dbm_contains fails on 64bit big-endian
	(test_dbm.py fails) when built against gdbm (int vs Py_ssize_t)
In-Reply-To: <1282766699.94.0.103473116752.issue9687@psf.upfronthosting.co.za>
Message-ID: <1342782586.55.0.742387986109.issue9687@psf.upfronthosting.co.za>


Changes by Ismail Donmez <ismail at namtrac.org>:


----------
nosy: +cartman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9687>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:13:13 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 20 Jul 2012 11:13:13 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
Message-ID: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue addresses the "file creation" portion of issue 15376, which is to refactor the walk_package support code in test_runpy into a common location.

----------
components: Tests
keywords: easy
messages: 165910
nosy: cjerdonek
priority: normal
severity: normal
stage: needs patch
status: open
title: Refactor package creation support code into a common location
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:19:10 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 20 Jul 2012 11:19:10 +0000
Subject: [issue15376] Refactor the test_runpy walk_package support code into a
	common location
In-Reply-To: <1342509049.53.0.303616016829.issue15376@psf.upfronthosting.co.za>
Message-ID: <1342783150.47.0.585523791636.issue15376@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I'm going to address this issue in parts to make it easier to review and see what is going on.

The first patch I'm uploading shortly here: issue 15403.  That issue I created to address just the "file creation" part of the code.

The approach I'm taking is to keep the file creation code decoupled from the temp directory, sys.path, and import code.  My plan is to address the latter in separate patches by creating or modifying existing test support context managers, as necessary.

----------
dependencies: +Refactor package creation support code into a common location
title: Refactor the create-package code in test_runpy into a helper module -> Refactor the test_runpy walk_package support code into a common location

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15376>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:25:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 20 Jul 2012 11:25:41 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1342783541.39.0.189977764475.issue15403@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:26:16 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 20 Jul 2012 11:26:16 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1342783576.25.0.415479068858.issue15403@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file26447/issue-15403-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:42:53 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 20 Jul 2012 11:42:53 +0000
Subject: [issue15404] Refleak in PyMethodObject repr
Message-ID: <1342784573.74.0.322752572282.issue15404@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Python leaks in method.__repr__ if class has no __name__.
Very rare situation.

----------
assignee: asvetlov
components: Interpreter Core
files: leak.diff
keywords: patch
messages: 165913
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Refleak in PyMethodObject repr
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26448/leak.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15404>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:46:38 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 20 Jul 2012 11:46:38 +0000
Subject: [issue15404] Refleak in PyMethodObject repr
In-Reply-To: <1342784573.74.0.322752572282.issue15404@psf.upfronthosting.co.za>
Message-ID: <1342784798.76.0.414395085757.issue15404@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


Removed file: http://bugs.python.org/file26448/leak.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15404>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:46:51 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 20 Jul 2012 11:46:51 +0000
Subject: [issue15404] Refleak in PyMethodObject repr
In-Reply-To: <1342784573.74.0.322752572282.issue15404@psf.upfronthosting.co.za>
Message-ID: <1342784811.4.0.537817166099.issue15404@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


Added file: http://bugs.python.org/file26449/leak.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15404>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:51:13 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 Jul 2012 11:51:13 +0000
Subject: [issue15391] Add bitlength function to the math module
In-Reply-To: <1342654343.1.0.00342933769834.issue15391@psf.upfronthosting.co.za>
Message-ID: <1342785073.67.0.280252795698.issue15391@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Indeed, int.bit_length is the way to do this.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15391>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:54:48 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 20 Jul 2012 11:54:48 +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: <1342785288.87.0.0277524926543.issue11816@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov.ml at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:57:54 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jul 2012 11:57:54 +0000
Subject: [issue15404] Refleak in PyMethodObject repr
In-Reply-To: <1342784573.74.0.322752572282.issue15404@psf.upfronthosting.co.za>
Message-ID: <3WdrFX68n8zPFh@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4b724884c81f by Andrew Svetlov in branch '3.2':
Issue #15404: Refleak in PyMethodObject repr.
http://hg.python.org/cpython/rev/4b724884c81f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15404>
_______________________________________

From report at bugs.python.org  Fri Jul 20 13:59:08 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 20 Jul 2012 11:59:08 +0000
Subject: [issue15404] Refleak in PyMethodObject repr
In-Reply-To: <1342784573.74.0.322752572282.issue15404@psf.upfronthosting.co.za>
Message-ID: <1342785548.1.0.523574106563.issue15404@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15404>
_______________________________________

From report at bugs.python.org  Fri Jul 20 14:07:35 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 20 Jul 2012 12:07:35 +0000
Subject: [issue15404] Refleak in PyMethodObject repr
In-Reply-To: <1342784573.74.0.322752572282.issue15404@psf.upfronthosting.co.za>
Message-ID: <1342786055.88.0.773946901525.issue15404@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
stage:  -> committed/rejected
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15404>
_______________________________________

From report at bugs.python.org  Fri Jul 20 14:24:03 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 20 Jul 2012 12:24:03 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1342787043.55.0.409704246583.issue12834@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The fix would require all of these functions from memoryview.c (3.3):

last_dim_is_contiguous
cmp_structure
copy_base
copy_rec
copy_buffer


How to avoid code duplication? I could move them into abstract.c,
but conceptually they're really just low level buffer interface
functions. Also, they make a lot of assumptions (ndim >= 1,
PyBUF_FULL) that are a little dangerous for a general interface.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Fri Jul 20 14:25:50 2012
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 20 Jul 2012 12:25:50 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1342787150.91.0.486042201468.issue12834@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

You could move PyBuffer_ToContiguous() from abstract.c to memoryview.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Fri Jul 20 14:42:00 2012
From: report at bugs.python.org (Antti Laine)
Date: Fri, 20 Jul 2012 12:42:00 +0000
Subject: [issue15393] JSONDecoder.raw_decode breaks on leading whitespace
In-Reply-To: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za>
Message-ID: <1342788120.02.0.253338061325.issue15393@psf.upfronthosting.co.za>


Antti Laine <antti.a.laine at iki.fi> added the comment:

> you are changing the signature of "decode()" and that would be a compatibility problem

I was changing the signature of raw_decode(), by adding a(n almost) private keyword. I really don't see how that would affect compatibility.

> you are thinking that "json document" includes the possibility of leading whitespace

Yes. While JSON does not have a real standard to follow, I believe that going by the RFC is the best thing to do, and the RFC very clearly states, that objects can be surrounded with whitespace.

decode() depends on the functionality of raw_decode(), and its own parameter _w. I have no idea why _w is a parameter. It is not used anywhere in CPython, and, beginning with an underscore, it shouldn't be used from anywhere else. Still it offers the users a possibility to break the behaviour of decode(). If it's a performance hack, making the variable being initialized only once, then I think it's a very poor one.

Now the patch leaves decode() as it is, and checks for whitespace in raw_decode(), which leads to checking for whitespace twice when using decode().

I think that a more extensive cleanup would be in order.

----------
Added file: http://bugs.python.org/file26450/json-raw-decoder-fix-whitespace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15393>
_______________________________________

From report at bugs.python.org  Fri Jul 20 14:54:24 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 20 Jul 2012 12:54:24 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1342788864.77.0.253898746975.issue12834@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> You could move PyBuffer_ToContiguous() from abstract.c to memoryview.c.

For 3.3 that would be ideal, yes. I asked a while ago on python-dev
whether to backport the memoryview rewrite. The general mood was
against it.

So, for 2.7/3.2 I could add all these functions to abstract.c.
But an additional problem is that the whole test infrastructure of
Lib/test/test_buffer.py and Modules/_testbuffer.c would be missing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:00:13 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Jul 2012 13:00:13 +0000
Subject: [issue15091] ImportError when package is symlinked on Unix
In-Reply-To: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za>
Message-ID: <1342789213.72.0.943987265163.issue15091@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/issue15091>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:00:32 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Jul 2012 13:00:32 +0000
Subject: [issue15091] ImportError when package is symlinked on Unix
In-Reply-To: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za>
Message-ID: <1342789232.92.0.129341871964.issue15091@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15091>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:09:48 2012
From: report at bugs.python.org (reynaldo)
Date: Fri, 20 Jul 2012 13:09:48 +0000
Subject: [issue15405] Invitation to connect on LinkedIn
Message-ID: <521105205.7590960.1342789784588.JavaMail.app@ela4-app0133.prod>


New submission from reynaldo <renben77 at gmail.com>:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- reynaldo

reynaldo bendijo
owner at www.omickiey.com
Greater Los Angeles Area

Confirm that you know reynaldo bendijo:
https://www.linkedin.com/e/-3qcne3-h4vad8ug-3t/isd/4079929199/bZ2HS2mr/?hs=false&tok=3ElCzFvFARvlk1

----------
messages: 165920
nosy: renben
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15405>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:19:33 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 20 Jul 2012 13:19:33 +0000
Subject: [issue15405] Invitation to connect on LinkedIn
In-Reply-To: <521105205.7590960.1342789784588.JavaMail.app@ela4-app0133.prod>
Message-ID: <1342790373.71.0.240991746231.issue15405@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15405>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:25:10 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Jul 2012 13:25:10 +0000
Subject: [issue15091] ImportError when package is symlinked on Unix
In-Reply-To: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za>
Message-ID: <1342790710.42.0.761783899489.issue15091@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oh, wow, that was a *lot* harder than I expected to create a test for - I had to import importlib right at the start of regrtest, as well as tweak the import order in runpy, and doing so actually caused test_import to *crash* completely without the bug fixed.

The trick was realising that *anything* importing imp before importlib would mask the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15091>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:38:15 2012
From: report at bugs.python.org (Rafael Caricio)
Date: Fri, 20 Jul 2012 13:38:15 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342791495.03.0.431180242967.issue15398@psf.upfronthosting.co.za>


Rafael Caricio <rafael at caricio.com> added the comment:

I had this problem when I run the tests in my machine (Mac OSX 10.6.8). The intermittence happen here.

----------
nosy: +rafaelcaricio

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:40:22 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jul 2012 13:40:22 +0000
Subject: [issue15386] Still getting two copies of importlib._bootstrap
In-Reply-To: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>
Message-ID: <3WdtWk5Mt9zPMT@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4431dc4bb770 by Nick Coghlan in branch 'default':
Close #15386: There was a loophole that meant importlib.machinery and imp would sometimes reference an uninitialised copy of importlib._bootstrap
http://hg.python.org/cpython/rev/4431dc4bb770

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15386>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:49:06 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Jul 2012 13:49:06 +0000
Subject: [issue15091] ImportError when package is symlinked on Unix
In-Reply-To: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za>
Message-ID: <1342792146.28.0.868935514026.issue15091@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
Removed message: http://bugs.python.org/msg165921

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15091>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:49:59 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Jul 2012 13:49:59 +0000
Subject: [issue15386] Still getting two copies of importlib._bootstrap
In-Reply-To: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>
Message-ID: <1342792199.91.0.207430153225.issue15386@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

That was a *lot* harder than I expected to create a test for - I had to import importlib right at the start of regrtest, as well as tweak the import order in runpy, and doing so actually caused test_import to *crash* completely without the bug fixed.

The trick was realising that *anything* importing imp before importlib would mask the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15386>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:55:41 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 13:55:41 +0000
Subject: [issue15400] int('12345L', 10) raises ValueError
In-Reply-To: <1342725703.62.0.185151812614.issue15400@psf.upfronthosting.co.za>
Message-ID: <1342792541.14.0.101968319219.issue15400@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Thanks for the analysis Mark.  I agree with your points.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15400>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:56:30 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Fri, 20 Jul 2012 13:56:30 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1342792590.19.0.174373621928.issue15398@psf.upfronthosting.co.za>


Fl?vio Ribeiro <email at flavioribeiro.com> added the comment:

Ronald,

I thought it could be an `atomic` issue by the fact that test_rename transforms a filename in tmp and then it change again to the original name. Not being atomic, the rename will not finish the executation of the first one (even though a return code has been sent) and FileNotFoundError is dispatched. 

Anyway, i've added a time.sleep in the middle of the two lines to assert this and no more intermittence could be found. Ideas?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15398>
_______________________________________

From report at bugs.python.org  Fri Jul 20 15:59:41 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 20 Jul 2012 13:59:41 +0000
Subject: [issue14562] urllib2 maybe blocks too long with small chunks
In-Reply-To: <1334233390.52.0.591380103695.issue14562@psf.upfronthosting.co.za>
Message-ID: <1342792781.6.0.730595522936.issue14562@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I had a discussion with Anrs on this, and it went along these lines - 

I confused the buffering issue (encountered with streaming data) of urllib2 with chunked transfer encoding.

The flow will be blocked in the case at the socket level waiting for 8192 bytes. But this buffer size has been kept for buffered reading purposes of normal read scenarios.
However, in case of streaming data, this may be not the best way.

Here it is explained best - 

http://stackoverflow.com/questions/1598331/how-to-read-continous-http-streaming-data-in-python

The advise is to make the socket buffer size to 0.

import socket

socket._fileobject.default_bufsize = 0

Now, if we come to chunked transfer encoding, the chunked transfer encoding will behave as it is advertised, like sending one chunk at the time, but still having the readline limit set by MAXLINE in the httplib.py. For the chunked transfer encoding to be recognized the client will have to get a header "transfer-encoding: chunked" from the server and when it receives that header, it will follow the path reading MAXLINE at the time and then returning. For smaller chunks with a blocking behavior of the server ( like you illustrated), we may still need to adopt to turn off default_bufsize to 0 to ensure quick responses to fill the buffer.

At this moment, I think that the above thing could be documented in the urllib2 docs for the issue you had raised. Not sure, if any other approach would be suitable to handle this behavior.

Anrs (The original poster) also responded that they way he had to overcome this for a very small chunks is setting the socket file size to 0 locally.

>> resp = opener.open(server, urllib.urlencode(data))
>> resp = opener.open(server)
>> resp.fp._rbufsize = 0
>> for line in iter(resp.readline, ''):
>>     yield line

I think, this could be documented in a certain fashion (like support for streaming without buffering or transfers for small data sizes without buffering).

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14562>
_______________________________________

From report at bugs.python.org  Fri Jul 20 16:00:33 2012
From: report at bugs.python.org (Tatiana Al-Chueyr)
Date: Fri, 20 Jul 2012 14:00:33 +0000
Subject: [issue9914] trace/profile conflict with the use of
	sys.modules[__name__]
In-Reply-To: <1285093065.41.0.819526070425.issue9914@psf.upfronthosting.co.za>
Message-ID: <1342792833.39.0.39184693237.issue9914@psf.upfronthosting.co.za>


Tatiana Al-Chueyr <tatiana.alchueyr at gmail.com> added the comment:

Yesterday I've studied this problem with flavio.ribeiro, and we've started "solving" it. The result of our progress is available at:
issue5758_trace_execute_other_modules_main_v0.patch

The problem of our approach is that any code outside the condition "if __name__ == '__main__'" will be run twice, as we used imp.load_source to obtain trace's analyzed code and redefine sys.modules['__main__'].

In order to provide a better solution, we were considering using lazy module import, e.g:
http://code.activestate.com/recipes/473888-lazy-module-imports/

Any thoughts on this?

----------
keywords: +patch
nosy: +tati_alchueyr
Added file: http://bugs.python.org/file26451/issue5758_trace_execute_other_modules_main_v0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9914>
_______________________________________

From report at bugs.python.org  Fri Jul 20 16:18:49 2012
From: report at bugs.python.org (Juarez Bochi)
Date: Fri, 20 Jul 2012 14:18:49 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1342793929.76.0.21378722399.issue1100942@psf.upfronthosting.co.za>


Juarez Bochi <jbochi at gmail.com> added the comment:

I've updated the patch based on ezio.melotti and berkerpeksag reviews (thanks).

It's still missing the modifications proposed on msg107402.

----------
Added file: http://bugs.python.org/file26452/issue1100942_pure2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Fri Jul 20 16:29:33 2012
From: report at bugs.python.org (Hugo Lopes Tavares)
Date: Fri, 20 Jul 2012 14:29:33 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1342794573.02.0.344858852798.issue13592@psf.upfronthosting.co.za>


Hugo Lopes Tavares <hltbra at gmail.com> added the comment:

Thanks for the review ezio.melotti.

He has notice a few things in my patch:
* assertEquals is deprecated; should use assertEqual
* the convention is assertEqual(result, expected), not assertEqual(expected, result)
* it should handle quotes correctly
* some lines were longer than 80 chars
* add tests using inline flags (re.I instead of re.IGNORECASE)

And I realized I was not covering the case where no flags are enabled (byte string, for instance). And I have fixed all this issues.

And now I think this patch would work against py2x and py3k anyway.

Attaching a new patch.

----------
Added file: http://bugs.python.org/file26453/issue13592_add_repr_to_regex_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Fri Jul 20 16:31:48 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 20 Jul 2012 14:31:48 +0000
Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support
Message-ID: <1342794708.19.0.320050474088.issue1675455@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

Bump.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675455>
_______________________________________

From report at bugs.python.org  Fri Jul 20 16:34:42 2012
From: report at bugs.python.org (Hugo Lopes Tavares)
Date: Fri, 20 Jul 2012 14:34:42 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1342794882.12.0.407168661285.issue13592@psf.upfronthosting.co.za>


Hugo Lopes Tavares <hltbra at gmail.com> added the comment:

Changed two test names to avoid misunderstanding.

----------
Added file: http://bugs.python.org/file26454/issue13592_add_repr_to_regex_v2_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Fri Jul 20 16:44:07 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Fri, 20 Jul 2012 14:44:07 +0000
Subject: [issue15406] Deprecation Warnings fixes on test suite
Message-ID: <1342795447.04.0.0636539536415.issue15406@psf.upfronthosting.co.za>


New submission from Fl?vio Ribeiro <email at flavioribeiro.com>:

Looking for bugs to be solved on a cPython Sprint, Hynek reported at core-mentorship list some Deprecation Warnings running the test suite in regression mode. 

This issue aims to solve this warnings.

----------
components: Tests
messages: 165933
nosy: flavio.ribeiro
priority: normal
severity: normal
status: open
title: Deprecation Warnings fixes on test suite
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15406>
_______________________________________

From report at bugs.python.org  Fri Jul 20 16:47:36 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Fri, 20 Jul 2012 14:47:36 +0000
Subject: [issue15406] Deprecation Warnings fixes on test suite
In-Reply-To: <1342795447.04.0.0636539536415.issue15406@psf.upfronthosting.co.za>
Message-ID: <1342795656.91.0.672251528855.issue15406@psf.upfronthosting.co.za>


Fl?vio Ribeiro <email at flavioribeiro.com> added the comment:

The patch remove this warning:

$ ./python.exe -Wm -m test test_ctypes
[1/1] test_ctypes
/Users/flavio.barbosa/dev/cpython/Lib/ctypes/test/test_bitfields.py:249: DeprecationWarning: Please use assertEqual instead.
  self.assertEquals(x.a, 10)
1 test OK.
[155770 refs]

----------
keywords: +patch
Added file: http://bugs.python.org/file26455/issue15406_fix_ctypes_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15406>
_______________________________________

From report at bugs.python.org  Fri Jul 20 17:00:33 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Fri, 20 Jul 2012 15:00:33 +0000
Subject: [issue15406] Deprecation Warnings fixes on test suite
In-Reply-To: <1342795447.04.0.0636539536415.issue15406@psf.upfronthosting.co.za>
Message-ID: <1342796433.0.0.475296861229.issue15406@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15406>
_______________________________________

From report at bugs.python.org  Fri Jul 20 17:03:28 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Jul 2012 15:03:28 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342796608.8.0.788759810799.issue15381@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There seems to be a problem with the patch: when you store the getvalue() result somewhere (instead of discarding it), things get much slower:

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
1000 loops, best of 3: 913 usec per loop

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "global y; y = s.getvalue()"
100 loops, best of 3: 4.67 msec per loop

This does not happen without the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 17:13:06 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 15:13:06 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1342797186.36.0.0944796335813.issue15402@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Module a few cosmetic changes (variable names and doc string tweaks), the patch looks good.  Having a correct answer for `sys.getsizeof(struct.Struct('100B'))` is definitely better.  Per the documentation for 'sys.getsizeof' [1]:

"""
All built-in objects will return correct results, but this does not have to hold true for third-party extensions as it is implementation specific.
"""

If we consider extension modules as built-in objects, then this is a bug and should be fixed in 2.7, 3.2, and 3.3.  If we don't, then the documentation for 'sys.getsizeof' should be adjusted and this patch should be applied after the default branch is unfrozen for enhancements.

[1] http://docs.python.org/library/sys.html

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Fri Jul 20 17:16:09 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Jul 2012 15:16:09 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342797369.38.0.267796087742.issue15381@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Under Windows (64-bit Windows 7 on a  VirtualBox VM), the patch increases performance slightly but not as much as under Linux:

-> before patch:

C:\t\cpython>pc\VS9.0\amd64\python.exe -m timeit -s "import io; n=2000; d=[b'a'*
n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.g
etvalue()"
10 loops, best of 3: 49.2 msec per loop

-> after patch:

C:\t\cpython>pc\VS9.0\amd64\python.exe -m timeit -s "import io; n=2000; d=[b'a'*
n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.g
etvalue()"
10 loops, best of 3: 41.7 msec per loop


And the join() approach is 10x faster (!):

C:\t\cpython>pc\VS9.0\amd64\python.exe -m timeit -s "import io; n=2000; d=[b'a'*
n,b'bb'*n,b'ccc'*n]*1000"  "b''.join(d)"
100 loops, best of 3: 4.63 msec per loop

... which points to a much less optimized realloc() under Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 17:43:02 2012
From: report at bugs.python.org (Cal Leeming)
Date: Fri, 20 Jul 2012 15:43:02 +0000
Subject: [issue15407] CSV parser fails to iterate properly on 2.6.6
Message-ID: <1342798982.0.0.719317357124.issue15407@psf.upfronthosting.co.za>


New submission from Cal Leeming <cal.leeming at simplicitymedialtd.co.uk>:

Getting some extremely strange behavior when attempting to parse a fairly standard CSV in Python 2.6.6.

I've tried a whole different mixture of dialects, quoting options, line terminators etc, and none seem to get a happy ending.

Spent about 2 hours banging my head against a brick wall on this, and struggling to see how the CSV libs could be so fundamentally broken, given that I couldn't find any other related bugs.

I have attempted to parse the following CSV data:

"First","Middle","Last","Nickname","Email","Category"
"Moe","","Howard","Moe","moe at 3stooges.com","actor"
"Jerome","Lester","Howard","Curly","curly at 3stooges.com","actor"
"Larry","","Fine","Larry","larry at 3stooges.com","musician"
"Jerome","","Besser","Joe","joe at 3stooges.com","actor"
"Joe","","DeRita","CurlyJoe","curlyjoe at 3stooges.com","actor"
"Shemp","","Howard","Shemp","shemp at 3stooges.com","actor"

The code used to parse was this:

datx = open("data.txt", "rb").read()
rows = csv.reader( datx , dialect="wat")
for row in rows:
    print x

The output given is this:

['First']
['', '']
['Middle']
['', '']
['Last']
['', '']
['Nickname']
['', '']
['Email']
['', '']
['Category']
[]
['Moe']
['', '']
['']
['', '']
['Howard']
['', '']
['Moe']
['', '']
['moe at 3stooges.com']
['', '']
['actor']
[]
['Jerome']
['', '']
['Lester']
['', '']
['Howard']
['', '']
['Curly']
['', '']
['curly at 3stooges.com']
['', '']
['actor']
[]
['Larry']
['', '']
['']
['', '']
['Fine']
['', '']
['Larry']
['', '']
['larry at 3stooges.com']
['', '']
['musician']
[]
['Jerome']
['', '']
['']
['', '']
['Besser']
['', '']
['Joe']
['', '']
['joe at 3stooges.com']
['', '']
['actor']
[]
['Joe']
['', '']
['']
['', '']
['DeRita']
['', '']
['CurlyJoe']
['', '']
['curlyjoe at 3stooges.com']
['', '']
['actor']
[]
['Shemp']
['', '']
['']
['', '']
['Howard']
['', '']
['Shemp']
['', '']
['shemp at 3stooges.com']
['', '']
['actor']
[]

----------
components: None
messages: 165938
nosy: sleepycal
priority: normal
severity: normal
status: open
title: CSV parser fails to iterate properly on 2.6.6
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15407>
_______________________________________

From report at bugs.python.org  Fri Jul 20 17:45:23 2012
From: report at bugs.python.org (Cal Leeming)
Date: Fri, 20 Jul 2012 15:45:23 +0000
Subject: [issue15407] CSV parser fails to iterate properly on 2.6.6
In-Reply-To: <1342798982.0.0.719317357124.issue15407@psf.upfronthosting.co.za>
Message-ID: <1342799123.14.0.237537350474.issue15407@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

Sorry, accidently pasted the wrong code snippet previously. The correct code snippet is:

datx = open("data.txt", "rb").read()
rows = csv.reader( datx )
for row in rows:
    print x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15407>
_______________________________________

From report at bugs.python.org  Fri Jul 20 17:46:21 2012
From: report at bugs.python.org (Cal Leeming)
Date: Fri, 20 Jul 2012 15:46:21 +0000
Subject: [issue15407] CSV parser fails to iterate properly on 2.6.6
In-Reply-To: <1342798982.0.0.719317357124.issue15407@psf.upfronthosting.co.za>
Message-ID: <1342799181.1.0.894458015856.issue15407@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

This bug also seems to be showing in 2.7.3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15407>
_______________________________________

From report at bugs.python.org  Fri Jul 20 17:53:44 2012
From: report at bugs.python.org (Cal Leeming)
Date: Fri, 20 Jul 2012 15:53:44 +0000
Subject: [issue15407] CSV parser fails to iterate properly on 2.6.6
In-Reply-To: <1342798982.0.0.719317357124.issue15407@psf.upfronthosting.co.za>
Message-ID: <1342799624.07.0.446147247675.issue15407@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

Okay, just found the reason for this.. It's because I was putting a .read() on the file descriptor..

I really think that the CSVReader should raise an assertion in the event that it is passed an object which has no iterator, or if it is given a string, as this is a fairly easy mistake to make.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15407>
_______________________________________

From report at bugs.python.org  Fri Jul 20 17:56:00 2012
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 20 Jul 2012 15:56:00 +0000
Subject: [issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2
Message-ID: <1342799760.81.0.0479132559422.issue15408@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

The attached script behaves differently on Python 2.7.2 and Python 3.2.3.

With Python 2.7 the script runs for ca. 30 seconds and then I get back my prompt.

With Python 3.2 the script runs in the background, I get back my prompt immediately and can type shell commands.

Commenting out the call to uname() changes the behaviour of the script on Python 3.2 so that it behaves like on Python 2.7.

(This happens on both Max OS X 10.7 and Linux.)

----------
files: gurk.py
messages: 165942
nosy: doerwalter
priority: normal
severity: normal
status: open
title: os.fork/os.popen behaviour change between 2.7 and 3.2
versions: Python 3.2
Added file: http://bugs.python.org/file26456/gurk.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15408>
_______________________________________

From report at bugs.python.org  Fri Jul 20 18:00:38 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 20 Jul 2012 16:00:38 +0000
Subject: [issue15038] Optimize python Locks on Windows
In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za>
Message-ID: <1342800038.74.0.984361040066.issue15038@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Thanks, Benjamin.  That's what reviews are for :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15038>
_______________________________________

From report at bugs.python.org  Fri Jul 20 18:07:01 2012
From: report at bugs.python.org (Tim Golden)
Date: Fri, 20 Jul 2012 16:07:01 +0000
Subject: [issue15407] CSV parser fails to iterate properly on 2.6.6
In-Reply-To: <1342799624.07.0.446147247675.issue15407@psf.upfronthosting.co.za>
Message-ID: <5009821F.70505@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

It already produces a TypeError with a specific message if the input is
not iterable. You seem to be using a homegrown dialect; with the
conventional list (csv.reader("the quick brown fox")) you very quickly
see that you're iterating over a string.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15407>
_______________________________________

From report at bugs.python.org  Fri Jul 20 18:23:13 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 20 Jul 2012 16:23:13 +0000
Subject: [issue15359] Sockets support for CAN_BCM
In-Reply-To: <1342357855.99.0.608670333225.issue15359@psf.upfronthosting.co.za>
Message-ID: <1342801393.39.0.303890797722.issue15359@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15359>
_______________________________________

From report at bugs.python.org  Fri Jul 20 18:38:23 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 20 Jul 2012 16:38:23 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1342802303.64.0.974420158735.issue15402@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The patch is easy. I want this in 3.3.

Reluctant to touch 2.7 and 3.2, thought. I would be +0 to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Fri Jul 20 18:56:25 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 20 Jul 2012 16:56:25 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1342803385.3.0.416003919301.issue15402@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

makes sense for 3.3 as i would consider it a bug.

i think it is reasonable for 2.7 and 3.2 as well, it is an actual bug that the value reported to getsizeof on struct.Struct is meaningless.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Fri Jul 20 18:58:11 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 20 Jul 2012 16:58:11 +0000
Subject: [issue15363] Idle/tkinter ~x.py 'save as' fails. closes idle
In-Reply-To: <1342394243.7.0.336788716257.issue15363@psf.upfronthosting.co.za>
Message-ID: <1342803491.67.0.458519873044.issue15363@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15363>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:06:21 2012
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 20 Jul 2012 17:06:21 +0000
Subject: [issue14674] Link to & explain deviations from RFC 4627 in json
	module docs
In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za>
Message-ID: <1342803981.95.0.852280150121.issue14674@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Pinging on this, since it's been just short of a month since ?ric's "last call" comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14674>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:08:20 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 20 Jul 2012 17:08:20 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342804100.32.0.64906939583.issue15397@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Can't you unbind without any changes to the C code by doing

    def unbind(f):
        if hasattr(f, '__func__'):
            return f.__func__
        self = getattr(f, '__self__', None)
        if self is not None and not isinstance(self, types.ModuleType):
            return getattr(type(f.__self__), f.__name__)
        raise TypeError('not a bound method')

Also, I am not convinced that it is a good idea to return f if f is already "unbound".  In practice I think you will always need to treat the bound and the unbound cases differently.

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:22:44 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Fri, 20 Jul 2012 17:22:44 +0000
Subject: [issue15406] Deprecation Warning fix on ctypes module
In-Reply-To: <1342795447.04.0.0636539536415.issue15406@psf.upfronthosting.co.za>
Message-ID: <1342804964.81.0.491230600003.issue15406@psf.upfronthosting.co.za>


Fl?vio Ribeiro <email at flavioribeiro.com> added the comment:

One issue per module will be created to facilitate the issues management.

----------
title: Deprecation Warnings fixes on test suite -> Deprecation Warning fix on ctypes module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15406>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:24:25 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Fri, 20 Jul 2012 17:24:25 +0000
Subject: [issue15406] Deprecation Warning fix on ctypes module test
In-Reply-To: <1342795447.04.0.0636539536415.issue15406@psf.upfronthosting.co.za>
Message-ID: <1342805065.61.0.426660640695.issue15406@psf.upfronthosting.co.za>


Changes by Fl?vio Ribeiro <email at flavioribeiro.com>:


----------
title: Deprecation Warning fix on ctypes module -> Deprecation Warning fix on ctypes module test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15406>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:26:08 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 17:26:08 +0000
Subject: [issue15406] Deprecation Warning fix on ctypes module test
In-Reply-To: <1342795447.04.0.0636539536415.issue15406@psf.upfronthosting.co.za>
Message-ID: <1342805168.95.0.478222952555.issue15406@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Thanks for the patch.  I will review it shortly.

----------
assignee:  -> meador.inge
components: +ctypes
nosy: +meador.inge
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15406>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:30:17 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Jul 2012 17:30:17 +0000
Subject: [issue15407] CSV parser fails to iterate properly on 2.6.6
In-Reply-To: <1342798982.0.0.719317357124.issue15407@psf.upfronthosting.co.za>
Message-ID: <1342805417.07.0.284681348103.issue15407@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We don't generally do that kind of type checking.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15407>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:32:06 2012
From: report at bugs.python.org (Cal Leeming)
Date: Fri, 20 Jul 2012 17:32:06 +0000
Subject: [issue15407] CSV parser fails to iterate properly on 2.6.6
In-Reply-To: <1342798982.0.0.719317357124.issue15407@psf.upfronthosting.co.za>
Message-ID: <1342805526.73.0.351203795778.issue15407@psf.upfronthosting.co.za>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

@david Gotcha - I had a feeling that would be the case. Thank you for the quick replies anyway guys! Hopefully this will help others in the future :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15407>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:32:56 2012
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 20 Jul 2012 17:32:56 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1342805576.49.0.706126158274.issue1100942@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:34:01 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 17:34:01 +0000
Subject: [issue15272] pkgutil.find_loader accepts invalid module names
In-Reply-To: <1341656387.47.0.245292094882.issue15272@psf.upfronthosting.co.za>
Message-ID: <1342805641.2.0.296123602753.issue15272@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

PEP 302 just says that find_module "will be called with the fully qualified name of the module." And importation by file name was removed in Python 3 (at some point; don't remember exact feature release). So supporting slashes in a module name is probably not necessary anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15272>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:38:31 2012
From: report at bugs.python.org (Igor Sobreira)
Date: Fri, 20 Jul 2012 17:38:31 +0000
Subject: [issue15010] unittest: _top_level_dir is incorrectly persisted
	between calls to different load_test methods
In-Reply-To: <1338945643.44.0.808523506511.issue15010@psf.upfronthosting.co.za>
Message-ID: <1342805911.49.0.0781810770398.issue15010@psf.upfronthosting.co.za>


Igor Sobreira <igor at igorsobreira.com> added the comment:

My previous patch is incorrect, talking to voidspace on irc self._top_leve_dir should be reverted to it's previous value

"so when discover is called the original value should be stored, then discovery done, and then the original restored"

I'll work on this one.

He also pointed out that this bugfix should be backported to 2.7 and 3.2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15010>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:45:34 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 20 Jul 2012 17:45:34 +0000
Subject: [issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2
In-Reply-To: <1342799760.81.0.0479132559422.issue15408@psf.upfronthosting.co.za>
Message-ID: <1342806334.74.0.710325555785.issue15408@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

The problem is that os.wait() is returning when the wrong process exits.

You can fix this by specifying the pid you are waiting for by doing "os.waitpid(pid, 0)" instead of "os.wait()".

Arguably os.popen() and subprocess.communicate() etc should always reap the pid of the process they started.

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15408>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:50:18 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Fri, 20 Jul 2012 17:50:18 +0000
Subject: [issue15409] Deprecation Warning fix on cookiejar module
Message-ID: <1342806618.21.0.425408251196.issue15409@psf.upfronthosting.co.za>


New submission from Fl?vio Ribeiro <email at flavioribeiro.com>:

Cookiejar calls some urllib.Request's deprecated methods. This patch fixes this deprecated calls.

----------
components: Extension Modules
files: cookiejar_fix_deprecated_method_calls.patch
keywords: patch
messages: 165956
nosy: flavio.ribeiro
priority: normal
severity: normal
status: open
title: Deprecation Warning fix on cookiejar module
versions: Python 3.3
Added file: http://bugs.python.org/file26457/cookiejar_fix_deprecated_method_calls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15409>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:50:49 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 17:50:49 +0000
Subject: [issue15292] import hook behavior documentation improvement
In-Reply-To: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>
Message-ID: <1342806649.51.0.941785228018.issue15292@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So I can't reproduce the problem under Python 2.7.3, Python 3.2.3, or a fresh checkout of Python 3.3. This is with both your script, Anders, and writing my own class that defined find_module() to just raise ImportError that I set in either sys.meta_path or in sys.path_importer_cache (both ways let the ImportError propagate).

This means I'm not sure exactly what problem you are encountering. Is this on an older version of Python 2.7? Do you have a unit test that can be run  which shows the test failing under Python 2.7 but passing under Python 3.3?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15292>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:51:24 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 17:51:24 +0000
Subject: [issue15163] pydoc displays __loader__ as module data
In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za>
Message-ID: <1342806684.83.0.970177448488.issue15163@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> eric.araujo
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15163>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:52:14 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 17:52:14 +0000
Subject: [issue2919] Merge profile/cProfile in 3.n+1
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1342806734.37.0.0188759935104.issue2919@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So I didn't find time at EuroPython. =) Is this dead, Alexandre, or do you want to see this happen for Python 3.4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:53:13 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 17:53:13 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
Message-ID: <1342806793.57.0.366238351769.issue665194@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue665194>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:54:23 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 17:54:23 +0000
Subject: [issue1644818] Allow built-in packages and submodules as well as
	top-level modules
Message-ID: <1342806863.57.0.455966282029.issue1644818@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1644818>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:54:53 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 17:54:53 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1342806893.63.0.360844687938.issue3367@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Should this be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:55:13 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jul 2012 17:55:13 +0000
Subject: [issue15406] Deprecation Warning fix on ctypes module test
In-Reply-To: <1342795447.04.0.0636539536415.issue15406@psf.upfronthosting.co.za>
Message-ID: <3Wf09r1rjqzP0W@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fb181698775d by Meador Inge in branch '3.2':
Issue #15406: Fix deprecation warning in ctypes test_bitfields.py
http://hg.python.org/cpython/rev/fb181698775d

New changeset f93efd4c45bd by Meador Inge in branch 'default':
Issue #15406: Fix deprecation warning in ctypes test_bitfields.py
http://hg.python.org/cpython/rev/f93efd4c45bd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15406>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:56:25 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 17:56:25 +0000
Subject: [issue14895] test_warnings.py EnvironmentVariableTests is a bad test
In-Reply-To: <1337809847.78.0.457285588571.issue14895@psf.upfronthosting.co.za>
Message-ID: <1342806985.07.0.192355447378.issue14895@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Phil said it's Jython's problem, so I won't worry about this on CPython's side.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14895>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:57:19 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Fri, 20 Jul 2012 17:57:19 +0000
Subject: [issue15409] Deprecation Warning fix on cookiejar module
In-Reply-To: <1342806618.21.0.425408251196.issue15409@psf.upfronthosting.co.za>
Message-ID: <1342807039.32.0.785648087185.issue15409@psf.upfronthosting.co.za>


Changes by Fl?vio Ribeiro <email at flavioribeiro.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15409>
_______________________________________

From report at bugs.python.org  Fri Jul 20 19:58:31 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 17:58:31 +0000
Subject: [issue15406] Deprecation Warning fix on ctypes module test
In-Reply-To: <1342795447.04.0.0636539536415.issue15406@psf.upfronthosting.co.za>
Message-ID: <1342807111.92.0.485236575002.issue15406@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Thanks again for the patch Fl?vio.  Please contribute again to Python (be sure to fill out a contributor agreement if you do: http://www.python.org/psf/contrib/).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15406>
_______________________________________

From report at bugs.python.org  Fri Jul 20 20:09:46 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 20 Jul 2012 18:09:46 +0000
Subject: [issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2
In-Reply-To: <1342799760.81.0.0479132559422.issue15408@psf.upfronthosting.co.za>
Message-ID: <1342807786.35.0.964476044581.issue15408@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Actually, if you replace

	print(os.popen("uname").read())

with

        f = os.popen("uname")
        print(f.read())
        f.close()

or

        with os.popen("uname") as f:
            print(f.read())

then things should work.  This is because f.close() waits for the pid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15408>
_______________________________________

From report at bugs.python.org  Fri Jul 20 20:22:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jul 2012 18:22:35 +0000
Subject: [issue15091] ImportError when package is symlinked on Unix
In-Reply-To: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za>
Message-ID: <3Wf0nP5czzzPK6@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 721b701feb4a by Brett Cannon in branch 'default':
Issue #15091: Call importlib.invalidate_caches() and reactivate a test
http://hg.python.org/cpython/rev/721b701feb4a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15091>
_______________________________________

From report at bugs.python.org  Fri Jul 20 20:23:01 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 18:23:01 +0000
Subject: [issue15091] ImportError when package is symlinked on Unix
In-Reply-To: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za>
Message-ID: <1342808581.32.0.727566331606.issue15091@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15091>
_______________________________________

From report at bugs.python.org  Fri Jul 20 20:29:09 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 18:29:09 +0000
Subject: [issue9914] trace/profile conflict with the use of
	sys.modules[__name__]
In-Reply-To: <1285093065.41.0.819526070425.issue9914@psf.upfronthosting.co.za>
Message-ID: <1342808949.5.0.903240878883.issue9914@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9914>
_______________________________________

From report at bugs.python.org  Fri Jul 20 20:35:01 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 20 Jul 2012 18:35:01 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1342809301.41.0.183172521834.issue3367@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think the original issue in parsetok.c is still present. The
fix that was committed was for sys_update_path().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Fri Jul 20 20:35:19 2012
From: report at bugs.python.org (Igor Sobreira)
Date: Fri, 20 Jul 2012 18:35:19 +0000
Subject: [issue15010] unittest: _top_level_dir is incorrectly persisted
	between calls to different load_test methods
In-Reply-To: <1338945643.44.0.808523506511.issue15010@psf.upfronthosting.co.za>
Message-ID: <1342809319.82.0.619044897905.issue15010@psf.upfronthosting.co.za>


Igor Sobreira <igor at igorsobreira.com> added the comment:

Updated patch to restore previous value of ._top_level_dir on discover() done. And added a unit test.

----------
Added file: http://bugs.python.org/file26458/restore_top_level_dir_to_previous_value.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15010>
_______________________________________

From report at bugs.python.org  Fri Jul 20 20:49:02 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jul 2012 18:49:02 +0000
Subject: [issue15168] Move importlib.test to test.importlib
In-Reply-To: <1340567730.83.0.639842949641.issue15168@psf.upfronthosting.co.za>
Message-ID: <3Wf1Mx3VVRzPPn@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4cebcfc97774 by Brett Cannon in branch 'default':
Issue #15168: Move importlb.test to test.test_importlib.
http://hg.python.org/cpython/rev/4cebcfc97774

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15168>
_______________________________________

From report at bugs.python.org  Fri Jul 20 20:55:56 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 18:55:56 +0000
Subject: [issue15168] Move importlib.test to test.importlib
In-Reply-To: <1340567730.83.0.639842949641.issue15168@psf.upfronthosting.co.za>
Message-ID: <1342810556.23.0.665357616206.issue15168@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15168>
_______________________________________

From report at bugs.python.org  Fri Jul 20 20:57:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 Jul 2012 18:57:59 +0000
Subject: [issue15163] pydoc displays __loader__ as module data
In-Reply-To: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za>
Message-ID: <1342810679.13.0.889387016417.issue15163@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have internet problems at home and am not set up to work on Python at work, so feel free to commit the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15163>
_______________________________________

From report at bugs.python.org  Fri Jul 20 21:00:11 2012
From: report at bugs.python.org (Hugo Lopes Tavares)
Date: Fri, 20 Jul 2012 19:00:11 +0000
Subject: [issue9736] doctest.DocTestSuite doesn't handle test globs correctly
In-Reply-To: <1283367674.32.0.228375766546.issue9736@psf.upfronthosting.co.za>
Message-ID: <1342810811.44.0.231773397444.issue9736@psf.upfronthosting.co.za>


Hugo Lopes Tavares <hltbra at gmail.com> added the comment:

I see the bug was not fixed yet, and I started to investigate it.

I am attaching a test patch. I don't know if I will get it working soon, since I see it as a very low priority for Python.

----------
keywords: +patch
nosy: +hltbra
versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2
Added file: http://bugs.python.org/file26459/issue9736_doctestsuite_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9736>
_______________________________________

From report at bugs.python.org  Fri Jul 20 21:26:39 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 19:26:39 +0000
Subject: [issue15409] Deprecation Warning fix on cookiejar module
In-Reply-To: <1342806618.21.0.425408251196.issue15409@psf.upfronthosting.co.za>
Message-ID: <1342812399.84.0.0765180629479.issue15409@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

This looks OK to me.  I will commit later today.

----------
assignee:  -> meador.inge
components: +Library (Lib) -Extension Modules
stage:  -> commit review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15409>
_______________________________________

From report at bugs.python.org  Fri Jul 20 21:33:34 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Fri, 20 Jul 2012 19:33:34 +0000
Subject: [issue15409] Deprecation Warning fix on cookiejar module
In-Reply-To: <1342806618.21.0.425408251196.issue15409@psf.upfronthosting.co.za>
Message-ID: <1342812814.48.0.0698751425433.issue15409@psf.upfronthosting.co.za>


Fl?vio Ribeiro <email at flavioribeiro.com> added the comment:

nice Meador :-) 

Already sent the form to contributors at python.org. Added also one diff to Misc/ACKS, it's up to you add it or not.

Thanks

----------
Added file: http://bugs.python.org/file26460/add_flavioribeiro_acks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15409>
_______________________________________

From report at bugs.python.org  Fri Jul 20 21:37:49 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 19:37:49 +0000
Subject: [issue15409] Deprecation Warning fix on cookiejar module
In-Reply-To: <1342806618.21.0.425408251196.issue15409@psf.upfronthosting.co.za>
Message-ID: <1342813069.81.0.594402438611.issue15409@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I already added you to ACKS with the ctypes patch :-)

http://hg.python.org/cpython/rev/f93efd4c45bd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15409>
_______________________________________

From report at bugs.python.org  Fri Jul 20 21:39:29 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Jul 2012 19:39:29 +0000
Subject: [issue15168] Move importlib.test to test.importlib
In-Reply-To: <1340567730.83.0.639842949641.issue15168@psf.upfronthosting.co.za>
Message-ID: <1342813169.42.0.121653473593.issue15168@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks like this broke the buildbots.

----------
nosy: +r.david.murray
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15168>
_______________________________________

From report at bugs.python.org  Fri Jul 20 21:42:55 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 19:42:55 +0000
Subject: [issue15168] Move importlib.test to test.importlib
In-Reply-To: <1340567730.83.0.639842949641.issue15168@psf.upfronthosting.co.za>
Message-ID: <1342813375.06.0.533704280783.issue15168@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixed by e5c34fe087ef and e2787e926969

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15168>
_______________________________________

From report at bugs.python.org  Fri Jul 20 22:25:33 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jul 2012 20:25:33 +0000
Subject: [issue15168] Move importlib.test to test.importlib
In-Reply-To: <1340567730.83.0.639842949641.issue15168@psf.upfronthosting.co.za>
Message-ID: <3Wf3WH5rglzLvW@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f1f480650a0a by Ned Deily in branch 'default':
Issue #15168: Ensure test_importlib subdirectories are installed.
http://hg.python.org/cpython/rev/f1f480650a0a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15168>
_______________________________________

From report at bugs.python.org  Fri Jul 20 22:30:29 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Jul 2012 20:30:29 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342816229.54.0.12043285344.issue15381@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

The patch updated. Fixed some errors, optimized initialization, added checks and comments. I think that now the patch is ready for review.

----------
Added file: http://bugs.python.org/file26461/bytesio_resized_bytes-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 22:30:58 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Jul 2012 20:30:58 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342816258.31.0.0334387923887.issue15381@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file26429/bytesio_resized_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 22:32:05 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Jul 2012 20:32:05 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342816325.34.0.805239285965.issue15381@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> There seems to be a problem with the patch: when you store the getvalue() result somewhere (instead of discarding it), things get much slower:

This problem exists with the new patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 22:48:26 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Jul 2012 20:48:26 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342817306.84.0.571987628744.issue15381@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Under Windows (64-bit Windows 7 on a  VirtualBox VM), the patch increases performance slightly but not as much as under Linux:

Thank you, Antoine. This is an expected result.

> And the join() approach is 10x faster (!):
> C:\t\cpython>pc\VS9.0\amd64\python.exe -m timeit -s "import io; n=2000; d=[b'a'*
> n,b'bb'*n,b'ccc'*n]*1000"  "b''.join(d)"
> 100 loops, best of 3: 4.63 msec per loop

To be fair, test body should be: "s=[]; w=s.append"  "for x in d: w(x)"  "b''.join(s)"

May be tuning resize strategy (overallocate not 1/8, but 1/4, 1/2, or 100%) can help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 22:53:34 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Jul 2012 20:53:34 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342816325.34.0.805239285965.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342817503.3377.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > There seems to be a problem with the patch: when you store the
> getvalue() result somewhere (instead of discarding it), things get
> much slower:
> 
> This problem exists with the new patch?

I think you can run the benchmark yourself (I ran it under Linux).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 23:12:00 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Jul 2012 21:12:00 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342817503.3377.1.camel@localhost.localdomain>
Message-ID: <201207210011.30695.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> I think you can run the benchmark yourself (I ran it under Linux).

I don't see any differences.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Jul 20 23:18:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Jul 2012 21:18:46 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342819126.43.0.572232104551.issue15381@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, with the latest patch I get:

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
1000 loops, best of 3: 982 usec per loop

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "global y; y = s.getvalue()"
100 loops, best of 3: 4.79 msec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Sat Jul 21 00:00:59 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Fri, 20 Jul 2012 22:00:59 +0000
Subject: [issue15409] Deprecation Warning fix on cookiejar module
In-Reply-To: <1342806618.21.0.425408251196.issue15409@psf.upfronthosting.co.za>
Message-ID: <1342821659.75.0.00275218147257.issue15409@psf.upfronthosting.co.za>


Fl?vio Ribeiro <email at flavioribeiro.com> added the comment:

wow :) thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15409>
_______________________________________

From report at bugs.python.org  Sat Jul 21 00:37:53 2012
From: report at bugs.python.org (Davide Rizzo)
Date: Fri, 20 Jul 2012 22:37:53 +0000
Subject: [issue15360] Behavior of assigning to __dict__ is not documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1342823873.36.0.576466728664.issue15360@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

Amaury, I don't honestly know, I would have proposed something otherwise.

I have been advised on #python (Freenode) not to assign to obj.__dict__ because its behaviour changes between versions and implementations, but I wouldn't know what has changed between CPython version.

One obscure thing is what can be assigned to __dict__. For class dicts no assignment is allowed. Object dicts can be assigned dict objects. If you try to assign a non-dict mapping it will complain.

However you can assign a dict-derived object, something like:

class SillyDict(dict):
    def __getitem__(self, key):
        return "hello"

obj.__dict__ = SillyDict()

Unfortunately accessing the attributes of obj will still use PyDict_* functions, thus ignoring any magic methods.

PyPy's behavior is slightly different. A class __dict__ attribute still is read only, but you can assign any mapping object to an object __dict__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15360>
_______________________________________

From report at bugs.python.org  Sat Jul 21 00:41:06 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Jul 2012 22:41:06 +0000
Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after
	error handling
In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za>
Message-ID: <1342824066.05.0.076817913481.issue14579@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There are spurious print() calls in the 2.7 patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14579>
_______________________________________

From report at bugs.python.org  Sat Jul 21 00:45:57 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Jul 2012 22:45:57 +0000
Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after
	error handling
In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za>
Message-ID: <1342824357.6.0.375396513042.issue14579@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: test needed -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14579>
_______________________________________

From report at bugs.python.org  Sat Jul 21 00:50:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jul 2012 22:50:12 +0000
Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after
	error handling
In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za>
Message-ID: <3Wf6kC2K9rzPPy@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 034ff986019d by Antoine Pitrou in branch '3.2':
Issue #14579: Fix CVE-2012-2135: vulnerability in the utf-16 decoder after error handling.
http://hg.python.org/cpython/rev/034ff986019d

New changeset 118fe0ee6921 by Antoine Pitrou in branch 'default':
Port additional tests from #14579 (the issue is already fixed).
http://hg.python.org/cpython/rev/118fe0ee6921

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14579>
_______________________________________

From report at bugs.python.org  Sat Jul 21 00:54:03 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jul 2012 22:54:03 +0000
Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after
	error handling
In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za>
Message-ID: <3Wf6pf5FFPzPPr@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4cadf91aaddd by Antoine Pitrou in branch '2.7':
Issue #14579: Fix error handling bug in the utf-16 decoder.
http://hg.python.org/cpython/rev/4cadf91aaddd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14579>
_______________________________________

From report at bugs.python.org  Sat Jul 21 00:54:34 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Jul 2012 22:54:34 +0000
Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after
	error handling
In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za>
Message-ID: <1342824874.65.0.557578978864.issue14579@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patches, Serhiy! They're now pushed.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14579>
_______________________________________

From report at bugs.python.org  Sat Jul 21 02:13:55 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Jul 2012 00:13:55 +0000
Subject: [issue15409] Deprecation Warning fix on cookiejar module
In-Reply-To: <1342806618.21.0.425408251196.issue15409@psf.upfronthosting.co.za>
Message-ID: <3Wf8Zg5H19zPPB@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ea8078365d3b by Meador Inge in branch 'default':
Issue #15409: Replace use of deprecated urllib.request.Request methods in http.cookijar
http://hg.python.org/cpython/rev/ea8078365d3b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15409>
_______________________________________

From report at bugs.python.org  Sat Jul 21 02:14:51 2012
From: report at bugs.python.org (Meador Inge)
Date: Sat, 21 Jul 2012 00:14:51 +0000
Subject: [issue15409] Deprecation Warning fix on cookiejar module
In-Reply-To: <1342806618.21.0.425408251196.issue15409@psf.upfronthosting.co.za>
Message-ID: <1342829691.85.0.810360107148.issue15409@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Thanks for the patch!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15409>
_______________________________________

From report at bugs.python.org  Sat Jul 21 02:35:10 2012
From: report at bugs.python.org (Meador Inge)
Date: Sat, 21 Jul 2012 00:35:10 +0000
Subject: [issue15410] urllib.request.Request.is_unverifiable deprecation
	documentation is incorrect
Message-ID: <1342830910.16.0.163498424458.issue15410@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

While reviewing the change for issue15409 I noticed that the 'urlib.request' documentation has an error in the deprecation note for 'urllib.request.Request.is_unverifiable' [1]:

"""
Deprecated in 3.3, use Request.is_unverifiable.
"""

The deprecation text of 'is_unverifiable' shouldn't be recommending 'is_unverifiable' as a replacement :-)  The text should actually read:

"""
Deprecated in 3.3, use Request.unverifiable.
"""

I will patch this shortly.

[1] http://docs.python.org/dev/library/urllib.request.html#urllib.request.Request.is_unverifiable

----------
assignee: meador.inge
components: Documentation
messages: 165990
nosy: meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.request.Request.is_unverifiable deprecation documentation is incorrect
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15410>
_______________________________________

From report at bugs.python.org  Sat Jul 21 02:51:30 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Jul 2012 00:51:30 +0000
Subject: [issue15410] urllib.request.Request.is_unverifiable deprecation
	documentation is incorrect
In-Reply-To: <1342830910.16.0.163498424458.issue15410@psf.upfronthosting.co.za>
Message-ID: <3Wf9Q73qgLzPPn@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f39895c55699 by Meador Inge in branch 'default':
Issue #15410: Fix the urllib.request.Request.is_unverifiable deprecation documentation.
http://hg.python.org/cpython/rev/f39895c55699

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15410>
_______________________________________

From report at bugs.python.org  Sat Jul 21 02:52:29 2012
From: report at bugs.python.org (Meador Inge)
Date: Sat, 21 Jul 2012 00:52:29 +0000
Subject: [issue15410] urllib.request.Request.is_unverifiable deprecation
	documentation is incorrect
In-Reply-To: <1342830910.16.0.163498424458.issue15410@psf.upfronthosting.co.za>
Message-ID: <1342831949.7.0.771694558032.issue15410@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15410>
_______________________________________

From report at bugs.python.org  Sat Jul 21 05:47:21 2012
From: report at bugs.python.org (Meador Inge)
Date: Sat, 21 Jul 2012 03:47:21 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1342842441.26.0.198751139218.issue3367@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I can still reproduce the parsetok.c problem on the 'default' branch using the CTRL+D method Stefan described.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Sat Jul 21 06:48:10 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 21 Jul 2012 04:48:10 +0000
Subject: [issue15063] Source code links for JSON documentation
In-Reply-To: <1339648255.05.0.789234331886.issue15063@psf.upfronthosting.co.za>
Message-ID: <1342846090.1.0.570482968709.issue15063@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I am with ?ric on this. Looking at json/decoder.py and json/encoder.py, I too feel that source link may not be helpful as much as it is helpful for others. Docs are best here. I am closing this report. Thanks!

----------
nosy: +orsenthil
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15063>
_______________________________________

From report at bugs.python.org  Sat Jul 21 08:16:09 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Jul 2012 06:16:09 +0000
Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after
	error handling
In-Reply-To: <1342824066.05.0.076817913481.issue14579@psf.upfronthosting.co.za>
Message-ID: <201207210915.54059.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> There are spurious print() calls in the 2.7 patch.

Oh, my inattentiveness. Thank you for pushing, Antoine. And thank Martin for 
review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14579>
_______________________________________

From report at bugs.python.org  Sat Jul 21 08:30:21 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Jul 2012 06:30:21 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342819126.43.0.572232104551.issue15381@psf.upfronthosting.co.za>
Message-ID: <201207210930.04405.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Hmm. Without the ability to reproduce this effect, it will be difficult for me to 
get rid of him. What times for StringIO, append/join, unpatched BytesIO? Do 
this happen with a little different numbers (n=1500, 1600,...,3000)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Sat Jul 21 10:31:25 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sat, 21 Jul 2012 08:31:25 +0000
Subject: [issue15411] os.chmod() does not follow symlinks on Windows
Message-ID: <1342859484.11.0.980886642738.issue15411@psf.upfronthosting.co.za>


New submission from Atsuo Ishimoto <ishimoto at gembook.org>:

os.chmod() should check symlinks if followsymlinks option is True on Windows. 

This is a cause of failure of test case 

   test.test_shutil.TestShutil.test_copymode_follow_symlinks

(#13837)

----------
components: Library (Lib), Windows
files: chmod_symlink_win32.patch
keywords: patch
messages: 165996
nosy: ishimoto
priority: normal
severity: normal
status: open
title: os.chmod() does not follow symlinks on Windows
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26462/chmod_symlink_win32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15411>
_______________________________________

From report at bugs.python.org  Sat Jul 21 10:33:48 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sat, 21 Jul 2012 08:33:48 +0000
Subject: [issue13837] test_shutil fails with symlinks enabled under Windows
In-Reply-To: <1327255807.39.0.63998442373.issue13837@psf.upfronthosting.co.za>
Message-ID: <1342859628.62.0.876747334814.issue13837@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Error in test_copymode_follow_symlinks is adderessed in #15411.

----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13837>
_______________________________________

From report at bugs.python.org  Sat Jul 21 11:23:13 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Jul 2012 09:23:13 +0000
Subject: [issue14998] pprint._safe_key is not always safe enough
In-Reply-To: <1338780735.82.0.957035826982.issue14998@psf.upfronthosting.co.za>
Message-ID: <3WfNmc34NmzPSq@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 03cda5360dc6 by Florent Xicluna in branch '3.2':
Issues #10017 and #14998: Fix TypeError using pprint on dictionaries with unorderable key.
http://hg.python.org/cpython/rev/03cda5360dc6

New changeset 4d0dcfbdf45b by Florent Xicluna in branch 'default':
Issues #10017 and #14998: Fix TypeError using pprint on dictionaries with unorderable key.
http://hg.python.org/cpython/rev/4d0dcfbdf45b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14998>
_______________________________________

From report at bugs.python.org  Sat Jul 21 11:23:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Jul 2012 09:23:14 +0000
Subject: [issue10017] pprint.pprint raises TypeError on dictionaries with
	user-defined types as keys
In-Reply-To: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>
Message-ID: <3WfNmd1X9gzPSq@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 03cda5360dc6 by Florent Xicluna in branch '3.2':
Issues #10017 and #14998: Fix TypeError using pprint on dictionaries with unorderable key.
http://hg.python.org/cpython/rev/03cda5360dc6

New changeset 4d0dcfbdf45b by Florent Xicluna in branch 'default':
Issues #10017 and #14998: Fix TypeError using pprint on dictionaries with unorderable key.
http://hg.python.org/cpython/rev/4d0dcfbdf45b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10017>
_______________________________________

From report at bugs.python.org  Sat Jul 21 11:27:05 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 09:27:05 +0000
Subject: [issue10017] pprint.pprint raises TypeError on dictionaries with
	user-defined types as keys
In-Reply-To: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>
Message-ID: <1342862825.39.0.540424211027.issue10017@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Thanks for this patch.
I've reviewed the issue and merged the patch of issue #14998 which fixes both cases.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> pprint._safe_key is not always safe enough

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10017>
_______________________________________

From report at bugs.python.org  Sat Jul 21 11:29:03 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 09:29:03 +0000
Subject: [issue14998] pprint._safe_key is not always safe enough
In-Reply-To: <1338780735.82.0.957035826982.issue14998@psf.upfronthosting.co.za>
Message-ID: <1342862943.63.0.452154147937.issue14998@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Thank you for this patch.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14998>
_______________________________________

From report at bugs.python.org  Sat Jul 21 11:41:58 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sat, 21 Jul 2012 09:41:58 +0000
Subject: [issue15412] Note in documentation for weakrefs
Message-ID: <1342863718.26.0.49587627068.issue15412@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

In the documentation on weakrefs there is the following quote

    Note: Weak references to an object are cleared before the object?s
    __del__() is called, to ensure that the weak reference callback 
    (if any) finds the object still alive.

But I think the weakref is always dead by the time the callback is invoked.  The first paragraph from the documentation for weakref.ref(object[, callback]) contains the following:

    If callback is provided and not None, and the returned weakref 
    object is still alive, the callback will be called when the object 
    is about to be finalized; the weak reference object will be passed 
    as the only parameter to the callback; **the referent will no longer 
    be available**.

Which does prompt a question: what use is there for the weakref argument to the callback if it already dead?

(Compare http://bugs.python.org/issue14933)

----------
assignee: docs at python
components: Documentation
messages: 166002
nosy: docs at python, pitrou, sbt
priority: normal
severity: normal
status: open
title: Note in documentation for weakrefs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15412>
_______________________________________

From report at bugs.python.org  Sat Jul 21 11:47:40 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sat, 21 Jul 2012 09:47:40 +0000
Subject: [issue15411] os.chmod() does not follow symlinks on Windows
In-Reply-To: <1342859484.11.0.980886642738.issue15411@psf.upfronthosting.co.za>
Message-ID: <1342864060.88.0.299160913179.issue15411@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Patch updated. Check symlinks only if supported by platform.

----------
Added file: http://bugs.python.org/file26463/issue1492704_new_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15411>
_______________________________________

From report at bugs.python.org  Sat Jul 21 11:48:28 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sat, 21 Jul 2012 09:48:28 +0000
Subject: [issue15411] os.chmod() does not follow symlinks on Windows
In-Reply-To: <1342859484.11.0.980886642738.issue15411@psf.upfronthosting.co.za>
Message-ID: <1342864108.19.0.336121949341.issue15411@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


Removed file: http://bugs.python.org/file26463/issue1492704_new_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15411>
_______________________________________

From report at bugs.python.org  Sat Jul 21 11:49:52 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sat, 21 Jul 2012 09:49:52 +0000
Subject: [issue15411] os.chmod() does not follow symlinks on Windows
In-Reply-To: <1342859484.11.0.980886642738.issue15411@psf.upfronthosting.co.za>
Message-ID: <1342864192.26.0.917603879444.issue15411@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


Added file: http://bugs.python.org/file26464/chmod_symlink_win32_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15411>
_______________________________________

From report at bugs.python.org  Sat Jul 21 12:10:34 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 10:10:34 +0000
Subject: [issue2919] Merge profile/cProfile in 3.n+1
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1342865434.78.0.685402600655.issue2919@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/issue2919>
_______________________________________

From report at bugs.python.org  Sat Jul 21 12:13:48 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 10:13:48 +0000
Subject: [issue14998] pprint._safe_key is not always safe enough
In-Reply-To: <1338780735.82.0.957035826982.issue14998@psf.upfronthosting.co.za>
Message-ID: <1342865628.49.0.380958443945.issue14998@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I just broke tests :(

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14998>
_______________________________________

From report at bugs.python.org  Sat Jul 21 12:15:33 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 10:15:33 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <201207210930.04405.storchaka@gmail.com>
Message-ID: <1342865621.3492.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Hmm. Without the ability to reproduce this effect, it will be difficult for me to 
> get rid of him.

It's under 64-bit Linux, Intel Core i5 CPU. Are you sure you're testing
in non-debug mode?

That said, the numbers under Windows suggest me that Eli's original idea
(append and then join at the end) would be more robust.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Sat Jul 21 12:23:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 10:23:53 +0000
Subject: [issue15412] Note in documentation for weakrefs
In-Reply-To: <1342863718.26.0.49587627068.issue15412@psf.upfronthosting.co.za>
Message-ID: <1342866122.3492.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In the documentation on weakrefs there is the following quote
> 
>     Note: Weak references to an object are cleared before the object?s
>     __del__() is called, to ensure that the weak reference callback 
>     (if any) finds the object still alive.
> 
> But I think the weakref is always dead by the time the callback is
> invoked.

It's true, the doc needs fixing.

> Which does prompt a question: what use is there for the weakref
> argument to the callback if it already dead?

The weakref is "dead" but it's still a weakref, and it can be used to
e.g. index a container of existing weakrefs (cf. WeakSet,
WeakKeyDictionary, WeakValueDictionary).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15412>
_______________________________________

From report at bugs.python.org  Sat Jul 21 12:27:21 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 10:27:21 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342866441.49.0.616880484445.issue15381@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, here is Matt Mackall's take on realloc():

http://www.selenic.com/pipermail/mercurial-devel/2011-October/034988.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Sat Jul 21 12:37:27 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 10:37:27 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1342867047.2.0.549556856417.issue15381@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

StringIO:

$ ./python -m timeit -s "import io; n=2000; d=['a'*n,'bb'*n,'ccc'*n]*1000"  "s=io.StringIO(); w=s.write"  "for x in d: w(x)"  "global y; y = s.getvalue()"

-> Linux: 1000 loops, best of 3: 985 usec per loop
-> Windows: 100 loops, best of 3: 4.26 msec per loop

Unpatched BytesIO:

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "global y; y = s.getvalue()"

-> Linux: 100 loops, best of 3: 2.44 msec per loop
-> Windows: 10 loops, best of 3: 38.4 msec per loop

b''.join():

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "l = list(d)"  "global y; y = b''.join(l)"

-> Linux: 1000 loops, best of 3: 821 usec per loop
-> Windows: 100 loops, best of 3: 4.09 msec per loop

bytearray:

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "b = bytearray()" "for x in d: b += x" "global y; y = b"

-> Linux: 1000 loops, best of 3: 834 usec per loop
-> Windows: 10 loops, best of 3: 37.8 msec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Sat Jul 21 12:58:22 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sat, 21 Jul 2012 10:58:22 +0000
Subject: [issue15412] Note in documentation for weakrefs
In-Reply-To: <1342863718.26.0.49587627068.issue15412@psf.upfronthosting.co.za>
Message-ID: <1342868302.42.0.824683171539.issue15412@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

> The weakref is "dead" but it's still a weakref, and it can be used to
> e.g. index a container of existing weakrefs (cf. WeakSet,
> WeakKeyDictionary, WeakValueDictionary).

Ah.

I had assumed that since dead weakrefs were unhashable you couldn't safely use them as keys in a dict.  (Presumably removal of a no longer hashable key from a dict is O(n)?)

I also hadn't realize that weakrefs were subclassable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15412>
_______________________________________

From report at bugs.python.org  Sat Jul 21 12:59:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 10:59:29 +0000
Subject: [issue15412] Note in documentation for weakrefs
In-Reply-To: <1342868302.42.0.824683171539.issue15412@psf.upfronthosting.co.za>
Message-ID: <1342868258.3492.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I had assumed that since dead weakrefs were unhashable you couldn't
> safely use them as keys in a dict.  (Presumably removal of a no longer
> hashable key from a dict is O(n)?)

They are unhashable if you didn't hash them alive. Otherwise they retain
their old hash value (which is quite useful :-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15412>
_______________________________________

From report at bugs.python.org  Sat Jul 21 13:05:24 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 11:05:24 +0000
Subject: [issue14998] pprint._safe_key is not always safe enough
In-Reply-To: <1338780735.82.0.957035826982.issue14998@psf.upfronthosting.co.za>
Message-ID: <1342868724.87.0.223911989873.issue14998@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Test test_pprint fixed with changesets 29642f82bbcc and 79d44f4920d9.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14998>
_______________________________________

From report at bugs.python.org  Sat Jul 21 13:41:15 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 21 Jul 2012 11:41:15 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1342870875.94.0.962676510061.issue12834@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

There is an additional problem with PyBuffer_ToContiguous():

Suppose 'view' is multi-dimensional, C-contiguous and initialized
according to PyBUF_ND, i.e. view->shape != NULL but view->strides == NULL.

Now if PyBuffer_ToContiguous() is called with 'F', PyBuffer_IsContiguous()
returns false and view->strides will be accessed.


This means that incomplete buffer information will have to be
reconstructed like it is done in the 3.3 memoryview.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Sat Jul 21 14:09:19 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 12:09:19 +0000
Subject: [issue7214] TreeBuilder.end(tag) differs between cElementTree and
	ElementTree
In-Reply-To: <1256599950.66.0.903450683949.issue7214@psf.upfronthosting.co.za>
Message-ID: <1342872559.82.0.297520051357.issue7214@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file18445/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7214>
_______________________________________

From report at bugs.python.org  Sat Jul 21 14:12:09 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 12:12:09 +0000
Subject: [issue7214] TreeBuilder.end(tag) differs between cElementTree and
	ElementTree
In-Reply-To: <1256599950.66.0.903450683949.issue7214@psf.upfronthosting.co.za>
Message-ID: <1342872729.09.0.446402960256.issue7214@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

does it require action in 3.3, where the C implementation is active by default?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7214>
_______________________________________

From report at bugs.python.org  Sat Jul 21 14:12:28 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 12:12:28 +0000
Subject: [issue7214] TreeBuilder.end(tag) differs between cElementTree and
	ElementTree
In-Reply-To: <1256599950.66.0.903450683949.issue7214@psf.upfronthosting.co.za>
Message-ID: <1342872748.37.0.695305376544.issue7214@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +eli.bendersky
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7214>
_______________________________________

From report at bugs.python.org  Sat Jul 21 14:21:08 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 12:21:08 +0000
Subject: [issue9610] buildbot: uncaptured python exception (smtpd),
	but no failure in regrtest
In-Reply-To: <1281888180.27.0.972389981931.issue9610@psf.upfronthosting.co.za>
Message-ID: <1342873268.74.0.530278057542.issue9610@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

probably related to issue #5154 mentioned in previous comment: http://bugs.python.org/issue9610#msg114000

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9610>
_______________________________________

From report at bugs.python.org  Sat Jul 21 14:29:47 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 12:29:47 +0000
Subject: [issue3609] does parse_header really belong in CGI module?
In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za>
Message-ID: <1342873787.31.0.3904578989.issue3609@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This refactoring between cgi and email modules is languishing for few years.
Any thought?

----------
status: open -> languishing
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3609>
_______________________________________

From report at bugs.python.org  Sat Jul 21 14:31:46 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 12:31:46 +0000
Subject: [issue8273] move generally useful test.support functions into the
	unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1342873906.36.0.0527832427392.issue8273@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
versions: +Python 3.4 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Sat Jul 21 14:38:58 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 12:38:58 +0000
Subject: [issue5504] ctypes should work with systems where mmap can't
	be	PROT_WRITE and PROT_EXEC
In-Reply-To: <1237348531.28.0.513167073983.issue5504@psf.upfronthosting.co.za>
Message-ID: <1342874338.35.0.37010975109.issue5504@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/issue5504>
_______________________________________

From report at bugs.python.org  Sat Jul 21 14:44:24 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Jul 2012 12:44:24 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <3WfTDl1YwszPTH@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d76b83803e7e by Ned Deily in branch 'default':
Issue #15184: Ensure consistent results of OS X configuration
http://hg.python.org/cpython/rev/d76b83803e7e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sat Jul 21 14:55:34 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 Jul 2012 12:55:34 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342875334.22.0.771116164492.issue15184@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I've committed an updated version of the refactoring patch which attempts to handle some additional edge cases and which includes a number of additional tests.  I still have not been able to reproduce the original failure so I'm setting the status to pending awaiting a test report from Georg or someone else who is able to reproduce it.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sat Jul 21 14:57:15 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 12:57:15 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1342875435.01.0.350210761443.issue9566@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Attached file is a copy of the remaining warnings on the AMD64 Windows7 SP1 3.x builder.

----------
keywords: +buildbot
nosy: +flox
Added file: http://bugs.python.org/file26465/warnings64.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Sat Jul 21 15:00:19 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 13:00:19 +0000
Subject: [issue9783] _elementtree.c warnings under 64-bit Windows
In-Reply-To: <1283777393.95.0.65520363014.issue9783@psf.upfronthosting.co.za>
Message-ID: <1342875619.58.0.274876967883.issue9783@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This warning is not specific to the _elementtree module.
See related issue #9566.

----------
nosy: +eli.bendersky
resolution:  -> duplicate
status: open -> closed
superseder:  -> Compilation warnings under x64 Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9783>
_______________________________________

From report at bugs.python.org  Sat Jul 21 15:04:30 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 13:04:30 +0000
Subject: [issue9772] test_pep277 failure on AMD64 debian parallel buildbot
In-Reply-To: <1283601685.6.0.819525034936.issue9772@psf.upfronthosting.co.za>
Message-ID: <1342875870.22.0.498227029106.issue9772@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> That appears to be a bug in the NFS server.

So, it's not a Python bug.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9772>
_______________________________________

From report at bugs.python.org  Sat Jul 21 15:14:53 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 13:14:53 +0000
Subject: [issue1610654] cgi.py multipart/form-data
Message-ID: <1342876493.22.0.311205020305.issue1610654@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It needs tests to demonstrate the issue in 3.x, and an updated patch.

----------
nosy: +hynek, pitrou
stage: patch review -> test needed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1610654>
_______________________________________

From report at bugs.python.org  Sat Jul 21 15:15:12 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 Jul 2012 13:15:12 +0000
Subject: [issue15195] test_distutils fails when ARCHFLAGS is set on a Mac
In-Reply-To: <1340724368.12.0.314472087482.issue15195@psf.upfronthosting.co.za>
Message-ID: <1342876512.61.0.868351426942.issue15195@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This problem has been fixed in changeset d76b83803e7e for Issue15184 which, among other things, tries to make the handling of ARCHFLAGS more consistent.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Test failure in test_sysconfig_module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15195>
_______________________________________

From report at bugs.python.org  Sat Jul 21 15:19:57 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 13:19:57 +0000
Subject: [issue9771] add an optional "default" argument to
	tokenize.detect_encoding
In-Reply-To: <1283599930.65.0.476914851505.issue9771@psf.upfronthosting.co.za>
Message-ID: <1342876797.48.0.058625417442.issue9771@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9771>
_______________________________________

From report at bugs.python.org  Sat Jul 21 15:33:30 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 13:33:30 +0000
Subject: [issue9692] UnicodeDecodeError in ElementTree.tostring()
In-Reply-To: <1282833776.05.0.825088232802.issue9692@psf.upfronthosting.co.za>
Message-ID: <1342877610.48.0.667781726011.issue9692@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I propose to close this as won't fix.

The upgrade to ElementTree 1.3 brought some consistency when dealing with Unicode and encodings.

The reported behavior was only seen in Python 2.7, when using bytes improperly.

----------
nosy: +eli.bendersky
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9692>
_______________________________________

From report at bugs.python.org  Sat Jul 21 15:36:28 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 13:36:28 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1342877788.7.0.411411792379.issue3783@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sat Jul 21 15:42:41 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 13:42:41 +0000
Subject: [issue1610654] cgi.py multipart/form-data
Message-ID: <1342878161.06.0.943571498704.issue1610654@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/issue1610654>
_______________________________________

From report at bugs.python.org  Sat Jul 21 15:43:06 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 13:43:06 +0000
Subject: [issue5166] ElementTree and minidom don't prevent creation of not
	well-formed XML
In-Reply-To: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za>
Message-ID: <1342878186.46.0.594509599244.issue5166@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
assignee: effbot -> 
components: +XML
versions: +Python 3.4 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5166>
_______________________________________

From report at bugs.python.org  Sat Jul 21 15:46:57 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 13:46:57 +0000
Subject: [issue7990] xml.etree.cElementTree lacks full dir() on Element
In-Reply-To: <1266856563.54.0.534391635456.issue7990@psf.upfronthosting.co.za>
Message-ID: <1342878417.37.0.913182941224.issue7990@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
assignee: effbot -> 
nosy: +eli.bendersky
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7990>
_______________________________________

From report at bugs.python.org  Sat Jul 21 15:50:21 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 13:50:21 +0000
Subject: [issue6625] UnicodeEncodeError on pydoc's CLI
In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>
Message-ID: <1342878621.22.0.548671989964.issue6625@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6625>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:05:37 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 14:05:37 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1342879537.52.0.670001260562.issue8583@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

See also issue 13378 which proposes custom namespace maps for serializing.

----------
components: +XML
nosy: +eli.bendersky
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8583>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:09:02 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 14:09:02 +0000
Subject: [issue12323] ElementPath 1.3 expressions
In-Reply-To: <1307959893.21.0.719611338142.issue12323@psf.upfronthosting.co.za>
Message-ID: <1342879742.46.0.897904861036.issue12323@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +eli.bendersky
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12323>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:10:19 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 14:10:19 +0000
Subject: [issue12322] ElementPath 1.3 expressions documentation
In-Reply-To: <1307959369.7.0.162667287307.issue12322@psf.upfronthosting.co.za>
Message-ID: <1342879819.86.0.095519594439.issue12322@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
keywords: +easy
nosy: +eli.bendersky
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12322>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:11:47 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 14:11:47 +0000
Subject: [issue12321] documentation of ElementTree.find
In-Reply-To: <1307958561.6.0.547513151308.issue12321@psf.upfronthosting.co.za>
Message-ID: <1342879907.37.0.59227177445.issue12321@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12321>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:13:00 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 14:13:00 +0000
Subject: [issue1573931] WSGI, cgi.FieldStorage incompatibility
Message-ID: <1342879980.57.0.805429827076.issue1573931@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +orsenthil
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1573931>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:15:03 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 14:15:03 +0000
Subject: [issue12411] cgi.parse_multipart is broken on 3.x
In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za>
Message-ID: <1342880103.64.0.0272464686125.issue12411@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12411>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:21:22 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Jul 2012 14:21:22 +0000
Subject: [issue15147] Remove packaging from the stdlib
In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za>
Message-ID: <1342880482.91.0.885442065004.issue15147@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Eric, ping?  When can this be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15147>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:22:11 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Jul 2012 14:22:11 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1342880531.2.0.984333928241.issue14578@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ping. Brian?  I'd rather have some testing period for this, so I'm reluctant to release b2 without it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:22:44 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Jul 2012 14:22:44 +0000
Subject: [issue15037] curses.unget_wch and test_curses fail when linked with
	ncurses 5.7 and earlier
In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za>
Message-ID: <1342880564.06.0.140395843775.issue15037@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Documentation issue, can be resolved after b2.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15037>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:23:38 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Jul 2012 14:23:38 +0000
Subject: [issue15295] Document PEP 420 namespace packages
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1342880618.61.0.956745491576.issue15295@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ping. Barry? (It's not strictly necessary to have the docs for b2, but could you give me a rough estimate when you'll do this?)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:24:08 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 Jul 2012 14:24:08 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342880648.85.0.0622793548545.issue15184@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Buildbot test failure:
http://buildbot.python.org/all/builders/AMD64%20Snow%20Leopard%203.x/builds/66

----------
resolution: fixed -> 
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:25:41 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Jul 2012 14:25:41 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342880741.25.0.581291207923.issue15184@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Damn, I don't have clang on this machine.  Will install and test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:26:33 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Jul 2012 14:26:33 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>
Message-ID: <1342880793.93.0.152404562018.issue15298@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The bug certainly is a valid annoyance, but I won't hold up beta2 for it.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15298>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:27:47 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Jul 2012 14:27:47 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1342880867.94.0.803646259135.issue14814@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

IIUC only docs are missing now?  That's not a b2 blocker then.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:27:57 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Jul 2012 14:27:57 +0000
Subject: [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342880877.86.0.169053037316.issue15151@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Docs issues won't block b2.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15151>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:31:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 14:31:13 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342881073.56.0.446522344307.issue15184@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Buildbot test failure:
> http://buildbot.python.org/all/builders/AMD64%20Snow%20Leopard%203.x/builds/66

These failures are not new, and the buildbot is an unstable one.

As for clang, the Lion buildbot uses it and is green. Its configure line is "./configure --with-pydebug CC=clang":
http://buildbot.python.org/all/builders/AMD64%20Lion%203.x

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:33:48 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 Jul 2012 14:33:48 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342881228.63.0.651315358252.issue15184@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The problem isn't with clang. The problem was that the test appeared to be taking an OS X only code path apparently because a clang was installed on a Gentoo machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:41:54 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 14:41:54 +0000
Subject: [issue9773] test_tarfile fails because of inaccurate mtime on AMD64
	debian parallel buildbot
In-Reply-To: <1283602399.09.0.660649968872.issue9773@psf.upfronthosting.co.za>
Message-ID: <1342881714.63.0.412144318353.issue9773@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Yet another issue with the filesystem on the same buildbot: see issue 9772.

----------
resolution:  -> works for me
stage: needs patch -> 
status: open -> closed
superseder:  -> test_pep277 failure on AMD64 debian parallel buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9773>
_______________________________________

From report at bugs.python.org  Sat Jul 21 16:57:58 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 14:57:58 +0000
Subject: [issue7710] Inconsistent Exception for int() conversion
In-Reply-To: <1263584123.75.0.822719915688.issue7710@psf.upfronthosting.co.za>
Message-ID: <1342882678.14.0.368955438687.issue7710@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The behavior seems acceptable in 2.7 too.

>>> int('\0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: ''
>>> int('\01')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '\x01'


>>> int(u'\0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'decimal' codec can't encode character u'\x00' in position 0: invalid decimal Unicode string
>>> int(u'\01')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '\x01'

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7710>
_______________________________________

From report at bugs.python.org  Sat Jul 21 17:01:06 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 15:01:06 +0000
Subject: [issue4221] inconsistent exception from int is confusing
In-Reply-To: <1225213917.89.0.391557406226.issue4221@psf.upfronthosting.co.za>
Message-ID: <1342882866.82.0.54545342098.issue4221@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Proposed as won't fix for the 2.x series.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4221>
_______________________________________

From report at bugs.python.org  Sat Jul 21 17:11:37 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Jul 2012 15:11:37 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342883497.44.0.828877389186.issue15184@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, test passes here now with clang installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sat Jul 21 17:17:13 2012
From: report at bugs.python.org (koobs)
Date: Sat, 21 Jul 2012 15:17:13 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342883833.43.0.766551262583.issue15184@psf.upfronthosting.co.za>


koobs <koobs.freebsd at gmail.com> added the comment:

FYI, Added two FreeBSD based buildslaves to the cluster not long ago, one is dedicated to python+CLANG
 
http://buildbot.python.org/all/buildslaves/koobs-freebsd-clang

----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sat Jul 21 17:18:58 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 Jul 2012 15:18:58 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342883938.59.0.0270459055437.issue15184@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The new buildbot failure is due to that buildbot using env variables for some of the config variables during execution.  The new tests need to isolate themselves from that.  Should have a fix shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sat Jul 21 17:23:38 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 15:23:38 +0000
Subject: [issue9708] cElementTree iterparse does not support "parser" argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <1342884218.13.0.202539845237.issue9708@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Either the documentation or the implementation should be fixed in 3.3, because they do not match.

----------
nosy: +eli.bendersky
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9708>
_______________________________________

From report at bugs.python.org  Sat Jul 21 17:27:22 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 15:27:22 +0000
Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular
	encoding
In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za>
Message-ID: <1342884442.87.0.903129559792.issue13612@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13612>
_______________________________________

From report at bugs.python.org  Sat Jul 21 17:54:31 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Jul 2012 15:54:31 +0000
Subject: [issue15381] Optimize BytesIO to so less reallocations when written, 
	similarly to StringIO
In-Reply-To: <1342865621.3492.1.camel@localhost.localdomain>
Message-ID: <201207211854.14377.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> It's under 64-bit Linux, Intel Core i5 CPU. Are you sure you're testing
> in non-debug mode?

I use 32-bit Linux.

> That said, the numbers under Windows suggest me that Eli's original idea
> (append and then join at the end) would be more robust.

I agree, it would be more robust, but much more complex solution. I will try to implement this approach too. Victor Stinner in their experiments with formatting preferred 
overallocation approach (_PyUnicodeWriter), therefore, the solution probably will be a hybrid.

However, even in itself the patch deserves attention. It not only significant speeds up writing under Linux, but also speeds up the initialization, which leads to faster reading.

./python -m timeit -s "import io; d=(b'a'*99+b'\n')*10000"  "s=io.BytesIO(d); r=s.readline"  "while r(): pass"

Unpatched:  100 loops, best of 3: 5.92 msec per loop
Patched:  100 loops, best of 3: 3.95 msec per loop

I will try to preserve this advantage.

> By the way, here is Matt Mackall's take on realloc():

Note, that list also uses realloc() inside and therefore you get the same behavior with other constant factor. Actually, appending to a list less than sizeof(void*) bytes at a 
time you will run into this sooner. Perhaps this is the cause that append/join approach under Windows slower than under Linux.

Thank you for measurements, this shows the scale of the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Sat Jul 21 18:25:45 2012
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 21 Jul 2012 16:25:45 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1342887945.14.0.78663956245.issue14578@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Sorry, I've been too busy to get caught up with this. I'm away most of today but I can try to take a look tonight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Sat Jul 21 18:27:26 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 16:27:26 +0000
Subject: [issue15413] os.times() disappeared under Windows
Message-ID: <1342888046.96.0.718260213751.issue15413@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is from issue #15118.

Python 3.3.0b1 (v3.3.0b1:e15c554cd43e+, Jun 26 2012, 20:41:17) [MSC v.1600 64 bi
t (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.times()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'times'

----------
assignee: larry
components: Library (Lib)
messages: 166045
nosy: georg.brandl, larry, pitrou
priority: release blocker
severity: normal
stage: needs patch
status: open
title: os.times() disappeared under Windows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15413>
_______________________________________

From report at bugs.python.org  Sat Jul 21 18:37:10 2012
From: report at bugs.python.org (koobs)
Date: Sat, 21 Jul 2012 16:37:10 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1342888630.95.0.823170957635.issue8893@psf.upfronthosting.co.za>


koobs <koobs.freebsd at gmail.com> added the comment:

uname -rs: FreeBSD 9.0-RELEASE-p3 (AMD64)
python -V: Python 2.7.3

`python readline.py:
read     :  ['oink', 'oink']
readlines:  ['oink\n', 'oink\n']
readline :

Without the patch:

read     :  []
readlines:  []
readline :

Is there a test for this we could add? FreeBSD buildbots currently passing all tests

----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8893>
_______________________________________

From report at bugs.python.org  Sat Jul 21 18:38:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Jul 2012 16:38:16 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <3WfZQb1dgWzPPk@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 295b715b6875 by Ned Deily in branch 'default':
Issue #15184: Ensure configuration-related environment variables
http://hg.python.org/cpython/rev/295b715b6875

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sat Jul 21 19:05:42 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 21 Jul 2012 17:05:42 +0000
Subject: [issue7214] TreeBuilder.end(tag) differs between cElementTree and
	ElementTree
In-Reply-To: <1256599950.66.0.903450683949.issue7214@psf.upfronthosting.co.za>
Message-ID: <1342890342.95.0.0127049363016.issue7214@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Even if this is a problem at all, it's certainly not something that must be fixed by 3.3

----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7214>
_______________________________________

From report at bugs.python.org  Sat Jul 21 19:52:02 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Jul 2012 17:52:02 +0000
Subject: [issue15188] test_ldshared_value failure on OS X using python.org
	Pythons
In-Reply-To: <1340693547.43.0.234356884387.issue15188@psf.upfronthosting.co.za>
Message-ID: <3Wfc3j1srkzPVP@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cd883160ad97 by Ned Deily in branch 'default':
Issue #15188: Modify the OS X build_installer script to remove temporary
http://hg.python.org/cpython/rev/cd883160ad97

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15188>
_______________________________________

From report at bugs.python.org  Sat Jul 21 19:57:40 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 Jul 2012 17:57:40 +0000
Subject: [issue15188] test_ldshared_value failure on OS X using python.org
	Pythons
In-Reply-To: <1340693547.43.0.234356884387.issue15188@psf.upfronthosting.co.za>
Message-ID: <1342893460.3.0.189745323303.issue15188@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Pending the final resolution of Issue15298, this changes ensures that the temporary build paths do not leak into the installed interpreter.  At the moment, the test is still failing because the CFLAGS values returned by the two sysconfigs differ in whitespace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15188>
_______________________________________

From report at bugs.python.org  Sat Jul 21 20:10:50 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 Jul 2012 18:10:50 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342894250.37.0.264952708995.issue15184@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I believe I've fixed the buildbot failure but the buildbot is not very stable and test runs aren't always completing.  I'll check back on it later.

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sat Jul 21 20:38:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Jul 2012 18:38:35 +0000
Subject: [issue15342] os.path.join behavior
In-Reply-To: <1342143930.94.0.174584687761.issue15342@psf.upfronthosting.co.za>
Message-ID: <3Wfd5Q1r1CzPQH@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 61d0e3526a51 by R David Murray in branch '3.2':
#15342: Add clarifying sentence to posixpath.join docstring.
http://hg.python.org/cpython/rev/61d0e3526a51

New changeset 30d4d1528b58 by R David Murray in branch 'default':
Merge #15342: Add clarifying sentence to posixpath.join docstring.
http://hg.python.org/cpython/rev/30d4d1528b58

New changeset f3cc7626a621 by R David Murray in branch '2.7':
#15342: Add clarifying sentence to posixpath.join docstring.
http://hg.python.org/cpython/rev/f3cc7626a621

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15342>
_______________________________________

From report at bugs.python.org  Sat Jul 21 20:39:57 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Jul 2012 18:39:57 +0000
Subject: [issue15342] os.path.join behavior
In-Reply-To: <1342143930.94.0.174584687761.issue15342@psf.upfronthosting.co.za>
Message-ID: <1342895997.4.0.168370004878.issue15342@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've added the sentence to the docstring, as you suggested.  Thanks for the suggestion.

----------
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15342>
_______________________________________

From report at bugs.python.org  Sat Jul 21 21:18:39 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 19:18:39 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>
Message-ID: <1342898319.58.0.540813219026.issue13922@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

This patch looks like the right fix to me. The tests look good too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13922>
_______________________________________

From report at bugs.python.org  Sat Jul 21 21:52:39 2012
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sat, 21 Jul 2012 19:52:39 +0000
Subject: [issue10091] ast.literal_eval does not handled new set literals
In-Reply-To: <1286998602.58.0.486068120725.issue10091@psf.upfronthosting.co.za>
Message-ID: <1342900359.35.0.678764299624.issue10091@psf.upfronthosting.co.za>


Piotr Dobrogost <pd at bugs.python.dobrogost.net> added the comment:

I totally agree with Eric's statement that "Set literals, a new feature indeed, have been backported to 2.7 and 3.1.  The lack of support in ast.literal_eval is arguably a bug."
I came here from "set literal syntax support in Python 2.7" question at Stackoverflow (http://stackoverflow.com/q/6078262/95735)

----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10091>
_______________________________________

From report at bugs.python.org  Sat Jul 21 21:53:50 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 21 Jul 2012 19:53:50 +0000
Subject: [issue15295] Document PEP 420 namespace packages
In-Reply-To: <1342880618.61.0.956745491576.issue15295@psf.upfronthosting.co.za>
Message-ID: <20120721155347.4c2951c1@limelight.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jul 21, 2012, at 02:23 PM, Georg Brandl wrote:

>Ping. Barry? (It's not strictly necessary to have the docs for b2, but could
>you give me a rough estimate when you'll do this?)

Unfortunately, I lost a bunch of work with a disk crash, but I might have
salvaged enough in the `importdocs` branch of the features/pep-420 clone.
I'll see what I can come up with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sat Jul 21 21:58:13 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Jul 2012 19:58:13 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1342900693.02.0.691807293444.issue10652@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would like to see my patch (cut and paste from message above) or something like it in the next beta. It fixes the problem (since forever?) of tcl/tk/ttk tests not running properly (at least on windows) as part of the test suite. (I presume the buildbots have extra skips in order to be green.) I am reluctant to apply myself without review simply because I am ignorant enough to miss something that others might see wrong.

----------
nosy: +georg.brandl
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Sat Jul 21 22:00:41 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Jul 2012 20:00:41 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1342900841.82.0.00716329255595.issue10652@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It would be much better to have an actual patch to review.  Then, we need someone who can test it on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Sat Jul 21 22:02:49 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 20:02:49 +0000
Subject: [issue14365] argparse: subparsers,
	argument abbreviations and ambiguous option
In-Reply-To: <1332102480.28.0.401837291603.issue14365@psf.upfronthosting.co.za>
Message-ID: <1342900969.88.0.0657404819759.issue14365@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I think the real fix needs to search recursively though all subparsers. Here's a first draft of a patch that does this. I believe your sample code works after this patch.

I don't have the time to turn your bug report into proper test (and add a test for the recursive bit), but hopefully this is enough to let someone else finish up fixing this bug.

And yes, your "dirty hack" was still helpful in putting this together. ;-)

----------
keywords: +patch
Added file: http://bugs.python.org/file26466/subparser_optionals.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14365>
_______________________________________

From report at bugs.python.org  Sat Jul 21 22:09:07 2012
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sat, 21 Jul 2012 20:09:07 +0000
Subject: [issue14489] repr() function link on the built-in function
	documentation is incorrect
In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>
Message-ID: <1342901347.16.0.170584163884.issue14489@psf.upfronthosting.co.za>


Piotr Dobrogost <pd at bugs.python.dobrogost.net> added the comment:

As of today the link is still not fixed although I guess it should have been due to the patch mentioned in http://bugs.python.org/issue14489#msg157543

----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14489>
_______________________________________

From report at bugs.python.org  Sat Jul 21 22:13:23 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 20:13:23 +0000
Subject: [issue14391] misc TYPO in argparse.Action docstring
In-Reply-To: <1332483933.58.0.148840583117.issue14391@psf.upfronthosting.co.za>
Message-ID: <1342901603.06.0.70901290226.issue14391@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The patch supplied was in reverse, but the bug report was correct. You can't pass "type=string" since there's no string callable, only a str callable.

The docstring is confusing because the quotes make it looks like we mean the string 'str', when we actually mean the callable 'str'. Maybe they should be `str` or ``str``? Not sure what the syntax for code, not string literals, is for docstrings.

Anyway, this should be an easy fix for a doc person.

----------
keywords: +easy
resolution: out of date -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14391>
_______________________________________

From report at bugs.python.org  Sat Jul 21 22:19:35 2012
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sat, 21 Jul 2012 20:19:35 +0000
Subject: [issue10854] Output .pyd name in error message of ImportError when
	DLL load fails
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1342901975.69.0.0038444806355.issue10854@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Sat Jul 21 22:19:40 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 20:19:40 +0000
Subject: [issue14392] type=bool doesn't raise error in argparse.Action
In-Reply-To: <1332486208.67.0.940302931961.issue14392@psf.upfronthosting.co.za>
Message-ID: <1342901980.49.0.747963561582.issue14392@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I can't find anywhere in the documentation where type=bool, type=unicode or type=long are disallowed. They shouldn't be disallowed. If you want to pass type=bool, argparse should not stop you. And it currently doesn't:

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', type=bool)
>>> parser.parse_args([''])
Namespace(foo=False)
>>> parser.parse_args(['x'])
Namespace(foo=True)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14392>
_______________________________________

From report at bugs.python.org  Sat Jul 21 22:28:20 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 20:28:20 +0000
Subject: [issue14449] argparse optional arguments should follow getopt_long(3)
In-Reply-To: <1333070449.88.0.543060276279.issue14449@psf.upfronthosting.co.za>
Message-ID: <1342902500.5.0.129467638281.issue14449@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I don't think this is going to change.

It's basically a consequence of having a unified handling of nargs='?', nargs='*', nargs='+', etc. These will all consume as many arguments as they can, and argparse doesn't distinguish between arguments that are concatenated to options and arguments that aren't. (And you couldn't concatenate a whole '+' style argument to the option anyway.)

If you really want getopt-style parsing instead, the getopt module is still available. ;-)

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14449>
_______________________________________

From report at bugs.python.org  Sat Jul 21 22:38:59 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 20:38:59 +0000
Subject: [issue14504] Suggestion to improve argparse's help messages for
	"store_const"
In-Reply-To: <1333614852.3.0.346870129538.issue14504@psf.upfronthosting.co.za>
Message-ID: <1342903139.86.0.4627512208.issue14504@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Special casing the formatting of 'store_const' makes me nervous because formatting is already complicated and it doesn't know anything about action types.

But feel free to propose a patch!

In the meantime:

- propagate the default to all the options

You can, of course, do this manually, by specifying default in each of them. And if you use formatter_class=ArgumentDefaultsHelpFormatter, you'll get the defaults in the usage message.

- group the keywords that have the same destination together (?)
- place the default option first (?)

You can achieve both of these by just adding the options in the order that you want them displayed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14504>
_______________________________________

From report at bugs.python.org  Sat Jul 21 22:41:08 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Jul 2012 20:41:08 +0000
Subject: [issue15414] os.path.join behavior on Windows (ntpath.join) is
	unexpected and not well documented
Message-ID: <1342903268.21.0.193498975528.issue15414@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

In looking at another os.path.join documentation issue I tried the Windows join to see if it matched the docs, and found that it was very unclear.   I searched the tracker and found Issue 1669539, which contains much relevant discussion but also much discussion of possible enhancements.  So I'm opening a new issue *just* about what I see as the current bugs in the os.path.join docs and ntpath.join implementation.

I'm not qualified to fix this, not being a Windows user, but it is clear to me that the documentation of os.path.join for Windows is unclear (it does not indicate what is considered an absolute path on Windows) and wrong (\foo will *not* restart the path if it is the second element and follows a drive specification, but it does any other time), and that the current behavior may have a bug if, as seems to be implied by the issue 1669539 discussion, something that looks like a drive specification in the middle of a path is invalid on Windows.  If this last is not a bug, it should be mentioned in the documentation, since the actual behavior is counter-intuitive.

----------
assignee: docs at python
components: Documentation, Windows
keywords: easy
messages: 166065
nosy: brian.curtin, christian.heimes, docs at python, eckhardt, ezio.melotti, jorend, mhammond, r.david.murray, terry.reedy, tim.golden
priority: normal
severity: normal
status: open
title: os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15414>
_______________________________________

From report at bugs.python.org  Sat Jul 21 22:45:50 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Jul 2012 20:45:50 +0000
Subject: [issue1669539] Improve Windows os.path.join (ntpath.join) "smart"
	joining
Message-ID: <1342903550.81.0.62898042394.issue1669539@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've opened a issue 15414 for fixing the documentation for os.path.join on Windows, and possibly existing bugs.  So I'm reclassifying this as a feature request, since that is most of what the discussion is about.

----------
dependencies: +os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented
nosy: +r.david.murray
priority: high -> normal
title: Fix bug in os.path.join -> Improve Windows os.path.join (ntpath.join) "smart" joining
type: behavior -> enhancement
versions: +Python 3.4 -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669539>
_______________________________________

From report at bugs.python.org  Sat Jul 21 22:50:49 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 20:50:49 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1342903849.69.0.571372363042.issue8893@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is there a test for this we could add?

You could certainly add a test to Lib/test/test_file2k.py.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8893>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:01:09 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 21:01:09 +0000
Subject: [issue13824] argparse.FileType opens a file and never closes it
In-Reply-To: <1326975939.94.0.524131708506.issue13824@psf.upfronthosting.co.za>
Message-ID: <1342904469.62.0.227464954844.issue13824@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

So I generally agree that FileType is not what you want for anything but quick scripts that can afford to either leave a file open or to close stdin and/or stdout. However, quick scripts are an important use case for argparse, so I don't think we should get rid of FileType.

What should definitely happen:

* Someone should add some documentation explaining the risks of using FileType (e.g. forgetting to close the file, or closing stdin/stdout when you didn't mean to).

What could potentially happen if someone really wanted it:

* Someone could create a "safe" replacement, e.g. a FileOpenerType that returns an object with open() and close() methods that do the right things (or whatever API makes sense).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13824>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:07:04 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Jul 2012 21:07:04 +0000
Subject: [issue14391] misc TYPO in argparse.Action docstring
In-Reply-To: <1332483933.58.0.148840583117.issue14391@psf.upfronthosting.co.za>
Message-ID: <3WfhNl2fwpzPQm@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e7f205ce080e by R David Murray in branch '3.2':
#14391: clarify docstring discussion of Action's 'type' argument's value.
http://hg.python.org/cpython/rev/e7f205ce080e

New changeset 3d1ea33611c1 by R David Murray in branch 'default':
Merge #14391: clarify docstring discussion of Action's 'type' argument's value.
http://hg.python.org/cpython/rev/3d1ea33611c1

New changeset 905d9bdae970 by R David Murray in branch '2.7':
#14391: clarify docstring discussion of Action's 'type' argument's value.
http://hg.python.org/cpython/rev/905d9bdae970

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14391>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:08:41 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Jul 2012 21:08:41 +0000
Subject: [issue14391] misc TYPO in argparse.Action docstring
In-Reply-To: <1332483933.58.0.148840583117.issue14391@psf.upfronthosting.co.za>
Message-ID: <1342904921.75.0.192247468758.issue14391@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I reworded it so that it is clear we are talking about types and not strings.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: enhancement -> behavior
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14391>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:13:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 21 Jul 2012 21:13:18 +0000
Subject: [issue15415] Add temp_dir() and change_cwd() to test.support
Message-ID: <1342905198.6.0.0438176504742.issue15415@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is partly in service to issue 15376, which is to refactor test_runpy's walk_package support code into a common location.

Currently, the temp_cwd() context manager in test.support does two things: it creates a temp directory, and it changes the current working directory.

It would be useful and clearer if test.support exposed these two things as separate context managers.  This will both let us simplify the implementation of temp_cwd() and give us an opportunity to increase code reuse between test.support and test.script_helper.  (Currently, test.script_helper has its own version of temp_dir(), whose functionality overlaps with temp_cwd().)

I will upload a patch shortly with tests.

----------
components: Tests
keywords: easy
messages: 166071
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Add temp_dir() and change_cwd() to test.support
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15415>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:17:28 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Jul 2012 21:17:28 +0000
Subject: [issue15392] Create a unittest framework for IDLE
In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za>
Message-ID: <1342905448.03.0.317602346712.issue15392@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The screen flickers a bunch, so something involving my display is certainly happening.

As for runtktests...test suites that live in the package as opposed to the test directory require support files to gather the tests to be run.  This can be done by the test_xxxx.py file in the test directory (which is what regrtest runs), or it can be done in a function imported from the packages test directory.  For tkinter it looks like the test gathering is done in runtktests.  Most Python test_xxxx file can be run directly to run the relevant tests, and runtktests works the same way.  So yes it is a runner, but that appears to be a convenience just like for other test_xxxx files, and not anything special.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15392>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:21:01 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Jul 2012 21:21:01 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1342905661.91.0.286121759553.issue10652@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I wonder if it would be sensible to have test___all__ restore the state of sys.modules after it runs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:30:04 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 21:30:04 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1342905661.91.0.286121759553.issue10652@psf.upfronthosting.co.za>
Message-ID: <1342906090.19457.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I wonder if it would be sensible to have test___all__ restore the
> state of sys.modules after it runs.

Probably not. I don't think we want to debug the consequences of having
duplicate modules lying around by way of old references registered here
and there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:33:13 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Jul 2012 21:33:13 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1342906393.33.0.541314858379.issue10652@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yeah, we probably do not want to go there, even though technically I think those would be bugs.  But bugs that it would only be "nice" to fix, not necessary to fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:34:25 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 21:34:25 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1342906465.22.0.968501344893.issue12776@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The patch looks good to me. I've updated it for trunk and to include Mike Meyer's additional test. All argparse tests pass.

Anyone who's able to commit and backport, please do.

(I should be able to commit myself, but it's now been too long and my SSH key seems to no longer work. I'll eventually get this sorted out, but as you may have noticed, I don't have much time for argparse these days, so best not to wait on me.)

----------
Added file: http://bugs.python.org/file26467/py3k-argparse-call-type-function-once-v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:39:10 2012
From: report at bugs.python.org (Ben Wolfson)
Date: Sat, 21 Jul 2012 21:39:10 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1342906750.13.0.839716704633.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

Ping!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:41:20 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 21:41:20 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <1342906880.62.0.643488301656.issue12353@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yes, the original patch looks fine to me. I applied and tested it, and it works as expected.

Please go ahead and apply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12353>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:51:54 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 21:51:54 +0000
Subject: [issue13966] Add disable_interspersed_args() to
	argparse.ArgumentParser
In-Reply-To: <1328687368.18.0.265955669963.issue13966@psf.upfronthosting.co.za>
Message-ID: <1342907514.78.0.557381030901.issue13966@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The argparse changes and tests look good. The new method needs to be documented. You can see some other things (e.g. Misc/NEWS) that also need to be updated by running "make patchcheck" as described here:

http://docs.python.org/devguide/patch.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13966>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:53:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 21 Jul 2012 21:53:29 +0000
Subject: [issue15415] Add temp_dir() and change_cwd() to test.support
In-Reply-To: <1342905198.6.0.0438176504742.issue15415@psf.upfronthosting.co.za>
Message-ID: <1342907609.91.0.717872104527.issue15415@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching a patch with tests.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file26468/issue-15415-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15415>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:54:35 2012
From: report at bugs.python.org (Martin Mokrejs)
Date: Sat, 21 Jul 2012 21:54:35 +0000
Subject: [issue15416] 3 * [] gives a list of 3 cross-referenced lists,
	a[1]='blash
Message-ID: <1342907675.08.0.583810202929.issue15416@psf.upfronthosting.co.za>


New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:

Hi,
  I thought that I can easily create a list of, say 3, nested lists:

$ python
Python 2.7.3 (default, May 17 2012, 21:10:41) 
[GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 3 * [[]]
[[], [], []]
>>> a=3 * [[]]
>>> a[0]
[]
>>> a[1].append('sdds')
>>> a
[['sdds'], ['sdds'], ['sdds']]
>>> a[0].append('xxx')
>>> a
[['sdds', 'xxx'], ['sdds', 'xxx'], ['sdds', 'xxx']]


The below works as expected.

>>> a=[[], [], []]
>>> a
[[], [], []]
>>> a[0]
[]
>>> a[1]
[]
>>> a[1].append('sdds')
>>> a[0].append('xxx')
>>> a
[['xxx'], ['sdds'], []]
>>>


Of course, I want to do like:

a = len(b) * [] # to get a list of individual hashes
c = len(b) * [0] # to get a list of indvidual counters

----------
components: None
messages: 166081
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: 3 * [] gives a list of 3 cross-referenced lists, a[1]='blash
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15416>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:54:58 2012
From: report at bugs.python.org (Martin Mokrejs)
Date: Sat, 21 Jul 2012 21:54:58 +0000
Subject: [issue15416] 3 * [] gives a list of 3 cross-referenced lists,
	a[1]='blah' writes in to ALL three!
In-Reply-To: <1342907675.08.0.583810202929.issue15416@psf.upfronthosting.co.za>
Message-ID: <1342907698.76.0.684007557949.issue15416@psf.upfronthosting.co.za>


Changes by Martin Mokrejs <mmokrejs at users.sourceforge.net>:


----------
title: 3 * [] gives a list of 3 cross-referenced lists, a[1]='blash -> 3 * [] gives a list of 3 cross-referenced lists, a[1]='blah' writes in to ALL three!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15416>
_______________________________________

From report at bugs.python.org  Sat Jul 21 23:59:41 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 21:59:41 +0000
Subject: [issue11807] Documentation of add_subparsers lacks information about
	parametres
In-Reply-To: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>
Message-ID: <1342907981.36.0.69313135077.issue11807@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks good. There was one typo in "parametres" that I've fixed. Should be ready to apply.

----------
Added file: http://bugs.python.org/file26469/11807_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11807>
_______________________________________

From report at bugs.python.org  Sun Jul 22 00:05:13 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 21 Jul 2012 22:05:13 +0000
Subject: [issue15415] Add temp_dir() and change_cwd() to test.support
In-Reply-To: <1342905198.6.0.0438176504742.issue15415@psf.upfronthosting.co.za>
Message-ID: <1342908313.28.0.103723812692.issue15415@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Fixing patch so it will apply cleanly.

----------
Added file: http://bugs.python.org/file26470/issue-15415-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15415>
_______________________________________

From report at bugs.python.org  Sun Jul 22 00:06:01 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 22:06:01 +0000
Subject: [issue13818] argparse: -h listening required options under optional
	arguments
In-Reply-To: <1326914635.35.0.671947933448.issue13818@psf.upfronthosting.co.za>
Message-ID: <1342908361.43.0.295670621494.issue13818@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> argparse: Default Help Message Lists Required Args As Optional

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13818>
_______________________________________

From report at bugs.python.org  Sun Jul 22 00:09:29 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 21 Jul 2012 22:09:29 +0000
Subject: [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1342908569.81.0.0960236701232.issue15269@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Given that we have self.left_list and self.left_only ( and self.right_list and self.right_only), I am not sure how adding self.left/self.right is going to add more meaning? It would simply point to the dir1 and dir2 arguments that are being passed. 

Also, it may not be a helpful feature. If it is a must, then we can just rename self.left to self._left within the *code*, but otherwise, I do not see any change which is required here.  I suggest closing this report as wont-fix.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15269>
_______________________________________

From report at bugs.python.org  Sun Jul 22 00:12:48 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 21 Jul 2012 22:12:48 +0000
Subject: [issue15416] 3 * [] gives a list of 3 cross-referenced lists,
	a[1]='blah' writes in to ALL three!
In-Reply-To: <1342907675.08.0.583810202929.issue15416@psf.upfronthosting.co.za>
Message-ID: <1342908768.64.0.566517004372.issue15416@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The * operator does not create copies, it duplicates references to existing objects.
Please read: http://docs.python.org/faq/programming.html#how-do-i-create-a-multidimensional-list

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15416>
_______________________________________

From report at bugs.python.org  Sun Jul 22 00:19:22 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 22:19:22 +0000
Subject: [issue9625] argparse: Problem with defaults for variable nargs when
	using choices
In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za>
Message-ID: <1342909162.7.0.719267253781.issue9625@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I agree that this looks like a bug. I think the fix is something like the attached patch, but it needs some tests to make sure that it fixes your problem.

----------
keywords: +patch
Added file: http://bugs.python.org/file26471/issue9625.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9625>
_______________________________________

From report at bugs.python.org  Sun Jul 22 00:29:29 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 22:29:29 +0000
Subject: [issue14856] argparse: creating an already defined subparsers does
	not raises an exception
In-Reply-To: <1337430471.4.0.633032333136.issue14856@psf.upfronthosting.co.za>
Message-ID: <1342909769.21.0.690189438618.issue14856@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yeah, overwriting the existing parser is probably not typically what the user intended.

However, I could see someone doing this if, say, they had a parser designed by another module writer, and they wanted to use it but just change one of the sub-parsers or something like that. But a "set_parser" method would probably make more sense for this use case than "add_parser".

I guess my recommendation is to add a "set_parser" method that replaces the old parser (like "add_parser" does now), and then issue deprecation warnings in "add_parser" if a parser with the given name is present (like the patch does, but with deprecation warnings instead of exceptions).

We could then turn the warnings into errors in a few releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14856>
_______________________________________

From report at bugs.python.org  Sun Jul 22 01:11:37 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 21 Jul 2012 23:11:37 +0000
Subject: [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1342912297.29.0.610297250273.issue15269@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

> Given that we have self.left_list and self.left_only ( and self.right_list and self.right_only), I am not sure how adding self.left/self.right is going to add more meaning?

It adds more meaning because you can't construct self.left and self.right from self.left_list, self.left_only, etc.  The latter are children inside the two directories (expressed relatively), while the former are the parent directories.  So it's strictly different information.

As I said, there are cases where being able to access the left and right directories simplifies the calling code in a way that is not otherwise possible.

For example, if you are recursively comparing directories, it is natural to recurse on the dircmp.subdirs attribute, whose values are dircmp instances.  The caller did not construct these instances, so there is no other way to obtain the left and right directories that were used to construct those instances.  Otherwise, the caller has to construct the dircmp instances manually from common_dirs, which reduces the usefulness of the subdirs attribute and the scenarios in which it can be used.

Secondly, there are cases where it is natural to pass dircmp instances around between functions.  If one cannot recover the left and right directories from the dircmp instances, then one would also have to pass the left and right directories to those functions, along with the dircmp instances, or else pass just the left and right directories and then reconstruct the dircmp instances from those arguments, which leads to uglier code.

Thirdly, it is better to reuse existing dircmp instances where possible rather than create new ones, because of the penalty after creating a new instance of needing to recalculate the attributes.  As the documentation notes, attributes are computed lazily and cached using __getattr__(), so it's better to hold onto existing instances.

If you are still not convinced, I would like the opportunity to provide actual code examples before you close this issue.  Then you can tell me if there is an equally simple alternative that does not involve accessing left and right.

I don't see how it hurts to be able to access left and right as attributes and why you would consider concealing this information from the caller behind private attributes.  It's a common idiom for constructor arguments to be stored as public attributes.

In this case, I think it's worth documenting because the names of the attributes ("left" and "right") used to store the constructor arguments don't match the names of the constructor arguments themselves ("a" and "b").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15269>
_______________________________________

From report at bugs.python.org  Sun Jul 22 01:20:49 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 21 Jul 2012 23:20:49 +0000
Subject: [issue15415] Add temp_dir() and change_cwd() to test.support
In-Reply-To: <1342905198.6.0.0438176504742.issue15415@psf.upfronthosting.co.za>
Message-ID: <1342912849.26.0.554970391269.issue15415@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Trying again to have the patch apply cleanly (for the review link).

----------
Added file: http://bugs.python.org/file26472/issue-15415-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15415>
_______________________________________

From report at bugs.python.org  Sun Jul 22 01:41:39 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 21 Jul 2012 23:41:39 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1342914099.23.0.908269871636.issue15250@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for this report. I saw that filecmp.rst could be improved a bit further too. I added some additional improvements to the docs in addition to the one you mentioned in the patch.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
Added file: http://bugs.python.org/file26473/Issue15250.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15250>
_______________________________________

From report at bugs.python.org  Sun Jul 22 02:04:38 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 00:04:38 +0000
Subject: [issue15417] Add support for csh and fish in venv activation scripts
Message-ID: <1342915478.17.0.0181949280241.issue15417@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: Library (Lib)
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Add support for csh and fish in venv activation scripts
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15417>
_______________________________________

From report at bugs.python.org  Sun Jul 22 02:06:29 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 00:06:29 +0000
Subject: [issue15417] Add support for csh and fish in venv activation scripts
Message-ID: <1342915589.34.0.636198771973.issue15417@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

I have added required shell files

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file26474/issue15417.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15417>
_______________________________________

From report at bugs.python.org  Sun Jul 22 02:09:27 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 00:09:27 +0000
Subject: [issue15417] Add support for csh and fish in venv activation scripts
In-Reply-To: <1342915589.34.0.636198771973.issue15417@psf.upfronthosting.co.za>
Message-ID: <1342915767.79.0.202838009096.issue15417@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

No idea if Doc/using/venv-create.inc should be updated to reflect support of new shells. 

virtualenv does nothing in own documentation btw.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15417>
_______________________________________

From report at bugs.python.org  Sun Jul 22 02:10:21 2012
From: report at bugs.python.org (Toshihiro Kamishima)
Date: Sun, 22 Jul 2012 00:10:21 +0000
Subject: [issue14392] type=bool doesn't raise error in argparse.Action
In-Reply-To: <1332486208.67.0.940302931961.issue14392@psf.upfronthosting.co.za>
Message-ID: <1342915821.67.0.211821540567.issue14392@psf.upfronthosting.co.za>


Toshihiro Kamishima <mail at kamishima.net> added the comment:

>     - type -- The type which the command-line arguments should be converted
>         to, should be one of 'string', 'int', 'float', 'complex' or a
>         callable object that accepts a single string argument. If None,
>         'string' is assumed.

I misunderstood this sentence in the docstring of arcparse.Action because `bool` or `unicode` is not appeared in this list, which are callables.

So, I close this issue.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14392>
_______________________________________

From report at bugs.python.org  Sun Jul 22 02:13:54 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 22 Jul 2012 00:13:54 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1342916033.24.0.772134315457.issue15250@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

For attribution purposes and to keep the issue focused, shouldn't those other changes be added as part of a separate issue?

The changes you added are much larger than mine, and address cosmetic issues and other issues unrelated to the original point about dircmp comparisons being "shallow".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15250>
_______________________________________

From report at bugs.python.org  Sun Jul 22 02:14:22 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 00:14:22 +0000
Subject: [issue15417] Add support for csh and fish in venv activation scripts
In-Reply-To: <1342915589.34.0.636198771973.issue15417@psf.upfronthosting.co.za>
Message-ID: <1342916062.35.0.588428040577.issue15417@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +carljm, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15417>
_______________________________________

From report at bugs.python.org  Sun Jul 22 03:23:48 2012
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 22 Jul 2012 01:23:48 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1342920228.6.0.749629066196.issue14578@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Can someone tell me where you want this changed? I guess Lib/imp.py in the find_module function, based on previous mention of imp.find_module? That's shown as deprecated so I'm hesitant to start there.

I don't really know anything about importlib, especially not enough to know where to start. If I have a pointer to the right spot I'll make the registry searching a part of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Sun Jul 22 04:30:15 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 22 Jul 2012 02:30:15 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
In-Reply-To: <1342916033.24.0.772134315457.issue15250@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOT1WhoKWg67_zk4p4UwA8oB8S8KxdBDX+ktL8_a1Q3fmg@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

If by attribution, if you mean, proper mention of credits/ acks, during the
commit, I shall add it. Also, I agree that "shallow" should be documented.
But there were few more places which were lacking, so I ended up with
expanding docs after reading the code. I can commit in two phases, if it is
desired or commit yours and then make the other  documentation
improvements. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15250>
_______________________________________

From report at bugs.python.org  Sun Jul 22 04:35:29 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Jul 2012 02:35:29 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <3Wfqgh1LFFzPW3@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ac53876d1cc8 by R David Murray in branch '3.2':
#12353: argparse now correctly handles null argument values.
http://hg.python.org/cpython/rev/ac53876d1cc8

New changeset c4ad8a6eb0df by R David Murray in branch 'default':
Merge #12353: argparse now correctly handles null argument values.
http://hg.python.org/cpython/rev/c4ad8a6eb0df

New changeset c9806f0aaefb by R David Murray in branch '2.7':
#12353: argparse now correctly handles null argument values.
http://hg.python.org/cpython/rev/c9806f0aaefb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12353>
_______________________________________

From report at bugs.python.org  Sun Jul 22 04:36:40 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Jul 2012 02:36:40 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <1342924600.3.0.268395165145.issue12353@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Done.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12353>
_______________________________________

From report at bugs.python.org  Sun Jul 22 04:46:35 2012
From: report at bugs.python.org (H Xu)
Date: Sun, 22 Jul 2012 02:46:35 +0000
Subject: [issue14489] repr() function link on the built-in function
	documentation is incorrect
In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>
Message-ID: <1342925195.71.0.709085516608.issue14489@psf.upfronthosting.co.za>


H Xu <xuhdev at gmail.com> added the comment:

I think this has been fixed. Where did you see the incorrect link?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14489>
_______________________________________

From report at bugs.python.org  Sun Jul 22 04:58:03 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Jul 2012 02:58:03 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>
Message-ID: <3Wfr9k2r90zPX2@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 18b114be013e by R David Murray in branch '3.2':
#13922: argparse no longer incorrectly strips '--' after the first one.
http://hg.python.org/cpython/rev/18b114be013e

New changeset bd2c167dfabc by R David Murray in branch '2.7':
#13922: argparse no longer incorrectly strips '--' after the first one.
http://hg.python.org/cpython/rev/bd2c167dfabc

New changeset a636f365d815 by R David Murray in branch 'default':
Merge #13922: argparse no longer incorrectly strips '--' after the first one.
http://hg.python.org/cpython/rev/a636f365d815

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13922>
_______________________________________

From report at bugs.python.org  Sun Jul 22 05:00:34 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Jul 2012 03:00:34 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>
Message-ID: <1342926034.44.0.775405383542.issue13922@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed.  Thanks, Jeff.  By the way, although this patch isn't big enough to require it, it would be great if you would submit a contributor agreement: http://www.python.org/psf/contrib.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13922>
_______________________________________

From report at bugs.python.org  Sun Jul 22 05:05:57 2012
From: report at bugs.python.org (Russell Sim)
Date: Sun, 22 Jul 2012 03:05:57 +0000
Subject: [issue13720] argparse print_help() fails if COLUMNS is set to a low
	value
In-Reply-To: <1325858148.7.0.947093232457.issue13720@psf.upfronthosting.co.za>
Message-ID: <1342926357.95.0.339942835565.issue13720@psf.upfronthosting.co.za>


Russell Sim <russell.sim at gmail.com> added the comment:

Hi,

I am having the same problem while running ipython in a batch mode emacs.  Apparently you can't even start ipython if the columns are less than 27, since they use the argparse library for the magic method help printing and they preformat the strings at import time. So importing the library fails. :(

I have a simple patch that fixes it but from what i can tell if you set the columns to 10 or 1000 there is no effect on the output, so i wonder if it even pays any attention to the width during rendering.

If you think it's of value I am happy to write tests. Or if someone has a better implementation idea I'll be happy to implement it, but if you are on a terminal that is getting <27 characters then you can't really expect the formmating of the messages to be that readable.

--- cpython/Lib/argparse.py	2012-07-22 12:10:42.751869655 +1000
+++ /tmp/ediff3953qkY	2012-07-22 12:54:51.380700044 +1000
@@ -95,6 +95,7 @@
 def _callable(obj):
     return hasattr(obj, '__call__') or hasattr(obj, '__bases__')
 
+MIN_WIDTH = 10
 
 SUPPRESS = '==SUPPRESS=='
 
@@ -486,7 +487,10 @@
         # determine the required width and the entry label
         help_position = min(self._action_max_length + 2,
                             self._max_help_position)
-        help_width = self._width - help_position
+        if self._width - help_position > MIN_WIDTH:
+            help_width = self._width - help_position
+        else:
+            help_width = MIN_WIDTH
         action_width = help_position - self._current_indent - 2
         action_header = self._format_action_invocation(action)

----------
nosy: +Russell.Sim
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13720>
_______________________________________

From report at bugs.python.org  Sun Jul 22 06:30:31 2012
From: report at bugs.python.org (Warren Turkal)
Date: Sun, 22 Jul 2012 04:30:31 +0000
Subject: [issue13922] argparse handling multiple "--" in args improperly
In-Reply-To: <1342926034.44.0.775405383542.issue13922@psf.upfronthosting.co.za>
Message-ID: <CAB_jBhg2KiMev-Jsx6M9X3Eio_tpE_Tza06KKAzXq8tWp5iSOQ@mail.gmail.com>


Warren Turkal <wt at penguintechs.org> added the comment:

Thanks for fixing this issue. You guys are great!

wt

On Sat, Jul 21, 2012 at 8:00 PM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Committed.  Thanks, Jeff.  By the way, although this patch isn't big
> enough to require it, it would be great if you would submit a contributor
> agreement: http://www.python.org/psf/contrib.
>
> ----------
> resolution:  -> fixed
> stage:  -> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13922>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13922>
_______________________________________

From report at bugs.python.org  Sun Jul 22 07:36:21 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Jul 2012 05:36:21 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <3WfvhN1wRKzPWK@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 31349bc40214 by Ned Deily in branch 'default':
Issue #15184: Fix test__remove_unsupported_archs failures on 10.6
http://hg.python.org/cpython/rev/31349bc40214

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sun Jul 22 09:47:20 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Jul 2012 07:47:20 +0000
Subject: [issue15188] test_ldshared_value failure on OS X using python.org
	Pythons
In-Reply-To: <1340693547.43.0.234356884387.issue15188@psf.upfronthosting.co.za>
Message-ID: <3WfybW1JBzzPWc@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f4470babf79b by Ned Deily in branch 'default':
Issue #15188: Prevent test_ldshared_value failure due to slightly
http://hg.python.org/cpython/rev/f4470babf79b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15188>
_______________________________________

From report at bugs.python.org  Sun Jul 22 09:53:01 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Jul 2012 07:53:01 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1342943581.95.0.508294954586.issue10652@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I tested this on Windows in my installed 3.3.0b1. Copying the inserted lines to my repository copy (where I cannot test it) gives the attached patch. On 3.2.3, the insertion line would be 1056 instead of 1158.

----------
Added file: http://bugs.python.org/file26475/Issue10652.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Sun Jul 22 09:58:45 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Jul 2012 07:58:45 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1342943925.85.0.322129738163.issue10652@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Hirokazu's original patch was to restore sys.modules after *every* test, not just sys.modules. That *did* cause problems because (at minimum) of references in importlib. Restoring only after __all__ would only let test_tcl run but not test_tk. And that is assuming alphabetic, not randomized order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Sun Jul 22 10:08:02 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 08:08:02 +0000
Subject: [issue14900] cProfile does not take its result headers as sort
	arguments
In-Reply-To: <1337869163.57.0.920578910684.issue14900@psf.upfronthosting.co.za>
Message-ID: <1342944482.96.0.240702370747.issue14900@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14900>
_______________________________________

From report at bugs.python.org  Sun Jul 22 10:14:27 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 08:14:27 +0000
Subject: [issue15418] 2to3 docs should mention setup.py fixes required to
	install compatible packages in Python 3
Message-ID: <1342944867.41.0.426616116312.issue15418@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/py3k/library/2to3.html

   should mention the practice of running 2to3 in setup.py for codebase compatible with both Python 2 and Python 3.

----------
assignee: docs at python
components: Documentation
messages: 166108
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: 2to3 docs should mention setup.py fixes required to install compatible packages in Python 3
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15418>
_______________________________________

From report at bugs.python.org  Sun Jul 22 10:32:56 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 08:32:56 +0000
Subject: [issue15419] distutils: build_py_2to3 should use a separate build
	directory
Message-ID: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

This scenario fails:
  python setup.py install
  python3 setup.py install

Because it seems like code once built for Python 2 is not rebuild when installing for Python 3.

----------
assignee: eric.araujo
components: Distutils, Distutils2
messages: 166109
nosy: alexis, eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: distutils: build_py_2to3 should use a separate build directory
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15419>
_______________________________________

From report at bugs.python.org  Sun Jul 22 10:47:25 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 08:47:25 +0000
Subject: [issue6964] import new fails
In-Reply-To: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za>
Message-ID: <1342946845.18.0.3081572312.issue6964@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Damn it. I've run 2to3 during setup.py phase and went smoothly, but when I run examples the package fails.

It should at least warn about this "import new". It should not be that hard to catch.

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6964>
_______________________________________

From report at bugs.python.org  Sun Jul 22 10:48:47 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 08:48:47 +0000
Subject: [issue15420] issue6964 reminder
Message-ID: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

issue6964 is closed, so this is a reminder that discussion over the actual issue is not finished yet.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 166111
nosy: techtonik
priority: normal
severity: normal
status: open
title: issue6964 reminder
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 11:15:47 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 22 Jul 2012 09:15:47 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342948547.5.0.296659318553.issue15420@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What is the issue that you are reporting here? 

If you think there is an issue with Python, please state explicitly what the issue is. I think issue 6964 was invalid to begin with: it complained that the new module is no longer, but deletion of the new module was intentional.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 11:25:26 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 09:25:26 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342949126.54.0.10673790945.issue15420@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

You're mistaken. issue6964 is not about deleting `new` module in Python 3, it is about the 2to3 tool skipping this fact without warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 11:50:26 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 09:50:26 +0000
Subject: [issue5819] Add PYTHONPREFIXES environment variable
In-Reply-To: <1240475142.53.0.423262271042.issue5819@psf.upfronthosting.co.za>
Message-ID: <1342950626.38.0.64118598982.issue5819@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

As PEP 405 has been implemented in Python 3.3 this issue can be closed I think.

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5819>
_______________________________________

From report at bugs.python.org  Sun Jul 22 12:00:03 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Jul 2012 10:00:03 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <3Wg1Xf0kcZzPVP@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c286d50ecd19 by Ned Deily in branch 'default':
Issue #15184: Some config variables in test_sysconfig_module
http://hg.python.org/cpython/rev/c286d50ecd19

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sun Jul 22 12:12:16 2012
From: report at bugs.python.org (Ned Deily)
Date: Sun, 22 Jul 2012 10:12:16 +0000
Subject: [issue15188] test_ldshared_value failure on OS X using python.org
	Pythons
In-Reply-To: <1340693547.43.0.234356884387.issue15188@psf.upfronthosting.co.za>
Message-ID: <1342951936.62.0.161059118339.issue15188@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

With the changes here along with the fixes in Issue15184, I'm declaring this resolved for 3.3.  If and when _sysconfigdata.py gets moved, build-installer.py will need to be tweaked.

----------
dependencies:  -_sysconfigdata is generated in srcdir, not builddir
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15188>
_______________________________________

From report at bugs.python.org  Sun Jul 22 12:12:16 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 22 Jul 2012 10:12:16 +0000
Subject: [issue9548] locale can be imported at startup but relies on too
	many	library modules
In-Reply-To: <1281380971.62.0.695264636628.issue9548@psf.upfronthosting.co.za>
Message-ID: <1342951936.9.0.330374421706.issue9548@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/issue9548>
_______________________________________

From report at bugs.python.org  Sun Jul 22 12:21:18 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 22 Jul 2012 10:21:18 +0000
Subject: [issue11051] Improve Python 3.3 startup time
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1342952478.9.0.793376283691.issue11051@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/issue11051>
_______________________________________

From report at bugs.python.org  Sun Jul 22 12:24:53 2012
From: report at bugs.python.org (Ned Deily)
Date: Sun, 22 Jul 2012 10:24:53 +0000
Subject: [issue15184] Test failure in test_sysconfig_module
In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>
Message-ID: <1342952693.44.0.859392991924.issue15184@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The buildbot failures were reproducible on OS X 10.6 with Xcode 3. With the latest two fixes and with the fixes for Issue15188, I believe this issue is resolved for 3.3.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15184>
_______________________________________

From report at bugs.python.org  Sun Jul 22 12:57:22 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Jul 2012 10:57:22 +0000
Subject: [issue15094] Incorrectly placed #endif in _tkinter.c.
In-Reply-To: <1339927047.37.0.67596869478.issue15094@psf.upfronthosting.co.za>
Message-ID: <3Wg2pn11cWzPXp@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 657673a37dd3 by Andrew Svetlov in branch 'default':
#15094: fix incorrectly placed #endif in _tkinter.c.
http://hg.python.org/cpython/rev/657673a37dd3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15094>
_______________________________________

From report at bugs.python.org  Sun Jul 22 12:58:50 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 10:58:50 +0000
Subject: [issue15094] Incorrectly placed #endif in _tkinter.c.
In-Reply-To: <1339927047.37.0.67596869478.issue15094@psf.upfronthosting.co.za>
Message-ID: <1342954730.63.0.228997851953.issue15094@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Fixed. Thanks, Serhiy!

----------
assignee:  -> asvetlov
nosy: +asvetlov
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15094>
_______________________________________

From report at bugs.python.org  Sun Jul 22 12:59:27 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 22 Jul 2012 10:59:27 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342954767.73.0.698600932529.issue15420@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It was answered in the previous message by Georg, on the related issue:

http://bugs.python.org/issue6964#msg93032
> Bottom line: move over to the types module *before* running 2to3.

(the thread is very short, and clearly states that there's no bug)

----------
nosy: +flox
resolution:  -> invalid
superseder:  -> import new fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 13:24:49 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 11:24:49 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342956289.65.0.79444139218.issue15420@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

>From the user point of view that's the same as saying for optparse:

Bottom line: move over to the argparse module *before* running 2to3.

----------
resolution: invalid -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 13:26:07 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 11:26:07 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342956367.45.0.545995683575.issue15420@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Bottom line: The fact that 2to3 isn't capable to fix "import new" automatically doesn't mean it should not warn that this code should be fixed manually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 13:28:32 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 22 Jul 2012 11:28:32 +0000
Subject: [issue10854] Output .pyd name in error message of ImportError when
	DLL load fails
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1342956512.26.0.241757810439.issue10854@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

An example patch that aims to put the "name" and "path" in str() and repr() representations of ImportError.

Output when _socket.pyd is not found:

>>> import socket
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\pydev\hg\cpython3\lib\socket.py", line 47, in <module>
    import _socket
ImportError: No module named '_socket', _socket,
>>> sys.last_value
<ImportError "No module named '_socket'", '_socket', None>
>>>

----------
Added file: http://bugs.python.org/file26476/ImportError.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Sun Jul 22 13:29:41 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 11:29:41 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1342956581.79.0.926543214383.issue15402@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

+1 for patch applying in 3.3 at least

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Sun Jul 22 13:33:50 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 11:33:50 +0000
Subject: [issue15390] PEP 3121, 384 refactoring applied to datetime module
In-Reply-To: <1342647232.82.0.0763290244077.issue15390@psf.upfronthosting.co.za>
Message-ID: <1342956830.65.0.831826789566.issue15390@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Too late for 3.3

----------
nosy: +asvetlov
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15390>
_______________________________________

From report at bugs.python.org  Sun Jul 22 13:37:52 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 11:37:52 +0000
Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree
In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za>
Message-ID: <1342957072.95.0.688578252417.issue15133@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15133>
_______________________________________

From report at bugs.python.org  Sun Jul 22 13:45:06 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 22 Jul 2012 11:45:06 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342957506.73.0.54795739776.issue15420@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It does mean exactly that. 2to3 is not designed or intended to ever issue warnings. So if your request is that it should issue a warning, I'm closing it as "won't fix".

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 13:56:28 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 22 Jul 2012 11:56:28 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342958188.38.0.106072963815.issue15420@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The documentation for porting is already clear about using "-3" switch.
http://docs.python.org/dev/howto/pyporting.html#eliminate-3-warnings

The argparse module is different because it is not in the stdlib in 2.6, and you can stay with optparse if you write code compatible with all versions between 2.6 and 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 14:25:10 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 12:25:10 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342959910.52.0.295665936979.issue15420@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

My request is that after running 2to3 my code still doesn't work in Python 3.

----------
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 14:27:37 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 12:27:37 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342960057.56.0.355582259366.issue15420@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Florent: It is the same. "new" module just doesn't need replacement, because its functionality is in the language, therefore it is no different saying.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 14:46:36 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 12:46:36 +0000
Subject: [issue15041] tkinter documentation: update  "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1342961196.21.0.315629760303.issue15041@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Add all recommended resources into seealso section.

If it's ok I will commit it next week.

----------
keywords: +patch
Added file: http://bugs.python.org/file26477/issue15041.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15041>
_______________________________________

From report at bugs.python.org  Sun Jul 22 14:52:11 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 22 Jul 2012 12:52:11 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342961531.47.0.90974971258.issue15420@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please don't reopen issues.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 14:52:26 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 22 Jul 2012 12:52:26 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342961546.43.0.0181079393237.issue15420@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 14:57:21 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 22 Jul 2012 12:57:21 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342961841.8.0.423473303545.issue15420@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

IIUC, your request is not "should issue a warning", but "2to3 should make sure that the resulting code runs on Python 3".

It is beyond the scope of 2to3 to provide such guarantees. Users are required to test the conversion result, as it cannot be perfect.

So with the scope of this issue changed (again!!!!), the issue still won't be fixed.

If somebody contributed a fixer that converted the new module in 2to3, I might be in favor of integrating it (but others still may not).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 14:59:24 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Jul 2012 12:59:24 +0000
Subject: [issue15419] distutils: build_py_2to3 should use a separate build
	directory
In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za>
Message-ID: <1342961964.74.0.172065043982.issue15419@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Could you please be more specific about what you are trying to do and what error you are seeing?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15419>
_______________________________________

From report at bugs.python.org  Sun Jul 22 15:18:58 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Jul 2012 13:18:58 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1342963138.67.0.692461342491.issue14578@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So it should end up in Lib/importlib/_bootstrap.py since it is directly part of how import works. The original code as found in Python 3.2 for PyWin_FindRegisteredModule() is referenced in Python/import.c and is implemented in PC/import_nt.c. You will want to create a new sys.meta_path importer (if I'm reading the code from Python/import.c correctly in terms of the call to PyWin_FindRegisteredModule() happening before sys.path is traversed). You can refactor FileFinder if you need to in order to reuse its code.

In terms of working with importlib, you will probably need the winreg module, so inject that (see _setup() on how to do that). Also remember that while this is Python code, you will need to rebuild to trigger the regeneration of importlib.h. Otherwise (I hope) it isn't too complicated or hard to understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Sun Jul 22 16:13:05 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 14:13:05 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342966385.67.0.646369856591.issue15397@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Stefan, I've fixed refleak found by you in #15404. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Sun Jul 22 16:25:44 2012
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 22 Jul 2012 14:25:44 +0000
Subject: [issue15421] Calendar.itermonthdates OverflowError
Message-ID: <1342967144.9.0.843108675207.issue15421@psf.upfronthosting.co.za>


New submission from C?dric Krier <cedric.krier at b2ck.com>:

itermonthdates fails when working on the last month of 9999
Here is a patch that catch the OverflowError.

----------
components: Library (Lib)
files: calendar.patch
keywords: patch
messages: 166137
nosy: ced
priority: normal
severity: normal
status: open
title: Calendar.itermonthdates OverflowError
type: enhancement
Added file: http://bugs.python.org/file26478/calendar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15421>
_______________________________________

From report at bugs.python.org  Sun Jul 22 16:33:03 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 14:33:03 +0000
Subject: [issue15422] Get rid of PyCFunction_New macro
Message-ID: <1342967583.47.0.436061975286.issue15422@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

For now (3.3 beta) PyCFunction_New defined as macro calling PyCFunction_NewEx.
To be compatible with PEP 384 (Defining a Stable ABI) Objects/methodobject.c has trampoline function named PyCFunction_New which calls PyCFunction_NewEx.
This is only single usage of this idiom in CPython code.
For sake of uniformity we need to:
 - remove PyCFunction_New macro from Include/methodobject.h
 - declare PyCFunction_New as function in Include/methodobject.h
 - replace all calls of PyCFunction_New to PyCFunction_NewEx in code (about 8 occurrences).

----------
assignee: asvetlov
components: Interpreter Core
messages: 166138
nosy: asvetlov, loewis
priority: normal
severity: normal
stage: needs patch
status: open
title: Get rid of PyCFunction_New macro
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15422>
_______________________________________

From report at bugs.python.org  Sun Jul 22 17:01:19 2012
From: report at bugs.python.org (AliDD)
Date: Sun, 22 Jul 2012 15:01:19 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
Message-ID: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>


New submission from AliDD <registration000 at web.de>:

Attempt to parse the string
<script type="text/javascript">document.write('<bb></b>');</script>
by calling minidom.parseString()
causes ExpatError: mismatched tag: line 1, column 53
in lib\xml\dom\expatbuilder.py at line 223.

It looks like the parser detects open / closing tag mismatch, trying to parse <bb></b>.

----------
components: Library (Lib)
messages: 166139
nosy: AliDD
priority: normal
severity: normal
status: open
title: Minidom tries to parse tags inside of <script> tag
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Sun Jul 22 17:06:32 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Jul 2012 15:06:32 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
In-Reply-To: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>
Message-ID: <1342969592.57.0.415113506979.issue15423@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Why do you think this is a bug?  To my understanding, XML does not treat the <script> tag as anything special, so to an XML parser, those *are* mismatched tags.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Sun Jul 22 17:09:30 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Jul 2012 15:09:30 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
In-Reply-To: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>
Message-ID: <1342969770.51.0.855932150874.issue15423@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm sorry, my phrasing there was awkward.  I didn't mean "Why do you think this is a bug", I meant "I don't think this is a bug, am I missing something?"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Sun Jul 22 17:19:21 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Sun, 22 Jul 2012 15:19:21 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342970361.06.0.891042192289.issue15397@psf.upfronthosting.co.za>


Stefan Mihaila <mstefanro at gmail.com> added the comment:

Richard, yes, I think that would work, I didn't think of using f.__self__'s type.
You might want to replace
  if self is not None and not isinstance(self, types.ModuleType):
with
  if self is not None and not isinstance(self, types.ModuleType) \
                      and not isinstance(self, type):
to correctly raise an exception when called on a classmethod too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Sun Jul 22 17:35:22 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 22 Jul 2012 15:35:22 +0000
Subject: [issue10854] Output .pyd name in error message of ImportError when
	DLL load fails
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1342971322.92.0.528924462208.issue10854@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

How it the new message better than "ImportError: No module named '_socket'"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Sun Jul 22 17:42:56 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Sun, 22 Jul 2012 15:42:56 +0000
Subject: [issue15397] Unbinding of methods
In-Reply-To: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>
Message-ID: <1342971776.47.0.310431776305.issue15397@psf.upfronthosting.co.za>


Stefan Mihaila <mstefanro at gmail.com> added the comment:

Andrew, thanks for creating a separate issue (the refleak was very rare and I thought I'd put it in the same place, but now I realize it was a bad idea).

Richard, actually, the isinstance(self, type) check I mentioned earlier would have to be before the hastattr(f, '__func__') check, because Python classmethods provide a __func__ too:

    def unbind(f):
        self = getattr(f, '__self__', None)
        if self is not None and not isinstance(self, types.ModuleType) \
                            and not isinstance(self, type):
            if hasattr(f, '__func__'):
                return f.__func__
            return getattr(type(f.__self__), f.__name__)
        raise TypeError('not a bound method')

Anyway, I'm not convinced this is worth adding anymore. As Antoine Pitrou suggested on the ml, it would probably be a better idea if I implemented __reduce__ for builtin methods as well as Python methods rather than having a separate opcode for pickling methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15397>
_______________________________________

From report at bugs.python.org  Sun Jul 22 17:46:56 2012
From: report at bugs.python.org (AliDD)
Date: Sun, 22 Jul 2012 15:46:56 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
In-Reply-To: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>
Message-ID: <1342972016.73.0.871017682175.issue15423@psf.upfronthosting.co.za>


AliDD <registration000 at web.de> added the comment:

> Why do you think this is a bug?
    IMHO XML parser must not and can not parse content of <script> tag because it don't "understand" JavaScript or any other scripting language. I think content of <script> should be returned as is.
> so to an XML parser, those *are* mismatched tags.
    Here they are not tags at all, but part of JavaScript string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Sun Jul 22 18:16:44 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Jul 2012 16:16:44 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
In-Reply-To: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>
Message-ID: <1342973804.97.0.368450137164.issue15423@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are exactly correct that an XML parser doesn't know how to parse javascript.  That's my point.

To my understanding <script> has no special meaning to XML.  Thus a <script> tag follows all the same content rules as any arbitrary other tag (<h1>, <bold>, <foo>).  An XML parser will not (again, to my understanding) treat the content of any of these tags as anything other than XML.  I believe that in XML the CDATA construct is used for embedding arbitrary content inside a tag.

Unless you have a reference to an XML standard that indicates the script tag should be treated specially, I'm going to close this as invalid.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Sun Jul 22 18:22:41 2012
From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=)
Date: Sun, 22 Jul 2012 16:22:41 +0000
Subject: [issue15424] __sizeof__ of array should include size of items
Message-ID: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za>


New submission from Ludwig H?hne <wkx at gmx.li>:

If sys.getsizeof is called on an array, the result doesn't include the size of the items: 

>>> from array import array
>>> a = array("i", [0] * 100000)
>>> a.__sizeof__()
40

While this makes sense for a list, an array doesn't have separate referents that could be sized:

>>> import gc
>>> gc.get_referents(a)
[]

The attached patch adds an implementation of the __sizeof__ method for arrays that includes the size of the buffer for the elements.

It would be great if the patch would be considered for one of the upcoming versions of Python.

Thanks, Ludwig

----------
components: Library (Lib)
files: array_sizeof.patch
keywords: patch
messages: 166147
nosy: Pankrat
priority: normal
severity: normal
status: open
title: __sizeof__ of array should include size of items
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26479/array_sizeof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15424>
_______________________________________

From report at bugs.python.org  Sun Jul 22 18:40:54 2012
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 22 Jul 2012 16:40:54 +0000
Subject: [issue14489] repr() function link on the built-in function
	documentation is incorrect
In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>
Message-ID: <1342975254.23.0.0180274356535.issue14489@psf.upfronthosting.co.za>


Piotr Dobrogost <pd at bugs.python.dobrogost.net> added the comment:

The wrong link is still at http://docs.python.org/library/functions.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14489>
_______________________________________

From report at bugs.python.org  Sun Jul 22 18:53:11 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 16:53:11 +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: <1342975991.9.0.0744509898832.issue11776@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Still not documented..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Sun Jul 22 18:58:11 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 22 Jul 2012 16:58:11 +0000
Subject: [issue15424] __sizeof__ of array should include size of items
In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za>
Message-ID: <1342976291.38.0.959001496086.issue15424@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please submit a contributor form?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15424>
_______________________________________

From report at bugs.python.org  Sun Jul 22 19:07:38 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 22 Jul 2012 17:07:38 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
In-Reply-To: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>
Message-ID: <1342976858.2.0.570265449673.issue15423@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

R. David is correct. The XML specification *clearly* defines that your XML document is ill-formed, since the closing tag for '<bb>' is '</b>', which doesn't match.

XML is not HTML: the XML parser must not treat the script element specially.

----------
nosy: +loewis
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Sun Jul 22 19:24:58 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 17:24:58 +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: <1342977898.54.0.708385873938.issue11776@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Another 4 complains about missing references: http://stackoverflow.com/questions/1015307/python-bind-an-unbound-method

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11776>
_______________________________________

From report at bugs.python.org  Sun Jul 22 19:25:17 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Jul 2012 17:25:17 +0000
Subject: [issue15424] __sizeof__ of array should include size of items
In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za>
Message-ID: <1342977917.78.0.234984220926.issue15424@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

I think it should be applied to 3.2 too.

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15424>
_______________________________________

From report at bugs.python.org  Sun Jul 22 19:26:09 2012
From: report at bugs.python.org (AliDD)
Date: Sun, 22 Jul 2012 17:26:09 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
In-Reply-To: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>
Message-ID: <1342977969.75.0.701090773642.issue15423@psf.upfronthosting.co.za>


AliDD <registration000 at web.de> added the comment:

Document Object Model (DOM) Level 1 Specification at 
http://www.w3.org/TR/REC-DOM-Level-1/
states that
"The Document Object Model provides a standard set of objects for representing HTML and XML documents"
That's why I try to use xml.dom.minidom to parse some HTML. And my HTML sample is valid HTML. Possibly I misunderstand purpose of xml.dom.minidom
and / or expat and they should be used only with XML. Or I should use minidom.parseString() with some parser other as default expat. If so could you recommend some built in one?

If xml.dom.minidom should process only XML and not HTML (which not always is valid XML), than I'm sorry for disturbance and please feel free to close this issue as invalid.

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Sun Jul 22 20:34:25 2012
From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=)
Date: Sun, 22 Jul 2012 18:34:25 +0000
Subject: [issue15424] __sizeof__ of array should include size of items
In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za>
Message-ID: <1342982065.84.0.149824434078.issue15424@psf.upfronthosting.co.za>


Ludwig H?hne <wkx at gmx.li> added the comment:

Uses self->allocated instead of Py_SIZE as Martin suggested.

----------
Added file: http://bugs.python.org/file26480/array_sizeof_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15424>
_______________________________________

From report at bugs.python.org  Sun Jul 22 20:35:54 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 18:35:54 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342982154.76.0.700038356538.issue15420@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

> Please don't reopen issues.

"Please don't ask for such silly stuff". You can understand the reason why this issue was opened, so why do you keep closing it if the "issue is not resolved"? 


The scope of this issue never changed, Martin. If you follow the user story, it is still the same original "user issue" or bad user experience with 2to3 tool.

It is fine if you're not going to work on a fix, but that's NOT the reason to close the issue. The proper fix would be to explain why you think there is nobody except yourself who can fix that, or provide the guarantees that the fix won't be accepted.

----------
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Sun Jul 22 20:57:20 2012
From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=)
Date: Sun, 22 Jul 2012 18:57:20 +0000
Subject: [issue15424] __sizeof__ of array should include size of items
In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za>
Message-ID: <1342983440.46.0.923045252437.issue15424@psf.upfronthosting.co.za>


Ludwig H?hne <wkx at gmx.li> added the comment:

Yes, it would be great if the change could be applied to 3.2 (and 2.7) but I guess not many people will be affected by the problem.

BTW, I just submitted the contributor form.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15424>
_______________________________________

From report at bugs.python.org  Sun Jul 22 21:40:27 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Jul 2012 19:40:27 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
In-Reply-To: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>
Message-ID: <1342986027.63.0.575604385502.issue15423@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

*xml*.dom.minidom parses only XML.  The documentation mentions only xml, not html.  I suppose that confusion could arise from the fact that that the w3c-dom API model can be provided by things that parse html as well.  I'm not sure if it is worth adding a documentation note to that effect or not, but if so that would be a different issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Sun Jul 22 21:57:08 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Jul 2012 19:57:08 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
In-Reply-To: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>
Message-ID: <1342987028.51.0.106503106179.issue15423@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> That's why I try to use xml.dom.minidom to parse some HTML.

Have you tried HTMLParser?

----------
nosy: +ezio.melotti
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Sun Jul 22 21:57:11 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 19:57:11 +0000
Subject: [issue14910] argparse: disable abbreviation
In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za>
Message-ID: <1342987031.06.0.574239492976.issue14910@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I think it makes a lot of sense to allow people to disable abbreviations, so +1 on the feature request.

The patch looked good. There was one typo - using "accept_abbrev" in the docstring instead of "allow_abbrev" as in the implementation, and I fixed that and uploaded a new patch.

To be complete, the patch also needs to add some documentation, edit Misc/NEWS, etc. See:

http://docs.python.org/devguide/patch.html#preparation

----------
versions: +Python 3.4 -Python 3.3
Added file: http://bugs.python.org/file26481/14910.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14910>
_______________________________________

From report at bugs.python.org  Sun Jul 22 21:58:18 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 19:58:18 +0000
Subject: [issue14910] argparse: disable abbreviation
In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za>
Message-ID: <1342987098.13.0.195953745602.issue14910@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Sorry, my mistake, the doc changes were already in the patch. I just checked them and they look good too. So everything's ready to commit.

Thanks for your contribution!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14910>
_______________________________________

From report at bugs.python.org  Sun Jul 22 22:01:45 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Jul 2012 20:01:45 +0000
Subject: [issue15392] Create a unittest framework for IDLE
In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za>
Message-ID: <1342987305.33.0.248379259042.issue15392@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/issue15392>
_______________________________________

From report at bugs.python.org  Sun Jul 22 22:03:38 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Jul 2012 20:03:38 +0000
Subject: [issue15360] Behavior of assigning to __dict__ is not documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1342987418.81.0.290902832574.issue15360@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15360>
_______________________________________

From report at bugs.python.org  Sun Jul 22 22:05:26 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Jul 2012 20:05:26 +0000
Subject: [issue15350] {urllib,urllib.parse}.urlencode.__doc__ is unclear
In-Reply-To: <1342263934.43.0.385544849615.issue15350@psf.upfronthosting.co.za>
Message-ID: <1342987526.64.0.818839726756.issue15350@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15350>
_______________________________________

From report at bugs.python.org  Sun Jul 22 22:06:33 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Jul 2012 20:06:33 +0000
Subject: [issue14910] argparse: disable abbreviation
In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za>
Message-ID: <1342987593.13.0.646092629167.issue14910@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Jonathan: we are in feature freeze right now preparing 3.3 for release, so you might want to ping the issue once 3.3 is out to remind us to do the checkin.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14910>
_______________________________________

From report at bugs.python.org  Sun Jul 22 22:07:02 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 22 Jul 2012 20:07:02 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
Message-ID: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Two "easy" ways to get tracebacks which contain useless importlib._bootstrap rows:
- When there is a syntax error in the imported module
- On "import package.module", when top-level package cannot be imported


$ ./python -c "import foo"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 1421, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1388, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 527, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 899, in load_module
  File "<frozen importlib._bootstrap>", line 880, in load_module
  File "<frozen importlib._bootstrap>", line 503, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 744, in _load_module
  File "<frozen importlib._bootstrap>", line 857, in get_code
  File "./foo.py", line 1
    invalid syntax
                 ^
SyntaxError: invalid syntax


$ ./python
Python 3.3.0b1 (default:afdb0e1a9dac+, Jul 19 2012, 23:55:02) 
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _sqlite3
>>> del _sqlite3.register_converter
>>> import sqlite3.dump
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 1421, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1372, in _find_and_load_unlocked
  File "/home/amauryfa/python/cpython3.x/Lib/sqlite3/__init__.py", line 23, in <module>
    from sqlite3.dbapi2 import *
  File "/home/amauryfa/python/cpython3.x/Lib/sqlite3/dbapi2.py", line 83, in <module>
    register_adapters_and_converters()
  File "/home/amauryfa/python/cpython3.x/Lib/sqlite3/dbapi2.py", line 80, in register_adapters_and_converters
    register_converter("date", convert_date)
NameError: global name 'register_converter' is not defined

----------
messages: 166163
nosy: amaury.forgeotdarc, brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Another strange Tracebacks with importlib
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 22 22:07:52 2012
From: report at bugs.python.org (Shocked Pancake)
Date: Sun, 22 Jul 2012 20:07:52 +0000
Subject: [issue15426] On a x86_64 Linux workstation,
	the build-from-source is borked.
Message-ID: <1342987672.67.0.931013334684.issue15426@psf.upfronthosting.co.za>


New submission from Shocked Pancake <shockedpancake at gmail.com>:

On a x86_64 Linux workstation, when building from source with ./configure  --prefix=/usr --libdir=/usr/lib64 --enable-ipv6 --with-threads --enable-shared --doc-dir=/usr/doc/python --mandir=/usr/man, almost all library get installed in /usr/lib and not /usr/lib64. And when the python interpreter get launched, it complain about not finding platform dependent libraries and that I should set $PYTHONHOME.
When I apply the patch that I joined with this, it all works well.

----------
components: Build
files: python3.x86_64.diff
keywords: patch
messages: 166164
nosy: Shocked.Pancake
priority: normal
severity: normal
status: open
title: On a x86_64 Linux workstation, the build-from-source is borked.
versions: Python 3.2
Added file: http://bugs.python.org/file26482/python3.x86_64.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15426>
_______________________________________

From report at bugs.python.org  Sun Jul 22 22:08:22 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 20:08:22 +0000
Subject: [issue8538] Add FlagAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1342987702.46.0.808319525391.issue8538@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

On the off chance that someone was waiting for feedback from me, I'll say:

(1) A simple boolean --foo/--no-foo action seems useful to me. I would probably call it BooleanOptionalAction rather than FlagAction. (Almost anything could be considered a "flag".)

(2) At the moment, argparse doesn't supply any actions, so I don't think we should make a separate namespace for them. If it starts to grow a list of such actions, we can add a separate namespace later. (And given that the name will end with "Action", I think it should be pretty clear without the namespace.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8538>
_______________________________________

From report at bugs.python.org  Sun Jul 22 22:18:45 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Jul 2012 20:18:45 +0000
Subject: [issue15426] On a x86_64 Linux workstation,
	the build-from-source is borked.
In-Reply-To: <1342987672.67.0.931013334684.issue15426@psf.upfronthosting.co.za>
Message-ID: <1342988325.95.0.401917571821.issue15426@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This might (or might not) be a duplicate of issue1294959.

----------
nosy: +doko, eric.araujo, pitrou
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15426>
_______________________________________

From report at bugs.python.org  Sun Jul 22 22:29:18 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Jul 2012 20:29:18 +0000
Subject: [issue13252] new decumulate() function in itertools module
In-Reply-To: <1319409168.22.0.462760902888.issue13252@psf.upfronthosting.co.za>
Message-ID: <1342988958.65.0.813680067159.issue13252@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I don't think this should go in itertools.  It could go in the recipes at the bottom of the itertools doc, if you can provide some valid use cases (and possibly a patch too).

----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13252>
_______________________________________

From report at bugs.python.org  Sun Jul 22 22:54:00 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 22 Jul 2012 20:54:00 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1342990440.17.0.956112842742.issue14578@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't have Windows, but here is an example of a WindowsRegistryImporter, written outside importlib (the script also contains a fake implementation of winreg, so I could test it...)

Of course it needs to be rewritten to fit in _bootstrap.py;  at least the script shows that it's only necessary to implement a find_module() function.

I'm not sure I had all details right - for example, should we search for the full module name, or only the last component?

This loader has some interesting features; for example it's possible to have several modules in the same .pyd file, as long as it exports the various PyInit_* functions.

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file26483/winreg_loader.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Sun Jul 22 22:54:13 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Sun, 22 Jul 2012 20:54:13 +0000
Subject: [issue6804] IDLE: Detect Python files even if name doesn't end in .py
In-Reply-To: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>
Message-ID: <1342990453.82.0.475362173667.issue6804@psf.upfronthosting.co.za>


Daniel Swanson <popcorn.tomato.dude at gmail.com> added the comment:

No. When I try to open the file a small window entitled "Specify file encoding" pops up that says 
"The file's encoding is invalid in Python 3.x.
Idle will convert it to UTF-8.
What is the current encoding of the file?"
followed by an entry widget that has "cp1252" and "ok" and "cancel" buttons. When I click "ok" the computer go "dunnn" and a error window titled "Decoding Error" that says "File C:\Python32\misc\bee.jpg Failed to Decode" with an "ok" button which, when clicked, closes idle (the edit window, not the shell). Does that answer your question?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6804>
_______________________________________

From report at bugs.python.org  Sun Jul 22 23:06:31 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 21:06:31 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1342991191.41.0.37159753337.issue14156@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The fix looks right, but we definitely need a test. I tried to write one, but I'm not sure how to do this properly given how test_argparse redirects standard input and output (so that fileno() doesn't work anymore). I've attached my current (failing) attempt to test this.

----------
Added file: http://bugs.python.org/file26484/14156.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Sun Jul 22 23:17:51 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 21:17:51 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1342991871.46.0.860963829286.issue11354@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The tests look like they're testing the right things, but the tests should instead be written like the rest of the argparse tests. For example, look at TestOptionalsNargs3 and TestPositionalsNargs2. You could write your tests to look something like those, e.g.

class TestOptionalsNargs1_3(ParserTestCase):

    argument_signatures = [Sig('-x', nargs=(1, 3))]
    failures = ['a', '-x', '-x a b c d']
    successes = [
        ('', NS(x=None)),
        ('-x a', NS(x=['a'])),
        ('-x a b', NS(x=['a', 'b'])),
        ('-x a b c', NS(x=['a', 'b', 'c'])),
    ]

Also, a complete patch will need to document the new feature in the Python documentation, among other things. See the details described here:

http://docs.python.org/devguide/patch.html#preparation

----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Sun Jul 22 23:21:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 22 Jul 2012 21:21:38 +0000
Subject: [issue15147] Remove packaging from the stdlib
In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za>
Message-ID: <1342992098.75.0.240543063317.issue15147@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

packaging (and related changes in sysconfig) have been removed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15147>
_______________________________________

From report at bugs.python.org  Sun Jul 22 23:53:47 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 21:53:47 +0000
Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept
	any items if preceded by an option and another positional
In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za>
Message-ID: <1342994027.39.0.277239827847.issue15112@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Your patch is a good start, but it needs to handle all the related situations, e.g. nargs='?' and the possibility of having more than one zero-length argument at the end.

I believe the following patch achieves this. Please test it out.

----------
versions: +Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26485/15112.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15112>
_______________________________________

From report at bugs.python.org  Mon Jul 23 00:12:34 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 22:12:34 +0000
Subject: [issue15427] Describe use of args parameter of
	argparse.ArgumentParser.parse_args
Message-ID: <1342995154.12.0.902919829048.issue15427@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

>From http://bugs.python.org/issue14191#msg155202:

ArgumentParser.parse_args(args=None, namespace=None)
...
However, nowhere is the args= parameter explained.  One example is given at the end of 15.4.4.6 showing the use of args= which apparently accepts a list of parameters, similar to the positional list of parameters that are used in all the other examples.  It might be nice to clarify that.

----------
assignee: docs at python
components: Documentation
messages: 166174
nosy: bethard, docs at python
priority: normal
severity: normal
status: open
title: Describe use of args parameter of argparse.ArgumentParser.parse_args
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/issue15427>
_______________________________________

From report at bugs.python.org  Mon Jul 23 00:16:22 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 22:16:22 +0000
Subject: [issue14191] argparse doesn't allow optionals within positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1342995382.19.0.520849761123.issue14191@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I created Issue 15427 for the parse_args documentation bug. So let's make this issue just about parsing intermixed arguments.

Yes, if someone would like to provide a patch for this, please create a method "parse_intermixed_args" rather than adding a boolean flag parameter. It should be basically equivalent to this code:

args, remaining_args = optionals.parse_known_args()
args = positionals.parse_args(remaining_args, args)

Except that it should give proper error messages. There should be some tests to make sure both that it parses things as expected and that it gives error messages as expected.

----------
assignee: docs at python -> 
components:  -Documentation
title: argparse: nargs='*' doesn't get out-of-order positional parameters -> argparse doesn't allow optionals within positionals
versions: +Python 3.4 -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14191>
_______________________________________

From report at bugs.python.org  Mon Jul 23 00:18:10 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 22 Jul 2012 22:18:10 +0000
Subject: [issue15420] issue6964 reminder
In-Reply-To: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>
Message-ID: <1342995490.65.0.7955459383.issue15420@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy:  -flox, loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15420>
_______________________________________

From report at bugs.python.org  Mon Jul 23 00:25:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 22 Jul 2012 22:25:06 +0000
Subject: [issue15360] Behavior of assigning to __dict__ is not documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1342995906.07.0.853785708578.issue15360@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/issue15360>
_______________________________________

From report at bugs.python.org  Mon Jul 23 00:37:36 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 22:37:36 +0000
Subject: [issue15271] argparse: repeatedly specifying the same argument
	ignores the previous ones
In-Reply-To: <1341650741.0.0.256570615986.issue15271@psf.upfronthosting.co.za>
Message-ID: <1342996656.62.0.0171950098764.issue15271@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I don't think this is a bug. You've specified two arguments with the same destination, "foo". This means that argparse will parse the first one, assign it to the attribute "foo" and then parse the second one and assign it to the attribute "foo" again, overwriting the previous one. So you only see the second one, but the first one wasn't ignored.

If you didn't want them to overwrite the same attribute, you either need to declare them as action="append" so that they both add to the same attribute, or you need to declare them with different destinations (and use metavar="foo" if you want them to display the same way).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15271>
_______________________________________

From report at bugs.python.org  Mon Jul 23 00:44:30 2012
From: report at bugs.python.org (AliDD)
Date: Sun, 22 Jul 2012 22:44:30 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
In-Reply-To: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>
Message-ID: <1342997070.11.0.758392343978.issue15423@psf.upfronthosting.co.za>


AliDD <registration000 at web.de> added the comment:

@Ezio Melotti:
Do you mean as parser with minidom.parseString() or stand alone? If second, than, result will be the sequence of handler calls instead of DOM. This is not bad, but entirely different story.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Mon Jul 23 00:51:17 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Jul 2012 22:51:17 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
In-Reply-To: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>
Message-ID: <1342997477.7.0.745370768338.issue15423@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Do you mean as parser with minidom.parseString() or stand alone?

Standalone.

> If second, than, result will be the sequence of handler calls instead of DOM. This is not bad, but entirely different story.

Indeed.  If you want a tree you could try BeautifulSoup or lxml; there's no tool in the stdlib that specifically parses an HTML document and builds a tree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Mon Jul 23 00:53:26 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 22 Jul 2012 22:53:26 +0000
Subject: [issue10854] Output .pyd name in error message of ImportError when
	DLL load fails
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1342997606.51.0.45718682842.issue10854@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, the demo demo I added sucks, because I didn't demo the original problem (.pyd found but could not be loaded), but the point is, it displays the "name" and "path" attributes.  They can be set, for example, if the module is found but cannot be loaded for some reason.

That's the point of this issue.  The fix added a "name" and "path" attributes, but they were never actually _output_ when such an error occurred.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Mon Jul 23 01:06:39 2012
From: report at bugs.python.org (AliDD)
Date: Sun, 22 Jul 2012 23:06:39 +0000
Subject: [issue15423] Minidom tries to parse tags inside of <script> tag
In-Reply-To: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>
Message-ID: <1342998399.48.0.853117908808.issue15423@psf.upfronthosting.co.za>


AliDD <registration000 at web.de> added the comment:

Will give a try to some of them later. Thanks for info.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15423>
_______________________________________

From report at bugs.python.org  Mon Jul 23 01:19:40 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 22 Jul 2012 23:19:40 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1342999180.15.0.0970024982827.issue15403@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/issue15403>
_______________________________________

From report at bugs.python.org  Mon Jul 23 01:27:30 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 23:27:30 +0000
Subject: [issue15125] argparse: positional arguments containing - in name not
	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1342999650.95.0.202813867708.issue15125@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I'm sympathetic to the idea that '-' should be translated similarly for optional and positional arguments, but as you've noted, it would be a risky patch because it's already possible for people to use getattr on hyphenated arguments. So I think this isn't possible without a long deprecation process first.

> But patching the module to allow explicitly setting dest via keyword 
> argument shouldn't hurt anybody.

I agree that it wouldn't hurt anybody. If you can find a way to do this, feel free to provide a patch.

However, the correct way to have one name for the attribute (i.e. dest=) and one name for the help (i.e. metavar=) is to use the metavar argument like so:

    parser.add_argument('positional_args', metavar='positional-args')

That said, this is not the first time I've seen someone run into this problem. I think the documentation could be improved in a few ways:

(1) In the "name or flags" section, describe how the flags (for optional arguments) are translated into both a default "dest" (stripping initial '-' and converting '-' to '_') and into a default "metavar" (stripping initial '-' and uppercasing). Part of this is in the "dest" and "metavar" documentation, but probably belongs up in the "name or flags" documentation. Add cross-references to "dest" and "metavar" sections.

(2) In the "name or flags" section, describe how the name (for positional arguments) are translated into the same default "dest" and "metavar" (no string munging at all). Again, move stuff from the "dest" and "metavar" sections as necessary. Add cross-references to "dest" and "metavar" sections.

(3) In the "dest" section and somewhere in the "parse_args" section, describe how "getattr" can be used to get attributes whose names aren't valid Python identifiers. Maybe cross-reference this section from the edits in (2).

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15125>
_______________________________________

From report at bugs.python.org  Mon Jul 23 01:37:07 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 23:37:07 +0000
Subject: [issue11176] give more meaningful argument names in argparse
	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1343000227.99.0.258414035185.issue11176@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Thanks for working on this! I think keeping the first example as simple is possible is probably a good idea. And I didn't have time to read through the whole patch, but as far as I went, the pizza examples looked great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Mon Jul 23 01:39:04 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 23:39:04 +0000
Subject: [issue15336] Argparse required arguments incorrectly displayed as
	optional arguments
In-Reply-To: <1342122214.84.0.306915245284.issue15336@psf.upfronthosting.co.za>
Message-ID: <1343000344.73.0.73671241044.issue15336@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> argparse: Default Help Message Lists Required Args As Optional

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15336>
_______________________________________

From report at bugs.python.org  Mon Jul 23 01:40:56 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 23:40:56 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
	arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1343000456.85.0.247846194864.issue9694@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I'm changing the title because I keep seeing duplicates.

Documentation patches still welcome!

----------
title: argparse: Default Help Message Lists Required Args As Optional -> argparse required arguments displayed under "optional arguments"
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Mon Jul 23 01:53:40 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 23:53:40 +0000
Subject: [issue15327] Argparse: main arguments and subparser arguments
	indistinguishable
In-Reply-To: <1342004730.08.0.363281774737.issue15327@psf.upfronthosting.co.za>
Message-ID: <1343001220.72.0.583329258326.issue15327@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I don't think there's any easy way for argparse to automatically do what you want. However, there's a simple workaround - just use the dest= argument and specify two different destinations:

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('--verbose', action='store_true', dest='verbose_main')
>>> subparsers = parser.add_subparsers(help='command', dest='command')
>>> cmd1_parser = subparsers.add_parser('command')
>>> cmd1_parser.add_argument('--verbose', action='store_true', dest='verbose_sub')
>>> parser.parse_args(['command', '--verbose'])
Namespace(command='command', verbose_main=False, verbose_sub=True)
>>> parser.parse_args(['--verbose', 'command'])
Namespace(command='command', verbose_main=True, verbose_sub=False)

Closing as a wontfix, but feel free to reopen if you want to provide a patch for something.

----------
resolution:  -> wont fix
status: open -> closed
versions:  -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15327>
_______________________________________

From report at bugs.python.org  Mon Jul 23 02:00:32 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 00:00:32 +0000
Subject: [issue15428] add "Name Collision" section to argparse docs
Message-ID: <1343001632.52.0.429837248023.issue15428@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Several bugs (e.g. Issue 15327 and Issue 15271) have been filed suggesting that people aren't really clear on how argparse handles argument name collisions or how they can get it to do what they want.

I think these problems could probably be solved by a "Name Collision" section (or something like that) in the argparse documentation. It would give a few example problems and show how to resolve them. Some things to include:

* What happens when two arguments have the same dest (Issue 15271), with solutions including action='append' or different dest= values combined with identical metavar= values.

* What happens when a parser and a sub-parser share some of the same argument names (Issue 15327), with solutions including specifying different dest= values for the parser and sub-parser

* A brief mention and cross-reference to the "conflict_handler" section.

----------
assignee: docs at python
components: Documentation
messages: 166185
nosy: bethard, docs at python
priority: normal
severity: normal
status: open
title: add "Name Collision" section to argparse docs
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15428>
_______________________________________

From report at bugs.python.org  Mon Jul 23 02:01:42 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 00:01:42 +0000
Subject: [issue15327] Argparse: main arguments and subparser arguments
	indistinguishable
In-Reply-To: <1342004730.08.0.363281774737.issue15327@psf.upfronthosting.co.za>
Message-ID: <1343001702.23.0.622218547383.issue15327@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

If you'd like to help improve the documentation so that the workaround for your problem is more obvious, please contribute to Issue 15428.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15327>
_______________________________________

From report at bugs.python.org  Mon Jul 23 02:04:15 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 00:04:15 +0000
Subject: [issue15271] argparse: repeatedly specifying the same argument
	ignores the previous ones
In-Reply-To: <1341650741.0.0.256570615986.issue15271@psf.upfronthosting.co.za>
Message-ID: <1343001855.32.0.515000617426.issue15271@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I'm going to close this issue, since argparse is doing what you've asked it to, even if that wasn't what you expected.

But I think the documentation for this kind of thing could be improved. If you'd like to help document the workaround for your problem that I described, please contribute to Issue 15428.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15271>
_______________________________________

From report at bugs.python.org  Mon Jul 23 02:17:18 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 00:17:18 +0000
Subject: [issue13720] argparse print_help() fails if COLUMNS is set to a low
	value
In-Reply-To: <1325858148.7.0.947093232457.issue13720@psf.upfronthosting.co.za>
Message-ID: <1343002638.78.0.657331018624.issue13720@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Definitely a bug here. Attached is a patch and a test, based on Russell Sim's suggestion, that should fix it.

----------
keywords: +patch
versions: +Python 3.4
Added file: http://bugs.python.org/file26486/13720.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13720>
_______________________________________

From report at bugs.python.org  Mon Jul 23 02:19:35 2012
From: report at bugs.python.org (Anders Kaseorg)
Date: Mon, 23 Jul 2012 00:19:35 +0000
Subject: [issue15429] types.NoneType missing
Message-ID: <1343002775.55.0.171826100235.issue15429@psf.upfronthosting.co.za>


Changes by Anders Kaseorg <andersk at mit.edu>:


----------
assignee: docs at python
components: Documentation
nosy: andersk, docs at python
priority: normal
severity: normal
status: open
title: types.NoneType missing
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15429>
_______________________________________

From report at bugs.python.org  Mon Jul 23 02:20:37 2012
From: report at bugs.python.org (Anders Kaseorg)
Date: Mon, 23 Jul 2012 00:20:37 +0000
Subject: [issue15429] types.NoneType missing
Message-ID: <1343002837.2.0.031540132971.issue15429@psf.upfronthosting.co.za>


New submission from Anders Kaseorg <andersk at mit.edu>:

http://docs.python.org/py3k/library/constants.html#None says that None is the sole value type types.NoneType.  However, NoneType was removed from the types module with Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15429>
_______________________________________

From report at bugs.python.org  Mon Jul 23 02:44:07 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Jul 2012 00:44:07 +0000
Subject: [issue15429] types.NoneType missing
In-Reply-To: <1343002837.2.0.031540132971.issue15429@psf.upfronthosting.co.za>
Message-ID: <3WgP8j33wHzPQ2@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 84b577567fab by R David Murray in branch '3.2':
#15429: Fix invalid mention of types.NoneType from None docs.
http://hg.python.org/cpython/rev/84b577567fab

New changeset c43d73277756 by R David Murray in branch 'default':
Merge #15429: Fix invalid mention of types.NoneType from None docs.
http://hg.python.org/cpython/rev/c43d73277756

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15429>
_______________________________________

From report at bugs.python.org  Mon Jul 23 02:45:04 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Jul 2012 00:45:04 +0000
Subject: [issue15429] types.NoneType missing
In-Reply-To: <1343002837.2.0.031540132971.issue15429@psf.upfronthosting.co.za>
Message-ID: <1343004304.61.0.0742429564644.issue15429@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the report.  Fixed.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15429>
_______________________________________

From report at bugs.python.org  Mon Jul 23 02:55:52 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 00:55:52 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1343004952.15.0.0443076336563.issue15250@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks, Senthil.  I would prefer if you created a new issue in the tracker for your additional changes, and then committed your changes as part of that issue.  By attribution, I was referencing the "Patch by Chris Jerdonek" which can go in the commit message and Misc/NEWS for this issue.  I am already listed in Misc/ACKS.

To keep things simple, can you perhaps review my original patch as is?  If you would like, I would be happy to provide feedback separately on your own changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15250>
_______________________________________

From report at bugs.python.org  Mon Jul 23 03:49:24 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 23 Jul 2012 01:49:24 +0000
Subject: [issue14191] argparse doesn't allow optionals within positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1343008164.93.0.221768726142.issue14191@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

So my t18a.py wraps Argparse, because the externals are documented and I could understand that. Given enough time, I might be able to understand the internals too... it is just Python...

Seems like the internals separate positionals and optionals into two subparsers, the logic needed is to save the positionals, temporarily replace them with an empty group, and call parse_known_args, then restore the positionals, and call parse_known_args again.

What I haven't figured out, is how that would affect the help message building, and how to make the empty group of positionals without affecting the help message.

It's also not clear that it is possible, with current internals, to substitute an empty group... the only features for creating a group seem to always add it to a list of _action_groups.  So that muddies the water, just like the help message... everything seems intertwined internally.

A little guidance here, would let me code... I could probably whack and slash, and keep extra lists of arguments and sort of make it work like my wrapper does, but I doubt that would be an acceptable patch. So I would be happy, with guidance, to try to create the code, and I can do a "diff", but beyond that, I'm sort of at a loss.

So I'd be happy to work with someone to create the patch, but I've also never created a patch, nor test cases, for Python (or any other open source project). Theoretically, it is straightforward, and documented; as a practical matter, it isn't likely that I'll find time to figure out all that methodology and actually create a patch, in the near future (although it is on my list of things to learn, in the fullness of time, and after the first one, I'm sure subsequent ones would be easier).

Or if someone else wants to code it, I'd be happy to look it over, test it with my environment and applications that I'm currently using with my wrapper.

Given this guidance, I've tweaked my wrapper to have parse_intermixed_args rather than changing the behavior of parse_args as I have been, and will tweak the apps correspondingly, so I'll be in a position to test any code created for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14191>
_______________________________________

From report at bugs.python.org  Mon Jul 23 03:50:25 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Jul 2012 01:50:25 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1343008225.58.0.946956005382.issue15250@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Chris, your patch looks good. I shall commit it now. The rest of the documentation changes can go in another patch. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15250>
_______________________________________

From report at bugs.python.org  Mon Jul 23 03:55:34 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Jul 2012 01:55:34 +0000
Subject: [issue15232] email.generator.Generator doesn't mangle "From " lines
	in MIME preamble
In-Reply-To: <1341118945.33.0.829442271947.issue15232@psf.upfronthosting.co.za>
Message-ID: <3WgQl92Rh5zP3Y@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b97f65f2298d by R David Murray in branch '3.2':
#15232: correctly mangle From lines in MIME preamble and epilogue
http://hg.python.org/cpython/rev/b97f65f2298d

New changeset 80b81658455b by R David Murray in branch 'default':
Merge #15232: correctly mangle From lines in MIME preamble and epilogue
http://hg.python.org/cpython/rev/80b81658455b

New changeset 9f500171c592 by R David Murray in branch '2.7':
#15232: correctly mangle From lines in MIME preamble and epilogue
http://hg.python.org/cpython/rev/9f500171c592

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15232>
_______________________________________

From report at bugs.python.org  Mon Jul 23 03:56:23 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Jul 2012 01:56:23 +0000
Subject: [issue15232] email.generator.Generator doesn't mangle "From " lines
	in MIME preamble
In-Reply-To: <1341118945.33.0.829442271947.issue15232@psf.upfronthosting.co.za>
Message-ID: <1343008583.12.0.888693362354.issue15232@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Same problem with the epilogue.  Fixed both.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15232>
_______________________________________

From report at bugs.python.org  Mon Jul 23 04:02:16 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 23 Jul 2012 02:02:16 +0000
Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links
In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za>
Message-ID: <1343008936.2.0.778671270735.issue9949@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Yet another patch to support symlink on Windows.

----------
nosy: +ishimoto
Added file: http://bugs.python.org/file26487/issue9949.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9949>
_______________________________________

From report at bugs.python.org  Mon Jul 23 04:33:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Jul 2012 02:33:38 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <3WgRb51Pq8zPCm@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f6ce142c2fce by Senthil Kumaran in branch '3.2':
- Issue #15250: Document that filecmp.dircmp compares files shallowly. Patch contributed by Chris Jerdonek.
http://hg.python.org/cpython/rev/f6ce142c2fce

New changeset d2a49ee77b6f by Senthil Kumaran in branch 'default':
- Issue #15250: Document that filecmp.dircmp compares files shallowly. Patch contributed by Chris Jerdonek.
http://hg.python.org/cpython/rev/d2a49ee77b6f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15250>
_______________________________________

From report at bugs.python.org  Mon Jul 23 04:36:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Jul 2012 02:36:58 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <3WgRfw5jZXzPKt@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3921d3c71e64 by Senthil Kumaran in branch '2.7':
Issue #15250: Document that filecmp.dircmp compares files shallowly. Patch contributed by Chris Jerdonek.
http://hg.python.org/cpython/rev/3921d3c71e64

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15250>
_______________________________________

From report at bugs.python.org  Mon Jul 23 04:39:30 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Jul 2012 02:39:30 +0000
Subject: [issue15430] Improve filecmp documentation
Message-ID: <1343011170.68.0.66414126493.issue15430@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <senthil at uthcode.com>:

filecmp.rst could see some improvements which are easy and useful too. It was discussed in Issue15250 and a patch is attached.

----------
assignee: orsenthil
components: Documentation
files: Issue15250.patch
keywords: easy, patch
messages: 166200
nosy: cjerdonek, orsenthil
priority: normal
severity: normal
stage: patch review
status: open
title: Improve filecmp documentation
type: behavior
Added file: http://bugs.python.org/file26488/Issue15250.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15430>
_______________________________________

From report at bugs.python.org  Mon Jul 23 04:40:23 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Jul 2012 02:40:23 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1343011223.3.0.934558749882.issue15250@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

This is taken care. Rest of documentation improvements could be dealt with in Issue15430. Thanks, Chris.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15250>
_______________________________________

From report at bugs.python.org  Mon Jul 23 04:51:08 2012
From: report at bugs.python.org (Kirubakaran Athmanathan)
Date: Mon, 23 Jul 2012 02:51:08 +0000
Subject: [issue7003] finish documentation of user local paths
In-Reply-To: <1253933860.16.0.325369023174.issue7003@psf.upfronthosting.co.za>
Message-ID: <1343011868.89.0.324806066201.issue7003@psf.upfronthosting.co.za>


Kirubakaran Athmanathan <pybugs at kirubakaran.com> added the comment:

This issue is present only in 3.0 and not in 3.2, 3.3 or 2.7. Since 3.0 is no longer maintained, I hope that this can be closed.


Refer:
http://docs.python.org/dev/library/site.html
http://docs.python.org/release/3.2/library/site.html
http://docs.python.org/release/2.7/library/site.html

----------
nosy: +kirubakaran

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7003>
_______________________________________

From report at bugs.python.org  Mon Jul 23 04:52:14 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Jul 2012 02:52:14 +0000
Subject: [issue7003] finish documentation of user local paths
In-Reply-To: <1253933860.16.0.325369023174.issue7003@psf.upfronthosting.co.za>
Message-ID: <1343011934.78.0.365089822285.issue7003@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7003>
_______________________________________

From report at bugs.python.org  Mon Jul 23 04:53:38 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Jul 2012 02:53:38 +0000
Subject: [issue15350] {urllib,urllib.parse}.urlencode.__doc__ is unclear
In-Reply-To: <1342263934.43.0.385544849615.issue15350@psf.upfronthosting.co.za>
Message-ID: <1343012018.39.0.361015181667.issue15350@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15350>
_______________________________________

From report at bugs.python.org  Mon Jul 23 05:16:43 2012
From: report at bugs.python.org (Kirubakaran Athmanathan)
Date: Mon, 23 Jul 2012 03:16:43 +0000
Subject: [issue7578] Behavior of operations on a closed file object is not
	documented correctly
In-Reply-To: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>
Message-ID: <1343013403.62.0.398917478066.issue7578@psf.upfronthosting.co.za>


Kirubakaran Athmanathan <pybugs at kirubakaran.com> added the comment:

Looks like this was fixed in 3.3 in the commit 72890:a22d94547570 Should this issue be closed?

----------
nosy: +kirubakaran

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7578>
_______________________________________

From report at bugs.python.org  Mon Jul 23 05:58:05 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 03:58:05 +0000
Subject: [issue15250] document that filecmp.dircmp comparisons are "shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1343015885.97.0.52330063955.issue15250@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks a lot for committing this for me Senthil.  And thanks also for creating a separate issue for the other changes.  I appreciate it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15250>
_______________________________________

From report at bugs.python.org  Mon Jul 23 06:18:44 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 04:18:44 +0000
Subject: [issue15430] Improve filecmp documentation
In-Reply-To: <1343011170.68.0.66414126493.issue15430@psf.upfronthosting.co.za>
Message-ID: <1343017124.92.0.445325806861.issue15430@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Some comments on the patch:

+   The buffer size value which will be used to read the file contents. Defaults
+   to 8192 bytes.

I would consider including the units for the value here (e.g. "The buffer
size value in bytes...").

+   When *shallow* flag is set to False, :data:`filecmp.BUFSIZE` bytes of file
+   content will be read and compared.

Should this instead read something like, "When the *shallow* flag is set to
False, the file contents will be read and compared, reading
:data:`filecmp.BUFSIZE` bytes at a time."  The current wording suggests
that only the first BUFSIZE bytes will be looked at.

+   The :class:`dircmp` class compares files by doing *shallow* comparisons as
+   described for :func:`filecmp.cmp`.

This change was already committed as part of issue 15250.

+   The :class:`dircmp` class offers a number of interesting attributes that may
+   be used to get various bits of information about the directory trees being

This change was already committed as part of issue 15250.

    .. attribute:: common_dirs

-      Subdirectories in both *a* and *b*.
+      Subdirectories in both *dir1* and *dir2*, using the class's file
+      comparison operator.

The phrase "using the class's file comparison operator" should not be added
to common_dirs.  common_dirs does not look at file contents.

    .. attribute:: common_files

-      Files in both *a* and *b*
+      Files in both *dir1* and *dir2*, whose contents differ according to the
+      class's file comparison operator.

The phrase "whose contents differ according to the class's file comparison
operator" should not be added to common_files.  common_files does not look
at file contents.

    .. attribute:: same_files

-      Files which are identical in both *a* and *b*.
+      Files which are identical in both *dir1* and *dir2*.

This line should reflect the change committed for issue 15250.

    .. attribute:: diff_files

-      Files which are in both *a* and *b*, whose contents differ.
+      Files which are in both *dir1* and *dir2*, whose contents differ.

This line should reflect the change committed for issue 15250.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15430>
_______________________________________

From report at bugs.python.org  Mon Jul 23 06:33:01 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 23 Jul 2012 04:33:01 +0000
Subject: [issue13252] new decumulate() function in itertools module
In-Reply-To: <1319409168.22.0.462760902888.issue13252@psf.upfronthosting.co.za>
Message-ID: <1343017981.84.0.457857191833.issue13252@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13252>
_______________________________________

From report at bugs.python.org  Mon Jul 23 06:40:47 2012
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 23 Jul 2012 04:40:47 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343018447.79.0.609374564324.issue14578@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I'm not sure what the deal is but I can't get the changes to apply (fitting Amaury's patch into _boostrap.py), meaning nothing I change to the _boostrap.py file changes how anything operates.

I don't have much time to learn all of this stuff and make it work on Windows like the build process does on Linux, especially not with a release waiting for it. I'd just say to run without it until someone who needs it has time to fiddle around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Mon Jul 23 06:56:03 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 04:56:03 +0000
Subject: [issue15376] Refactor the test_runpy walk_package support code into a
	common location
In-Reply-To: <1342509049.53.0.303616016829.issue15376@psf.upfronthosting.co.za>
Message-ID: <1343019363.13.0.374744497293.issue15376@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I created issue 15415 and uploaded a patch there with this issue in mind.

test_runpy contains supporting _make_pkg() and _del_pkg() methods that,
among other things, create and delete a temp directory.  That logic
would be better handled by a temp directory context manager.

The patch uploaded to issue 15415 creates such a context manager and
also unit-tests it.  It also reduces the duplication of temp
directory logic between test/script_helper.py and test/support.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15376>
_______________________________________

From report at bugs.python.org  Mon Jul 23 08:06:08 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Jul 2012 06:06:08 +0000
Subject: [issue15295] Document PEP 420 namespace packages
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343023568.2.0.0418648401662.issue15295@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +larry, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Mon Jul 23 08:07:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Jul 2012 06:07:25 +0000
Subject: [issue15295] Document PEP 420 namespace packages
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343023645.07.0.101954769419.issue15295@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

>From the import-sig discussions, this wasn't just about documenting PEP 420, it was about finally bringing the full import system specification into the language reference. (Now that it doesn't need to be loaded with caveats about the old default import mechanisms)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Mon Jul 23 08:21:50 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 23 Jul 2012 06:21:50 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
Message-ID: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

On Windows, the _freeze_importlib tool is not built, so it's not possible to refresh the file Python/importlib.h, which makes development on the importlib very difficult on Windows.

The Makefile contains the rules below, it's probably necessary to implement a similar behavior in a new build project:

Modules/_freeze_importlib: Modules/_freeze_importlib.o $(LIBRARY_OBJS_OMIT_FROZEN)
	$(LINKCC) $(PY_LDFLAGS) -o $@ Modules/_freeze_importlib.o $(LIBRARY_OBJS_OMIT_FROZEN) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)

Python/importlib.h: $(srcdir)/Lib/importlib/_bootstrap.py Modules/_freeze_importlib.c
	$(MAKE) Modules/_freeze_importlib
	./Modules/_freeze_importlib \
		$(srcdir)/Lib/importlib/_bootstrap.py Python/importlib.h

----------
components: Build, Windows
messages: 166209
nosy: amaury.forgeotdarc, brian.curtin
priority: high
severity: normal
status: open
title: Cannot build importlib.h on Windows
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Mon Jul 23 08:22:45 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 23 Jul 2012 06:22:45 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343024565.44.0.0030727089243.issue14578@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

importlib.h is not rebuilt on Windows, see issue15431.

----------
dependencies: +Cannot build importlib.h on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Mon Jul 23 09:29:23 2012
From: report at bugs.python.org (Christopher Dunn)
Date: Mon, 23 Jul 2012 07:29:23 +0000
Subject: [issue5819] Add PYTHONPREFIXES environment variable
In-Reply-To: <1240475142.53.0.423262271042.issue5819@psf.upfronthosting.co.za>
Message-ID: <1343028563.92.0.0331828918454.issue5819@psf.upfronthosting.co.za>


Christopher Dunn <cdunn2001 at gmail.com> added the comment:

I agree. venv solves this problem and more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5819>
_______________________________________

From report at bugs.python.org  Mon Jul 23 10:09:50 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 23 Jul 2012 08:09:50 +0000
Subject: [issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2
In-Reply-To: <1342799760.81.0.0479132559422.issue15408@psf.upfronthosting.co.za>
Message-ID: <1343030990.4.0.0122007645227.issue15408@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

In Python 2.x, when the file object returned by popen() is garbage collected the process is automatically waited on, collecting the pid of the process.

In Python 3.x a wrapper object is used whose close method wait on the pid.  This close method is *not* invoked when the wrapper is garbage collected.  However, the set of dead pids cannot accumulate since dead pids get collected whenever os.popen()/subprocess.Popen() is used.

The old behaviour is only an advantage in a refcounted implementation of Python like CPython.  I am not sure that "fixing" the current behaviour is necessary.

Simply adding to the wrapper class a __del__() method which invokes close() will not work.  (One could instead use a weakref callback, but that is non-trivial.)

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15408>
_______________________________________

From report at bugs.python.org  Mon Jul 23 10:13:25 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 23 Jul 2012 08:13:25 +0000
Subject: [issue13837] test_shutil fails with symlinks enabled under Windows
In-Reply-To: <1327255807.39.0.63998442373.issue13837@psf.upfronthosting.co.za>
Message-ID: <1343031205.12.0.637462747879.issue13837@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Error in test_move_dangling_symlink is fixed by #9949

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13837>
_______________________________________

From report at bugs.python.org  Mon Jul 23 11:29:31 2012
From: report at bugs.python.org (Geir Ove Myhr)
Date: Mon, 23 Jul 2012 09:29:31 +0000
Subject: [issue15432] gzip.py: mtime argument only since python 2.7
Message-ID: <1343035771.6.0.0683574772688.issue15432@psf.upfronthosting.co.za>


New submission from Geir Ove Myhr <gomyhr at gmail.com>:

In the gzip documentation (http://docs.python.org/library/gzip.html) a note should be added that the mtime option was added in Python 2.7. 

The patch which adds the option (http://svn.python.org/view?view=revision&revision=68319) is not included in Python 2.6.5.

----------
assignee: docs at python
components: Documentation
messages: 166214
nosy: docs at python, gomyhr
priority: normal
severity: normal
status: open
title: gzip.py: mtime argument only since python 2.7
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15432>
_______________________________________

From report at bugs.python.org  Mon Jul 23 11:32:27 2012
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Mon, 23 Jul 2012 09:32:27 +0000
Subject: [issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2
In-Reply-To: <1342799760.81.0.0479132559422.issue15408@psf.upfronthosting.co.za>
Message-ID: <1343035947.44.0.665536222712.issue15408@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

So is this simply a documentation issue, or can we close the bug as "won't fix"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15408>
_______________________________________

From report at bugs.python.org  Mon Jul 23 11:42:10 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Jul 2012 09:42:10 +0000
Subject: [issue7578] Behavior of operations on a closed file object is not
	documented correctly
In-Reply-To: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>
Message-ID: <1343036530.54.0.109453133209.issue7578@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7578>
_______________________________________

From report at bugs.python.org  Mon Jul 23 11:48:38 2012
From: report at bugs.python.org (Reinis Ivanovs)
Date: Mon, 23 Jul 2012 09:48:38 +0000
Subject: [issue15433] argparse usage line is wrong
Message-ID: <1343036918.13.0.713633576876.issue15433@psf.upfronthosting.co.za>


New submission from Reinis Ivanovs <dabas at untu.ms>:

I set a positional argument and an optional argument that accepts a list:

> parser = argparse.ArgumentParser()
> parser.add_argument('foo')
> parser.add_argument('-bar', nargs='*')

The usage line I get from --help is this:

> $ example.py --help
> usage: example.py [-h] [-bar [BAR [BAR ...]]] foo

Trying to actually follow the usage instructions produces this error:

> $ example.py -bar x y z
> error: too few arguments

Reversing the argument order works however:

> $ example.py z -bar x y

So the usage instructions are clearly wrong.

----------
components: Library (Lib)
messages: 166217
nosy: reinis
priority: normal
severity: normal
status: open
title: argparse usage line is wrong
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15433>
_______________________________________

From report at bugs.python.org  Mon Jul 23 12:18:04 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Jul 2012 10:18:04 +0000
Subject: [issue15434] __import__() problem in 3.3
Message-ID: <1343038684.54.0.966180035561.issue15434@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Using b127046831e2, I'm experiencing an import problem during the NumPy build.

I've reduced it to this scenario, which works in 3.2 but not in 3.3.
Note that in NumPy's setup.py, the equivalent of /home/stefan/tmp is 
the first entry in sys.path. I'm not sure if this isolated example is 
terribly useful:


$ pwd
/home/stefan/tmp
$ ls distutils/command/
__init__.py  xyz.py
$ cat distutils/command/__init__.py

distutils_all = ['xyz']
__import__('distutils.command',globals(),locals(),distutils_all)

$ cat distutils/command/xyz.py
$
$ python3.2 distutils/command/__init__.py
$
$ /home/stefan/usr/bin/python3.3 distutils/command/__init__.py
Traceback (most recent call last):
  File "distutils/command/__init__.py", line 3, in <module>
    __import__('distutils.command',globals(),locals(),distutils_all)
ImportError: No module named 'distutils.command.xyz'
$

----------
components: Interpreter Core
messages: 166218
nosy: brett.cannon, pitrou, skrah
priority: high
severity: normal
status: open
title: __import__() problem in 3.3
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15434>
_______________________________________

From report at bugs.python.org  Mon Jul 23 13:02:12 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Jul 2012 11:02:12 +0000
Subject: [issue15434] __import__() problem in 3.3
In-Reply-To: <1343038684.54.0.966180035561.issue15434@psf.upfronthosting.co.za>
Message-ID: <1343041332.67.0.879140505618.issue15434@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

It looks like distutils/command from the stdlib is searched first
despite the fact that the first path entry is '/home/stefan/tmp'.

If distutils/command is replaced with a/b, the import works:

$ pwd
/home/stefan/tmp
$ 
$ ls a/b/
__init__.py  xyz.py
$ ls distutils/command/
__init__.py  xyz.py
$ 
$ cat a/b/__init__.py 

import sys
sys.path.insert(0, '/home/stefan/tmp')
print(sys.path)

distutils_all = ['xyz']
__import__('a.b',globals(),locals(),distutils_all)


$ cat distutils/command/__init__.py 

import sys
sys.path.insert(0, '/home/stefan/tmp')
print(sys.path)

distutils_all = ['xyz']
__import__('distutils.command',globals(),locals(),distutils_all)



$ /home/stefan/usr/bin/python3.3 a/b/__init__.py 
['/home/stefan/tmp', '/home/stefan/tmp/a/b', '/home/stefan/usr/lib/python33.zip', '/home/stefan/usr/lib/python3.3', '/home/stefan/usr/lib/python3.3/plat-linux', '/home/stefan/usr/lib/python3.3/lib-dynload', '/home/stefan/.local/lib/python3.3/site-packages', '/home/stefan/usr/lib/python3.3/site-packages']
['/home/stefan/tmp', '/home/stefan/tmp', '/home/stefan/tmp/a/b', '/home/stefan/usr/lib/python33.zip', '/home/stefan/usr/lib/python3.3', '/home/stefan/usr/lib/python3.3/plat-linux', '/home/stefan/usr/lib/python3.3/lib-dynload', '/home/stefan/.local/lib/python3.3/site-packages', '/home/stefan/usr/lib/python3.3/site-packages']



$ /home/stefan/usr/bin/python3.3 distutils/command/__init__.py 
['/home/stefan/tmp', '/home/stefan/tmp/distutils/command', '/home/stefan/usr/lib/python33.zip', '/home/stefan/usr/lib/python3.3', '/home/stefan/usr/lib/python3.3/plat-linux', '/home/stefan/usr/lib/python3.3/lib-dynload', '/home/stefan/.local/lib/python3.3/site-packages', '/home/stefan/usr/lib/python3.3/site-packages']
Traceback (most recent call last):
  File "distutils/command/__init__.py", line 7, in <module>
    __import__('distutils.command',globals(),locals(),distutils_all)
ImportError: No module named 'distutils.command.xyz'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15434>
_______________________________________

From report at bugs.python.org  Mon Jul 23 13:06:54 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 23 Jul 2012 11:06:54 +0000
Subject: [issue15434] __import__() problem in 3.3
In-Reply-To: <1343038684.54.0.966180035561.issue15434@psf.upfronthosting.co.za>
Message-ID: <1343041614.25.0.685852069805.issue15434@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/issue15434>
_______________________________________

From report at bugs.python.org  Mon Jul 23 14:01:14 2012
From: report at bugs.python.org (Bertrand Croq)
Date: Mon, 23 Jul 2012 12:01:14 +0000
Subject: [issue4713] Installing sgmlop causes xmlrpclib error
In-Reply-To: <1229895007.0.0.481278630748.issue4713@psf.upfronthosting.co.za>
Message-ID: <1343044874.07.0.907843798186.issue4713@psf.upfronthosting.co.za>


Bertrand Croq <bertrand.croq at gmail.com> added the comment:

This bug still present in Python 2.7, the proposed patch works.

----------
nosy: +bcroq

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4713>
_______________________________________

From report at bugs.python.org  Mon Jul 23 14:43:45 2012
From: report at bugs.python.org (Jeremy Hylton)
Date: Mon, 23 Jul 2012 12:43:45 +0000
Subject: [issue11549] Build-out an AST optimizer,
	moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1343047425.99.0.67691674175.issue11549@psf.upfronthosting.co.za>


Changes by Jeremy Hylton <jhylton at gmail.com>:


----------
nosy: +Jeremy.Hylton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Mon Jul 23 15:27:20 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 23 Jul 2012 13:27:20 +0000
Subject: [issue15424] __sizeof__ of array should include size of items
In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za>
Message-ID: <1343050040.03.0.990988109749.issue15424@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

With the precedent of issue #15402, I think that 2.7 and 3.2 should be fine.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15424>
_______________________________________

From report at bugs.python.org  Mon Jul 23 16:28:26 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 23 Jul 2012 14:28:26 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343053706.44.0.448046357378.issue15431@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Mon Jul 23 16:36:33 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 23 Jul 2012 14:36:33 +0000
Subject: [issue15434] __import__() problem in 3.3
In-Reply-To: <1343038684.54.0.966180035561.issue15434@psf.upfronthosting.co.za>
Message-ID: <1343054193.74.0.427398134576.issue15434@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15434>
_______________________________________

From report at bugs.python.org  Mon Jul 23 16:43:50 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 Jul 2012 14:43:50 +0000
Subject: [issue15434] __import__() problem in 3.3
In-Reply-To: <1343038684.54.0.966180035561.issue15434@psf.upfronthosting.co.za>
Message-ID: <1343054630.74.0.606739905259.issue15434@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Could you explain what is it you?re trying to achieve?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15434>
_______________________________________

From report at bugs.python.org  Mon Jul 23 16:47:09 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 23 Jul 2012 14:47:09 +0000
Subject: [issue15433] argparse usage line is wrong
In-Reply-To: <1343036918.13.0.713633576876.issue15433@psf.upfronthosting.co.za>
Message-ID: <1343054829.22.0.37255135811.issue15433@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


----------
nosy: +anton.barkovsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15433>
_______________________________________

From report at bugs.python.org  Mon Jul 23 16:47:35 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 23 Jul 2012 14:47:35 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343054855.64.0.636131667946.issue14578@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I just wanted to say that Amaury's proof-of-concept looks right (although what is returned by the registry isn't a "fullname" but a file path so I would at least change that variable name and you wouldn't append this mat path finder but instead insert it before PathFinder).

And to answer the question of what to pass in, technically it's the tail part of the name for full backwards-compatibility, but that's stupid as it creates an ambiguity e.g. a package named foo vs. a submodule named pkg.foo, so I say use the full name of the module when looking something up in the registry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Mon Jul 23 16:54:16 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Jul 2012 14:54:16 +0000
Subject: [issue15434] __import__() problem in 3.3
In-Reply-To: <1343038684.54.0.966180035561.issue15434@psf.upfronthosting.co.za>
Message-ID: <1343055256.63.0.380474409678.issue15434@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This is not a distutils issue. I want to know why this does not
throw an exception ...

python3.2 distutils/command/__init__.py


... while this raises ImportError:

~/usr/bin/python3.3 distutils/command/__init__.py



For the path structure please see my previous message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15434>
_______________________________________

From report at bugs.python.org  Mon Jul 23 17:06:01 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 23 Jul 2012 15:06:01 +0000
Subject: [issue15434] __import__() problem in 3.3
In-Reply-To: <1343038684.54.0.966180035561.issue15434@psf.upfronthosting.co.za>
Message-ID: <1343055961.86.0.604488381474.issue15434@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It might be a runpy thing as Nick has been tweaking that lately to deal with pkgutil issues.

And this is of course ignoring the fact that __import__ should never be called directly over importlib.import_module().

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15434>
_______________________________________

From report at bugs.python.org  Mon Jul 23 17:20:46 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 23 Jul 2012 15:20:46 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343056846.28.0.125000599456.issue15402@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

OK, I will commit this sometime today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Mon Jul 23 17:23:42 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 15:23:42 +0000
Subject: [issue15434] __import__() problem in 3.3
In-Reply-To: <1343038684.54.0.966180035561.issue15434@psf.upfronthosting.co.za>
Message-ID: <1343057022.99.0.237164615543.issue15434@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15434>
_______________________________________

From report at bugs.python.org  Mon Jul 23 17:25:46 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Jul 2012 15:25:46 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <3Wgmk05zy9zPRt@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset dbe7f39ff341 by Meador Inge in branch '2.7':
Issue #15402: Add a __sizeof__ method to struct.Struct.
http://hg.python.org/cpython/rev/dbe7f39ff341

New changeset 3e7b517e1b68 by Meador Inge in branch '3.2':
Issue #15402: Add a __sizeof__ method to struct.Struct.
http://hg.python.org/cpython/rev/3e7b517e1b68

New changeset 03063e718f5f by Meador Inge in branch 'default':
Issue #15402: Add a __sizeof__ method to struct.Struct.
http://hg.python.org/cpython/rev/03063e718f5f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Mon Jul 23 17:26:48 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 23 Jul 2012 15:26:48 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343057208.93.0.722368899169.issue15402@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Thanks for the patch Serhiy!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Mon Jul 23 17:27:14 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 15:27:14 +0000
Subject: [issue15433] argparse usage line is wrong
In-Reply-To: <1343036918.13.0.713633576876.issue15433@psf.upfronthosting.co.za>
Message-ID: <1343057234.81.0.157676492334.issue15433@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15433>
_______________________________________

From report at bugs.python.org  Mon Jul 23 17:37:01 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 23 Jul 2012 15:37:01 +0000
Subject: [issue15417] Add support for csh and fish in venv activation scripts
In-Reply-To: <1342915589.34.0.636198771973.issue15417@psf.upfronthosting.co.za>
Message-ID: <1343057821.86.0.596881842962.issue15417@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I have no objection in principle to supporting additional shells, but do have the following comments/questions:

1. Georg feels that this is a new feature he doesn't want to add to 3.3. IMO we have to respect his judgement as RM, no matter how trivial the change might seem. It's more about the discipline of the process than it is about any one specific change.

2. Where do we draw the line in terms of support for ("arbitrary") shells? Each activation script will potentially need maintenance into the future. It was originally envisaged that the stdlib code would add minimal support for activation scripts and that third-party tools would add support for additional shells and other value-adding features. The venv API design was intended to facilitate usage by third-party code.

----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15417>
_______________________________________

From report at bugs.python.org  Mon Jul 23 17:44:38 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 23 Jul 2012 15:44:38 +0000
Subject: [issue15424] __sizeof__ of array should include size of items
In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za>
Message-ID: <1343058278.97.0.334152260163.issue15424@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +meador.inge
versions: +Python 3.2 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15424>
_______________________________________

From report at bugs.python.org  Mon Jul 23 17:52:34 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Jul 2012 15:52:34 +0000
Subject: [issue15434] __import__() problem in 3.3
In-Reply-To: <1343038684.54.0.966180035561.issue15434@psf.upfronthosting.co.za>
Message-ID: <1343058754.54.0.929461822705.issue15434@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Argh. __init__.py was missing in the top directory. For some reason
Python 3.2 does not throw the error. Also, 3.3 does not raise in the
case of the a/b directory structure:

$ tree a
a
`-- b
    |-- __init__.py
    `-- xyz.py

$ ~/usr/bin/python3.3 a/b/__init__.py               
['/home/stefan/tmp', '/home/stefan/tmp/a/b', '/home/stefan/usr/lib/python33.zip', '/home/stefan/usr/lib/python3.3', '/home/stefan/usr/lib/python3.3/plat-linux', '/home/stefan/usr/lib/python3.3/lib-dynload', '/home/stefan/.local/lib/python3.3/site-packages', '/home/stefan/usr/lib/python3.3/site-packages']


With the added __init__.py, also the (fake) distutils package is OK:


$ tree distutils/
distutils/
|-- __init__.py
`-- command
    |-- __init__.py
    `-- xyz.py


$ ~/usr/bin/python3.3 distutils/command/__init__.py
['/home/stefan/tmp', '/home/stefan/tmp/distutils/command', '/home/stefan/usr/lib/python33.zip', '/home/stefan/usr/lib/python3.3', '/home/stefan/usr/lib/python3.3/plat-linux', '/home/stefan/usr/lib/python3.3/lib-dynload', '/home/stefan/.local/lib/python3.3/site-packages', '/home/stefan/usr/lib/python3.3/site-packages']




Brett, if this all looks good to you, this issue can be closed. The
original NumPy build error must be due to something else.

Perhaps 3.3 should raise in the a/b case, too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15434>
_______________________________________

From report at bugs.python.org  Mon Jul 23 18:16:26 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 23 Jul 2012 16:16:26 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343060186.42.0.887357326987.issue15402@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

We collide mid-air, Meador. I was just checking-in this :-). I have changed the tests to actually verify the changes :-). Also added to "Doc/ACKS.txt".

Could I suggest you to take care of issue #15424 too?.

----------
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Mon Jul 23 18:17:21 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Jul 2012 16:17:21 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <3WgnsX3YqnzPRh@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b1d85a44f149 by Jesus Cea in branch '2.7':
Better test for Issue #15402: Add a __sizeof__ method to struct.Struct
http://hg.python.org/cpython/rev/b1d85a44f149

New changeset 1911e192af0d by Jesus Cea in branch '3.2':
Better test for Issue #15402: Add a __sizeof__ method to struct.Struct
http://hg.python.org/cpython/rev/1911e192af0d

New changeset b9a3ed1b14b9 by Jesus Cea in branch 'default':
MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct
http://hg.python.org/cpython/rev/b9a3ed1b14b9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Mon Jul 23 18:20:52 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 23 Jul 2012 16:20:52 +0000
Subject: [issue15417] Add support for csh and fish in venv activation scripts
In-Reply-To: <1342915589.34.0.636198771973.issue15417@psf.upfronthosting.co.za>
Message-ID: <1343060452.42.0.570218442662.issue15417@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

1. I agree with you about exclusion from 3.3.

2. Hmm. Good question. For now virtualenv has support for cmd.exe, csh, fish, bash/zsh and PowerShell.
I propose to add csh and fish to venv too. 
If later somebody will push request for adding yet another shell support we can consider it. Personally I doubt if we will see many requests for that.

3. Which standard way to append new activation script in third-party tool? I see th only way: inherit from `venv.EnvBuilder` and override `setup_scripts` method pointing to new directory with desired activators as `path` parameter for `self.install_scripts(...)`.
Also that third-party tool have to reimplement functionality of `create` and `main` functions with setting up ArgumentParser. Doesn't look like trivial steps if you wish to just add single activation script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15417>
_______________________________________

From report at bugs.python.org  Mon Jul 23 18:26:53 2012
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Mon, 23 Jul 2012 16:26:53 +0000
Subject: [issue15435] Strange behavior when AttributeError raise inside a
	property get function
Message-ID: <1343060813.45.0.564529215103.issue15435@psf.upfronthosting.co.za>


New submission from C?dric Krier <cedric.krier at b2ck.com>:

When a AttributeError is raised inside the get function of a property and if the class has a __getattr__ method defined then this method is called.
It is strange behavior because when looking at the traceback it looks like Python doesn't find the property.

----------
components: Interpreter Core
files: test.py
messages: 166234
nosy: ced
priority: normal
severity: normal
status: open
title: Strange behavior when AttributeError raise inside a property get function
type: behavior
Added file: http://bugs.python.org/file26489/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15435>
_______________________________________

From report at bugs.python.org  Mon Jul 23 18:29:23 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 23 Jul 2012 16:29:23 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343060963.51.0.258087014727.issue15402@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Hi Jes?s,

I replied to python-dev, but the Doc/ACKS.txt changes aren't necessary and I was OK with the way Serhiy submitted the tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Mon Jul 23 18:37:12 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 23 Jul 2012 16:37:12 +0000
Subject: [issue15417] Add support for csh and fish in venv activation scripts
In-Reply-To: <1342915589.34.0.636198771973.issue15417@psf.upfronthosting.co.za>
Message-ID: <1343061432.62.0.865407978228.issue15417@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> inherit from `venv.EnvBuilder` and override `setup_scripts` method
> pointing to new directory with desired activators as `path` parameter
> for `self.install_scripts(...)`.

Yes, that's it. A third party tool would potentially do more than just custom scripts, and would presumably have its own command line parameters and handling code, reflecting the features it offers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15417>
_______________________________________

From report at bugs.python.org  Mon Jul 23 18:46:01 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 16:46:01 +0000
Subject: [issue15433] argparse usage line is wrong
In-Reply-To: <1343036918.13.0.713633576876.issue15433@psf.upfronthosting.co.za>
Message-ID: <1343061961.63.0.959876522163.issue15433@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


----------
resolution:  -> duplicate
superseder:  -> argparse optionals with nargs='+' can't be followed by positionals

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15433>
_______________________________________

From report at bugs.python.org  Mon Jul 23 18:46:08 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 16:46:08 +0000
Subject: [issue15433] argparse usage line is wrong
In-Reply-To: <1343036918.13.0.713633576876.issue15433@psf.upfronthosting.co.za>
Message-ID: <1343061968.49.0.586583708233.issue15433@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15433>
_______________________________________

From report at bugs.python.org  Mon Jul 23 18:57:36 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 16:57:36 +0000
Subject: [issue9338] argparse optionals with nargs='?',
	'*' or '+' can't be followed by positionals
In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za>
Message-ID: <1343062656.57.0.954605325792.issue9338@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

So Kotan's patch doesn't actually solve the original problem. Instead, it inserts the workaround into the help message of the parser. I think this is probably not the right fix. We should probably do two things:

(1) Right now: create a documentation patch which at least explains the current limitations of argparse parsing, and describes the '--' workaround. Probably this patch should add a separate section about '--', give an example like the one in this issue, and then cross-reference this section from nargs='?', nargs='*', nargs='+' and the "Arguments containing -" section.

(2) Longer term: create a code patch that implements the changes to the regular expression-based parsing like I've suggested.

----------
title: argparse optionals with nargs='+' can't be followed by positionals -> argparse optionals with nargs='?', '*' or '+' can't be followed by positionals

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9338>
_______________________________________

From report at bugs.python.org  Mon Jul 23 18:59:26 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 23 Jul 2012 16:59:26 +0000
Subject: [issue15434] __import__() problem in 3.3
In-Reply-To: <1343038684.54.0.966180035561.issue15434@psf.upfronthosting.co.za>
Message-ID: <1343062766.36.0.470254356819.issue15434@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The a/b case is legitimate in Python 3.3; namespace packages are delineated by not defining an __init__.py file. Closing as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15434>
_______________________________________

From report at bugs.python.org  Mon Jul 23 19:04:08 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 17:04:08 +0000
Subject: [issue9338] argparse optionals with nargs='?',
	'*' or '+' can't be followed by positionals
In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za>
Message-ID: <1343063048.39.0.276648378149.issue9338@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

And I guess Issue 9182 is the right place for (1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9338>
_______________________________________

From report at bugs.python.org  Mon Jul 23 19:28:56 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 23 Jul 2012 17:28:56 +0000
Subject: [issue11466] getpass.getpass doesn't close tty file
In-Reply-To: <1299844492.32.0.259676792362.issue11466@psf.upfronthosting.co.za>
Message-ID: <1343064536.47.0.904244336493.issue11466@psf.upfronthosting.co.za>


Anton Barkovsky <swarmer.pm at gmail.com> added the comment:

The issue is still there. I hope someone fixes it before the release.

----------
nosy: +anton.barkovsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11466>
_______________________________________

From report at bugs.python.org  Mon Jul 23 19:31:57 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Jul 2012 17:31:57 +0000
Subject: [issue15295] Document PEP 420 namespace packages
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343064717.17.0.475405334811.issue15295@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/issue15295>
_______________________________________

From report at bugs.python.org  Mon Jul 23 19:51:44 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Jul 2012 17:51:44 +0000
Subject: [issue15435] Strange behavior when AttributeError raise inside a
	property get function
In-Reply-To: <1343060813.45.0.564529215103.issue15435@psf.upfronthosting.co.za>
Message-ID: <1343065904.36.0.472553536462.issue15435@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

AttributeError is how Python decides that __getattr__ should be called.  I believe this is working as designed.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15435>
_______________________________________

From report at bugs.python.org  Mon Jul 23 20:20:41 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 23 Jul 2012 18:20:41 +0000
Subject: [issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2
In-Reply-To: <1342799760.81.0.0479132559422.issue15408@psf.upfronthosting.co.za>
Message-ID: <1343067641.07.0.697106944777.issue15408@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

A program which depends on the old behaviour would be broken on a non-refcounted implementation of Python, so I would be inclined to say "won't fix".

However, I think the following patch would restore the old behaviour

diff -r a970054a93fb Lib/os.py
--- a/Lib/os.py	Mon Jul 16 18:30:03 2012 +0100
+++ b/Lib/os.py	Mon Jul 23 19:12:38 2012 +0100
@@ -1004,6 +1004,13 @@
 # Helper for popen() -- a proxy for a file whose close waits for the process
 class _wrap_close:
     def __init__(self, stream, proc):
+        # proc should be waited on when stream is garbage collected
+        import weakref
+        def callback(wr):
+            proc._weakref = None           # break ref cycle
+            proc.wait()
+        proc._weakref = weakref.ref(stream, callback)
+        proc.stdin = proc.stdout = None    # proc must not keep stream alive
         self._stream = stream
         self._proc = proc
     def close(self):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15408>
_______________________________________

From report at bugs.python.org  Mon Jul 23 20:44:04 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 18:44:04 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1343069044.46.0.343941001411.issue9182@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Ok, here's what I think needs to go into the documentation here:

(1) Add a separate section to the argparse docs about '--'. Give examples like the ones in this issue, and show how '--' can solve them

(2) Cross-reference the section on '--' from nargs='?', nargs='*', nargs='+' and the "Arguments containing -" sections (and any other places where people are likely to run into the need for '--').

All of these changes should be on Doc/library/argparse.rst - I don't think we want to change the code at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Mon Jul 23 21:15:32 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 19:15: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: <1343070932.2.0.819384158547.issue13249@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I've updated the patch for the current trunk. Should be ready to commit.

----------
Added file: http://bugs.python.org/file26490/Issue13249-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Mon Jul 23 21:54:42 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Jul 2012 19:54:42 +0000
Subject: [issue15436] __sizeof__ is not documeneted
Message-ID: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

__sizeof__ is not mentioned on page Doc/reference/datamodel.rst together with other special methods. There is no __sizeof__ in index.

----------
assignee: docs at python
components: Documentation
messages: 166245
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: __sizeof__ is not documeneted
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Mon Jul 23 21:55:30 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 19:55:30 +0000
Subject: [issue12932] filecmp.dircmp does not allow non-shallow comparisons
In-Reply-To: <1315411296.33.0.213336425163.issue12932@psf.upfronthosting.co.za>
Message-ID: <1343073330.22.0.894864383881.issue12932@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Allowing dircmp() to accept a file comparison function is another option to consider that may address more needs going forward.  shallow=False could be achieved by passing lambda a, b: filecmp.cmp(a, b, shallow=False).

----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12932>
_______________________________________

From report at bugs.python.org  Mon Jul 23 21:57:46 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Jul 2012 19:57:46 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343073466.16.0.0508588201421.issue15436@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
title: __sizeof__ is not documeneted -> __sizeof__ is not documented

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Mon Jul 23 22:07:34 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 20:07:34 +0000
Subject: [issue15437] Merge Doc/ACKS and Misc/ACKS
Message-ID: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to merge the Doc/ACKS and Misc/ACKS files as discussed here:

http://mail.python.org/pipermail/python-dev/2012-July/121096.html

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166247
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: Merge Doc/ACKS and Misc/ACKS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Mon Jul 23 22:32:39 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 20:32:39 +0000
Subject: [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343075559.71.0.591845961914.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I would be happy to prepare a patch.  I can upload a script to this issue that the committer can then run on the latest Misc/ACKS and Doc/ACKS.txt.

The script would preserve the ordering of Misc/ACKS.  It would iterate through the names in Doc/ACKS.txt and insert them in Misc/ACKS at the appropriate location.  Duplicates would not be inserted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Mon Jul 23 22:41:37 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Jul 2012 20:41:37 +0000
Subject: [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343076097.07.0.198453769504.issue15437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Georg, do you think this is ok for all 3 branches?

----------
nosy: +georg.brandl, pitrou
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 00:04:40 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 23 Jul 2012 22:04:40 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343081080.22.0.482978892407.issue15402@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch that Meador committed is incorrect: METH_NOARGS functions still take a PyObject* args argument, which will be NULL. I'm puzzled, as Serhiy's original patch was correct.

As for the tests, I really wish there were tests that tested for *actual* values.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Tue Jul 24 00:29:30 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 Jul 2012 22:29:30 +0000
Subject: [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343082570.16.0.206887414404.issue15437@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This was indeed proposed once or twice before; I can?t search my archive right now but I think I remember Georg saying that he was OK as long as the docs displayed Misc/ACKS.  This means checking the rst syntax of Misc/ACKS and using the right include directive.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 00:29:49 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 23 Jul 2012 22:29:49 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343082589.26.0.653677247953.issue15402@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Also, I wonder why this loops over s_codes, instead of just looking at s_len+1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Tue Jul 24 01:10:01 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 23 Jul 2012 23:10:01 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343085001.32.0.00108272866133.issue15436@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Could you possibly write a patch for 2.7, 3.2 and 3.3?

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Tue Jul 24 01:12:15 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 23 Jul 2012 23:12:15 +0000
Subject: [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343085135.56.0.549387002474.issue15437@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/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 01:15:00 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 23 Jul 2012 23:15:00 +0000
Subject: [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343085300.17.0.0764206448669.issue15437@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 01:44:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Jul 2012 23:44:31 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>
Message-ID: <1343087071.97.0.307423067528.issue12428@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why does the pure Python version of partial have to be so complicated?
I don't think the __class__, __setattr__ and __delattr__ are useful. As Raymond said, only the core, documented functionality needs to be preserved, not implementation details.

Something else:

-    from _thread import allocate_lock as Lock
+    from thread import allocate_lock as Lock

The module is named _thread in 3.x, so this shouldn't have been changed (but admittedly it's thread in 2.x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12428>
_______________________________________

From report at bugs.python.org  Tue Jul 24 02:04:54 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 24 Jul 2012 00:04:54 +0000
Subject: [issue11824] freeze.py broken due to ABI flags
In-Reply-To: <1302488520.76.0.698152823885.issue11824@psf.upfronthosting.co.za>
Message-ID: <1343088294.28.0.753769778372.issue11824@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Ping!

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11824>
_______________________________________

From report at bugs.python.org  Tue Jul 24 02:19:11 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Tue, 24 Jul 2012 00:19:11 +0000
Subject: [issue15195] test_distutils fails when ARCHFLAGS is set on a Mac
In-Reply-To: <1340724368.12.0.314472087482.issue15195@psf.upfronthosting.co.za>
Message-ID: <1343089150.84.0.227418666858.issue15195@psf.upfronthosting.co.za>


Marc Abramowitz <msabramo at gmail.com> added the comment:

I just verified -- the issue seems to be fixed for me on OS X 10.6.8 with revision 00db71b3c5bd. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15195>
_______________________________________

From report at bugs.python.org  Tue Jul 24 03:05:21 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 24 Jul 2012 01:05:21 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343091921.38.0.635974086873.issue15402@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

On Mon, Jul 23, 2012 at 5:04 PM, Martin v. L?wis <report at bugs.python.org> wrote:

> The patch that Meador committed is incorrect: METH_NOARGS functions
> still take a PyObject* args argument, which will be NULL. I'm puzzled, as
> Serhiy's original patch was correct.

I almost committed the two-argument version with the 'unused' parameter, but
then I had the bright idea to look at how '__sizeof__' is implemented elsewhere
in the interpreter:

  static PyObject *
  list_sizeof(PyListObject *self);
  static PyObject *
  dict_sizeof(PyDictObject *mp);
  static PyObject *
  set_sizeof(PySetObject *so);

  etc ...

So I dropped the 'unused' parmeter for the 'struct' implementation:

   static PyObject *
   s_sizeof(PyStructObject *self);

I will happily fix it, but if it is wrong one place, then it is wrong
everywhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Tue Jul 24 03:26:31 2012
From: report at bugs.python.org (Kevin Barry)
Date: Tue, 24 Jul 2012 01:26:31 +0000
Subject: [issue14916] PyRun_InteractiveLoop fails to run interactively when
	using a Linux pty that's not tied to stdin/stdout
In-Reply-To: <1337960558.56.0.442179213708.issue14916@psf.upfronthosting.co.za>
Message-ID: <1343093191.04.0.149053298428.issue14916@psf.upfronthosting.co.za>


Kevin Barry <ta0kira at gmail.com> added the comment:

Here is a patch that corrects the problem (quoted below and attached.) This only corrects the problem when 'PyOS_ReadlineFunctionPointer' is set, e.g. you must 'import readline', otherwise Python will defer to stdin/stdout with 'PyOS_StdioReadline'.


The patch:


--- Python-2.6.8/Parser/tokenizer.c     2012-04-10 11:32:11.000000000 -0400
+++ Python-2.6.8-patched/Parser/tokenizer.c     2012-07-23 19:56:39.645992101 -0400
@@ -805,7 +805,7 @@
             return Py_CHARMASK(*tok->cur++);
         }
         if (tok->prompt != NULL) {
-            char *newtok = PyOS_Readline(stdin, stdout, tok->prompt);
+            char *newtok = PyOS_Readline(tok->fp? tok->fp : stdin, tok->fp? tok->fp : stdout, tok->prompt);
             if (tok->nextprompt != NULL)
                 tok->prompt = tok->nextprompt;
             if (newtok == NULL)


Kevin Barry

----------
keywords: +patch
status: open -> pending
Added file: http://bugs.python.org/file26491/Python-2.6.8-Run_Interactive-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14916>
_______________________________________

From report at bugs.python.org  Tue Jul 24 03:39:10 2012
From: report at bugs.python.org (Kevin Barry)
Date: Tue, 24 Jul 2012 01:39:10 +0000
Subject: [issue14916] PyRun_InteractiveLoop fails to run interactively when
	using a Linux pty that's not tied to stdin/stdout
In-Reply-To: <1337960558.56.0.442179213708.issue14916@psf.upfronthosting.co.za>
Message-ID: <1343093950.12.0.473762508892.issue14916@psf.upfronthosting.co.za>


Kevin Barry <ta0kira at gmail.com> added the comment:

I've attached a new example source file to demonstrate the fix.


Compile the attached program with (*after* patching and installing Python):

> gcc `python-config --cflags` working2.c -o working2 `python-config --ldflags`

and run it with:

> ./working2 xterm -S/0 < /dev/null > /dev/null

(The redirection shows that it works when stdin/stdout aren't a tty.)


I looked at the most-recent revision of tokenizer.c (http://hg.python.org/cpython/file/52032b13243e/Parser/tokenizer.c) and see that the change in my patch above hasn't been made already.

Kevin Barry

----------
status: pending -> open
Added file: http://bugs.python.org/file26492/working2.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14916>
_______________________________________

From report at bugs.python.org  Tue Jul 24 04:41:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 02:41:20 +0000
Subject: [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343097680.48.0.876967009657.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attached is a script that seems to do the job (except for the rst formatting, which can be added later.  This was so that you can see by the diff what has changed).

In the process of doing this, I found that Jeff McNeil is far out of order in Misc/ACKS, and possibly also Hugo Lopes Tavares and Xavier de Gaye, depending on what alphabetization rules should be used.

The script contains logic to collect the non-ascii characters that appear in people's names, so that non-ascii characters can be approximated by ascii characters for ordering purposes (which seems to be how it is done now in some cases).

In a subsequent comment, I will attach a diff that results from running the script, so you can see what effect it has on Misc/ACKS.

----------
Added file: http://bugs.python.org/file26493/merge-acks.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 04:44:27 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 02:44:27 +0000
Subject: [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343097867.07.0.798827342462.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching sample output of running the script.

----------
keywords: +patch
Added file: http://bugs.python.org/file26494/issue-15437-sample-output.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 04:51:27 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 24 Jul 2012 02:51:27 +0000
Subject: [issue11824] freeze.py broken due to ABI flags
In-Reply-To: <1302488520.76.0.698152823885.issue11824@psf.upfronthosting.co.za>
Message-ID: <1343098287.59.0.453435354091.issue11824@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/issue11824>
_______________________________________

From report at bugs.python.org  Tue Jul 24 06:26:35 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 24 Jul 2012 04:26:35 +0000
Subject: [issue15232] email.generator.Generator doesn't mangle "From " lines
	in MIME preamble
In-Reply-To: <1341118945.33.0.829442271947.issue15232@psf.upfronthosting.co.za>
Message-ID: <1343103995.94.0.725745249417.issue15232@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Thanks. The news entry should probably say 'From ' instead of 'From'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15232>
_______________________________________

From report at bugs.python.org  Tue Jul 24 07:45:14 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 05:45:14 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343085001.32.0.00108272866133.issue15436@psf.upfronthosting.co.za>
Message-ID: <201207240845.01012.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Could you possibly write a patch for 2.7, 3.2 and 3.3?

No, not for documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Tue Jul 24 07:59:34 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 24 Jul 2012 05:59:34 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1343109574.14.0.511764179196.issue10399@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/issue10399>
_______________________________________

From report at bugs.python.org  Tue Jul 24 08:00:26 2012
From: report at bugs.python.org (Brian Thorne)
Date: Tue, 24 Jul 2012 06:00:26 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>
Message-ID: <1343109626.05.0.406862704891.issue12428@psf.upfronthosting.co.za>


Brian Thorne <hardbyte at gmail.com> added the comment:

Thanks Antoine, the __class__ attribute wasn't useful, I've removed that. Overriding the __setattr__ and __delattr__ gives consistent behaviour with the both versions - allowing the unittest reuse. Also I've changed thread back to _thread.

Isn't more compatibility between the Python and C implementations desired? Is it an aim to document more of the functionality? An earlier version of this patch had a closure implementation of partial; I'm happy to revert to that if simplicity is preferred to compatibility?

Should the caching decorators be tested from multiple threads?

----------
Added file: http://bugs.python.org/file26495/issue12428.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12428>
_______________________________________

From report at bugs.python.org  Tue Jul 24 08:11:45 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 24 Jul 2012 06:11:45 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343110305.21.0.184893226326.issue15436@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

is __sizeof__ part of the language or just an implementation detail?

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Tue Jul 24 08:58:46 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 06:58:46 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343110305.21.0.184893226326.issue15436@psf.upfronthosting.co.za>
Message-ID: <201207240958.30230.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

See issue2898.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Tue Jul 24 10:46:59 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Tue, 24 Jul 2012 08:46:59 +0000
Subject: [issue5619] Pass MS CRT debug flags into subprocesses
In-Reply-To: <1238472783.0.0.132667741337.issue5619@psf.upfronthosting.co.za>
Message-ID: <1343119619.85.0.557357247253.issue5619@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5619>
_______________________________________

From report at bugs.python.org  Tue Jul 24 11:29:32 2012
From: report at bugs.python.org (Manuel de la Pena)
Date: Tue, 24 Jul 2012 09:29:32 +0000
Subject: [issue15275] isinstance is called a more times that needed in ntpath
In-Reply-To: <1341668298.8.0.671820953585.issue15275@psf.upfronthosting.co.za>
Message-ID: <1343122172.17.0.663309775686.issue15275@psf.upfronthosting.co.za>


Manuel de la Pena <manuel at canonical.com> added the comment:

Tests indeed cover the changes made. I don't know about a decent way of doing benchmarks for the changes. Any recommendation?

> If this patch is applied I think it would be good to change posixpath too.

I agree and I'd love to do it but in a diff bug to make things self-contained, what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15275>
_______________________________________

From report at bugs.python.org  Tue Jul 24 11:45:19 2012
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Tue, 24 Jul 2012 09:45:19 +0000
Subject: [issue15435] Strange behavior when AttributeError raise inside a
	property get function
In-Reply-To: <1343060813.45.0.564529215103.issue15435@psf.upfronthosting.co.za>
Message-ID: <1343123119.37.0.579309059892.issue15435@psf.upfronthosting.co.za>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

The problem is that the code of the property could raise an AttributeError. So this error is not showed by the traceback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15435>
_______________________________________

From report at bugs.python.org  Tue Jul 24 12:05:00 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 24 Jul 2012 10:05:00 +0000
Subject: [issue15435] Strange behavior when AttributeError raise inside a
	property get function
In-Reply-To: <1343060813.45.0.564529215103.issue15435@psf.upfronthosting.co.za>
Message-ID: <1343124300.6.0.825114033495.issue15435@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yup. It's unfortunate, but there's really nothing we can do about it - some protocols use exceptions, and if you raise an exception type that is part of the defined protocol as the result of a genuine error, then you're going to have a fun debugging exercise to deal with.

You'll often see a similar misdiagnosis with TypeError in conversion functions that try several different conversion techniques.

----------
nosy: +ncoghlan
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15435>
_______________________________________

From report at bugs.python.org  Tue Jul 24 12:06:51 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 24 Jul 2012 10:06:51 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1343124411.22.0.570201654162.issue10399@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/issue10399>
_______________________________________

From report at bugs.python.org  Tue Jul 24 12:14:07 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 Jul 2012 10:14:07 +0000
Subject: [issue14197] OS X framework builds do not create ABI-suffixed
	libpython3.x
In-Reply-To: <1330923428.91.0.0488366772742.issue14197@psf.upfronthosting.co.za>
Message-ID: <1343124847.17.0.247853798102.issue14197@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The attached patch ensures that additional SOABI-suffixed symlinks are created in the framework lib and lib/pythonx.x/config-yy directories and fixes pythons.x-config to not return garbage data for the --ldflags option. 

# current
$ ls -l /Library/Frameworks/Python.framework/Versions/3.2/lib
total 8
lrwxr-xr-x   1 root  wheel     9 Jul 15 17:40 libpython3.2.dylib@ -> ../Python
drwxrwxr-x   2 root  admin   170 Apr 10 11:27 pkgconfig/
drwxrwxr-x  32 root  admin  6290 Apr 10 11:27 python3.2/

# with patch
$ ls -l /Library/Frameworks/Python.framework/Versions/3.2/lib
total 16
lrwxr-xr-x   1 root  wheel     9 Jul 24 02:43 libpython3.2.dylib@ -> ../Python
lrwxr-xr-x   1 root  wheel     9 Jul 24 02:43 libpython3.2m.dylib@ -> ../Python
drwxrwxr-x   2 root  admin   170 Jul 24 02:38 pkgconfig/
drwxrwxr-x  34 root  admin  6494 Jul 24 02:38 python3.2/

# current
$ ls -l /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/config-3.2m/
total 256
-rw-rw-r--  1 root  admin  51118 Apr 10 11:27 Makefile
-rw-rw-r--  1 root  admin  15018 Apr 10 11:27 Setup
-rw-rw-r--  1 root  admin    370 Apr 10 11:27 Setup.config
-rw-rw-r--  1 root  admin     41 Apr 10 11:27 Setup.local
-rw-rw-r--  1 root  admin   2902 Apr 10 11:27 config.c
-rw-rw-r--  1 root  admin   1642 Apr 10 11:27 config.c.in
-rwxrwxr-x  1 root  admin   7122 Apr 10 11:27 install-sh*
lrwxr-xr-x  1 root  wheel     15 Jul 15 17:40 libpython3.2.a@ -> ../../../Python
lrwxr-xr-x  1 root  wheel     15 Jul 15 17:40 libpython3.2.dylib@ -> ../../../Python
-rwxrwxr-x  1 root  admin   7460 Apr 10 11:27 makesetup*
-rw-rw-r--  1 root  admin  18776 Apr 10 11:27 python.o

# with patch
$ ls -l /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/config-3.3m/
total 280
-rw-rw-r--  1 root  admin  55198 Jul 24 02:38 Makefile
-rw-rw-r--  1 root  admin  15009 Jul 24 02:38 Setup
-rw-rw-r--  1 root  admin    370 Jul 24 02:38 Setup.config
-rw-rw-r--  1 root  admin     41 Jul 24 02:38 Setup.local
-rw-rw-r--  1 root  admin   2963 Jul 24 02:38 config.c
-rw-rw-r--  1 root  admin   1619 Jul 24 02:38 config.c.in
-rwxrwxr-x  1 root  admin   7122 Jul 24 02:38 install-sh*
lrwxr-xr-x  1 root  wheel     15 Jul 24 02:43 libpython3.2.a@ -> ../../../Python
lrwxr-xr-x  1 root  wheel     15 Jul 24 02:43 libpython3.2.dylib@ -> ../../../Python
lrwxr-xr-x  1 root  wheel     15 Jul 24 02:43 libpython3.2m.a@ -> ../../../Python
lrwxr-xr-x  1 root  wheel     15 Jul 24 02:43 libpython3.2m.dylib@ -> ../../../Python
-rwxrwxr-x  1 root  admin   7460 Jul 24 02:38 makesetup*
-rw-rw-r--  1 root  admin  18896 Jul 24 02:38 python.o

# current
$ python3.2-config --ldflags
-L/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/config-3.2m -ldl -framework CoreFoundation -lpython3.2m -framework CoreFoundation Python.framework/Versions/3.2/Python

# with patch
$ python3.2-config --ldflags
-L/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.3/config-3.2m -ldl -framework CoreFoundation -lpython3.2m

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26496/issue14197.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14197>
_______________________________________

From report at bugs.python.org  Tue Jul 24 12:19:16 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 Jul 2012 10:19:16 +0000
Subject: [issue14197] OS X framework builds do not create ABI-suffixed
	libpython3.x
In-Reply-To: <1330923428.91.0.0488366772742.issue14197@psf.upfronthosting.co.za>
Message-ID: <1343125156.87.0.472736135703.issue14197@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Georg, I'd like to apply this for both 3.2.4 and 3.3.0b2.  It's a low risk bug fix but does solve a real problem for users wanting to embed Python on OS X.  Issue15353 is also fixed by this.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14197>
_______________________________________

From report at bugs.python.org  Tue Jul 24 12:25:07 2012
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 24 Jul 2012 10:25:07 +0000
Subject: [issue15413] os.times() disappeared under Windows
In-Reply-To: <1342888046.96.0.718260213751.issue15413@psf.upfronthosting.co.za>
Message-ID: <1343125507.52.0.270837601671.issue15413@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Larry?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15413>
_______________________________________

From report at bugs.python.org  Tue Jul 24 12:25:16 2012
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 24 Jul 2012 10:25:16 +0000
Subject: [issue15295] Document PEP 420 namespace packages
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343125516.23.0.354634744449.issue15295@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 24 12:46:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Jul 2012 10:46:14 +0000
Subject: [issue14197] OS X framework builds do not create ABI-suffixed
	libpython3.x
In-Reply-To: <1330923428.91.0.0488366772742.issue14197@psf.upfronthosting.co.za>
Message-ID: <3WhGT05PFrzPV7@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2d4f290ea71c by Ned Deily in branch '3.2':
Issue #14197: For OS X framework builds, ensure links to the shared
http://hg.python.org/cpython/rev/2d4f290ea71c

New changeset 51ac5f06dd04 by Ned Deily in branch 'default':
Issue #14197: merge
http://hg.python.org/cpython/rev/51ac5f06dd04

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14197>
_______________________________________

From report at bugs.python.org  Tue Jul 24 12:50:27 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 Jul 2012 10:50:27 +0000
Subject: [issue14197] OS X framework builds do not create ABI-suffixed
	libpython3.x
In-Reply-To: <1330923428.91.0.0488366772742.issue14197@psf.upfronthosting.co.za>
Message-ID: <1343127027.07.0.602611273995.issue14197@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Fix applied for release in 3.2.4 and (with release manager approval) for 3.3.0b2.

----------
components: +Build -Macintosh, None
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14197>
_______________________________________

From report at bugs.python.org  Tue Jul 24 12:57:50 2012
From: report at bugs.python.org (andrea bergamini)
Date: Tue, 24 Jul 2012 10:57:50 +0000
Subject: [issue15438] Incredible issue in math.pow
Message-ID: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>


New submission from andrea bergamini <andrea.bergamini.it at gmail.com>:

math.pow(43, 10) gives the wrong result: 21611482313284248.0
Instead, the build-in function 43**10 and pow(43, 10) give the correct result: 21611482313284249L.
This bug has been seen on ActivePython 2.5.1.1. Sorry no tests on recent versions.

----------
components: Library (Lib)
messages: 166275
nosy: andrea.bergamini
priority: normal
severity: normal
status: open
title: Incredible issue in math.pow
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 13:00:16 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 Jul 2012 11:00:16 +0000
Subject: [issue15353] ld: library not found for -lpython3.3m because of wrong
	LDFLAGS_PYTHON
In-Reply-To: <1342297831.17.0.252581659185.issue15353@psf.upfronthosting.co.za>
Message-ID: <1343127616.3.0.209914243727.issue15353@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the report.  The python-3.3.pc file is correct.  It is a symlink to the python-3.3m.pc.  What isn't correct is that OS X framework builds were not creating the proper libpython3.3m.{dylib,a} symlinks for use with python3.x-config and with pkg-config (if installed).  The fixes applied for Issue14197 (for release in 3.2.4 and 3.3.0b2) correct that and ensure that python-3.x-conifg --ldflags returns a useful value.

----------
components: +Build
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> OS X framework builds do not create ABI-suffixed libpython3.x
type: compile error -> 
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15353>
_______________________________________

From report at bugs.python.org  Tue Jul 24 13:08:12 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 Jul 2012 11:08:12 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343128092.03.0.8575378589.issue15438@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 13:32:57 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 24 Jul 2012 11:32:57 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343129577.96.0.610119989003.issue15438@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is what I get on both 2.7 and 3.3:
>>> import math
>>> math.pow(43, 10)
2.161148231328425e+16
>>> pow(43, 10)
21611482313284249
>>> 43**10
21611482313284249
>>> int(math.pow(43, 10))
21611482313284248

----------
nosy: +ezio.melotti, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 13:42:47 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 11:42:47 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343130167.33.0.688425515253.issue15438@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

>>> (43**10).bit_length()
55
>>> sys.float_info.mant_dig
53

See http://docs.python.org/faq/design.html#why-are-floating-point-calculations-so-inaccurate

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 13:51:40 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 11:51:40 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
Message-ID: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to include the names in Misc/ACKS into the documentation --
in place of the names from Doc/ACKS.txt.  This was mentioned in the
discussion for issue 15437, which is to add the names from Doc/ACKS.txt
into Misc/ACKS.

This issue should be done shortly after issue 15437.  The current issue
can include (1) converting Misc/ACKS into rst format, (2) deleting
DOC/ACKS.txt (after confirming that any changes since issue 15437 are
reflected in Misc/ACKS), and (3) resolving the intros in the two files
with about.rst's surrounding text so that the text makes sense when
included into the main documentation.

Should Guido's note of acknowledgment in Misc/ACKS be included as is?
And should a new "Python Acknowledgments" section be added to the docs,
or is it okay for this more general acknowledgment to be included in the
section called "About these documents"?  If the former, the "About these
documents" section could link to the more general "Python
Acknowledgments" section to reference documentation contributors.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166279
nosy: cjerdonek, docs at python, eric.araujo, ezio.melotti, georg.brandl, jcea, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Include Misc/ACKS names into the documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Tue Jul 24 13:53:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 11:53:26 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343130806.84.0.337061337255.issue15439@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
dependencies: +Merge Doc/ACKS and Misc/ACKS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Tue Jul 24 13:58:25 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 11:58:25 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343131105.37.0.711152230421.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1. Misc/ACKS is fine where it is. No need to include it into the docs.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Tue Jul 24 14:01:34 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 12:01:34 +0000
Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343131294.59.0.459638466935.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I created a new issue 15439 for including the combined Misc/ACKS into the documentation (as ?ric mentioned) because the nature of that discussion is different, and because the changes will be easier to observe and understand if committed separately.

----------
title: Merge Doc/ACKS and Misc/ACKS -> Merge Doc/ACKS.txt names into Misc/ACKS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 14:10:36 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 12:10:36 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343131836.16.0.768896870389.issue15439@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Martin, just to be sure, this is to be done after issue 15437 (a dependency), and the location of Misc/ACKS will not change.  Have you already read the discussion there?  ?ric said that he recalled it was Georg's preference to do this if Doc/ACKS.txt is removed.  (I personally have no opinion.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Tue Jul 24 14:18:41 2012
From: report at bugs.python.org (andrea bergamini)
Date: Tue, 24 Jul 2012 12:18:41 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343132321.86.0.164447322301.issue15438@psf.upfronthosting.co.za>


andrea bergamini <andrea.bergamini.it at gmail.com> added the comment:

Ok, but math.pow IMPO has to be aligned to pow and built-in pow (**), otherwise this kind of "inaccuracies" can compromise the application behavior. I was using this funcion in a cryptographic mechanisms, and this issue resulted in a failure. 
Generally speaking, integer numbers should not be affected by inaccuracies. I mean, there's no floating point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 14:30:30 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Jul 2012 12:30:30 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343133030.93.0.920194239608.issue15438@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If I understand correctly, the math module is providing C standard (Annex F) *floating point* mathematical functions.  Mark will have the definitive answer once he gets a chance to comment.  Perhaps a documentation clarification is in order on this point.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 14:38:20 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 24 Jul 2012 12:38:20 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343133500.18.0.330949409435.issue15438@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think Serhiy has already explained that 43**10 is too large
to be represented exactly in 53-bit floating point arithmetic.

The math module wraps the floating point functions from the
C standard:

"It provides access to the mathematical functions defined by the C standard."

"Except when explicitly noted otherwise, all return values are floats."


So there's no bug, and the documentation looks fine to me, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 14:40:00 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 12:40:00 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343133600.09.0.3101045676.issue15438@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the math.pow() doc could use a "seealso" pointing to the built-in pow() function perhaps.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 14:45:07 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 24 Jul 2012 12:45:07 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343133907.17.0.930850104419.issue15438@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

How about changing the title to something like:

math -- 53-bit floating point arithmetic

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 14:46:17 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 24 Jul 2012 12:46:17 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343133977.78.0.145197792714.issue15438@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

"Title" referring to the section header of http://docs.python.org/dev/library/math.html ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 14:53:21 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 12:53:21 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343134401.4.0.346031098375.issue15438@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That could help, but you easily miss the title when looking up the doc for a given function.

And since log2() already has a seealso for the corresponding int method, pow() could grow one as well.
(and in all honesty I don't know the difference between the "**" operator and the built-in pow() function :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 15:02:50 2012
From: report at bugs.python.org (andrea bergamini)
Date: Tue, 24 Jul 2012 13:02:50 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343134970.6.0.822609539869.issue15438@psf.upfronthosting.co.za>


andrea bergamini <andrea.bergamini.it at gmail.com> added the comment:

Well, from a library I'm used to expect a good result or an exception. Not a value that differs from the correct of one unit! I agree with Antoine, the doc should warn about this behavior. I've lost a lot of time before discovering my application issue came from the py math library...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 15:45:36 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Jul 2012 13:45:36 +0000
Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343137536.53.0.956304009397.issue15437@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not clear if your script is trying to do this, but there is no way to automatically alphabetize the file.  That's why it says "rough" alphabetic order.  The issue is that different languages alphabetize different letters in different places.  We try to respect the alphabetization of the source language as much as practical...which means there is no algorithm that can do the sorting, since the names in the file do not carry explicit language information.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 15:49:23 2012
From: report at bugs.python.org (Derek Wilson)
Date: Tue, 24 Jul 2012 13:49:23 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1343137763.3.0.577629146271.issue6056@psf.upfronthosting.co.za>


Derek Wilson <jderekwilson at gmail.com> added the comment:

Thanks, Jim, here is an updated patch. 

1) I feel like it is clearly not-a-feature. Currently 2.7 crashes if remote managers are used and socket.setdefaulttimeout is anything other than None. Crashing seems bad and all this does is keep multiprocessing connection sockets non-blocking even if a default timeout is specified (so it maintains current behavior rather than crashing).

2) This problem is still evident on 2.7, 3.2 and 3.3 beta 1. This patch is against the current dev tip as of a few days ago.

3) here it is!

4) I agree that setblocking is more clear. I made the change.

My test modifications cover the entire suite twice, once without a default timeout and once with. This may be excessive? I'm not sure where non-blocking sockets might pop up as an issue since there is C code that relies on blocking sockets and I haven't dug that deep.

----------
Added file: http://bugs.python.org/file26497/mp6056fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Tue Jul 24 15:49:29 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Jul 2012 13:49:29 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343137769.22.0.861869692788.issue15438@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Your problems didn't come from the "Python" math library, it came from the C math library that Python provides a wrapper for, which the documentation does clearly state.  And the result you got is accurate...for a floating point calculation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Tue Jul 24 16:02:59 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 14:02:59 +0000
Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343138579.64.0.956134166036.issue15437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the script output looks good (apart from a few duplicates which can be resolved by hand, e.g. "Terry Reedy" vs. "Terry J. Reedy").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 16:15:03 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 14:15:03 +0000
Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343139303.92.0.980855901028.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I did think through those issues and made a special effort to address them in the script.

For starters, the script does not change the order of any names in Misc/ACKS.  This is to preserve the existing rough alphabetical ordering, and to ensure that the diff consists only of insertions (for easier manual checking, if desired).

As for inserting new names in rough alphabetical order, I dealt with different language characters as follows.  The script has a translation table to map non-ascii characters to ascii characters for sorting purposes.  Currently, that table is as follows (I'm not sure if all of these characters will render on the page):

NON_ASCII = "?????????????????????????????????????"
ASCII_SUB = 'AEOaaaaceeinooouuuceLnZKMCabrekhopw""'

This mapping can easily be modified if my initial choices are not the best.  As an early step, the script collects all non-ascii characters that appear in all names to make sure the translation table is up to date (exiting with a message otherwise).

When I said "Jeff McNeil" is out of order, that was because the name appears after "Jeff Epler" but before "Tom Epperly".  The script maintains a list of "out of order" names like this to skip when inserting, to prevent insertions from being out of rough alphabetical order.

If different languages use a different ordering on the word level, the script will not handle that, however.  It only orders lexicographically by last name, and then first name(s).

Much of this information is spelled out in the script's docstring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 16:20:12 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 14:20:12 +0000
Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343139612.58.0.291575986021.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

That is correct, Antoine.  Duplicates need to be removed by hand.

To assist in this process, the script currently prints "possible duplicates" to stdout after running.  However, the script could easily be modified to display an in-line indicator before possible duplicates to make this manual step easier, e.g.:

 John Redford
 Terry Reedy
+>>> Terry J. Reedy
 Gareth Rees

Currently, possible duplicates are determined based on whether the last name matches an already existing last name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 16:22:02 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Tue, 24 Jul 2012 14:22:02 +0000
Subject: [issue11466] getpass.getpass doesn't close tty file
In-Reply-To: <1299844492.32.0.259676792362.issue11466@psf.upfronthosting.co.za>
Message-ID: <1343139722.48.0.669514028104.issue11466@psf.upfronthosting.co.za>


Anton Barkovsky <swarmer.pm at gmail.com> added the comment:

I think I've found the root cause.

On my system (also tested in 3.2) /dev/tty is opened successfully, but wrapping it in io.BufferedRandom fails. By the time the exception is raised, FileIO object is already created, and then it immediately gets deleted.

I'm attaching a patch that closes the file explicitly in this case.
Be extra careful when reviewing though - this is the first time I'm touching Python's C code.

----------
Added file: http://bugs.python.org/file26498/closewarning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11466>
_______________________________________

From report at bugs.python.org  Tue Jul 24 16:22:35 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 14:22:35 +0000
Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343139612.58.0.291575986021.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343139634.3405.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> To assist in this process, the script currently prints "possible
> duplicates" to stdout after running.  However, the script could easily
> be modified to display an in-line indicator before possible duplicates
> to make this manual step easier, e.g.:
> 
>  John Redford
>  Terry Reedy
> +>>> Terry J. Reedy
>  Gareth Rees

Well, no need to be perfectionist IMO. The merging will only be done
once (thrice if we count all branches :-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 16:26:22 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Tue, 24 Jul 2012 14:26:22 +0000
Subject: [issue11466] getpass.getpass doesn't close tty file
In-Reply-To: <1299844492.32.0.259676792362.issue11466@psf.upfronthosting.co.za>
Message-ID: <1343139982.82.0.679264776089.issue11466@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


Removed file: http://bugs.python.org/file26498/closewarning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11466>
_______________________________________

From report at bugs.python.org  Tue Jul 24 16:26:36 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Tue, 24 Jul 2012 14:26:36 +0000
Subject: [issue11466] getpass.getpass doesn't close tty file
In-Reply-To: <1299844492.32.0.259676792362.issue11466@psf.upfronthosting.co.za>
Message-ID: <1343139996.81.0.0350663087616.issue11466@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


Added file: http://bugs.python.org/file26499/closewarning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11466>
_______________________________________

From report at bugs.python.org  Tue Jul 24 16:37:45 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 24 Jul 2012 14:37:45 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1343140665.46.0.773804743302.issue6056@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Tue Jul 24 17:17:52 2012
From: report at bugs.python.org (Bala FA)
Date: Tue, 24 Jul 2012 15:17:52 +0000
Subject: [issue15440] multiprocess fails to re-raise exception which has
	mandatory arguments
Message-ID: <1343143072.3.0.822241372547.issue15440@psf.upfronthosting.co.za>


New submission from Bala FA <barumuga at redhat.com>:

I use multiprocess in one of my project.  When an exception which
requires mandatory argument is raised by a server process, is not
re-raised properly to client process.  I get an error something like
below

Traceback (most recent call last):
  File "prod.py", line 69, in <module>
    main()
  File "prod.py", line 61, in main
    print myobj.fun3()
  File "<string>", line 2, in fun3
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 759,
in _callmethod
    kind, result = conn.recv()
TypeError: ('__init__() takes exactly 2 arguments (1 given)', <class
'__main__.MyException2'>, ())

However, if an exception which has optional argument is raised by
server process, is re-raised properly to client process.

Below is a reproducer.

#!/usr/bin/python

import sys
import os
import time
import subprocess
from multiprocessing.managers import BaseManager

class MyManager(BaseManager):
    pass

class MyException1(Exception):
    def __init__(self, msg=''):
        self.msg = msg

    def __str__(self):
        return self.msg

class MyException2(Exception):
    def __init__(self, msg):
        self.msg = msg

    def __str__(self):
        return self.msg

class MyClass(object):
    def fun1(self):
        return 'this is fun1'

    def fun2(self):
        raise MyException1('fun2 raised')

    def fun3(self):
        raise MyException2('fun3 raised')

def runManager():
    manager = MyManager(address=('', 50000), authkey='abc')
    manager.register('instance', callable=MyClass)
    server = manager.get_server()
    print "manager is running"
    server.serve_forever()

def startManager():
    p = subprocess.Popen(['python', __file__, 'manager'])
    time.sleep(1)
    return p

def main():
    p = startManager()
    manager = MyManager(address=('', 50000), authkey='abc')
    manager.register('instance')
    print "connecting to manager"
    manager.connect()
    myobj = manager.instance()
    print myobj.fun1()
    try:
        print myobj.fun2()
    except MyException1, e:
        print e
    try:
        print myobj.fun3()
    except MyException2, e:
        print e
    finally:
        p.kill()

if __name__ == '__main__':
    if len(sys.argv) == 1:
        main()
    else:
        runManager()

I use python 2.7.3 on fedora 17 on x86_64 (rpm version is
python-2.7.3-6.fc17.x86_64)

----------
components: Interpreter Core
messages: 166299
nosy: Bala.FA
priority: normal
severity: normal
status: open
title: multiprocess fails to re-raise exception which has mandatory arguments
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15440>
_______________________________________

From report at bugs.python.org  Tue Jul 24 17:24:08 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Tue, 24 Jul 2012 15:24:08 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
Message-ID: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>


New submission from Atsuo Ishimoto <ishimoto at gembook.org>:

test_posixpath.PosixCommonTest.test_nonascii_abspath fails on Japanese edition
of Windows.

If a file name was invalid byte character, os.chdir() raises UnicodeDecodeError()
instead of WindowsError.

This is a byte-api issue on Windows, so we may be able to simply skip this test.

======================================================================
ERROR: test_nonascii_abspath (test.test_posixpath.PosixCommonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\cygwin\home\ishimoto\src\cpython\lib\test\test_genericpath.py", line
318, in test_nonascii_abspath
    with support.temp_cwd(b'\xe7w\xf0'):
  File "C:\cygwin\home\ishimoto\src\cpython\lib\contextlib.py", line 48, in __en
ter__
    return next(self.gen)
  File "C:\cygwin\home\ishimoto\src\cpython\lib\test\support.py", line 614, in t
emp_cwd
    os.chdir(path)
UnicodeDecodeError: 'mbcs' codec can't decode bytes in position 0--1: No mapping
for the Unicode character exists in the target code page.

----------------------------------------------------------------------

----------
components: Unicode, Windows
files: test_nonascii_abspath.patch
keywords: patch
messages: 166300
nosy: ezio.melotti, ishimoto
priority: normal
severity: normal
status: open
title: test_posixpath fails on Japanese edition of Windows
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26500/test_nonascii_abspath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Tue Jul 24 17:46:28 2012
From: report at bugs.python.org (Kevin Barry)
Date: Tue, 24 Jul 2012 15:46:28 +0000
Subject: [issue14916] PyRun_InteractiveLoop fails to run interactively when
	using a Linux pty that's not tied to stdin/stdout
In-Reply-To: <1337960558.56.0.442179213708.issue14916@psf.upfronthosting.co.za>
Message-ID: <1343144788.1.0.0170868816709.issue14916@psf.upfronthosting.co.za>


Kevin Barry <ta0kira at gmail.com> added the comment:

The patch from before needed a slight modification for when Python actually defaults to an interactive session on stdin. Since I rebuild this for my current distro (Slackware64 13.37,) I switched to the Python 2.6.6 source. This might not be the proper way to handle the default case (e.g. 'Py_Main'), but it's a start.


The patch (also attached):

--- ./Parser/tokenizer.c.orig   2012-07-23 22:24:56.513992301 -0400
+++ ./Parser/tokenizer.c        2012-07-23 22:23:24.329992167 -0400
@@ -805,7 +805,7 @@
             return Py_CHARMASK(*tok->cur++);
         }
         if (tok->prompt != NULL) {
-            char *newtok = PyOS_Readline(stdin, stdout, tok->prompt);
+            char *newtok = PyOS_Readline(tok->fp? tok->fp : stdin, (tok->fp && tok->fp != stdin)? tok->fp : stdout, tok->prompt);
             if (tok->nextprompt != NULL)
                 tok->prompt = tok->nextprompt;
             if (newtok == NULL)


Kevin Barry

----------
Added file: http://bugs.python.org/file26501/Python-2.6.6-Run_Interactive-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14916>
_______________________________________

From report at bugs.python.org  Tue Jul 24 17:51:46 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Tue, 24 Jul 2012 15:51:46 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343145106.72.0.864718828786.issue15441@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

changed name of test method. In the old patch, new test method shadowed 
existing one.

----------
Added file: http://bugs.python.org/file26502/test_nonascii_abspath_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Tue Jul 24 17:51:58 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Tue, 24 Jul 2012 15:51:58 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343145118.26.0.610318906365.issue15441@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


Removed file: http://bugs.python.org/file26500/test_nonascii_abspath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Tue Jul 24 17:54:24 2012
From: report at bugs.python.org (Kevin Barry)
Date: Tue, 24 Jul 2012 15:54:24 +0000
Subject: [issue14916] PyRun_InteractiveLoop fails to run interactively when
	using a Linux pty that's not tied to stdin/stdout
In-Reply-To: <1337960558.56.0.442179213708.issue14916@psf.upfronthosting.co.za>
Message-ID: <1343145264.42.0.00742888173781.issue14916@psf.upfronthosting.co.za>


Kevin Barry <ta0kira at gmail.com> added the comment:

I've attached a simplified example program (working3.c) that demonstrates both the original problem and that the patch (Python-2.6.6-Run_Interactive-fix.patch) works. It eliminates the need for a pty, 'xterm', and redirection.


Compile the attached program with:

> gcc `python-config --cflags` working3.c -o working3 `python-config --ldflags`

and run it with (before and after patching):

> ./working3


Also, for verification, run 'python' with no arguments to show that default interactivity is preserved.

Kevin Barry

----------
Added file: http://bugs.python.org/file26503/working3.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14916>
_______________________________________

From report at bugs.python.org  Tue Jul 24 17:57:08 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 24 Jul 2012 15:57:08 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343145428.7.0.113979906455.issue15436@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

It is part of runtime services and is mentioned in the documentation for 'sys.getsizeof' [1]:

"""
getsizeof() calls the object?s __sizeof__ method and adds an additional garbage collector overhead if the object is managed by the garbage collector.
"""

[1] http://docs.python.org/library/sys.html?highlight=__sizeof__#sys.getsizeof.

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Tue Jul 24 18:29:30 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 24 Jul 2012 16:29:30 +0000
Subject: [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343147370.13.0.742288318542.issue15269@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Yes, code samples would help clarifying the rationale for this request

----------
nosy: +eli.bendersky
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15269>
_______________________________________

From report at bugs.python.org  Tue Jul 24 18:32:12 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 24 Jul 2012 16:32:12 +0000
Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores
Message-ID: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The default ignore list of filecmp.dircmp is ['RCS', 'CVS', 'tags'].

This predates even Subversion! I suggest to freshen up this module to also ignore the dirs for SVN, Mercurial, Git and Bazaar.


[this is a new feature, so no earlier than 3.4...]

----------
components: Library (Lib)
keywords: easy
messages: 166306
nosy: eli.bendersky
priority: low
severity: normal
stage: needs patch
status: open
title: Expand the list of default dirs filecmp.dircmp ignores
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15442>
_______________________________________

From report at bugs.python.org  Tue Jul 24 18:34:34 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 24 Jul 2012 16:34:34 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343147674.25.0.288143843473.issue15231@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

The patch looks reasonable to me. Martin/?ric - any objections to committing?

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Tue Jul 24 18:40:29 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 16:40:29 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343148029.04.0.44484664849.issue15231@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/issue15231>
_______________________________________

From report at bugs.python.org  Tue Jul 24 18:51:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 16:51:45 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343145428.7.0.113979906455.issue15436@psf.upfronthosting.co.za>
Message-ID: <201207241951.27040.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> It is part of runtime services and is mentioned in the documentation for
> 'sys.getsizeof' [1]:

Yes, but it is not mentioned in the index.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Tue Jul 24 18:51:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Jul 2012 16:51:49 +0000
Subject: [issue15321] bdist_wininst installers may terminate with "close
	failed in file object destructor:\nsys.excepthook is
	missing\nlost sys.stderr"
In-Reply-To: <1341965309.27.0.878027505194.issue15321@psf.upfronthosting.co.za>
Message-ID: <3WhQZq5DnGzPZm@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f315cfa22630 by Eli Bendersky in branch 'default':
Issue #15321: update PyPI upload doc to say --no-raw passed to rst2html.py. Patch by Chris Jerdonek
http://hg.python.org/cpython/rev/f315cfa22630

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15321>
_______________________________________

From report at bugs.python.org  Tue Jul 24 19:01:10 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 24 Jul 2012 17:01:10 +0000
Subject: [issue15321] bdist_wininst installers may terminate with "close
	failed in file object destructor:\nsys.excepthook is
	missing\nlost sys.stderr"
In-Reply-To: <1341965309.27.0.878027505194.issue15321@psf.upfronthosting.co.za>
Message-ID: <1343149270.24.0.527402066619.issue15321@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Sorry about the commit message. Ignore it, I got the issue number wrong :)

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15321>
_______________________________________

From report at bugs.python.org  Tue Jul 24 19:01:15 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 24 Jul 2012 17:01:15 +0000
Subject: [issue15321] bdist_wininst installers may terminate with "close
	failed in file object destructor:\nsys.excepthook is
	missing\nlost sys.stderr"
In-Reply-To: <1341965309.27.0.878027505194.issue15321@psf.upfronthosting.co.za>
Message-ID: <1343149275.89.0.0936678414441.issue15321@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/issue15321>
_______________________________________

From report at bugs.python.org  Tue Jul 24 19:01:50 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 24 Jul 2012 17:01:50 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343149310.22.0.972789099338.issue15231@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed in f315cfa22630

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Tue Jul 24 19:09:47 2012
From: report at bugs.python.org (Nam Nguyen)
Date: Tue, 24 Jul 2012 17:09:47 +0000
Subject: [issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet
In-Reply-To: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>
Message-ID: <1343149787.04.0.782257293884.issue15285@psf.upfronthosting.co.za>


Nam Nguyen <bitsink at gmail.com> added the comment:

Using a remote server such as python.org is a good idea when you have internet connection. When you don't, though, how will the test run?

----------
nosy: +Nam.Nguyen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Tue Jul 24 19:12:43 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 17:12:43 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343149963.06.0.697377578737.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks a lot, Eli.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Tue Jul 24 19:18:46 2012
From: report at bugs.python.org (Brian Brazil)
Date: Tue, 24 Jul 2012 17:18:46 +0000
Subject: [issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet
In-Reply-To: <1343149787.04.0.782257293884.issue15285@psf.upfronthosting.co.za>
Message-ID: <CAOMb=FsE7KeVNo_ywXbqU8ytjDi-MxAOF--uGCRrXpsMkQXH2A@mail.gmail.com>


Brian Brazil <brian.brazil at gmail.com> added the comment:

There's already existing infrastructure not to run certain tests when
there's no internet connection, no ipv6, no tk etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15285>
_______________________________________

From report at bugs.python.org  Tue Jul 24 19:31:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 24 Jul 2012 17:31:56 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343151116.75.0.349241222764.issue15231@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It seems to me there are missing words in the text, and it needs porting to the packaging docs.

Proposal: [...] being able to run the command above without warnings is not sufficient to be sure that PyPI will convert the content successfully.

----------
components: +Distutils, Distutils2
nosy: +alexis, tarek
resolution: fixed -> 
stage: committed/rejected -> commit review
status: closed -> open
versions: +Python 2.7, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Tue Jul 24 19:33:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 17:33:29 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1343109626.05.0.406862704891.issue12428@psf.upfronthosting.co.za>
Message-ID: <1343151087.3405.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mardi 24 juillet 2012 ? 06:00 +0000, Brian Thorne a ?crit :
> Isn't more compatibility between the Python and C implementations
> desired?

IMHO, not when compatibility regards obscure details such as whether
setting an attribute is allowed or not. I don't know why this was
codified in the unit tests in the first place, perhaps Nick can shed
some light.

> Should the caching decorators be tested from multiple threads?

Why not, if there's an easy way to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12428>
_______________________________________

From report at bugs.python.org  Tue Jul 24 20:04:09 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 18:04:09 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343153049.39.0.449728870414.issue15441@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Tue Jul 24 20:24:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Jul 2012 18:24:58 +0000
Subject: [issue15232] email.generator.Generator doesn't mangle "From " lines
	in MIME preamble
In-Reply-To: <1341118945.33.0.829442271947.issue15232@psf.upfronthosting.co.za>
Message-ID: <3WhSfK1kBCzPYx@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0caff799e4bf by R David Murray in branch '3.2':
#15232: make NEWS entry more accurate.
http://hg.python.org/cpython/rev/0caff799e4bf

New changeset d53524c43d0e by R David Murray in branch 'default':
#15232: make NEWS entry more accurate.
http://hg.python.org/cpython/rev/d53524c43d0e

New changeset e9ffde2c7da3 by R David Murray in branch '2.7':
#15232: make NEWS entry more accurate.
http://hg.python.org/cpython/rev/e9ffde2c7da3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15232>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:03:45 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 19:03:45 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343156625.66.0.030974871637.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok, please rephrase: what do you mean by "inlude ... into ..."? If the place of Misc/ACKS doesn't change, in what way is it being included into something? And which "documentation" is it being included into, if it doesn't change its location?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:09:41 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 19:09:41 +0000
Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343156981.95.0.122054944674.issue15437@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Also, if you want to do phonetic translation of non-ASCII, then ???????? really matches abgeknor, and ? is transliterated to "sh" in English (IIUC) (to "sch" in German).

But I agree that this is best done manually. What matters is what the script produces; the script certainly won't make it into Python's source code. I'm sure Chris had fun writing it.

----------
keywords:  -easy
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:21:11 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 19:21:11 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343157671.71.0.0891944018464.issue15439@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Ok, please rephrase: what do you mean by "inlude ... into ..."?

http://docs.python.org/about.html#contributors-to-the-python-documentation

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:26:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Jul 2012 19:26:01 +0000
Subject: [issue15413] os.times() disappeared under Windows
In-Reply-To: <1342888046.96.0.718260213751.issue15413@psf.upfronthosting.co.za>
Message-ID: <3WhV0m0VqtzPZf@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d9a881b0d6ca by Antoine Pitrou in branch 'default':
Issue #15413: os.times() had disappeared under Windows.
http://hg.python.org/cpython/rev/d9a881b0d6ca

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15413>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:26:42 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 19:26:42 +0000
Subject: [issue15413] os.times() disappeared under Windows
In-Reply-To: <1342888046.96.0.718260213751.issue15413@psf.upfronthosting.co.za>
Message-ID: <1343158002.76.0.859520602748.issue15413@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I fixed it.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15413>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:29:09 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 19:29:09 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343158149.85.0.57534628587.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I see; I'm changing my vote to -0 then. I don't think this list of names should have been included in the documentation in the first place. Since it is, providing the full list of contributors is just as fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:36:50 2012
From: report at bugs.python.org (Vincenzo Ampolo)
Date: Tue, 24 Jul 2012 19:36:50 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
Message-ID: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>


New submission from Vincenzo Ampolo <vincenzo.ampolo at gmail.com>:

As long as computers evolve time management becomes more precise and more granular.
Unfortunately the standard datetime module is not able to deal with nanoseconds even if OSes are able to. For example if i do:

print "%.9f" % time.time()
1343158163.471209049

I've actual timestamp from the epoch with nanosecond granularity.

Thus support for nanoseconds in datetime would really be appreciated

----------
components: ctypes
messages: 166326
nosy: Vincenzo.Ampolo
priority: normal
severity: normal
status: open
title: datetime module has no support for nanoseconds
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:37:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 19:37:26 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343158646.72.0.402261213753.issue15439@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

The second sense of the word "include" is in the possible implementation.  ?ric pointed out in the other issue's thread that this can be achieved by modifying the existing include directive, for example--

--- a/Doc/about.rst
+++ b/Doc/about.rst
@@ -30,7 +30,7 @@
 documentation, or Python itself.
 
 .. including the ACKS file here so that it can be maintained separately
-.. include:: ACKS.txt
+.. include:: ../Misc/ACKS

The details of the surrounding text still need to be worked out though so that it reads right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:46:08 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 19:46:08 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1343159168.63.0.679978577942.issue15443@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +belopolsky, haypo, lemburg
versions: +Python 3.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:48:32 2012
From: report at bugs.python.org (Vincenzo Ampolo)
Date: Tue, 24 Jul 2012 19:48:32 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1343159312.16.0.662455526303.issue15443@psf.upfronthosting.co.za>


Changes by Vincenzo Ampolo <vincenzo.ampolo at gmail.com>:


----------
components: +Library (Lib) -ctypes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:48:48 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 19:48:48 +0000
Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343159328.09.0.702520129395.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Yes, I did. Even though it is throw-away.

By the way, I'm taking Antoine's advice to avoid perfectionism on this. Otherwise I'd include your suggestion re: the special characters. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Tue Jul 24 21:57:19 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 19:57:19 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343159839.05.0.368454901313.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think Guido's wording should be included literally in the online version. It very much explains what this list really is and how to interpret it. The post scriptum should be converted into a ReST comment, since it is primarily a note to maintainers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Tue Jul 24 22:01:55 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 24 Jul 2012 20:01:55 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1343160115.53.0.991491051327.issue15443@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/issue15443>
_______________________________________

From report at bugs.python.org  Tue Jul 24 22:25:12 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 20:25:12 +0000
Subject: [issue15444] Incorrectly writen contributor's names
Message-ID: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Some contributor's names written incorrectly (in ASCII) in documentation:

Jes?s Cea Avi?n as Jes?s Cea Avion
Lars Gust?bel as Lars Gustaebel
Gerhard H?ring as Gerhard Haering
Marc-Andr? Lemburg as Marc-Andre Lemburg
Martin von L?wis as Martin von Loewis
Charles-Fran?ois Natali as Charles-Francois Natali
?iga Seilnach as Ziga Seilnacht

The proposed patch restores natural spelling (based on Doc/ACKS and Misc/ACKS).

I'm not sure about how to write right: ?iga Seilnach or Seilnacht?

----------
assignee: docs at python
components: Documentation
files: doc-nonascii-names.patch
keywords: patch
messages: 166330
nosy: docs at python, ghaering, jcea, lars.gustaebel, lemburg, loewis, neologix, storchaka, zseil
priority: normal
severity: normal
status: open
title: Incorrectly writen contributor's names
Added file: http://bugs.python.org/file26504/doc-nonascii-names.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Tue Jul 24 22:27:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 20:27:53 +0000
Subject: [issue15444] Incorrectly writen contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343161673.15.0.503988315755.issue15444@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Tue Jul 24 22:28:35 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 24 Jul 2012 20:28:35 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <500F0575.6070704@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Vincenzo Ampolo wrote:
> 
> As long as computers evolve time management becomes more precise and more granular.
> Unfortunately the standard datetime module is not able to deal with nanoseconds even if OSes are able to. For example if i do:
> 
> print "%.9f" % time.time()
> 1343158163.471209049
> 
> I've actual timestamp from the epoch with nanosecond granularity.
> 
> Thus support for nanoseconds in datetime would really be appreciated

I would be interested in an actual use case for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Tue Jul 24 23:43:38 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 24 Jul 2012 21:43:38 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343166218.85.0.0504560172436.issue1692335@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

ISTM the simplest approach would be to just set self->args in BaseException.__new__() (like in Georg's patch) but to ignore the possibility that the user might later set self.args to something stupid "wrong":

diff -r 51ac5f06dd04 Objects/exceptions.c
--- a/Objects/exceptions.c      Tue Jul 24 03:45:39 2012 -0700
+++ b/Objects/exceptions.c      Tue Jul 24 22:12:49 2012 +0100
@@ -44,12 +44,17 @@
     self->traceback = self->cause = self->context = NULL;
     self->suppress_context = 0;

-    self->args = PyTuple_New(0);
-    if (!self->args) {
-        Py_DECREF(self);
-        return NULL;
+    if (!args) {
+        args = PyTuple_New(0);
+        if (!args) {
+            Py_DECREF(self);
+            return NULL;
+        }
+    } else {
+        Py_INCREF(args);
     }

+    self->args = args;
     return (PyObject *)self;
 }

Certainly it will not work for all cases (like calling a base classes' __init__ with different arguments), but it does cover the *very* common case where __init__() is defined but does not call the base classes' __init__().

Such a patch is minimally invasive and, as far as I can see, would not break currently working code.

Would this be acceptable for a bugfix release?

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Tue Jul 24 23:45:07 2012
From: report at bugs.python.org (Vincenzo Ampolo)
Date: Tue, 24 Jul 2012 21:45:07 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <500F0575.6070704@egenix.com>
Message-ID: <500F175E.5000901@gmail.com>


Vincenzo Ampolo <vincenzo.ampolo at gmail.com> added the comment:

On 07/24/2012 01:28 PM, Marc-Andre Lemburg wrote:
> I would be interested in an actual use case for this.

Alice has a dataset with nanosecond granularity. He wants to make a
python library to let Bob access the dataset. Nowadays Alice has to
implement her own time class losing all the flexibility of the datetime
module. With this enhancement she can provide a library that just uses
the standard python datetime module. Her library will get the needed
time format, including nanoseconds.

Many python sql libraries, like the one in django e the one in web2py,
relay on datetime objects for time representation. Bob has a web2py
website that has some data with nanosecond granularity. Nowadays Bob has
to store this data as a string or a long number without the ability to
use the powerful datetime module. With this enhancement Bob doesn't need
to build or learn another interface, he can just use the datetime module
using microseconds or nanoseconds as needed.

Google search for "python datetime nanoseconds" shows more than 141k
results:
https://www.google.com/search?sourceid=chrome&ie=UTF-8&q=python+time#hl=en&biw=1615&bih=938&sclient=psy-ab&q=python+datetime+nanoseconds&oq=python+datetime+nanoseconds

So this is definitively a requested feature. And as soon as technology
evolves more people will ask for it.

I imagine something like:

import datetime
nano_time = datetime.datetime(year=2012, month=07, day=24, hour=14,
minute=35, second=3, microsecond=53, nanosecond=27)

in case you need nanosecond granularity. if you don't need it just skip
the nanosecond part and the module works like it's now. Of course
strftime format should be updated to support nanoseconds.

I can write a patch if some dev can maybe review it.

Before someone takes the datetime source code and starts a third part
module that supports nanoseconds, I think this enhancement has almost
null impact in existing code and makes the datetime module even more
powerful. It's up to the Cpython admins to decide between maintaining
datetime module up to date with new needs or let third part modules take
care of those lacks.

Best Regards,
-- 
Vincenzo Ampolo
http://vincenzo-ampolo.net
http://goshawknest.wordpress.com

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Tue Jul 24 23:45:56 2012
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 24 Jul 2012 21:45:56 +0000
Subject: [issue15413] os.times() disappeared under Windows
In-Reply-To: <1342888046.96.0.718260213751.issue15413@psf.upfronthosting.co.za>
Message-ID: <1343166356.12.0.750445284373.issue15413@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Sorry, I've been on the road a lot.  Thanks, Antoine!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15413>
_______________________________________

From report at bugs.python.org  Wed Jul 25 00:03:11 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Jul 2012 22:03:11 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1343167391.99.0.146382462484.issue15443@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe Marc-Andre was looking for an actual real-world use case rather than a hypothetical one.  We discussed this briefly on the irc channel and we think Guido vetoed it on a YAGNI basis (we haven't checked the archives though...) so a real world use case is probably required.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 00:36:33 2012
From: report at bugs.python.org (Vincenzo Ampolo)
Date: Tue, 24 Jul 2012 22:36:33 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343167391.99.0.146382462484.issue15443@psf.upfronthosting.co.za>
Message-ID: <500F236C.5030207@gmail.com>


Vincenzo Ampolo <vincenzo.ampolo at gmail.com> added the comment:

This is a real use case I'm working with that needs nanosecond precision
and lead me in submitting this request:

most OSes let users capture network packets (using tools like tcpdump or
wireshark) and store them using file formats like pcap or pcap-ng. These
formats include a timestamp for each of the captured packets, and this
timestamp usually has nanosecond precision. The reason is that on
gigabit and 10 gigabit networks the frame rate is so high that
microsecond precision is not enough to tell two frames apart.
pcap (and now pcap-ng) are extremely popular file formats, with millions
of files stored around the world. Support for nanoseconds in datetime
would make it possible to properly parse these files inside python to
compute precise statistics, for example network delays or round trip times.

Other case is in stock markets. In that field information is timed in
nanoseconds and have the ability to easily deal with this kind of
representation natively with datetime can make the standard module even
more powerful.

The company I work for is in the data networking field, and we use
python extensively. Currently we rely on custom code to process
timestamps, a nanosecond datetime would let us avoit that and use
standard python datetime module.

Best Regards,

---
Vincenzo Ampolo
http://vincenzo-ampolo.net
http://goshawknest.wordpress.com

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 00:38:58 2012
From: report at bugs.python.org (Vincenzo Ampolo)
Date: Tue, 24 Jul 2012 22:38:58 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1343169538.34.0.74203489163.issue15443@psf.upfronthosting.co.za>


Changes by Vincenzo Ampolo <vincenzo.ampolo at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 01:18:15 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Jul 2012 23:18:15 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343171895.85.0.540300311086.issue15438@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The math module is primarily about exposing the C floating point library functions.  Any integer arguments are converted to double.

We could add more docs but that usually doesn't help someone who already has an expectation that math.pow does the same thing as int ** int.

----------
assignee:  -> rhettinger
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Wed Jul 25 01:18:41 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Jul 2012 23:18:41 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343171921.53.0.787949893508.issue15438@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components: +Documentation -Library (Lib)
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Wed Jul 25 01:20:19 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Jul 2012 23:20:19 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1343172019.87.0.520346621185.issue15443@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Are the nanosecond timestamps timestamps or strings?  If they are timestamps it's not immediately obvious why you want to convert them to datetime objects, so motivating that would probably help.  On the other hand the fact that you have an application that does so is certain an argument for real world applicability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 01:21:22 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 23:21:22 +0000
Subject: [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343172082.97.0.327273299728.issue15269@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks for taking the time to look at this, Eli.

In response to your question, here is one illustrated rationale.

When recursing through a directory using dircmp, it is simplest and cleanest to be able to recurse on the subdirs attribute without having to pass pairs of paths around or reconstruct dircmp instances.  You can see this for example in filecmp's own very concise implementation of dircmp.report_full_closure():

    def report_full_closure(self): # Report on self and subdirs recursively
        self.report()
        for sd in self.subdirs.values():
            print()
            sd.report_full_closure()

However, dircmp's reporting functionality is self-admittedly "lousy":

    def report(self): # Print a report on the differences between a and b
        # Output format is purposely lousy
        print('diff', self.left, self.right)
        ...

(Incidentally, observe above that dircmp.report() itself uses the 'left' and 'right' attributes.)

Given the limitations of report_full_closure(), etc, it is natural that one might want to write a custom or replacement reporting function with nicer formatting.  When doing this, it would be nice to be able to follow that same clean and concise recursion pattern.  For example--

    def diff(dcmp):
        for sd in dcmp.subdirs.values():
            diff(sd)
        for name in dcmp.diff_files:
            print("%s differs in %s and %s" % (name, dcmp.left, dcmp.right))

    dcmp = dircmp('dir1', 'dir2')
    diff(dcmp)

If one isn't able to access 'left' and 'right' (or if one simply isn't aware of those attributes, which was the case for me at one point), the alternative would be to do something like the following, which is much uglier and less DRY:

    import os

    def diff2(dcmp, dir1, dir2):
        for name, sd in dcmp.subdirs.items():
            subdir1 = os.path.join(dir1, name)
            subdir2 = os.path.join(dir2, name)
            diff2(sd, subdir1, subdir2)
        for name in dcmp.diff_files:
            print("%s differs in %s and %s" % (name, dir1, dir2))

    dcmp = dircmp('dir1', 'dir2')
    diff2(dcmp, dir1='dir1', dir2='dir2')

An example like diff() above might even be worth including in the docs as an example of how subdirs can be used to avoid having to manually call os.path.join(...), etc.

There are also non-recursive situations in which being able to access dircmp.left and dircmp.right makes for cleaner code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15269>
_______________________________________

From report at bugs.python.org  Wed Jul 25 01:28:25 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Jul 2012 23:28:25 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1343172505.14.0.0676176633604.issue15443@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Even if accepted this can't get fixed in 2.7, so removing that from versions.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 01:34:51 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Jul 2012 23:34:51 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343172891.74.0.00861586434788.issue15439@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I agree with Martin and don't think the ACKS list should be exposed further than it already is.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Wed Jul 25 01:40:23 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 23:40:23 +0000
Subject: [issue15444] Incorrectly writen contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343173223.03.0.373576202784.issue15444@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

It seems to be the latter: ?iga Seilnacht

http://mail.python.org/pipermail/python-dev/2007-March/071786.html

----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Wed Jul 25 02:14:27 2012
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 25 Jul 2012 00:14:27 +0000
Subject: [issue15445] Ability to do code injection via logging module
	configuration listener port.
Message-ID: <1343175266.51.0.990414840949.issue15445@psf.upfronthosting.co.za>


New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:

This issue was raised first on security at python.org. Guido responded that not sensitive enough to be kept to the list and that okay to log a bug report.

This issue may not warrant any action except perhaps an update to
documentation for the logging module to warn about it, but thought
that should raise it just in case someone felt it needed actual code
changes to be made to avoid the issue if possible.

The problem arises in the Python logging modules ability to create a
listener socket which can accept new configuration in the ini file
format.

http://docs.python.org/library/logging.config.html#logging.config.listen

"""To send a configuration to the socket, read in the configuration
file and send it to the socket as a string of bytes preceded by a
four-byte length string packed in binary using struct.pack('>L',
n)."""

This sounds innocuous and the documentation at that point doesn't warn
that you are opening yourself up to security problems in using it.

You get a hint of potential issues later if one reads later
documentation about the file format:

"""The class entry indicates the handler?s class (as determined by
eval() in the logging package?s namespace). The level is interpreted
as for loggers, and NOTSET is taken to mean ?log everything?."""

There are other mentions about eval() in context of log level and args
for the handler class as well, but not sure that is used for log level
as it says.

The combination of the open listener port for configuration and that
processing of the configuration file uses eval(), means that one could
send a configuration file to the process containing:

[handler_consoleHandler]
class=os.system('echo security issue') or StreamHandler
level=DEBUG
formatter=simpleFormatter
args=(sys.stdout,)

and one could execute an arbitrary command as the user the process runs as.

The problem is tempered by the fact that someone has to enable the
feature, which is likely rare, but also because socket connections to
send new configuration will only be accepted from the same host
('localhost') and the host can not be overridden. So can only be taken
advantage of by someone (potentially a different user) on the same
host and not remotely at least.

The specific code in Python 3.2 is:

        section = cp["handler_%s" % hand]
        klass = section["class"]
        fmt = section.get("formatter", "")
        try:
            klass = eval(klass, vars(logging))
        except (AttributeError, NameError):
            klass = _resolve(klass)
        args = section["args"]
        args = eval(args, vars(logging))
        h = klass(*args)

and older Python 2.X versions have similar code.

Although you could perhaps avoid need for eval for class lookup, can't
see that you could do that for args unless you restrict it to literal
values and use a more limited eval like parser.

At the minimum there probably should be a warning in the documentation about using the logging module configuration port on untrusted systems with shared users.

----------
components: Library (Lib)
messages: 166343
nosy: grahamd
priority: normal
severity: normal
status: open
title: Ability to do code injection via logging module configuration listener port.
type: security
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15445>
_______________________________________

From report at bugs.python.org  Wed Jul 25 02:18:39 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 00:18:39 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343175519.35.0.885325411565.issue15439@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Is that a -0 then, Raymond?

I think either the combined Misc/ACKS list should be included in the docs, or it should be removed entirely.  If what Meador said is true (that people already in Misc/ACKS who contribute documentation should not be added)--

> Doc/ACKS.txt is *only* for acknowledging documentation contributions.  Serhiy is already in Misc/ACKS.  No need to add him to Doc/ACKS.txt.

http://mail.python.org/pipermail/python-dev/2012-July/121093.html

Then it's not clear to me why the current docs list is meaningful and what exactly it represents.  At the least, the description of the list on the page doesn't match the stated practice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Wed Jul 25 02:25:54 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Jul 2012 00:25:54 +0000
Subject: [issue15445] Ability to do code injection via logging module
	configuration listener port.
In-Reply-To: <1343175266.51.0.990414840949.issue15445@psf.upfronthosting.co.za>
Message-ID: <1343175954.96.0.449141096256.issue15445@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15445>
_______________________________________

From report at bugs.python.org  Wed Jul 25 02:42:23 2012
From: report at bugs.python.org (Vincenzo Ampolo)
Date: Wed, 25 Jul 2012 00:42:23 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343172019.87.0.520346621185.issue15443@psf.upfronthosting.co.za>
Message-ID: <500F40E9.2030208@gmail.com>


Vincenzo Ampolo <vincenzo.ampolo at gmail.com> added the comment:

On 07/24/2012 04:20 PM, R. David Murray wrote:
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> Are the nanosecond timestamps timestamps or strings?  If they are timestamps it's not immediately obvious why you want to convert them to datetime objects, so motivating that would probably help.  On the other hand the fact that you have an application that does so is certain an argument for real world applicability.

It depends. When they are exported for example as csv (this can be the
case of market stock) or json (which is close to my case) that's a
string so having a datetime object may be very helpful in doing datetime
adds, subs, <, deltas and in changing representation to human readable
format thanks to strftime() without loosing precison and maintaining
readability.

Think about a web application. User selects year, month, day, hour,
minute, millisecond, nanosecond of an event and the javascript does a
ajax call with time of this format (variant of iso8601):
YYYY-MM-DDTHH:MM:SS.mmmmmmnnn (where nnn is the nanosecond representation).
The python server takes that string, converts to a datetime, does all
the math with its data and gives the output back using labeling data
with int(nano_datetime.strftime('MMSSmmmmmmnnn')) so I've a sequence
number that javascript can sort and handle easily.

It's basically the same you already do nowadays at microseconds level,
but this time you have to deal with nanosecond data.

I agree with the YAGNI principle and I think that we have a clear
evidence of a real use case here indeed.

Best Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 02:50:12 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Jul 2012 00:50:12 +0000
Subject: [issue15445] Ability to do code injection via logging module
	configuration listener port.
In-Reply-To: <1343175266.51.0.990414840949.issue15445@psf.upfronthosting.co.za>
Message-ID: <1343177412.21.0.263936358224.issue15445@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15445>
_______________________________________

From report at bugs.python.org  Wed Jul 25 03:04:08 2012
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 25 Jul 2012 01:04:08 +0000
Subject: [issue15445] Ability to do code injection via logging module
	configuration listener port.
In-Reply-To: <1343175266.51.0.990414840949.issue15445@psf.upfronthosting.co.za>
Message-ID: <1343178248.7.0.477152010007.issue15445@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

ast.literal_eval() is a good choice for limited evaluation of Python string as it only supports data types like numbers, str, dict etc. but no classes or function calls.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15445>
_______________________________________

From report at bugs.python.org  Wed Jul 25 03:07:48 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 25 Jul 2012 01:07:48 +0000
Subject: [issue15445] Ability to do code injection via logging module
	configuration listener port.
In-Reply-To: <1343175266.51.0.990414840949.issue15445@psf.upfronthosting.co.za>
Message-ID: <1343178468.42.0.718043548784.issue15445@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/issue15445>
_______________________________________

From report at bugs.python.org  Wed Jul 25 03:56:17 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 25 Jul 2012 01:56:17 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343181377.51.0.744082359618.issue15439@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

What I meant by that was that Serhiy contributed a code change and was already in Misc/ACKS, therefore no ACKS file should have been updated.  I didn't mean to imply that someone can't be in both files.  My impression is that Misc/ACKS is for code contributions and Docs/ACKS.txt is for documentation contributions.

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Wed Jul 25 04:07:29 2012
From: report at bugs.python.org (Peter Donis)
Date: Wed, 25 Jul 2012 02:07:29 +0000
Subject: [issue1812] doctest _load_testfile function -- newline handling seems
	incorrect
In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
Message-ID: <1343182049.47.0.670300493559.issue1812@psf.upfronthosting.co.za>


Peter Donis <peterdonis at alum.mit.edu> added the comment:

I recently noticed that there has been a minor code change in the _load_testfile function in doctest, so I generated a new patch against the latest pull from Mercurial (cpython). No actual changes to the issue fix, but this patch should apply cleanly against a checkout from Mercurial. This patch also adds my name to the Misc/ACKS file. :-)

I have not re-done patches in Mercurial's format against any other branches except the default. If this fix is still under consideration, I can generate patches against other branches and test them.

----------
versions: +Python 3.3
Added file: http://bugs.python.org/file26505/doctest-fixes7-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1812>
_______________________________________

From report at bugs.python.org  Wed Jul 25 04:33:26 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Wed, 25 Jul 2012 02:33:26 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343183606.76.0.328158789246.issue15441@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


Removed file: http://bugs.python.org/file26502/test_nonascii_abspath_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Wed Jul 25 04:34:10 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 25 Jul 2012 02:34:10 +0000
Subject: [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343183650.86.0.183967844083.issue15269@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Makes sense. I agree that publicly exposing the left/right attributes makes sense. But let's do it properly:

1. Add an example to the documentation
2. Add some tests to Lib/test/test_filecmp.py that verify these attributes behave as expected

In addition, I think it makes a lot of sense to add an optional "stream" argument to the report() and report_*() methods, to at leas allow reporting to some custom channel and not solely stdout. The report() method does a lot more than your simple example demonstrates, and it's not very easy to replace its functionality.

Would you like to submit a full patch for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15269>
_______________________________________

From report at bugs.python.org  Wed Jul 25 04:37:45 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Wed, 25 Jul 2012 02:37:45 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343183865.4.0.57532649097.issue15441@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

I'm sorry, I generated a patch in wrong direction.

----------
Added file: http://bugs.python.org/file26506/issue15441.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Wed Jul 25 05:06:39 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Wed, 25 Jul 2012 03:06:39 +0000
Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, 
	creates wrong mappings
In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za>
Message-ID: <1343185599.82.0.965857927996.issue15207@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

This patch looks good to me.

I generated a patch for current trunk, with some cosmetic changes.

----------
nosy: +ishimoto
Added file: http://bugs.python.org/file26507/issue15207.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15207>
_______________________________________

From report at bugs.python.org  Wed Jul 25 05:10:25 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 25 Jul 2012 03:10:25 +0000
Subject: [issue11549] Build-out an AST optimizer,
	moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1343185825.87.0.90644847683.issue11549@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/issue11549>
_______________________________________

From report at bugs.python.org  Wed Jul 25 05:18:45 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Wed, 25 Jul 2012 03:18:45 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1343186325.09.0.790960529785.issue2122@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Wed Jul 25 05:44:38 2012
From: report at bugs.python.org (Peter Donis)
Date: Wed, 25 Jul 2012 03:44:38 +0000
Subject: [issue1812] doctest _load_testfile function -- newline handling seems
	incorrect
In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
Message-ID: <1343187878.68.0.568250834959.issue1812@psf.upfronthosting.co.za>


Peter Donis <peterdonis at alum.mit.edu> added the comment:

Updated patch to ensure that tests pass when the -v flag is set running the test suite. This is done by having the helper script, doctest_testfile.py, call doctest.testfile with verbose=False to ensure there is no output if the test passes (which is what the master test_doctest script expects) even if the -v flag is set on the command line.

----------
Added file: http://bugs.python.org/file26508/doctest-fixes8-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1812>
_______________________________________

From report at bugs.python.org  Wed Jul 25 06:52:21 2012
From: report at bugs.python.org (Eric Snow)
Date: Wed, 25 Jul 2012 04:52:21 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343191941.32.0.349320923884.issue15436@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

issue2898 smells like an implementation detail to me. Also, sys.getsizeof() isn't necessarily authoritative here, since the sys module is full of all sorts of implementation details.

I'm not saying __sizeof__ shouldn't be made an official part of the language, but we should be careful before we effectively etch something in stone for all Python implementations.  It may be worth getting feedback from python-dev, particularly from the major Python implementers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Wed Jul 25 06:52:26 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 25 Jul 2012 04:52:26 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343191946.37.0.849744117132.issue15402@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I agree with Martin on having tests for the exact values and the s_len + 1 point.  I will fix both issues.

----------
assignee:  -> meador.inge
nosy:  -python-dev
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Wed Jul 25 07:58:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 05:58:18 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343195898.84.0.889400296668.issue15439@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Okay, thanks for clarifying.  Then I have no strong opinion.

However, if Doc/ACKS.txt is retained, then I think the Dev Guide should mention Doc/ACKS.txt just as it mentions Misc/ACKS:

http://docs.python.org/devguide/patch.html#preparation

And it should include instructions for when to update which files, and the patchcheck script should be suitably modified.  With only ~230 names versus Misc/ACKS's ~1160 , I'm surprised that Doc/ACKS.txt does not have more names -- especially given that it's not uncommon for documentation changes to accompany code changes (or so one might think).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Wed Jul 25 08:18:01 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Jul 2012 06:18:01 +0000
Subject: [issue15444] Incorrectly writen contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343197081.96.0.0412258021097.issue15444@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> It seems to be the latter: ?iga Seilnacht

Then Misc/ACKS should be corrected too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Wed Jul 25 08:25:15 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 06:25:15 +0000
Subject: [issue15444] Incorrectly writen contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343197515.4.0.31462018664.issue15444@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Is there a reason not to correct that spelling in this issue?  Otherwise, we could create a new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Wed Jul 25 08:39:41 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 06:39:41 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343198381.97.0.260152784271.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't know how Doc ACKS is maintained, but I think the devguide is fine as it stands, whether or not Doc ACKS is preserved or not. People should put themselves into Misc/ACKS if they made a contribution, period.

If people need to be acknowledged separately for contributing to the documentation, I think only major contributions (such as writing the documentation for a yet-undocumented module) should be explicitly acknowledged.

I think this all started from the documentation having initially Guido van Rossum given as its sole author, and then later Fred Drake. So Doc/ACKS.txt may have been an attempt to correct the impression that these two are the authors, but I think it went into the wrong direction (eventually leading to the creation of issues such as this one)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Wed Jul 25 09:21:55 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 07:21:55 +0000
Subject: [issue15444] Incorrectly writen contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343200915.25.0.241236707755.issue15444@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

There was a long-standing opposition by Guido to use UTF-8 in that file, and also complaints about legibility. Not sure what the current status is.

It doesn't matter much to me, even though the spelling of my name is affected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Wed Jul 25 09:45:15 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Jul 2012 07:45:15 +0000
Subject: [issue15445] Ability to do code injection via logging module
	configuration listener port.
In-Reply-To: <1343175266.51.0.990414840949.issue15445@psf.upfronthosting.co.za>
Message-ID: <1343202315.06.0.879033517749.issue15445@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15445>
_______________________________________

From report at bugs.python.org  Wed Jul 25 09:45:24 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Jul 2012 07:45:24 +0000
Subject: [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343202324.71.0.474003959923.issue15444@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Well, here is updated patch. Also fixed names of Walter D?rwald (was Walter D?rwald) and Martin von L?wis in Misc/HISTORY.

All changed files (documentation, ACK-files, Misc/HISTORY) already in UTF-8 and contains non-ASCII names.

L?wis written as Loewis in some other places: Lib/idlelib/NEWS.txt, Tools/README, source comments. Same for Marc-Andre (without ?) Lemburg. I?do not think, that it matter in comments, but not sure about NEWS- and README-files.

----------
title: Incorrectly writen contributor's names -> Incorrectly written contributor's names
Added file: http://bugs.python.org/file26509/doc-nonascii-names-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Wed Jul 25 09:51:18 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Jul 2012 07:51:18 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1343202678.9.0.983606445804.issue15443@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

See the PEP 410.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 10:03:23 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Jul 2012 08:03:23 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343203403.37.0.695980484633.issue15441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The following change is a major change on how Python handles undecodable filenames on Windows:

-    return PyUnicode_DecodeMBCS(s, size, NULL);
+    return PyUnicode_DecodeMBCS(s, size, "surrogateescape");

I disagree with this change, Python should not generate surrogates *on Windows*.

By the way, there is also os.fsdecode(), it has the same behaviour than PyUnicode_DecodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize() (it uses the "strict" error handler on Windows).

----------
nosy: +loewis, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Wed Jul 25 10:11:50 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 25 Jul 2012 08:11:50 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343203910.38.0.537487048787.issue15402@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Martin]
> The patch that Meador committed is incorrect: METH_NOARGS functions
> still take a PyObject* args argument, which will be NULL.

Hmm.  I see this usage in a lot of places---e.g. see unicode_capitalize, unicode_casefold, unicode_title etc. in Objects/unicodeobject.c.  So it looks like we're relying on the (PyCFunction) cast to convert from a one-argument function pointer to a two-argument function pointer, which sounds a bit worrisome---I guess it just happens to work with common ABI calling conventions. I'm a bit surprised that we're not seeing compiler warnings about this sort of thing.

[Meador]
> I will happily fix it, but if it is wrong one place, then it is wrong
> everywhere.

It sounds like 'wrong everywhere' is accurate, unfortunately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Wed Jul 25 10:17:27 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 25 Jul 2012 08:17:27 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <500F236C.5030207@gmail.com>
Message-ID: <500FAB91.7000106@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Vincenzo Ampolo wrote:
> 
> Vincenzo Ampolo <vincenzo.ampolo at gmail.com> added the comment:
> 
> This is a real use case I'm working with that needs nanosecond precision
> and lead me in submitting this request:
> 
> most OSes let users capture network packets (using tools like tcpdump or
> wireshark) and store them using file formats like pcap or pcap-ng. These
> formats include a timestamp for each of the captured packets, and this
> timestamp usually has nanosecond precision. The reason is that on
> gigabit and 10 gigabit networks the frame rate is so high that
> microsecond precision is not enough to tell two frames apart.
> pcap (and now pcap-ng) are extremely popular file formats, with millions
> of files stored around the world. Support for nanoseconds in datetime
> would make it possible to properly parse these files inside python to
> compute precise statistics, for example network delays or round trip times.
> 
> Other case is in stock markets. In that field information is timed in
> nanoseconds and have the ability to easily deal with this kind of
> representation natively with datetime can make the standard module even
> more powerful.
> 
> The company I work for is in the data networking field, and we use
> python extensively. Currently we rely on custom code to process
> timestamps, a nanosecond datetime would let us avoit that and use
> standard python datetime module.

Thanks for the two use cases.

You might want to look at mxDateTime and use that for your timestamps.
It does provide full C double precision for the time part of a timestamp,
which covers nanoseconds just fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 10:17:35 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Jul 2012 08:17:35 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343204255.55.0.363445520738.issue15441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> If a file name was invalid byte character, os.chdir() raises
> UnicodeDecodeError() instead of WindowsError.

I realized that the problem is in the error handling: raising the OSError fails with a UnicodeDecodeError because PyErr_SetFromWindowsErrWithFilename() calls PyUnicode_DecodeFSDefault(), whereas the filename is not decodable. If you want to change something, it should be PyErr_SetFromWindowsErrWithFilename(). We may use PyObject_Repr() or PyObject_ASCII() for example.

--

See also the issue #13374: "The Windows bytes API has been deprecated in the os module. Use Unicode filenames instead of bytes filenames to not depend on the ANSI code page anymore and to support any filename."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Wed Jul 25 10:33:55 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Wed, 25 Jul 2012 08:33:55 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343205235.75.0.373791519501.issue15441@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Yes, I know #13374, that's why I wrote

> This is a byte-api issue on Windows, so we may be able to simply skip 
> this test.

Do you think we need a patch to avoid UnicodeDecodeError raised? 
Or should we change test to skip this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Wed Jul 25 10:44:42 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 25 Jul 2012 08:44:42 +0000
Subject: [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343202324.71.0.474003959923.issue15444@psf.upfronthosting.co.za>
Message-ID: <500FB1F5.9070709@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Thank you for taking the initiative. Regarding use of UTF-8 for text files:

I think we ought to acknowledge that UTF-8 has become the defacto standard
for non-ASCII text files by now and with Python 3 being all Unicode, it
feels silly not make use of it in Python source files.

Regarding my name: I have no issue with the apostrophe missing on the e.
I've long given up using it in source code or emails :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Wed Jul 25 10:49:51 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Jul 2012 08:49:51 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <3WhqrG1zPTzPSs@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a82fd35e28be by Martin v. L?wis in branch '3.2':
Issue #15318: Prevent writing to sys.stdin.
http://hg.python.org/cpython/rev/a82fd35e28be

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 25 10:56:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Jul 2012 08:56:35 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <3Whr016CpyzPSn@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fa7d4ecc6357 by Martin v. L?wis in branch '2.7':
Issue #15318: Prevent writing to sys.stdin.
http://hg.python.org/cpython/rev/fa7d4ecc6357

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 25 10:57:02 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 08:57:02 +0000
Subject: [issue15318] IDLE - sys.stdin is writeable
In-Reply-To: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>
Message-ID: <1343206622.23.0.876066652802.issue15318@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15318>
_______________________________________

From report at bugs.python.org  Wed Jul 25 10:59:08 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 25 Jul 2012 08:59:08 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343206748.39.0.593987484211.issue15438@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Agreed that this is at worst a doc issue.

[Antoine]
> and in all honesty I don't know the difference between the "**" operator
> and the built-in pow() function :-)

None, as far as I know, apart from the pow function's ability to take a 3rd argument.  Both ultimately call PyNumber_Power, and the various type-specific __pow__ methods take over from there.  [+1 for removing pow from the builtins and shunting three-argument pow to the math module in Python 5000000.]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Wed Jul 25 11:01:18 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 09:01:18 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1343091921.38.0.635974086873.issue15402@psf.upfronthosting.co.za>
Message-ID: <500FB5D8.5000205@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I will happily fix it, but if it is wrong one place, then it is wrong
> everywhere.

Yes, it is wrong everywhere. METH_NOARGS functions do take an
args argument, see ceval.c:call_function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Wed Jul 25 11:06:26 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 09:06:26 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1343203910.38.0.537487048787.issue15402@psf.upfronthosting.co.za>
Message-ID: <500FB710.6090205@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Hmm.  I see this usage in a lot of places---e.g. see
> unicode_capitalize, unicode_casefold, unicode_title etc. in
> Objects/unicodeobject.c.  So it looks like we're relying on the
> (PyCFunction) cast to convert from a one-argument function pointer to
> a two-argument function pointer, which sounds a bit worrisome---I
> guess it just happens to work with common ABI calling conventions.
> I'm a bit surprised that we're not seeing compiler warnings about
> this sort of thing.

The compiler has no chance to find out. You cast the pointer to
PyCFunction, telling the compiler that it really is a PyCFunction.

I really wish we could put a ban on function pointer casts, and try
to make this all statically type-correct. This, of course, would
require the sizeof function to take PyObject*, and cast it to
PyStructObject * locally. My idiom for that is

static PyObject *
s_sizeof(PyStructObject *_self, PyObject *unused)
{
  PyStructObject *self = (PyStructObject *)_self;

> It sounds like 'wrong everywhere' is accurate, unfortunately.

"Everywhere" is nowhere close to the truth. There are tons of
NOARGS functions which have the correct signature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Wed Jul 25 11:19:51 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Jul 2012 09:19:51 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343205235.75.0.373791519501.issue15441@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYe1CCRE=mDRxxfz1jEqpbP7Z_0v6=9XUfAtUajU-dupA@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Do you think we need a patch to avoid UnicodeDecodeError raised?
> Or should we change test to skip this?

It's a bug, the test should not be skipped. You should get an OSError
because the chdir() failed, not an UnicodeDecodeError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Wed Jul 25 11:23:59 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 09:23:59 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343208239.22.0.869271161153.issue15441@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

IMO, it is ok to skip the test on Windows; it was apparently targeted for Unix.

If we preserve it, we should pick a file name (on Windows) which is encodable in the file system encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Wed Jul 25 11:25:36 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 09:25:36 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343208336.56.0.319918402823.issue15441@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As for your patch: you are missing the point of the test. The file name is assumed to be valid, despite it not being in the file system encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Wed Jul 25 11:33:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Jul 2012 09:33:14 +0000
Subject: [issue7163] IDLE suppresses sys.stdout.write() return value
In-Reply-To: <1255819083.11.0.568760312973.issue7163@psf.upfronthosting.co.za>
Message-ID: <3WhrpK41xfzPQG@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f72965374b2a by Martin v. L?wis in branch '3.2':
Issue #7163: Propagate return value of sys.stdout.write.
http://hg.python.org/cpython/rev/f72965374b2a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7163>
_______________________________________

From report at bugs.python.org  Wed Jul 25 11:33:55 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 09:33:55 +0000
Subject: [issue7163] IDLE suppresses sys.stdout.write() return value
In-Reply-To: <1255819083.11.0.568760312973.issue7163@psf.upfronthosting.co.za>
Message-ID: <1343208835.9.0.218844276837.issue7163@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/issue7163>
_______________________________________

From report at bugs.python.org  Wed Jul 25 11:51:56 2012
From: report at bugs.python.org (Arseniy)
Date: Wed, 25 Jul 2012 09:51:56 +0000
Subject: [issue15446] Recursion SIGSEGV
Message-ID: <1343209916.8.0.539933820287.issue15446@psf.upfronthosting.co.za>


New submission from Arseniy <senyai at gmail.com>:

a=lambda:a
print eval("a" + "()" * 999999)

----------
components: None
messages: 166378
nosy: senyai
priority: normal
severity: normal
status: open
title: Recursion SIGSEGV
type: crash
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15446>
_______________________________________

From report at bugs.python.org  Wed Jul 25 11:54:51 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 09:54:51 +0000
Subject: [issue15363] Idle/tkinter ~x.py 'save as' fails. closes idle
In-Reply-To: <1342394243.7.0.336788716257.issue15363@psf.upfronthosting.co.za>
Message-ID: <1343210091.41.0.221952656756.issue15363@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think this should apply to all systems, and I think the proper escaping is with "./", see TclpNativeSplitPath (in Tcl's source code).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15363>
_______________________________________

From report at bugs.python.org  Wed Jul 25 12:29:12 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 25 Jul 2012 10:29:12 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343212152.25.0.124964823326.issue15402@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> The compiler has no chance to find out. You cast the pointer to
> PyCFunction, telling the compiler that it really is a PyCFunction.

True; I was thinking that the compiler should have the necessary information to warn about the suspicious (PyCFunction) cast.  But then again the function pointer cast is perfectly legal---it's the subsequent call that invokes undefined behaviour, and that's in a different file, so the compiler can't help.

> "Everywhere" is nowhere close to the truth.

Yep, sorry;  bad wording on my part.  I didn't intend to imply that all uses of METH_NOARGS had this problem.  'Everywhere' for very small values of 'everywhere'. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Wed Jul 25 12:59:29 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 Jul 2012 10:59:29 +0000
Subject: [issue14930] Make memoryview weakrefable
In-Reply-To: <1338152760.41.0.3704127468.issue14930@psf.upfronthosting.co.za>
Message-ID: <1343213969.83.0.44488923735.issue14930@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

A quick question: Prior to this patch test_memoryview.py exercised
both mbuf_clear() and memory_clear(). Now gcov shows no coverage.

Is this expected? Is it still possible to construct tests that
exercise the code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14930>
_______________________________________

From report at bugs.python.org  Wed Jul 25 13:00:42 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 25 Jul 2012 11:00:42 +0000
Subject: [issue15445] Ability to do code injection via logging module
	configuration listener port.
In-Reply-To: <1343175266.51.0.990414840949.issue15445@psf.upfronthosting.co.za>
Message-ID: <1343214042.08.0.103758541413.issue15445@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I think it is sufficient for 2.7, 3.2 and 3.3 to just update the documentation, as Graham says, using "note" markup so that it stands out.

I can look at ast.literal_eval as an option for 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15445>
_______________________________________

From report at bugs.python.org  Wed Jul 25 13:24:29 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 25 Jul 2012 11:24:29 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1343215469.78.0.23187921367.issue15443@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Wed, Jul 25, 2012 at 4:17 AM, Marc-Andre Lemburg <report at bugs.python.org> wrote:
> ... full C double precision for the time part of a timestamp,
> which covers nanoseconds just fine.

No, it does not:

>>> import time
>>> t = time.time()
>>> t + 5e-9 == t
True

In fact, C double precision is barely enough to cover microseconds:

>>> t + 1e-6 == t
False

>>> t + 1e-7 == t
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 13:36:27 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 Jul 2012 11:36:27 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343216187.77.0.808769635373.issue15402@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

""Everywhere" is nowhere close to the truth. There are tons of
NOARGS functions which have the correct signature."

When I started writing C-extensions, I used the PyObject *unused
idiom. Then I saw Meador's version in so many places in the source
tree that I assumed it's correct.

I think raising this issue on python-dev would be beneficial.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Wed Jul 25 13:38:44 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Jul 2012 11:38:44 +0000
Subject: [issue15446] Eval Recursion SIGSEGV
In-Reply-To: <1343209916.8.0.539933820287.issue15446@psf.upfronthosting.co.za>
Message-ID: <1343216324.94.0.416947287062.issue15446@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> stack overflow evaluating eval("()" * 30000)
title: Recursion SIGSEGV -> Eval Recursion SIGSEGV

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15446>
_______________________________________

From report at bugs.python.org  Wed Jul 25 13:40:34 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 25 Jul 2012 11:40:34 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343215469.78.0.23187921367.issue15443@psf.upfronthosting.co.za>
Message-ID: <500FDB2D.7040302@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:
> 
> On Wed, Jul 25, 2012 at 4:17 AM, Marc-Andre Lemburg <report at bugs.python.org> wrote:
>> ... full C double precision for the time part of a timestamp,
>> which covers nanoseconds just fine.
> 
> No, it does not:
> 
>>>> import time
>>>> t = time.time()
>>>> t + 5e-9 == t
> True
> 
> In fact, C double precision is barely enough to cover microseconds:
> 
>>>> t + 1e-6 == t
> False
> 
>>>> t + 1e-7 == t
> True

I was referring to the use of a C double to store the time part
in mxDateTime. mxDateTime uses the C double to store the number of
seconds since midnight, so you don't run into the Unix ticks value
range problem you showcased above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 13:45:09 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 25 Jul 2012 11:45:09 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <500FDB2D.7040302@egenix.com>
Message-ID: <500FDC3F.8000501@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
>> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:
>>
>> On Wed, Jul 25, 2012 at 4:17 AM, Marc-Andre Lemburg <report at bugs.python.org> wrote:
>>> ... full C double precision for the time part of a timestamp,
>>> which covers nanoseconds just fine.
>>
>> No, it does not:
>>
>>>>> import time
>>>>> t = time.time()
>>>>> t + 5e-9 == t
>> True
>>
>> In fact, C double precision is barely enough to cover microseconds:
>>
>>>>> t + 1e-6 == t
>> False
>>
>>>>> t + 1e-7 == t
>> True
> 
> I was referring to the use of a C double to store the time part
> in mxDateTime. mxDateTime uses the C double to store the number of
> seconds since midnight, so you don't run into the Unix ticks value
> range problem you showcased above.

There's enough room to even store 1/100th of a nanosecond, which may
be needed for some physics experiments :-)

False
>>> x == x + 1e-10
False
>>> x == x + 1e-11
False
>>> x == x + 1e-12
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 13:46:41 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 25 Jul 2012 11:46:41 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <500FDC3F.8000501@egenix.com>
Message-ID: <500FDC9C.1030600@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

[Roundup's email interface again...]

>>>> x = 86400.0
>>>> x == x + 1e-9
> False
>>>> x == x + 1e-10
> False
>>>> x == x + 1e-11
> False
>>>> x == x + 1e-12
> True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 13:55:45 2012
From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=)
Date: Wed, 25 Jul 2012 11:55:45 +0000
Subject: [issue15424] __sizeof__ of array should include size of items
In-Reply-To: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za>
Message-ID: <1343217345.12.0.0160954357979.issue15424@psf.upfronthosting.co.za>


Ludwig H?hne <wkx at gmx.li> added the comment:

Revised the patch based on the discussion in issue #15402 (http://bugs.python.org/msg166372). It doesn't typecast the function anymore and instead casts to the array type inside the function.

----------
Added file: http://bugs.python.org/file26510/array_sizeof_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15424>
_______________________________________

From report at bugs.python.org  Wed Jul 25 14:02:09 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 25 Jul 2012 12:02:09 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343217729.87.0.699571666859.issue15402@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I think that C standard actually documents the parameter order placement, so you can left out the last ones in the actual function definition.

So, that this is working is not an accident, it is a C standard requirement.

I think...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Wed Jul 25 14:33:59 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 12:33:59 +0000
Subject: [issue15275] isinstance is called a more times that needed in ntpath
In-Reply-To: <1341668298.8.0.671820953585.issue15275@psf.upfronthosting.co.za>
Message-ID: <1343219639.64.0.446952280059.issue15275@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I don't know about a decent way of doing benchmarks for the changes.
> Any recommendation?

You could make a script that uses the timeit module.

>> If this patch is applied I think it would be good to change
>> posixpath too.
> I agree and I'd love to do it but in a diff bug to make things
> self-contained, what do you think?

Having a single patch that fixes both is OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15275>
_______________________________________

From report at bugs.python.org  Wed Jul 25 15:11:19 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 13:11:19 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343221879.7.0.126490490227.issue15402@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Jes?s: this is a (common) mistake. Standard C makes it undefined behavior to call a function with an incorrect number of arguments, see 6.5.2.2p9

# If the function is de?ned with a type that is not compatible with the 
# type (of the expression) pointed to by the expression that denotes the 
# called function, the behavior is unde?ned.

Two function pointers are compatible if the function types are compatible (6.7.5.1p2), which in turn is defined in 6.7.5.3p15,
which is too long to quote here.

Your understanding of the parameter passing convention is not part of the language definition. The only way to have more parameters in the call than are declared is by means of an ellipsis. 

There is an exception for "old style" (K&R) functions and declarations, but it doesn't apply here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Wed Jul 25 15:15:13 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Wed, 25 Jul 2012 13:15:13 +0000
Subject: [issue15447] A file is not properly closed by webbrowser._invoke
Message-ID: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za>


New submission from Anton Barkovsky <swarmer.pm at gmail.com>:

webbrowser._invoke opens /dev/null, never closes it and a warning is
printed.

I'm attaching a patch.
The diff looks messy, but I'm just wrapping the code in a try-finally
block, the rest is just indented.

----------
components: Library (Lib)
files: fileclose.patch
keywords: patch
messages: 166392
nosy: anton.barkovsky
priority: normal
severity: normal
status: open
title: A file is not properly closed by webbrowser._invoke
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file26511/fileclose.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15447>
_______________________________________

From report at bugs.python.org  Wed Jul 25 15:22:28 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 13:22:28 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343222548.06.0.588448386239.issue15402@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Stefan: not sure whether raising this to python-dev really helps; see also  msg42177, msg58196, issue1648268, and msg75239. Feel free to raise it, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Wed Jul 25 15:31:49 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Jul 2012 13:31:49 +0000
Subject: [issue15447] A file is not properly closed by webbrowser._invoke
In-Reply-To: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za>
Message-ID: <1343223109.03.0.799542028274.issue15447@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.  Is this warning printed by the webbrowser unit tests?  If not can you see a way to add one that does?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15447>
_______________________________________

From report at bugs.python.org  Wed Jul 25 15:38:05 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Wed, 25 Jul 2012 13:38:05 +0000
Subject: [issue15447] A file is not properly closed by webbrowser._invoke
In-Reply-To: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za>
Message-ID: <1343223485.35.0.74965952419.issue15447@psf.upfronthosting.co.za>


Anton Barkovsky <swarmer.pm at gmail.com> added the comment:

The warning is printed by the file object when it closes itself in __del__:

  ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r+' encoding='UTF-8'>

There isn't much to test, or is there?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15447>
_______________________________________

From report at bugs.python.org  Wed Jul 25 15:39:11 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Wed, 25 Jul 2012 13:39:11 +0000
Subject: [issue15447] A file is not properly closed by webbrowser._invoke
In-Reply-To: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za>
Message-ID: <1343223551.31.0.074940653696.issue15447@psf.upfronthosting.co.za>


Anton Barkovsky <swarmer.pm at gmail.com> added the comment:

To clarify, I discovered this when I was simply running webbrowser.open
in REPL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15447>
_______________________________________

From report at bugs.python.org  Wed Jul 25 15:43:09 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 25 Jul 2012 13:43:09 +0000
Subject: [issue15447] A file is not properly closed by webbrowser._invoke
In-Reply-To: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za>
Message-ID: <1343223789.34.0.424743554004.issue15447@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Are there any webbrowser unit tests?

(this could probably use the new subprocess.DEVNULL constant in 3.3)

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15447>
_______________________________________

From report at bugs.python.org  Wed Jul 25 15:46:34 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 25 Jul 2012 13:46:34 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343223994.19.0.657489710321.issue15438@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

> [+1 for removing pow from the builtins and shunting three-argument pow to the math module in Python 5000000.]
Me too.
Anybody who uses pow with to arguments can use arg1**arg2
Anybody who uses pow with three is doing something mathematical and has most likely imported math already.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Wed Jul 25 15:48:17 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Jul 2012 13:48:17 +0000
Subject: [issue15447] A file is not properly closed by webbrowser._invoke
In-Reply-To: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za>
Message-ID: <1343224097.14.0.868795082291.issue15447@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

@Anton: That's what I was guessing.  If we had a unit test in test_webbrowser that did the same thing, we'd have seen the resource warning when running the tests and fixed it.  However, it looks like there aren't *any* tests for webbrowser, not even in test_sundry (which just makes sure modules without tests are importable).

So adding a test that will trigger this resource warning requires setting up a test_webbrowser file first, even before we get to the problem of how to test something that wants to start up a web browser...(but that should be solvable with unittest.mock, I think).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15447>
_______________________________________

From report at bugs.python.org  Wed Jul 25 15:53:51 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 Jul 2012 13:53:51 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343224431.85.0.00876957695118.issue12834@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Here's a patch for 3.3, which consists mostly of tests. A couple of points:

  o I removed the len > view->len check in PyBuffer_ToContiguous(), since
    the function is not documented and silently accepting output buffers
    that are too large seems unusual to me.

  o Removed the comment in bytesobject.c "Better way to get to internal buffer?".
    IMO the answer is no: There isn't any better way that works in full generality.

  o Removed the "need to check for overflow" comment: ndim is now officially
    limited to 64.


I think this can go into 3.3: It's easy to see that for contiguous buffers
PyBuffer_ToContiguous() behaves in the same manner as before (except for
the len issue).

For memoryview, buffer_to_contiguous(x, y 'C') is literally the same
code as buffer_to_c_contiguous().

----------
keywords: +patch
Added file: http://bugs.python.org/file26512/issue12834.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Wed Jul 25 16:01:37 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Wed, 25 Jul 2012 14:01:37 +0000
Subject: [issue15447] A file is not properly closed by webbrowser._invoke
In-Reply-To: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za>
Message-ID: <1343224897.89.0.402360287614.issue15447@psf.upfronthosting.co.za>


Anton Barkovsky <swarmer.pm at gmail.com> added the comment:

Adding a patch that uses subprocess.DEVNULL instead.

Writing tests for webbrowser should be a separate issue, right?

----------
Added file: http://bugs.python.org/file26513/fileclose_devnull.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15447>
_______________________________________

From report at bugs.python.org  Wed Jul 25 16:03:27 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 Jul 2012 14:03:27 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343223994.19.0.657489710321.issue15438@psf.upfronthosting.co.za>
Message-ID: <20120725140328.GA28999@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Ramchandra Apte <report at bugs.python.org> wrote:
> > [+1 for removing pow from the builtins and shunting three-argument pow to the math module in Python 5000000.]
> Anybody who uses pow with three is doing something mathematical and has most likely imported math already.

Wouldn't that reinforce the misconception that math is for arbitrary precision
number theoretical functions? The OP used it for cryptography.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Wed Jul 25 16:13:11 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 25 Jul 2012 14:13:11 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343225591.3.0.106542743952.issue15438@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Wouldn't that reinforce the misconception that math is for arbitrary
> precision number theoretical functions?

Perhaps.  We already have math.factorial, though;  adding math.powmod wouldn't seem so much of a stretch.  Just to be clear, I'm not seriously proposing this for any version of Python before 4.0; apologies for derailing the issue thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Wed Jul 25 16:27:53 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Jul 2012 14:27:53 +0000
Subject: [issue15447] A file is not properly closed by webbrowser._invoke
In-Reply-To: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za>
Message-ID: <1343226473.18.0.221746423215.issue15447@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You could do it either way.  Normally we prefer to have a test along with any fix; in this case adding a test involves adding the test module as well, but it is not different in principle.  If you want to work on it and prefer to have it as a separate issue that's fine, we'll just make the test issue dependent on this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15447>
_______________________________________

From report at bugs.python.org  Wed Jul 25 17:11:37 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 25 Jul 2012 15:11:37 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343229097.06.0.105686193829.issue15402@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

While looking this up in the C Standard (ISO/IEC 9899:TC3) I also noticed 6.3.2.3p8:

"""
A pointer to a function of one type may be converted to a pointer to a function of another
type and back again; the result shall compare equal to the original pointer. If a converted
pointer is used to call a function whose type is not compatible with the pointed-to type, the behavior is undefined.
"""

I will add the 'unused' parameter back with my refresh patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Wed Jul 25 17:38:51 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 25 Jul 2012 15:38:51 +0000
Subject: [issue14930] Make memoryview weakrefable
In-Reply-To: <1338152760.41.0.3704127468.issue14930@psf.upfronthosting.co.za>
Message-ID: <1343230731.72.0.135581030223.issue14930@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Is it possible that the use of test.support.gc_collect() in test_memoryview made the difference?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14930>
_______________________________________

From report at bugs.python.org  Wed Jul 25 17:59:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 15:59:29 +0000
Subject: [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343231969.52.0.664252258377.issue15444@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

To be clear on this issue's scope, I would state in a single comment a white list of which directories or individual files are being corrected (or if necessary, the rules to determine such a list, e.g. any file whose name root is "NEWS", etc).

I would also recommend being systematic about this by creating a script to search the above files, along with a configuration section containing the list of replacements: e.g. correct spelling -> list of misspellings for that name.  And upload the script to this issue.  That way people can see what misspellings have already been accounted for, more could be added easily, and it could be used again if necessary.

Because this may grow in scope (e.g. into source files) and because it affects people's names, it may be worth raising on python-dev.  At the least, people would have the chance to contribute known misspellings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Wed Jul 25 18:10:53 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 16:10:53 +0000
Subject: [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343232653.3.0.224179250425.issue15444@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Make sure that it's still possible to generate the pdf of the docs (with `make latex` and then `make all-pdf` in build/latex/).
Latin1 should be fine, but IIRC non-latin1 will break (sorry ?iga).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Wed Jul 25 18:29:39 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 16:29:39 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343233779.55.0.369301463553.issue15439@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW including Misc/ACKS in the doc will probably break the generation of the pdf version of the doc, since it contains non-latin1 characters (see msg166408).  I don't think it's necessary to include the names in the doc.

> I don't know how Doc ACKS is maintained, but I think the devguide is
> fine as it stands, whether or not Doc ACKS is preserved or not. 
> People should put themselves into Misc/ACKS if they made a 
> contribution, period.

In my experience Doc/ACKS.txt is mostly ignored/unmaintained.  I did a lot of work on the docs and my name is not in there, and I don't think I ever added anyone there.

> If people need to be acknowledged separately for contributing to the
> documentation, I think only major contributions (such as writing the 
> documentation for a yet-undocumented module) should be explicitly 
> acknowledged.

It's already possible to give credit directly in the docs using directives like "sectionauthor".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Wed Jul 25 18:37:21 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 16:37:21 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343234241.96.0.669829229239.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

OK, I propose to completely drop the Doc/ACKS.txt from the documentation, and replace it with the words

"Many people have contributed to the Python language, the Python standard library, and the Python documentation. See Misc/ACKS in the Python source distribution for a partial list of contributors"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Wed Jul 25 18:42:00 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 16:42:00 +0000
Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343234520.2.0.824656133434.issue15437@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think the docs should display Misc/ACKS. Instead, I propose the following wording

"Many people have contributed to the Python language, the Python standard library, and the Python documentation. See Misc/ACKS in the Python source distribution for a partial list of contributors"

It might be useful to link "Misc/ACKS" to http://hg.python.org/cpython/file/default/Misc/ACKS
(http://hg.python.org/cpython/raw-file/default/Misc/ACKS would be better if hgweb wouldn't declare that application/octet-stream)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Wed Jul 25 18:45:22 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 Jul 2012 16:45:22 +0000
Subject: [issue14930] Make memoryview weakrefable
In-Reply-To: <1343230731.72.0.135581030223.issue14930@psf.upfronthosting.co.za>
Message-ID: <20120725164523.GA30273@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Sorry folks, I messed up the revisions when testing. This commit has
nothing to do with the decreased coverage.

Now I properly bisected and in r75481 mbuf_clear() and memory_clear()
are still covered, but in r75484 they are not.

r75484 addresses #1469629. I've got to figure out whether the changed
behavior is expected or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14930>
_______________________________________

From report at bugs.python.org  Wed Jul 25 18:50:07 2012
From: report at bugs.python.org (Richard Moseley)
Date: Wed, 25 Jul 2012 16:50:07 +0000
Subject: [issue15448] utimes() functions fail with ENOSYS even when detected
	by configure
Message-ID: <1343235007.8.0.870502159269.issue15448@psf.upfronthosting.co.za>


New submission from Richard Moseley <dickie.moseley at virgin.net>:

When building on a ASUS Eee PC 1000 running the original Xandros O/S with libc-2.7-13, the various utimes() functions are being detected as available for use, everything compiles. However, during installation of the lib-dynload libraries, the error 'Error: Function not implemented' is given and the installation halts.

This problem has been tracked down to the fact that some of the utimes() functions will return ENOSYS rather than the expected result.

I have now patched the configure.ac script to check for the seven variants of the function, which is attached. This patch would ideally have made use of the same model as the AC_CHCEK_FUNCS macro but this would require adding a new file to the source tree.

----------
components: Build
files: configure.ac.diff
keywords: patch
messages: 166413
nosy: richmose
priority: normal
severity: normal
status: open
title: utimes() functions fail with ENOSYS even when detected by configure
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file26514/configure.ac.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15448>
_______________________________________

From report at bugs.python.org  Wed Jul 25 18:53:24 2012
From: report at bugs.python.org (Vincenzo Ampolo)
Date: Wed, 25 Jul 2012 16:53:24 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1343235204.99.0.73204083424.issue15443@psf.upfronthosting.co.za>


Vincenzo Ampolo <vincenzo.ampolo at gmail.com> added the comment:

Have a look to this python dev mailing list thread too:

http://mail.python.org/pipermail/python-dev/2012-July/121123.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Wed Jul 25 18:54:11 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 16:54:11 +0000
Subject: [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343235251.02.0.999783324997.issue15444@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Indeed, PDF rendering is important. OTOH, Latex T1 does support ?. Untested, \v{Z} should generate that character. If this doesn't work, the build process needs to be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Wed Jul 25 19:03:32 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 Jul 2012 17:03:32 +0000
Subject: [issue14930] Make memoryview weakrefable
In-Reply-To: <1338152760.41.0.3704127468.issue14930@psf.upfronthosting.co.za>
Message-ID: <1343235812.57.0.228260325014.issue14930@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

r75484 should be b595e1ad5722.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14930>
_______________________________________

From report at bugs.python.org  Wed Jul 25 20:20:55 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Jul 2012 18:20:55 +0000
Subject: [issue15445] Ability to do code injection via logging module
	configuration listener port.
In-Reply-To: <1343175266.51.0.990414840949.issue15445@psf.upfronthosting.co.za>
Message-ID: <3Wj4WB0Ll7zPdX@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f30b49a5072e by Vinay Sajip in branch '2.7':
Issue #15445: Updated logging configuration documentation to highlight potential security risk posed by listen() in certain scenarios.
http://hg.python.org/cpython/rev/f30b49a5072e

New changeset e5d7d202f2bf by Vinay Sajip in branch '3.2':
Issue #15445: Updated logging configuration documentation to highlight potential security risk posed by listen() in certain scenarios.
http://hg.python.org/cpython/rev/e5d7d202f2bf

New changeset 410be02de1c6 by Vinay Sajip in branch 'default':
Closes #15445: Merged documentation update from 3.2.
http://hg.python.org/cpython/rev/410be02de1c6

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15445>
_______________________________________

From report at bugs.python.org  Wed Jul 25 20:26:34 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 18:26:34 +0000
Subject: [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343240794.89.0.451499786623.issue15269@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks a lot, Eli, and for the suggestions.  I would be happy to prepare a full patch.

Regarding the stream argument, I think there are other changes to dircmp that would be more useful (e.g. issue 12932), but I agree that some form of your suggestion makes sense.  Would you mind if I created a separate issue for it to discuss there?  I have some suggestions on it, and I would be happy to work on it there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15269>
_______________________________________

From report at bugs.python.org  Wed Jul 25 20:42:04 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 18:42:04 +0000
Subject: [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343241724.38.0.415429810219.issue15444@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Indeed, PDF rendering is important. OTOH, Latex T1 does support ?.

I tried to put a ? directly in an rst source and indeed the pdf has been created correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Wed Jul 25 20:55:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 25 Jul 2012 18:55:23 +0000
Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343242523.61.0.317780329826.issue15437@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We can just use :source:`Misc/ACKS` and it will created a link to hgweb (the colored HTML page, not the raw file).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15437>
_______________________________________

From report at bugs.python.org  Wed Jul 25 21:38:46 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Jul 2012 19:38:46 +0000
Subject: [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343232653.3.0.224179250425.issue15444@psf.upfronthosting.co.za>
Message-ID: <201207252238.26355.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

All names interpreted correctly except cyrillic (Alexander ?????? Belopolsky 
and ???? ?????????). I think it's just because of lack of some non-installed 
package (of course, Latex supports cyrillic).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Wed Jul 25 22:15:48 2012
From: report at bugs.python.org (Sworddragon)
Date: Wed, 25 Jul 2012 20:15:48 +0000
Subject: [issue15449] Optional size argument for readline()
Message-ID: <1343247348.26.0.437825831921.issue15449@psf.upfronthosting.co.za>


New submission from Sworddragon <sworddragon2 at aol.com>:

For file objects the read() function has the optional size argument to limit the data that will be read. I'm wondering why there isn't such an argument for readline(). Theoretically lines in a file could have million of characters and even much more. An optional limit could prevent that a high amount of data will be load into the memory.

----------
components: Library (Lib)
messages: 166422
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Optional size argument for readline()
type: enhancement
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15449>
_______________________________________

From report at bugs.python.org  Wed Jul 25 22:28:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Jul 2012 20:28:25 +0000
Subject: [issue12605] Enhancements to gdb 7 debugging hooks
In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za>
Message-ID: <1343248105.58.0.937157214662.issue12605@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Dave, test_gdb fails consistently on the ARM buildbot:


======================================================================
FAIL: test_threads (test.test_gdb.PyBtTests)
Verify that "py-bt" indicates threads that are waiting for the GIL
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_gdb.py", line 706, in test_threads
    self.assertIn('Waiting for the GIL', gdb_output)
AssertionError: 'Waiting for the GIL' not found in 'Breakpoint 1 at 0x9e36a: file Python/bltinmodule.c, line 962.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".\n[New Thread 0x2b2b2470 (LWP 8779)]\n[New Thread 0x2b5ff470 (LWP 8780)]\n[New Thread 0x2b8ff470 (LWP 8781)]\n[New Thread 0x2baff470 (LWP 8782)]\n\nBreakpoint 1, builtin_id (self=<module at remote 0x2aca5638>, v=42) at Python/bltinmodule.c:962\n962\t    return PyLong_FromVoidPtr(v);\n\nThread 5 (Thread 0x2baff470 (LWP 8782)):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/threading.py", line 639, in _bootstrap_inner\n    self.run()\n  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/threading.py", line 616, in _bootstrap\n    self._bootstrap_inner()\n\nThread 4 (Thread 0x2b8ff470 (LWP 8781)):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/threading.py", line 639, in _bootstrap_inner\n    self.run()\n  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/threading.py", line 616, in _bootstrap\n    self._bootstrap_inner()\n\nThread 3 (Thread 0x2b5ff470 (LWP 8780)):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/threading.py", line 639, in _bootstrap_inner\n    self.run()\n  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/threading.py", line 616, in _bootstrap\n    self._bootstrap_inner()\n\nThread 2 (Thread 0x2b2b2470 (LWP 8779)):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/threading.py", line 639, in _bootstrap_inner\n    self.run()\n  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/threading.py", line 616, in _bootstrap\n    self._bootstrap_inner()\n\nThread 1 (Thread 0x2aac5300 (LWP 8776)):\nTraceback (most recent call first):\n  File "<string>", line 18, in <module>\n'


http://buildbot.python.org/all/builders/ARM%20Ubuntu%203.x

----------
stage: patch review -> committed/rejected
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12605>
_______________________________________

From report at bugs.python.org  Wed Jul 25 22:31:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Jul 2012 20:31:48 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343248308.58.0.507646918364.issue15431@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +kristjan.jonsson, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Wed Jul 25 22:35:15 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Jul 2012 20:35:15 +0000
Subject: [issue15449] Optional size argument for readline()
In-Reply-To: <1343247348.26.0.437825831921.issue15449@psf.upfronthosting.co.za>
Message-ID: <1343248515.54.0.405498217776.issue15449@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, it does:
http://docs.python.org/dev/library/io.html#io.IOBase.readline

?readline(limit=-1)

    Read and return one line from the stream. If limit is specified, at most limit bytes will be read.?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15449>
_______________________________________

From report at bugs.python.org  Wed Jul 25 22:35:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Jul 2012 20:35:31 +0000
Subject: [issue15449] Optional size argument for readline()
In-Reply-To: <1343247348.26.0.437825831921.issue15449@psf.upfronthosting.co.za>
Message-ID: <1343248531.98.0.23774098071.issue15449@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15449>
_______________________________________

From report at bugs.python.org  Wed Jul 25 22:36:05 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 25 Jul 2012 20:36:05 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343248565.84.0.31314339295.issue15431@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

shouldn't be too hard to add, I'll give it a go soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Wed Jul 25 23:24:39 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 21:24:39 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1343251479.67.0.287176398646.issue15320@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Antoine, does the latest patch look okay to you, or did you want something even more minimal (e.g. by defining and acquiring the lock directly in main)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Wed Jul 25 23:27:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Jul 2012 21:27:46 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1343251666.96.0.141738569321.issue15320@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would have taken the "simpler" route myself (taking the lock around the next() call), that said it looks ok as it is to me. Do other people have an opinion?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Wed Jul 25 23:46:22 2012
From: report at bugs.python.org (Tyler Crompton)
Date: Wed, 25 Jul 2012 21:46:22 +0000
Subject: [issue15209] Re-raising exceptions from an expression
In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za>
Message-ID: <1343252782.96.0.169605370587.issue15209@psf.upfronthosting.co.za>


Tyler Crompton <gtr053 at gmail.com> added the comment:

As for the losing valuable debug information, much worse can be done:

import sys

try:
	x
except NameError:
	print('An error occurred.', file=sys.stderr)
	sys.exit(1)

This is obviously not how one should handle errors in development, but it's allowed. As Ethan pointed out, the initial proposal can be recreated by just adding three words which is obviously also allowed.

Nick, I'm not saying you're opinions are wrong, I just wanted to point out how easy it is to throw away valuable information. It's almost futile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15209>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:01:17 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Jul 2012 22:01:17 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343153049.43.0.984675399859.issue15441@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb9ymbJzxB5HuuO5=WtvRK0T30yMXgKTxKihL-J2SeAgA@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

decode_filename_mbcs.patch uses the "replace" error handler to decode
the filename on Windows. It should solve the issue.

----------
Added file: http://bugs.python.org/file26515/decode_filename_mbcs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________
-------------- next part --------------
diff -r b127046831e2 Python/errors.c
--- a/Python/errors.c	Mon Jul 23 00:24:24 2012 -0500
+++ b/Python/errors.c	Wed Jul 25 15:40:52 2012 +0200
@@ -463,11 +463,22 @@ PyErr_SetFromErrnoWithFilenameObject(PyO
     return NULL;
 }
 
+static PyObject *
+decode_filename(const char *filename)
+{
+    if (!filename)
+        return NULL;
+#ifdef HAVE_MBCS
+    return PyUnicode_DecodeMBCS(filename, strlen(filename), "replace");
+#else
+    return PyUnicode_DecodeFSDefault(filename);
+#endif
+}
 
 PyObject *
 PyErr_SetFromErrnoWithFilename(PyObject *exc, const char *filename)
 {
-    PyObject *name = filename ? PyUnicode_DecodeFSDefault(filename) : NULL;
+    PyObject *name = decode_filename(filename);
     PyObject *result = PyErr_SetFromErrnoWithFilenameObject(exc, name);
     Py_XDECREF(name);
     return result;
@@ -558,7 +569,7 @@ PyObject *PyErr_SetExcFromWindowsErrWith
     int ierr,
     const char *filename)
 {
-    PyObject *name = filename ? PyUnicode_DecodeFSDefault(filename) : NULL;
+    PyObject *name = decode_filename(filename);
     PyObject *ret = PyErr_SetExcFromWindowsErrWithFilenameObject(exc,
                                                                  ierr,
                                                                  name);
@@ -595,7 +606,7 @@ PyObject *PyErr_SetFromWindowsErrWithFil
     int ierr,
     const char *filename)
 {
-    PyObject *name = filename ? PyUnicode_DecodeFSDefault(filename) : NULL;
+    PyObject *name = decode_filename(filename);
     PyObject *result = PyErr_SetExcFromWindowsErrWithFilenameObject(
                                                   PyExc_WindowsError,
                                                   ierr, name);
@@ -892,7 +903,7 @@ PyErr_SyntaxLocationEx(const char *filen
         }
     }
     if (filename != NULL) {
-        tmp = PyUnicode_DecodeFSDefault(filename);
+        tmp = decode_filename(filename);
         if (tmp == NULL)
             PyErr_Clear();
         else {

From report at bugs.python.org  Thu Jul 26 00:32:47 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 22:32:47 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343255567.95.0.139390999567.issue15441@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

haypo: how is this meant to fix the bug? Won't it now cause a WindowsError, when a successful operation is expected?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:33:54 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 25 Jul 2012 22:33:54 +0000
Subject: [issue15008] PEP 362 "Signature Objects" reference implementation
In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za>
Message-ID: <1343255634.98.0.551985504657.issue15008@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Are we going to get documentation?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15008>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:36:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 22:36:38 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1343255798.23.0.883636832956.issue15320@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks, Antoine. Just a note: with that other implementation I think the call to pending.close() would probably also warrant a lock since it appears close() can't be called either if a generator is already executing (granted that situation would be even rarer since it could arise only during KeyboardInterrupt).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:38:51 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 25 Jul 2012 22:38:51 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343255931.18.0.384533441757.issue15402@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

So the good old "int main(void)" behaviour is "undefined" :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:41:27 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 25 Jul 2012 22:41:27 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343256087.44.0.851097245498.issue15402@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Talking about this, anybody has an electronic version of C Standard to share with me, or should I hunt around the dark corners of Internet? :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:46:32 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 22:46:32 +0000
Subject: [issue7593] Computed-goto patch for RE engine
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1343256392.72.0.26837290954.issue7593@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:49:05 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 25 Jul 2012 22:49:05 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1343255931.18.0.384533441757.issue15402@psf.upfronthosting.co.za>
Message-ID: <CAK1QoopPKDastg-9pfc7BJKPm4r73qJ5rmqWLVHDk7dVSYZ7-A@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Wed, Jul 25, 2012 at 5:38 PM, Jes?s Cea Avi?n <report at bugs.python.org> wrote:

> So the good old "int main(void)" behaviour is "undefined" :-)

Actually the C Standard says that is OK.  See 5.1.2.2.1 of ISO/IEC 9899:TC3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:50:45 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 22:50:45 +0000
Subject: [issue13525] Tutorial: Example of Source Code Encoding triggers error
In-Reply-To: <1322918242.84.0.309365391343.issue13525@psf.upfronthosting.co.za>
Message-ID: <1343256645.98.0.65234689944.issue13525@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13525>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:51:26 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 22:51:26 +0000
Subject: [issue14501] Error initialising BaseManager class with 'authkey'
	argument of string type.
In-Reply-To: <1333608355.05.0.964001699487.issue14501@psf.upfronthosting.co.za>
Message-ID: <1343256686.06.0.00494065735032.issue14501@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +jnoller
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14501>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:53:49 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 22:53:49 +0000
Subject: [issue4712] Document pickle behavior for subclasses of dicts/lists
In-Reply-To: <1229880245.44.0.0654065239479.issue4712@psf.upfronthosting.co.za>
Message-ID: <1343256829.88.0.420814595794.issue4712@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.2, Python 3.3, Python 3.4 -Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4712>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:54:04 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Jul 2012 22:54:04 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <3WjBZM1M8ZzP9v@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d7a64e095930 by Antoine Pitrou in branch '3.2':
Issue #15320: Make iterating the list of tests thread-safe when running tests in multiprocess mode.
http://hg.python.org/cpython/rev/d7a64e095930

New changeset 43ae2a243eca by Antoine Pitrou in branch 'default':
Issue #15320: Make iterating the list of tests thread-safe when running tests in multiprocess mode.
http://hg.python.org/cpython/rev/43ae2a243eca

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:55:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Jul 2012 22:55:13 +0000
Subject: [issue15320] thread-safety issue in regrtest.main()
In-Reply-To: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>
Message-ID: <1343256913.05.0.782227328628.issue15320@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I've committed the patch to 3.2 and 3.3. I don't really want to bother with 2.7 (it's a rare enough issue). Thank you Chris!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15320>
_______________________________________

From report at bugs.python.org  Thu Jul 26 00:58:30 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 22:58:30 +0000
Subject: [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1343257110.99.0.470472446907.issue13538@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13538>
_______________________________________

From report at bugs.python.org  Thu Jul 26 01:03:08 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 25 Jul 2012 23:03:08 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343257388.78.0.412104304984.issue15436@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This may be CPython specific.

Also, sys.getsizeof() hasn't proved to be very useful (I never see anyone use it or see it in production code).  Worse, it doesn't even make sense in the case of shared-key dictionaries and whatnot.  Accordingly, there is little reason to make this more public than it already is.  I would be happy to see it written-off as an implementation detail.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Thu Jul 26 01:05:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Jul 2012 23:05:31 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343257531.93.0.571099850008.issue15436@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

sys.getsizeof() is not for production code, it's for experimenting and getting information at the command prompt. It's quite useful when you know its limitations.

I'd argue that implementing __sizeof__ for user types doesn't make much sense (except C extension types, which are CPython-specific).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Thu Jul 26 01:22:49 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 25 Jul 2012 23:22:49 +0000
Subject: [issue15008] PEP 362 "Signature Objects" reference implementation
In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za>
Message-ID: <1343258569.47.0.761964732971.issue15008@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov.ml at gmail.com> added the comment:

Benjamin: http://bugs.python.org/issue15151

----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15008>
_______________________________________

From report at bugs.python.org  Thu Jul 26 01:23:37 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Jul 2012 23:23:37 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343258617.83.0.691035505447.issue15441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> haypo: how is this meant to fix the bug?
> Won't it now cause a WindowsError, when a successful
> operation is expected?

Oh, I was referring to the new test proposed in the attached patch (issue15441.patch):

+    def test_chdir_invalid_filename(self):
+        self.assertRaises(WindowsError, os.chdir, b'\xe7w\xf0')

os.chdir() in a non existent directory with a bytes name should raise an OSError, not a UnicodeDecodeError.

--

About the original issue: it looks like mkdir(bytes) decodes internally the directory name and ignore undecodable bytes. On Windows 7, mkdir(b"\xe7w\xf0") creates a directory called "\u8f42" (b"\xe7w", b"\xf0" suffix has been dropped). It is not possible to change the directory to "b"\xe7w\xf0", but it works with "b"\xe7w" or "\u8f42".

There are 2 issues:

 * On Windows, os.chdir(bytes) should not raise a UnicodeDecodeError on the directory does not exist
 * test_nonascii_abspath() can be skipped on Windows if os.fsdecode(b"\xe7w\xf0") fails, or b"\xe7w" name should be used instead

My patch is not the best solution because it looses information (if the filename contains undecodable bytes). I realized that OSError.filename is not necessary a str, bytes is also accepted. win32_error_object() can be used. The following patch pass the original bytes object to OSError constructor instead:


diff -r 43ae2a243eca Modules/posixmodule.c
--- a/Modules/posixmodule.c     Thu Jul 26 00:47:15 2012 +0200
+++ b/Modules/posixmodule.c     Thu Jul 26 01:19:14 2012 +0200
@@ -1138,11 +1138,10 @@ static PyObject *
 path_error(char *function_name, path_t *path)
 {
 #ifdef MS_WINDOWS
-    if (path->narrow)
-        return win32_error(function_name, path->narrow);
-    if (path->wide)
-        return win32_error_unicode(function_name, path->wide);
-    return win32_error(function_name, NULL);
+    return PyErr_SetExcFromWindowsErrWithFilenameObject(
+                PyExc_OSError,
+                0,
+                path->object);
 #else
     return path_posix_error(function_name, path);
 #endif

(sorry, I failed to attach a patch, I have an issue with my file chooser...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Thu Jul 26 01:49:10 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 23:49:10 +0000
Subject: [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343260150.65.0.678943444999.issue15269@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching a patch to address Eli's requests (1) and (2).

Since this patch merely adds documentation and tests for existing functionality, is there any reason why this cannot go into Python 3.3?  Thanks.

----------
Added file: http://bugs.python.org/file26516/issue-15269-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15269>
_______________________________________

From report at bugs.python.org  Thu Jul 26 02:00:03 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 00:00:03 +0000
Subject: [issue15450] Allow dircmp.subdirs to behave well under subclassing
Message-ID: <1343260803.75.0.101432828571.issue15450@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

Currently, the subdirs attribute of filecmp.dircmp does not respect subclassing:

>>> from filecmp import dircmp
>>> class MyDirCmp(dircmp):
...   pass
... 
>>> my_dcmp = MyDirCmp('dir1', 'dir2')
>>> for item in my_dcmp.subdirs.values():
...   print(type(item))
...   break
... 
<class 'filecmp.dircmp'>

This is the only place where dircmp does not respect subclassing.  It can be corrected here:

def phase4(self): # Find out differences between common subdirectories
    ...
        ...
        self.subdirs[x]  = dircmp(a_x, b_x, self.ignore, self.hide)

This would let one do things like override dircmp.report() and have dircmp.report_full_closure() behave as expected.

----------
components: Library (Lib)
keywords: easy
messages: 166443
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Allow dircmp.subdirs to behave well under subclassing
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15450>
_______________________________________

From report at bugs.python.org  Thu Jul 26 02:08:23 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 26 Jul 2012 00:08:23 +0000
Subject: [issue14330] don't use host python,
	use host search paths for host compiler
In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za>
Message-ID: <1343261303.91.0.602345766085.issue14330@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The last changeset (7955d769fdf5) caused some problem on my machine.
Before the changeset I was getting:

Python build finished, but the necessary bits to build these modules were not found:
_bz2               _curses            _curses_panel   
_dbm               _gdbm              _lzma           
_tkinter                                              
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

After 7955d769fdf5 I get:

Python build finished, but the necessary bits to build these modules were not found:
_bz2               _curses            _curses_panel   
_dbm               _gdbm              _lzma           
_sqlite3           _ssl               _tkinter        
readline           zlib                               
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

I'm on an ubuntu 12.04 machine.

----------
nosy: +ezio.melotti
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14330>
_______________________________________

From report at bugs.python.org  Thu Jul 26 02:23:11 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 26 Jul 2012 00:23:11 +0000
Subject: [issue14501] Error initialising BaseManager class with 'authkey'
	argument of string type.
In-Reply-To: <1333608355.05.0.964001699487.issue14501@psf.upfronthosting.co.za>
Message-ID: <1343262191.52.0.779810471239.issue14501@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14501>
_______________________________________

From report at bugs.python.org  Thu Jul 26 02:42:58 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Thu, 26 Jul 2012 00:42:58 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343263378.42.0.258470211773.issue15441@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Here's another try:

In this patch:

- skip test_nonascii_abspath() test since it fails on some code pages.

- Added a test to reproduce bug on latin code pages.

- Use repr(filename) only if decode failed. This is more backward-compatible and does not lose any information.

----------
Added file: http://bugs.python.org/file26517/issue15441_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Thu Jul 26 02:45:51 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Thu, 26 Jul 2012 00:45:51 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343263551.02.0.60489369697.issue15441@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

martin: while os.mkdir(b'\xe7w\xf0') succeeds, but strangely enough, subsequent os.chdir(b'\xe7w\xf0') fails.

This is not a bug in Python, but Windows issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Thu Jul 26 02:57:10 2012
From: report at bugs.python.org (Grissiom Gu)
Date: Thu, 26 Jul 2012 00:57:10 +0000
Subject: [issue15451] PATH is not honored in subprocess.Popen in win32
Message-ID: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>


New submission from Grissiom Gu <chaos.proton at gmail.com>:

My system is 32 bit win7 and python is 2.7.2.

Sample code is here:
=======================
import os, sys

nenv = {}
nenv['PATH'] = 'C:\\Windows\\System32\\;e:\\projects\\teest\\python\\exe\\'
nenv['SystemRoot'] = 'C:\\Windows\\'

#os.putenv('PATH', nenv['PATH'])
import subprocess
proc = subprocess.Popen('test.bat', stdin=subprocess.PIPE, stdout=subprocess.PIPE,
    stderr=subprocess.PIPE, shell = False, env=nenv)
data, err = proc.communicate()
rv = proc.wait()

if data:
    print data
if err:
    print err
sys.exit(rv)
==========================
in E:\projects\teest\python I have two folders: 'exe/' have a bat file named 'test.bat' and a 'launch/' folder have the above script. When execute the above script, python yield "WindowsError: [Error 2]" which means could not find the executable.

However, if I un-comment the line "#os.putenv('PATH', nenv['PATH'])", it works like a charm. It seems _subprocess.CreateProcess does not honer the PATH.

FYI, if I use the CreateProcess of win32 extensions, thing works fine without the need to export PATH.

----------
messages: 166447
nosy: Grissiom.Gu
priority: normal
severity: normal
status: open
title: PATH is not honored in subprocess.Popen in win32
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15451>
_______________________________________

From report at bugs.python.org  Thu Jul 26 03:01:35 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Jul 2012 01:01:35 +0000
Subject: [issue15452] Eliminate the use of eval() in the logging config
	implementation
Message-ID: <1343264495.49.0.0195201203683.issue15452@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The current implementation of PEP 391 relies on eval, which is substantially more permissive than the expected syntax described in the spec. This means the listen() feature provides an attack vector for injection of untrusted code.

While the documentation has been updated with a cautionary note to this effect, longer term, the use of eval() should be replaced with:

1. ast.literal_eval()
2. refactoring the str.format attribute and item lookup code into something suitable for reuse in other contexts (perhaps exposed via the ast module as "ast.lookup_eval()")

----------
components: Library (Lib)
messages: 166448
nosy: ncoghlan, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: Eliminate the use of eval() in the logging config implementation
type: security
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15452>
_______________________________________

From report at bugs.python.org  Thu Jul 26 03:09:40 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 Jul 2012 01:09:40 +0000
Subject: [issue10654] test_datetime sometimes fails on Python3.x windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1343264980.5.0.914166010784.issue10654@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I do not see the error with installed 3.2.3. I **DO** see it consistently, when running the test with installed 3.3.0b1 on 64 bit Win 7. The only failure is
======================================================================
FAIL: test_computations (test.datetimetester.TestSubclassDateTime_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Programs\Python33\lib\test\datetimetester.py", line 1640, in test_computations
    self.assertRaises(TypeError, lambda: a+i)
AssertionError: TypeError not raised by <lambda>
ionError: TypeError not raised by <lambda>

The other 9 runs of test_computations pass.
test_computations (test.datetimetester.TestDate_Pure) ... ok
test_computations (test.datetimetester.TestDateTimeTZ_Pure) ... ok
test_computations (test.datetimetester.TestTimeDelta_Pure) ... ok
test_computations (test.datetimetester.TestSubclassDateTime_Pure) ... ok
test_computations (test.datetimetester.TestDateTime_Pure) ... ok
test_computations (test.datetimetester.TestDate_Fast) ... ok
test_computations (test.datetimetester.TestDateTimeTZ_Fast) ... ok
test_computations (test.datetimetester.TestTimeDelta_Fast) ... ok
test_computations (test.datetimetester.TestDateTime_Fast) ... ok

I reproduce in same way Hirokazo does.
>>> class Sub(datetime): pass

>>> dsub = Sub(2002, 1, 31)
>>> dsub+1
NotImplemented
>>> d = datetime(2000,1,1)
>>> d+1
Traceback (most recent call last):
  File "<pyshell#28>", line 1, in <module>
    b+1
TypeError: unsupported operand type(s) for +: 'datetime.datetime' and 'int'

My understanding of a+b is that a.__add__(b) is tried and if it NotImplemented, which d and dsub.__add__(1) do, b.__radd__(a) is tried. If that does the same, TypeError is raised. 1 .__radd__(x) returns NotImplemented for both d and dsub, but TypeError is raised only for d, not dsub.

Alexander, there are known problems with abstract.c #11477

Nick, I nosied you because you have worked on the binary op dance. Are there special problems for Python subclasses of builtins? Is this problem the same or related to the one in #11477?

----------
nosy: +ncoghlan, terry.reedy
stage:  -> needs patch
title: test_datetime fails on Python3.2 windows binary -> test_datetime sometimes fails on Python3.x windows binary
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Thu Jul 26 03:15:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 01:15:56 +0000
Subject: [issue15376] Refactor the test_runpy walk_package support code into a
	common location
In-Reply-To: <1342509049.53.0.303616016829.issue15376@psf.upfronthosting.co.za>
Message-ID: <1343265356.24.2.5613344793e-05.issue15376@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Hi Nick, I was wondering if you'd have time to take a look at the patches I've uploaded to issue 15403 and issue 15415 at some point.

Once those are addressed, I think we will be in a much better position to address most of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15376>
_______________________________________

From report at bugs.python.org  Thu Jul 26 03:54:56 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Jul 2012 01:54:56 +0000
Subject: [issue10654] test_datetime sometimes fails on Python3.x windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1343267696.53.0.300456907611.issue10654@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The precedence problems described in #11477 shouldn't factor into this case - that issue is specific to C level types that implement + and * via tp_as_sequence *without* implementing the corresponding slots in tp_as_number. That's not the case here, since datetime types *only* implement the slots via tp_as_number.

I can't reproduce the failure at all, so here's a couple of tricks for Windows users trying to reproduce or investigate the problem:

# Getting the C version of datetime:
import _datetime as cdt

# Getting the pure Python version of datetime:
from test.support import import_fresh_module
pydt = import_fresh_module("datetime", blocked=["_datetime"])

# Test the results of all the following operations
d+1
1+d
d.__add__(1)
d.__radd__(1)
1 .__add__(d)
1 .__radd__(d)

# For the following kinds of "d"
d = cdt.datetime(1, 2, 3)
d = pydt.datetime(1, 2, 3)
class SubC(cdt.datetime): pass
d = SubC(1, 2, 3)
class SubPy(cdt.datetime): pass
d = SubPy(1, 2, 3)

----------
components: +Interpreter Core -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Thu Jul 26 04:18:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Jul 2012 02:18:25 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343269105.73.0.224283492316.issue15403@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Thu Jul 26 04:18:25 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Thu, 26 Jul 2012 02:18:25 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343269105.71.0.62865312307.issue15441@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Updated patch again.

In this patch, byte object is passed as argument to WindowsError as Victor's patch.

I prefer to fix PyErr_SetFromWindowsErrWithFilename() over path_error(), because PyErr_SetFromWindowsErrWithFilename() is public API, so someone may use PyErr_SetFromWindowsErrWithFilename() for their own extension modules.

----------
Added file: http://bugs.python.org/file26518/issue15441_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Thu Jul 26 04:18:59 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Jul 2012 02:18:59 +0000
Subject: [issue15415] Add temp_dir() and change_cwd() to test.support
In-Reply-To: <1342905198.6.0.0438176504742.issue15415@psf.upfronthosting.co.za>
Message-ID: <1343269139.32.0.322903733747.issue15415@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15415>
_______________________________________

From report at bugs.python.org  Thu Jul 26 04:59:50 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 Jul 2012 02:59:50 +0000
Subject: [issue10654] test_datetime sometimes fails on Python3.x windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1343271590.19.0.864202586837.issue10654@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Both subclasses return NotImplemented for d+1. Otherwise, TypeError or NotImplemented as expected. See file.

----------
Added file: http://bugs.python.org/file26519/datetimetest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Thu Jul 26 05:27:29 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 26 Jul 2012 03:27:29 +0000
Subject: [issue15452] Eliminate the use of eval() in the logging config
	implementation
In-Reply-To: <1343264495.49.0.0195201203683.issue15452@psf.upfronthosting.co.za>
Message-ID: <1343273249.62.0.82427950836.issue15452@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/issue15452>
_______________________________________

From report at bugs.python.org  Thu Jul 26 05:59:16 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 26 Jul 2012 03:59:16 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343275156.56.0.0434521750621.issue15402@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

The attached patch fixes: (1) the test cases to make them exact (inspired by 'test_sys.py'), (2) the definition of 's_sizeof' to add the dummy parameter, and (3) simplifies the sizeof calculation using 's_len'.

----------
Added file: http://bugs.python.org/file26520/issue15402-redux-v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 06:02:02 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 26 Jul 2012 04:02:02 +0000
Subject: [issue14201] Documented caching for shared library's __getattr__ and
	__getitem__ is incorrect
In-Reply-To: <1330957421.08.0.5889949548.issue14201@psf.upfronthosting.co.za>
Message-ID: <1343275322.98.0.370360712711.issue14201@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Any comments on this one?  I plan on committing the changes tomorrow unless I hear something otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14201>
_______________________________________

From report at bugs.python.org  Thu Jul 26 06:10:55 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Jul 2012 04:10:55 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1343256087.44.0.851097245498.issue15402@psf.upfronthosting.co.za>
Message-ID: <201207260710.35767.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Talking about this, anybody has an electronic version of C Standard to
> share with me, or should I hunt around the dark corners of Internet? :-)

http://www.open-std.org/jtc1/sc22/wg14/www/standards (see n1256.pdf).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 06:36:31 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 26 Jul 2012 04:36:31 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343277391.45.0.484124389126.issue15402@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> So the good old "int main(void)" behaviour is "undefined" :-)

No, it's not; see 5.1.2.2.1p1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 06:37:00 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 26 Jul 2012 04:37:00 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343277420.69.0.267710067489.issue15402@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

issue15402-redux-v1.patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 07:15:26 2012
From: report at bugs.python.org (Eric Snow)
Date: Thu, 26 Jul 2012 05:15:26 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343279726.39.0.781269039357.issue14578@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Brian, perhaps the problem described in issue15431 ("Cannot build importlib.h on Windows") is part of the problem for you here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Thu Jul 26 07:25:14 2012
From: report at bugs.python.org (Eric Snow)
Date: Thu, 26 Jul 2012 05:25:14 +0000
Subject: [issue15368] bytecode generation is not deterministic
In-Reply-To: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>
Message-ID: <1343280314.95.0.904017316453.issue15368@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/issue15368>
_______________________________________

From report at bugs.python.org  Thu Jul 26 07:55:41 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Jul 2012 05:55:41 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343282141.07.0.930889685144.issue15402@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> +        # The size of 'PyStructObject'
>?+        totalsize = size(self.header + '5P')

What if use totalsize = object.__sizeof__(struct_obj) ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 07:58:23 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 26 Jul 2012 05:58:23 +0000
Subject: [issue14330] don't use host python,
	use host search paths for host compiler
In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za>
Message-ID: <1343282303.39.0.797885752304.issue14330@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14330>
_______________________________________

From report at bugs.python.org  Thu Jul 26 07:59:26 2012
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 26 Jul 2012 05:59:26 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343282366.95.0.846647660164.issue15436@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Thu Jul 26 08:35:34 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 26 Jul 2012 06:35:34 +0000
Subject: [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343284534.95.0.0890672085481.issue15269@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I think it can go into 3.3 but only if it gets reviewed by another core dev (we're in release candidate stage now). Senthil - can you review the patch together with me?

As for customizing the stream, yes, go ahead and open a new issue for it, and add me there as nosy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15269>
_______________________________________

From report at bugs.python.org  Thu Jul 26 08:44:08 2012
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 26 Jul 2012 06:44:08 +0000
Subject: [issue15360] Behavior of assigning to __dict__ is not documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1343285048.35.0.855959573477.issue15360@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15360>
_______________________________________

From report at bugs.python.org  Thu Jul 26 09:06:38 2012
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 26 Jul 2012 07:06:38 +0000
Subject: [issue15451] PATH is not honored in subprocess.Popen in win32
In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>
Message-ID: <1343286398.22.0.284895660557.issue15451@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15451>
_______________________________________

From report at bugs.python.org  Thu Jul 26 09:24:57 2012
From: report at bugs.python.org (Mike Castle)
Date: Thu, 26 Jul 2012 07:24:57 +0000
Subject: [issue15453] ctype with packed bitfields does not match native
	compiler
Message-ID: <1343287497.79.0.127552089432.issue15453@psf.upfronthosting.co.za>


New submission from Mike Castle <dalgoda at gmail.com>:

On debian/testing with python 2.7.3rc2 and gcc 4.7.1.

I was trying to use ctypeslib to wrap libdvdnav and running into some issues porting my test C code to Python, eventually tracking it down to this difference between how ctypes and gcc handles bitfields in packed structs (i.e., affects real world problems).

Basically, by default, gcc treats 8, 16 and 32 bit types in bit fields as 1 byte when using __attribute__ ((packed)) , while ctypes treats them each as 1, 2 and 4 bytes even when using _pack_ = 1.  (and libdvdnav using packed a lot)

Output from the attached programs:

$ ./a.out
1
1
1
$ ./t.py
1
2
4

Removing the packed attribute or building with gcc -mms-bitfields both match the ctypes expectations (though -mms-bitfields is probably rarely used in Linux).

----------
components: ctypes
files: t.py
messages: 166462
nosy: Mike.Castle
priority: normal
severity: normal
status: open
title: ctype with packed bitfields does not match native compiler
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file26521/t.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15453>
_______________________________________

From report at bugs.python.org  Thu Jul 26 09:25:55 2012
From: report at bugs.python.org (Mike Castle)
Date: Thu, 26 Jul 2012 07:25:55 +0000
Subject: [issue15453] ctype with packed bitfields does not match native
	compiler
In-Reply-To: <1343287497.79.0.127552089432.issue15453@psf.upfronthosting.co.za>
Message-ID: <1343287555.05.0.304963613152.issue15453@psf.upfronthosting.co.za>


Mike Castle <dalgoda at gmail.com> added the comment:

And the C version....

----------
Added file: http://bugs.python.org/file26522/t.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15453>
_______________________________________

From report at bugs.python.org  Thu Jul 26 09:42:18 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 26 Jul 2012 07:42:18 +0000
Subject: [issue15453] ctype with packed bitfields does not match native
	compiler
In-Reply-To: <1343287497.79.0.127552089432.issue15453@psf.upfronthosting.co.za>
Message-ID: <1343288538.5.0.00768283885811.issue15453@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15453>
_______________________________________

From report at bugs.python.org  Thu Jul 26 09:48:52 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 07:48:52 +0000
Subject: [issue15454] Allow dircmp.report() output stream to be customized
Message-ID: <1343288932.25.0.229744443043.issue15454@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

Currently, filecmp.dircmp's report(), report_partial_closure(), and report_full_closure() methods all only allow printing to stdout.

This issue is to provide some way for the caller to control the stream to which these methods print their output (e.g. a 'stream' argument on the three methods).

This suggestion was made by Eli in the discussion for issue 15269.

----------
components: Library (Lib)
keywords: easy
messages: 166464
nosy: cjerdonek, eli.bendersky
priority: normal
severity: normal
status: open
title: Allow dircmp.report() output stream to be customized
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15454>
_______________________________________

From report at bugs.python.org  Thu Jul 26 09:51:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 07:51:47 +0000
Subject: [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343289107.05.0.990278039103.issue15269@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Sounds good.  And for the record, new issue created here: issue 15454

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15269>
_______________________________________

From report at bugs.python.org  Thu Jul 26 10:09:04 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Jul 2012 08:09:04 +0000
Subject: [issue9914] trace/profile conflict with the use of
	sys.modules[__name__]
In-Reply-To: <1285093065.41.0.819526070425.issue9914@psf.upfronthosting.co.za>
Message-ID: <1343290144.2.0.715032080327.issue9914@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This is a tricky one. Long term, the right approach is to migrate all the "scripts that run other scripts" over to runpy, but the runpy API needs work before we can do that (see #9325).

For bug fix purposes though, these modules can borrow some of runpy's infrastructure in order to fake the system state correctly. Specifically, the runpy._TempModule and runpy._ModifiedArgv0 context managers. (_TempModule may need a tweak to allow the module to be used to be passed in rather than always being implicitly created)

See runpy._run_module_code for an example of how to use them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9914>
_______________________________________

From report at bugs.python.org  Thu Jul 26 10:55:36 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 08:55:36 +0000
Subject: [issue15455] index entries not showing up in glossary
Message-ID: <1343292936.36.0.839564467916.issue15455@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I haven't tracked down the reason for this, but certain index entries seem to be getting skipped in the Glossary.  If you view source on the Glossary page and search for "index-":

http://docs.python.org/dev/glossary.html

You will find that it skips from 'index-2' to 'index-5'.  Only :pep: index entries are getting included even though the Glossary's rst file contains explicit index directives (where 'index-3' and 'index-4' would otherwise be).

I tried some experiments, and this seems to occur even if the index directive text does not match the name of the Glossary term.

----------
assignee: docs at python
components: Documentation
messages: 166467
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: index entries not showing up in glossary
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15455>
_______________________________________

From report at bugs.python.org  Thu Jul 26 10:55:43 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 26 Jul 2012 08:55:43 +0000
Subject: [issue15452] Eliminate the use of eval() in the logging config
	implementation
In-Reply-To: <1343264495.49.0.0195201203683.issue15452@psf.upfronthosting.co.za>
Message-ID: <1343292943.33.0.721984694938.issue15452@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It's not actually the PEP 391 implementation - dictConfig() - that uses eval(). Rather, it's the older fileConfig() API which was part of the original logging package when added to Python 2.3. The use of eval() by fileConfig() was documented at that time, IIRC.

I have no problem in principle with updating fileConfig() - which uses eval() in just one private function - to use ast.literal_eval(), but it may break existing, innocuous code which can't be handled by ast.literal_eval().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15452>
_______________________________________

From report at bugs.python.org  Thu Jul 26 12:29:15 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Jul 2012 10:29:15 +0000
Subject: [issue15456] Correct __sizeof__ support for code objects
Message-ID: <1343298555.0.0.339886098812.issue15456@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Here is a patch that implements __sizeof__ for code objects (PyCodeObject) counting co_cell2arg array.

----------
components: Interpreter Core
files: code_sizeof.patch
keywords: patch
messages: 166469
nosy: storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for code objects
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26523/code_sizeof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15456>
_______________________________________

From report at bugs.python.org  Thu Jul 26 12:30:25 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 26 Jul 2012 10:30:25 +0000
Subject: [issue15455] index entries not showing up in glossary
In-Reply-To: <1343292936.36.0.839564467916.issue15455@psf.upfronthosting.co.za>
Message-ID: <1343298625.74.0.257671805763.issue15455@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.araujo, ezio.melotti, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15455>
_______________________________________

From report at bugs.python.org  Thu Jul 26 12:36:11 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Jul 2012 10:36:11 +0000
Subject: [issue15456] Correct __sizeof__ support for code objects
In-Reply-To: <1343298555.0.0.339886098812.issue15456@psf.upfronthosting.co.za>
Message-ID: <1343298971.23.0.495965138205.issue15456@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

See also issue12399.

----------
nosy: +benjamin.peterson, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15456>
_______________________________________

From report at bugs.python.org  Thu Jul 26 12:53:31 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Jul 2012 10:53:31 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343300011.87.0.0624148929911.issue15441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

+    @unittest.skipIf(sys.platform == 'win32',
+        "Win32 can fail cwd() with invalid utf8 name")
     def test_nonascii_abspath(self):

You should not always skip the test on Windows: the filename is decodable in code pages other than cp932. It would be better to add the following code at the beginning of test_nonascii_abspath():

name = b'\xe7w\xf0'
if sys.platform == 'win32':
  try:
    os.fsdecode(name)
  except UnicodeDecodeError:
    self.skipTest("the filename %a is not decodable from the ANSI code page (%s)" % (name, sys.getfilesystemencoding()))

Note: Windows does not use UTF-8 for ANSI or OEM code pages, except if you change it manually.

+        batfile = """
+chcp 932
+{exe} {scriptname}
+chcp {codepage}
+"""

chcp does only change the OEM code page, whereas Python uses the ANSI code page for sys.getfilesystemencoding().

It is possible to change the ANSI code page of the current thread (CP_THREAD_ACP) using SetThreadLocale(), but it doesn't help because Python uses the global ANSI code page (CP_ACP). I don't think that changing the CP_THREAD_ACP code page does change the CP_ACP code page of child processes.

Changing the ANSI code page manually is possible in the Control Panel, but it requires to reboot Windows.

--

Your patch expects that "os.mkdir(b'\xe7w\xf0'); os.chdir(b'\xe7w\xf0')" works whereas I tested manually in Python, and it doesn't work because Windows creates a directory called "\u8f42" (b'\xe7w'), see my previous message (msg166441). At least with a NTFS filesystem on Windows 7.

--

Your last patch tries to decode the bytes filename from the filesystem encoding, or uses repr(filename). I may be better to keep the bytes filenames unchanged in OSError.filename, instead of using repr(). But it sounds like a good idea to patch all PyErr_Set*WithFilename(..., char*) functions. My patch for  path_error() avoids the creation of a temporary bytes objets.

--

test_support.temp_cwd(b'\xe7w\xf0') test was added by the changeset ebdc2aa730c0 and is related to the issue #3426. I'm not sure that it was really expected to test b'\xe7w\xf0', because a previous test was using u'\xe7w\xf0' :

-        # Issue 3426: check that abspath retuns unicode when the arg is unicode
-        # and str when it's str, with both ASCII and non-ASCII cwds
-        for cwd in (u'cwd', u'\xe7w\xf0'):

We may use b'\xe7w' instead of b'\xe7w\xf0' if b'\xe7w\xf0' cannot be decoded.

--

Attached patch win32_bytes_filename.patch tries to solve both issues: the test and UnicodeDecodeError on raising the OSError.

I tries to decode the bytes filename from the FS encoding, or keeps it unchanged (as bytes). As Python 2 does with os.listdir(unicode).

----------
nosy: +flox
Added file: http://bugs.python.org/file26524/win32_bytes_filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Thu Jul 26 13:00:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 11:00:26 +0000
Subject: [issue15355] generator.__next__() docs should mention exception if
	already executing
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343300426.95.0.328151054789.issue15355@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

This is a very simple patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file26525/issue-15355-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15355>
_______________________________________

From report at bugs.python.org  Thu Jul 26 13:11:57 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 26 Jul 2012 11:11:57 +0000
Subject: [issue15451] PATH is not honored in subprocess.Popen in win32
In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>
Message-ID: <1343301117.49.0.424064747055.issue15451@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

I think env is used for specifying the environment used by the  child process once it has started.  env['PATH'] is not used by the parent process to find program to run.

Having said that, maybe if you used "shell=True" as well then the shell would find the program using env['PATH'].

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15451>
_______________________________________

From report at bugs.python.org  Thu Jul 26 13:37:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 11:37:56 +0000
Subject: [issue15457] consistent treatment of generator terminology
Message-ID: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The documentation on generators (outside of PEP 255) does not currently educate the reader on the more specific  "generator function" and "generator iterator" terminology, or at least not in any consistent or systematic way.

For example, the glossary includes only a single entry for "generator," and that entry does not mention the two more specific forms.

I think it would help for general discourse purposes if this distinction were made clearer, while still continuing to allow for the use of the generic word "generator" when the context makes it clear.

There are also cases where index entries can be improved in this regard, and where references to the section containing details about generators can still be added.  I am in the process of completing a proposed patch.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166474
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: consistent treatment of generator terminology
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15457>
_______________________________________

From report at bugs.python.org  Thu Jul 26 13:39:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 11:39:28 +0000
Subject: [issue15355] generator.__next__() docs should mention exception if
	already executing
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343302768.44.0.400836910173.issue15355@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15355>
_______________________________________

From report at bugs.python.org  Thu Jul 26 14:28:05 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 12:28:05 +0000
Subject: [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343305685.48.0.921224867794.issue15457@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file26526/issue-15457-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15457>
_______________________________________

From report at bugs.python.org  Thu Jul 26 14:29:54 2012
From: report at bugs.python.org (andrea bergamini)
Date: Thu, 26 Jul 2012 12:29:54 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343305794.79.0.188329964617.issue15438@psf.upfronthosting.co.za>


andrea bergamini <andrea.bergamini.it at gmail.com> added the comment:

Ok guys, ticket closed, but I'm still confused: I'm not a Python expert, I've understood that math is a sort of wrapper of C math.h or something like this, but:
- I can't find any reason in using math.pow if I can get errors like the one explained.
- I've used math.h in my C++ code without having experienced any problem in that pow operation.
I'm surely missing something but I'm a bit confused...

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Thu Jul 26 14:50:03 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Jul 2012 12:50:03 +0000
Subject: [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343307003.59.0.159267860894.issue15457@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/issue15457>
_______________________________________

From report at bugs.python.org  Thu Jul 26 14:50:34 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Jul 2012 12:50:34 +0000
Subject: [issue15355] generator.__next__() docs should mention exception if
	already executing
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343307034.76.0.757266261713.issue15355@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/issue15355>
_______________________________________

From report at bugs.python.org  Thu Jul 26 14:52:55 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 26 Jul 2012 12:52:55 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343307175.45.0.866377450976.issue1692335@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

I see that the originally proposed patch is more or less what I suggested above.  Since this has been a critical issue for 5 years, I think such a minimal patch should be committed even though it is not a complete solution.

It seems to me that the more complicated patch exception_pickling_26.diff has a significant overlap with _common_reduce() in typeobject.c.

The patch actually attempts to be *more* general than _common_reduce() since it collects data from tp_getset and tp_members, whereas _common_reduce() only collects data from __slots__.  The patch does not seem to take account of read-only members/getsetters, which I think would cause exceptions when unpickling.

An alternative implementation piggy-backing on _common_reduce() (and using __reduce__ rather than __getstate__) would be

def __reduce__(self):
    slots = None
    func, args, state = object.__reduce__(self, 2)[:3]
    if type(state) is tuple:
        state, slots = state
    newstate = {'args': self.args}
    if state:
        newstate.update(state)
    if slots:
        newstate.update(slots)
    return func, args, newstate

This deals correctly with slots and works with all protocols.  However, the pickles produced can only be unpickled on versions where exceptions are new-style classes, ie Python 2.5 and later.

This would have the side effect that __init__() would no longer be called while unpickling.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Thu Jul 26 14:53:00 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Jul 2012 12:53:00 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343307180.15.0.591899442854.issue15438@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> - I can't find any reason in using math.pow if I can get errors like the one explained.

The reason is your intention to get the error.

>>> pow(-1, 0.5)
(6.123031769111886e-17+1j)
>>> math.pow(-1, 0.5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error

>?- I've used math.h in my C++ code without having experienced any problem in that pow operation.

What you get in C++ as result of pow(43, 10)?

Technically, in C++?you should use <cmath> header, not <math.h>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Thu Jul 26 14:56:19 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 26 Jul 2012 12:56:19 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343307379.85.0.0770652793273.issue15438@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

- I can't find any reason in using math.pow if I can get errors like the one explained.

Yep---don't use math.pow if you want *exact* integer results.  If you're doing numerical calculations and errors of around 1 part in 1 thousand million million are acceptable to you, then math.pow works just fine.  Just like the other math functions (math.log, math.exp, math.sin, etc.), it's using floating-point arithmetic, so converts its inputs to float and gives a float result.  Unlike Python ints, which have unbounded precision, Python floats have a fixed size (64 bits), so there are only finitely many values (less than 2**64) that can be represented exactly.  The fact is that the number you were expecting, 21611482313284249, isn't one of those numbers:  it *doesn't exist* as a float, because it's not exactly representable in the usual 64-bit floating-point type that Python uses internally.

- I've used math.h in my C++ code without having experienced any problem in that pow operation.

I'd be quite surprised if this were true:  if you're using the double type with C or C++, and the pow function from math.h / cmath, you should expect to see *exactly* the same issues.  With the 'long double' type, you may get a little more precision (depending on the platform), but that just delays the point at which those issues would appear.

By the way, don't close the issue just yet!  There's still ongoing discussion here about whether
there's potential for a documentation improvement.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Thu Jul 26 14:59:39 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 26 Jul 2012 12:59:39 +0000
Subject: [issue14501] Error initialising BaseManager class with 'authkey'
	argument of string type.
In-Reply-To: <1333608355.05.0.964001699487.issue14501@psf.upfronthosting.co.za>
Message-ID: <1343307579.97.0.497711273692.issue14501@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

You could just do

    Server_1=TestServer(address=("127.0.0.1",55555),authkey=b"passkey")

so this is probably a documentation issue.  The examples in the documentation should at least be updated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14501>
_______________________________________

From report at bugs.python.org  Thu Jul 26 15:17:23 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 26 Jul 2012 13:17:23 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1343308643.02.0.647243089724.issue15364@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Any objection if I commit the last patch before the next beta?  This is the one which on installed Pythons have

    get_config_var('srcdir') == os.path.dirname(get_makefile_filename())

on posix systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Thu Jul 26 16:18:24 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Thu, 26 Jul 2012 14:18:24 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343312304.67.0.785914952424.issue15441@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

> chcp does only change the OEM code page, whereas Python uses the ANSI code page for sys.getfilesystemencoding().

Sorry, I should have investigated the code more carefully.

> Attached patch win32_bytes_filename.patch tries to solve both issues: the test and UnicodeDecodeError on raising the OSError.

Looks good to me. Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Thu Jul 26 16:20:04 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Jul 2012 14:20:04 +0000
Subject: [issue15041] tkinter documentation: update  "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <3Wjb6q2FLkzPHF@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset aa296d685e02 by Andrew Svetlov in branch '3.2':
Issue #15041: update "see also" list in tkinter documentation.
http://hg.python.org/cpython/rev/aa296d685e02

New changeset e2ab56295b56 by Andrew Svetlov in branch 'default':
Issue #15041: update "see also" list in tkinter documentation.
http://hg.python.org/cpython/rev/e2ab56295b56

New changeset c947f493ccec by Andrew Svetlov in branch '2.7':
Issue #15041: Update "see also" list in tkinter documentation.
http://hg.python.org/cpython/rev/c947f493ccec

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15041>
_______________________________________

From report at bugs.python.org  Thu Jul 26 16:26:13 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Thu, 26 Jul 2012 14:26:13 +0000
Subject: [issue10296] ctypes catches BreakPoint error on windows 32
In-Reply-To: <1288772433.69.0.284335189868.issue10296@psf.upfronthosting.co.za>
Message-ID: <1343312773.25.0.0408413075288.issue10296@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10296>
_______________________________________

From report at bugs.python.org  Thu Jul 26 16:29:44 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 26 Jul 2012 14:29:44 +0000
Subject: [issue15452] Eliminate the use of eval() in the logging config
	implementation
In-Reply-To: <1343264495.49.0.0195201203683.issue15452@psf.upfronthosting.co.za>
Message-ID: <1343312984.08.0.717908276863.issue15452@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Initial evaluation indicates that ast.literal_eval doesn't cut the mustard: it doesn't do any name lookups, so you can't for example successfully evaluate something like 'handlers.WatchedFileHandler' or even 'FileHandler'. 

However, a limited evaluator which goes further than ast.literal_eval will probably work. One such is shown in this Gist:

https://gist.github.com/3182304

It supports a reasonable subset of Python expressions and also could be useful in other contexts than logging configuration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15452>
_______________________________________

From report at bugs.python.org  Thu Jul 26 16:41:11 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 26 Jul 2012 14:41:11 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343313671.58.0.550720284108.issue15402@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> What if use totalsize = object.__sizeof__(struct_obj) ?

That would defeat the purpose of the test. We want to test whether __sizeof__ is correct, so we shouldn't use __sizeof__ in the test to compute the expected result. I understand that object.__sizeof__ is actually a different implementation, but still: there might be errors e.g. in the type definition that cancel out errors in the sizeof implementation. The more "directly" the expected result is computed, the better.

I also realize that such tests will be fragile if the the structures change. This is a good thing, IMO: anybody changing the layout of some object should *have* to verify that the size computation is still correct, so it's good that the test breaks if the structures change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 16:51:58 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Jul 2012 14:51:58 +0000
Subject: [issue10296] ctypes catches BreakPoint error on windows 32
In-Reply-To: <1288772433.69.0.284335189868.issue10296@psf.upfronthosting.co.za>
Message-ID: <1343314318.71.0.243491332112.issue10296@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10296>
_______________________________________

From report at bugs.python.org  Thu Jul 26 16:58:33 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Thu, 26 Jul 2012 14:58:33 +0000
Subject: [issue15093] ntpath.isdir returns False for directory symlinks
In-Reply-To: <1339925337.89.0.456468873164.issue15093@psf.upfronthosting.co.za>
Message-ID: <1343314713.47.0.107543741454.issue15093@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

On Windows, 'target_is_directory' is required for directory symlink.

python -c "import os; os.mkdir('bar'); os.symlink('bar', 'foo', target_is_directory=True); print(os.path.isdir('foo'))"
True

Should we automatically specify target_is_directory if target exists and the target is a directory?

----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15093>
_______________________________________

From report at bugs.python.org  Thu Jul 26 17:12:45 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Jul 2012 15:12:45 +0000
Subject: [issue15093] ntpath.isdir returns False for directory symlinks
In-Reply-To: <1339925337.89.0.456468873164.issue15093@psf.upfronthosting.co.za>
Message-ID: <1343315565.68.0.383010198218.issue15093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Should we automatically specify target_is_directory if target exists and the target is a directory?

No, see issue14917 and issue13772.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15093>
_______________________________________

From report at bugs.python.org  Thu Jul 26 17:17:35 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Thu, 26 Jul 2012 15:17:35 +0000
Subject: [issue15093] ntpath.isdir returns False for directory symlinks
In-Reply-To: <1339925337.89.0.456468873164.issue15093@psf.upfronthosting.co.za>
Message-ID: <1343315855.87.0.747358748509.issue15093@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

ah, thank you for pointer! I should have googled before I wrote.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15093>
_______________________________________

From report at bugs.python.org  Thu Jul 26 17:22:34 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Thu, 26 Jul 2012 15:22:34 +0000
Subject: [issue15093] ntpath.isdir returns False for directory symlinks
In-Reply-To: <1339925337.89.0.456468873164.issue15093@psf.upfronthosting.co.za>
Message-ID: <1343316154.18.0.670321464501.issue15093@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Jason: You can re-activate test you disabled if you use target_is_directory. Please take a look at a issue15093.patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file26527/issue15093.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15093>
_______________________________________

From report at bugs.python.org  Thu Jul 26 17:24:52 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Thu, 26 Jul 2012 15:24:52 +0000
Subject: [issue15093] ntpath.isdir returns False for directory symlinks
In-Reply-To: <1339925337.89.0.456468873164.issue15093@psf.upfronthosting.co.za>
Message-ID: <1343316292.34.0.673082005426.issue15093@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

I think we can close this ticket as "won't fix".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15093>
_______________________________________

From report at bugs.python.org  Thu Jul 26 17:26:36 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 26 Jul 2012 15:26:36 +0000
Subject: [issue7996] concurrency problem in regrtest -jX
In-Reply-To: <1266882602.92.0.94768857178.issue7996@psf.upfronthosting.co.za>
Message-ID: <1343316396.71.0.583002072761.issue7996@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> thread-safety issue in regrtest.main()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7996>
_______________________________________

From report at bugs.python.org  Thu Jul 26 17:38:55 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 26 Jul 2012 15:38:55 +0000
Subject: [issue11602] python-config code should be in sysconfig
In-Reply-To: <1300475478.49.0.935411639754.issue11602@psf.upfronthosting.co.za>
Message-ID: <1343317135.62.0.308106166569.issue11602@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/issue11602>
_______________________________________

From report at bugs.python.org  Thu Jul 26 17:42:55 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 26 Jul 2012 15:42:55 +0000
Subject: [issue15458] Add python-config --configdir option
Message-ID: <1343317375.87.0.261249641765.issue15458@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

To assist with vendor builds, Matthias has requested added a --configdir option to the python3-config script.  This would return sysconfig.get_config_var('LIBPL').  The value is embedded in the output for --ldflags, but not in a convenient way.

The change is fairly trivial; see attached patch.  I am assigning this to Georg and making it a release blocker because I would like to get a freeze exemption for Python 3.3.  If Georg agrees, I will commit the patch.  If not, please twiddle Priority, Versions, and Assigned To as appropriate.

----------
assignee: georg.brandl
files: configdir.diff
keywords: patch
messages: 166491
nosy: barry, georg.brandl
priority: release blocker
severity: normal
status: open
title: Add python-config --configdir option
versions: Python 3.3
Added file: http://bugs.python.org/file26528/configdir.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15458>
_______________________________________

From report at bugs.python.org  Thu Jul 26 17:43:07 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 26 Jul 2012 15:43:07 +0000
Subject: [issue15458] Add python-config --configdir option
In-Reply-To: <1343317375.87.0.261249641765.issue15458@psf.upfronthosting.co.za>
Message-ID: <1343317387.02.0.135418902909.issue15458@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15458>
_______________________________________

From report at bugs.python.org  Thu Jul 26 18:14:58 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Jul 2012 16:14:58 +0000
Subject: [issue15360] Behavior of assigning to __dict__ is not documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1343319298.69.0.599817826643.issue15360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think assigning to __dict__ is an implementation detail; we shouldn't document it before it is clearly agreed what it should do (which probably deserves asking on python-dev).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15360>
_______________________________________

From report at bugs.python.org  Thu Jul 26 18:37:43 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 26 Jul 2012 16:37:43 +0000
Subject: [issue15454] Allow dircmp.report() output stream to be customized
In-Reply-To: <1343288932.25.0.229744443043.issue15454@psf.upfronthosting.co.za>
Message-ID: <1343320663.84.0.749071405756.issue15454@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15454>
_______________________________________

From report at bugs.python.org  Thu Jul 26 18:48:36 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 26 Jul 2012 16:48:36 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343321316.88.0.0411400412205.issue15438@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

C comparison rules are different from Python's.
In the program below (which outputs 1), the mixed comparison will first convert the literal to a double, and lost some precision.
Python does the opposite: the (imprecise) float is converted to a long, so all digits are compared.


#include <math.h>
#include <stdio.h>
int main()
{
    printf("result: %d\n", (pow(43,10) == 21611482313284249));
}

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Thu Jul 26 18:53:25 2012
From: report at bugs.python.org (Christian Rickert)
Date: Thu, 26 Jul 2012 16:53:25 +0000
Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree
In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za>
Message-ID: <1343321605.83.0.417677588114.issue15133@psf.upfronthosting.co.za>


Christian Rickert <mail at crickert.de> added the comment:

Noticed this odd behaviour with BooleanVar.get() as well:

class MyCheckbutton(Checkbutton):
	def __init__(self, parent, **options):
		Checkbutton.__init__(self, parent, **options)
		self.var = BooleanVar()
		self.configure(indicatoron=False, command=self.cb, variable=self.var)
		print(self.var.get)	# "<bound method BooleanVar.get of <tkinter.BooleanVar object at 0x245c310>>"
		print(self.var.get())	# "0"
	def cb(self, *events): # button callback (manual toggle)
		print(self.var.get)	# <bound method BooleanVar.get of <tkinter.BooleanVar object at 0x245c310>>
		print(self.var.get())	# True

Python 3.2.3 (default, May  3 2012, 15:51:42) 
[GCC 4.6.3] on linux2

----------
nosy: +crickert
versions:  -Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15133>
_______________________________________

From report at bugs.python.org  Thu Jul 26 20:07:37 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 26 Jul 2012 18:07:37 +0000
Subject: [issue15452] Eliminate the use of eval() in the logging config
	implementation
In-Reply-To: <1343264495.49.0.0195201203683.issue15452@psf.upfronthosting.co.za>
Message-ID: <1343326057.83.0.364715829328.issue15452@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Having reflected on this further, ISTM that limiting the scope of evaluation is not the correct answer. For example, a malicious user could still send a bogus configuration which, for example, just turns the verbosity of all loggers off, or configures a huge number of bogus loggers. This would certainly be allowed even by a limited-evaluation scheme if a user legitimately wanted to do so; but if a malicious user sends the exact same ?legal? configuration, it is still a security exploit because the consequences may be undesirable to the victim.

But how is the listener to know whether or not the configuration is coming from a legitimate source (a client process controlled by the same user who is running the process which uses listen())  or a malicious user (a client process controlled by some other user)? The simplest answer would appear to be a shared secret: When listen() is called, it is passed a text passphrase, which is also known to legitimate clients. When handling a configuration request via the socket, the configuration is checked to see if it contains the passphrase. If it does, the request is processed; otherwise, it is ignored.

In the fileConfig() input data, the passphrase could be provided via a passphrase=secret entry in the [default] section. In the dictConfig() input data, the passphrase could be provided against the passphrase key in the dict which is passed to dictConfig(). The checking would be done in the request handler code before calling fileConfig() or dictConfig(). If the passphrase argument to the listen() call is None (the default, preserving the current behaviour) no passphrase checking would be done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15452>
_______________________________________

From report at bugs.python.org  Thu Jul 26 20:35:05 2012
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 26 Jul 2012 18:35:05 +0000
Subject: [issue15459] ctypes Structures with subclassed types in the _fields_
	list
Message-ID: <1343327705.62.0.223741820518.issue15459@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

When a ctypes Structure uses a subclass of c_int, c_short, c_byte in the _fields_ list to define bitfields, the results are wrong.

The attached script showbug.py demonstrates this behaviour.

----------
components: ctypes
files: showbug.py
keywords: needs review, patch
messages: 166496
nosy: theller
priority: normal
severity: normal
status: open
title: ctypes Structures with subclassed types in the _fields_ list
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26529/showbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15459>
_______________________________________

From report at bugs.python.org  Thu Jul 26 20:38:47 2012
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 26 Jul 2012 18:38:47 +0000
Subject: [issue15459] ctypes Structures with subclassed types in the _fields_
	list
In-Reply-To: <1343327705.62.0.223741820518.issue15459@psf.upfronthosting.co.za>
Message-ID: <1343327927.89.0.153491325773.issue15459@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

The attached patch for branch default fixes this issue.  It also contains a unittest.

----------
Added file: http://bugs.python.org/file26530/bitfields.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15459>
_______________________________________

From report at bugs.python.org  Thu Jul 26 20:39:01 2012
From: report at bugs.python.org (Charlie Clark)
Date: Thu, 26 Jul 2012 18:39:01 +0000
Subject: [issue15460] SQLite cursor.description is not DB-API compatible
Message-ID: <1343327941.65.0.811204153568.issue15460@psf.upfronthosting.co.za>


New submission from Charlie Clark <charlie.clark at clark-consulting.eu>:

It says in the docs:
"""This read-only attribute provides the column names of the last query. To remain compatible with the Python DB API, it returns a 7-tuple for each column where the last six items of each tuple are None."""

According to the DB-API, however, the first two items, name and type, must be specified:
"""
The first two items (name and type_code) are mandatory, the other five are optional and are set to None if no meaningful values can be provided.
"""

Even with it's limited number of types SQLite is typed and should be able to return the type for column.

----------
components: Library (Lib)
messages: 166498
nosy: CharlieX
priority: normal
severity: normal
status: open
title: SQLite cursor.description is not DB-API compatible
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15460>
_______________________________________

From report at bugs.python.org  Thu Jul 26 20:58:10 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 18:58:10 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343329090.82.0.248184575742.issue15403@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

It occurs to me that the filecmp/dircmp tests in Lib/test/test_filecmp.py would also benefit from code like this (i.e. being able to create a nested directory of files in one or two lines).  And perhaps elsewhere in the tests.

This is an argument for slightly generalizing the test support API in the uploaded patch from creating modules/packages to creating files/directories.  A convenience wrapper for packages could still be included that includes an __init__.py in the calls to the underlying directory code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:10:08 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 26 Jul 2012 19:10:08 +0000
Subject: [issue15459] ctypes Structures with subclassed types in the _fields_
	list
In-Reply-To: <1343327705.62.0.223741820518.issue15459@psf.upfronthosting.co.za>
Message-ID: <1343329808.25.0.451476323042.issue15459@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/issue15459>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:12:29 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 26 Jul 2012 19:12:29 +0000
Subject: [issue13772] listdir() doesn't work with non-trivial symlinks
In-Reply-To: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za>
Message-ID: <1343329949.66.0.711664363507.issue13772@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I apologize I missed this issue when it arose, so my comments come late.

The reason for inferring the directory status of the targets was so that use of os.symlink(link, target) would behave much the same on Unix as on Windows for the most common use cases. By requiring the directory status to be supplied when calling os.symlink, it makes the function barely portable (it becomes only portable for symlinks to files, not directories).

As was indicated by Larry Hastings in issue14917, there's an expectation that Python could easily detect the directory status of the target. There was apparently a bug in the earlier detection code for directories, which doesn't exist in the [reference implementation](https://bitbucket.org/jaraco/jaraco.windows/src/2.7/jaraco/windows/filesystem/__init__.py#cl-46) (done in ctypes):

PS C:\Users\jaraco\projects\jaraco.windows> mkdir -p Lib/test/foo
PS C:\Users\jaraco\projects\jaraco.windows> python
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from jaraco.windows import filesystem as fs
>>> fs.symlink('.\\test', 'Lib/bar')
>>> import os
>>> os.listdir('Lib/bar')
['foo']

I suspect this bug crept in as we worked through the various challenges with directory detection at that low level of Python. As you can see, the reference implementation is clean an straightforward and correct.

In my opinion, it would be worthwhile restoring the directory detection and creating tests to capture cases where detection fails, rather than removing the implementation.

I've been using the ctypes implementation for some time, and having automatic directory detection is a huge benefit to portability and simplicity of use.

It was pointed out that there is a race condition, and theoretically, that is true, but I believe this not to be a problem because the automatic detection is a best-effort. It's used to guess the best possible directory status for the symlink. If there's a directory there one millisecond, then the target is then removed, and the symlink is created as a directory symlink, that's most probably still what the user would have wanted.

As a heavy user of symlinks in Windows, I would strongly prefer inference of directory status. Of course, I can always continue to use the ctypes implementation in my environments, but I imagine that other potential users would feel the same as I do and would appreciate a more portable implementation.

Without the directory feature, many uses of os.symlink are not portable and will fail (with ugly results) on Windows. With the directory detection feature, most (if not all) will simply work as expected. Removal of this feature is a regression of the intended functionality, and I'd like it to be considered to be restored.

----------
nosy: +jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:21:40 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Jul 2012 19:21:40 +0000
Subject: [issue15093] ntpath.isdir returns False for directory symlinks
In-Reply-To: <1339925337.89.0.456468873164.issue15093@psf.upfronthosting.co.za>
Message-ID: <3Wjjpq4vnkzPNL@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5bf7afd944a2 by Jason R. Coombs in branch 'default':
Restored test by specifying that the symlink links to a target (currently required for Windows symlinks). See issue15093 for details.
http://hg.python.org/cpython/rev/5bf7afd944a2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15093>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:23:18 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 26 Jul 2012 19:23:18 +0000
Subject: [issue15093] ntpath.isdir returns False for directory symlinks
In-Reply-To: <1339925337.89.0.456468873164.issue15093@psf.upfronthosting.co.za>
Message-ID: <1343330598.59.0.360891395488.issue15093@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks ishimoto for getting to the bottom of this. Thanks pitrou for the links to the symlink implementation changes.

Yes, this issue as reported was invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15093>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:31:09 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 26 Jul 2012 19:31:09 +0000
Subject: [issue15041] tkinter documentation: update  "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1343331069.1.0.0234065064745.issue15041@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15041>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:32:54 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 19:32:54 +0000
Subject: [issue15450] Allow dircmp.subdirs to behave well under subclassing
In-Reply-To: <1343260803.75.0.101432828571.issue15450@psf.upfronthosting.co.za>
Message-ID: <1343331174.71.0.163020178318.issue15450@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Adding a patch with a failing test for the issue.

----------
keywords: +patch
stage:  -> needs patch
Added file: http://bugs.python.org/file26531/issue-15450-failing-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15450>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:33:36 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 26 Jul 2012 19:33:36 +0000
Subject: [issue15438] Incredible issue in math.pow
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343331216.34.0.990099713313.issue15438@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah yes; a comparison like that could indeed give the impression that C/C++ was computing things exactly. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:41:19 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 19:41:19 +0000
Subject: [issue15450] Allow dircmp.subdirs to behave well under subclassing
In-Reply-To: <1343260803.75.0.101432828571.issue15450@psf.upfronthosting.co.za>
Message-ID: <1343331679.91.0.607505666508.issue15450@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching full patch (though Misc/NEWS would need to be moved a new section is created for pre-alpha).

----------
Added file: http://bugs.python.org/file26532/issue-15450-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15450>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:41:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 19:41:26 +0000
Subject: [issue15450] Allow dircmp.subdirs to behave well under subclassing
In-Reply-To: <1343260803.75.0.101432828571.issue15450@psf.upfronthosting.co.za>
Message-ID: <1343331686.54.0.13513845776.issue15450@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15450>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:43:15 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 26 Jul 2012 19:43:15 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1343331795.89.0.816359520277.issue15364@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

LGTM

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:44:10 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 19:44:10 +0000
Subject: [issue15450] Allow dircmp.subdirs to behave well under subclassing
In-Reply-To: <1343260803.75.0.101432828571.issue15450@psf.upfronthosting.co.za>
Message-ID: <1343331850.56.0.394061845173.issue15450@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Actually, this should also be documented.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15450>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:46:54 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Jul 2012 19:46:54 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1343313671.58.0.550720284108.issue15402@psf.upfronthosting.co.za>
Message-ID: <201207262246.35253.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> That would defeat the purpose of the test. We want to test whether
> __sizeof__ is correct, so we shouldn't use __sizeof__ in the test to
> compute the expected result. I understand that object.__sizeof__ is
> actually a different implementation, but still: there might be errors e.g.
> in the type definition that cancel out errors in the sizeof
> implementation. The more "directly" the expected result is computed, the
> better.

I do not think that the purpose of testing is a testing of object.__sizeof__. 
Memory consumption consists of two parts -- memory for C structure (and the 
base object implementation works for this) and extra memory, for which we 
write a specialized __sizeof__ method. If we doubt object.__sizeof__, then we 
are obligated to implement and test __sizeof__ methods for all C-implemented 
classes, not using the base object implementation.

> I also realize that such tests will be fragile if the the structures
> change. This is a good thing, IMO: anybody changing the layout of some
> object should *have* to verify that the size computation is still correct,
> so it's good that the test breaks if the structures change.

Such tests is too fragile. They force the programmer to write unnecessary code 
in cases when it can be done automatically. We write in C code 
sizeof(SomeStruct), and not the sum of sizes (+paddings) of the structure 
fields.

Let's focus on the differences, on the extra memory usage that not allows us to 
simply use inherited base object implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:54:14 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 26 Jul 2012 19:54:14 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343332454.03.0.984339833686.issue15441@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I still would prefer if only one issue at a time gets fixed, in particular if the two issues require independent changes. This issue is about test_nonascii_abspath failing on the Japanese edition of Windows (see the first sentence of the first message from Atsuo)

If you absolutely must fix the other issue right away also, it needs a test case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Thu Jul 26 21:56:43 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 26 Jul 2012 19:56:43 +0000
Subject: [issue15458] Add python-config --configdir option
In-Reply-To: <1343317375.87.0.261249641765.issue15458@psf.upfronthosting.co.za>
Message-ID: <1343332603.12.0.55326550441.issue15458@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I guess we can do this, looks fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15458>
_______________________________________

From report at bugs.python.org  Thu Jul 26 22:03:49 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 26 Jul 2012 20:03:49 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <201207262246.35253.storchaka@gmail.com>
Message-ID: <5011A2A3.60202@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I do not think that the purpose of testing is a testing of object.__sizeof__. 
> Memory consumption consists of two parts -- memory for C structure (and the 
> base object implementation works for this)

Note that object.__sizeof__ does something slightly different, though:
it uses basicsize (which may or may not contain the sizeof() invocation
of the correct C structure), and it considers tp_itemsize (which may or
may not have a correct value).

> 
>> I also realize that such tests will be fragile if the the structures
>> change. This is a good thing, IMO: anybody changing the layout of some
>> object should *have* to verify that the size computation is still correct,
>> so it's good that the test breaks if the structures change.
> 
> Such tests is too fragile. They force the programmer to write unnecessary code 
> in cases when it can be done automatically.

That's not the definition of "fragile", though. What you describe is
that writing the test this way is "tedious" (????????????); it isn't
(necessarily) "fragile" (???????). I (clearly) disagree that this
approach is "too tedious".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 22:18:22 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 26 Jul 2012 20:18:22 +0000
Subject: [issue15456] Correct __sizeof__ support for code objects
In-Reply-To: <1343298555.0.0.339886098812.issue15456@psf.upfronthosting.co.za>
Message-ID: <1343333902.86.0.211659786457.issue15456@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Interestingly, the original patch did change the sizeof test, but incorrectly (adding the extra pointer to the struct spec, but failing to recognize that there is additional memory allocated).

This tells me

a) we *absolutely* need to preserve the current testing style where the test cases count the individual fields (see issue15402 for the related discussion). Had the test used object.__sizeof__, it would not have needed any change to continue to pass, losing all hope that somebody might have detected it except by very careful review.

b) the trigger that the test broke apparently was not sufficient to hint Benjamin that the sizeof implementation may be incorrect, he just assumed that the test was incorrect.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15456>
_______________________________________

From report at bugs.python.org  Thu Jul 26 22:21:47 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 26 Jul 2012 20:21:47 +0000
Subject: [issue12399] simplify cell var initialization by storing constant
	data on the code object
In-Reply-To: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>
Message-ID: <1343334107.93.0.163113083595.issue12399@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

See issue15456 for a follow-up issue.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12399>
_______________________________________

From report at bugs.python.org  Thu Jul 26 22:23:39 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Jul 2012 20:23:39 +0000
Subject: [issue15456] Correct __sizeof__ support for code objects
In-Reply-To: <1343298555.0.0.339886098812.issue15456@psf.upfronthosting.co.za>
Message-ID: <3WjlBL037lzNvc@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5093cfdff2a9 by Martin v. L?wis in branch 'default':
Issue #15456: Fix code __sizeof__ after #12399 change.
http://hg.python.org/cpython/rev/5093cfdff2a9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15456>
_______________________________________

From report at bugs.python.org  Thu Jul 26 22:23:39 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Jul 2012 20:23:39 +0000
Subject: [issue12399] simplify cell var initialization by storing constant
	data on the code object
In-Reply-To: <1308931560.13.0.00225198817974.issue12399@psf.upfronthosting.co.za>
Message-ID: <3WjlBL5ZP1zNvc@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5093cfdff2a9 by Martin v. L?wis in branch 'default':
Issue #15456: Fix code __sizeof__ after #12399 change.
http://hg.python.org/cpython/rev/5093cfdff2a9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12399>
_______________________________________

From report at bugs.python.org  Thu Jul 26 22:24:04 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 26 Jul 2012 20:24:04 +0000
Subject: [issue15456] Correct __sizeof__ support for code objects
In-Reply-To: <1343298555.0.0.339886098812.issue15456@psf.upfronthosting.co.za>
Message-ID: <1343334244.41.0.270789489759.issue15456@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/issue15456>
_______________________________________

From report at bugs.python.org  Thu Jul 26 22:29:22 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Jul 2012 20:29:22 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <5011A2A3.60202@v.loewis.de>
Message-ID: <201207262327.10259.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Note that object.__sizeof__ does something slightly different, though:
> it uses basicsize (which may or may not contain the sizeof() invocation
> of the correct C structure), and it considers tp_itemsize (which may or
> may not have a correct value).

All such cases are bugs (memory manager works with tp_basicsize and 
tp_itemsize, not with __sizeof__ result) and tests do not test it. In 
paranoidal mode we should tests both __sizeof__ and object.__sizeof__. For all 
classes, even for those that do not use the extra memory. I think it is really 
tedious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 22:46:17 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 26 Jul 2012 20:46:17 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <201207262327.10259.storchaka@gmail.com>
Message-ID: <5011AC97.7010602@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> All such cases are bugs (memory manager works with tp_basicsize and 
> tp_itemsize, not with __sizeof__ result) and tests do not test it. In 
> paranoidal mode we should tests both __sizeof__ and object.__sizeof__. For all 
> classes, even for those that do not use the extra memory. I think it is really 
> tedious.

It's clearly a tradeoff. The question is whether a more paranoid
formulation of the test might detect any real bugs. issue15456
efficiently demonstrates that the current style can detect bugs
which testing with object.__sizeof__ can't. This is not theoretical:
it's an *actual* bug that did get detected with the current style
of testing, but would not have been detected with object.__sizeof__.
This, IMO, makes the more tedious formulation worthwhile.

Of course, developers need to be educated how to deal with any
breakage of these tests: it may be that they really just added
or removed fields to the structure, in which case they just need
to update the struct specs. In many cases, I claim, addition of
new fields (in particular of struct type "P") corresponds to the
allocation of additional memory blocks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Thu Jul 26 23:03:21 2012
From: report at bugs.python.org (coder.maliubiao)
Date: Thu, 26 Jul 2012 21:03:21 +0000
Subject: [issue15461] os.stat() 's inappropriate behavior when dealing with a
	broken link in linux systems.
Message-ID: <1343336601.05.0.224760800644.issue15461@psf.upfronthosting.co.za>


New submission from coder.maliubiao <maliubiao at gmail.com>:

the code:
import os,stat
mode=os.stat("a broken link file").st_mode
then i got :OSError: [Errno 2] No such file or directory.

why not just treat a broken link as something existing and don't report any error.

----------
components: Library (Lib)
messages: 166519
nosy: maliubiao at gmail.com
priority: normal
severity: normal
status: open
title: os.stat() 's inappropriate behavior when dealing with a broken link in linux systems.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15461>
_______________________________________

From report at bugs.python.org  Thu Jul 26 23:06:21 2012
From: report at bugs.python.org (Aimon Bustardo)
Date: Thu, 26 Jul 2012 21:06:21 +0000
Subject: [issue15462] UTF8 BOM incorrectly prepended syslog messages when
	using rsysolog
Message-ID: <1343336781.88.0.897924928117.issue15462@psf.upfronthosting.co.za>


New submission from Aimon Bustardo <abustardo at morphlabs.com>:

Ubuntu 12.0.4 LTS 64bit
python2.7-minimal 2.7.3-0ubuntu3
rsyslog 5.8.6-1ubuntu8

Python converts all syslog messages to UTF8 before sending to syslog. It also prepends the Byte Order Mark (BOM) of the Unicode Standard. This prepended BOM causes bad characters when using rsyslog (have not verified with std syslog or syslog-ng).

Example log line:

Jul 25 13:36:03 mc ???2012-07-25 13:36:03 INFO nova.api.openstack.wsgi [req-48a555a5-6d2a-4a38-8384-3b4684357e72 19f932a5b0b34655989f4cb761522bb3 2617e657fdf84569a6be7977318e46c8] http://MASKED:8774/v1.1/2617e657fdf84569a6be7977318e46c8/os-hosts/MASKED.json?ignore_awful_caching1343248563 returned with HTTP 200

Note the ' ???' before the date field.

Interesting find on issues from another site:

"Yes, "???" is the Byte Order Mark (BOM) of the Unicode Standard. Specifically it is the hex bytes EF BB BF, which form the UTF-8 representation of the BOM, misinterpreted as ISO 8859/1 text instead of UTF-8."

If I patch the code in /usr/lib/python2.7/logging/handlers.py:
------------------------------------------
@@ -797,9 +797,10 @@
                                             self.mapPriority(record.levelname))
         # Message is a string. Convert to bytes as required by RFC 5424
         if type(msg) is unicode:
            msg = msg.encode('utf-8')
- if codecs:
- msg = codecs.BOM_UTF8 + msg
+ #if codecs:
+ # msg = codecs.BOM_UTF8 + msg
         msg = prio + msg
         try:
             if self.unixsocket:

----------------------------------------

The logs will now appear normally. What is happening with the 'codecs' condition? Is this controllable through config? Is this a bug in rsyslog? 

Related tickets:

https://bugs.launchpad.net/openstack-common/+bug/1029116
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1029640
http://bugzilla.adiscon.com/show_bug.cgi?id=346

----------
components: IO, Library (Lib), Unicode
messages: 166520
nosy: Aimon.Bustardo, ezio.melotti
priority: normal
severity: normal
status: open
title: UTF8 BOM incorrectly prepended syslog messages when using rsysolog
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15462>
_______________________________________

From report at bugs.python.org  Thu Jul 26 23:16:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 Jul 2012 21:16:23 +0000
Subject: [issue15041] tkinter documentation: update  "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1343337383.07.0.0379983478078.issue15041@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, there is no need to add a Misc/NEWS entry for such small doc changes (and especially not in the Library section :)  The Documentation section of Misc/NEWS is used for important changes to the doc or the toolchain, not the everyday changes we do.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15041>
_______________________________________

From report at bugs.python.org  Thu Jul 26 23:16:51 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 Jul 2012 21:16:51 +0000
Subject: [issue15459] ctypes Structures with subclassed types in the _fields_
	list
In-Reply-To: <1343327705.62.0.223741820518.issue15459@psf.upfronthosting.co.za>
Message-ID: <1343337411.43.0.958091684631.issue15459@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
stage:  -> patch review
versions: +Python 3.2 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15459>
_______________________________________

From report at bugs.python.org  Thu Jul 26 23:24:06 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 26 Jul 2012 21:24:06 +0000
Subject: [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1343337846.76.0.0413850331321.issue15151@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15151>
_______________________________________

From report at bugs.python.org  Thu Jul 26 23:29:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 Jul 2012 21:29:12 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1343338152.83.0.095908307007.issue15364@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does get_config_var('srcdir') always return a string or sometimes None?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Thu Jul 26 23:34:22 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 26 Jul 2012 21:34:22 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343338462.96.0.422693465359.issue1692335@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

While I would be happy to see this issue finally closed, but it's up to Georg if this goes into 3.3 or not as one could argue it's a feature or a bugfix/oversight.

As for the actual fix, classic classes shouldn't hold back a good solution since that is a 2.x thing that only affects Python 2.4 which is too old to worry about; I think it's an acceptable limitation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 00:12:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Jul 2012 22:12:16 +0000
Subject: [issue15458] Add python-config --configdir option
In-Reply-To: <1343317375.87.0.261249641765.issue15458@psf.upfronthosting.co.za>
Message-ID: <3Wjnbg0mfCzPLQ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ddf15cd9be4a by Barry Warsaw in branch 'default':
- Issue #15458: python-config gets a new option --configdir to print the
http://hg.python.org/cpython/rev/ddf15cd9be4a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15458>
_______________________________________

From report at bugs.python.org  Fri Jul 27 00:13:11 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 26 Jul 2012 22:13:11 +0000
Subject: [issue15458] Add python-config --configdir option
In-Reply-To: <1343317375.87.0.261249641765.issue15458@psf.upfronthosting.co.za>
Message-ID: <1343340791.77.0.666096924593.issue15458@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/issue15458>
_______________________________________

From report at bugs.python.org  Fri Jul 27 00:31:50 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 26 Jul 2012 22:31:50 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1343341910.84.0.0293080084493.issue15364@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

> Does get_config_var('srcdir') always return a string or sometimes None?

Always a string.

distutils.support._get_xxmodule_path() is one place which (currently) would throw an exception if it returned None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Fri Jul 27 01:16:39 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 26 Jul 2012 23:16:39 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343344599.32.0.530948449101.issue1692335@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

I realize now that the idea of using object.__reduce__(..., 2) would not really work since many exception classes use non-slot descriptors (unless '__slots__' attributes were also added as hints of what to serialize).

I think there are two options simple enough to sneak in to 3.3:

(1) The trivial patch of initially setting self->args in __new__().

(2) Georg's idea of additionally setting a __newargs__ attribute in __new__() and using it in __reduce__().  However, I would store __newargs__ directly in the struct to avoid always triggering creation of a dict for the instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 01:23:17 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Jul 2012 23:23:17 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
In-Reply-To: <1343344599.32.0.530948449101.issue1692335@psf.upfronthosting.co.za>
Message-ID: <1343344868.3697.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think there are two options simple enough to sneak in to 3.3:
> 
> (1) The trivial patch of initially setting self->args in __new__().
> 
> (2) Georg's idea of additionally setting a __newargs__ attribute in
> __new__() and using it in __reduce__().  However, I would store
> __newargs__ directly in the struct to avoid always triggering creation
> of a dict for the instance.

At this point of the release process, the trivial approach sounds safer
to me (but is it?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 01:23:58 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 26 Jul 2012 23:23:58 +0000
Subject: [issue11602] python-config code should be in sysconfig
In-Reply-To: <1300475478.49.0.935411639754.issue11602@psf.upfronthosting.co.za>
Message-ID: <1343345038.01.0.781763766098.issue11602@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11602>
_______________________________________

From report at bugs.python.org  Fri Jul 27 01:25:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 23:25:35 +0000
Subject: [issue15454] Allow dircmp.report() output stream to be customized
In-Reply-To: <1343288932.25.0.229744443043.issue15454@psf.upfronthosting.co.za>
Message-ID: <1343345135.97.0.0991632776911.issue15454@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

For discussion purposes, I'd like to mention an alternate approach.  (I haven't yet formed an opinion on what approach is preferable.)

Python's built-in print() function accepts more than just a 'file' keyword argument:

http://docs.python.org/dev/library/functions.html#print

In addition, because adding a stream argument would require modifying the signatures of three different methods, adding a stream argument might not set us on the right path if we'd like to add support for more arguments to print() in the future (or add additional methods that print output alongside the existing reporting methods).

Another approach is to add a print() method to the dircmp class and have the report methods call self.print() instead of print().  With this approach, callers wanting a different output stream could subclass dircmp and override the print method.  This approach also seems like it would offer more flexibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15454>
_______________________________________

From report at bugs.python.org  Fri Jul 27 01:34:38 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Jul 2012 23:34:38 +0000
Subject: [issue13772] listdir() doesn't work with non-trivial symlinks
In-Reply-To: <1343329949.66.0.711664363507.issue13772@psf.upfronthosting.co.za>
Message-ID: <1343345549.3697.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 26 juillet 2012 ? 19:12 +0000, Jason R. Coombs a ?crit :
> Without the directory feature, many uses of os.symlink are not
> portable and will fail (with ugly results) on Windows.

The target_is_directory argument is supposed to be "supported" (i.e.
ignored) on other platforms, so you should be able to write portable
code easily.

I'm not against restoring detection, but it should be non-buggy and
correctly unit-tested :) That said it's probably too late for 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Fri Jul 27 01:57:26 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Thu, 26 Jul 2012 23:57:26 +0000
Subject: [issue9269] Cannot pickle self-referencing sets
In-Reply-To: <1279234902.88.0.629141543515.issue9269@psf.upfronthosting.co.za>
Message-ID: <1343347046.78.0.0859140278036.issue9269@psf.upfronthosting.co.za>


Stefan Mihaila <mstefanro at gmail.com> added the comment:

I have attached a fix to this issue (and implicitly issue1062277).

This patch allows pickling self-referential sets by implementing a set.__reduce__ which uses states as opposed to ctor parameters.

Before:
>>> s=set([1,2,3])
>>> s.__reduce__()
(<class 'set'>, ([1, 2, 3],), None)
>>> len(pickle.dumps(s,1))
38

After:
>>> s=set([1,2,3])
>>> s.__reduce__()
(<class 'set'>, (), [1, 2, 3])
>>> len(pickle.dumps(s,1))
36

Basically what this does is: instead of unpickling the set by doing set([1,2,3]) it does s=set(); s.__setstate__([1,2,3]).
States are supported in all versions of pickle so this shouldn't break anything.
Creating empty data structures and then filling them is the way pickle does it for all mutable containers in order to allow self-references (with the exception of sets, of course).

Since memoization is performed after the object is created but before its state is set, pickling an object's state can contain references to oneself.

    class A:
        pass

    a=A()
    s=set([a])
    a.s=s

    s_=loads(dumps(s,1))
    next(iter(s_)).s is s_ # True

Note that this fix only applies for sets, not frozensets. Frozensets are a different matter, because their immutability makes it impossible to set their state. Self-referential frozensets are currently supported in my implementation of pickle4 using a trick similar to what tuples use. But the trick works more easily there because frozensets have their own opcodes, like tuples.

Also note that applying this patch makes Lib/test/pickletester.py:test_pickle_to_2x fail (DATA3 and DATA6 there contain pickled data of sets, which naturally have changed).
I'll upload a patch fixing this as well as adding one or more test for sets soon.

----------
keywords: +patch
nosy: +mstefanro
Added file: http://bugs.python.org/file26533/self_referential-sets.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9269>
_______________________________________

From report at bugs.python.org  Fri Jul 27 03:21:51 2012
From: report at bugs.python.org (mike bayer)
Date: Fri, 27 Jul 2012 01:21:51 +0000
Subject: [issue1062277] Pickle breakage with reduction of recursive structures
Message-ID: <1343352111.82.0.614738467673.issue1062277@psf.upfronthosting.co.za>


Changes by mike bayer <mike_mp at zzzcomputing.com>:


----------
nosy: +zzzeek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1062277>
_______________________________________

From report at bugs.python.org  Fri Jul 27 03:23:08 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 27 Jul 2012 01:23:08 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
Message-ID: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

======================================================================
FAIL: test_dump_traceback_threads (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/3.3/lib/python3.3/test/test_faulthandler.py", line 365, in test_dump_traceback_threads
    self.check_dump_traceback_threads(None)
  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/3.3/lib/python3.3/test/test_faulthandler.py", line 361, in check_dump_traceback_threads
    self.assertRegex(output, regex)
AssertionError: Regex didn't match: '^Thread 0x[0-9a-f]+:\n(?:  File ".*threading.py", line [0-9]+ in [_a-z]+\n){1,3}  File "<string>", line 23 in run\n  File ".*threading.py", line [0-9]+ in _bootstrap_inner\n  File ".*threading.py", line [0-9]+ in _bootstrap\n\nCurrent thread XXX:\n  File "<string>", line 10 in dump\n  File "<string>", line 28 in <module>$' not found in 'Thread 0x0000000103a4a000:\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 184 in wait\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 330 in wait\n  File "<string>", line 23 in run\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 639 in _bootstrap_inner\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 616 in _bootstrap\n\nCurrent thread XXX:\n  File "<string>", line 10 in dump\n  File "<string>", line 28 in <module>'

======================================================================
FAIL: test_dump_traceback_threads_file (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/3.3/lib/python3.3/test/test_faulthandler.py", line 369, in test_dump_traceback_threads_file
    self.check_dump_traceback_threads(filename)
  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/3.3/lib/python3.3/test/test_faulthandler.py", line 361, in check_dump_traceback_threads
    self.assertRegex(output, regex)
AssertionError: Regex didn't match: '^Thread 0x[0-9a-f]+:\n(?:  File ".*threading.py", line [0-9]+ in [_a-z]+\n){1,3}  File "<string>", line 23 in run\n  File ".*threading.py", line [0-9]+ in _bootstrap_inner\n  File ".*threading.py", line [0-9]+ in _bootstrap\n\nCurrent thread XXX:\n  File "<string>", line 8 in dump\n  File "<string>", line 28 in <module>$' not found in 'Thread 0x0000000105215000:\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 184 in wait\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 330 in wait\n  File "<string>", line 23 in run\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 639 in _bootstrap_inner\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 616 in _bootstrap\n\nCurrent thread XXX:\n  File "<string>", line 8 in dump\n  File "<string>", line 28 in <module>'

----------------------------------------------------------------------
Ran 27 tests in 20.582s

FAILED (failures=2)
test test_faulthandler failed

The two failing tests call check_dump_traceback_threads which has a regex to find threading.py in the traceback but the path is truncated in the traceback so "threading.py" doesn't appear.

----------
components: Tests
messages: 166531
nosy: haypo, ned.deily
priority: low
severity: normal
status: open
title: test_faulthandler can fail if install path is too long
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Fri Jul 27 03:34:16 2012
From: report at bugs.python.org (=?utf-8?q?Thi=C3=A9baud_Weksteen?=)
Date: Fri, 27 Jul 2012 01:34:16 +0000
Subject: [issue15464] ssl: add set_msg_callback function
Message-ID: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za>


New submission from Thi?baud Weksteen <thiebaud at weksteen.fr>:

I wrote a patch for Python 3 to expose the function
SSL_CTX_set_msg_callback in the module ssl.

Here is a description of this function:
"SSL_CTX_set_msg_callback() or SSL_set_msg_callback() can be used
to define a message callback function cb for observing all SSL/TLS
protocol messages (such as handshake messages) that are received or sent."

There is also a test case included in the patch.

Comments are welcomed.

----------
components: Extension Modules
files: ssl_msg_callback.patch
keywords: patch
messages: 166532
nosy: tweksteen
priority: normal
severity: normal
status: open
title: ssl: add set_msg_callback function
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26534/ssl_msg_callback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15464>
_______________________________________

From report at bugs.python.org  Fri Jul 27 04:23:28 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Jul 2012 02:23:28 +0000
Subject: [issue15461] os.stat() 's inappropriate behavior when dealing with a
	broken link in linux systems.
In-Reply-To: <1343336601.05.0.224760800644.issue15461@psf.upfronthosting.co.za>
Message-ID: <1343355808.69.0.919259967432.issue15461@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Because we are doing what the linux stat call (and command) does .  See man stat.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15461>
_______________________________________

From report at bugs.python.org  Fri Jul 27 04:33:25 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Jul 2012 02:33:25 +0000
Subject: [issue15462] UTF8 BOM incorrectly prepended syslog messages when
	using rsysolog
In-Reply-To: <1343336781.88.0.897924928117.issue15462@psf.upfronthosting.co.za>
Message-ID: <1343356405.94.0.195286948686.issue15462@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe this is a duplicate of issue 14452.

----------
components:  -IO, Library (Lib)
nosy: +r.david.murray, vinay.sajip
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> SysLogHandler sends invalid messages when using unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15462>
_______________________________________

From report at bugs.python.org  Fri Jul 27 04:34:02 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 27 Jul 2012 02:34:02 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343356442.95.0.402133432879.issue15463@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

This might be obvious to some people, but for background purposes, this seems to be where the file name gets truncated (in the dump_frame() function):

    write(fd, "\"", 1);
    dump_ascii(fd, code->co_filename);
    write(fd, "\"", 1);

http://hg.python.org/cpython/file/ddf15cd9be4a/Python/traceback.c#l564

Out of curiosity, I wonder if we have a test to check the formatting of tracebacks for long file names, which would be nice to have.  I didn't see one.

----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Fri Jul 27 04:35:06 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Jul 2012 02:35:06 +0000
Subject: [issue15464] ssl: add set_msg_callback function
In-Reply-To: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za>
Message-ID: <1343356506.55.0.991540207572.issue15464@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15464>
_______________________________________

From report at bugs.python.org  Fri Jul 27 04:47:53 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 27 Jul 2012 02:47:53 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343357273.28.0.0450377242795.issue15463@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Without investigating further, my instinct would be to prefer to truncate in the middle, if possible, otherwise truncate the head of the path, rather than truncate the tail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Fri Jul 27 05:12:10 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 27 Jul 2012 03:12:10 +0000
Subject: [issue15464] ssl: add set_msg_callback function
In-Reply-To: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za>
Message-ID: <1343358730.15.0.941647102781.issue15464@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

In your test, is there a reason you don't need to verify that your callback is actually called?

+            def cb(packet):
+              self.assertGreater(len(packet), 0)
+            ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
+            ctx.set_msg_callback(cb)

----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15464>
_______________________________________

From report at bugs.python.org  Fri Jul 27 05:57:30 2012
From: report at bugs.python.org (=?utf-8?q?Thi=C3=A9baud_Weksteen?=)
Date: Fri, 27 Jul 2012 03:57:30 +0000
Subject: [issue15464] ssl: add set_msg_callback function
In-Reply-To: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za>
Message-ID: <1343361450.64.0.650401217197.issue15464@psf.upfronthosting.co.za>


Thi?baud Weksteen <thiebaud at weksteen.fr> added the comment:

I'm not sure what would be the best way to verify that. 
What about:

    def test_connect_with_msg_callback(self):
        with support.transient_internet("svn.python.org"):
            self.called = False
            def cb(packet):
                self.assertGreater(len(packet), 0)
                self.called = True
            ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
            ctx.set_msg_callback(cb)
            s = ctx.wrap_socket(socket.socket(socket.AF_INET))
            try:
                s.connect(("svn.python.org", 443))
                self.assertTrue(self.called)
            finally:
                s.close()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15464>
_______________________________________

From report at bugs.python.org  Fri Jul 27 05:58:03 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 27 Jul 2012 03:58:03 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343361483.58.0.712633176745.issue15231@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric - what is missing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Fri Jul 27 06:00:23 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Fri, 27 Jul 2012 04:00:23 +0000
Subject: [issue12034] check_GetFinalPathNameByHandle() suboptimal
In-Reply-To: <1304884806.89.0.503663992861.issue12034@psf.upfronthosting.co.za>
Message-ID: <1343361623.48.0.224845118626.issue12034@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Patch to cache result of check_GetFinalPathNameByHandle().

----------
keywords: +patch
nosy: +ishimoto
Added file: http://bugs.python.org/file26535/issue12034.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12034>
_______________________________________

From report at bugs.python.org  Fri Jul 27 07:18:56 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 27 Jul 2012 05:18:56 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343366336.97.0.448876217508.issue14578@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I would really like to release beta2 this weekend.  Is it possible to get this resolved by then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Fri Jul 27 07:19:00 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 27 Jul 2012 05:19:00 +0000
Subject: [issue14330] don't use host python,
	use host search paths for host compiler
In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za>
Message-ID: <1343366340.11.0.94636137181.issue14330@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I would really like to release beta2 this weekend.  Is it possible to get this resolved by then?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14330>
_______________________________________

From report at bugs.python.org  Fri Jul 27 08:17:19 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Fri, 27 Jul 2012 06:17:19 +0000
Subject: [issue15461] os.stat() 's inappropriate behavior when dealing with a
	broken link in linux systems.
In-Reply-To: <1343336601.05.0.224760800644.issue15461@psf.upfronthosting.co.za>
Message-ID: <1343369839.6.0.630700768027.issue15461@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

For the sake of completeness: what you're looking for is os.lstat.

----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15461>
_______________________________________

From report at bugs.python.org  Fri Jul 27 08:33:10 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 27 Jul 2012 06:33:10 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343370790.86.0.190594173865.issue14578@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

So I tried to make proper changes in _bootstrap.py, and regenerate importlib.h on Linux.
I don't have any Windows machine; all this is completely untested, but at least it can help some Windows developer to finish the work, and write unit tests...
(in case of bugs, if you don't know how to regenerate importlib.h, it's still possible to monkeypatch the WindowsRegistryImporter class; it's in sys.meta_path)

----------
keywords: +patch
Added file: http://bugs.python.org/file26536/winreg_loader.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Fri Jul 27 08:39:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 06:39:53 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343371193.31.0.66516267735.issue14578@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/issue14578>
_______________________________________

From report at bugs.python.org  Fri Jul 27 08:45:24 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 06:45:24 +0000
Subject: [issue12034] check_GetFinalPathNameByHandle() suboptimal
In-Reply-To: <1304884806.89.0.503663992861.issue12034@psf.upfronthosting.co.za>
Message-ID: <1343371524.56.0.485305169638.issue12034@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you, patch looks fine to me. It will have to wait for after the 3.3 release, though, since we are now in feature freeze.

----------
versions: +Python 3.4 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12034>
_______________________________________

From report at bugs.python.org  Fri Jul 27 09:05:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 Jul 2012 07:05:25 +0000
Subject: [issue15465] Improved documentation for C API version info
Message-ID: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As far as I can tell, the only mentions of the C API version macros are:

1. In the prose for the stable ABI section (incidentally: this section has a typo in the title)

2. In the documentation for sys.hexversion

There should be a clear "API and ABI Versioning" section in the C API docs that covers:

PY_LIMITED_API
PY_HEX_VERSION
PY_MAJOR_VERSION
PY_MINOR_VERSION
PY_MICRO_VERSION
PY_RELEASE_LEVEL
PY_RELEASE_SERIAL

----------
assignee: docs at python
components: Documentation
messages: 166546
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Improved documentation for C API version info
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15465>
_______________________________________

From report at bugs.python.org  Fri Jul 27 09:05:35 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 Jul 2012 07:05:35 +0000
Subject: [issue15465] Improved documentation for C API version info
In-Reply-To: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>
Message-ID: <1343372735.51.0.641148081546.issue15465@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15465>
_______________________________________

From report at bugs.python.org  Fri Jul 27 09:10:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 07:10:53 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343373053.18.0.589497955476.issue14578@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I would really like to release beta2 this weekend.  Is it possible to get this resolved by then?

At worse, perhaps 3.3 can be released without this feature. I don't know who relies on it.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Fri Jul 27 09:51:56 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Jul 2012 07:51:56 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343357273.28.0.0450377242795.issue15463@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa+Fmb+Bx9PJy7SQ=kDmEbRq7saNkK2yYT5nVHL8q=o8g@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

faulthandler has arbitrary limits to avoid an unlimited loop if some
data are corrupted.

#define MAX_STRING_LENGTH 100
#define MAX_FRAME_DEPTH 100
#define MAX_NTHREADS 100

The string limit is maybe too short. MAX_STRING_LENGTH can be set to
500 characters, what do you think?

We may also add a function to change these limits at runtime.

> Without investigating further, my instinct would be to prefer to truncate in the middle,
> if possible, otherwise truncate the head of the path, rather than truncate the tail.

faulthandler does not trust anything, including the length of the
string. Change the limit to 500 characters should be safer.

Remember that faulthandler is called when something really bad
happens, like a segfault or an illegal instruction.

faulthandler may be less strict when it is called explicitly, ex:
faulthandler.dump_traceback().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Fri Jul 27 10:57:59 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 27 Jul 2012 08:57:59 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343379479.5.0.822605616834.issue14578@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

pywin32 used to install modules this way, but it seems it doesn't anymore:
http://pywin32.hg.sourceforge.net/hgweb/pywin32/pywin32/file/16707e6f1624/pywin32_postinstall.py#l307
    # It is possible people with old versions installed with still have 
    # pywintypes and pythoncom registered.  We no longer need this, and stale
    # entries hurt us.
Maybe this feature is not so important after all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Fri Jul 27 11:34:09 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 27 Jul 2012 09:34:09 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343381649.04.0.81695926041.issue12834@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Any objections to committing this before beta2? What about the
len > view->len change: Does that look reasonable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Fri Jul 27 12:15:11 2012
From: report at bugs.python.org (Ricky Ng-Adam)
Date: Fri, 27 Jul 2012 10:15:11 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>
Message-ID: <1343384111.77.0.382222281669.issue12556@psf.upfronthosting.co.za>


Ricky Ng-Adam <rngadam at lophilo.com> added the comment:

I find this resolution to rejected somewhat questionable. It has been pointed that the mmap behavior in Python differs from the behavior of the underlying mmap as defined by the system documentation. 

I think the incorrect assumption here is that mmap is used to only map real files. In the case of virtual files such those found in sysfs and debugfs in Linux, mmap is a general operation that lets the underlying driver arbitrarily map to other memory regions.

As an example, we are developing a new hardware platform. To maximize performance, instead of creating a file-based interface to the Linux driver, we are experimenting with mmap'ing the hardware memory address to the userspace by implementing the mmap operation in our Linux kernel module. 

This mmap operation works in C and in Node.JS, but not in Python where it can't get past the underlying debugfs (or sysfs) file having a size of 0...

----------
nosy: +rngadam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12556>
_______________________________________

From report at bugs.python.org  Fri Jul 27 13:00:59 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 27 Jul 2012 11:00:59 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343386859.3.0.285875665989.issue1692335@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Here is a minimal patch against default.

It is a clear improvement on the current situation, even though it still cannot handle the case

  class Error(Exception):
    def __init__(self, x):
      Exception.__init__(self)
      self.x = x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 13:01:26 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 27 Jul 2012 11:01:26 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343386886.69.0.701033348259.issue1692335@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


Added file: http://bugs.python.org/file26537/init_args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 13:08:45 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Jul 2012 11:08:45 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <3Wk6qb2z5jzMXk@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d2f448dbc30d by Richard Oudkerk in branch 'default':
Issue #15364: Fix sysconfig.get_config_var('srcdir') to be an absolute path.
http://hg.python.org/cpython/rev/d2f448dbc30d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Fri Jul 27 13:40:03 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 27 Jul 2012 11:40:03 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343389203.37.0.945790073284.issue15431@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Here's a patch.  A new project, _freeze_importlib, has the necessary prerequisites and runs the executable, generating importlib.h, as a post-build step.

I'm not sure if we should make this project a pre-requisite of any other projects, though

----------
keywords: +patch
Added file: http://bugs.python.org/file26538/_freeze_importlib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Fri Jul 27 13:40:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 11:40:44 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
In-Reply-To: <1343386886.73.0.939388151763.issue1692335@psf.upfronthosting.co.za>
Message-ID: <1343389114.3352.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

There should be an actual pickling / unpickling test, so that this
doesn't regress by mistake.

Le vendredi 27 juillet 2012 ? 11:01 +0000, Richard Oudkerk a ?crit :
> Changes by Richard Oudkerk <shibturn at gmail.com>:
> 
> 
> Added file: http://bugs.python.org/file26537/init_args.patch
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 13:49:42 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 27 Jul 2012 11:49:42 +0000
Subject: [issue15041] tkinter documentation: update  "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1343389782.65.0.697036583452.issue15041@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Ok

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15041>
_______________________________________

From report at bugs.python.org  Fri Jul 27 14:09:01 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 27 Jul 2012 12:09:01 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343390941.19.0.630494735239.issue1692335@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

ExceptionTests.testAttributes already checks the attributes of unpickled copies (using all protocols).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 14:11:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 12:11:13 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343391073.01.0.101031690732.issue1692335@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> ExceptionTests.testAttributes already checks the attributes of
> unpickled copies (using all protocols).

Ok, sorry for the noise then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 14:50:59 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 27 Jul 2012 12:50:59 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
Message-ID: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

As shown in a patch in issue15431, frozen.c does not output the same data on different platforms.

The first difference looks like this (extracted from the patch):
-    101,73,255,255,255,255,0,0,0,0,40,10,0,0,0,117,
+    101,108,3,0,0,0,255,127,255,127,3,0,40,10,0,0,

On first row, 'I' followed by 0xFFFFFFFF on 8 bytes.
On second row, 'l' followed by 3 followed by 0xFFFFFFFF (in 3 chunks of 15 bits).
The Python number 0xFFFFFFFF is marshalled with TYPE_INT64 when SIZEOF_LONG>4 (Unix 64bit), and with TYPE_LONG on other platforms (32bit, or win64)

The C "long" type has much less importance in 3.x Python, because PyIntObject does not exist anymore.
I suggest to remove this distinction, and allow TYPE_INT64 on all platforms.

I don't see any compatibility issue, on unmarshalling both methods produce the same object.
I'll try to suggest a patch later today.

----------
messages: 166559
nosy: amaury.forgeotdarc, pitrou
priority: high
severity: normal
status: open
title: Python/importlib.h is different on 32bit and 64bit

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Fri Jul 27 14:51:37 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 27 Jul 2012 12:51:37 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343393497.25.0.350214951328.issue15431@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

IMO dependencies is not a big issue here.  In the worst case, the developer can build a second time...

I think your patch won't work on Unix machines: _freeze_importlib.c is linked with all Python files *except* frozen.c which defines PyImport_FrozenModules.  #ifdef should be used IMO.

Also, I noticed that the marshalled code is different. The first difference a 32bit vs. 64bit issue: 0xFFFFFFFF is marshalled as a TYPE_INT64 on 64bit platforms, but as a TYPE_LONG on 32bit platforms.  See issue15466.

----------
dependencies: +Python/importlib.h is different on 32bit and 64bit

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Fri Jul 27 14:53:53 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 27 Jul 2012 12:53:53 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343393633.48.0.900362218772.issue15466@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I realize that uppercase I and lowercase L are easily confused:

On first row, 'I' (=TYPE_INT64) followed by 0xFFFFFFFF on 8 bytes.
On second row, 'l' (=TYPE_LONG) followed by 3 followed by 0xFFFFFFFF (in 3 chunks of 15 bits).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Fri Jul 27 14:56:12 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Fri, 27 Jul 2012 12:56:12 +0000
Subject: [issue1062277] Pickle breakage with reduction of recursive structures
Message-ID: <1343393772.89.0.6101752312.issue1062277@psf.upfronthosting.co.za>


Changes by Stefan Mihaila <mstefanro at gmail.com>:


----------
nosy: +mstefanro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1062277>
_______________________________________

From report at bugs.python.org  Fri Jul 27 15:20:32 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 Jul 2012 13:20:32 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343395232.86.0.536676849672.issue12834@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Georg, need a call on how close you are to cutting beta 2 and whether you want this to wait until rc1.

----------
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Fri Jul 27 15:21:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 13:21:31 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343395291.32.0.621638689189.issue15466@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I suggest to remove this distinction, and allow TYPE_INT64 on all
> platforms.

You have to find a 64-bit C int type that works on all platforms and for which a PyLongAsXXX() function exists, though. Or perhaps you want to restrict yourself to systems which have "long long" and where it is at least 64 bits wide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Fri Jul 27 15:28:17 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 Jul 2012 13:28:17 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343395697.27.0.137952852379.issue12834@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Summary of my review for Georg's benefit: I had one minor formatting nit with the patch (which Stefan can easily fix before committing), but it otherwise looked fine to me.

I also agree that the old implicit truncation was unusable in practice, as the *actual* length is not returned from the function, and in fact cannot be returned because the return type is int rather than Py_ssize_t. A length mismatch therefore needs to be an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Fri Jul 27 15:45:41 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 27 Jul 2012 13:45:41 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343396741.34.0.363535717594.issue15466@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

My primary goal is to have a stable importlib.h, and currently all developer work on machines where PY_LONG_LONG is >64bit.  So the restriction is OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Fri Jul 27 15:54:41 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Jul 2012 13:54:41 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1343397281.82.0.556410719371.issue15364@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, so LGTM.  Let?s ask the RMs if this is a new behavior or a bugfix.

----------
nosy: +benjamin.peterson, georg.brandl
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Fri Jul 27 15:57:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Jul 2012 13:57:31 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <3WkBZL4fSnzN4g@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4e85e4743757 by Richard Oudkerk in branch '2.7':
Issue #6056: Make multiprocessing use setblocking(True) on the sockets it uses.
http://hg.python.org/cpython/rev/4e85e4743757

New changeset 290f04722be3 by Richard Oudkerk in branch '3.2':
Issue #6056: Make multiprocessing use setblocking(True) on the sockets it uses.
http://hg.python.org/cpython/rev/290f04722be3

New changeset f03839401420 by Richard Oudkerk in branch 'default':
Issue #6056: Make multiprocessing use setblocking(True) on the sockets it uses.
http://hg.python.org/cpython/rev/f03839401420

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Fri Jul 27 16:05:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Jul 2012 14:05:24 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343397924.03.0.648422435138.issue15231@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Compare:

running the command above without warnings is not sufficient for PyPI to convert the content successfully.

being able to run the command above without warnings is not sufficient to be sure that PyPI will convert the content successfully.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Fri Jul 27 16:10:51 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 27 Jul 2012 14:10:51 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1343398251.15.0.375564753117.issue15364@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The current patch should be fine, although it is IMHO not the long-term solution. For installed python's get_config_var('srcdir') still lies, but now at least returns slightly more sane path.

As I noted before the real problem is that it is not clear which config_vars are usable in which situations. One example is 'srcdir': this value is only useful in the build tree and there currently is no clean way to signal that you are retrieving a value that is not useful.  Another example is 'RUNSHARED', that's also only useable when building python.

I'm not sure what the right solution for the larger issue is. It might be good enough to document generally useful config_vars and warn that other's might exist but might not be safe to use, on the other hand it might be better to explicitly reduce the set of config_vars to something sane (and document which those are and when they can be used)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Fri Jul 27 16:26:49 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Fri, 27 Jul 2012 14:26:49 +0000
Subject: [issue9269] Cannot pickle self-referencing sets
In-Reply-To: <1279234902.88.0.629141543515.issue9269@psf.upfronthosting.co.za>
Message-ID: <1343399209.34.0.385457740345.issue9269@psf.upfronthosting.co.za>


Stefan Mihaila <mstefanro at gmail.com> added the comment:

Attaching patch for fixing a test and adding better testing of sets.

----------
Added file: http://bugs.python.org/file26539/sets-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9269>
_______________________________________

From report at bugs.python.org  Fri Jul 27 16:37:38 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 14:37:38 +0000
Subject: [issue9269] Cannot pickle self-referencing sets
In-Reply-To: <1279234902.88.0.629141543515.issue9269@psf.upfronthosting.co.za>
Message-ID: <1343399858.73.0.4321175108.issue9269@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: belopolsky -> 
dependencies:  -Pickle breakage with reduction of recursive structures
stage: needs patch -> patch review
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9269>
_______________________________________

From report at bugs.python.org  Fri Jul 27 16:42:50 2012
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 27 Jul 2012 14:42:50 +0000
Subject: [issue14330] don't use host python,
	use host search paths for host compiler
In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za>
Message-ID: <1343400170.91.0.920484010812.issue14330@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

just back in DE today, but still travelling. Won't be able to look at this before late Monday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14330>
_______________________________________

From report at bugs.python.org  Fri Jul 27 16:58:53 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 27 Jul 2012 14:58:53 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343401133.3.0.000862582755069.issue1692335@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Temporarily making this a blocker to see if Georg considers this a bugfix or feature.

----------
nosy: +benjamin.peterson
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 16:59:58 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 27 Jul 2012 14:59:58 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343401198.14.0.108488443448.issue15466@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Fri Jul 27 17:18:37 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Fri, 27 Jul 2012 15:18:37 +0000
Subject: [issue14135] check for locale changes in test.regrtest
In-Reply-To: <1330296468.42.0.0463135348779.issue14135@psf.upfronthosting.co.za>
Message-ID: <1343402317.57.0.14675673422.issue14135@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Patch to check if locale was changed.

Since I'm not sure where to put tests for test.regrtest, I created 
new file, test.test_regrtest.

----------
keywords: +patch
nosy: +ishimoto
Added file: http://bugs.python.org/file26540/issue14135.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14135>
_______________________________________

From report at bugs.python.org  Fri Jul 27 17:33:47 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 15:33:47 +0000
Subject: [issue15467] Updating __sizeof__ tests
Message-ID: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

The proposed patches move to test.support some functions, which will be useful for testing __sizeof__. The next few patches will use it. Also in 3.3 some bugs have fixed, now "n" is used for Py_ssize_t and Py_hash_t (which is not long now).

----------
components: Tests
files: sizeof_tests-3.3.patch
keywords: patch
messages: 166574
nosy: loewis, storchaka
priority: normal
severity: normal
status: open
title: Updating __sizeof__ tests
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26541/sizeof_tests-3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Fri Jul 27 17:34:23 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 15:34:23 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343403263.35.0.652910260907.issue15467@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26542/sizeof_tests-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Fri Jul 27 17:34:44 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 15:34:44 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343403284.8.0.51745976987.issue15467@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26543/sizeof_tests-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Fri Jul 27 17:38:22 2012
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 Jul 2012 15:38:22 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1343403502.97.0.979646009487.issue9216@psf.upfronthosting.co.za>


Daniel Holth <dholth at fastmail.fm> added the comment:

While you are at it, can you edit the docs to put md5() at the bottom of the page at the back of the list in a 2-point font and raise a DeprecationWarning("This function is totally lame, and it is slower than SHA-3, get with the program.") the first time it is used? I don't agree that md5 has a legitimate place in systems designed after 1996.

----------
nosy: +dholth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Fri Jul 27 17:41:51 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 15:41:51 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1343403711.98.0.728314064836.issue9216@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> While you are at it, can you edit the docs to put md5() at the bottom
> of the page at the back of the list in a 2-point font and raise a
> DeprecationWarning("This function is totally lame, and it is slower
> than SHA-3, get with the program.") the first time it is used?

Please... don't make suggestions unrelated to the issue. Open a new issue instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Fri Jul 27 17:46:47 2012
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 Jul 2012 15:46:47 +0000
Subject: [issue15468] Edit docs to hide hashlib.md5()
Message-ID: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za>


New submission from Daniel Holth <dholth at fastmail.fm>:

md5() has been obsolete since 1996. It has no place as the first item in hashlib's list of "guaranteed to be available" hashes, and it doesn't work when Python has been compiled to be FIPS-compliant.

The documentation should be edited to make md5's availability as non-obvious as possible.

----------
messages: 166577
nosy: dholth
priority: normal
severity: normal
status: open
title: Edit docs to hide hashlib.md5()
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15468>
_______________________________________

From report at bugs.python.org  Fri Jul 27 17:47:58 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 15:47:58 +0000
Subject: [issue15469] Correct __sizeof__ support for deque
Message-ID: <1343404078.66.0.00721941905437.issue15469@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Here is a patch that implements correct __sizeof__ for collections.deque.

Test depends on issue15467.

----------
components: Library (Lib)
files: deque_sizeof.patch
keywords: patch
messages: 166578
nosy: storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for deque
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26544/deque_sizeof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15469>
_______________________________________

From report at bugs.python.org  Fri Jul 27 17:49:23 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 15:49:23 +0000
Subject: [issue15469] Correct __sizeof__ support for deque
In-Reply-To: <1343404078.66.0.00721941905437.issue15469@psf.upfronthosting.co.za>
Message-ID: <1343404163.65.0.294190771274.issue15469@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +rhettinger
Added file: http://bugs.python.org/file26545/deque_sizeof-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15469>
_______________________________________

From report at bugs.python.org  Fri Jul 27 17:49:54 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 15:49:54 +0000
Subject: [issue15469] Correct __sizeof__ support for deque
In-Reply-To: <1343404078.66.0.00721941905437.issue15469@psf.upfronthosting.co.za>
Message-ID: <1343404194.98.0.338361130496.issue15469@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26546/deque_sizeof-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15469>
_______________________________________

From report at bugs.python.org  Fri Jul 27 18:01:10 2012
From: report at bugs.python.org (Seamus McKenna)
Date: Fri, 27 Jul 2012 16:01:10 +0000
Subject: [issue15470] Stuck/hang when reading ssl object
Message-ID: <1343404870.87.0.816938002683.issue15470@psf.upfronthosting.co.za>


New submission from Seamus McKenna <seamus.mckenna at intunenetworks.com>:

My python scripting has been running for several weeks periodically sending out emails.  However the script has been stuck for the last 24 hrs.  No parts of my script have been executed in this period.

On terminating the script via ctrl-c, I can see that the script is stuck with the python ssl library. See below;

-----------------------------------------------------------------
File "/export2/home/intregress/LabEnv210/lab/int_lib/int_tools/PTM_COMMON/user.py", line 4277, in email
    mailServer.sendmail(gmail_user, to, msg.as_string())
  File "/tools/ACTIVESTATE/python/2.7.1.3/x86/lib/python2.7/smtplib.py", line 713, in sendmail
    (code,resp) = self.data(msg)
  File "/tools/ACTIVESTATE/python/2.7.1.3/x86/lib/python2.7/smtplib.py", line 482, in data
    (code,msg)=self.getreply()
  File "/tools/ACTIVESTATE/python/2.7.1.3/x86/lib/python2.7/smtplib.py", line 338, in getreply
    line = self.file.readline()
  File "/tools/ACTIVESTATE/python/2.7.1.3/x86/lib/python2.7/smtplib.py", line 177, in readline
    chr = self.sslobj.read(1)
  File "/tools/ACTIVESTATE/python/2.7.1.3/x86/lib/python2.7/ssl.py", line 138, in read
    return self._sslobj.read(len)
-------------------------------------------------------------------

----------
components: None
messages: 166579
nosy: seamus.mckenna
priority: normal
severity: normal
status: open
title: Stuck/hang when reading ssl object
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15470>
_______________________________________

From report at bugs.python.org  Fri Jul 27 18:13:31 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 27 Jul 2012 16:13:31 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343405611.65.0.909783808246.issue15467@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The problem is that this adds new features to test_support, which can only be done in 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Fri Jul 27 18:21:53 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 27 Jul 2012 16:21:53 +0000
Subject: [issue15411] os.chmod() does not follow symlinks on Windows
In-Reply-To: <1342859484.11.0.980886642738.issue15411@psf.upfronthosting.co.za>
Message-ID: <1343406113.79.0.979095388186.issue15411@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15411>
_______________________________________

From report at bugs.python.org  Fri Jul 27 18:26:25 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 27 Jul 2012 16:26:25 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343406385.23.0.849356251742.issue1692335@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

BTW, BaseException_init() has the code

    Py_XDECREF(self->args);
    self->args = args;
    Py_INCREF(self->args);

Presumably the Py_XDECREF(self->args) would be better replaced by Py_CLEAR(self->args)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 18:54:29 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 27 Jul 2012 16:54:29 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343408069.48.0.190598711335.issue15431@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Thank you.  I see how I must change the linkage on PC Only, although I wonder why tuen unix version isn't simply doing something similar..

The marshaled code was indeed created using 64 bits.  I was unsure whether to include that file as part of the patch, perhaps I shouldn't.

I'll wait for an update for the 64 bit issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Fri Jul 27 18:58:43 2012
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 27 Jul 2012 16:58:43 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343408323.18.0.976221951946.issue14578@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

> I would really like to release beta2 this weekend.  Is it possible to get this resolved by then?

As others stated, I'm not sure it's entirely necessary. Given the two dependencies that need to be fixed before this one can move forward, I don't think it's happening soon so I'd suggest to move on with beta2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Fri Jul 27 19:05:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Jul 2012 17:05:21 +0000
Subject: [issue15468] Edit docs to hide hashlib.md5()
In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za>
Message-ID: <1343408721.22.0.0881072273041.issue15468@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15468>
_______________________________________

From report at bugs.python.org  Fri Jul 27 19:07:56 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 27 Jul 2012 17:07:56 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343408876.79.0.901842788357.issue15431@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

If you look at Makefile.pre.in, you'll see that on Unix it builds a special binary: Modules/_freezeimportlib.c;  it uses most of Python machinery (except importlib, of course), and manually open importlib/_bootstrap.py, compiles it, and marshals the result to importlib.h.

Your solution on Windows is to use the full python.exe instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Fri Jul 27 19:08:17 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 27 Jul 2012 17:08:17 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343408897.28.0.245685890096.issue15431@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
Removed message: http://bugs.python.org/msg166584

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Fri Jul 27 19:09:37 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 27 Jul 2012 17:09:37 +0000
Subject: [issue15471] importlib's __import__() argument style nit
Message-ID: <1343408977.86.0.620892563203.issue15471@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Very minor style nit.  In general, it's not considered good style to use mutable objects in default argument values.  importlib's _bootstrap.__import__() does just this for its globals, locals, and fromlist arguments.

The implementation currently doesn't abuse this, or allow any of the extensions to abuse, it may be possible in the future to naively cause negative side-effects due to mutate the keyword arguments.  It would be better to use non-mutable default values in the argument list.

----------
assignee: brett.cannon
components: Library (Lib)
keywords: easy
messages: 166585
nosy: barry, brett.cannon
priority: low
severity: normal
status: open
title: importlib's __import__() argument style nit
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15471>
_______________________________________

From report at bugs.python.org  Fri Jul 27 19:19:59 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 27 Jul 2012 17:19:59 +0000
Subject: [issue15468] Edit docs to hide hashlib.md5()
In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za>
Message-ID: <1343409599.24.0.88048130322.issue15468@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The only edit that is needed is for md5 to be documented as unavailable when Python has been compiled in FIPS-compliant mode.  Most of the world does not and will never use that mode.

md5 is still a perfectly good algorithm for many uses and is required for legacy reasons to support the decades of already deployed uses of md5.

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15468>
_______________________________________

From report at bugs.python.org  Fri Jul 27 19:26:34 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 27 Jul 2012 17:26:34 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343409994.25.0.407720538498.issue15431@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

(Sorry for the previous message, it was wrong, and I also pressed the wrong button...)

A Unix Makefile cannot stand circular dependencies, so _freezeimportlib.c cannot depend on frozen.o.  OTOH it's not simple to have almost-similar list of files on VS projects (here we need all-of-python-but-frozen.c), so your solution is not bad either.
Please check that python33.dll is not always rebuilt each time you hit F7, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Fri Jul 27 19:38:15 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 17:38:15 +0000
Subject: [issue15470] Stuck/hang when reading ssl object
In-Reply-To: <1343404870.87.0.816938002683.issue15470@psf.upfronthosting.co.za>
Message-ID: <1343410695.9.0.863142087923.issue15470@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the traceback shows it's stuck trying to read from the network. It doesn't mean it's stuck in the ssl library; unless your script was taking 100% CPU when you killed it, it was most likely waiting for the peer (a SMTP server, I guess) to respond.

One suggestion would be to add a timeout to the SMTP connection. You can also use set_debuglevel() to get more detailed info about what's happening.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15470>
_______________________________________

From report at bugs.python.org  Fri Jul 27 19:41:39 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 17:41:39 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343410899.98.0.401551880082.issue15431@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'll wait for an update for the 64 bit issue.

I don't think it's necessary, it's a pretty minor issue since the generated bytecode is portable anyway.

----------
dependencies:  -Python/importlib.h is different on 32bit and 64bit
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Fri Jul 27 19:42:59 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 17:42:59 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343410979.99.0.645082640718.issue1692335@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Presumably the Py_XDECREF(self->args) would be better replaced by Py_CLEAR(self->args)?

Ah, yes, definitely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 19:46:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 27 Jul 2012 17:46:38 +0000
Subject: [issue15464] ssl: add set_msg_callback function
In-Reply-To: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za>
Message-ID: <1343411198.0.0.680811288569.issue15464@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

That is one way to do it.  But it would be better to use a local variable rather than an attribute of the class (because otherwise you have to worry about resetting the value if more than one test uses the same pattern).  Something like this would be better

called = []
def cb(packet):
    called.append(1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15464>
_______________________________________

From report at bugs.python.org  Fri Jul 27 19:47:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 17:47:46 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343411266.34.0.941755000487.issue1692335@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Or you could simply Py_INCREF(args) before the Py_XDECREF...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 20:11:32 2012
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 Jul 2012 18:11:32 +0000
Subject: [issue15468] Edit docs to hide hashlib.md5()
In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za>
Message-ID: <1343412692.35.0.210870948342.issue15468@psf.upfronthosting.co.za>


Daniel Holth <dholth at fastmail.fm> added the comment:

Not to mention its continued popularity as a password hash, surpassed only by double-rot13. You've convinced me, it is reasonable to continue to support, nay, recommend md5 for the non-FIPS world. This hash function continues to have raving fans, especially in applications such as hashing data that is either read from or written to disk where the computational and storage cost of using a more modern hash is too severe for the majority of new applications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15468>
_______________________________________

From report at bugs.python.org  Fri Jul 27 20:23:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Jul 2012 18:23:54 +0000
Subject: [issue15472] Itertools doc summary table misdocuments some arguments
Message-ID: <1343413434.71.0.36910737273.issue15472@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

In the tables near the top of http://docs.python.org/library/itertools , some functions like cycle have an example that uses ?seq?, which is interpreted as ?sequence? but the functions do work with any iterable.

----------
assignee: docs at python
components: Documentation
messages: 166594
nosy: docs at python, eric.araujo, rhettinger
priority: normal
severity: normal
status: open
title: Itertools doc summary table misdocuments some arguments
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15472>
_______________________________________

From report at bugs.python.org  Fri Jul 27 20:36:57 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 27 Jul 2012 18:36:57 +0000
Subject: [issue15473] importlib no longer uses imp.NullImporter
Message-ID: <1343414217.14.0.255366402583.issue15473@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

I think this is mostly just out of date documentation, but I want to get Brett's feedback.  The sys module has this to say about sys.path_importer_cache:

"A dictionary acting as a cache for finder objects. The keys are paths that have been passed to sys.path_hooks and the values are the finders that are found. If a path is a valid file system path but no explicit finder is found on sys.path_hooks then None is stored to represent the implicit default finder should be used. If the path is not an existing path then imp.NullImporter is set."

Notice that last sentence.  AFAICT, this is not true in importlib.  I can find no relevant reference to imp.NullImporter in _bootstrap.py.  Maybe we should just remove this from the documentation?  OTOH, there are a few tests that check semantics related to imp.NullImporter found in sys.path_importer_cache, so clearly there are API constraints.  See also runpy.py, which gives some semantics to finding this importer in the cache.

Any suggestions for better wording about imp.NullImporter and sys.path_importer_cache?  I'd like to add this to my rewritten import machinery docs, but I'm not exactly sure what to say about it.

----------
assignee: brett.cannon
components: Documentation
messages: 166595
nosy: barry, brett.cannon, eric.smith, ncoghlan
priority: normal
severity: normal
status: open
title: importlib no longer uses imp.NullImporter
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15473>
_______________________________________

From report at bugs.python.org  Fri Jul 27 20:37:24 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 27 Jul 2012 18:37:24 +0000
Subject: [issue1234674] filecmp.cmp's "shallow" option
Message-ID: <1343414244.25.0.681664329005.issue1234674@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1234674>
_______________________________________

From report at bugs.python.org  Fri Jul 27 20:39:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 18:39:36 +0000
Subject: [issue15468] Edit docs to hide hashlib.md5()
In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za>
Message-ID: <1343414376.2.0.110191660328.issue15468@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The hashlib doc starts with "Warning: Some algorithms have known hash collision weaknesses, see the FAQ at the end" (the "FAQ at the end" is a link to a Wikipedia article). The sentence "Included are the FIPS secure hash algorithms SHA1, SHA224, SHA256, SHA384, and SHA512 (defined in FIPS 180-2) as well as RSA?s MD5 algorithm" also conveys the idea that MD5 is not part of the "secure" bunch. The only addition I can think of would be to replace md5 with sha1 in the small example snippet at the beginning.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15468>
_______________________________________

From report at bugs.python.org  Fri Jul 27 20:43:27 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 27 Jul 2012 18:43:27 +0000
Subject: [issue15460] SQLite cursor.description is not DB-API compatible
In-Reply-To: <1343327941.65.0.811204153568.issue15460@psf.upfronthosting.co.za>
Message-ID: <1343414607.88.0.981267572887.issue15460@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15460>
_______________________________________

From report at bugs.python.org  Fri Jul 27 20:50:28 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 27 Jul 2012 18:50:28 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343415028.03.0.952807700147.issue15439@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Fri Jul 27 20:51:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 18:51:25 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343415085.47.0.482401040416.issue15439@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> OK, I propose to completely drop the Doc/ACKS.txt from the documentation, and replace it with the words

Sounds good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Fri Jul 27 20:51:49 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 18:51:49 +0000
Subject: [issue15460] SQLite cursor.description is not DB-API compatible
In-Reply-To: <1343327941.65.0.811204153568.issue15460@psf.upfronthosting.co.za>
Message-ID: <1343415109.19.0.230331779554.issue15460@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15460>
_______________________________________

From report at bugs.python.org  Fri Jul 27 20:54:19 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 27 Jul 2012 18:54:19 +0000
Subject: [issue15418] 2to3 docs should mention setup.py fixes required to
	install compatible packages in Python 3
In-Reply-To: <1342944867.41.0.426616116312.issue15418@psf.upfronthosting.co.za>
Message-ID: <1343415259.93.0.93517955146.issue15418@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15418>
_______________________________________

From report at bugs.python.org  Fri Jul 27 21:00:41 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 27 Jul 2012 19:00:41 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343415641.48.0.990413575644.issue1692335@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

> Or you could simply Py_INCREF(args) before the Py_XDECREF...

But won't self->args point to a broken object while any callbacks triggered by Py_XDECREF() are run?

An alternative would be

    tmp = self->args;
    self->args = args;
    Py_INCREF(self->args);
    Py_XDECREF(tmp);

As far as I can see the idiom Py_?DECREF(self->...) is rarely safe outside of a deallocator unless you are sure the pointed to object has a "safe" type (or you are sure the refcount cannot fall to zero).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 21:02:17 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 19:02:17 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343405611.65.0.909783808246.issue15467@psf.upfronthosting.co.za>
Message-ID: <201207272201.58779.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Can we get around this by renaming check_sizeof into _check_sizeof? Or would 
we have to duplicate these auxiliary functions in every test file with 
__sizeof__ test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Fri Jul 27 21:10:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Jul 2012 19:10:07 +0000
Subject: [issue15474] Differentiate decorator and decorator factory in docs
Message-ID: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Some of the confusion encountered when writing decorators arise from the difference between a decorator (@something) and a decorator factory (@something(args)).  It would help to adopt this clearer terminology in our docs: a decorator takes the decorated function as argument and does its business, a decorator factory takes some arguments and returns a decorator which wraps the decorated function.

(I think it was Nick who suggested this in a recent-ish mailing list thread.)

----------
assignee: docs at python
components: Documentation
messages: 166600
nosy: docs at python, eric.araujo, ncoghlan
priority: normal
severity: normal
status: open
title: Differentiate decorator and decorator factory in docs
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15474>
_______________________________________

From report at bugs.python.org  Fri Jul 27 21:12:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 19:12:29 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
In-Reply-To: <1343415641.48.0.990413575644.issue1692335@psf.upfronthosting.co.za>
Message-ID: <1343416218.3352.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But won't self->args point to a broken object while any callbacks triggered by Py_XDECREF() are run?
> 
> An alternative would be
> 
>     tmp = self->args;
>     self->args = args;
>     Py_INCREF(self->args);
>     Py_XDECREF(tmp);

You are right, that's better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 21:32:30 2012
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 27 Jul 2012 19:32:30 +0000
Subject: [issue15460] SQLite cursor.description is not DB-API compatible
In-Reply-To: <1343327941.65.0.811204153568.issue15460@psf.upfronthosting.co.za>
Message-ID: <1343417550.63.0.214854989792.issue15460@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

SQLite's columns aren't typed, only SQLite values are. So it's entirely possible for the same column to have different types, like the NULL type, the INTEGER type and the TEXT type.

It's thus impossible to give meaningful type information in a SQLite3 DB-API module. That's why it's set to None instead.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15460>
_______________________________________

From report at bugs.python.org  Fri Jul 27 21:44:02 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 19:44:02 +0000
Subject: [issue15475] Correct __sizeof__ support for itertools
Message-ID: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Here is a patch that implements correct __sizeof__ for some itertools iterators: product(), combinations(), combinations_with_replacement() and permutations().

----------
components: Library (Lib)
files: itertools_sizeof-3.3.patch
keywords: patch
messages: 166603
nosy: rhettinger, storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for itertools
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26547/itertools_sizeof-3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15475>
_______________________________________

From report at bugs.python.org  Fri Jul 27 21:45:38 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 19:45:38 +0000
Subject: [issue15475] Correct __sizeof__ support for itertools
In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>
Message-ID: <1343418338.59.0.889150716729.issue15475@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26548/itertools_sizeof-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15475>
_______________________________________

From report at bugs.python.org  Fri Jul 27 21:46:13 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 19:46:13 +0000
Subject: [issue15475] Correct __sizeof__ support for itertools
In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>
Message-ID: <1343418373.41.0.46618317944.issue15475@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26549/itertools_sizeof-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15475>
_______________________________________

From report at bugs.python.org  Fri Jul 27 21:47:43 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 27 Jul 2012 19:47:43 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343418463.4.0.329237775159.issue15467@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Not sure: that's for release managers to decide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Fri Jul 27 22:16:23 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 27 Jul 2012 20:16:23 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343420183.59.0.117051632555.issue1692335@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

Patch which adds fix for BaseException_init().

Actually this class of problem seem to be quite common.  

BaseException_set_tb() appears to be affected too, as is the code in the tutorial which introduces setters.

----------
Added file: http://bugs.python.org/file26550/init_args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Jul 27 23:07:59 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Jul 2012 21:07:59 +0000
Subject: [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343423279.05.0.643387009377.issue15439@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with Martin also. A short paragraph and link to the (combined) online file is quite sufficient. There is no need for the file to be in offline copies. And I would make the change in all current versions.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15439>
_______________________________________

From report at bugs.python.org  Fri Jul 27 23:56:39 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 27 Jul 2012 21:56:39 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1343426199.93.0.550491445847.issue15311@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Hi Ned, you committed two of my Dev Guide patches in the recent past.  I was wondering if you would be willing to commit this one as well.  Thanks a lot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Sat Jul 28 00:03:27 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Jul 2012 22:03:27 +0000
Subject: [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343426607.2.0.161741066047.issue15444@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I basically agree with Marc-Andr?. Indeed, I think Acks, at least, should contain names in native spelling plus, if that is not Latin-based, a romanization. Three reasons:
1. I want English-speaking Python programmers to feel welcome to contribute and be acknowledged with what is visibly their native name.
2. I want people to be able to looks at the contributors list and see that Python is an international project.
3. Transliterations are ofter lossy, and in both directions. Romanizations do not necessarily tell contributors' compatriots how to address them in their mutual native language.

If stdlib .py files are still restricted to romanizations, those could at least be looked up in Acks. But Python does come with an utf-8 unicode editor, Idle, that handles at least the BMP just fine (because tcl/tk does).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Sat Jul 28 00:03:37 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 27 Jul 2012 22:03:37 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1343426617.91.0.862360472946.issue15311@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I believe you'll find that the "update" target in the Doc Makefile will install or update all the necessary doc tools including Sphinx.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Sat Jul 28 00:05:00 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Jul 2012 22:05:00 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1343426700.62.0.0585955352186.issue15311@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The Doc makefile does install Sphinx, just like it used to install the previous toolchain, but the devguide is a regular Sphinx project which requires you to have Sphinx installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Sat Jul 28 00:08:20 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 27 Jul 2012 22:08:20 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1343426900.77.0.260866890649.issue15311@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Sorry, of course!  The devguide is not the docset.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Sat Jul 28 00:15:28 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Jul 2012 22:15:28 +0000
Subject: [issue15451] PATH is not honored in subprocess.Popen in win32
In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>
Message-ID: <1343427328.48.0.65900111587.issue15451@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Richard is correct. From 17.1.1.2. Popen Constructor
"If env is not None, it must be a mapping that defines the environment variables for the new process; these are used instead of inheriting the current process? environment, which is the default behavior." 
(followed by Window note about SystemRoot.)

The paragraph about shell=True in 17.1.1.1. Frequently Used Arguments suggests that that might work (but see warning).

----------
nosy: +terry.reedy
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15451>
_______________________________________

From report at bugs.python.org  Sat Jul 28 00:15:50 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Jul 2012 22:15:50 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <3WkPdK0gXTzPMR@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 706b1fa362a4 by Ned Deily in branch 'default':
Issue #15311: Expand section on helping with the Developer's Guide
http://hg.python.org/devguide/rev/706b1fa362a4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Sat Jul 28 00:16:34 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 27 Jul 2012 22:16:34 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1343427394.62.0.449943124907.issue15311@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the patch.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Sat Jul 28 00:19:49 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 22:19:49 +0000
Subject: [issue15311] Developer Guide doesn't get updated once a day
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1343427589.49.0.887610001329.issue15311@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The original issue ("Developer Guide doesn't get updated once a day") isn't fixed, though.

----------
priority: normal -> critical
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Sat Jul 28 00:26:02 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 27 Jul 2012 22:26:02 +0000
Subject: [issue15311] Dev Guide update hook broken
In-Reply-To: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>
Message-ID: <1343427962.11.0.667554097602.issue15311@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks, Ned!  Renaming the issue title to be more specific.

----------
keywords:  -easy, patch
title: Developer Guide doesn't get updated once a day -> Dev Guide update hook broken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15311>
_______________________________________

From report at bugs.python.org  Sat Jul 28 01:00:58 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 27 Jul 2012 23:00:58 +0000
Subject: [issue15295] Document PEP 420 namespace packages
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343430058.1.0.458378179914.issue15295@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

First draft is complete, along with updates to the importlib abcs for the new protocols.  You'll see the language reference has a new importmachinery.rst file which describes finding and loading modules.  You'll see that the import statement docs have been simplified to point to this for step (1), and now only describe the name binding operations, i.e. step (2).  Various other documentation updates are made, including new glossary terms.

Everything lives in features/pep-420 in the importdocs branch.  I don't know if it's possible to just attach that branch to this tracker issue.  I'd rather not post a patch right now since that's much less convenient for the inevitable deluge of comments I'm sure I'll get.

Off to email python-dev now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sat Jul 28 01:01:13 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 27 Jul 2012 23:01:13 +0000
Subject: [issue15450] Allow dircmp.subdirs to behave well under subclassing
In-Reply-To: <1343260803.75.0.101432828571.issue15450@psf.upfronthosting.co.za>
Message-ID: <1343430073.99.0.130877105695.issue15450@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Updating patch to include documentation changes.

----------
keywords:  -patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26551/issue-15450-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15450>
_______________________________________

From report at bugs.python.org  Sat Jul 28 01:11:23 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 27 Jul 2012 23:11:23 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343430683.99.0.659907570154.issue15295@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker
stage: needs patch -> patch review
title: Document PEP 420 namespace packages -> Import machinery documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sat Jul 28 01:36:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 27 Jul 2012 23:36:56 +0000
Subject: [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343432216.5.0.345229867592.issue15444@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

The idea also to include a romanization is a good one.

While working on issue 15437, it occurred to me that storing the names in a structured form might come in handy.  This would let us do things like list the username(s) associated with each contributor alongside their name (and access this information programmatically).  And perhaps also include information like the following: http://www.python.org/dev/committers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15444>
_______________________________________

From report at bugs.python.org  Sat Jul 28 01:48:54 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Jul 2012 23:48:54 +0000
Subject: [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343432934.42.0.704753701284.issue15457@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think the current entry calling a generator function a generator is wrong, so I appreciate your patch. Generator functions return instances of class 'generator'*. I personally refer to generators as generator-iterators about as often as I refer to lists as list-sequences. (Generators implement the iterator protocol; lists implement the sequence protocol.)

* I personally think of a generator function as defining a virtual subclass of class generator and returning instances of that (vitual) subclass. The gf does this# by setting the gi_code attribute of instances to the code object compiled from its body. (Or perhaps it calls the generator class with its code object as parameter. In any case, this is what the special gf.__call__ method does instead of executing its code attribute. The call protocol makes this magic easy.) The generator subclass, then, is all instances with the same gi_code attribute. The name of the 'subclass' is the name of the generator function, which is also g.gi_code.co_name.

# Although 'gi_code' does not have a leading underscore, I am not sure whether it is intended to be public or if the mechanism is CPython specific. It *is' the only way to get the gf/subclass name from the generator.

What I think still needs correction is "generator then controls the execution of a generator function". The generator function has already run to create the generator. What is controlled is the execution of the code object compiled from the body of a gf. And the 'generator function' in question is not just 'a generator function' but 'the generator function that created the generator'.

So I suggest as more correct something like "generator then controls the execution of the [code object compiled from the] body of the generator function that created it" The part in [] is true but might be omitted if it seems too much in the context.

----------
nosy: +terry.reedy
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15457>
_______________________________________

From report at bugs.python.org  Sat Jul 28 02:00:41 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Jul 2012 00:00:41 +0000
Subject: [issue15453] ctype with packed bitfields does not match native
	compiler
In-Reply-To: <1343287497.79.0.127552089432.issue15453@psf.upfronthosting.co.za>
Message-ID: <1343433641.68.0.0965537459608.issue15453@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If you have not, please check other ctypes bitfields issues, especially #15119 "ctypes mixed-types bitfield layout nonsensical; doesn't match compiler." to see if this is the same problem.

----------
nosy: +terry.reedy
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15453>
_______________________________________

From report at bugs.python.org  Sat Jul 28 02:11:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 00:11:29 +0000
Subject: [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343434289.05.0.621315676048.issue15457@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks a lot for the excellent feedback.  I'll update the patch to incorporate it.

One background note: I tried not to be too strict about using "generator iterator" or "generator function" in place of "generator" in the general docs in deference to this remark in PEP 255:  "Note that when the intent is clear from context, the unqualified name "generator" may be used to refer either to a generator-function or a generator-iterator."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15457>
_______________________________________

From report at bugs.python.org  Sat Jul 28 03:16:12 2012
From: report at bugs.python.org (Michael Johnson)
Date: Sat, 28 Jul 2012 01:16:12 +0000
Subject: [issue9161] add_option in optparse no longer accepts unicode string
In-Reply-To: <1278308192.07.0.362660691035.issue9161@psf.upfronthosting.co.za>
Message-ID: <1343438172.52.0.268755696369.issue9161@psf.upfronthosting.co.za>


Michael Johnson <mjjohnson.geo at yahoo.com> added the comment:

Created a unit test for the patch that was committed in r82581. I can easily add the test to argparse too, if needed; I didn't see any tests related to Unicode in there.

----------
nosy: +mjjohnson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9161>
_______________________________________

From report at bugs.python.org  Sat Jul 28 03:45:03 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 01:45:03 +0000
Subject: [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343439903.28.0.855329979378.issue15457@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching updated patch incorporating feedback.

It would be nice to have a good term for "the generator function code object associated with a generator" to distinguish it from the original generator function as you point out.

There are many places in the docs where this distinction is blurred, for example throughout the subsection describing generator methods:

"generator.__next__(): Starts the execution of a generator function or resumes it at the last executed yield expression..."

http://docs.python.org/dev/reference/expressions.html#generator.__next__

By the way, I think it would be a good idea to add "code object" to the glossary as it is not currently listed.  In particular, the entry could link to the section of the docs that discuss code objects in more detail:

http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy
specifically: http://docs.python.org/dev/reference/datamodel.html#index-52

----------
Added file: http://bugs.python.org/file26552/issue-15457-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15457>
_______________________________________

From report at bugs.python.org  Sat Jul 28 04:09:50 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sat, 28 Jul 2012 02:09:50 +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: <1343441390.91.0.618127754588.issue9035@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Sat Jul 28 04:31:22 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 02:31:22 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1343442682.69.0.433118215439.issue1859@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Here is an even simpler failing test case:

>>> from textwrap import wrap
>>> wrap("a\nb", replace_whitespace=False)
['a\nb']

It should return--

['a', 'b']

I will start working on this issue by assembling formal test cases.

----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sat Jul 28 04:36:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 02:36:38 +0000
Subject: [issue15450] Allow dircmp.subdirs to behave well under subclassing
In-Reply-To: <1343260803.75.0.101432828571.issue15450@psf.upfronthosting.co.za>
Message-ID: <1343442998.52.0.543261735338.issue15450@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15450>
_______________________________________

From report at bugs.python.org  Sat Jul 28 06:48:06 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 28 Jul 2012 04:48:06 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343450886.5.0.71283555914.issue15231@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Feel free to change it, I don't mind. I think the intention is clear anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Sat Jul 28 07:56:39 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 05:56:39 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1343454999.2.0.202752102676.issue1859@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

> def wrap_paragraphs(text, width=70, **kwargs):
>     return [line for para in text.splitlines() for line in textwrap.wrap(para, width, **kwargs)]

I just want to point out that, at least for the purposes of this issue, I don't believe the above is equivalent to what we want.  For example--

>>> wrap_paragraphs('a\n\nb', replace_whitespace=False)
['a', 'b']

With replace_whitespace=False, we want to preserve newline information, which would instead mean a return value of--

['a', '', 'b']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sat Jul 28 08:38:19 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Jul 2012 06:38:19 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <3Wkcn63c5QzPPd@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c2618b916081 by Ned Deily in branch 'default':
Issue #15364: Fix test_srcdir for the installed case.
http://hg.python.org/cpython/rev/c2618b916081

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Sat Jul 28 08:51:36 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Jul 2012 06:51:36 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1343458296.58.0.451038789278.issue1859@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

def wrap_paragraphs(text, width=70, **kwargs):
    return [line for para in text.splitlines() for line in textwrap.wrap(para, width, **kwargs) or ['']]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sat Jul 28 08:54:41 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 Jul 2012 06:54:41 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343458481.19.0.981104259648.issue15295@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Awesome addition, Barry!  Bless you for slogging through this.  Here are some thoughts (prepare one grain of salt for each):

* (glossary.rst) finder: should also reference PEP 420.
* (glossary.rst) module: s/contain/containing/
* (glossary.rst) path importer: I like that you pointed out this specific metapath importer, but aren't path importers something else? [2]  Perhaps the metapath importer doesn't need to be in the glossary.  Then again I like the entry, though I'd change ":term:`finder` / :term:`loader`" to "metapath importer".  Maybe just a different term would work, like "sys path subsystem".  Regardless, it is certainly the big dog in the import machinery and deserves special attention. 
* (glossary.rst) sys path finder: having "sys" is a nice touch, making it more distinct and more explicit.

* (importlib.rst) I could have sworn that find_loader() and resolve_name() were public...
* (importlib.rst) module_repr() is nice.
* (importlib.rst) SourceFileLoader.load_module(): What about when the name does not match?

* (import_machinery.rst) import machinery: really nice intrro!
* (import_machinery.rst) import machinery, end of first paragraph: "Note that importlib.import_module() is the recommended method of calling the import machinery."
* (import_machinery.rst) import machinery, third paragraph: though there is the side effects of the module getting added to sys.modules, and of parent modules getting imported (if not bound).
* (import_machinery.rst) package, second paragraph: "generally" implies further explanation which doesn't materialize.  Perhaps s/modules generally do not contain other modules or packages/modules do not naturally contain other modules or packages/ or something like that?
* (import_machinery.rst) I like that you make it clear that even packages are not strictly a FS-based construct.
* (import_machinery.rst) how about a section devoted just to the attributes of modules and packages, perhaps expanding upon or supplanting the related entries in the data model reference page?
* (import_machinery.rst) Namespace packages: while "provided by a separate vendor installed container" does convey the broad possibilities, it's nearly equivalent to "separate sys.path entries" in practice (and in the example).  Regardless, "separate vendor installed container" could be clarified.
* (import_machinery.rst) Searching, paragraph 1: don't forget importlib.import_module()!  :)
* (import_machinery.rst) The module cache: A gotcha snuck in under the old machinery that may or may not be worth noting. [3]
* (import_machinery.rst) nice point about messing around with sys.modules.
* (import_machinery.rst) I like the sound of "import protocol".
* (import_machinery.rst) Meta path loaders, end of paragraph 2: "The finder could also be a classmethod that returns an instance of the class."
* (import_machinery.rst) Meta path loaders: reload() is no longer a builtin function.
* (import_machinery.rst) Meta path loaders: "If the load fails, the loader needs to remove any modules..." is a pretty exceptional case, since the modules is not in charge of its parent or children, nor of import statements executed for it.  Is this a new requirement?
* (import_machinery.rst) Meta path loaders: too bad there isn't something like "__origin__" for the case where __file__ doesn't make semantic sense, but you still want to record where the module came from.
* (import_machinery.rst) I'm surprised __name__ isn't required.
* (import_machinery.rst) __loader__ is finally getting the respect it deserves (after nearly 10 long years)!
* (import_machinery.rst) Meta path loaders: what should __package__ be set to for a top-level module?
* (import_machinery.rst) Meta path loaders: s/it should execute the module's code/the loader should execute the module's code/.
* (import_machinery.rst) Module reprs: perhaps s/``loader.module_repr(module)``/``module.__loader__.module_repr(module)``/
* (import_machinery.rst) Module reprs: how does module.__qualname__ fit in?
* (import_machinery.rst) module.__path__: s/are consulted/is consulted/ ?
* (import_machinery.rst) The Path Importer: as noted above, this seems like a new usage of "path importer", a term which carries other meaning already.  It's an important and distinct thing though, worthy of its own name. 
* (import_machinery.rst) sys path finders, third paragraph: maybe put a reference to the site module?
* (import_machinery.rst) sys path finders, last paragraph: s/it is used to load/that's what the import machinery uses to load/.
* (import_machinery.rst) NullImporter (issue15473)?  I though Brett had a plan for taking it to the gallows...
* (import_machinery.rst) Diagrams?  Brett again.  :)  He put together some nice ones a few years back.
* (import_machinery.rst) 
* (import_machinery.rst) 

* (simple_stmts.rst) a wonderful improvement!
* (simple_stmts.rst) the from list can include submodules which must be imported separately, implying a step 1b
* (simple_stmts.rst) is __all__ "considered public" in any technical way or is it just convention?  The description somewhat implies that "from module import *" is asking for the module's public API.  That's fine with me.  Explicitly describing it as such would make that connection even more concrete.

Whew.  All in all, Barry, nice work on a difficult and tedious project!  This is such an improvement and long overdue.

Other notes:

[1] A package doesn't necessarily have to correspond to a directory, does it?  Meta path importers should be able to generate packages just as well as path importers.  issue1644818 hints at this.

[2] Doesn't "path importer" refer to the callables on sys.path_hooks that decide the path-based finder to use for a module during filesystem-based imports.  In light of "sys path finder", maybe "sys path importer" is more appropriate.  So "sys path finder" refers to the specialized finder used during FS-based imports.

[3] A module may replace itself in sys.modules.  This came up during the importlib integration when several people pointed out that they relied on this previously unspecified side-effect of the old import machinery (and importlib didn't cooperate).  Django was involved, if I recall correctly.  You've alluded to the situation in the footnote on import_machinery.rst.

I'm pretty sure this still isn't specified, nor that it should be.  And yet...  Anyway, this would somewhat imply that all module attributes set by the loader should likewise be set before the module's code is executed (which _is_ already at least vaguely specified).

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sat Jul 28 08:54:53 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Jul 2012 06:54:53 +0000
Subject: [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343458493.46.0.79123635734.issue15457@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Up until today, I had assumed that it was the generator.__next__ method that was associated with the compiled body. But in writing my response, I investigated and discovered

>>> def gf(): yield None

>>> gf().gi_code is gf.__code__
True

Then i realized that the simple call protocal -- a callable is an object with an executable __call__ method -- makes the magic simpler than I thought. Generator functions must have a special __call__ method that simply creates and returns a generator instance with the code object attached (instead of executing the code).

Since code objects are referred to in various places (compile(), exec(), probably def statement doc), I agree that there should be a minimal glossary entry. One can't really understand generator functions and generators without knowing that def statements create both a function object and an attached code object, but that they can operate somewhat separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15457>
_______________________________________

From report at bugs.python.org  Sat Jul 28 08:56:31 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Jul 2012 06:56:31 +0000
Subject: [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343458591.65.0.175401451692.issue15457@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I will try to read your new patch when I am fresher.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15457>
_______________________________________

From report at bugs.python.org  Sat Jul 28 09:11:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 07:11:11 +0000
Subject: [issue15476] Add "code object" to glossary
Message-ID: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to add "code object" to the documentation glossary, as discussed in issue 15457 regarding the documentation around generators.

This can be a minimal entry that links to the details here, for example--

http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy
specifically: http://docs.python.org/dev/reference/datamodel.html#index-52

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166633
nosy: cjerdonek, docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add "code object" to glossary
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15476>
_______________________________________

From report at bugs.python.org  Sat Jul 28 09:26:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 07:26:28 +0000
Subject: [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343460388.87.0.35358990965.issue15457@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I created issue 15476 to add "code object" to the glossary.

> Generator functions must have a special __call__ method that simply creates and returns a generator instance with the code object attached (instead of executing the code).

Just to be sure, is this the same as what you were saying in your previous comment?

"The gf does this# by setting the gi_code attribute of instances to the code object compiled from its body. (Or perhaps it calls the generator class with its code object as parameter. In any case, this is what the special gf.__call__ method does instead of executing its code attribute."

Since you're not sure whether the gi_code attribute is meant to be public, it may be best not to mention it explicitly in the docs.  This is consistent with what I have done in the latest patch.  Thanks in advance for reviewing the update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15457>
_______________________________________

From report at bugs.python.org  Sat Jul 28 09:36:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 07:36:20 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343460980.12.0.400675409116.issue15463@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

> We may also add a function to change these limits at runtime.

This sounds like a good idea.  Is there already an issue for this?  If not, I could create one.

Regardless of whether MAX_STRING_LENGTH is increased, my instinct is that the test should work for long install paths independent of the setting's value.  I wonder if there is a way to adjust the test so that the file name can still be checked in such a scenario (i.e. so that we do not simply add "or '...'" logic to the regular expression).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Sat Jul 28 10:27:02 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Jul 2012 08:27:02 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <5011AC97.7010602@v.loewis.de>
Message-ID: <201207281126.42753.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> issue15456
> efficiently demonstrates that the current style can detect bugs
> which testing with object.__sizeof__ can't.

Hmm, I see this as a counterexample. The bug *was not detected* with the 
current style of testing.

But if you insist, I began to translation tests to more tedious style. I hope 
that issue 15467 patch will be accepted, it is slightly reduce tediousity. 
However, not all of the tests can be written in this style.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Sat Jul 28 10:28:22 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Jul 2012 08:28:22 +0000
Subject: [issue15456] Correct __sizeof__ support for code objects
In-Reply-To: <1343334244.41.0.270789489759.issue15456@psf.upfronthosting.co.za>
Message-ID: <201207281128.04515.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Thank you for fast commiting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15456>
_______________________________________

From report at bugs.python.org  Sat Jul 28 10:50:20 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 28 Jul 2012 08:50:20 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343465420.14.0.53754395191.issue12834@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Thanks, Nick! I'll move the function declaration back to abstract.h.

Waiting for Georg's input. -- It seems to me that #14330 is a blocker
that will only be fixed on Monday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Sat Jul 28 10:57:04 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Jul 2012 08:57:04 +0000
Subject: [issue14973] restore python2 unicode literals in "ur" strings
In-Reply-To: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za>
Message-ID: <1343465824.38.0.467999981989.issue14973@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy:  -storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14973>
_______________________________________

From report at bugs.python.org  Sat Jul 28 11:15:26 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 28 Jul 2012 09:15:26 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343466926.71.0.297722439818.issue12834@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

With the beta delayed as you say, I'm okay with this going in now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Sat Jul 28 11:19:06 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 28 Jul 2012 09:19:06 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343467146.74.0.746998382499.issue1692335@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, finally I think this can go in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Sat Jul 28 11:19:30 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 28 Jul 2012 09:19:30 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343467170.34.0.217488170754.issue14578@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, demoting.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Sat Jul 28 12:03:57 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 Jul 2012 10:03:57 +0000
Subject: [issue15477] test_cmath failures on OS X 10.8
Message-ID: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

======================================================================
FAIL: testAtanSign (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 526, in testAtanSign
    self.assertComplexIdentical(cmath.atan(z), z)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 96, in assertComplexIdentical
    self.assertFloatIdentical(x.imag, y.imag)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 86, in assertFloatIdentical
    self.fail(msg.format(x, y))
AssertionError: floats -0.0 and 0.0 are not identical: zeros have different signs

======================================================================
FAIL: testAtanhSign (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 533, in testAtanhSign
    self.assertComplexIdentical(cmath.atanh(z), z)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 95, in assertComplexIdentical
    self.assertFloatIdentical(x.real, y.real)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 86, in assertFloatIdentical
    self.fail(msg.format(x, y))
AssertionError: floats 0.0 and -0.0 are not identical: zeros have different signs

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 382, in test_specific_values
    msg=error_message)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 128, in rAssertAlmostEqual
    'got {!r}'.format(a, b))
AssertionError: atan1000: atan(complex(-0.0, 0.0))
Expected: complex(-0.0, 0.0)
Received: complex(-0.0, -0.0)
Received value insufficiently close to expected value.

----------------------------------------------------------------------

Failures seen across various compilers and deployment targets and running the tests with the same binaries on earlier OS X versions do not fail.

FWIW, the Apple-supplied Python 2.7.2 in 10.8 (that's the most recent version supplied) also has a test_cmath failure:

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_cmath.py", line 352, in test_specific_values
    msg=error_message)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_cmath.py", line 94, in rAssertAlmostEqual
    'got {!r}'.format(a, b))
AssertionError: atan0000: atan(complex(0.0, 0.0))
Expected: complex(0.0, 0.0)
Received: complex(0.0, -0.0)
Received value insufficiently close to expected value.

----------------------------------------------------------------------

Is there any reason to not consider this a platform bug?  If it is, what should the bug report be?

----------
messages: 166642
nosy: mark.dickinson, ned.deily
priority: normal
severity: normal
status: open
title: test_cmath failures on OS X 10.8
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15477>
_______________________________________

From report at bugs.python.org  Sat Jul 28 12:16:03 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 10:16:03 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343470563.21.0.952985743494.issue15466@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I suggest the opposite: never emit TYPE_INT64 at all. For compatibility, we can still support reading it in 3.3 (and drop that support in 3.4).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 12:28:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Jul 2012 10:28:09 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <3WkjtJ4F1XzPRy@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8fbbc7c8748e by Stefan Krah in branch 'default':
Issue #12834: Fix PyBuffer_ToContiguous() for non-contiguous arrays.
http://hg.python.org/cpython/rev/8fbbc7c8748e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Sat Jul 28 12:38:30 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 28 Jul 2012 10:38:30 +0000
Subject: [issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous
	arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343471910.81.0.949945939801.issue12834@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

All right, 3.3 is fixed. Re-targeting for 3.2 and 2.7.

----------
priority: release blocker -> normal
versions: +Python 3.1 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Sat Jul 28 12:47:27 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 10:47:27 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343472447.75.0.136282257945.issue15466@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a patch to stop generating TYPE_INT64. Ok for 3.30b2?

----------
keywords: +patch
priority: high -> release blocker
Added file: http://bugs.python.org/file26553/marshal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 13:09:46 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 28 Jul 2012 11:09:46 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343473786.32.0.436270101912.issue15466@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a patch that write TYPE_INT64 on most platforms (where either long or long long is 64bit).
It is admittedly much larger than Martin's...

----------
Added file: http://bugs.python.org/file26554/marshal_use_int64.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 13:49:11 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Jul 2012 11:49:11 +0000
Subject: [issue15477] test_cmath failures on OS X 10.8
In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za>
Message-ID: <1343476151.8.0.61090102746.issue15477@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Judging by previous reports of this type, it's probably either a bug in the platform math library or a compiler optimization bug (or possibly a combination of the two: one previous OS X bug involved calls to sin / cos being 'optimized' to a badly implemented single call to cexp).  I assume the failure still happens in debug mode?  If so, a math library bug seems more likely.

Are there any math module failures?

It's not immediately obvious what the bug is, since the cmath module functions are not just simple wrappers around library functions.  In this case it looks like either atan2 or log1p is doing the wrong thing with signs of zeros.

What do math.log1p(0.0) and math.log1p(-0.0) give?  (Answers *should* be 0.0 and -0.0 respectively.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15477>
_______________________________________

From report at bugs.python.org  Sat Jul 28 13:51:57 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Jul 2012 11:51:57 +0000
Subject: [issue15477] test_cmath failures on OS X 10.8
In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za>
Message-ID: <1343476317.78.0.360751308551.issue15477@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Also:  what's HAVE_LOG1P for this build?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15477>
_______________________________________

From report at bugs.python.org  Sat Jul 28 14:35:20 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 28 Jul 2012 12:35:20 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343460980.12.0.400675409116.issue15463@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbg=X_rYDTVVs4UpJE3pd_=nbcZ1ASEZxJ7Q5_UmHfi7w@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

>> We may also add a function to change these limits at runtime.
>
> This sounds like a good idea.  Is there already an issue for this?  If not, I could create one.

There is no such issue. You can create it: add me to the nosy list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Sat Jul 28 14:39:05 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 28 Jul 2012 12:39:05 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343460980.12.0.400675409116.issue15463@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY06Vk1_zkfNkdftW9WLrRupy9VB2SEWTc_w41h0kLu1A@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Regardless of whether MAX_STRING_LENGTH is increased, my instinct is that the test should work for long install paths independent of the setting's value.  I wonder if there is a way to adjust the test so that the file name can still be checked in such a scenario (i.e. so that we do not simply add "or '...'" logic to the regular expression).

The purpose of the test is to check that the traceback is correct:
it's important to check that the filename ends with "threading.py". If
you don't know in which file the bug occured, the traceback is
useless.

Changing the MAX_STRING_LENGTH should be enough to fix this issue
before Python 3.3 final.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Sat Jul 28 14:49:06 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 28 Jul 2012 12:49:06 +0000
Subject: [issue15478] UnicodeDecodeError on OSError
Message-ID: <1343479745.83.0.410557070565.issue15478@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

On Windows, if an OS error fails, the filename type is bytes and the filename cannot be decoded: Python raises an UnicodeDecodeError instead of an OSError. The problem is that Python decodes the filename to fill OSError.filename field. See the issue #15441 for the initial report.

There are different options to solve this issue:
 - always keep the filename parameter unchanged, so OSError.filename can be a str or a bytes string, depending on the input parameter
 - try to decode the filename from the filesystem encoding, or keep the filename unchanged: OSError.filename is only a bytes string if the filename cannot be decoded
 - don't fill OSError.filename (= None) if the filename cannot be decoded
 - use "surrogateescape", "replace" or "backslashreplace" error handler to decode the filename

This issue is specific to Windows: on other plaforms, the filename is decoded using the "surrogateescape" error handler and so decoding the filename cannot fail.

I don't know if OSError.filename is only used to display more information to the user, or if it is used to do another operation on the file (ex: os.chmod).

I like solutions keeping the filename unchanged, because it does not loose information, and the user can decide how to handle the undecodable filename.

I don't like the option trying to decode the filename or keeping it unchanged it decoding fails, because applications will work in most cases, but "crash" when someone comes with an unusual code page, a special USB key, or a filename with a non-ASCII character.

So the best option is maybe to always keep the bytes filename unchanged.

Such change cannot be done anymore in Python 3.3, it's too late to test it correctly.

----------
components: Unicode, Windows
messages: 166652
nosy: ezio.melotti, flox, haypo, ishimoto, loewis, tim.golden
priority: normal
severity: normal
status: open
title: UnicodeDecodeError on OSError
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15478>
_______________________________________

From report at bugs.python.org  Sat Jul 28 14:51:18 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 28 Jul 2012 12:51:18 +0000
Subject: [issue15441] test_posixpath fails on Japanese edition of Windows
In-Reply-To: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>
Message-ID: <1343479878.38.0.69032413383.issue15441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I still would prefer if only one issue at a time gets fixed, in particular if the two issues require independent changes.

Sorry, you are right: I created the issue #15478 for the general fix, and we will use this issue to fix test_genericpath.

This issue can be fixed in Python 3.3, whereas #15478 will have to wait for Python 3.4 beause it's an major change and may break a lot of code. It's better to wait the next release to test such change correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15441>
_______________________________________

From report at bugs.python.org  Sat Jul 28 14:52:06 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 28 Jul 2012 12:52:06 +0000
Subject: [issue15478] UnicodeDecodeError on OSError on Windows with
	undecodable (bytes) filename
In-Reply-To: <1343479745.83.0.410557070565.issue15478@psf.upfronthosting.co.za>
Message-ID: <1343479926.99.0.762047672398.issue15478@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: UnicodeDecodeError on OSError -> UnicodeDecodeError on OSError on Windows with undecodable (bytes) filename

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15478>
_______________________________________

From report at bugs.python.org  Sat Jul 28 14:53:43 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 28 Jul 2012 12:53:43 +0000
Subject: [issue15478] UnicodeDecodeError on OSError on Windows with
	undecodable (bytes) filename
In-Reply-To: <1343479745.83.0.410557070565.issue15478@psf.upfronthosting.co.za>
Message-ID: <1343480023.47.0.843521995235.issue15478@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

In Python 2, it looks like open(arg) does pass its filename argument unchanged to OSError constructor (so it can be bytes or unicode). OSError.filename is always bytes for os.chdir() on UNIX, but OSError.filename can be bytes or unicode for os.chdir() on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15478>
_______________________________________

From report at bugs.python.org  Sat Jul 28 15:22:23 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Jul 2012 13:22:23 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343481743.11.0.453358910161.issue15466@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

I can see yet another problem under the hood. Marshalling will output different data on platforms with a different representation of negative numbers. Worse still, these data are non-portable, written on one platform will be read incorrectly on the other. Mark, time for your inquisitor sword.

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 15:25:02 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Jul 2012 13:25:02 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343481902.12.0.0563561982596.issue15466@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 15:38:42 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 28 Jul 2012 13:38:42 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343482722.73.0.775364833107.issue15466@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Are there really platforms which don't use two's complement?
(If there are, I'm not sure to want to share binary data with them. Same for EBCDIC)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 15:39:38 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 13:39:38 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343482778.85.0.506973721921.issue15466@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Serhiy: this is safe to ignore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 15:44:16 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 28 Jul 2012 13:44:16 +0000
Subject: [issue14330] don't use host python,
	use host search paths for host compiler
In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za>
Message-ID: <1343483056.75.0.00782854648085.issue14330@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Everything is still building happily for me on Fedora, so I suggest looking at the Debian/Ubuntu multiarch support (which is the origin of the dpkg-architecture call).

Background in http://bugs.python.org/issue11715

----------
nosy: +barry, ncoghlan
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14330>
_______________________________________

From report at bugs.python.org  Sat Jul 28 15:47:53 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Jul 2012 13:47:53 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343483273.62.0.109038509696.issue15467@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

I asked in Python-Dev, and if I understood the answers correctly, we can make changes to 2.7 and 3.2 without fear. For 3.3 risk is higher, so we need to be more attentive. However patch for 3.3 contains not only the potential improvements for other tests, but also bug fixes (I think these bugs should cause tests failure on the platforms where sizeof(Py_ssize_t) != sizeof(long) or sizeof(Py_ssize_t) != sizeof(void*)).

Of cause, if Georg Brandl not vetoes this.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Sat Jul 28 17:22:47 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 Jul 2012 15:22:47 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1343488967.84.0.344327843385.issue2771@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

test

----------
keywords: +easy -patch
nosy:  -python-dev
priority:  -> low
resolution: fixed -> later

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sat Jul 28 18:13:52 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 16:13:52 +0000
Subject: [issue15479] Allow MAX_STRING_LENGTH limits to be changed at runtime
Message-ID: <1343492032.88.0.552798503045.issue15479@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to allow the MAX_STRING_LENGTH limit defined in Python/traceback.c to be changed at runtime, as discussed in issue 15463, as well as the two related limits:

#define MAX_STRING_LENGTH 100
#define MAX_FRAME_DEPTH 100
#define MAX_NTHREADS 100

http://hg.python.org/cpython/file/ddf15cd9be4a/Python/traceback.c#l16

----------
messages: 166661
nosy: cjerdonek, haypo
priority: normal
severity: normal
status: open
title: Allow MAX_STRING_LENGTH limits to be changed at runtime
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15479>
_______________________________________

From report at bugs.python.org  Sat Jul 28 18:15:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 16:15:28 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343492128.87.0.461862874225.issue15463@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> There is no such issue. You can create it: add me to the nosy list.

I created issue 15479 to allow the limits to be changed at runtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Sat Jul 28 18:28:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 16:28:41 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343492921.81.0.453854184571.issue15463@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> The purpose of the test is to check that the traceback is correct:
> it's important to check that the filename ends with "threading.py".

I agree with you.  That is why I argued against including "or '...'" logic in the current test.

> Changing the MAX_STRING_LENGTH should be enough to fix this issue
> before Python 3.3 final.

That is fine.  However, I should also point out that the current test is not sufficient to test on all systems/installs that this issue has been fixed.  It would be good to add such a test (i.e. one that can, for example, simulate a long install path).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Sat Jul 28 18:35:19 2012
From: report at bugs.python.org (Meador Inge)
Date: Sat, 28 Jul 2012 16:35:19 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <201207281126.42753.storchaka@gmail.com>
Message-ID: <CAK1Qooru=90HorCcJO+bUpvfjcBy5FyN_8BvsjLM8-3Gkqyvqw@mail.gmail.com>


Meador Inge added the comment:

On Sat, Jul 28, 2012 at 3:27 AM, Serhiy Storchaka
<report at bugs.python.org> wrote:

> Serhiy Storchaka <storchaka at gmail.com> added the comment:
>
>> issue15456
>> efficiently demonstrates that the current style can detect bugs
>> which testing with object.__sizeof__ can't.
>
> Hmm, I see this as a counterexample. The bug *was not detected* with the
> current style of testing.

I disagree.  It wasn't *directly* detected -- the test broke because of the new
structure field that was added and not because of the new dynamic memory
allocation that was added.  Even so, the fact that the test broke *at all*
should have thrown a warning flag up in the developer's mind to reevaluate
how the size is calculated.  If the test were written using your
object.__sizeof__
method, then the test would not have broken *at all* and therefore it might not
have even crossed the developers mind to verify whether the sizeof calculation
is correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:11:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Jul 2012 17:11:08 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <3WktqG67fnzPTC@mail.python.org>


Roundup Robot added the comment:

New changeset 68e2690a471d by Richard Oudkerk in branch 'default':
Issue #1692335: Move initial args assignment to BaseException.__new__
http://hg.python.org/cpython/rev/68e2690a471d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:12:33 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 28 Jul 2012 17:12:33 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343495553.19.0.299429370205.issue15425@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

IMO we should not ship 3.3 without a fix for this.

----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:15:33 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 Jul 2012 17:15:33 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343495733.36.0.134538858301.issue15425@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:21:36 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 28 Jul 2012 17:21:36 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343496096.3.0.246363593303.issue15425@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:25:56 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 Jul 2012 17:25:56 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343496356.24.0.400420179372.issue15466@psf.upfronthosting.co.za>


Eric Snow added the comment:

> I suggest the opposite: never emit TYPE_INT64 at all. For
> compatibility, we can still support reading it in 3.3 (and drop
> that support in 3.4).

+1  essentially we maintain the status quo

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:44:23 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Jul 2012 17:44:23 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <3WkvYf3T6xzPWK@mail.python.org>


Roundup Robot added the comment:

New changeset 461e84fc8c60 by Martin v. L?wis in branch 'default':
Issue #15466: Stop using TYPE_INT64 in marshal,
http://hg.python.org/cpython/rev/461e84fc8c60

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:45:08 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 Jul 2012 17:45:08 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343497508.63.0.234276440988.issue15425@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:45:24 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 Jul 2012 17:45:24 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343497524.26.0.480083328189.issue15466@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:46:28 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 28 Jul 2012 17:46:28 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343497588.53.0.979518708167.issue15466@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Removing TYPE_INT64 was indeed the most reasonable choice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:47:54 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 17:47:54 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343497674.07.0.185651461627.issue15466@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:49:02 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 17:49:02 +0000
Subject: [issue15480] Drop TYPE_INT64 from marshal in Python 3.4
Message-ID: <1343497742.77.0.0142368260807.issue15480@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

As a follow-up of issue15466, TYPE_INT64 can be deleted in Python 3.4.

----------
messages: 166670
nosy: loewis
priority: deferred blocker
severity: normal
status: open
title: Drop TYPE_INT64 from marshal in Python 3.4
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15480>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:49:55 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 17:49:55 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343497795.53.0.578484809136.issue15466@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I put the complete removal of TYPE_INT64 into issue15480

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 19:54:42 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 Jul 2012 17:54:42 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343498082.02.0.959707738524.issue15466@psf.upfronthosting.co.za>


Eric Snow added the comment:

Looks like the Misc/NEWS entry got truncated.  Also, does this change need a new PYC magic number (now in Lib/importlib/_bootstrap.py)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 20:28:07 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 18:28:07 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343500087.62.0.418729139962.issue15466@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

For the truncation, see ec7267fa8b84. I don't see why a new pyc magic number should be necessary. Python continues to support the existing files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 20:47:34 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Jul 2012 18:47:34 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <3WkwyX5DFnzNP0@mail.python.org>


Roundup Robot added the comment:

New changeset fe29a657bde9 by Martin v. L?wis in branch 'default':
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows.
http://hg.python.org/cpython/rev/fe29a657bde9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Sat Jul 28 20:48:26 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 18:48:26 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343501306.95.0.894506726129.issue15431@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Thanks for the patch, committed with slight modifications.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Sat Jul 28 20:53:44 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 28 Jul 2012 18:53:44 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343501624.16.0.359264467508.issue15431@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Comments about PyImport_FrozenModules linkage have not been addressed.  Now the build is failing on all Unix machines...

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Sat Jul 28 21:33:10 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 Jul 2012 19:33:10 +0000
Subject: [issue15481] Add exec_module() as part of the import loader API
Message-ID: <1343503990.21.0.184521715499.issue15481@psf.upfronthosting.co.za>


New submission from Eric Snow:

issue15110 introduced a new private function, _exec_module(), to the default loaders in Lib/importlib/_bootstrap.py.  Doing so helped hide importlib frames from the traceback.  A related fix is likely required for issue15425.

Should some general form of exec_module() be an official part of the loader API (in importlib.abc.Loader).  If a loader subclasses one of the default ones, it already gets the behavior for free.  Otherwise it does not benefit from the cleaner traceback (unless the author is savvy to the _exec_module() implementation detail).

Though the use of Loader._exec_module() to strip tracebacks is an implementation detail of CPython, having a public Loader.exec_module() would allow other implementations to perform a similar action.  And if we found a way to move remove_importlib_frames to importlib then all the better.  (Looking into traceback API improvements is on my to-do list.)

As a bonus, Loader.exec_module() would also allow loaders that wrap other loaders (yes, esoteric) to manage the execution portion of loading.  I haven't given this part a lot of thought, so it may not be much of a bonus (or could even be a negative).

>From the perspective of caution, the import machinery is already pretty complicated.  It may not be advisable to add to that even in this little way.

----------
assignee: eric.snow
components: Interpreter Core
messages: 166677
nosy: amaury.forgeotdarc, brett.cannon, eric.snow, pitrou
priority: normal
severity: normal
status: open
title: Add exec_module() as part of the import loader API
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15481>
_______________________________________

From report at bugs.python.org  Sat Jul 28 21:34:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Jul 2012 19:34:09 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <3Wky0J09y0zPS0@mail.python.org>


Roundup Robot added the comment:

New changeset bd58c421057c by Martin v. L?wis in branch 'default':
Issue #14578: Support modules registered in the Windows registry again.
http://hg.python.org/cpython/rev/bd58c421057c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Sat Jul 28 21:36:16 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 19:36:16 +0000
Subject: [issue14578] importlib doesn't check Windows registry for paths
In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>
Message-ID: <1343504176.27.0.675747339282.issue14578@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Amaury's patch nearly worked; committed with slight modifications.

----------
dependencies:  -Cannot build importlib.h on Windows
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14578>
_______________________________________

From report at bugs.python.org  Sat Jul 28 21:46:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 19:46:57 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343504817.08.0.0122463331994.issue15463@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Here is a patch to the tests that allows the tests to pass when the install path is long while still checking that file names show up correctly in the traceback.

One advantage of this patch's approach is that it provides a way to test the rendering of long paths on all systems/installs.  Simply create a test case by setting the scriptname to, for example--

scriptname = 'test_long_file_path_' + 200 * 'x'

This patch is just an illustration for discussion purposes and is not meant as a final patch.

Also, this patch does not fix the issue of the file names of long paths not getting rendered (which can be addressed by setting the limit to 500 as we discussed).  However, as I have noted this patch provides a way to test such a fix.

----------
keywords: +patch
Added file: http://bugs.python.org/file26555/issue-15463-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Sat Jul 28 21:51:46 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 Jul 2012 19:51:46 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343505106.36.0.845953118677.issue15425@psf.upfronthosting.co.za>


Eric Snow added the comment:

Perhaps this should be split into two issues, as the fix will likely be different for the two.

For the first part (SyntaxError), my initial impression is that this will require a similar fix, or extension of it, to the one in issue15110.  That fix was limited just to the execution of the module, while this problem happens earlier (during the compilation step in SourceLoader.get_code()).  

For the second part, it is all about failures during the execution of an import that was initiated during the import of another module.  That traceback is definitely less than helpful.  A better traceback would is doable.

For both (and maybe for issue15110) we should explore using exception chaining to separate the import portion from the rest.  I see about working on a patch later this evening.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sat Jul 28 21:53:04 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 Jul 2012 19:53:04 +0000
Subject: [issue15110] strange Tracebacks with importlib
In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>
Message-ID: <1343505183.99.0.508587147358.issue15110@psf.upfronthosting.co.za>


Eric Snow added the comment:

Issue15425 is related.  I'm looking into an exception chaining approach that could be applied for this issue too.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15110>
_______________________________________

From report at bugs.python.org  Sat Jul 28 21:53:49 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Jul 2012 19:53:49 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343505229.91.0.550052475032.issue15431@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

To be clear, the build fails when importlib needs to be frozen again:

$ touch Lib/importlib/_bootstrap.py 
$ make
make Modules/_freeze_importlib
make[1] : on entre dans le r?pertoire ? /home/antoine/cpython/default ?
gcc -pthread -c -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o Modules/_freeze_importlib.o Modules/_freeze_importlib.c
gcc -pthread   -o Modules/_freeze_importlib Modules/_freeze_importlib.o Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/capsule.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/random.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o   Python/thread.o Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o  Modules/_threadmodule.o  Modules/signalmodule.o  Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/_functoolsmodule.o  Modules/operator.o  Modules/_collectionsmodule.o  Modules/itertoolsmodule.o  Modules/_localemodule.o  Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/zipimport.o  Modules/faulthandler.o  Modules/symtablemodule.o  Modules/xxsubtype.o -lpthread -ldl  -lutil   -lm  
Modules/_freeze_importlib.o: In function `main':
/home/antoine/cpython/default/Modules/_freeze_importlib.c:37: undefined reference to `PyImport_FrozenModules'
Python/import.o: In function `find_frozen':
/home/antoine/cpython/default/Python/import.c:978: undefined reference to `PyImport_FrozenModules'
collect2: ld a retourn? 1 code d'?tat d'ex?cution
make[1]: *** [Modules/_freeze_importlib] Erreur 1
make[1] : on quitte le r?pertoire ? /home/antoine/cpython/default ?
make: *** [Python/importlib.h] Erreur 2

----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Sat Jul 28 21:55:52 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Jul 2012 19:55:52 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <3WkyTM0JswzN3P@mail.python.org>


Roundup Robot added the comment:

New changeset 7967cb63e50e by Martin v. L?wis in branch 'default':
Issue #15431: Declare PyImport_FrozenModules conditionally on Unix only.
http://hg.python.org/cpython/rev/7967cb63e50e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Sat Jul 28 21:57:34 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 Jul 2012 19:57:34 +0000
Subject: [issue15466] Python/importlib.h is different on 32bit and 64bit
In-Reply-To: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>
Message-ID: <1343505454.35.0.936794830961.issue15466@psf.upfronthosting.co.za>


Eric Snow added the comment:

> I don't see why a new pyc magic number should be necessary. Python
> continues to support the existing files.

Good point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15466>
_______________________________________

From report at bugs.python.org  Sat Jul 28 22:00:28 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Jul 2012 20:00:28 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <3WkyZg5jKnzPS9@mail.python.org>


Roundup Robot added the comment:

New changeset deb421baf671 by Martin v. L?wis in branch 'default':
Issue #15431: Drop _freeze_importlib from all build configurations,
http://hg.python.org/cpython/rev/deb421baf671

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Sat Jul 28 22:01:01 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 28 Jul 2012 20:01:01 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343505661.95.0.551155099456.issue1692335@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
assignee: lukasz.langa -> sbt
stage: patch review -> commit review
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Sat Jul 28 22:05:55 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 20:05:55 +0000
Subject: [issue15431] Cannot build importlib.h on Windows
In-Reply-To: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>
Message-ID: <1343505955.23.0.472466698614.issue15431@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

The last commits should address Amaury's concerns. _freeze_importlib must now be built manually, followed by a build of pythoncore.

Interestingly, the builds failed only once. When rebuilding, the builds succeeded as no attempt to build freeze_importlib was made. After the last change to freeze_importlib, they again built it, and that seems to work now.

Tentatively closing the issue again.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15431>
_______________________________________

From report at bugs.python.org  Sat Jul 28 22:20:21 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 20:20:21 +0000
Subject: [issue15355] generator.__next__() docs should mention exception if
	already executing
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343506821.82.0.75517765529.issue15355@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Terry, if when reviewing my patch for issue 15457, you also have time to review this much simpler patch (also in the documentation on generators), I would appreciate it.  If not, that's okay.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15355>
_______________________________________

From report at bugs.python.org  Sat Jul 28 22:27:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 20:27:47 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343507267.19.0.859902346623.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Is there any way I could assist in closing this, perhaps by preparing patches for the Distutils and Distutils2 components?  Can someone point me to where the changes to those components should be made (e.g. where they are located)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Sat Jul 28 23:01:43 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 Jul 2012 21:01:43 +0000
Subject: [issue15477] test_cmath failures on OS X 10.8
In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za>
Message-ID: <1343509303.75.0.694686827399.issue15477@psf.upfronthosting.co.za>


Ned Deily added the comment:

> I assume the failure still happens in debug mode?

Yes

> Are there any math module failures?

No

> What do math.log1p(0.0) and math.log1p(-0.0) give?  (Answers *should* be 0.0 and -0.0 respectively.)

>>> math.log1p(0.0)
0.0
>>> math.log1p(-0.0)
0.0
>>> sysconfig.get_config_var('HAVE_LOG1P')
1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15477>
_______________________________________

From report at bugs.python.org  Sat Jul 28 23:06:55 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 21:06:55 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343509615.11.0.849503494244.issue15231@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

distutils are in Lib/distutils. Distutils2 has been removed from Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Sat Jul 28 23:08:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Jul 2012 21:08:20 +0000
Subject: [issue15438] document that math.pow is inappropriate for integers
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1343509700.91.0.352943969869.issue15438@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Changing the incredible issue title :-)

----------
title: Incredible issue in math.pow -> document that math.pow is inappropriate for integers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Sat Jul 28 23:11:40 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Jul 2012 21:11:40 +0000
Subject: [issue15479] Allow MAX_STRING_LENGTH limits to be changed at runtime
In-Reply-To: <1343492032.88.0.552798503045.issue15479@psf.upfronthosting.co.za>
Message-ID: <1343509900.36.0.262557279893.issue15479@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Sounds totally overkill to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15479>
_______________________________________

From report at bugs.python.org  Sat Jul 28 23:37:09 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 21:37:09 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343511429.44.0.214671533701.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks, Martin.  Should Distutils2 be removed from the "Components" list of the tracker form, then?  Or was ?ric referencing a third-party location?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Sat Jul 28 23:40:17 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 21:40:17 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343511617.18.0.585168528932.issue15231@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

> Should Distutils2 be removed from the "Components" list of the tracker form, then? 

No. Please stick to one issue at a time, and distutils2 may come back (google for details).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Sat Jul 28 23:59:59 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 21:59:59 +0000
Subject: [issue15479] Allow MAX_STRING_LENGTH limits to be changed at runtime
In-Reply-To: <1343492032.88.0.552798503045.issue15479@psf.upfronthosting.co.za>
Message-ID: <1343512799.42.0.958459698801.issue15479@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I don't have a problem with closing this as rejected if Victor agrees.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15479>
_______________________________________

From report at bugs.python.org  Sun Jul 29 00:17:23 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Jul 2012 22:17:23 +0000
Subject: [issue15477] test_cmath failures on OS X 10.8
In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za>
Message-ID: <1343513843.73.0.554609064696.issue15477@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

>>> math.log1p(0.0)
0.0
>>> math.log1p(-0.0)
0.0

Ah, that would do it, then.  It looks as though the system's log1p function is buggy, in the sense that it doesn't follow C99 Annex F (F.9.3.9).  It also doesn't agree with what 'man log1p' says on my OS X 10.6 Macbook:  under 'SPECIAL VALUES', it says:  'log1p(+-0) returns +-0.'

I'm puzzled about one thing, though:  there's a test for this problem in the configure script, and LOG1P_DROPS_ZERO_SIGN should be defined in this case---in that case, the two testAtanSign and testAtanhSign tests are skipped.  So it looks as though LOG1P_DROPS_ZERO_SIGN isn't being defined on this machine;  I'm not sure why---there may be a compiler optimization kicking in in the configure test.  (Is this clang or gcc, BTW?)

So definitely worth a bug report, I'd say, though perhaps it's too much to hope for a fix within the lifetime of 10.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15477>
_______________________________________

From report at bugs.python.org  Sun Jul 29 01:05:14 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 23:05:14 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343516714.3.0.780096493871.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> No. Please stick to one issue at a time, and distutils2 may come back (google for details).

I was asking only to determine whether to create a new issue -- not to have that issue addressed here.

> It seems to me there are missing words in the text, and it needs porting to the packaging docs.

Okay, I misunderstood and thought there was more to do.  Since Martin said packaging has been removed, all that is left is to add ?ric's requested modifications to 3.3 (and make the collected change to 2.7 and 3.2).

Patch attached.  The commit message can be something like:

Issue #15231: minor adjustment to prior fix committed in f315cfa22630 regarding, "update PyPI upload doc to say --no-raw passed to rst2html.py."

I included a Misc/NEWS entry since that was left out of the previous commit.

Also, incidentally, there was a typo in the issue number of the commit message for the previous commit, which explains why Roundup did not post here.

----------
Added file: http://bugs.python.org/file26556/issue-15231-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Sun Jul 29 01:18:29 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 Jul 2012 23:18:29 +0000
Subject: [issue15477] test_cmath failures on OS X 10.8
In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za>
Message-ID: <1343517509.94.0.791628173336.issue15477@psf.upfronthosting.co.za>


Ned Deily added the comment:

>>It also doesn't agree with what 'man log1p' says on my OS X 10.6
>>Macbook:  under 'SPECIAL VALUES', it says:  'log1p(+-0) returns +-0.'

That manpage is unchanged for 10.8.

>>I'm puzzled about one thing, though:  there's a test for this problem
>>in the configure script, and LOG1P_DROPS_ZERO_SIGN should be defined in
>>this case---in that case, the two testAtanSign and testAtanhSign tests
>>are skipped.  So it looks as though LOG1P_DROPS_ZERO_SIGN isn't being
>>defined on this machine;  I'm not sure why---there may be a compiler
>>optimization kicking in in the configure test.

Ah, this rings a bell and points out yet another issue:

1. The configure test is working properly: when run on 10.8, LOG1P_DROPS_ZERO_SIGN is set to 1.  However, something I just ran into recently, the unittest skip idiom using sysconfig.get_config_vars results - as is being used here in test_cmath - doesn't seem to work properly.  I see it is used in test_math and test_subprocess as well.  I'll look into that.

2. These types of run-time tests based on configure-time tests are problematic for binary installations of Python, like the OS X installers.  For example, the OS X installers are built on earlier versions of OS X where a configuration test (like this one) may have one result but not necessarily the same result on all supported target configurations where the binary Pythons may be installed.  And, in general, multiple-architecture builds, in particular, OS X universal builds may have different configuration values per architecture embedded in one executable (i386 vs x86_64 or i386 vs ppc or i386 vs x86_64 vs ppc) that are not reflected in the single architecture ./configure results.  I guess it's time to open an issue on that can of worms.

>>(Is this clang or gcc, BTW?)

It's clang which is now the only supported option with Xcode 4.4 on either 10.7 or 10.8.  More importantly, 10.8 is the first OS X release which itself was built with clang; 10.7 was built with the transitional llvm-gcc compiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15477>
_______________________________________

From report at bugs.python.org  Sun Jul 29 01:58:39 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 23:58:39 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343519919.65.0.69619522721.issue15231@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I won't be able to work on this for the next few months. This took too much time already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Sun Jul 29 01:58:54 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 23:58:54 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343519934.76.0.727949696267.issue15231@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy:  -loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Sun Jul 29 03:41:25 2012
From: report at bugs.python.org (Eric Snow)
Date: Sun, 29 Jul 2012 01:41:25 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343526085.53.0.654461115973.issue15425@psf.upfronthosting.co.za>


Eric Snow added the comment:

Here's a trivial patch that demonstrates what I mean.  Yet, in light of exception chaining, I wonder if we should consider actually making ImportError supercede the inner exception.  I'll still try coming up with something similar, but propagates the inside exception.

----------
keywords: +patch
Added file: http://bugs.python.org/file26557/ImportError_is_king.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 04:24:13 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sun, 29 Jul 2012 02:24: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: <1343528653.73.0.528672468226.issue9035@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

Patch to expose GetVolumePathName() and implementation of ismount().
Tested on Windows7/XP.

----------
keywords: +patch
Added file: http://bugs.python.org/file26558/issue9035.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Sun Jul 29 04:26:40 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 29 Jul 2012 02:26:40 +0000
Subject: [issue15355] generator.__next__() docs should mention exception if
	already executing
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343528800.38.0.609944617048.issue15355@psf.upfronthosting.co.za>


Meador Inge added the comment:

Hmmm, in your original description you say that the 'generator.__next__' documentation should be changed, but in the patch the note applies to all generator methods.  From looking at the code it seems that the patch is correct and that '__next__', 'send', 'throw', and 'close' can all raise the "already executing" exception via 'gen_send_ex'.  Documenting this behavior seems reasonable, but you should probably mention what exception gets raises.

BTW, you don't need to make the Misc/NEWS changes a part of your patches.  A core dev will write that for you and since Misc/NEWS is changed so much it might conflict and make patches harder to apply across similar branches (say 3.2 and 3.3).

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15355>
_______________________________________

From report at bugs.python.org  Sun Jul 29 04:52:56 2012
From: report at bugs.python.org (Catherine Devlin)
Date: Sun, 29 Jul 2012 02:52:56 +0000
Subject: [issue6471] errno and strerror attributes incorrectly set on socket
	errors wrapped by urllib
In-Reply-To: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za>
Message-ID: <1343530376.45.0.947264484604.issue6471@psf.upfronthosting.co.za>


Catherine Devlin added the comment:

It's very hard to tell what ought to be done here, since Lib/urllib/request.py throws URLErrors with a great variety of order and number of arguments, and it's not clear how URLError (in Lib/urllib/error.py) intends to handle them.

However, in this case, AbstractHTTPHandler.do_open is instantiating URLError with another exception instance, and that exception contains .errno and .strerror.  URLError puts the entire error instance into ``reason``, where the information is hidden away as .reason.strno and .reason.strerror. 

In the name of keeping this information available rather than hiding it, I'm attaching a patch that adds to URLError.__init__:

        if hasattr(reason, "errno"):
            self.errno = reason.errno
        if hasattr(reason, "strerror"):
            self.strerror = reason.strerror

Again, I'm not sure this is the most logical approach because I can't find a consistent pattern in the ways URLError is instantiated.

----------
keywords: +patch
nosy: +catherine
Added file: http://bugs.python.org/file26559/keeperrdata.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6471>
_______________________________________

From report at bugs.python.org  Sun Jul 29 04:55:10 2012
From: report at bugs.python.org (Ronan Lamy)
Date: Sun, 29 Jul 2012 02:55:10 +0000
Subject: [issue15482] __import__() change between 3.2 and 3.3
Message-ID: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>


New submission from Ronan Lamy:

I noticed a change in the behaviour of __import__() between 3.2 and 3.3. It looks like in 3.2 __import__() does a Py2-style combo relative/absolute import. Here's a minimal test case:

$ ls foo
bar.py  __init__.py  __pycache__
$ cat foo/__init__.py
__import__('bar', globals(), locals())
$ python3.3 -c "import foo"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "./foo/__init__.py", line 1, in <module>
    __import__('bar', globals(), locals())
ImportError: No module named 'bar'
$ python3.2 -c "import foo"
$

I believe that 3.3 is correct and that 3.2 is wrong but can't be changed now, so I suppose that 3.2 should just document the actual behaviour of __import__() and 3.3 should document the change. 

(The context is that I encountered issue 15434. This looks related, but I'm not sure it is.)

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 166706
nosy: Ronan.Lamy, brett.cannon, docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: __import__() change between 3.2 and 3.3
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15482>
_______________________________________

From report at bugs.python.org  Sun Jul 29 05:31:09 2012
From: report at bugs.python.org (Eric Snow)
Date: Sun, 29 Jul 2012 03:31:09 +0000
Subject: [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>
Message-ID: <1343532669.65.0.466665947725.issue15482@psf.upfronthosting.co.za>


Eric Snow added the comment:

See issue14592 (particularly msg158466).

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15482>
_______________________________________

From report at bugs.python.org  Sun Jul 29 05:35:00 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 03:35:00 +0000
Subject: [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>
Message-ID: <1343532900.72.0.413159692026.issue15482@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The specific bug is that, in 3.2, the claimed default (level=0) is not accurate: the default is actually (level=-1), as it was in 2.x. The import statement passes level=0 explicitly (as it does in 2.x when "from __future__ import absolute_import" is in effect).

The docstring in 3.2 is accurate, the prose documentation is incorrect.

In 3.3, the docstring is currently wrong, but the prose documentation is correct. However, it should have a "versionchanged: 3.3" not added, indicating that the default import level has finally been brought into compliance with the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15482>
_______________________________________

From report at bugs.python.org  Sun Jul 29 05:36:15 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jul 2012 03:36:15 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <3Wl8hZ1gqqzPWR@mail.python.org>


Roundup Robot added the comment:

New changeset 37554bda2014 by Meador Inge in branch '2.7':
Issue #15402: Simplify Struct.__sizeof__ and make tests more precise.
http://hg.python.org/cpython/rev/37554bda2014

New changeset 97dd2090a36c by Meador Inge in branch '3.2':
Issue #15402: Simplify Struct.__sizeof__ and make tests more precise.
http://hg.python.org/cpython/rev/97dd2090a36c

New changeset 0eedf56f9a38 by Meador Inge in branch 'default':
Issue #15402: Simplify Struct.__sizeof__ and make tests more precise.
http://hg.python.org/cpython/rev/0eedf56f9a38

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Sun Jul 29 05:36:54 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 29 Jul 2012 03:36:54 +0000
Subject: [issue15402] Correct __sizeof__ support for struct
In-Reply-To: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>
Message-ID: <1343533014.74.0.826073000518.issue15402@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15402>
_______________________________________

From report at bugs.python.org  Sun Jul 29 05:41:03 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 29 Jul 2012 03:41:03 +0000
Subject: [issue15475] Correct __sizeof__ support for itertools
In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>
Message-ID: <1343533263.75.0.361672741698.issue15475@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/issue15475>
_______________________________________

From report at bugs.python.org  Sun Jul 29 05:47:00 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 03:47:00 +0000
Subject: [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>
Message-ID: <1343533620.6.0.411638252355.issue15482@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

s/not added/note added/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15482>
_______________________________________

From report at bugs.python.org  Sun Jul 29 05:54:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 03:54:57 +0000
Subject: [issue15355] generator docs should mention already-executing exception
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343534097.46.0.771177267135.issue15355@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Hmmm, in your original description you say that the 'generator.__next__' documentation should be changed, but in the patch the note applies to all generator methods.

Thanks, Meador.  Yes, I realized that later.  Retitling now.  I will also add the exception type.  I wasn't sure if that was implementation-specific.

> BTW, you don't need to make the Misc/NEWS changes

Certainly -- will do from now on.  Thanks for telling me.  I had thought I was helping.  New patch attached.

----------
title: generator.__next__() docs should mention exception if already executing -> generator docs should mention already-executing exception
Added file: http://bugs.python.org/file26560/issue-15355-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15355>
_______________________________________

From report at bugs.python.org  Sun Jul 29 06:00:26 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 29 Jul 2012 04:00:26 +0000
Subject: [issue15469] Correct __sizeof__ support for deque
In-Reply-To: <1343404078.66.0.00721941905437.issue15469@psf.upfronthosting.co.za>
Message-ID: <1343534426.76.0.740331045531.issue15469@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/issue15469>
_______________________________________

From report at bugs.python.org  Sun Jul 29 06:17:21 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 04:17:21 +0000
Subject: [issue12834] memorview.to_bytes() and PyBuffer_ToContiguous()
	incorrect for non-contiguous arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343535441.27.0.481441973051.issue12834@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Was the point that memoryview.tobytes() has a known data corruption bug in 3.2 and 2.7 raised in the previous discussion? I'm pretty sure I had forgotten about it, and I don't remember it coming up in the thread.

The trickiest aspect of a backport of the new implementation is that we need to preserve the C ABI - extensions compiled against any maintenance release should work with all maintenance releases in that series.

The new APIs aren't a major problem - just sprinkle a few underscores around to mark them as private on the older versions (I've certainly done that before when a bug fix genuinely needed something that qualified as a new feature: implemented a private version to use in fixing the bug on the maintenance branch, then promote that to a public API on trunk)

----------
priority: normal -> high
title: PyBuffer_ToContiguous() incorrect for non-contiguous arrays -> memorview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Sun Jul 29 06:21:26 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 04:21:26 +0000
Subject: [issue15473] importlib no longer uses imp.NullImporter
In-Reply-To: <1343414217.14.0.255366402583.issue15473@psf.upfronthosting.co.za>
Message-ID: <1343535686.75.0.782793865083.issue15473@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

See the porting notes: http://docs.python.org/dev/whatsnew/3.3.html#porting-python-code

With the removal of the implicit default finder, the 3.3 semantics are that both None *and* imp.NullImporter mean "There is no importer for this path".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15473>
_______________________________________

From report at bugs.python.org  Sun Jul 29 06:32:01 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 04:32:01 +0000
Subject: [issue15452] Eliminate the use of eval() in the logging config
	implementation
In-Reply-To: <1343264495.49.0.0195201203683.issue15452@psf.upfronthosting.co.za>
Message-ID: <1343536321.55.0.412193411648.issue15452@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I know ast.literal_eval() isn't enough - that's why I suggested the addition of ast.lookup_eval() in the opening post.

As far as your other suggestion goes, don't reinvent crypto badly - if you want to provide authentication support in listener(), provide a hook that allows the application to decide whether or not to accept the configuration before it gets applied. They can then choose there own authentication mechanism based on their own needs, and handle any appropriate security updates. Some will choose a simple shared secret, some may choose to require a cryptographic signature, some may pass the entire payload in an encrypted form.

However, this isn't an either/or situation - we can, and should, do both (i.e. provide a hook that allows the application to preauthenticate the configuration before it is applied, as well as replacing the use of eval() with something more limited like str.format lookup syntax). The right security mindset is to set up defence in depth, not trust one particular layer of defence to handle all possible varieties of attack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15452>
_______________________________________

From report at bugs.python.org  Sun Jul 29 06:38:37 2012
From: report at bugs.python.org (Grissiom Gu)
Date: Sun, 29 Jul 2012 04:38:37 +0000
Subject: [issue15451] PATH is not honored in subprocess.Popen in win32
In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>
Message-ID: <1343536717.44.0.105665309251.issue15451@psf.upfronthosting.co.za>


Grissiom Gu added the comment:

Thank you for everyone participated in this issue. I learnt a lot from you.

But I observe that the same script(with proper modification of file names) works very well under Linux. After I dive into the source code, I found Python use execvpe to invoke the child process which _will_ use the PATH variable to search the executable.

So I think this is a inconsistent behavior at least. So I think we should either notify the user that this API is inconsistent or just fix the Popen call in windows. Prepending the new PATH to the env of current process and than call CreateProcess is just a patch within 10 lines, I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15451>
_______________________________________

From report at bugs.python.org  Sun Jul 29 06:39:15 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 04:39:15 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343536755.57.0.118379694569.issue15295@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
hgrepos: +142

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sun Jul 29 07:10:47 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 05:10:47 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343538647.87.0.343802121082.issue15295@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I would title the new section "Import system" rather than "Import machinery" as it is meant to be a specification documentation rather than an implementation description.

Import statement:

The statement that "from X import A" only performs a single import lookup is incorrect. The trick is that if A, B or C refers to a submodule of X then it will be imported.

I'll use a couple of examples from the logging package to make this clear:

# Attribute access will fail for submodules that haven't been imported yet
>>> import logging
>>> logging.DEBUG
10
>>> logging.handlers
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'handlers'

# Direct imports will fail for attributes that are not submodules
>>> import logging.DEBUG
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'logging.DEBUG'
>>> import logging.handlers

# From imports check for an existing attribute first, but check for a submodule if the attribute is missing
>>> del sys.modules["logging"]
>>> del sys.modules["logging.handlers"]
>>> from logging import DEBUG
>>> from logging import handlers

Aside from this flaw, the new content in the import statement looks good. More on the import system section in a subsequent comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sun Jul 29 08:01:44 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 29 Jul 2012 06:01:44 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343541704.06.0.300394339472.issue1692335@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Richard, can the issue be closed?

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Sun Jul 29 08:09:43 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 06:09:43 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343542183.14.0.0311024413828.issue15295@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

General comment:

runpy, pkgutil, et al should all get "See Also" links at the top pointing to the new import system section.

Import system intro:

As noted above, I suggest changing the name :)

Opening section should refer to importlib.import_module(). Any mentions of __import__ should point out that its API is designed for the convenience of the interpreter, and thus it's a pain to use directly. However, we should also document explicitly that, unlike the import statement and calling __import__ directly, importlib.import_module will ignore any module level replacements of __import__.

Replacing builtins.__import__ won't reliably override the entire import system (due to module level __import__ definitions, most notably importlib.__import__) and other tools that work with the process global import state directly (e.g. pkgutil, runpy).

5.1 Packages:

Don't tease readers, just tell them: the defining characteristic of a package is that it is a module object with a __path__ attribute.

Since we have the privilege of defining *the* standard terminology for old-style packages, I suggest we use the term "initialised" packages (since having an __init__.py is what makes them special). We should also note explicitly that an initialised package can also behave as a namespace package, by setting __path__ appropriately in __init__.py

Also, I suggest adding a 5.1.3 Package Example subheading - currently you define an initialised package under the namespace package heading

Finally, I think this section needs to explicitly define the terms *import path* and *path entry*. The meta path docs later refer to find_module() accepting a module name and path, and the reader could be forgiven for thinking that meant a filesystem path, when it is actually an import path (which is a sequence of path entries, which may themselves by filesystem paths).

5.2.2 Finders and loaders:

The term "sys path finder" is incorrect as registered path hooks are invoked for both sys.path entries *and* package __path__ entries. I suggest "path entry finder". (I agree a longer name is needed to better distinguish them from metapath finders)

5.2.3 Import hooks:

While it does get cleared up in 5.2.4, this section could be clearer that the hooks *cannot* override the initial check of the module cache.

5.3.4 Metapath:

See above comment about clarifying that an import path is passed to find_module() rather than a filesystem path.

The description of the path importer is incorrect. It only knows how to scan an import path and interrogate the path hooks. It's the individual path entry finders that know how to do things like load modules from the filesystem or zip files.


5.2.5 Meta path loaders

I don't like the title here. There's no such thing as a meta path loader. there are only module loaders. Once they're created, it doesn't matter how you found them.

Clarify that the loader only has to remove the modules it inserted itself. Other modules that were loaded *successfully* as a side effect of the code execution will remain in the cache.

5.3 The Path Importer

As noted above, the path importer is *NOT* restricted to filesystem imports. All it cares about is arbitrary text sequences and path hooks. With the right path hook, you could use URLs or database connection strings as path entries.

5.5 References

I'd also point to PEP 328 (absolute imports by default and explicit relative import syntax) and PEP 338 (using the import system to find __main__)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sun Jul 29 08:10:29 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 06:10:29 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343542229.31.0.967791826455.issue15295@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Great start here Barry, I'll switch my checkout over to read/write access and start contributing fixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sun Jul 29 08:39:32 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 06:39:32 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343543972.97.0.534744614454.issue15295@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Pushed the import machinery -> import system change (which hopefully won't break Barry's world)

Also merged in a more recent version of trunk. This probably screwed up the default branch in this clone, but the clone should be done after these docs updates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sun Jul 29 08:57:24 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 06:57:24 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343545044.2.0.426009143097.issue15467@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Patches updated. Simplified struct __sizeof__?testing for 2.7 and 3.2 and fixed (using 'n' for Py_ssize_t) for 3.3.

----------
nosy: +meador.inge
Added file: http://bugs.python.org/file26561/sizeof_tests-3.3_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Sun Jul 29 08:58:11 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 06:58:11 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343545091.68.0.428684686035.issue15467@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26562/sizeof_tests-3.2_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Sun Jul 29 08:58:54 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 06:58:54 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343545134.02.0.806630910765.issue15467@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26563/sizeof_tests-2.7_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Sun Jul 29 08:59:28 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 06:59:28 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343545168.31.0.920339236177.issue15467@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file26541/sizeof_tests-3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Sun Jul 29 08:59:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 06:59:45 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343545185.29.0.205250097386.issue15467@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file26542/sizeof_tests-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Sun Jul 29 08:59:57 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 06:59:57 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343545197.87.0.452114307353.issue15467@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file26543/sizeof_tests-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Sun Jul 29 09:01:18 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 07:01:18 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343545278.79.0.880558625579.issue14803@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've switched back to being -1 on the PYTHONRUNFIRST idea. There are no ACLs for environment variables, so the security implications scare me too much for me to support the feature.

The simple -C option doesn't have that problem, though, and could be used as infrastructure in a process infrastructure framework to provide enhanced configuration of Python subprocesses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Sun Jul 29 09:19:33 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 07:19:33 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343546373.92.0.530531956661.issue15425@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/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 10:19:10 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 08:19:10 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343549950.0.0.0331656290416.issue15425@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Added patch with test cases for the situations Amaury picked up, as well another I noticed (when the from clause refers to a module that fails)

----------
Added file: http://bugs.python.org/file26564/issue15425_test_cases.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 10:20:44 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 08:20:44 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343550044.92.0.204718864738.issue15425@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I actually did start refactoring a lot of this when I was working on the pkgutil changes, but stopped because that patch was already hairy enough.

Maybe I should have kept going...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 10:25:45 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 08:25:45 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343550345.46.0.76915256806.issue15425@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think tuning the "what frames to hide" heuristic is a better bet - I remember know that the real reason I stopped messing with which exceptions were thrown was that I ended up confusing pkgutil.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 10:28:33 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 08:28:33 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343550513.39.0.182855766798.issue15425@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Fixed test case patch - previous one included a comment from when my test was buggy.

----------
Added file: http://bugs.python.org/file26565/issue15425_test_cases.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 10:28:45 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 08:28:45 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343550525.26.0.173375616358.issue15425@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file26564/issue15425_test_cases.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 10:49:49 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 29 Jul 2012 08:49:49 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343551789.68.0.0969199810841.issue15425@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

I like the concept of "exit points" that Antoine introduced with a special method name. Maybe we coule generalize this and have a "execute_and_hide_frames(func, *args, **kwargs)" that is recognized by the caller in import.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 10:59:18 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 29 Jul 2012 08:59:18 +0000
Subject: [issue12834] memorview.to_bytes() and PyBuffer_ToContiguous()
	incorrect for non-contiguous arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343552358.66.0.299089763669.issue12834@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Christian's posts and my initial report were about memoryview.tobytes(). It's
good that you changed the title: memoryview.tobytes() is more meaningful than
the slightly obscure PyBuffer_ToContiguous().


BTW, I'm sure that PyBuffer_FromContiguous() and PyObject_CopyData() have the
same problem, but they aren't used in the Python source tree and they are
undocumented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Sun Jul 29 11:04:50 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 29 Jul 2012 09:04:50 +0000
Subject: [issue15477] test_cmath failures on OS X 10.8
In-Reply-To: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za>
Message-ID: <1343552690.38.0.647447532557.issue15477@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> These types of run-time tests based on configure-time tests are problematic
> for binary installations of Python, like the OS X installers.

Understood.  I'm wondering how to fix this for Python, given that we're unlikely to see an OS-level fix for a while.  There's an easy workaround, namely to add an "if (x == 0.0) return x;" before any use of the system log1p;  the issue is how and when to apply this workaround.

One option is always to apply the workaround, but this feels to me as though it's unnecessarily penalising those OSs that get it right;  maybe just always apply the workaround on OS X?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15477>
_______________________________________

From report at bugs.python.org  Sun Jul 29 11:07:32 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 09:07:32 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343552852.35.0.682584375061.issue15425@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

OK, to investigate the failures a bit further, I turned off the traceback suppression altogether by sticking an immediate return at the start of remove_importlib_frames. For the three failing tests, this is what I got when adding a traceback.print_tb call:

test_broken_from (test.test_import.ImportTracebackTests) ...   File "/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 890, in test_broken_from
    from _parent_foo import bar
  File "<frozen importlib._bootstrap>", line 1572, in _handle_fromlist
  File "<frozen importlib._bootstrap>", line 1524, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1491, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 571, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1002, in load_module
  File "<frozen importlib._bootstrap>", line 983, in load_module
  File "<frozen importlib._bootstrap>", line 547, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 853, in _load_module
  File "<frozen importlib._bootstrap>", line 860, in _exec_module
  File "./_parent_foo/bar.py", line 1, in <module>
    1/0
FAIL
test_broken_parent (test.test_import.ImportTracebackTests) ...   File "/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 902, in test_broken_parent
    import _parent_foo.bar
  File "<frozen importlib._bootstrap>", line 1524, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1475, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1524, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1491, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 571, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1002, in load_module
  File "<frozen importlib._bootstrap>", line 983, in load_module
  File "<frozen importlib._bootstrap>", line 547, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 853, in _load_module
  File "<frozen importlib._bootstrap>", line 860, in _exec_module
  File "./_parent_foo/__init__.py", line 1, in <module>
    1/0
FAIL
test_syntax_error (test.test_import.ImportTracebackTests) ...   File "/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 851, in test_syntax_error
    import foo
  File "<frozen importlib._bootstrap>", line 1524, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1491, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 571, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1002, in load_module
  File "<frozen importlib._bootstrap>", line 983, in load_module
  File "<frozen importlib._bootstrap>", line 547, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 838, in _load_module
  File "<frozen importlib._bootstrap>", line 960, in get_code
FAIL

And here's what I get with my patched version enabled (which also ignores chunks ending with get_code when the failure is a syntax error):

test_broken_from (test.test_import.ImportTracebackTests) ...   File "/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 890, in test_broken_from
    from _parent_foo import bar
  File "<frozen importlib._bootstrap>", line 1572, in _handle_fromlist
  File "./_parent_foo/bar.py", line 1, in <module>
    1/0
FAIL
test_broken_parent (test.test_import.ImportTracebackTests) ...   File "/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 902, in test_broken_parent
    import _parent_foo.bar
  File "<frozen importlib._bootstrap>", line 1524, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1475, in _find_and_load_unlocked
  File "./_parent_foo/__init__.py", line 1, in <module>
    1/0
FAIL
test_syntax_error (test.test_import.ImportTracebackTests) ...   File "/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 851, in test_syntax_error
    import foo
FAIL

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 11:26:09 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 09:26:09 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343553969.87.0.20194730854.issue15425@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I realised that it is my test that was wrong in the syntax error case. Attached patch includes the test cases, and the fix for that case.

The weird thing that still requires an explanation is why the chunks in the first two cases are only being partially stripped. Those blocks end with _exec_module, yet a couple of frames are being left in the traceback.

Current patch includes my debugging output from those tests.

----------
Added file: http://bugs.python.org/file26566/issue15425_handle_syntax_error.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 11:37:34 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 09:37:34 +0000
Subject: [issue15268] curses configure checks fail if only
	/usr/include/ncursesw/curses.h is installed
In-Reply-To: <1341623074.57.0.341676091224.issue15268@psf.upfronthosting.co.za>
Message-ID: <1343554654.44.0.5969486565.issue15268@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

Matthias, do not use hack if cross-build

----------
nosy: +rpetrov
Added file: http://bugs.python.org/file26567/4-CROSS-avoid-ncursesw-include-path-hack.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15268>
_______________________________________

From report at bugs.python.org  Sun Jul 29 11:40:33 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 09:40:33 +0000
Subject: [issue15483] CROSS: initialise include and library paths in setup.py
Message-ID: <1343554833.66.0.976178324221.issue15483@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

In setup.py  inc_dirs and lib_dirs are not initialized in cross-build case.

----------
files: 1-CROSS-initialise-include-and-library-paths.patch
keywords: patch
messages: 166733
nosy: rpetrov
priority: normal
severity: normal
status: open
title: CROSS: initialise include and library paths in setup.py
Added file: http://bugs.python.org/file26568/1-CROSS-initialise-include-and-library-paths.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15483>
_______________________________________

From report at bugs.python.org  Sun Jul 29 11:43:22 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 09:43:22 +0000
Subject: [issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig
Message-ID: <1343555002.08.0.568710473474.issue15484@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Same as sysconfig but now in distutils  _PYTHON_PROJECT_BASE has to be used in cross-build environment.

----------
components: Build
files: 2-CROSS-use-_PYTHON_PROJECT_BASE-in-distutils-sysconfig.patch
keywords: patch
messages: 166734
nosy: rpetrov
priority: normal
severity: normal
status: open
title: CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig
versions: Python 3.3
Added file: http://bugs.python.org/file26569/2-CROSS-use-_PYTHON_PROJECT_BASE-in-distutils-sysconfig.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15484>
_______________________________________

From report at bugs.python.org  Sun Jul 29 11:46:17 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 09:46:17 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343555177.26.0.443211386115.issue15425@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ah, it turns out the three problem children are those which accept an "import_" callback, which is set to builtins.__import__ when accessed via the import statement. This means we end up making a *recursive* call to PyImport_ImportModuleLevelObject, which calls remove_importlib_frames. The inner section of the trace gets stripped away, thus the "_exec_module" frame is already gone by the time the outer frames get added to the traceback.

For the moment, I'm just going to adopt the blunt instrument approach and special case those three functions (including them in the "always strip" category). If anyone else comes up with a more elegant mechanism to deal with the recursion, we can switch to it later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 11:48:49 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 09:48:49 +0000
Subject: [issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig
In-Reply-To: <1343555002.08.0.568710473474.issue15484@psf.upfronthosting.co.za>
Message-ID: <1343555329.92.0.781519517635.issue15484@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

Also _PYTHON_PROJECT_BASE should be initialized to build directory by configure - low priority as other issue prevent python to be build and tested smoothly outside source tree.

----------
Added file: http://bugs.python.org/file26570/2-CROSS-set-_PYTHON_PROJECT_BASE-to-current-build-dir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15484>
_______________________________________

From report at bugs.python.org  Sun Jul 29 11:55:18 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 09:55:18 +0000
Subject: [issue15485] CROSS: append gcc library search paths
Message-ID: <1343555717.99.0.825702829621.issue15485@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Currently if cross-build add_gcc_paths use append_dir_to_list but later prepend library paths. As result  gcc is multilib 64-bit libraries will be found first before 32-bit one.

----------
components: Cross-Build
files: 3-CROSS-append-gcc-library-search-paths.patch
keywords: patch
messages: 166737
nosy: rpetrov
priority: normal
severity: normal
status: open
title: CROSS: append gcc library search paths
versions: Python 3.3
Added file: http://bugs.python.org/file26571/3-CROSS-append-gcc-library-search-paths.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15485>
_______________________________________

From report at bugs.python.org  Sun Jul 29 11:58:44 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 09:58:44 +0000
Subject: [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>
Message-ID: <1343555924.3.0.235800550091.issue15482@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

So should 3.2 be changed to adjust the default value to match the documentation?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15482>
_______________________________________

From report at bugs.python.org  Sun Jul 29 11:59:23 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 09:59:23 +0000
Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous()
	incorrect for non-contiguous arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343555963.61.0.0511110526507.issue12834@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: memorview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays -> memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Sun Jul 29 12:02:05 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 10:02:05 +0000
Subject: [issue15483] CROSS: initialise include and library paths in setup.py
In-Reply-To: <1343554833.66.0.976178324221.issue15483@psf.upfronthosting.co.za>
Message-ID: <1343556125.48.0.0279627098471.issue15483@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
components: +Cross-Build
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15483>
_______________________________________

From report at bugs.python.org  Sun Jul 29 12:02:35 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 10:02:35 +0000
Subject: [issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig
In-Reply-To: <1343555002.08.0.568710473474.issue15484@psf.upfronthosting.co.za>
Message-ID: <1343556155.71.0.590957942694.issue15484@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
components: +Cross-Build -Build
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15484>
_______________________________________

From report at bugs.python.org  Sun Jul 29 12:03:42 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 10:03:42 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343556222.88.0.27429596274.issue15425@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I'll at least introduce a "_recursive_import" exit point to simplify handling of those three cases. For those, if there isn't another importlib frame on the stack below them, odds are pretty good that it has been stripped already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 12:20:32 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 10:20:32 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1343557232.78.0.41570870513.issue3754@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

I hope that  following separate issues will address remaining part of this patch:

required:
- 15483: initialise include and library paths in setup.py
- 15484: use _PYTHON_PROJECT_BASE in distutils sysconfig
- TODO: typo in in configure.in - use ac_cv_pthread instead ac_cv_thread
- 15268: skip "curses configure checks fail if only /usr/include/ncursesw/curses.h is installed"

optional:
- 15298: _sysconfigdata is generated in srcdir, not builddir
- 14598: _cursesmodule.c fails with ncurses-5.9 on Linux reported first as 14438 - _cursesmodule build fails on cygwin
and all other that allow python to be build smoothly outside source directory

----------
components: +Cross-Build -Build, Distutils2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sun Jul 29 12:26:48 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 10:26:48 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	packaging
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1343557608.41.0.743499390069.issue3871@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

May be patch 20120729 cannot be applied as my source tree contain a number of patches related to cross build - see msg166740  from issue 3754 .

----------
Added file: http://bugs.python.org/file26572/python-py3k-20120729-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jul 29 12:30:51 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jul 2012 10:30:51 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <3WlKty3cdGzPYx@mail.python.org>


Roundup Robot added the comment:

New changeset 75a30a478dc7 by Nick Coghlan in branch 'default':
Close #15425: Eliminate more importlib related traceback noise
http://hg.python.org/cpython/rev/75a30a478dc7

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 12:36:50 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 10:36:50 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343558210.67.0.674496129458.issue15425@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think the implementation I just checked in is close to being as simple as we can get:

Blocks ending in _exec_module and _recursive_import are trimmed unconditionally
For SyntaxError, it also trims blocks ending in get_code
For ImportError, it trims everything involving importlib

Because the latter two are conditional on the kind of exception thrown, it's only the first two that could be unified and I think keeping the two distinct checks is actually clearer in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 12:40:00 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 10:40:00 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343558400.57.0.0570899489708.issue15425@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

On second thought, I realised having a general purpose "hide this" hook means that any future unconditional cases can easily be hidden just by changing from the normal call to a stripped call. I'll implement that now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 12:46:43 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 10:46:43 +0000
Subject: [issue15486] Standardise the mechanisms for stripping importlib frames
Message-ID: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Thanks to issue #15425, the number of special cases in the importlib frame stripping is growing. This patch tweaks the frame stripping mechanism to make it easy to selectively strip frames in importlib._bootstrap by creating a _call_with_frames_removed helper function.

The rules in remove_importlib_frames then change to remove any sequence of importlib frames which ends with that helper and all importlib frames in the ImportError case.

----------
messages: 166745
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Standardise the mechanisms for stripping importlib frames

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Sun Jul 29 12:47:22 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 10:47:22 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343558842.93.0.396491296412.issue15425@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Seeing as the blocker is dealt with for beta2, see #15486 for the proposed refactoring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 13:03:55 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 11:03:55 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1343545278.79.0.880558625579.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343559699.3388.4.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> I've switched back to being -1 on the PYTHONRUNFIRST idea. There are
> no ACLs for environment variables, so the security implications scare
> me too much for me to support the feature.

I'm quite sure PYTHONHOME and PYTHONPATH already allow you to mess quite
freely. That's why we have the -E flag.

I'm -0.5 myself, though, for the reason that it complicates the startup
process a little bit more, without looking very compelling. It smells
disturbingly like LD_PRELOAD to me.

> The simple -C option doesn't have that problem, though, and could be
> used as infrastructure in a process infrastructure framework to
> provide enhanced configuration of Python subprocesses.

What do you mean exactly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Sun Jul 29 13:28:02 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 11:28:02 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343561282.05.0.416183541351.issue15486@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

In trying to find a new case that wasn't already covered by the test suite, I found an error which I'm not even sure should be an error. Doesn't 3.2 suppress failures that occur when attempting to implicitly cache the .pyc?

Anyway, given the rest of the patch, trimming this traceback will be easy if we decide that's the right thing to do.

----------
components: +Interpreter Core, Library (Lib)
keywords: +patch
nosy: +amaury.forgeotdarc, brett.cannon, eric.snow, georg.brandl
priority: normal -> release blocker
stage:  -> patch review
title: Standardise the mechanisms for stripping importlib frames -> Standardised mechanism for stripping importlib frames from tracebacks
type:  -> behavior
versions: +Python 3.3
Added file: http://bugs.python.org/file26573/issue15486_simplify_importlib_frame_removal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Sun Jul 29 13:44:57 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 29 Jul 2012 11:44:57 +0000
Subject: [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>
Message-ID: <1343562297.57.0.857382561066.issue15482@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/issue15482>
_______________________________________

From report at bugs.python.org  Sun Jul 29 13:53:56 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 29 Jul 2012 11:53:56 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343562836.55.0.679410266784.issue15425@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/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 13:54:19 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 29 Jul 2012 11:54:19 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343562859.66.0.928110824186.issue15486@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/issue15486>
_______________________________________

From report at bugs.python.org  Sun Jul 29 13:56:19 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 29 Jul 2012 11:56:19 +0000
Subject: [issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig
In-Reply-To: <1343555002.08.0.568710473474.issue15484@psf.upfronthosting.co.za>
Message-ID: <1343562979.49.0.408940943728.issue15484@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/issue15484>
_______________________________________

From report at bugs.python.org  Sun Jul 29 14:19:38 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 12:19:38 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343564378.58.0.208345178212.issue15295@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Updated the statement docs to accurately describe the from X import Y case.

I also noted that unlike the statement form, importlib.import_module ignores module level __import__ overrides.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Sun Jul 29 14:24:55 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Jul 2012 12:24:55 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343564695.76.0.141815527322.issue1692335@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Richard, can the issue be closed?

I guess so (although the change could arguably be back ported).

Pickling of Exception classes is still somewhat dodgy because an example like

    class Error(Exception):
        def __init__(self, x):
            Exception.__init__(self)
            self.x = x

is still not picklable.

Any further improvements can be discussed in a separate issue, so I will close.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Sun Jul 29 14:27:53 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 29 Jul 2012 12:27:53 +0000
Subject: [issue12288] Python 2.7.1 tkSimpleDialog initialvalue
In-Reply-To: <1307568483.64.0.2959467561.issue12288@psf.upfronthosting.co.za>
Message-ID: <1343564873.79.0.691741763641.issue12288@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Add patch for py3k

----------
assignee:  -> asvetlov
keywords: +patch
nosy: +asvetlov
versions: +Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26574/issue12288.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12288>
_______________________________________

From report at bugs.python.org  Sun Jul 29 14:28:11 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Jul 2012 12:28:11 +0000
Subject: [issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
In-Reply-To: <1242668944.28.0.292370665479.issue6056@psf.upfronthosting.co.za>
Message-ID: <1343564891.86.0.430506378857.issue6056@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6056>
_______________________________________

From report at bugs.python.org  Sun Jul 29 14:28:29 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 29 Jul 2012 12:28:29 +0000
Subject: [issue12288] tkinter SimpleDialog initialvalue
In-Reply-To: <1307568483.64.0.2959467561.issue12288@psf.upfronthosting.co.za>
Message-ID: <1343564909.08.0.748745913184.issue12288@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
title: Python 2.7.1 tkSimpleDialog initialvalue -> tkinter SimpleDialog initialvalue

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12288>
_______________________________________

From report at bugs.python.org  Sun Jul 29 14:37:21 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 12:37:21 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343565441.94.0.991289324767.issue14803@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Nothing too complicated - just noting that a test suite like ours that launches Python subprocesses to test process global state handling could fairly easily arrange to pass appropriate -C options to trigger things like recording coverage data or profiling options.

I'll also note that if you put a "preinit.py" on sys.path (e.g. in the current directory if using -m for invocation), you could easily do "-C 'import preinit'" to do arbitrarily complex custom setups, including preconfiguring your test framework.

A lot of my thoughts on this come out of looking into migrating the various stdlib modules like trace, pdb and profile over to supporting everything that runpy (and hence the main executable) supports, and a lot of the complexity lies in the mechanics of how to daisy chain the two "__main__" modules together. Running a bit of extra code in __main__ as supplied on the command line before kicking off the full import process helps avoid a lot of pain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Sun Jul 29 14:37:53 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Jul 2012 12:37:53 +0000
Subject: [issue15364] sysconfig confused by relative paths
In-Reply-To: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>
Message-ID: <1343565473.96.0.63896378213.issue15364@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> One example is 'srcdir': this value is only useful in the build tree and 
> there currently is no clean way to signal that you are retrieving a 
> value that is not useful.

In the particular case of 'srcdir', sysconfig.is_python_build() tells you whether the value is useful.

Concerns about sysconfig often returning values which are meaningless for the current configuration can be discussed in another issue.

Unless there are objections I will close.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________

From report at bugs.python.org  Sun Jul 29 14:49:08 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 29 Jul 2012 12:49:08 +0000
Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous()
	incorrect for non-contiguous arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343566148.26.0.857899341362.issue12834@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks Stefan and Nick!

I tried to find the off-by-one bug myself but gave up quickly. Stefan's rewrite is a better approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Sun Jul 29 15:04:42 2012
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 29 Jul 2012 13:04:42 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343567082.39.0.563553998846.issue14803@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

> I'm -0.5 myself, though, for the reason that it complicates the startup
> process a little bit more, without looking very compelling. It smells
> disturbingly like LD_PRELOAD to me.

Antoine, do you have a suggestion for how to solve the coverage.py problem?  To re-iterate: imagine you have a large test suite, and it spawns python processes during the tests.  Mercurial, for example, is like this.  You want to measure the coverage of your test suite.  This means not do you have to invoke the main suite with "python coverage.py run tests.py" instead of "python tests.py", but all the subprocess invocations need to invoke coverage.py as well.

We are looking for ways to make this as transparent as possible to the tests themselves, just as coverage measurement is now for test suites that don't spawn python subprocesses.

http://nedbatchelder.com/code/coverage/subprocess.html describes the two current hacks people can use to invoke coverage on subprocesses.  I was hoping for a cleaner more natural solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Sun Jul 29 15:10:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 13:10:45 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
Message-ID: <1343567445.16.0.656305805275.issue15487@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for C implementation of buffered I/O files: io.BufferedReader, io.BufferedWriter and io.BufferedRandom.

----------
components: IO, Library (Lib)
messages: 166756
nosy: benjamin.peterson, hynek, pitrou, storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for buffered I/O
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________

From report at bugs.python.org  Sun Jul 29 15:30:33 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 13:30:33 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343568633.57.0.619700201502.issue15425@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

The unit tests added here are another candidate for the refactoring in issue 15403 ("Refactor package creation support code into a common location").  I'll note this in that issue.

----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Sun Jul 29 15:31:28 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 29 Jul 2012 13:31:28 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
In-Reply-To: <1343567445.16.0.656305805275.issue15487@psf.upfronthosting.co.za>
Message-ID: <1343568688.01.0.905401241522.issue15487@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

There is no patch.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________

From report at bugs.python.org  Sun Jul 29 15:36:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 13:36:47 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343569007.03.0.277422613217.issue15403@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Lib/test/test_import.py also contains test code that would benefit from this (see for example issue 15425).  (Though not all files need to be refactored in a single issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Sun Jul 29 15:44:31 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 13:44:31 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343569471.88.0.824503400427.issue15486@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

The test cases uploaded to issue 7559 ("TestLoader.loadTestsFromName swallows import errors") a while back contain a number of distinct cases (four, I think) in which an import error can be raised.  IIRC, these include a couple recursive scenarios (cyclical import from within __init__.py, etc).

Those test cases were designed specifically to cover different scenarios in which unittest's loader was swallowing import errors.  Might be worth taking a look.

----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Sun Jul 29 15:46:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 13:46:18 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343569578.82.0.851261635488.issue14803@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Sun Jul 29 15:56:52 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 13:56:52 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
In-Reply-To: <1343567445.16.0.656305805275.issue15487@psf.upfronthosting.co.za>
Message-ID: <1343570212.09.0.952612072243.issue15487@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file26575/bufferedio_sizeof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:04:54 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Jul 2012 14:04:54 +0000
Subject: [issue15451] PATH is not honored in subprocess.Popen in win32
In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>
Message-ID: <1343570694.9.0.95115813902.issue15451@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> But I observe that the same script(with proper modification of file names) 
> works very well under Linux. After I dive into the source code, I found 
> Python use execvpe to invoke the child process which _will_ use the PATH 
> variable to search the executable.

The posix execvpe function does not use PATH from the passed environment, but (surprisingly to me) os.execvpe does.  subprocess in Python 3 no longer uses os.execvpe, but still goes out of its way to use envp['PATH'] on posix systems when searching for the executable.

So I think you have a legitimate complaint of inconsistency.

However, I don't think your suggested fix is a good idea since it (temporarily) changes the environment of the current process which might be problematic in a threaded program.

I am sure that Python 2.7 will not be patched to address this, but you might want to make a feature request for Python 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15451>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:18:58 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 14:18:58 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1343567082.39.0.563553998846.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343571402.3388.7.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> > I'm -0.5 myself, though, for the reason that it complicates the startup
> > process a little bit more, without looking very compelling. It smells
> > disturbingly like LD_PRELOAD to me.
> 
> Antoine, do you have a suggestion for how to solve the coverage.py
> problem?  To re-iterate: imagine you have a large test suite, and it
> spawns python processes during the tests.  Mercurial, for example, is
> like this.  You want to measure the coverage of your test suite.  This
> means not do you have to invoke the main suite with "python
> coverage.py run tests.py" instead of "python tests.py", but all the
> subprocess invocations need to invoke coverage.py as well.

Ok, sorry then, I retract what I said. I agree the use case is
legitimate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:19:15 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 14:19:15 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343571555.5.0.197696023367.issue14803@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Ned, two questions: in the scenario you just described, is it a requirement that your test suite's code need not be modified (even minimally) to support coverage of subprocesses?

And can the solution assume that the test suite is spawning the Python processes in certain standard ways, or must it address all possible ways (even convoluted ones)?  If the former, what are the standard ways?  I am referring to things like the path to the Python interpreter invoked and how that is obtained, whether the subprocess module is always used, etc.

These questions are meant to help pin down the scope of what needs to be satisfied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:25:46 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 29 Jul 2012 14:25:46 +0000
Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous()
	incorrect for non-contiguous arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343571946.51.0.0449343298162.issue12834@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Nick, are you talking about a complete backport or just about pulling
in all functions needed by PyBuffer_ToContiguous()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:38:11 2012
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 29 Jul 2012 14:38:11 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343572691.15.0.479985124263.issue14803@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

Chris:

The real problem is that it isn't the "test suite" that spawns the processes, the tests invoke product code, and the product code spawns Python.  So modifying the Python-spawning really means modifying the product code to do something different under coverage, which most developers (rightfully) won't want to do.

My preference is not to assume a particular style of spawning subprocesses, since coverage.py tried quite hard to be applicable to any Python project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:39:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jul 2012 14:39:01 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <3WlRPJ2hRRzPTw@mail.python.org>


Roundup Robot added the comment:

New changeset efade142ef01 by Martin v. L?wis in branch '3.2':
Issue #15467: Move helpers for __sizeof__ tests into test_support.
http://hg.python.org/cpython/rev/efade142ef01

New changeset d43ff8eb4cb3 by Martin v. L?wis in branch 'default':
Issue #15467: Merge 3.2
http://hg.python.org/cpython/rev/d43ff8eb4cb3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:39:25 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jul 2012 14:39:25 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <3WlRPm3fjtzPbV@mail.python.org>


Roundup Robot added the comment:

New changeset fa95b04e67fd by Martin v. L?wis in branch '2.7':
Issue #15467: Move helpers for __sizeof__ tests into test_support.
http://hg.python.org/cpython/rev/fa95b04e67fd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:40:05 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 14:40:05 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343572805.16.0.977191905552.issue15467@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I wasn't aware that test_support isn't public API. The patches are fine then; committed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:44:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 14:44:30 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
In-Reply-To: <1343567445.16.0.656305805275.issue15487@psf.upfronthosting.co.za>
Message-ID: <1343573070.06.0.0824042831168.issue15487@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Instead of putting this in MiscIOTest, you could use the relevant class-specific test cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:50:32 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 14:50:32 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343573432.0.0.0466693699564.issue15486@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This is an elegant solution, +1 from me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:54:40 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 14:54:40 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343573680.29.0.528180741756.issue15403@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Please let's not have something called test.supportlib in addition to test.support. If test.support grows too large we can turn it into a package.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Sun Jul 29 16:54:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 14:54:47 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343573687.51.0.379586854606.issue14803@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I understand that.  Sorry, I meant to say "code under test."

If you make no assumptions about spawning subprocesses, does this mean, for example, that the solution must satisfy the case of subprocesses invoking a different version of Python, or invoking the same version of Python in a different virtual environment?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Sun Jul 29 17:03:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 15:03:38 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343574218.72.0.430961837551.issue15403@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I feel like it is already too large (it is over 1750 lines), and I did not want to create a third sibling test support module (there is also test/script_helper.py that overlaps with test.support).  Do you think that the community would be open to refactoring test.support into a package for Python 3.3?  This was meant to assist in increasing test coverage for Python 3.3 bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Sun Jul 29 17:14:10 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 15:14:10 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1343574218.72.0.430961837551.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343574712.3388.10.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> I feel like it is already too large (it is over 1750 lines), and I did
> not want to create a third sibling test support module (there is also
> test/script_helper.py that overlaps with test.support).  Do you think
> that the community would be open to refactoring test.support into a
> package for Python 3.3?  This was meant to assist in increasing test
> coverage for Python 3.3 bugs.

That's too late for 3.3, IMO. Whether or not test.support is too large
is a matter of taste (we have larger files in the stdlib; what makes
test.support annoying to work with is that it's a hodge-podge of utility
functions with little care for consistency). Unless we can clearly
separate it in thematic areas, making it a package would only make
finding stuff more difficult.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Sun Jul 29 17:22:27 2012
From: report at bugs.python.org (Cheer Xiao)
Date: Sun, 29 Jul 2012 15:22:27 +0000
Subject: [issue633930] Nested class __name__
Message-ID: <1343575347.26.0.517885081261.issue633930@psf.upfronthosting.co.za>


Cheer Xiao added the comment:

There is a bigger problem:

>>> class C:
...     class D:
...         pass
...
>>> repr(C)
"<class '__main__.C'>"
>>> repr(C.D)
"<class '__main__.D'>"

Default repr on nested classes produce specious results.

The problem become pratical when you have two nested classes C1.D and C2.D in module m, which end up being both "m.D" in exception traceback. 

Classes nested in function are likely to contain some information from the function arguments and are thus different on each function call, making it impossible to have a general way to name them. Thus I propose embedding the resulting class's `id` in __name__, like what i'm doing manually in a hulking way:

>>> def factory(foo):
...     class C(object):
...         bar = foo
...     func_name = 'factory'
...     C.__name__ = '%s generated classobj at 0x%x' % (func_name, id(C))
...     return C
...
>>> factory(0)
<class '__main__.factory generated classobj at 0x32273c0'>
>>> factory(0)
<class '__main__.factory generated classobj at 0x32245b0'>

Please consider reopening this issue.

----------
nosy: +xiaq

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue633930>
_______________________________________

From report at bugs.python.org  Sun Jul 29 17:23:36 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 15:23:36 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343575416.66.0.444666071454.issue15403@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

At this point, would you advise me to add even more to the existing hodge podge, or to create a third sibling test support module?  My patch adds closely related test support functionality.

Incidentally, this discussion relates to the point I was getting at in the python-dev thread in the past couple days about how restrictions on refactoring test support code for maintenance releases can affect the quality of our test code.  I am still struggling with how to approach that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Sun Jul 29 17:32:08 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sun, 29 Jul 2012 15:32:08 +0000
Subject: [issue15478] UnicodeDecodeError on OSError on Windows with
	undecodable (bytes) filename
In-Reply-To: <1343479745.83.0.410557070565.issue15478@psf.upfronthosting.co.za>
Message-ID: <1343575928.98.0.836729185602.issue15478@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

+1 for keeping the file name unchanged. This solution is not very 
compatible with prior versions, but simple and least-surprise.

I prefer other platforms than Windows to use same method to build OSError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15478>
_______________________________________

From report at bugs.python.org  Sun Jul 29 17:40:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 15:40:30 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1343575416.66.0.444666071454.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343576292.3388.15.camel@localhost.localdomain>


Antoine Pitrou added the comment:

I don't mind refactoring test support routines in maintenance release. I
said it was too late for 3.3 because the beta period is closing; but it
could be fine for 3.3.1 ;)

As for the way forward, I see three possibilites:
1) put everying in test.support, as a single module (that includes
folding script_helper into it)
2) make test.support a package of thematic modules
3) refactor test.support into a variety of independent modules
(script_helper, import_helper, socket_helper, etc.); a small
test.support providing fundamental features such as TESTFN could remain

My personal preference would be for 1) or 3). But whatever we choose, we
should do it consistently. Having a large test.support + a supportlib
package + some independent helpers is not a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Sun Jul 29 17:47:55 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 29 Jul 2012 15:47:55 +0000
Subject: [issue15467] Updating __sizeof__ tests
In-Reply-To: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>
Message-ID: <1343576875.53.0.694327228967.issue15467@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
stage:  -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15467>
_______________________________________

From report at bugs.python.org  Sun Jul 29 17:56:46 2012
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 29 Jul 2012 15:56:46 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343577406.61.0.728823361148.issue14803@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

Chris, I'm not sure how to answer your questions.  The more powerful and flexible, the better.  There is no "must" here.  I'm looking for a way to avoid the hacks coverage.py has used in the past to measure coverage in subprocesses.  A language feature that allowed me to externally configure the interpreter to run some of my code first would allow me to do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:11:29 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 16:11:29 +0000
Subject: [issue15475] Correct __sizeof__ support for itertools
In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>
Message-ID: <1343578289.19.0.758008212212.issue15475@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Patches updated on Meador's remarks. Tests updated to use new test.support helpers.

----------
Added file: http://bugs.python.org/file26576/itertools_sizeof-3.3-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15475>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:12:16 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 16:12:16 +0000
Subject: [issue15475] Correct __sizeof__ support for itertools
In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>
Message-ID: <1343578336.0.0.65400696576.issue15475@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26577/itertools_sizeof-3.2-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15475>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:12:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 16:12:45 +0000
Subject: [issue15475] Correct __sizeof__ support for itertools
In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>
Message-ID: <1343578365.17.0.690279727884.issue15475@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26578/itertools_sizeof-2.7-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15475>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:13:50 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 16:13:50 +0000
Subject: [issue15475] Correct __sizeof__ support for itertools
In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>
Message-ID: <1343578430.15.0.143689057323.issue15475@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry, on Martin's remarks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15475>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:18:05 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 16:18:05 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343578685.01.0.787516894062.issue15436@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

rhettinger: users frequently need sys.getsizeof. See, for example,

http://stackoverflow.com/questions/1331471/in-memory-size-of-python-stucture
http://stackoverflow.com/questions/449560/how-do-i-determine-the-size-of-an-object-in-python
http://stackoverflow.com/questions/2117255/python-deep-getsizeof-list-with-contents
http://stackoverflow.com/questions/11301295/measure-object-size-accurately-in-python-sys-getsizeof-not-functioning
[and so on]

In what cases, do you think, it generates meaningless results? I find the results for the shared-keys dictionary quite meaningful and natural.

sys.getsizeof is certainly CPython-specific. However, __sizeof__ is not just an implementation detail of sys.getsizeof, just as __len__ is not an implementation detail of len(). Authors of extension types are supposed to implement it if object.__sizeof__ is incorrect.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:30:55 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 29 Jul 2012 16:30:55 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
In-Reply-To: <1343567445.16.0.656305805275.issue15487@psf.upfronthosting.co.za>
Message-ID: <1343579455.17.0.11499995103.issue15487@psf.upfronthosting.co.za>


Meador Inge added the comment:

Serhiy, I didn't analyze it too in depth, but why aren't the test cases using the __sizeof__ support work you implemented for issue15467?  I think these tests should be using the more exact method like your other '__sizeof__' patches.

----------
nosy: +meador.inge
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:33:44 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 16:33:44 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
In-Reply-To: <1343573070.06.0.0824042831168.issue15487@psf.upfronthosting.co.za>
Message-ID: <201207291933.28399.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> Instead of putting this in MiscIOTest, you could use the relevant
> class-specific test cases.

Thank you, good advice. Here is updated patch.

----------
Added file: http://bugs.python.org/file26579/bufferedio_sizeof-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________
-------------- next part --------------
diff -r d43ff8eb4cb3 Lib/test/test_io.py
--- a/Lib/test/test_io.py	Sun Jul 29 16:38:45 2012 +0200
+++ b/Lib/test/test_io.py	Sun Jul 29 19:30:56 2012 +0300
@@ -802,6 +802,20 @@
             buf.raw = x
 
 
+class SizeofTest:
+
+    @support.cpython_only
+    def test_sizeof(self):
+        bufsize1 = 4096
+        bufsize2 = 8192
+        rawio = self.MockRawIO()
+        bufio = self.tp(rawio, buffer_size=bufsize1)
+        size = sys.getsizeof(bufio) - bufsize1
+        rawio = self.MockRawIO()
+        bufio = self.tp(rawio, buffer_size=bufsize2)
+        self.assertEqual(sys.getsizeof(bufio), size + bufsize2)
+
+
 class BufferedReaderTest(unittest.TestCase, CommonBufferedTests):
     read_mode = "rb"
 
@@ -999,7 +1013,7 @@
                              "failed for {}: {} != 0".format(n, rawio._extraneous_reads))
 
 
-class CBufferedReaderTest(BufferedReaderTest):
+class CBufferedReaderTest(BufferedReaderTest, SizeofTest):
     tp = io.BufferedReader
 
     def test_constructor(self):
@@ -1260,7 +1274,7 @@
             self.tp(self.MockRawIO(), 8, 12)
 
 
-class CBufferedWriterTest(BufferedWriterTest):
+class CBufferedWriterTest(BufferedWriterTest, SizeofTest):
     tp = io.BufferedWriter
 
     def test_constructor(self):
@@ -1650,7 +1664,7 @@
     # You can't construct a BufferedRandom over a non-seekable stream.
     test_unseekable = None
 
-class CBufferedRandomTest(BufferedRandomTest):
+class CBufferedRandomTest(BufferedRandomTest, SizeofTest):
     tp = io.BufferedRandom
 
     def test_constructor(self):
diff -r d43ff8eb4cb3 Modules/_io/bufferedio.c
--- a/Modules/_io/bufferedio.c	Sun Jul 29 16:38:45 2012 +0200
+++ b/Modules/_io/bufferedio.c	Sun Jul 29 19:30:56 2012 +0300
@@ -398,6 +398,17 @@
     Py_TYPE(self)->tp_free((PyObject *)self);
 }
 
+static PyObject *
+buffered_sizeof(buffered *self, void *unused)
+{
+    Py_ssize_t res;
+
+    res = sizeof(buffered);
+    if (self->buffer)
+        res += self->buffer_size;
+    return PyLong_FromSsize_t(res);
+}
+
 static int
 buffered_traverse(buffered *self, visitproc visit, void *arg)
 {
@@ -1699,6 +1710,7 @@
     {"seek", (PyCFunction)buffered_seek, METH_VARARGS},
     {"tell", (PyCFunction)buffered_tell, METH_NOARGS},
     {"truncate", (PyCFunction)buffered_truncate, METH_VARARGS},
+    {"__sizeof__", (PyCFunction)buffered_sizeof, METH_NOARGS},
     {NULL, NULL}
 };
 
@@ -2079,6 +2091,7 @@
     {"flush", (PyCFunction)buffered_flush, METH_NOARGS},
     {"seek", (PyCFunction)buffered_seek, METH_VARARGS},
     {"tell", (PyCFunction)buffered_tell, METH_NOARGS},
+    {"__sizeof__", (PyCFunction)buffered_sizeof, METH_NOARGS},
     {NULL, NULL}
 };
 
@@ -2470,6 +2483,7 @@
     {"readline", (PyCFunction)buffered_readline, METH_VARARGS},
     {"peek", (PyCFunction)buffered_peek, METH_VARARGS},
     {"write", (PyCFunction)bufferedwriter_write, METH_VARARGS},
+    {"__sizeof__", (PyCFunction)buffered_sizeof, METH_NOARGS},
     {NULL, NULL}
 };
 

From report at bugs.python.org  Sun Jul 29 18:35:16 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 29 Jul 2012 16:35:16 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343579716.12.0.264901429026.issue15486@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/issue15486>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:41:24 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 16:41:24 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343580084.9.0.440224123075.issue14803@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Okay, then in the interest of understanding why various alternatives fail, I'll just throw out the suggestion or question that I had in mind because I don't see it mentioned above or on the web page.

Why wouldn't it work to define an alias or script that invokes the desired "python -m ...", and then when you call your test suite (using a potentially different "-m ..."), you set sys.executable to that script so that subprocesses in your code under test will invoke it?  (coverage.py could do all of this under the hood so that the user need not be aware of it.)  Or would this work just fine, but that it's an example of the kind of hack that you're trying to avoid?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:50:53 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 16:50:53 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
In-Reply-To: <1343579455.17.0.11499995103.issue15487@psf.upfronthosting.co.za>
Message-ID: <201207291950.41219.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> Serhiy, I didn't analyze it too in depth, but why aren't the test cases
> using the __sizeof__ support work you implemented for issue15467?  I think
> these tests should be using the more exact method like your other
> '__sizeof__' patches.

Because struct has not codes for Py_off_t and PyThread_type_lock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:54:27 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 16:54:27 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343580867.37.0.929257316995.issue15403@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks for your thoughts.  For the purposes of this patch, I will change to putting the new support functionality in test.support.  Going forward, if we could do some of the refactoring for 3.3.1, that would be great. :)

I worry that the third option may make things worse because it would become less obvious where all of the different test support functionality is located.

Are you opposed to (2), or is it simply less favorable?  The transition to (2) could be a gradual one beginning with two or even one module inside the package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:56:14 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 16:56:14 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1343580867.37.0.929257316995.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343580837.3388.17.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Are you opposed to (2), or is it simply less favorable?

Less favorable, because it produces longer import strings
("test.support.some_helper" instead of "test.some_helper").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:57:21 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 16:57:21 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <1343578685.01.0.787516894062.issue15436@psf.upfronthosting.co.za>
Message-ID: <201207291957.09566.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> sys.getsizeof is certainly CPython-specific. However, __sizeof__ is not
> just an implementation detail of sys.getsizeof, just as __len__ is not an
> implementation detail of len(). Authors of extension types are supposed to
> implement it if object.__sizeof__ is incorrect.

I think there is one difference between __len__ and __sizeof__. __sizeof__ 
should be overloaded only for C-implemented classes. IMHO, it is a part of C 
API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:00:46 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 17:00:46 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343581246.85.0.895131856055.issue15403@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Less favorable, because it produces longer import strings
("test.support.some_helper" instead of "test.some_helper").

This can be addressed by exposing the API in __init__.py though (as does, say, the unittest package), no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:07:07 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 29 Jul 2012 17:07:07 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1343581627.79.0.906789148908.issue1692335@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Please reopen if you think it should be backported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:07:34 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jul 2012 17:07:34 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
In-Reply-To: <1343567445.16.0.656305805275.issue15487@psf.upfronthosting.co.za>
Message-ID: <3WlVhj1nFMzPTd@mail.python.org>


Roundup Robot added the comment:

New changeset 8a02a93c803a by Antoine Pitrou in branch '3.2':
Issue #15487: Add a __sizeof__ implementation for buffered I/O objects.
http://hg.python.org/cpython/rev/8a02a93c803a

New changeset 1d811e1097ed by Antoine Pitrou in branch 'default':
Issue #15487: Add a __sizeof__ implementation for buffered I/O objects.
http://hg.python.org/cpython/rev/1d811e1097ed

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:10:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 17:10:07 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1343581246.85.0.895131856055.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343581669.3388.18.camel@localhost.localdomain>


Antoine Pitrou added the comment:

Le dimanche 29 juillet 2012 ? 17:00 +0000, Chris Jerdonek a ?crit :
> Chris Jerdonek added the comment:
> 
> > Less favorable, because it produces longer import strings
> ("test.support.some_helper" instead of "test.some_helper").
> 
> This can be addressed by exposing the API in __init__.py though (as
> does, say, the unittest package), no?

Yes, that's right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:12:30 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jul 2012 17:12:30 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
In-Reply-To: <1343567445.16.0.656305805275.issue15487@psf.upfronthosting.co.za>
Message-ID: <3WlVpP1v1szPTd@mail.python.org>


Roundup Robot added the comment:

New changeset 1102e86b8739 by Antoine Pitrou in branch '2.7':
Issue #15487: Add a __sizeof__ implementation for buffered I/O objects.
http://hg.python.org/cpython/rev/1102e86b8739

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:13:37 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 17:13:37 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
In-Reply-To: <1343567445.16.0.656305805275.issue15487@psf.upfronthosting.co.za>
Message-ID: <1343582017.62.0.905749086476.issue15487@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks for the patch :)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:31:58 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 17:31:58 +0000
Subject: [issue15436] __sizeof__ is not documented
In-Reply-To: <201207291957.09566.storchaka@gmail.com>
Message-ID: <5015738C.9020105@v.loewis.de>


Martin v. L?wis added the comment:

> I think there is one difference between __len__ and __sizeof__. __sizeof__ 
> should be overloaded only for C-implemented classes. IMHO, it is a part of C 
> API.

That is a reasonable point. So documenting it along with the type slots
might be best.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15436>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:39:37 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 29 Jul 2012 17:39:37 +0000
Subject: [issue15452] Eliminate the use of eval() in the logging config
	implementation
In-Reply-To: <1343264495.49.0.0195201203683.issue15452@psf.upfronthosting.co.za>
Message-ID: <1343583577.75.0.0346960628807.issue15452@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

> As far as your other suggestion goes, don't reinvent crypto badly -
> if you want to provide authentication support in listener(), provide a
> hook that allows the application to decide whether or not to accept
> the configuration before it gets applied.

Well, that's fine. My earlier suggestion keeps the API change to a minimum, but I suppose there's no real need to be so minimal.

I suppose the basic approach would be to pass to listen() an optional verify callable (defaulting to None) which, if provided, would be called with the bytes received over the socket. That allows for e.g. signed or encrypted data. The value returned from the verify() call would be processed as the current received value is (allowing the verifier to transform the input, e.g. by decrypting it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15452>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:45:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 17:45:02 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343583902.3.0.0383860459487.issue15486@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

That said, given the nature of the patch (a cleanup without any functional impact), I don't think it should be a release blocker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:45:17 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 29 Jul 2012 17:45:17 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
In-Reply-To: <1343567445.16.0.656305805275.issue15487@psf.upfronthosting.co.za>
Message-ID: <1343583917.85.0.17564324275.issue15487@psf.upfronthosting.co.za>


Meador Inge added the comment:

On Sun, Jul 29, 2012 at 11:50 AM, Serhiy Storchaka <report at bugs.python.org> wrote:

>> Serhiy, I didn't analyze it too in depth, but why aren't the test cases
>> using the __sizeof__ support work you implemented for issue15467?  I think
>> these tests should be using the more exact method like your other
>> '__sizeof__' patches.
>
> Because struct has not codes for Py_off_t and PyThread_type_lock.

Of course it doesn't -- those are Python specific typedefs.  'PyThread_type_lock'
is just a typedef to 'void *' and something could be figured out for 'Py_off_t'
in the support code.

Anyway, the way you are implementing the tests has the same issue as Martin pointed
out for the 'object.__sizeof__' method in issue15402.  I could replace the 
'buffered_sizeof' implementation with:

   static PyObject *
   buffered_sizeof(buffered *self, void *unused)
   {
       Py_ssize_t res;

       res = 1;
       if (self->buffer)
           res += self->buffer_size;
       return PyLong_FromSsize_t(res);
   }

and the tests will still pass.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:55:10 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 17:55:10 +0000
Subject: [issue15487] Correct __sizeof__ support for buffered I/O
In-Reply-To: <1343583917.85.0.17564324275.issue15487@psf.upfronthosting.co.za>
Message-ID: <1343584372.3388.20.camel@localhost.localdomain>


Antoine Pitrou added the comment:

Le dimanche 29 juillet 2012 ? 17:45 +0000, Meador Inge a ?crit :
> Anyway, the way you are implementing the tests has the same issue as Martin pointed
> out for the 'object.__sizeof__' method in issue15402.  I could replace the 
> 'buffered_sizeof' implementation with:
> 
>    static PyObject *
>    buffered_sizeof(buffered *self, void *unused)
>    {
>        Py_ssize_t res;
> 
>        res = 1;
>        if (self->buffer)
>            res += self->buffer_size;
>        return PyLong_FromSsize_t(res);
>    }
> 
> and the tests will still pass.

That's true but, OTOH, I don't think it's very important. First, because
it is a rather unlikely mistake. Second, because the important thing is
to check that the internal buffer is part of the returned size, which is
what Serhiy's test checks for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15487>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:56:32 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 17:56:32 +0000
Subject: [issue15488] Closed files keep their buffer alive
Message-ID: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>>> f = open("LICENSE", "rb")
>>> sys.getsizeof(f)
4296
>>> f.close()
>>> sys.getsizeof(f)
4296

Instead of waiting for the file object's deallocation, perhaps we should free the buffer when it is closed?

----------
components: IO, Library (Lib)
messages: 166801
nosy: pitrou
priority: low
severity: normal
status: open
title: Closed files keep their buffer alive
type: resource usage
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15488>
_______________________________________

From report at bugs.python.org  Sun Jul 29 19:56:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 17:56:44 +0000
Subject: [issue15488] Closed files keep their buffer alive
In-Reply-To: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za>
Message-ID: <1343584604.76.0.0225406452207.issue15488@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson, hynek, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15488>
_______________________________________

From report at bugs.python.org  Sun Jul 29 20:04:58 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 29 Jul 2012 18:04:58 +0000
Subject: [issue15488] Closed files keep their buffer alive
In-Reply-To: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za>
Message-ID: <1343585098.3.0.82857434795.issue15488@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/issue15488>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:01:54 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Sun, 29 Jul 2012 19:01:54 +0000
Subject: [issue633930] Nested class __name__
Message-ID: <1343588514.14.0.968478570772.issue633930@psf.upfronthosting.co.za>


Stefan Mihaila added the comment:

Only an issue in Python2.

    >>> A.B.__qualname__
    'A.B'
    >>> repr(A.B)
    "<class '__main__.A.B'>"

----------
nosy: +mstefanro
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue633930>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:09:33 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 Jul 2012 19:09:33 +0000
Subject: [issue15451] PATH is not honored in subprocess.Popen in win32
In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>
Message-ID: <1343588973.14.0.0692320068902.issue15451@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

What I understand you two as saying is that there seems to be an undocumented difference in execxxe between unix and windows which has been carried over to subprocess. In particular, for both, the PATH component of the env parameter is used to search for the file on *nix but not on windows, even though this is not part of posix behavior. So reopening -- as a doc issue -- unless an os expert like Martin declares this to be a behavior bug.

Grissiom, can you verify that the difference still exists in 3.2/3?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, loewis
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15451>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:09:44 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 29 Jul 2012 19:09:44 +0000
Subject: [issue15488] Closed files keep their buffer alive
In-Reply-To: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za>
Message-ID: <1343588984.92.0.552638890623.issue15488@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Sounds reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15488>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:15:52 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 19:15:52 +0000
Subject: [issue15469] Correct __sizeof__ support for deque
In-Reply-To: <1343404078.66.0.00721941905437.issue15469@psf.upfronthosting.co.za>
Message-ID: <1343589352.53.0.457059729525.issue15469@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Patches updated. Now __sizeof__ is O(1) as Martin advised.

----------
Added file: http://bugs.python.org/file26580/deque_sizeof-3.3-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15469>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:16:19 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 19:16:19 +0000
Subject: [issue15469] Correct __sizeof__ support for deque
In-Reply-To: <1343404078.66.0.00721941905437.issue15469@psf.upfronthosting.co.za>
Message-ID: <1343589379.3.0.439033387761.issue15469@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26581/deque_sizeof-3.2-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15469>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:16:47 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 19:16:47 +0000
Subject: [issue15469] Correct __sizeof__ support for deque
In-Reply-To: <1343404078.66.0.00721941905437.issue15469@psf.upfronthosting.co.za>
Message-ID: <1343589407.91.0.379477733459.issue15469@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26582/deque_sizeof-2.7-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15469>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:48:07 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 19:48:07 +0000
Subject: [issue15489] Correct __sizeof__ support for BytesIO
Message-ID: <1343591287.44.0.516337828305.issue15489@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for C implementation of io.BytesIO.

----------
components: IO, Library (Lib)
files: bytesio_sizeof-3.3.patch
keywords: patch
messages: 166806
nosy: benjamin.peterson, hynek, pitrou, storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for BytesIO
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26583/bytesio_sizeof-3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15489>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:48:37 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 19:48:37 +0000
Subject: [issue15489] Correct __sizeof__ support for BytesIO
In-Reply-To: <1343591287.44.0.516337828305.issue15489@psf.upfronthosting.co.za>
Message-ID: <1343591317.61.0.971702606215.issue15489@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26584/bytesio_sizeof-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15489>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:48:56 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 19:48:56 +0000
Subject: [issue15489] Correct __sizeof__ support for BytesIO
In-Reply-To: <1343591287.44.0.516337828305.issue15489@psf.upfronthosting.co.za>
Message-ID: <1343591336.88.0.1239113889.issue15489@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26585/bytesio_sizeof-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15489>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:53:37 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 19:53:37 +0000
Subject: [issue15490] Correct __sizeof__ support for StringIO
Message-ID: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for C implementation of io.StringIO.

I haven't tested the patch on narrow build.

----------
components: IO, Library (Lib)
files: stringio_sizeof-3.3.patch
keywords: patch
messages: 166807
nosy: benjamin.peterson, hynek, pitrou, storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for StringIO
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26586/stringio_sizeof-3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15490>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:53:55 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 19:53:55 +0000
Subject: [issue15490] Correct __sizeof__ support for StringIO
In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za>
Message-ID: <1343591635.7.0.97057970745.issue15490@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26587/stringio_sizeof-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15490>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:54:18 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 19:54:18 +0000
Subject: [issue15490] Correct __sizeof__ support for StringIO
In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za>
Message-ID: <1343591658.54.0.0929082185839.issue15490@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26588/stringio_sizeof-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15490>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:58:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 19:58:29 +0000
Subject: [issue15490] Correct __sizeof__ support for StringIO
In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za>
Message-ID: <1343591771.3388.22.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Here is a patch that implements correct __sizeof__ for C implementation of io.StringIO.

For some value of "correct", since the internal accumulator could hold
alive some unicode strings.

> I haven't tested the patch on narrow build.

There's no narrow build anymore on 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15490>
_______________________________________

From report at bugs.python.org  Sun Jul 29 21:58:42 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 19:58:42 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1343591921.99.0.218261126776.issue1859@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

In working on the patch for this issue, I also noticed that there is a minor error in the documentation of the replace_whitespace attribute.

The docs say that string.whitespace is used, but the code uses a hard-coded string and includes a comment explaining why string.whitespace should *not* be used.

http://hg.python.org/cpython/file/1102e86b8739/Lib/textwrap.py#l30

I will correct this in the patch, but if people think so, I could file it as a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sun Jul 29 22:17:08 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 20:17:08 +0000
Subject: [issue15491] hg.python.org/cpython "browse" link defaults to 2.7
Message-ID: <1343593028.62.0.462659118728.issue15491@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

I'm not sure if I'm filing this in the right place since I don't see hg.python.org in the tracker "components" list, but if one clicks on the "Browse online" link of the Dev Guide here:

http://docs.python.org/devguide/

One is taken to--

http://hg.python.org/cpython/

(which is actually the list of revisions rather than the browser).

But if one then clicks on the "browse" link in the left column, it seems to default to the 2.7 branch.

It is a bit confusing because the browser does not say the name of the branch at the top, which can lead to unknowingly browsing the wrong branch.

So there may be three issues here: (1) the Dev Guide links to the revision list rather than directly to the browser, (2) browsing defaults to browsing 2.7 rather than the default branch, and (3) the branch name should be diplayed somewhere on the page when browsing (or better yet, also in the URL itself).

----------
messages: 166810
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: hg.python.org/cpython "browse" link defaults to 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15491>
_______________________________________

From report at bugs.python.org  Sun Jul 29 22:23:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 20:23:56 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1343593436.89.0.574830096959.issue1859@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Sorry, that link should have been--

http://hg.python.org/cpython/file/1d811e1097ed/Lib/textwrap.py#l12

(hg.python.org seems to default to the 2.7 branch.  I just filed an issue about this.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sun Jul 29 22:54:42 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 20:54:42 +0000
Subject: [issue15490] Correct __sizeof__ support for StringIO
In-Reply-To: <1343591771.3388.22.camel@localhost.localdomain>
Message-ID: <201207292354.28240.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> For some value of "correct", since the internal accumulator could hold
> alive some unicode strings.

This is not a concern of __sizeof__, because these lists and strings are 
managed by GC.

> There's no narrow build anymore on 3.3.

I mean 2.7 and 3.2. I have written test for such case, but can't check if it 
correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15490>
_______________________________________

From report at bugs.python.org  Sun Jul 29 23:04:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 21:04:07 +0000
Subject: [issue15490] Correct __sizeof__ support for StringIO
In-Reply-To: <201207292354.28240.storchaka@gmail.com>
Message-ID: <1343595708.3388.23.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> > For some value of "correct", since the internal accumulator could hold
> > alive some unicode strings.
> 
> This is not a concern of __sizeof__, because these lists and strings are 
> managed by GC.

It is, since they are private and not known by the user.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15490>
_______________________________________

From report at bugs.python.org  Sun Jul 29 23:11:23 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 21:11:23 +0000
Subject: [issue15490] Correct __sizeof__ support for StringIO
In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za>
Message-ID: <1343596283.29.0.179804216706.issue15490@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

The question really is what memory blocks can "leak out" of the object, and those don't really belong to the container. Those shouldn't be accounted for, since somebody else may get hold of them, and pass them to sys.sizeof.

For the PyAccu, AFAICT, objects cannot leak out of it (except for gc.getobjects in debug mode). So I think the memory allocated by the accu really belongs to the StringIO, and needs to be accounted there. The same goes for readnl, writenl, and weakreflist.

On a related note, I wonder why the tp_clear and tp_traverse functions for stringio are so short. Shouldn't it also visit "decoder"?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15490>
_______________________________________

From report at bugs.python.org  Sun Jul 29 23:11:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 21:11:57 +0000
Subject: [issue15492] textwrap.wrap expand_tabs does not behave as expected
Message-ID: <1343596317.09.0.0346303694102.issue15492@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

While working on issue 1859, I noticed that textwrap.wrap()'s tab expansion does not seem to behave sensibly.

In particular, the documentation says, "If expand_tabs is true, then all tab characters in text will be expanded to zero or more spaces, *depending on the current column* and the given tab size."

The problem is that tab expansion is done as the first stage (and in particular, before wrapping), which means that "the current column" is no longer current after wrapping.  This leads to results like--

from textwrap import wrap

text = ("a\tb "
        "a\tb")

lines = wrap(text, width=5, tabsize=4)
for line in lines:
    print(repr(line))

Output:
'a   b'
'a b'

One would expect tab expansion to occur after (or while) wrapping, so that tab stops line up in the wrapped output.

----------
messages: 166815
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: textwrap.wrap expand_tabs does not behave as expected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15492>
_______________________________________

From report at bugs.python.org  Sun Jul 29 23:15:21 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 21:15:21 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1343596521.35.0.119663969053.issue1859@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

If people are interested, I filed a new issue (issue 15492) about textwrap's tab expansion that I noticed while working on this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sun Jul 29 23:51:12 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Jul 2012 21:51:12 +0000
Subject: [issue15451] PATH is not honored in subprocess.Popen in win32
In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>
Message-ID: <1343598672.49.0.465838337108.issue15451@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> What I understand you two as saying is that there seems to be an 
> undocumented difference in execxxe between unix and windows which has been 
> carried over to subprocess.

No.  There is no difference between the platforms in the behaviour of os.execvpe().  os.execvpe() is simply implemented by trying execve() with a list of candidate executable paths until one of them works -- see _execvpe() in os.py.

Whether this difference from the behaviour of Posix's execvpe() was deliberate, I don't know.

The difference between the platforms in Python 2.x is caused by the fact that subprocess uses os.execvpe() on Unix and CreateProcess() on Windows.

In Python 3.x, os.execvpe() is no longer used on Unix, but the old behaviour has been deliberately maintained.  So the difference in behaviour is still present in Python 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15451>
_______________________________________

From report at bugs.python.org  Sun Jul 29 23:59:38 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 Jul 2012 21:59:38 +0000
Subject: [issue15421] Calendar.itermonthdates OverflowError
In-Reply-To: <1342967144.9.0.843108675207.issue15421@psf.upfronthosting.co.za>
Message-ID: <1343599178.23.0.858661084017.issue15421@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +belopolsky, ezio.melotti, rhettinger
stage:  -> patch review
type: enhancement -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15421>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:07:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jul 2012 22:07:14 +0000
Subject: [issue15489] Correct __sizeof__ support for BytesIO
In-Reply-To: <1343591287.44.0.516337828305.issue15489@psf.upfronthosting.co.za>
Message-ID: <3WldLS10BrzPS9@mail.python.org>


Roundup Robot added the comment:

New changeset 1d3155750808 by Antoine Pitrou in branch '3.2':
Issue #15489: Add a __sizeof__ implementation for BytesIO objects.
http://hg.python.org/cpython/rev/1d3155750808

New changeset 917295aaad76 by Antoine Pitrou in branch 'default':
Issue #15489: Add a __sizeof__ implementation for BytesIO objects.
http://hg.python.org/cpython/rev/917295aaad76

New changeset e8851809ae83 by Antoine Pitrou in branch '2.7':
Issue #15489: Add a __sizeof__ implementation for BytesIO objects.
http://hg.python.org/cpython/rev/e8851809ae83

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15489>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:07:43 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 22:07:43 +0000
Subject: [issue15489] Correct __sizeof__ support for BytesIO
In-Reply-To: <1343591287.44.0.516337828305.issue15489@psf.upfronthosting.co.za>
Message-ID: <1343599663.3.0.441104876968.issue15489@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15489>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:10:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jul 2012 22:10:16 +0000
Subject: [issue15491] hg.python.org/cpython "browse" link defaults to 2.7
In-Reply-To: <1343593028.62.0.462659118728.issue15491@psf.upfronthosting.co.za>
Message-ID: <3WldPz1KVHzPNr@mail.python.org>


Roundup Robot added the comment:

New changeset 0529e2062ec7 by Ezio Melotti in branch 'default':
#15491: link to the file list of the "default" branch.
http://hg.python.org/devguide/rev/0529e2062ec7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15491>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:11:49 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 22:11:49 +0000
Subject: [issue15491] hg.python.org/cpython "browse" link defaults to 2.7
In-Reply-To: <1343593028.62.0.462659118728.issue15491@psf.upfronthosting.co.za>
Message-ID: <1343599909.11.0.035047671995.issue15491@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The "snapshot of py3k" link has the same issue.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15491>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:13:09 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 22:13:09 +0000
Subject: [issue15493] No more Daily OS X installers
Message-ID: <1343599989.22.0.189482939769.issue15493@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The "Daily OS X installer" link in the devguide points to an empty directory (http://www.python.org/dev/daily-dmg/).

----------
components: Devguide
messages: 166822
nosy: ezio.melotti, ned.deily, pitrou, ronaldoussoren
priority: low
severity: normal
status: open
title: No more Daily OS X installers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15493>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:22:57 2012
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 Jul 2012 22:22:57 +0000
Subject: [issue15493] No more Daily OS X installers
In-Reply-To: <1343599989.22.0.189482939769.issue15493@psf.upfronthosting.co.za>
Message-ID: <1343600577.38.0.803601655207.issue15493@psf.upfronthosting.co.za>


Ned Deily added the comment:

It looks like the buildbot is still building them:
http://buildbot.python.org/all/buildslaves/bolen-dmg

I'm not sure who set up the web site link.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15493>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:23:15 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jul 2012 22:23:15 +0000
Subject: [issue15491] hg.python.org/cpython "browse" link defaults to 2.7
In-Reply-To: <1343593028.62.0.462659118728.issue15491@psf.upfronthosting.co.za>
Message-ID: <3Wldhx6VkZzPRd@mail.python.org>


Roundup Robot added the comment:

New changeset 54ec1b493006 by Ezio Melotti in branch 'default':
#15491: change a couple more links to point to the "default" branch.
http://hg.python.org/devguide/rev/54ec1b493006

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15491>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:23:57 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 Jul 2012 22:23:57 +0000
Subject: [issue15491] hg.python.org/cpython "browse" link defaults to 2.7
In-Reply-To: <1343593028.62.0.462659118728.issue15491@psf.upfronthosting.co.za>
Message-ID: <1343600637.93.0.887241887406.issue15491@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> So there may be three issues here:
> (1) the Dev Guide links to the revision list rather than directly
> to the browser,

This is now fixed.

> (2) browsing defaults to browsing 2.7 rather than the default branch,

This is fixed as well.  FTR it's not defaulting to 2.7, it just uses the branch of the latest commit, and when you checked it happened to be 2.7.

> (3) the branch name should be diplayed somewhere on the page when 
> browsing (or better yet, also in the URL itself).

This seems to be a bug in hgweb, and you should report it upstream.
In http://hg.python.org/cpython/rev/e8851809ae83 you can see at the top, next to the csid, the branch name and the 'tip' tag.
In http://hg.python.org/cpython/file/e8851809ae83 only the 'tip' tag is shown.
I don't know if the omission of the branch is intentional, but it seems reasonable to me to have it in the "browse" page too.

----------
assignee:  -> ezio.melotti
components: +Devguide
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15491>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:28:45 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 22:28:45 +0000
Subject: [issue15493] No more Daily OS X installers
In-Reply-To: <1343600577.38.0.803601655207.issue15493@psf.upfronthosting.co.za>
Message-ID: <1343600787.3388.24.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> It looks like the buildbot is still building them:
> http://buildbot.python.org/all/buildslaves/bolen-dmg
> 
> I'm not sure who set up the web site link.

The upload directory is wrong in the buildmaster configuration, I'm
trying to fix that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15493>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:33:39 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 22:33:39 +0000
Subject: [issue15493] No more Daily OS X installers
In-Reply-To: <1343599989.22.0.189482939769.issue15493@psf.upfronthosting.co.za>
Message-ID: <1343601219.93.0.0944705169338.issue15493@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

> I'm not sure who set up the web site link.

The current version of that link comes from Antoine Pitrou; I believe I put the original version on the website (before Brett moved it into the devguide).

The DMG uploading really can't work anymore since buildbot become its own system. In addition, the directory to upload to was not there on the machine, so all uploading failed.

I have now created the upload directory, let's see whether it fills (and no, it's still not on dinsdale).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15493>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:38:40 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 22:38:40 +0000
Subject: [issue15493] No more Daily OS X installers
In-Reply-To: <1343601219.93.0.0944705169338.issue15493@psf.upfronthosting.co.za>
Message-ID: <1343601382.3388.25.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> I have now created the upload directory, let's see whether it fills
> (and no, it's still not on dinsdale).

No need to create it, I've already pointer the master.cfg to another
directory (/data/www/buildbot/daily-dmg).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15493>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:42:59 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 22:42:59 +0000
Subject: [issue15493] No more Daily OS X installers
In-Reply-To: <1343601382.3388.25.camel@localhost.localdomain>
Message-ID: <20120730004257.Horde.a_OGO0lCcOxQFbxx58pz16A@webmail.df.eu>


Martin v. L?wis added the comment:

> No need to create it, I've already pointer the master.cfg to another
> directory (/data/www/buildbot/daily-dmg).

And indeed, that's the directory that I have just created. I also had
it put into the master.cfg, but you apparently overwrote my edit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15493>
_______________________________________

From report at bugs.python.org  Mon Jul 30 00:47:12 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 22:47:12 +0000
Subject: [issue15493] No more Daily OS X installers
In-Reply-To: <1343599989.22.0.189482939769.issue15493@psf.upfronthosting.co.za>
Message-ID: <1343602032.14.0.611375064831.issue15493@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Actually, I had created a different directory.

I wish you had said from the beginning that you were going to look into it; it would have saved me some time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15493>
_______________________________________

From report at bugs.python.org  Mon Jul 30 01:01:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 23:01:30 +0000
Subject: [issue15493] No more Daily OS X installers
In-Reply-To: <1343599989.22.0.189482939769.issue15493@psf.upfronthosting.co.za>
Message-ID: <1343602890.53.0.745714098163.issue15493@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well, I said it ("The upload directory is wrong in the buildmaster configuration, I'm trying to fix that"), but perhaps it was too late.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15493>
_______________________________________

From report at bugs.python.org  Mon Jul 30 01:03:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jul 2012 23:03:14 +0000
Subject: [issue15493] No more Daily OS X installers
In-Reply-To: <1343599989.22.0.189482939769.issue15493@psf.upfronthosting.co.za>
Message-ID: <3Wlfb53Y6tzPW8@mail.python.org>


Roundup Robot added the comment:

New changeset 89d9874dfd13 by Antoine Pitrou in branch 'default':
Closes #15493: fix link to daily DMG installer
http://hg.python.org/devguide/rev/89d9874dfd13

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15493>
_______________________________________

From report at bugs.python.org  Mon Jul 30 01:03:50 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 23:03:50 +0000
Subject: [issue15493] No more Daily OS X installers
In-Reply-To: <1343602890.53.0.745714098163.issue15493@psf.upfronthosting.co.za>
Message-ID: <20120730010349.Horde.0U5RMElCcOxQFcFVqcTD8dA@webmail.df.eu>


Martin v. L?wis added the comment:

> Well, I said it ("The upload directory is wrong in the buildmaster  
> configuration, I'm trying to fix that"), but perhaps it was too late.

Yes, tough luck.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15493>
_______________________________________

From report at bugs.python.org  Mon Jul 30 01:08:01 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 29 Jul 2012 23:08:01 +0000
Subject: [issue14973] restore python2 unicode literals in "ur" strings
In-Reply-To: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za>
Message-ID: <1343603281.19.0.799318303198.issue14973@psf.upfronthosting.co.za>


Christian Heimes added the comment:

As of #15096 I've closed this bug as "won't fix".

----------
nosy: +christian.heimes
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14973>
_______________________________________

From report at bugs.python.org  Mon Jul 30 01:19:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 23:19:18 +0000
Subject: [issue15491] hg.python.org/cpython "browse" link defaults to 2.7
In-Reply-To: <1343593028.62.0.462659118728.issue15491@psf.upfronthosting.co.za>
Message-ID: <1343603958.0.0.415696078702.issue15491@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> > (3) the branch name should be diplayed somewhere on the page when 
> > browsing (or better yet, also in the URL itself).
>
> This seems to be a bug in hgweb, and you should report it upstream.

I filed an issue for this upstream as you suggested:

http://bz.selenic.com/show_bug.cgi?id=3559

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15491>
_______________________________________

From report at bugs.python.org  Mon Jul 30 01:33:41 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 29 Jul 2012 23:33:41 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1343542183.14.0.0311024413828.issue15295@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W4R4awxx20ENNuWW4M+F=U3G+C41PoW42rYvKC3yy_d=w@mail.gmail.com>


Brett Cannon added the comment:

On Jul 29, 2012 2:09 AM, "Nick Coghlan" <report at bugs.python.org> wrote:
>
>
> Nick Coghlan added the comment:
>
> General comment:
>
> runpy, pkgutil, et al should all get "See Also" links at the top pointing
to the new import system section.
>
> Import system intro:
>
> As noted above, I suggest changing the name :)
>
> Opening section should refer to importlib.import_module(). Any mentions
of __import__ should point out that its API is designed for the convenience
of the interpreter, and thus it's a pain to use directly. However, we
should also document explicitly that, unlike the import statement and
calling __import__ directly, importlib.import_module will ignore any module
level replacements of __import__.
>
> Replacing builtins.__import__ won't reliably override the entire import
system (due to module level __import__ definitions, most notably
importlib.__import__) and other tools that work with the process global
import state directly (e.g. pkgutil, runpy).
>
> 5.1 Packages:
>
> Don't tease readers, just tell them: the defining characteristic of a
package is that it is a module object with a __path__ attribute.
>
> Since we have the privilege of defining *the* standard terminology for
old-style packages, I suggest we use the term "initialised" packages (since
having an __init__.py is what makes them special). We should also note
explicitly that an initialised package can also behave as a namespace
package, by setting __path__ appropriately in __init__.py
>
> Also, I suggest adding a 5.1.3 Package Example subheading - currently you
define an initialised package under the namespace package heading
>
> Finally, I think this section needs to explicitly define the terms
*import path* and *path entry*. The meta path docs later refer to
find_module() accepting a module name and path, and the reader could be
forgiven for thinking that meant a filesystem path, when it is actually an
import path (which is a sequence of path entries, which may themselves by
filesystem paths).
>
> 5.2.2 Finders and loaders:
>
> The term "sys path finder" is incorrect as registered path hooks are
invoked for both sys.path entries *and* package __path__ entries. I suggest
"path entry finder". (I agree a longer name is needed to better distinguish
them from metapath finders)
>
> 5.2.3 Import hooks:
>
> While it does get cleared up in 5.2.4, this section could be clearer that
the hooks *cannot* override the initial check of the module cache.
>
> 5.3.4 Metapath:
>
> See above comment about clarifying that an import path is passed to
find_module() rather than a filesystem path.
>
> The description of the path importer is incorrect. It only knows how to
scan an import path and interrogate the path hooks. It's the individual
path entry finders that know how to do things like load modules from the
filesystem or zip files.
>
>
> 5.2.5 Meta path loaders
>
> I don't like the title here. There's no such thing as a meta path loader.
there are only module loaders. Once they're created, it doesn't matter how
you found them.
>
> Clarify that the loader only has to remove the modules it inserted
itself. Other modules that were loaded *successfully* as a side effect of
the code execution will remain in the cache.
>
> 5.3 The Path Importer
>
> As noted above, the path importer is *NOT* restricted to filesystem
imports. All it cares about is arbitrary text sequences and path hooks.
With the right path hook, you could use URLs or database connection strings
as path entries.
>

Just so this doesn't get lost and in case it is important enough to block
on: it might be worth having separate ABCs for meta path finders and the
finders pathfinder uses since they have different APIs now (if one ignores
find_module for pathfinder finders). Just need to come up with names.

-brett

> 5.5 References
>
> I'd also point to PEP 328 (absolute imports by default and explicit
relative import syntax) and PEP 338 (using the import system to find
__main__)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue15295>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Mon Jul 30 02:10:24 2012
From: report at bugs.python.org (=?utf-8?q?Thi=C3=A9baud_Weksteen?=)
Date: Mon, 30 Jul 2012 00:10:24 +0000
Subject: [issue15464] ssl: add set_msg_callback function
In-Reply-To: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za>
Message-ID: <1343607024.45.0.49951549418.issue15464@psf.upfronthosting.co.za>


Thi?baud Weksteen added the comment:

I've updated the patch with this method of testing.

----------
Added file: http://bugs.python.org/file26589/ssl_msg_callback-0.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15464>
_______________________________________

From report at bugs.python.org  Mon Jul 30 02:11:05 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Jul 2012 00:11:05 +0000
Subject: [issue15473] importlib no longer uses imp.NullImporter
In-Reply-To: <1343535686.75.0.782793865083.issue15473@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W6z6aUMjTUwAZ+7O9eyNb5sTj0Sgyq8CJWnGmK8_HzWqg@mail.gmail.com>


Brett Cannon added the comment:

On Jul 29, 2012 12:21 AM, "Nick Coghlan" <report at bugs.python.org> wrote:
>
>
> Nick Coghlan added the comment:
>
> See the porting notes:
http://docs.python.org/dev/whatsnew/3.3.html#porting-python-code
>
> With the removal of the implicit default finder, the 3.3 semantics are
that both None *and* imp.NullImporter mean "There is no importer for this
path".

What Nick said is true, but for docs it's too broad a statement. Since
nullimporter inherently never finds anything it acts like there is no
importer. But the new behaviour is the use of None to represent that which
is the official semantics now.

-brett

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue15473>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15473>
_______________________________________

From report at bugs.python.org  Mon Jul 30 02:13:08 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Jul 2012 00:13:08 +0000
Subject: [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343555924.3.0.235800550091.issue15482@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W7NSvoEHw5V9xUu+XULEhZwo8ZPhGy3minW+5=ngFPvGQ@mail.gmail.com>


Brett Cannon added the comment:

On Jul 29, 2012 5:58 AM, "Martin v. L?wis" <report at bugs.python.org> wrote:
>
>
> Martin v. L?wis added the comment:
>
> So should 3.2 be changed to adjust the default value to match the
documentation?

It is probably safe to do so.

-brett

>
> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue15482>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15482>
_______________________________________

From report at bugs.python.org  Mon Jul 30 02:38:24 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 00:38:24 +0000
Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous()
	incorrect for non-contiguous arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343608704.26.0.651453151961.issue12834@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I suspect the need to preserve the C ABI would make a complete backport a challenge. I'm still tempted though, mainly to give third parties a robust core implementation of the buffer API to test against.

This is especially so with Python 2.7 still having a couple of years of full maintenance left - that's a long time to leave it with a known broken memoryview implementation. I'm less worried about 3.2, since the upgrade path to 3.3 is easier in that case, but even that version is likely to see widespread use for a long time.

----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Mon Jul 30 02:55:39 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 00:55:39 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343609739.76.0.773165348432.issue14803@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

There are two different use cases here. "-C" tackles one of them, "PYTHONRUNFIRST" the other.

My original use case came from working on the Python test suite. In that suite, we have "test.script_helper" which spawns Python subprocesses in order to test various aspects of the startup machinery. I can easily modify script_helper to pass an extra -C argument when gathering coverage data, so I don't need any implicit magic.

The -C option also simplifies a whole host of things by letting you use the Python API to perform preconfiguration of various subsystems before executing __main__ normally rather than having to either write a custom launch script (difficult to do with full generality) or adding even more arcane command line options.

However, the -C option doesn't cover the case of *implicit* invocation of subprocesses. This is where the PYTHONRUNFIRST suggestion comes in - the idea would that, unless -E is specified, then -C $PYTHONRUNFIRST would be implied.

To be honest, I *don't* think this latter capability should be built into the core implementation. Instead, I think it is more appropriate for it to be handled at a virtual environment level, so that it doesn't inadvertently affect invocation of other applications (like hg) that merely happen to be written in Python. Scoping it to a venv would also lessen many of my security concerns with the idea. A simple way to do this would be if pyvenv.cfg could contain a customisation snippet that was executed prior to __main__ invocation (building off the -C machinery)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:02:57 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Jul 2012 01:02:57 +0000
Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous()
	incorrect for non-contiguous arrays
In-Reply-To: <1343608704.26.0.651453151961.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343610038.3388.26.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> This is especially so with Python 2.7 still having a couple of years
> of full maintenance left - that's a long time to leave it with a known
> broken memoryview implementation. I'm less worried about 3.2, since
> the upgrade path to 3.3 is easier in that case, but even that version
> is likely to see widespread use for a long time.

Well, there's a reason we don't backport features to bugfix branches,
especially when we're talking about a complete rewrite of the
implementation.  So I really don't agree this should be backported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:06:19 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Jul 2012 01:06:19 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1343609739.76.0.773165348432.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343610240.3388.29.camel@localhost.localdomain>


Antoine Pitrou added the comment:

Le lundi 30 juillet 2012 ? 00:55 +0000, Nick Coghlan a ?crit :
> However, the -C option doesn't cover the case of *implicit* invocation
> of subprocesses. This is where the PYTHONRUNFIRST suggestion comes in
> - the idea would that, unless -E is specified, then -C $PYTHONRUNFIRST
> would be implied.
> 
> To be honest, I *don't* think this latter capability should be built
> into the core implementation. Instead, I think it is more appropriate
> for it to be handled at a virtual environment level, so that it
> doesn't inadvertently affect invocation of other applications (like
> hg) that merely happen to be written in Python.

Well, it shouldn't if you don't start doing "export PYTHONRUNFIRST=...",
but instead set it from the calling Python process (possibly from
coverage itself).

Having to create virtual environments and whatnot just to enjoy this
feature sounds terribly tedious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:19:02 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 01:19:02 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343611142.98.0.990950803278.issue15403@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Discoverability is definitely a problem - part of that is a docs issue, since test.support is currently the only one mentioned in the prose docs.

One advantage to moving to a support subpackage is that we can lose the "helper" suffix from the names, while still allowing thematic divisions.

So, for example, we could have

# support.py -> support/__init__.py
import test.support
# script_helper.py -> support/scripts.py
import test.support.scripts
# Other possible additions
import test.support.imports
import test.support.network

Even without updating the prose docs, this would help discoverability a lot by having a much smaller directory listing to scan for useful support code. At the moment the general purpose helper modules are mixed in with the tests

I agree with Antoine that we're probably better off handling this as a refactor post-release at this point, though. I'd hoped to have the time to devote to it beforehand, but there's user facing stuff that's higher priority right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:22:32 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 01:22:32 +0000
Subject: [issue15452] Improve the security model for logging listener()
In-Reply-To: <1343264495.49.0.0195201203683.issue15452@psf.upfronthosting.co.za>
Message-ID: <1343611352.41.0.00758009559225.issue15452@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yep, that's exactly the kind of hook I had in mind. That way the user can decide for themselves what level of scrutiny they want to apply.

----------
title: Eliminate the use of eval() in the logging config implementation -> Improve the security model for logging listener()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15452>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:28:13 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 01:28:13 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343611693.5.0.658620582148.issue15486@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The "release blocker" status comes from the test case I added in order to demonstrate the ability to strip a new frame sequence without needing to modify the C code.

Currently that test (failing to write the PYC file) fails with an IsADirectory traceback that includes a lot of importlib frames.

There are two possible solutions:
- redirect the affected call through "_call_with_frames_removed" but otherwise leave the failure intact
- change it so this particular case isn't a fatal error

I need to check if failing to write the .pyc was a fatal error in 3.2 before I decide how to fix it (unless someone else remembers off the top of their head)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:33:09 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 01:33:09 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343611989.38.0.437547098496.issue15403@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Sounds good.  Later today I will create an issue to move test/support.py into a test.support subpackage post-release.

We can continue the discussion of how to organize it there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:37:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 01:37:11 +0000
Subject: [issue15494] Move test/support.py into a test.support subpackage
Message-ID: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to move test/support.py into a test.support subpackage as discussed in issue 15403.

This can be done post-release.

----------
components: Tests
messages: 166848
nosy: cjerdonek, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Move test/support.py into a test.support subpackage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15494>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:40:49 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 01:40:49 +0000
Subject: [issue15494] Move test/support.py into a test.support subpackage
In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>
Message-ID: <1343612449.47.0.119568775339.issue15494@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

If people are okay with populating test/support/__init__.py with code (at least initially), the first patch could be to move support.py into test/support/__init__.py.  One nice thing about this approach is that the calling code won't need to change. 

The second patch could be to move test/script_helper.py into the package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15494>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:42:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 01:42:38 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343612558.41.0.827201156476.issue15403@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Later today I will create an issue to move test/support.py into a test.support subpackage post-release.

I created issue 15494 for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:49:50 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 30 Jul 2012 01:49:50 +0000
Subject: [issue15495] enable type truncation warnings for gcc builds
Message-ID: <1343612990.44.0.366704900621.issue15495@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

It would seem that enabling GCC's type conversion/truncation warnings would be a good thing for Python builds.

This would bring GCC builds in line with MSVC builds and reduce the burden on the Windows developers in fixing them.  Also, it would bring attention to those issues by the developer who writes code and would hopefully understand the truncation issues at hand.

The CFLAGS required for this are '-Wconversion -Wno-sign-conversion'.

I unfortunately do not know the autoconf foo needed to implement this suggestion, however.  Perhaps it should only be enabled for debug builds as well to eliminate excess noise for other builds.  Or at least enabled on some of the buildbots.

----------
components: Build
messages: 166851
nosy: jkloth
priority: normal
severity: normal
status: open
title: enable type truncation warnings for gcc builds
type: enhancement
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15495>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:51:52 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Jul 2012 01:51:52 +0000
Subject: [issue15495] enable type truncation warnings for gcc builds
In-Reply-To: <1343612990.44.0.366704900621.issue15495@psf.upfronthosting.co.za>
Message-ID: <1343613112.93.0.543565122524.issue15495@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15495>
_______________________________________

From report at bugs.python.org  Mon Jul 30 03:53:47 2012
From: report at bugs.python.org (Chris Calloway)
Date: Mon, 30 Jul 2012 01:53:47 +0000
Subject: [issue15454] Allow dircmp.report() output stream to be customized
In-Reply-To: <1343288932.25.0.229744443043.issue15454@psf.upfronthosting.co.za>
Message-ID: <1343613227.97.0.342547222236.issue15454@psf.upfronthosting.co.za>


Changes by Chris Calloway <cbc at chriscalloway.org>:


----------
nosy: +cbc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15454>
_______________________________________

From report at bugs.python.org  Mon Jul 30 04:12:58 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 30 Jul 2012 02:12:58 +0000
Subject: [issue15494] Move test/support.py into a test.support subpackage
In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>
Message-ID: <1343614378.11.0.900705747024.issue15494@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I'd prefer to keep test.support as a single module, rather than converting it to a package.
Most of the time I open up test.support when I'm trying to find some function, so having more files will only make this more complicated.

----------
nosy: +ezio.melotti
type:  -> enhancement
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15494>
_______________________________________

From report at bugs.python.org  Mon Jul 30 04:14:56 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 30 Jul 2012 02:14:56 +0000
Subject: [issue15496] harden directory removal for tests on Windows
Message-ID: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

Currently, removing directories during testing on Windows w/NTFS can causing sporadic failures due to access denied errors.  This is caused by other processes getting a handle to the directory itself (change notifications) or a handle to a file within the directory.  The most notable offender is the Indexing Service.

Most (but not all!) external programs can be configured to ignore the development directory.  For example, the Indexing Service can be disabled or have those directories ignored.  TortoiseSVN is another offender that can exclude directories but each directory needs to be listed separately so it is easy to forgot one.  On my machine I have programs that simply do not have an option to ignore any directories thus causing some grief during testing.

The attached patch to test.support eliminates the need to disable or and ignores to any programs (tested on a Win7-x64 i7-3770K at 4.3GHz).

It achieves this by checking for the removal of the directory before returning to the caller.  It performs an exponential backoff timeout loop that amounts to a total of ~1 second in the worst case.  If the directory is not removed from the filesystem by then, it will probably be in error anyway.  However, the loop is seldom executed more than once.

----------
components: Tests
files: support.diff
keywords: patch
messages: 166853
nosy: jkloth
priority: normal
severity: normal
status: open
title: harden directory removal for tests on Windows
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26590/support.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15496>
_______________________________________

From report at bugs.python.org  Mon Jul 30 04:44:05 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 02:44:05 +0000
Subject: [issue15494] Move test/support.py into a test.support subpackage
In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>
Message-ID: <1343616245.81.0.527970943091.issue15494@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Note that I don't think test.support itself should be broken up - I don't see any good reason to split the current grab bag of functionality out into submodules, so you'd just have support/__init__.py open instead.

This is really about giving us a better way to organise the *other* helper modules like script_helper and make them easier to find.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15494>
_______________________________________

From report at bugs.python.org  Mon Jul 30 06:10:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 04:10:41 +0000
Subject: [issue15497] correct characters in TextWrapper.replace_whitespace docs
Message-ID: <1343621441.45.0.427004155003.issue15497@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to correct the list of whitespace characters to replace in the documentation for the textwrap module's TextWrapper.replace_whitespace attribute.

The documentation says this list is string.whitespace:

http://docs.python.org/dev/library/textwrap.html#textwrap.TextWrapper.replace_whitespace

However, the code deliberately avoids using string.whitespace and uses a hard-coded list of characters instead.  For example, see this code comment:

# Hardcode the recognized whitespace characters to the US-ASCII
# whitespace characters.  The main reason for doing this is that in
# ISO-8859-1, 0xa0 is non-breaking whitespace, so in certain locales
# that character winds up in string.whitespace....

http://hg.python.org/cpython/file/917295aaad76/Lib/textwrap.py#l12

Patch attached.

----------
assignee: docs at python
components: Documentation
files: issue-textwrap-whitespace.patch
keywords: easy, patch
messages: 166855
nosy: cjerdonek, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: correct characters in TextWrapper.replace_whitespace docs
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file26591/issue-textwrap-whitespace.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15497>
_______________________________________

From report at bugs.python.org  Mon Jul 30 06:39:45 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 30 Jul 2012 04:39:45 +0000
Subject: [issue15471] importlib's __import__() argument style nit
In-Reply-To: <1343408977.86.0.620892563203.issue15471@psf.upfronthosting.co.za>
Message-ID: <1343623185.67.0.579780091954.issue15471@psf.upfronthosting.co.za>


Meador Inge added the comment:

How about the attached?

----------
keywords: +patch
nosy: +meador.inge
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file26592/issue-15471.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15471>
_______________________________________

From report at bugs.python.org  Mon Jul 30 07:23:49 2012
From: report at bugs.python.org (Chris Pickett)
Date: Mon, 30 Jul 2012 05:23:49 +0000
Subject: [issue15232] email.generator.Generator doesn't mangle "From " lines
	in MIME preamble
In-Reply-To: <1341118945.33.0.829442271947.issue15232@psf.upfronthosting.co.za>
Message-ID: <1343625829.25.0.0245289586834.issue15232@psf.upfronthosting.co.za>


Chris Pickett added the comment:

Thanks everyone!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15232>
_______________________________________

From report at bugs.python.org  Mon Jul 30 08:55:54 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 30 Jul 2012 06:55:54 +0000
Subject: [issue15494] Move test/support.py into a test.support subpackage
In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>
Message-ID: <1343631354.61.0.19768296178.issue15494@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

-1. test.support is not at all too large for a single module; there is no point in refactoring it.

Without a specific patch to review which proposes some specific change, I'm rejecting this change request.

----------
nosy: +loewis
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15494>
_______________________________________

From report at bugs.python.org  Mon Jul 30 09:07:03 2012
From: report at bugs.python.org (Catherine Devlin)
Date: Mon, 30 Jul 2012 07:07:03 +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: <1343632023.7.0.377517670706.issue13214@psf.upfronthosting.co.za>


Catherine Devlin added the comment:

Needed to update the patch slightly for Python 3; now that filter() returns an iterator, ``do_help``'s call to 
names = self.get_names()
followed by
            names.sort()
was throwing an error, so I changed get_names to return a list.

----------
nosy: +Catherine.Devlin
Added file: http://bugs.python.org/file26593/python-cmd-better-filtering-py3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13214>
_______________________________________

From report at bugs.python.org  Mon Jul 30 09:12:57 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Jul 2012 07:12:57 +0000
Subject: [issue15489] Correct __sizeof__ support for BytesIO
In-Reply-To: <1343591287.44.0.516337828305.issue15489@psf.upfronthosting.co.za>
Message-ID: <1343632377.22.0.411394832372.issue15489@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Antoine, it looks like you committed the wrong patch for 3.3. Patches for 3.2 and 3.3 are different, otherwise I would have provided a one patch.

-        basesize = support.calcobjsize('P2PP2PP')
+        basesize = support.calcobjsize('P2nN2Pn')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15489>
_______________________________________

From report at bugs.python.org  Mon Jul 30 09:15:55 2012
From: report at bugs.python.org (Catherine Devlin)
Date: Mon, 30 Jul 2012 07:15:55 +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: <1343632555.76.0.563372636208.issue13214@psf.upfronthosting.co.za>


Catherine Devlin added the comment:

Change to test_cmd.py to test for help displaying the name of the registered subcommand (as well as a simple test for the basic operation of the registered sub-CLI).

----------
Added file: http://bugs.python.org/file26594/test_cmd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13214>
_______________________________________

From report at bugs.python.org  Mon Jul 30 09:33:42 2012
From: report at bugs.python.org (Tim Golden)
Date: Mon, 30 Jul 2012 07:33:42 +0000
Subject: [issue15496] harden directory removal for tests on Windows
In-Reply-To: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za>
Message-ID: <1343633622.21.0.754190965806.issue15496@psf.upfronthosting.co.za>


Tim Golden added the comment:

This is a (near) duplicate of issue7443, I think.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15496>
_______________________________________

From report at bugs.python.org  Mon Jul 30 09:34:25 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Jul 2012 07:34:25 +0000
Subject: [issue15498] Eliminate the use of deprecated OS X APIs in getpath.c
Message-ID: <1343633664.98.0.256476653975.issue15498@psf.upfronthosting.co.za>


New submission from Ned Deily:

getpath.c uses three OS X APIs that have been producing deprecation warnings since at least OS X 10.5:  NSModuleForSymbol, NSLookupAndBindSymbol, and NSLibraryNameForModule.  We should figure out how to live without them.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 166863
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Eliminate the use of deprecated OS X APIs in getpath.c
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15498>
_______________________________________

From report at bugs.python.org  Mon Jul 30 10:04:54 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 08:04:54 +0000
Subject: [issue15494] Move test/support.py into a test.support subpackage
In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>
Message-ID: <1343635494.86.0.13572656229.issue15494@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Martin, this change has been specifically requested by me to better organise all the support code that ISN'T in test.support.

That file is already huge, and I'm not going to make it even bigger with all the test infrastructure needed for generating packaging heirarchies and zip files and invoking Python subprocesses in various ways.

However, that support code *does* need to be made more discoverable (so we stop reinventing these wheels badly).

A package with the current support.py as its __init__.py is the obvious solution.

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15494>
_______________________________________

From report at bugs.python.org  Mon Jul 30 10:14:11 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Jul 2012 08:14:11 +0000
Subject: [issue15490] Correct __sizeof__ support for StringIO
In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za>
Message-ID: <1343636051.68.0.24385243692.issue15490@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> For the PyAccu, AFAICT, objects cannot leak out of it (except for gc.getobjects in debug mode).

Not only in debug mode.

>>> import io, gc
>>> s=io.StringIO()
>>> s.write('12345')
5
>>> s.write('qwerty')
6
>>> for o in gc.get_objects():
...     if "'123" in repr(o) and len(repr(o)) < 1000:
...         print(type(o), repr(o))
... 
<class 'list'> ['12345', 'qwerty']
<class 'list'> ['o', 'gc', 'get_objects', 'repr', 'o', "'123", 1000, 'len', 'repr', 'o', 'print', 'type', 'o', 'repr', 'o']
<class 'tuple'> ("'123", 1000, None)

Someone can summarize sys.getsizeof() for all managed by GC objects and therefore count internal objects twice.

I think the standard library should provide a method for recursive calculation of memory (in some sense, perhaps using different strategies), but that should wait up to 3.4. __sizeof__ should count non-object memory that is not available for GC. As I understand it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15490>
_______________________________________

From report at bugs.python.org  Mon Jul 30 10:17:18 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 30 Jul 2012 08:17:18 +0000
Subject: [issue15495] enable type truncation warnings for gcc builds
In-Reply-To: <1343612990.44.0.366704900621.issue15495@psf.upfronthosting.co.za>
Message-ID: <1343636238.31.0.544993109371.issue15495@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

How many extra warnings do you get by adding these flags (e.g., just by doing 'export CFLAGS= ...' before building)?  It might be useful to see a sampling of those warnings.

The addition of these flags should be conditional on gcc's version being >= 4.3:  gcc 4.2 apparently has a different meaning for -Wconversion (to do with implicit conversions when passing function arguments), and generates crazy numbers of warnings on my OS X 10.6 machine (which comes with gcc 4.2).

Why '-Wno-sign-conversion'?  Is fixing all the places that have implicit sign conversions a reasonable goal, or are there just too many of those?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15495>
_______________________________________

From report at bugs.python.org  Mon Jul 30 10:29:15 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 30 Jul 2012 08:29:15 +0000
Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility
In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za>
Message-ID: <1343636955.02.0.629381179087.issue15267@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

patch contains fix and test for 2.7.
With this patch, AttibuteError is captured as Tim sujested.

----------
keywords: +patch
nosy: +ishimoto
Added file: http://bugs.python.org/file26595/issue15267.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15267>
_______________________________________

From report at bugs.python.org  Mon Jul 30 11:01:18 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 30 Jul 2012 09:01:18 +0000
Subject: [issue15490] Correct __sizeof__ support for StringIO
In-Reply-To: <1343636051.68.0.24385243692.issue15490@psf.upfronthosting.co.za>
Message-ID: <20120730110116.Horde.oeClQklCcOxQFk1cgNtAScA@webmail.df.eu>


Martin v. L?wis added the comment:

>> For the PyAccu, AFAICT, objects cannot leak out of it (except for  
>> gc.getobjects in debug mode).
>
> Not only in debug mode.

I see. I meant sys.getobjects, which is in debug mode only, but
I now see that gc.get_objects will get the list (but not the strings)
of the Accu.

That still leaves readnl and writenl.

> I think the standard library should provide a method for recursive  
> calculation of memory (in some sense, perhaps using different  
> strategies), but that should wait up to 3.4.

Actually, this is (and should be) a separate project:

http://guppy-pe.sourceforge.net/

> __sizeof__ should count non-object memory that is not available for  
> GC. As I understand it.

I think you misunderstand slightly; the GC relevance is only a side
effect. __sizeof__ should only account for memory that isn't separately
accessible. The notion of "separately accessible" is somewhat weak, since
it may depend on the container.

Non-PyObject blocks clearly need to be accounted for.

PyObject blocks normally don't need to be accounted for, as they are typically
accessible separately, by the following means:
- gc.get_objects (for GC objects)
- gc.get_referents (for contained non-GC objects)

There are also irregular ways to get objects:
- in debug mode only: sys.getobjects
- customer access functions or attributes

For memory accounting, it would really be best if the latter two categories
wouldn't exist, i.e. if all non-GC objects were still visible through  
tp_traverse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15490>
_______________________________________

From report at bugs.python.org  Mon Jul 30 11:37:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Jul 2012 09:37:38 +0000
Subject: [issue14018] OS X installer does not detect bad symlinks created by
	Xcode 3.2.6
In-Reply-To: <1329267688.42.0.5159808393.issue14018@psf.upfronthosting.co.za>
Message-ID: <3Wlwg522KzzP8p@mail.python.org>


Roundup Robot added the comment:

New changeset f96579debefa by Ned Deily in branch 'default':
Issue #14018: Fix OS X Tcl/Tk framework checking when using OS X SDKs.
http://hg.python.org/cpython/rev/f96579debefa

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14018>
_______________________________________

From report at bugs.python.org  Mon Jul 30 11:46:38 2012
From: report at bugs.python.org (Seamus McKenna)
Date: Mon, 30 Jul 2012 09:46:38 +0000
Subject: [issue15470] Stuck/hang when reading ssl object
In-Reply-To: <1343404870.87.0.816938002683.issue15470@psf.upfronthosting.co.za>
Message-ID: <1343641598.04.0.556737789741.issue15470@psf.upfronthosting.co.za>


Seamus McKenna added the comment:

Thankyou for update.  Script was not using 100% cpu. I will add SMTP timeout and increase debuglevel() within the function should this reoccur.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15470>
_______________________________________

From report at bugs.python.org  Mon Jul 30 12:03:52 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 30 Jul 2012 10:03:52 +0000
Subject: [issue15494] Move test/support.py into a test.support subpackage
In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>
Message-ID: <1343642632.26.0.746839615083.issue15494@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

So who is going to provide a patch for it, and when?

I don't think the tracker is the right place to keep list of things that someone wants to do some day. There isn't an issue "Python should have a JIT", either. Tracker issues should be actionable at the time the issue is submitted, unless there is a clear criterion on which to defer the issue.

If the objective is to just put the module into an __init__.py, it takes just a few minutes, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15494>
_______________________________________

From report at bugs.python.org  Mon Jul 30 12:25:53 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 10:25:53 +0000
Subject: [issue15494] Move test/support.py into a test.support subpackage
In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>
Message-ID: <1343643953.56.0.611716365093.issue15494@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As noted in the original post, this is a change which will be made once the 3.3 release is out the door. It's origin lies in the fact that one of the new pkgutil tests currently lives in test_runpy because test_runpy has much better infrastructure for that kind of thing.

While figuring out where to put some shared infrastructure for the runpy, pkgutil, import and importlib tests, I came to the conclusion that having support.py, script_helper.py and whatever we decide to call the new module all living in the main test directory makes the support modules unnecessarily hard to find, and merging them all into a single massive support.py module doesn't make sense either.

Chris has been working on the patches. We were going to try to get this refactoring done before the release, but enough other things have ended up coming up that Antoine and I decided it was better to wait.

----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15494>
_______________________________________

From report at bugs.python.org  Mon Jul 30 12:26:40 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 10:26:40 +0000
Subject: [issue15403] Refactor package creation support code into a common
	location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1343644000.9.0.978708420595.issue15403@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
dependencies: +Move test/support.py into a test.support subpackage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Mon Jul 30 12:27:22 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 10:27:22 +0000
Subject: [issue15376] Refactor the test_runpy walk_package support code into a
	common location
In-Reply-To: <1342509049.53.0.303616016829.issue15376@psf.upfronthosting.co.za>
Message-ID: <1343644042.13.0.0666551860406.issue15376@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15376>
_______________________________________

From report at bugs.python.org  Mon Jul 30 12:27:46 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 10:27:46 +0000
Subject: [issue15376] Refactor the test_runpy walk_package support code into a
	common location
In-Reply-To: <1342509049.53.0.303616016829.issue15376@psf.upfronthosting.co.za>
Message-ID: <1343644066.38.0.832474734872.issue15376@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
dependencies: +Add temp_dir() and change_cwd() to test.support

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15376>
_______________________________________

From report at bugs.python.org  Mon Jul 30 12:28:14 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 10:28:14 +0000
Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of
	test_runpy
In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>
Message-ID: <1343644094.69.0.620249944299.issue15358@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15358>
_______________________________________

From report at bugs.python.org  Mon Jul 30 12:29:28 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 10:29:28 +0000
Subject: [issue15494] Move test/support.py into a test.support subpackage
In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>
Message-ID: <1343644168.78.0.211878125299.issue15494@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've just gone through and made sure all the related issues are correctly assigned to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15494>
_______________________________________

From report at bugs.python.org  Mon Jul 30 12:38:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Jul 2012 10:38:49 +0000
Subject: [issue14018] OS X installer does not detect bad symlinks created by
	Xcode 3.2.6
In-Reply-To: <1329267688.42.0.5159808393.issue14018@psf.upfronthosting.co.za>
Message-ID: <3Wly1h1z6xzPYt@mail.python.org>


Roundup Robot added the comment:

New changeset 7232d544c811 by Ned Deily in branch '2.7':
Issue #14018: Update the OS X IDLE Tcl/Tk warning check to include
http://hg.python.org/cpython/rev/7232d544c811

New changeset 17ddc0c34d9d by Ned Deily in branch '3.2':
Issue #14018: Update the OS X IDLE Tcl/Tk warning check to include
http://hg.python.org/cpython/rev/17ddc0c34d9d

New changeset 28cb0bcaa22e by Ned Deily in branch 'default':
Issue #14018: merge
http://hg.python.org/cpython/rev/28cb0bcaa22e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14018>
_______________________________________

From report at bugs.python.org  Mon Jul 30 12:59:53 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 30 Jul 2012 10:59:53 +0000
Subject: [issue15494] Move test/support.py into a test.support subpackage
In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>
Message-ID: <1343645993.97.0.93305245887.issue15494@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15494>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:00:41 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 30 Jul 2012 11:00:41 +0000
Subject: [issue15494] Move test/support.py into a test.support subpackage
In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>
Message-ID: <1343646041.42.0.80347241763.issue15494@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15494>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:06:34 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 11:06:34 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343646394.44.0.76243470234.issue15486@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

OK, after a bit of experimentation, it appears both 3.2 and 3.3 eventually get annoyed if you mess about too much with __pycache__.

1. They're both fine if __pycache__ is entirely unwritable (they just silently skip caching the bytecode)

2. 3.2 throws EOFError if you replace the cache entry with an empty file, 3.3 silently rewrites it with a valid cached version

3. 3.2 throws EOFError if you replace the cache entry with a directory, 3.3 throws a more accurate IsADirectory error

That means my chosen test case is a valid one, and I can just update the offending call in importlib._bootrap to use the new frame stripping hook as I originally planned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:08:40 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Jul 2012 11:08:40 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <3Wlyh72fSkzPYw@mail.python.org>


Roundup Robot added the comment:

New changeset ff7fc6a91212 by Victor Stinner in branch 'default':
Issue #15463: the faulthandler module truncates strings to 500 characters,
http://hg.python.org/cpython/rev/ff7fc6a91212

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:13:07 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 11:13:07 +0000
Subject: [issue14966] Fully document subprocess.CalledProcessError
In-Reply-To: <1338446762.96.0.360332771622.issue14966@psf.upfronthosting.co.za>
Message-ID: <1343646787.01.0.97621425262.issue14966@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


----------
nosy: +anton.barkovsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14966>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:18:42 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 11:18:42 +0000
Subject: [issue15499] Sleep is hardcoded in webbrowser.UnixBrowser
Message-ID: <1343647122.66.0.223275733233.issue15499@psf.upfronthosting.co.za>


New submission from Anton Barkovsky:

webbrowser.UnixBrowser._invoke will sleep for at least 1 second after
launching browser process and then probably 4 more seconds. These numbers
are hardcoded and can't be modified which is especially problematic for
testing.

I think this code should be replaced with Popen.wait with timeout.
A patch is attached.

----------
components: Library (Lib)
files: webbrowser_sleep.patch
keywords: patch
messages: 166877
nosy: anton.barkovsky
priority: normal
severity: normal
status: open
title: Sleep is hardcoded in webbrowser.UnixBrowser
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26596/webbrowser_sleep.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15499>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:19:55 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Jul 2012 11:19:55 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343647195.91.0.955061620122.issue15463@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Issue #15463: the faulthandler module truncates strings to 500 characters,

It should be able for most setup. See the issue #15479 if you consider that something better should be implemented.

Long path names are handled differently on each platform, I don't want to add a test checking a path longer than 500 characters. You might add a new test for truncated path if limits become configurable (#15479).

I consider this issue as resolved.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:21:42 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Jul 2012 11:21:42 +0000
Subject: [issue14018] OS X installer does not detect bad symlinks created by
	Xcode 3.2.6
In-Reply-To: <1329267688.42.0.5159808393.issue14018@psf.upfronthosting.co.za>
Message-ID: <3Wlyz90wV9zPZS@mail.python.org>


Roundup Robot added the comment:

New changeset e0eb7dea245f by Ned Deily in branch '2.7':
Issue #14018: Fix OS X Tcl/Tk framework checking when using OS X SDKs.
http://hg.python.org/cpython/rev/e0eb7dea245f

New changeset eb0af7f6ea6d by Ned Deily in branch '3.2':
Issue #14018: Fix OS X Tcl/Tk framework checking when using OS X SDKs.
http://hg.python.org/cpython/rev/eb0af7f6ea6d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14018>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:23:42 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 11:23:42 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343647422.01.0.271559466884.issue15486@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Looking at the actual code - I don't think it actually makes sense to strip the frames in this case. Unlike the previous examples, it only comes up if someone is doing something deliberately pathological, at which point a little noise in the traceback is the least of your worries.

Updated patch just drops that test case entirely and only has the changes that simplify the frame removal code. Since Georg isn't on IRC right now, assigning him to decide if he wants this version in beta 2 rather than the current "multiple exit points" approach.

----------
assignee:  -> georg.brandl
Added file: http://bugs.python.org/file26597/issue15486_simplify_importlib_frame_removal_no_new_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:23:56 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 11:23:56 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343647436.83.0.787400251913.issue15486@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file26573/issue15486_simplify_importlib_frame_removal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:25:32 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 11:25:32 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343647532.43.0.566304228109.issue15463@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Shouldn't a test be added to check that the issue has been fixed though (i.e. a test with a path longer than the original 100 characters)?

I provided a patch to show how this can easily be done.

I would be happy to write the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:34:05 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Jul 2012 11:34:05 +0000
Subject: [issue14018] OS X installer does not detect bad symlinks created by
	Xcode 3.2.6
In-Reply-To: <1329267688.42.0.5159808393.issue14018@psf.upfronthosting.co.za>
Message-ID: <1343648045.45.0.148952031416.issue14018@psf.upfronthosting.co.za>


Ned Deily added the comment:

The SDK test in setup.py has been extended to include files in /Library/Frameworks (see OS X ld man page).  The test in IDLE
to issue a warning message about unstable Tcl/Tk versions was
updated to include the Apple-supplied Tcl/Tk 8.5 in OS X 10.7
and 10.8.  All of these are applied for release in 2.7.4, 3.2.4,
and 3.3.0.  In addition for 3.3.0, checks are added to the OS X
installer build script to ensure that the desired Tcl/Tk shared
library has actually been linked as expected.  (I plan to
backport all outstanding build script changes prior to the 2.7.4
and 3.2.4 releases.)

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14018>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:46:03 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Jul 2012 11:46:03 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343648763.56.0.326733885317.issue15463@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I provided a patch to show how this can easily be done.

Your patch does not create a path longer than 100 characters. I didn't want to write such test, but I can review a patch adding such test.

The limit is not only applied on the filename, but also on the function name. It is maybe easier (more portable) to declare a function with a very long name:

exec(compile("def " + "f"*600 + "(): raise ValueError()\n" + "f"*600 + "()", "a", "exec"))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:50:35 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Jul 2012 11:50:35 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343649035.72.0.350556628049.issue15463@psf.upfronthosting.co.za>


Ned Deily added the comment:

BTW, the applied patch does fix the problem originally reported. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:51:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 11:51:57 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343649117.59.0.315174442876.issue15463@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> I didn't want to write such test, but I can review a patch adding such test.

Thank you.  I will provide a patch for your review.

I think a test for the path may be better as that was the original issue experienced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Mon Jul 30 13:59:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Jul 2012 11:59:29 +0000
Subject: [issue15489] Correct __sizeof__ support for BytesIO
In-Reply-To: <1343591287.44.0.516337828305.issue15489@psf.upfronthosting.co.za>
Message-ID: <1343649569.2.0.06763310964.issue15489@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, but the BytesIO structure is the same in 3.2 and 3.3. Ok, that's because struct now has support for size_t and Py_ssize_t, I see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15489>
_______________________________________

From report at bugs.python.org  Mon Jul 30 14:01:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Jul 2012 12:01:12 +0000
Subject: [issue15489] Correct __sizeof__ support for BytesIO
In-Reply-To: <1343591287.44.0.516337828305.issue15489@psf.upfronthosting.co.za>
Message-ID: <3Wlzrl2jQMzPZv@mail.python.org>


Roundup Robot added the comment:

New changeset e77c117ab024 by Antoine Pitrou in branch 'default':
Better test for BytesIO.__sizeof__, now that the struct module supports (s)size_t.
http://hg.python.org/cpython/rev/e77c117ab024

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15489>
_______________________________________

From report at bugs.python.org  Mon Jul 30 14:05:16 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Jul 2012 12:05:16 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343649916.52.0.696672610453.issue15425@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

For some reason the new tests fail on the XP buildbots.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Mon Jul 30 14:11:16 2012
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 30 Jul 2012 12:11:16 +0000
Subject: [issue15495] enable type truncation warnings for gcc builds
In-Reply-To: <1343612990.44.0.366704900621.issue15495@psf.upfronthosting.co.za>
Message-ID: <1343650276.5.0.993113353113.issue15495@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'm getting more than thousand warnings:

$ CFLAGS="-Wconversion -Wno-sign-conversion" ./configure
$ LC_ALL=C make -s -j8 2>&1 | tee log
$ grep Wconversion log | wc -l
1163

platform: Ubuntu 12.04 x86_64
gcc: 4.6.3

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15495>
_______________________________________

From report at bugs.python.org  Mon Jul 30 14:19:30 2012
From: report at bugs.python.org (Attila Nagy)
Date: Mon, 30 Jul 2012 12:19:30 +0000
Subject: [issue15500] Python should support naming threads
Message-ID: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za>


New submission from Attila Nagy:

Python class Thread has a "name" argument, which sets the name of the given thread. This name is used only internally, while there is a possibility to set this on an OS-level.
Related discussion:
http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a-thread-in-pthreads-linux

#include <pthread.h>
int pthread_setname_np(pthread_t thread, const char *name);

// FreeBSD & OpenBSD: function name is slightly different
void pthread_set_name_np(pthread_t tid, const char *name);

// Mac OS X: it only seems applicable to the current thread (no thread ID)
int pthread_setname_np(const char*);

It would be very useful if Python set the name parameter with the above pthread calls, so the user/developer could see which threads do what in ps or top.

----------
components: Library (Lib)
messages: 166890
nosy: bra
priority: normal
severity: normal
status: open
title: Python should support naming threads
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15500>
_______________________________________

From report at bugs.python.org  Mon Jul 30 14:25:10 2012
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 30 Jul 2012 12:25:10 +0000
Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous()
	incorrect for non-contiguous arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343651110.14.0.217882251884.issue12834@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Right now major parts of the buffer API are broken for non-trivial buffer definitions. IMHO a backport of the fix doesn't count as a new feature although it needs some new internal functions.

I don't quite understand why Nick thinks that ABI compatibility is a challenge. The structs, typedefs and function definitions aren't modified. The new functions aren't visible because they can be implemented as static functions if PyBuffer_ToContiguous() is moved to memoryview.c. That won't break the ABI eiter.

If we want to keep the function in its old place then we can prefix the new functions with _Py and include them in a private header file. That would export new function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Mon Jul 30 14:42:03 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 30 Jul 2012 12:42:03 +0000
Subject: [issue15496] harden directory removal for tests on Windows
In-Reply-To: <1343633622.21.0.754190965806.issue15496@psf.upfronthosting.co.za>
Message-ID: <CAGvrs3L3ZJMCt8LsyQ+zrBa2_yaj8csqBswdZ2+uX3T8AsRh6A@mail.gmail.com>


Jeremy Kloth added the comment:

> This is a (near) duplicate of issue7443, I think.

Partially so it seems.  However, my testing with Process Monitor (from
sysinterals) shows that most of the access denied errors occur when
removing directories.

The blind rename-remove dance doesn't work when removing entire
directory trees as now the renamed file/directory might be held
pending delete when the removing parent directory.

For some background for newcomers, see http://support.microsoft.com/kb/159199

For testing, I used regrtest -F -j6 test_import

Without patching it would fail consistently (albeit randomly).

----------
nosy: +jeremy.kloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15496>
_______________________________________

From report at bugs.python.org  Mon Jul 30 14:51:31 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 30 Jul 2012 12:51:31 +0000
Subject: [issue15495] enable type truncation warnings for gcc builds
In-Reply-To: <1343650276.5.0.993113353113.issue15495@psf.upfronthosting.co.za>
Message-ID: <CAGvrs3JvPUYKC5ykxAZW0rvudAWKnV4-sywn8oHkiGHPNjKhsA@mail.gmail.com>


Jeremy Kloth added the comment:

> I'm getting more than thousand warnings:
>
> $ CFLAGS="-Wconversion -Wno-sign-conversion" ./configure
> $ LC_ALL=C make -s -j8 2>&1 | tee log
> $ grep Wconversion log | wc -l
> 1163

My Win64 buildbot currentlyhas 544 conversion warnings, but it seems
something has recently changed with OpenSSL thus causing over 2100
total warnings.

----------
nosy: +jeremy.kloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15495>
_______________________________________

From report at bugs.python.org  Mon Jul 30 15:28:30 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 13:28:30 +0000
Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous()
	incorrect for non-contiguous arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343654910.09.0.0673722722554.issue12834@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I was musing about backporting *all* the memoryview fixes, including the buffer lifecycle ones. Antoine and Stefan rightly pointed out that was a bad idea, and not necessary to address this problem.

So +1 for backporting just this specific fix, with the necessary infrastructure to make it work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Mon Jul 30 15:31:43 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 13:31:43 +0000
Subject: [issue15501] Document exception classes in subprocess module
Message-ID: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za>


New submission from Anton Barkovsky:

Exception classes from subprocess module are mentioned in the doc but do
not have their own entries.

I'm attaching patches for 3.3, 3.2 and 2.7

This issue supersedes #14966.

----------
assignee: docs at python
components: Documentation
files: subprocess_doc_3.3.patch
keywords: patch
messages: 166895
nosy: anton.barkovsky, docs at python
priority: normal
severity: normal
status: open
title: Document exception classes in subprocess module
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26598/subprocess_doc_3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15501>
_______________________________________

From report at bugs.python.org  Mon Jul 30 15:31:56 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 13:31:56 +0000
Subject: [issue15501] Document exception classes in subprocess module
In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za>
Message-ID: <1343655116.13.0.57199610734.issue15501@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


Added file: http://bugs.python.org/file26599/subprocess_doc_3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15501>
_______________________________________

From report at bugs.python.org  Mon Jul 30 15:32:02 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 13:32:02 +0000
Subject: [issue15501] Document exception classes in subprocess module
In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za>
Message-ID: <1343655122.08.0.0841193658482.issue15501@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


Added file: http://bugs.python.org/file26600/subprocess_doc_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15501>
_______________________________________

From report at bugs.python.org  Mon Jul 30 15:37:08 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 13:37:08 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343655428.85.0.810050937189.issue15295@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ah, the perils of email readers with quote folding and issue trackers without it. The important part of Brett's email is that PEP 420 has started splitting the meta path finder and path entry finder APIs, but importlib still uses a single ABC for both of them. That's probably a mistake, and something we want to address prior to the release of 3.3. I'll create a separate issue for that.

I just pushed a docs update to the PEP 420 repo that should address all of my comments. I went ahead with the "regular package" -> "initialized package" and "sys path finder" -> "path entry finder" name changes - they just make more sense given the way the components are used.

I wanted to avoid "regular package" as I expect namespace packages to eventually become the norm and initialized packages the more unusual case.

"sys path finder" was simply misleading, as those finders are used for *all* path entries, including those in package __path__ attributes.

I haven't reviewed Eric's comments in detail, so I don't know if I also picked up all of those.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Mon Jul 30 15:39:42 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 13:39:42 +0000
Subject: [issue15502] Meta path finders and path entry finders are different, 
	but share an ABC
Message-ID: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In the review of #15295, Brett noted that the APIs of meta path finders and path entry finders have now diverged substantially thanks to PEP 420, thus it's rather dubious that they continue to share a single Finder ABC in importlib.

----------
components: Library (Lib)
messages: 166897
nosy: brett.cannon, georg.brandl, ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Meta path finders and path entry finders are different, but share an ABC
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15502>
_______________________________________

From report at bugs.python.org  Mon Jul 30 15:40:14 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 13:40:14 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343655614.3.0.465390705978.issue15295@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

#15502 records Brett concern about the merged ABC

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Mon Jul 30 15:48:13 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 13:48:13 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343656093.21.0.36335997955.issue15463@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Attaching patch with test case for long script path.

This test failed on my system before the fix and passes after.

----------
Added file: http://bugs.python.org/file26601/issue-15463-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Mon Jul 30 15:51:18 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 30 Jul 2012 13:51:18 +0000
Subject: [issue15502] Meta path finders and path entry finders are different, 
	but share an ABC
In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za>
Message-ID: <1343656278.47.0.750833484799.issue15502@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15502>
_______________________________________

From report at bugs.python.org  Mon Jul 30 16:07:19 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 14:07:19 +0000
Subject: [issue15447] A file is not properly closed by webbrowser._invoke
In-Reply-To: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za>
Message-ID: <1343657239.31.0.129724277832.issue15447@psf.upfronthosting.co.za>


Anton Barkovsky added the comment:

An updated patch with the same issue fixed in Konqueror class.

----------
Added file: http://bugs.python.org/file26602/fileclose_devnull_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15447>
_______________________________________

From report at bugs.python.org  Mon Jul 30 16:20:01 2012
From: report at bugs.python.org (=?utf-8?q?Petri_Heinil=C3=A4?=)
Date: Mon, 30 Jul 2012 14:20:01 +0000
Subject: [issue15503] concatenating string in dict unexpected performance
Message-ID: <1343658001.1.0.546887001379.issue15503@psf.upfronthosting.co.za>


New submission from Petri Heinil?:

In concatenating string in dict somehow radically depends the added string size.

code 

----
import timeit

s1 = """
text = ""
for i in range(1,50000):
  text += "12345678901234567890"
"""
print("str cat 20: {0}s".format(timeit.timeit(s1,number=1)))

s2 = """
d = dict()
d["text"] = ""
for i in range(1,50000):
  d["text"] += "12345"
"""
print("dict cat 5: {0}s".format(timeit.timeit(s2,number=1)))

s3 = """
d = dict()
d["text"] = ""
for i in range(1,50000):
  d["text"] += "1234567890"
"""
print("dict cat 10: {0}s".format(timeit.timeit(s3,number=1)))


s4 = """
d = dict()
d["text"] = ""
for i in range(1,50000):
  d["text"] += "12345678901234567890"
"""
print("dict cat 20: {0}s".format(timeit.timeit(s4,number=1)))

----

gives:

str cat 20: 0.011670112609863281s
dict cat 5: 2.994051933288574s
dict cat 10: 6.61974310874939s
dict cat 20: 34.230541944503784s

----------
assignee: collinwinter
components: Benchmarks
files: string_cat.py
messages: 166901
nosy: collinwinter, hevi
priority: normal
severity: normal
status: open
title: concatenating string in dict unexpected performance
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file26603/string_cat.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15503>
_______________________________________

From report at bugs.python.org  Mon Jul 30 16:43:43 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 14:43:43 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343659423.75.0.826152226571.issue15463@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Is it okay for me to reopen this issue to review the patch to add a test case for file paths longer than 100 characters, or should I create a new issue for that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Mon Jul 30 16:46:10 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 30 Jul 2012 14:46:10 +0000
Subject: [issue1610654] cgi.py multipart/form-data
Message-ID: <1343659570.5.0.383635028431.issue1610654@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1610654>
_______________________________________

From report at bugs.python.org  Mon Jul 30 16:51:17 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 30 Jul 2012 14:51:17 +0000
Subject: [issue15503] concatenating string in dict unexpected performance
In-Reply-To: <1343658001.1.0.546887001379.issue15503@psf.upfronthosting.co.za>
Message-ID: <1343659877.26.0.240117264597.issue15503@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Actually, I would argue that it's concatentation of a local variable which has unexpected performance. Logically it should be O(n**2), however due to hacks in CPython it isn't.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15503>
_______________________________________

From report at bugs.python.org  Mon Jul 30 16:57:56 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Jul 2012 14:57:56 +0000
Subject: [issue15503] concatenating string in dict unexpected performance
In-Reply-To: <1343658001.1.0.546887001379.issue15503@psf.upfronthosting.co.za>
Message-ID: <1343660276.5.0.131364441511.issue15503@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, the total time of repeated string concatenation is O(N**2). s3 is twice larger s2, therefore s3 time about twice large s2 time.

In the first case Python use a special optimization which allows O(N) in some cases. You can deactivate it:

s5 = """
text = ""
for i in range(1,50000):
  text2 = text
  text += "12345678901234567890"
"""
print("str cat 20: {0}s".format(timeit.timeit(s5,number=1)))

It's not a bug, it's feature.

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15503>
_______________________________________

From report at bugs.python.org  Mon Jul 30 17:03:39 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 30 Jul 2012 15:03:39 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343660619.39.0.636598373201.issue8847@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Mon Jul 30 17:07:38 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 30 Jul 2012 15:07:38 +0000
Subject: [issue14302] Move python.exe to bin/
In-Reply-To: <1331742575.57.0.919941207524.issue14302@psf.upfronthosting.co.za>
Message-ID: <1343660858.9.0.352574707544.issue14302@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14302>
_______________________________________

From report at bugs.python.org  Mon Jul 30 17:14:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Jul 2012 15:14:20 +0000
Subject: [issue15503] concatenating string in dict unexpected performance
In-Reply-To: <1343658001.1.0.546887001379.issue15503@psf.upfronthosting.co.za>
Message-ID: <1343661260.16.0.6404159988.issue15503@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

It's a FAQ entry:
http://docs.python.org/dev/faq/programming.html#what-is-the-most-efficient-way-to-concatenate-many-strings-together

----------
nosy: +pitrou
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15503>
_______________________________________

From report at bugs.python.org  Mon Jul 30 17:18:24 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 30 Jul 2012 15:18:24 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1343661504.84.0.691168163353.issue6132@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6132>
_______________________________________

From report at bugs.python.org  Mon Jul 30 17:19:35 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 30 Jul 2012 15:19:35 +0000
Subject: [issue7671] test_popen fails if path contains special char like ";"
In-Reply-To: <1263150436.77.0.15262763131.issue7671@psf.upfronthosting.co.za>
Message-ID: <1343661575.09.0.685141581759.issue7671@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7671>
_______________________________________

From report at bugs.python.org  Mon Jul 30 17:21:35 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 30 Jul 2012 15:21:35 +0000
Subject: [issue4722] _winreg.QueryValue fault while reading mangled registry
	values
In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za>
Message-ID: <1343661695.04.0.823514956818.issue4722@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4722>
_______________________________________

From report at bugs.python.org  Mon Jul 30 17:23:00 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 30 Jul 2012 15:23:00 +0000
Subject: [issue7686] redundant open modes 'rbb', 'wbb',
	'abb' no longer work on Windows
In-Reply-To: <1263342536.73.0.0502696558207.issue7686@psf.upfronthosting.co.za>
Message-ID: <1343661780.63.0.386009251546.issue7686@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7686>
_______________________________________

From report at bugs.python.org  Mon Jul 30 17:43:48 2012
From: report at bugs.python.org (Philipp Lies)
Date: Mon, 30 Jul 2012 15:43:48 +0000
Subject: [issue15504] pickle/cPickle saves invalid/incomplete data
Message-ID: <1343663028.38.0.42350418133.issue15504@psf.upfronthosting.co.za>


New submission from Philipp Lies:

I just stumbled upon a very serious bug in cPickle where cPickle stores the data passed to it only partially without a warning/error:

#creating a >8GB long random data sting
import os
import cPickle
random_string = os.urandom(int(1.1*2**33))
print len(random_string)
fout = open('test.pickle', 'wb')
cPickle.dump(random_string, fout, 2)
fout.close()
fin = open('test.pickle', 'rb')
random_string2 = cPickle.load(fin)
print len(random_string2)
print random_string == random_string2

The loaded string is significantly shorter, meaning that some of the data got lost while storing the string. This is a serious issue. However, when I use pickle, writing fails with 
error: 'i' format requires -2147483648 <= number <= 2147483647
so I guess pickle is not able to handle large data, therefore cPickle should either throw an error as well of pickle/cPickle should be patched to handle larger data.

Code to reproduce error using numpy (that's how I stumbled upon it):
import numpy as np
import cPickle as pickle
A = np.random.randn(1080,1920,553)
fout = open('test.pickle', 'wb')
pickle.dump(A, fout, 2)
fout.close()
fin = open('test.pickle', 'rb')
B = pickle.load(fin)
Here, numpy detects that the amount of data is wrong and throws an error. However, still serious because saving does not lead to an error so the user expects that the data are safely stored.

I guess might be related to http://bugs.python.org/issue13555 which is still open.

Python 2.7.3 on latest Ubuntu with numpy 1.6.2, 64bit architecture, 128GB RAM

----------
messages: 166906
nosy: Philipp.Lies
priority: normal
severity: normal
status: open
title: pickle/cPickle saves invalid/incomplete data
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15504>
_______________________________________

From report at bugs.python.org  Mon Jul 30 17:50:08 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Jul 2012 15:50:08 +0000
Subject: [issue15463] test_faulthandler can fail if install path is too long
In-Reply-To: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>
Message-ID: <1343663408.22.0.229205021901.issue15463@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15463>
_______________________________________

From report at bugs.python.org  Mon Jul 30 17:54:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Jul 2012 15:54:31 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343663671.84.0.602840871573.issue8847@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

For some reasons I was able to reproduce under 64-bit Windows with the 3.3b1 official build, but neither with my own VS9.0-compiled build, nor with the 3.2 official build.

To reproduce:

>>> class T(tuple): pass
...
>>> t = T((1,2))
>>> [] + t
(1, 2)
>>> [3,] + t
# crash

I tried to use the debugging symbols but it doesn't help a lot. The primary issue seems to be that the concatenation doesn't raise TypeError, and instead constructs an invalid object which then makes PyObject_Repr() crash.

Also, it is not the Python compiler, the same thing happens with constructor calls:

>>> list() + T([1,2])
(1, 2)
>>> list((3,)) + T([1,2])
# crash

And no it doesn't happen with list subclasses:

>>> class L(list): pass
...
>>> class T(tuple): pass
...
>>> L([]) + T([1,2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "T") to list
>>> [] + T([1,2])
(1, 2)

Also, directly calling the __add__ method doesn't trigger the issue, but operator.add does:

>>> l + T([1,2])
(1, 2)
>>> operator.add(list(), T([1,2]))
(1, 2)
>>> list().__add__(T([1,2]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "T") to list

----------
nosy: +brian.curtin, pitrou, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Mon Jul 30 18:30:56 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Jul 2012 16:30:56 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343665856.86.0.759867022952.issue8847@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The exact same issue happens when concatenating a list subclass to a tuple:

>>> () + L([1,2])
[1, 2]
>>> (3,) + L([1,2])
# crash

Also, note that in this case a list is returned, not a tuple despite the first operand being a tuple. Conversely:

>>> [] + T((1,2))
(1, 2)

A tuple is returned, not a list. Which is exactly what happens when calling T.__add__:

>>> T.__add__((), T((1,2)))
(1, 2)

My intuition is that the issue is somewhere in binary_op1() (called by PyNumber_Add) in abstract.c. I can't go much further since my own builds don't exhibit the issue.

(in the end, chances are it's a MSVC compiler bug)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Mon Jul 30 18:34:28 2012
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 30 Jul 2012 16:34:28 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343666068.75.0.338038919788.issue8847@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Raising priority.  This should be investigated properly before 3.3 final.

----------
nosy: +georg.brandl
priority: high -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Mon Jul 30 18:37:02 2012
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 30 Jul 2012 16:37:02 +0000
Subject: [issue15505] unittest.installHandler incorrectly assumes SIGINT
	handler is set.
Message-ID: <1343666222.08.0.345756863201.issue15505@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

unittest.installHandler incorrectly assumes signal.SIGINT will always be set to a callable object, rather than signal.SIG_DFL or signal.SIG_IGN. This breaks if the test is being executed in an environment that e.g. ignores signal.SIGINT, like a bash script that executes 'make' in a subshell, because an attempt to call the original handler (for whatever reason) causes it to try and call an integer.

On top of that, the *tests* for unittest.installHandler in unittest/tests/test_break.py assume not just that signal.SIGINT is set to a callable object, but that they're set to signal.default_int_handler.

----------
components: Tests
messages: 166910
nosy: twouters
priority: normal
severity: normal
status: open
title: unittest.installHandler incorrectly assumes SIGINT handler is set.
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15505>
_______________________________________

From report at bugs.python.org  Mon Jul 30 18:44:12 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 30 Jul 2012 16:44:12 +0000
Subject: [issue15504] pickle/cPickle saves invalid/incomplete data
In-Reply-To: <1343663028.38.0.42350418133.issue15504@psf.upfronthosting.co.za>
Message-ID: <1343666652.91.0.484926489661.issue15504@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

People can probably debate endless about seriousness of an issue. Keep in mind that two factors affect seriousness: what's the impact when it happens (here it is "quite bad"), and what's the chance that it happens (it's "quite low", since it requires you to pickle very long string objects, which only few people ever attempt). So these two cancel them out, in some form.

That said, I certainly agree that it needs to be fixed. AFAICT, the issue is that save_string uses "int" for size and len, when it should use Py_ssize_t. In addition, it shouldn't check for INT_MAX, but 0x7fffffff, since INT_MAX might be 2**63-1 on systems where int is a 64-bit type - but that should not be a problem on your system. I believe the bug exists in more cases; e.g. saving BINUNICODE.

Also, AFAICT, this shouldn't be a problem for 3.x, which already checks for overflow.

Then, AFAICT, there is a glitch in the BINUNICODE handling of 3.x, which rejects strings longer than 0xffffffff, when the  maximum supported length really is 0x7fffffff.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15504>
_______________________________________

From report at bugs.python.org  Mon Jul 30 18:56:07 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 30 Jul 2012 16:56:07 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343667367.9.0.864313416364.issue8847@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Mon Jul 30 19:05:20 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Jul 2012 17:05:20 +0000
Subject: [issue12288] tkinter SimpleDialog initialvalue
In-Reply-To: <1307568483.64.0.2959467561.issue12288@psf.upfronthosting.co.za>
Message-ID: <3Wm6bg05qGzPTp@mail.python.org>


Roundup Robot added the comment:

New changeset fd5166fdb978 by Andrew Svetlov in branch '3.2':
Issue #12288: Consider '0' and '0.0' as valid initialvalue for tkinter SimpleDialog.
http://hg.python.org/cpython/rev/fd5166fdb978

New changeset 2f3ccf4ec193 by Andrew Svetlov in branch 'default':
Issue #12288: Consider '0' and '0.0' as valid initialvalue for tkinter SimpleDialog.
http://hg.python.org/cpython/rev/2f3ccf4ec193

New changeset f98e2944cb40 by Andrew Svetlov in branch '2.7':
Issue #12288: Consider '0' and '0.0' as valid initialvalue for tkinter SimpleDialog.
http://hg.python.org/cpython/rev/f98e2944cb40

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12288>
_______________________________________

From report at bugs.python.org  Mon Jul 30 19:06:01 2012
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 30 Jul 2012 17:06:01 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343667961.14.0.953650339424.issue15486@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Looks good and simplifies things.  Green light :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Mon Jul 30 19:12:46 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 30 Jul 2012 17:12:46 +0000
Subject: [issue12288] tkinter SimpleDialog initialvalue
In-Reply-To: <1307568483.64.0.2959467561.issue12288@psf.upfronthosting.co.za>
Message-ID: <1343668366.15.0.298986208802.issue12288@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed. Thank you, Tom.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12288>
_______________________________________

From report at bugs.python.org  Mon Jul 30 19:52:21 2012
From: report at bugs.python.org (Mike Frysinger)
Date: Mon, 30 Jul 2012 17:52:21 +0000
Subject: [issue15506] configure should use PKG_PROG_PKG_CONFIG
Message-ID: <1343670741.23.0.818269374942.issue15506@psf.upfronthosting.co.za>


New submission from Mike Frysinger:

the current configure script open codes the pkg-config look up:
AC_PATH_TOOL([PKG_CONFIG], [pkg-config])

rather than using the standard macro from pkg-config's own pkg.m4:
PKG_PROG_PKG_CONFIG

this causes the build env to not operate exactly like other pkg-config autoconf builds :(

simple fix:
-AC_PATH_TOOL([PKG_CONFIG], [pkg-config])
+PKG_PROG_PKG_CONFIG

----------
components: Build
messages: 166915
nosy: vapier
priority: normal
severity: normal
status: open
title: configure should use PKG_PROG_PKG_CONFIG
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15506>
_______________________________________

From report at bugs.python.org  Mon Jul 30 20:00:06 2012
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 30 Jul 2012 18:00:06 +0000
Subject: [issue15505] unittest.installHandler incorrectly assumes SIGINT
	handler is set.
In-Reply-To: <1343666222.08.0.345756863201.issue15505@psf.upfronthosting.co.za>
Message-ID: <1343671206.11.0.924002095896.issue15505@psf.upfronthosting.co.za>


Thomas Wouters added the comment:

Patch attached.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file26604/inthandler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15505>
_______________________________________

From report at bugs.python.org  Mon Jul 30 20:13:11 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 30 Jul 2012 18:13:11 +0000
Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous()
	incorrect for non-contiguous arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1343671991.72.0.888857795926.issue12834@psf.upfronthosting.co.za>


Stefan Krah added the comment:

> Right now major parts of the buffer API are broken for non-trivial
> buffer definitions. IMHO a backport of the fix doesn't count as a new
> feature although it needs some new internal functions.

This particular bug fix for PyBuffer_ToContiguous() (which would automatically
fix memoryview.tobytes() in 2.7 and 3.2) is easy to backport.

For non-trivial buffers it's likely though that other problems
will show up in versions 2.7 and 3.2.


Backporting the *complete* rewrite would be relatively easy, too.
But that would change the layout of the MemoryView object etc.

Fixing all of #10181 without the drastic changes would be very time
consuming (if at all possible).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Mon Jul 30 20:21:26 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 Jul 2012 18:21:26 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1343672486.96.0.466992357453.issue13555@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/issue13555>
_______________________________________

From report at bugs.python.org  Mon Jul 30 20:27:55 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 Jul 2012 18:27:55 +0000
Subject: [issue15504] pickle/cPickle saves invalid/incomplete data
In-Reply-To: <1343663028.38.0.42350418133.issue15504@psf.upfronthosting.co.za>
Message-ID: <1343672875.29.0.765790820868.issue15504@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/issue15504>
_______________________________________

From report at bugs.python.org  Mon Jul 30 20:28:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Jul 2012 18:28:05 +0000
Subject: [issue15500] Python should support naming threads
In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za>
Message-ID: <1343672885.8.0.901436311247.issue15500@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15500>
_______________________________________

From report at bugs.python.org  Mon Jul 30 20:29:15 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 Jul 2012 18:29:15 +0000
Subject: [issue15506] configure should use PKG_PROG_PKG_CONFIG
In-Reply-To: <1343670741.23.0.818269374942.issue15506@psf.upfronthosting.co.za>
Message-ID: <1343672955.71.0.477588008726.issue15506@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/issue15506>
_______________________________________

From report at bugs.python.org  Mon Jul 30 20:30:20 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 Jul 2012 18:30:20 +0000
Subject: [issue15500] Python should support naming threads
In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za>
Message-ID: <1343673020.4.0.308413763808.issue15500@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/issue15500>
_______________________________________

From report at bugs.python.org  Mon Jul 30 20:33:32 2012
From: report at bugs.python.org (Daniel Holth)
Date: Mon, 30 Jul 2012 18:33:32 +0000
Subject: [issue15468] Edit docs to hide hashlib.md5()
In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za>
Message-ID: <1343673212.15.0.688392930084.issue15468@psf.upfronthosting.co.za>


Daniel Holth added the comment:

Taking a second look it is pretty good.

The only other thing that might be worth mentioning explicitly is that the "always present" hashes don't actually use OpenSSL.

"Constructors for hash algorithms that are always present in this module are md5(), sha1(), sha224(), sha256(), sha384(), and sha512(). Additional algorithms may also be available depending upon the OpenSSL library that Python uses on your platform."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15468>
_______________________________________

From report at bugs.python.org  Mon Jul 30 20:40:58 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Jul 2012 18:40:58 +0000
Subject: [issue15502] Meta path finders and path entry finders are different, 
	but share an ABC
In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za>
Message-ID: <1343673658.77.0.750002194474.issue15502@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Making this a dependency on the import machinery docs issues as the terminology settled on in those docs to differentiate between finders involving sys.meta_path and sys.path will help dictate what to name the new ABCs.

----------
dependencies: +Import machinery documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15502>
_______________________________________

From report at bugs.python.org  Mon Jul 30 20:44:59 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 30 Jul 2012 18:44:59 +0000
Subject: [issue15505] unittest.installHandler incorrectly assumes SIGINT
	handler is set.
In-Reply-To: <1343666222.08.0.345756863201.issue15505@psf.upfronthosting.co.za>
Message-ID: <1343673899.89.0.268662880996.issue15505@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
keywords: +needs review
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15505>
_______________________________________

From report at bugs.python.org  Mon Jul 30 21:10:17 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 30 Jul 2012 19:10:17 +0000
Subject: [issue9803] IDLE closes with save while breakpoint open
In-Reply-To: <1283974949.4.0.785258120567.issue9803@psf.upfronthosting.co.za>
Message-ID: <1343675417.93.0.262984420511.issue9803@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
assignee:  -> asvetlov
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9803>
_______________________________________

From report at bugs.python.org  Mon Jul 30 22:26:15 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 30 Jul 2012 20:26:15 +0000
Subject: [issue15468] Edit docs to hide hashlib.md5()
In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za>
Message-ID: <1343679975.81.0.672887520679.issue15468@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

The always present hashes do use openssl if the openssl version hashlib was compiled against supports them.  otherwise it falls back to the builtin C implementations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15468>
_______________________________________

From report at bugs.python.org  Mon Jul 30 22:35:41 2012
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 30 Jul 2012 20:35:41 +0000
Subject: [issue15507] test_subprocess assumes SIGINT is not being ignored.
Message-ID: <1343680541.23.0.308681373166.issue15507@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

test_subprocess's test_send_signal assumes SIGINT is not being ignored, by spawning a new process and expecting it to have the default SIGINT handler . SIGINT can be set to SIG_IGN if the process running the test inherited it from the parent process.

----------
components: Tests
messages: 166921
nosy: twouters
priority: normal
severity: normal
status: open
title: test_subprocess assumes SIGINT is not being ignored.
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15507>
_______________________________________

From report at bugs.python.org  Mon Jul 30 22:39:52 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 30 Jul 2012 20:39:52 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343680792.87.0.658837919995.issue8847@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/issue8847>
_______________________________________

From report at bugs.python.org  Mon Jul 30 22:47:32 2012
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 30 Jul 2012 20:47:32 +0000
Subject: [issue15507] test_subprocess assumes SIGINT is not being ignored.
In-Reply-To: <1343680541.23.0.308681373166.issue15507@psf.upfronthosting.co.za>
Message-ID: <1343681252.93.0.22565897914.issue15507@psf.upfronthosting.co.za>


Thomas Wouters added the comment:

Patch attached to (briefly) set signal.SIGINT to the default in the test.

It may make sense to add a feature to subprocess.Popen to ignore/unignore signals (it should only need to support SIG_DFL and SIG_IGN, not other signal handlers, considering there'll be an exec right after.)

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file26605/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15507>
_______________________________________

From report at bugs.python.org  Mon Jul 30 22:55:50 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 30 Jul 2012 20:55:50 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1343458481.19.0.981104259648.issue15295@psf.upfronthosting.co.za>
Message-ID: <20120730165547.3f0cf9b2@limelight.wooz.org>


Barry A. Warsaw added the comment:

Thanks for the review Eric.  I'm slogging through these and many other
comments, but I now have the docs integrated with trunk, and will probably
land them for better or worse in the next day or so.

I'll respond just to a few of your comments.  Whatever I omit you can consider
them "fixed"!

On Jul 28, 2012, at 06:54 AM, Eric Snow wrote:

>* (glossary.rst) path importer: I like that you pointed out this specific
>* metapath importer, but aren't path importers something else? [2] Perhaps
>* the metapath importer doesn't need to be in the glossary.  Then again I
>* like the entry, though I'd change ":term:`finder` / :term:`loader`" to
>* "metapath importer".  Maybe just a different term would work, like "sys
>* path subsystem".  Regardless, it is certainly the big dog in the import
>* machinery and deserves special attention.

I certainly struggled with this term.  I almost picked PathFinder (or "path
finder") since that's the name of the actual class used in the implementation,
but then I thought this might be too implementation specific.

You ask in [2] whether "path importer" refers specifically to the callables on
sys.path_hooks.  Can you site a reference for this?  I found one reference in
PEP 302 to "path importer" but it's hard to tell exactly what that is
referring to.  The sys module doesn't use that term.

If we agree that "path importer" is the name of the things on sys.path_hooks,
then we need a name for the thing on sys.meta_path that implements the things
on sys.path_hook. :)

>* (glossary.rst) sys path finder: having "sys" is a nice touch, making it more distinct and more explicit.

TBH, I'm not crazy about the term "sys path finder" either but I couldn't
think of anything better.

Keep the suggestions coming for both of these terms,.  I'll ruminate on it too
and leave XXX's in the docs for now.  (Maybe as I work through the rest of the
comments, something better has already been suggested.)

>* (importlib.rst) I could have sworn that find_loader() and resolve_name()
>* were public...

There's importlib.find_loader() and importlib.util.resolve_name(), but OTOH,
this is not intended to be the importlib library documentation.  So I'm happy
to leave out such details and add a reference to those docs (done).

In a subsequent comment, Nick suggests this whole chapter be called the
"Import System" instead of the "Import Machinery", but I've been thinking
"Import Protocol" might be good too.  The intent is really to describe the
hooks, methods, and attributes used by Python to accomplish import, as well as
allow Python code to extend or modify the import machinery.  The background at
the top of the chapter is really just there to set the stage (and because
afaict, nothing like that existed before :).

I'm still thinking about this.

>* (importlib.rst) SourceFileLoader.load_module(): What about when the name
>* does not match?

An ImportError gets raised?  Were you suggesting that some additional
documentation should be added for this?

>* (import_machinery.rst) import machinery, end of first paragraph: "Note that
>* importlib.import_module() is the recommended method of calling the import
>* machinery."

I rewrote the introductory paragraphs, and added a mention of
import_module(), as well as a section on importlib.  Hopefully this will
provide enough information for people to figure things out. :)

>* (import_machinery.rst) how about a section devoted just to the attributes
>* of modules and packages, perhaps expanding upon or supplanting the related
>* entries in the data model reference page?

I've added an XXX for this.  I think the right thing to do is to update the
data model chapter, and add a link from here to there.

>* (import_machinery.rst) Meta path loaders, end of paragraph 2: "The finder
>* could also be a classmethod that returns an instance of the class."

I don't understand what you're suggesting here.

>* (import_machinery.rst) Meta path loaders: "If the load fails, the loader
>* needs to remove any modules..." is a pretty exceptional case, since the
>* modules is not in charge of its parent or children, nor of import
>* statements executed for it.  Is this a new requirement?

I don't think so.  I lifted it from somewhere (hard to remember exactly where
now ;).  PEP 302?

>* (import_machinery.rst) Meta path loaders: too bad there isn't something
>* like "__origin__" for the case where __file__ doesn't make semantic sense,
>* but you still want to record where the module came from.

Yeah.

>* (import_machinery.rst) I'm surprised __name__ isn't required.

Indeed!  AFAICT, it was only required by the module object's default repr, but
I fixed that when I added module_repr(). :)

>* (import_machinery.rst) Meta path loaders: what should __package__ be set to
>* for a top-level module?

Great question.  I see no official recommendation in anything I've consulted,
and I think CPython is all over the map.  Some set it to None, some to the
empty string.  I added a footnote about this, and recommend the empty string,
but that's me making an executive decision. ;)

>* (import_machinery.rst) Module reprs: how does module.__qualname__ fit in?

Currently, it doesn't afaict.  The timing of the related PEPs was such that I
don't think PEP 420 ever considered __qualname__.  I'm staying silent on this
for now.

>* (import_machinery.rst) NullImporter (issue15473)?  I though Brett had a
>* plan for taking it to the gallows...

Let's cheer him on!  I have added a footnote about this based on the
discussion in that issue.

>* (import_machinery.rst) Diagrams?  Brett again.  :) He put together some
>* nice ones a few years back.

C'mon Brett, let's see 'em!

>* (simple_stmts.rst) the from list can include submodules which must be
>* imported separately, implying a step 1b

I couldn't figure out what to say differently here.

>* (simple_stmts.rst) is __all__ "considered public" in any technical way or
>* is it just convention?  The description somewhat implies that "from module
>* import *" is asking for the module's public API.  That's fine with me.
>* Explicitly describing it as such would make that connection even more
>* concrete.

I think __all__ should be considered a public, official API.  Certainly it's a
defacto standard.  However, I didn't change much substantial here, so I've
pretty much left it as is.

>[1] A package doesn't necessarily have to correspond to a directory, does it?
>Meta path importers should be able to generate packages just as well as path
>importers.  issue1644818 hints at this.

I've rewritten some of this, so I think the distinction is clearer.  More
clarification can perhaps come after I land this in trunk.

>[3] A module may replace itself in sys.modules.  This came up during the
>importlib integration when several people pointed out that they relied on
>this previously unspecified side-effect of the old import machinery (and
>importlib didn't cooperate).  Django was involved, if I recall correctly.
>You've alluded to the situation in the footnote on import_machinery.rst.

Crazy!  But I've added a footnote about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Mon Jul 30 23:05:11 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 Jul 2012 21:05:11 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343682311.68.0.170575374256.issue15295@psf.upfronthosting.co.za>


?ric Araujo added the comment:

A small note in passing: ?protocol? is used for things like the sequence protocol, the iterator protocol, or closer to home the finder and loader protocols, so it would sound weird or potentially confusing to me.  Import system is how I?ve always thought about it (probably took that term from the docs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Mon Jul 30 23:39:34 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 Jul 2012 21:39:34 +0000
Subject: [issue15508] __import__.__doc__ has outdated information about level
Message-ID: <1343684374.06.0.811645492819.issue15508@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

$ python3.2 -c '__import__("os", level=-1)'
$ python3.3 -c '__import__("os", level=-1)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: level must be >= 0
$ python3.3 -c 'print(__import__.__doc__)'
__import__(name, globals={}, locals={}, fromlist=[], level=-1) -> module

Import a module. Because this function is meant for use by the Python
interpreter and not for general use it is better to use
importlib.import_module() to programmatically import a module.

The globals argument is only used to determine the context;
they are not modified.  The locals argument is unused.  The fromlist
should be a list of names to emulate ``from name import ...'', or an
empty list to emulate ``import name''.
When importing a module from a package, note that __import__('A.B', ...)
returns package A when fromlist is empty, but its submodule B when
fromlist is not empty.  Level is used to determine whether to perform 
absolute or relative imports.  -1 is the original strategy of attempting
both absolute and relative imports, 0 is absolute, a positive number
is the number of parent directories to search relative to the current module.
$

Also please add a ".. versionchanged:: 3.3" note in Doc/library/functions.rst about no longer allowed negative level.

----------
messages: 166925
nosy: Arfrever, brett.cannon
priority: normal
severity: normal
status: open
title: __import__.__doc__ has outdated information about level
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15508>
_______________________________________

From report at bugs.python.org  Mon Jul 30 23:41:17 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Jul 2012 21:41:17 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343684477.77.0.647520030121.issue15295@psf.upfronthosting.co.za>


Brett Cannon added the comment:

To answer a couple of Barry's comments in reply to Eric...

__package__ should be set to the empty string if I'm reading PEP 362 correctly (and importlib isn't broken): "When the import system encounters an explicit relative import in a module without __package__ set (or with it set to None), it will calculate and store the correct value (__name__.rpartition('.')[0] for normal modules and __name__ for package initialisation modules". If someone sets __package__ to None, then importlib fills it in as necessary.

As for the diagram(s), I have attached the overall PDF that I still have from my original Omnifgraffle file (which I don't have a license to anymore) that I built my PyCon 2008 presentation with. It's probably outdated at this point. I will have to redo them for my PyCon Argentina/Brasil (maybe US?) import talks anyway.

----------
Added file: http://bugs.python.org/file26606/__import__.pdf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Mon Jul 30 23:46:03 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Jul 2012 21:46:03 +0000
Subject: [issue15508] __import__.__doc__ has outdated information about level
In-Reply-To: <1343684374.06.0.811645492819.issue15508@psf.upfronthosting.co.za>
Message-ID: <3WmDqZ0W7NzPWy@mail.python.org>


Roundup Robot added the comment:

New changeset 2a4ca86cc2b7 by Brett Cannon in branch 'default':
Issue #15508: Fix the docstring for __import__ to not mention negative
http://hg.python.org/cpython/rev/2a4ca86cc2b7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15508>
_______________________________________

From report at bugs.python.org  Mon Jul 30 23:46:45 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Jul 2012 21:46:45 +0000
Subject: [issue15508] __import__.__doc__ has outdated information about level
In-Reply-To: <1343684374.06.0.811645492819.issue15508@psf.upfronthosting.co.za>
Message-ID: <1343684805.41.0.0888188881787.issue15508@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15508>
_______________________________________

From report at bugs.python.org  Mon Jul 30 23:50:42 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 Jul 2012 21:50:42 +0000
Subject: [issue15508] __import__.__doc__ has outdated information about level
In-Reply-To: <1343684374.06.0.811645492819.issue15508@psf.upfronthosting.co.za>
Message-ID: <1343685042.49.0.460913524888.issue15508@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

What about the suggested change in Doc/library/functions.rst?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15508>
_______________________________________

From report at bugs.python.org  Tue Jul 31 00:01:21 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 30 Jul 2012 22:01:21 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343685681.91.0.803554646584.issue8847@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I can reproduce this exclusively with the pgupdate build:

msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=win32
msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platform=win32

PCbuild\Win32-pgo\python.exe
Python 3.3.0b1 (default, Jul 30 2012, 23:45:42) [MSC v.1600 32 bit (Intel)] on win32                          
Type "help", "copyright", "credits" or "license" for more information.                                        
>>> from collections import namedtuple                                                                        
>>> foo = namedtuple('foo', '')                                                                               
>>> [1] + foo()                                                                                               
                                  

Interpreter exits silently here. So it could be either an optimizer
bug or it's a Python bug exposed by the optimizer making draconian
assumptions at the highest level (c.f. clang exposing overflows).

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 00:35:18 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 22:35:18 +0000
Subject: [issue15509] webbrowser.open sometimes passes zero-length argument to
	the browser.
Message-ID: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za>


New submission from Anton Barkovsky:

Because of the way webbrowser.UnixBrowser.open generates command-line
arguments the resulting list sometimes looks like this:

  ['chromium', '', 'http://www.example.org/']

This seems to work fine with chromium for me but as you can see:

  >>> subprocess.call(['ls', '', '-l'])
  ls: cannot access : No such file or directory
  2

It's not a good idea to rely on that.
I'm attaching a patch that filters out those empty arguments.

----------
components: Library (Lib)
files: webbrowser_args.patch
keywords: patch
messages: 166930
nosy: anton.barkovsky
priority: normal
severity: normal
status: open
title: webbrowser.open sometimes passes zero-length argument to the browser.
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26607/webbrowser_args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15509>
_______________________________________

From report at bugs.python.org  Tue Jul 31 00:35:52 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Jul 2012 22:35:52 +0000
Subject: [issue15508] __import__.__doc__ has outdated information about level
In-Reply-To: <1343684374.06.0.811645492819.issue15508@psf.upfronthosting.co.za>
Message-ID: <1343687752.89.0.399885589033.issue15508@psf.upfronthosting.co.za>


Brett Cannon added the comment:

changest 231d98a38eec has the versionchanged notice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15508>
_______________________________________

From report at bugs.python.org  Tue Jul 31 00:39:23 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 22:39:23 +0000
Subject: [issue15509] webbrowser.open sometimes passes zero-length argument to
	the browser.
In-Reply-To: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za>
Message-ID: <1343687963.79.0.63128752697.issue15509@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


Removed file: http://bugs.python.org/file26607/webbrowser_args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15509>
_______________________________________

From report at bugs.python.org  Tue Jul 31 00:39:40 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 22:39:40 +0000
Subject: [issue15509] webbrowser.open sometimes passes zero-length argument to
	the browser.
In-Reply-To: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za>
Message-ID: <1343687980.84.0.776452889389.issue15509@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


Added file: http://bugs.python.org/file26608/webbrowser_args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15509>
_______________________________________

From report at bugs.python.org  Tue Jul 31 00:40:56 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 Jul 2012 22:40:56 +0000
Subject: [issue15508] __import__.__doc__ has outdated information about level
In-Reply-To: <1343684374.06.0.811645492819.issue15508@psf.upfronthosting.co.za>
Message-ID: <1343688056.35.0.928062906916.issue15508@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

You should probably use *level* instead of 'level'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15508>
_______________________________________

From report at bugs.python.org  Tue Jul 31 01:03:15 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 30 Jul 2012 23:03:15 +0000
Subject: [issue15509] webbrowser.open sometimes passes zero-length argument to
	the browser.
In-Reply-To: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za>
Message-ID: <1343689395.76.0.996564530855.issue15509@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, georg.brandl
stage:  -> test needed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15509>
_______________________________________

From report at bugs.python.org  Tue Jul 31 01:31:34 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Jul 2012 23:31:34 +0000
Subject: [issue15508] __import__.__doc__ has outdated information about level
In-Reply-To: <1343684374.06.0.811645492819.issue15508@psf.upfronthosting.co.za>
Message-ID: <1343691094.53.0.805878439634.issue15508@psf.upfronthosting.co.za>


Brett Cannon added the comment:

changelist d56b647f325a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15508>
_______________________________________

From report at bugs.python.org  Tue Jul 31 01:45:40 2012
From: report at bugs.python.org (Derek Wilson)
Date: Mon, 30 Jul 2012 23:45:40 +0000
Subject: [issue15468] Edit docs to hide hashlib.md5()
In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za>
Message-ID: <1343691940.23.0.814101211583.issue15468@psf.upfronthosting.co.za>


Derek Wilson added the comment:

Attached patch mentioning availability of md5 under FIPS compliance and the use of OpenSSL algorithms when available and altering the initial example to use sha1 instead of md5.

----------
keywords: +patch
nosy: +Derek.Wilson
Added file: http://bugs.python.org/file26609/issue15468.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15468>
_______________________________________

From report at bugs.python.org  Tue Jul 31 02:08:57 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Jul 2012 00:08:57 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343693337.69.0.470463379137.issue8847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

When Python is compiled by Visual Studio 10 in PGUpdate mode, duplicated functions are merged to become the same unique function. The C code of wrap_binaryfunc() and wrap_binaryfunc_l() functions is the same and so both functions get the same address.

For "class List(list): pass", type_new() fills type->tp_as_number->nb_add to list_concat() because "d->d_base->wrapper == p->wrapper" is True whereas it should be False (wrap_binaryfunc vs wrap_binaryfunc_l).

A workaround is to use a different code for wrap_binaryfunc() and wrap_binaryfunc_l(). A real fix is to use something else than the address of the wrapper to check the type of the operator (left, right, or the 3rd type).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 02:17:55 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Jul 2012 00:17:55 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343693875.78.0.8233879743.issue8847@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Nice detective work, Victor.

Can we turn that particular optimisation off? We use function addresses for identification purposes in many more places than just this one. Having the compiler merge different pointers just because the functions happen to have the same implementation is simply *not cool* from the point of view of the CPython code base.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 02:24:03 2012
From: report at bugs.python.org (Thomas Wouters)
Date: Tue, 31 Jul 2012 00:24:03 +0000
Subject: [issue15505] unittest.installHandler incorrectly assumes SIGINT
	handler is set.
In-Reply-To: <1343666222.08.0.345756863201.issue15505@psf.upfronthosting.co.za>
Message-ID: <1343694243.52.0.549135904332.issue15505@psf.upfronthosting.co.za>


Thomas Wouters added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file26610/inthandler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15505>
_______________________________________

From report at bugs.python.org  Tue Jul 31 02:24:13 2012
From: report at bugs.python.org (Thomas Wouters)
Date: Tue, 31 Jul 2012 00:24:13 +0000
Subject: [issue15505] unittest.installHandler incorrectly assumes SIGINT
	handler is set.
In-Reply-To: <1343666222.08.0.345756863201.issue15505@psf.upfronthosting.co.za>
Message-ID: <1343694253.83.0.630935771054.issue15505@psf.upfronthosting.co.za>


Changes by Thomas Wouters <thomas at python.org>:


Removed file: http://bugs.python.org/file26604/inthandler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15505>
_______________________________________

From report at bugs.python.org  Tue Jul 31 02:26:13 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 00:26:13 +0000
Subject: [issue15355] generator docs should mention already-executing exception
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343694373.78.0.629195403456.issue15355@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Meador, does this language look okay to you now that it states the exception type?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15355>
_______________________________________

From report at bugs.python.org  Tue Jul 31 02:28:04 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 00:28:04 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343694484.08.0.513510031013.issue15295@psf.upfronthosting.co.za>


Eric Snow added the comment:

> I certainly struggled with this term.  I almost picked PathFinder (or "path
> finder") since that's the name of the actual class used in the implementation,
> but then I thought this might be too implementation specific.

Considering that the goal is for importlib to be the common import machinery for the various Python implementations, this might not be inappropriate.

> You ask in [2] whether "path importer" refers specifically to the callables on
> sys.path_hooks.  Can you site a reference for this?  I found one reference in
> PEP 302 to "path importer" but it's hard to tell exactly what that is
> referring to.

Unfortunately not.  There aren't many people that use import hook terminology and I already have a terrible memory. :)  Regardless, I find "path importer" a little too ambiguous.

>>* (glossary.rst) sys path finder: having "sys" is a nice touch, making it more distinct and more explicit.
>
> TBH, I'm not crazy about the term "sys path finder" either but I couldn't
> think of anything better.

What don't you like about the "sys path thingee" names?  I find them to be nice and explicit.  I'll mull this over some more.

> In a subsequent comment, Nick suggests this whole chapter be called the
> "Import System" instead of the "Import Machinery", but I've been thinking
> "Import Protocol" might be good too.

I agree with Nick.

> The background at
> the top of the chapter is really just there to set the stage (and because
> afaict, nothing like that existed before :).

And it does a good job of it.

>>* (importlib.rst) SourceFileLoader.load_module(): What about when the name
>>* does not match?
>
> An ImportError gets raised?  Were you suggesting that some additional
> documentation should be added for this?

I guess I was just noting a possible hole in the Import System (sounds nice, doesn't it <wink>) specification.  Since importlib is a complete reference implementation, it's not critical to have every detail spelled out (at least, that's seems to be the status quo).

>>* (import_machinery.rst) how about a section devoted just to the attributes
>>* of modules and packages, perhaps expanding upon or supplanting the related
>>* entries in the data model reference page?
>
> I've added an XXX for this.  I think the right thing to do is to update the
> data model chapter, and add a link from here to there.

Perfect.

>>* (import_machinery.rst) Meta path loaders, end of paragraph 2: "The finder
>>* could also be a classmethod that returns an instance of the class."
>
> I don't understand what you're suggesting here.

Yeah, that was poorly worded.  I'd meant to suggest that you could document the alternative to find_module() and load_module() being regular methods of the same object.  For instance:

class MyMetaHook:
    @classmethod
    def find_module(cls, name, path=None):
        return cls()
    def load_module(self, name):
        raise ImportError("You lose!")

Thus, the "finder" is the class, and the "loader" is the instance.

>>* (import_machinery.rst) Meta path loaders: "If the load fails, the loader
>>* needs to remove any modules..." is a pretty exceptional case, since the
>>* modules is not in charge of its parent or children, nor of import
>>* statements executed for it.  Is this a new requirement?
>
> I don't think so.  I lifted it from somewhere (hard to remember exactly where
> now ;).  PEP 302?

Nick made the point more clearly.  :)

>>* (simple_stmts.rst) the from list can include submodules which must be
>>* imported separately, implying a step 1b
>
> I couldn't figure out what to say differently here.

No, you've got it covered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 03:26:19 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 01:26:19 +0000
Subject: [issue15510] textwrap.wrap('') returns empty list
Message-ID: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

While working on issue 1859, I found that textwrap.wrap() returns an empty list when passed the empty string:

>>> from textwrap import wrap
>>> wrap('')
[]

as opposed to a list containing the empty string which is what I expected--

['']

I originally accepted this as intended behavior, but for the following reasons I now think it is a bug that we should consider fixing:

1. The textwrap documentation says that wrap(), "Wraps the single paragraph in text (a string) so every line is at most width characters long. Returns a list of output lines, without final newlines."  The empty string is less than width characters long, so following the documentation, wrapping should not change it.

2. It is known that wrap() is broken for strings containing newlines (i.e. strings containing more than one paragraph).  Indeed, this is the issue that issue 1859 is meant to fix.

The commonly recommended work-around is to call splitlines() on the incoming string, pass the pieces to wrap(), and then join the return values on newlines.

However, the behavior described in this issue causes this workaround not to behave sensibly when the original string contains breaks between paragraphs.  See this message, for example:

http://bugs.python.org/issue1859#msg166627

Currently, this work-around would return "a\nb" for both "a\nb" and "a\n\nb" for example when common sense says it should preserve the newlines and return "a\nb" and "a\n\nb", respectively.

3. In addition, the behavior causes the following inconsistent behavior:

>>> repr(wrap('  ', drop_whitespace=False))
"['  ']"
>>> repr(wrap('  ', drop_whitespace=True))
'[]'

The documentation says this about drop_whitespace: "If true, whitespace that, after wrapping, happens to end up at the beginning or end of a line is dropped."  If the first case is correct, then, the second case should at least return a non-empty list because that is what would result from dropping whitespace from the string '  ' in the first list.  This is how drop_whitespace behaves when the string contains non-whitespace characters:

>>> repr(wrap('a  ', drop_whitespace=False))
"['a  ']"
>>> repr(wrap('a  ', drop_whitespace=True))
"['a']"

4. There is no unit test for the case of the empty string, and existing tests still pass after fixing the issue.

If we cannot correct this behavior, then I feel we should at least document the inconsistent behavior, and then work around it in the fix for issue 1859.

Marking for this issue to be resolved either way before fixing issue 1859.  I am happy to prepare the patch.

----------
messages: 166940
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: textwrap.wrap('') returns empty list
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15510>
_______________________________________

From report at bugs.python.org  Tue Jul 31 03:29:15 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 01:29:15 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1343698155.7.0.891034632402.issue1859@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Marking issue 15510 as a dependency because there is a behavioral issue in existing use cases that affects how to proceed in this issue.

----------
dependencies: +textwrap.wrap('') returns empty list

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Tue Jul 31 03:36:04 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 31 Jul 2012 01:36:04 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343698564.53.0.269418369598.issue8847@psf.upfronthosting.co.za>


Meador Inge added the comment:

Nice work Victor.

> Can we turn that particular optimisation off?

/OPT:NOICF is probably what we are looking for [1]:

"""
/OPT:ICF can result in the same address being assigned to different functions or read only data members (const variables compiled with /Gy). So, /OPT:ICF can break a program that depends on the address of functions or read-only data members being different. See /Gy (Enable Function-Level Linking) for more information.
"""

Now it makes sense that this only crops up with the PGO builds -- those are the only ones where we link with /OPT:ICF.

Can someone try out this option?  I would, but I don't have a Windows box handy.

[1] http://msdn.microsoft.com/en-us/library/bxwfs976.aspx

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 03:46:07 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 31 Jul 2012 01:46:07 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343699167.84.0.406847880175.issue8847@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

> Having the compiler merge different pointers just because the functions 
> happen to have the same implementation is simply *not cool* from the 
> point of view of the CPython code base.

I believe the compiler is completely entitled to do so according to the C language definition. There is no guarantee that two different functions have two different addresses as long as calling the function pointer does the same thing according to the as-if rule.

So we really need to fix Python, not work-around in the compiler. There may be many more compilers which use the same optimisation. Python relying on undefined behavior is simply *not cool*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 03:53:08 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Jul 2012 01:53:08 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343699588.44.0.730959248028.issue15295@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As far as the path importer goes, it's important to keep in mind there are *four* different pieces in play:

1. The path importer itself

This is a meta path finder installed on sys.meta_path, which implements the find_module API. It scans the supplied search path (or sys.path) for path entries, using sys.path_importer_cache and sys.path_hooks to find the locate path entry finders. "Path importer" is an eminently appropriate name as it is responsible for *all* of the standard semantics of sys.path and package __path__ attribute processing. It could be potentially be qualified with "standard path importer" or "default path importer" to distinguish it from other cases.

2. The path hooks

These are installed in sys.path_hooks, and are simply callables that accept a path entry and return an appropriate path entry handler or else raise ImportError. The specification is designed to make it easy to use the classes for path entry handlers directly as path hooks (since __init__ can throw ImportError, but it can't return None). For these, "path hook" is just fine as a name.

3. The path entry handlers

These are the objects returned by the path hooks. Historically, they implemented find_module() (without the second "search path" parameter), and now they can implement the "find_loader()" API instead.

The reason I don't like "sys path finder" for these is that it misses their essential role in handling package __path__ attributes. I have previously suggested "path entry finder", but that's a little ambiguous (since it suggests they're tools for *finding* path entries, rather than tools for finding module loaders *given* a path entry). Thus, my new suggestion here: "path entry handler". They're objects that handle particular path entries on behalf of the path importer, so the name is perfectly appropriate, and better distinguishes them from the meta path finder objects.

4. The module loaders

As with any import, the module loaders implement the load_module() API to create, cache, initialise and return a loaded module object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 03:54:18 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Jul 2012 01:54:18 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343699658.59.0.853343730348.issue15295@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

s/locate path entry finders/appropriate path entry handlers/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 03:56:07 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 31 Jul 2012 01:56:07 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343699767.55.0.0338655106757.issue8847@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

OTOH, 6.5.9p6 says

"Two pointers compare equal if and only if both are null pointers, both 
are pointers to the same object (including a pointer to an object and a 
subobject at its beginning) or function [...]"

This is probably meant to imply that pointers to different functions must not compare equal.

So if this is determined to be a compiler bug, the most natural conclusion is to stop using PGI/PGO entirely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 04:08:45 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 02:08:45 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343700525.92.0.528089221074.issue15486@psf.upfronthosting.co.za>


Eric Snow added the comment:

patch LGTM.  Nice and clean.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Tue Jul 31 04:22:00 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Tue, 31 Jul 2012 02:22:00 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <1343701320.04.0.943414804229.issue15486@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Tue Jul 31 04:30:26 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 31 Jul 2012 02:30:26 +0000
Subject: [issue13553] Tkinter doesn't set proper application name in Gnome
	Shell
In-Reply-To: <1323306729.26.0.368335158355.issue13553@psf.upfronthosting.co.za>
Message-ID: <1343701826.42.0.381644454039.issue13553@psf.upfronthosting.co.za>


Roger Serwy added the comment:

It looks like this code will set the title properly in the latest GNOME shell (3.4):


    from Tkinter import *
    app = Tk(className='App Name')
    app.title('App Title')
    app.mainloop()


The documentation should be updated to explain the arguments to Tk().

----------
title: Tkinter doesn't set proper application name -> Tkinter doesn't set proper application name in Gnome Shell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13553>
_______________________________________

From report at bugs.python.org  Tue Jul 31 05:00:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 03:00:29 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343703629.84.0.386776706773.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Since Martin is busy, is there anything I can do to help close this very minor change?  It seems to be in a half-committed state right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Tue Jul 31 05:15:19 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Jul 2012 03:15:19 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <3WmN7T5zQszPYJ@mail.python.org>


Roundup Robot added the comment:

New changeset 3a08d766eee3 by Eli Bendersky in branch 'default':
Issue #15231: rephrase the last paragraph slightly
http://hg.python.org/cpython/rev/3a08d766eee3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Tue Jul 31 05:17:54 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 03:17:54 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343704674.04.0.444707528155.issue15231@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I've committed a rephrase [the Misc/NEWS entry is IMHO unnecessary for tiny documentation clarifications].

Since there's no distutils2/packaging in 3.3 at the moment, I think we're done. ?ric - would you like to keep this issue alive to remember applying the fix to packaging, once it's back?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Tue Jul 31 05:21:09 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 03:21:09 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343704869.56.0.834482644373.issue15295@psf.upfronthosting.co.za>


Eric Snow added the comment:

Sounds good to me.  As I understood them:

1. default path importer (a.k.a PathFinder),
2. path hook (lives on sys.path_hooks),
3. path entry handler (finder look-alike that a path hook returns),
4. module loader (business as usual).

A "path entry handler" would stand in contrast to a "meta path finder".  These two would also map well to ABCs for issue15502.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 05:23:30 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 03:23:30 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343705010.86.0.964916931604.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks, Eli.  I know ?ric had marked in the tracker for the change to be done in 2.7 and 3.2 as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Tue Jul 31 05:27:53 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 31 Jul 2012 03:27:53 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343705273.92.0.39596364479.issue8847@psf.upfronthosting.co.za>


Meador Inge added the comment:

> This is probably meant to imply that pointers to different functions must
> not compare equal.

I think so.  Also, in our case the functions have different names, therefore
they can't be the "same" function.

> So if this is determined to be a compiler bug, the most natural conclusion
> is to stop using PGI/PGO entirely.

I think it is non-conformant behavior.  Microsoft warns about it in their
documentation, but they don't go as far to say it is non-conformant.

Also, this isn't really a problem with PGO.  AFAICT, it is the COMDAT folding
optimization in the linker.  That optimization just happens to be enabled on
our PGO configurations.

Do we even use PGO to the fullest extent?  Does someone actually build an
instrumented Python, run training inputs on it, and then rebuild with the
training data to take advantage of the profile-guided optimizations?  If not,
then I doubt PGO is buying us anything anyway.

Also, PGO is only available on the Premium and Ultimate versions of VC++ [1].
I noticed when building with VC++ 2010 Express on the PGI/PGO builds that it
warns about PGO not being available.  I don't know what version we build our
Python release bits with.

[1] http://msdn.microsoft.com/en-us/library/hs24szh9.aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 05:28:44 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 03:28:44 +0000
Subject: [issue15231] update PyPI upload doc to say --no-raw passed to
	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343705324.3.0.507991332961.issue15231@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Yes, if the new phrasing looks OK I will backport to 3.2 & 2.7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15231>
_______________________________________

From report at bugs.python.org  Tue Jul 31 05:30:19 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 31 Jul 2012 03:30:19 +0000
Subject: [issue15355] generator docs should mention already-executing exception
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343705419.0.0.933103800623.issue15355@psf.upfronthosting.co.za>


Meador Inge added the comment:

Hi Chris, it seems reasonable to me, but I would feel more comfortable if someone (like Nick) that is more familiar with the generator implementation can comment on this as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15355>
_______________________________________

From report at bugs.python.org  Tue Jul 31 05:59:16 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 03:59:16 +0000
Subject: [issue15464] ssl: add set_msg_callback function
In-Reply-To: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za>
Message-ID: <1343707156.08.0.383480705889.issue15464@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I haven't commented on the content of your patch (I'm not knowledgeable enough in this area), but as for your test, I noticed that you removed the part that asserted something about the argument passed to cb().

Ideally when testing a callback, you want to test whatever is important about it, like: that it gets called at the right times (and as many times as it should), and that it is getting passed the right data.

So you might also want to make whatever assertions are appropriate about the packet(s) passed to cb().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15464>
_______________________________________

From report at bugs.python.org  Tue Jul 31 07:13:59 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 05:13:59 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343711639.35.0.261670370816.issue15295@psf.upfronthosting.co.za>


Eric Snow added the comment:

More on import-related terms.

Given Nick's recommendation, here's a broader view, as related to the import state:

sys.meta_path:
  "meta path finder" -> "module loader"
sys.meta_path[-1] (initially):
  "default path importer"
sys.path_hooks:
  "path hook" -> "path entry handler"
sys.path_importer_cache:
  "path entry handler" -> "module loader"

One unfortunate name is "sys.path_importer_cache", which implies either a cache of "path importers" or a cache belonging to "path importer", both of which are still rather ambiguous.

In light of all the above, I've attached an updated patch just for the glossary.  The import system reference then goes further into the protocols that the different objects implement and so forth.

----------
keywords: +patch
Added file: http://bugs.python.org/file26611/issue15295_glossary_refactor.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 07:18:33 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 05:18:33 +0000
Subject: [issue15502] Meta path finders and path entry finders are different, 
	but share an ABC
In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za>
Message-ID: <1343711913.36.0.352115060657.issue15502@psf.upfronthosting.co.za>


Eric Snow added the comment:

Would importlib.abc.Finder become something like MetapathHandler, or would we just add a new one (like PathEntryHandler)?  Obviously the actual names would depend on the outcome of issue15295, but the fate of importlib.abc.Finder is independent of the names.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15502>
_______________________________________

From report at bugs.python.org  Tue Jul 31 07:47:08 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Jul 2012 05:47:08 +0000
Subject: [issue15502] Meta path finders and path entry finders are different, 
	but share an ABC
In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za>
Message-ID: <1343713628.57.0.700632817043.issue15502@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As we want to eventually deprecate find_module in the PathEntryHandler API, I'd suggest two new subclasses, MetaPathFinder and PathEntryHandler, both inheriting from Finder.

Current path hooks would be updated to inherit from PathEntryHandler, meta path hooks from MetaPathFinder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15502>
_______________________________________

From report at bugs.python.org  Tue Jul 31 08:03:16 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 06:03:16 +0000
Subject: [issue15502] Meta path finders and path entry finders are different, 
	but share an ABC
In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za>
Message-ID: <1343714596.78.0.763148838526.issue15502@psf.upfronthosting.co.za>


Eric Snow added the comment:

Yeah, but right now the API of importlib.abc.Finder is strictly find_module(name, path=None).  I would expect that to remain the same for MetaPathFinder (bikeshedding aside :).  So what would be left in importlib.abc.Finder if the ultimate plan is that PathEntryHandler would not implement find_module()?  Would it simply be an alias to MetaPathFinder?

I agree with the plan, but wonder if a common base class is warranted.  The connection to "finder" in PEP 302 is nice, but rather superfluous in a practical context.  Having a Finder class is necessary at this point for backward-compatibility, but I don't see how it is different from the more appropriately named MetaPathFinder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15502>
_______________________________________

From report at bugs.python.org  Tue Jul 31 08:09:01 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 06:09:01 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343714941.29.0.0746946254997.issue15425@psf.upfronthosting.co.za>


Eric Snow added the comment:

For instance, http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/7214/steps/test/logs/stdio

4 cases of "ImportError: No module named '_parent_foo'".  Failing on "import _parent_foo.bar" and "from _parent_foo import bar".

Unfortunately I don't have an XP system set up on which to debug this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Tue Jul 31 08:25:20 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 06:25:20 +0000
Subject: [issue15481] Add exec_module() as part of the import loader API
In-Reply-To: <1343503990.21.0.184521715499.issue15481@psf.upfronthosting.co.za>
Message-ID: <1343715920.61.0.750178337341.issue15481@psf.upfronthosting.co.za>


Eric Snow added the comment:

This isn't going to be worth it.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15481>
_______________________________________

From report at bugs.python.org  Tue Jul 31 09:10:47 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Jul 2012 07:10:47 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343718647.52.0.371334222231.issue8847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I noticed when building with VC++ 2010 Express on the PGI/PGO
> builds that it warns about PGO not being available.

Even if PGO is not available, wrap_binaryfunc() and wrap_binaryfunc_l() functions get the same address when Python is compiled in "PGUpdate" mode. (I tried Visual C++ 2010 Express).

The issue was seen at least with the following versions:

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32
Python 3.2 (which version exactly?)
Python 3.3b.01, MSVC v16.00 64 bits (AMD 64) on win32

So the issue was also reproduced with old Python versions compiled with Visual C++ 2008, and I'm not sure that the "ICF" optimization is only enabled in "Profile-Guided" (PG*) modes.

If we choose to change Visual Studio options instead of changing the mode, we may also try /Gy- option:
http://msdn.microsoft.com/en-us/library/xsa71f43.aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 09:14:59 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 07:14:59 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343718899.16.0.468576312325.issue14814@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I'm looking at the docs. Started with the HOWTO (Doc/howto/ipaddress.rst)

This example:

>>> net4 = ipaddress.ip_network('192.0.2.0/24')
>>> for x in net4.iterhosts():
       print(x)

Seems to be wrong:

... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'IPv4Network' object has no attribute 'iterhosts'


I wonder if it simply needs to iterate the net4 object itself.

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 09:15:37 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 07:15:37 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343718937.98.0.0445586779431.issue14814@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

P.S. I intend to prepare patch(es) eventually, but I will document the problems I find here, in case anyone is interested to discuss.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 09:19:58 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 07:19:58 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343719198.83.0.510406934329.issue14814@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Ah, probably hosts() replaced iterhosts()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 09:36:01 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 07:36:01 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343720161.95.0.457418819489.issue14814@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Attaching a patch for the howto

----------
Added file: http://bugs.python.org/file26612/ipaddr_howto.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 09:38:45 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 31 Jul 2012 07:38:45 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1343705273.92.0.39596364479.issue8847@psf.upfronthosting.co.za>
Message-ID: <20120731093843.Horde.ErSeaqGZi1VQF4uDw3BWu8A@webmail.df.eu>


Martin v. L?wis added the comment:

> Do we even use PGO to the fullest extent?  Does someone actually build an
> instrumented Python, run training inputs on it, and then rebuild with the
> training data to take advantage of the profile-guided optimizations?

Yes, I do, on every release of Python. The test set includes at the minimum
"Tools\pybench\pybench.py -n1 -C1 --with-gc". I used to also include
"Lib\test\regrtest.py". Now, some recently added tests have slowed this down
so much that this is not feasible anymore in PGI mode.

This issue wouldn't have been reported in the first place if this  
feature wasn't
used; see also msg107124.

I don't mind just not doing it anymore; it speeds up the release process.

> If not, then I doubt PGO is buying us anything anyway.

It was originally added because people reported measurable speedups when
profile-guided optimization is used, for VS 2008.

> I noticed when building with VC++ 2010 Express on the PGI/PGO builds that it
> warns about PGO not being available.  I don't know what version we build our
> Python release bits with.

I do, of course, have at least a professional edition of Visual Studio to make
the Python releases available from www.python.org. More specifically,  
my VS 2008
installation is "Professional"; my VS 2010 installation is "Ultimate".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 09:39:03 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Jul 2012 07:39:03 +0000
Subject: [issue15511] _decimal does not build in PGUpdate mode
Message-ID: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>


New submission from Stefan Krah:

_decimal does not build in PGUpdate mode. I didn't notice this because
I've always used the Release mode so far:

msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=x64
msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platform=x64


"C:\Users\stefan\pydev\cpython\PCbuild\pcbuild.sln" (default target) (1) ->                                              
"C:\Users\stefan\pydev\cpython\PCbuild\_decimal.vcxproj" (default target) (10) ->                                        
(Link target) ->                                                                                                         
  LINK : fatal error LNK1181: cannot open input file 'C:\Users\stefan\pydev\cpython\PCbuild\\amd64\python33.lib' [C:\Use 
rs\stefan\pydev\cpython\PCbuild\_decimal.vcxproj]

----------
components: Extension Modules
messages: 166970
nosy: brian.curtin, loewis, skrah
priority: release blocker
severity: normal
stage: needs patch
status: open
title: _decimal does not build in PGUpdate mode
type: compile error
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 09:50:40 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Jul 2012 07:50:40 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <20120731093843.Horde.ErSeaqGZi1VQF4uDw3BWu8A@webmail.df.eu>
Message-ID: <20120731075041.GA22358@sleipnir.bytereef.org>


Stefan Krah added the comment:

Martin v. L??wis <report at bugs.python.org> wrote:
> > If not, then I doubt PGO is buying us anything anyway.
> 
> It was originally added because people reported measurable speedups when
> profile-guided optimization is used, for VS 2008.

For libmpdec/64-bit I've measured huge speedups in the order of 50% (with
training data).  This led me to believe that the main optimizations for
x64 are only available with PGO, perhaps as a distinguishing feature from
the Express versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:00:35 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 08:00:35 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343721635.35.0.609235244933.issue14814@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

FWIW I would prefer this HOWTO to be part of the document itself. Splitting a document to two parts and keeping them separated is problematic exactly for the same reasons as external documentation in general - it can be forgotten when things get updated.

HOWTOs are good to discuss concepts that don't pertain to a specific modules, and so there is no other "natural" place to place them. Tutorials that only discuss a single module belong in its doc page together with the reference - I think there are plenty of examples in the stdlib docs where this is the case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:03:19 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 31 Jul 2012 08:03:19 +0000
Subject: [issue15507] test_subprocess assumes SIGINT is not being ignored.
In-Reply-To: <1343680541.23.0.308681373166.issue15507@psf.upfronthosting.co.za>
Message-ID: <1343721799.9.0.879958979367.issue15507@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

Couldn't the preexec_fn argument of Popen be used instead?

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15507>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:18:07 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 08:18:07 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343722687.88.0.0693342401595.issue14814@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

The docs don't mention that addresses can also be packed in bytes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:29:58 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Jul 2012 08:29:58 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343723398.04.0.626004638379.issue14814@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

No, the HOWTO should be separate. Having them in the same document makes for something that is worse as both a tutorial and as an API reference (just look at argparse).

Yes, that means there are three places to update (code, reference, tutorial). There are three places to update regardless - the only question is whether two of those places are jammed awkwardly into the same file. Handling this will hopefully become more natural as the howto/tutorial section of the docs grows larger.

The main problem with the ipadddress docs at the moment is extracting the docstrings for the methods and including them in the reference docs in a sane way (i.e. without excessive duplication of material, as Terry and I discussed above).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:30:03 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 31 Jul 2012 08:30:03 +0000
Subject: [issue15511] _decimal does not build in PGUpdate mode
In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>
Message-ID: <1343723403.74.0.591949174462.issue15511@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I can't reproduce this. It builds fine for me. Are you sure you did PGInstrument before?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:30:34 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 31 Jul 2012 08:30:34 +0000
Subject: [issue15511] _decimal does not build in PGUpdate mode
In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>
Message-ID: <1343723434.28.0.247653834797.issue15511@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Also, can you try building from the GUI, rather than from the command line?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:30:43 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 31 Jul 2012 08:30:43 +0000
Subject: [issue15511] _decimal does not build in PGUpdate mode
In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>
Message-ID: <1343723443.07.0.196148496507.issue15511@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:31:53 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 08:31:53 +0000
Subject: [issue15512] Correct __sizeof__ support for parser
Message-ID: <1343723513.03.0.835632561476.issue15512@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for ST objects in parser module.

----------
components: Interpreter Core, Library (Lib)
files: parser_sizeof.patch
keywords: patch
messages: 166978
nosy: benjamin.peterson, storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for parser
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26613/parser_sizeof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15512>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:32:30 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 08:32:30 +0000
Subject: [issue15512] Correct __sizeof__ support for parser
In-Reply-To: <1343723513.03.0.835632561476.issue15512@psf.upfronthosting.co.za>
Message-ID: <1343723550.07.0.385421926921.issue15512@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26614/parser_sizeof-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15512>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:35:39 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 08:35:39 +0000
Subject: [issue15513] Correct __sizeof__ support for pickle
Message-ID: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for Pickler and Unpickler in pickler module.

----------
components: Library (Lib)
files: pickle_sizeof-3.3.patch
keywords: patch
messages: 166979
nosy: alexandre.vassalotti, pitrou, storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for pickle
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26615/pickle_sizeof-3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15513>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:36:04 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 08:36:04 +0000
Subject: [issue15513] Correct __sizeof__ support for pickle
In-Reply-To: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za>
Message-ID: <1343723764.44.0.820767841961.issue15513@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26616/pickle_sizeof-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15513>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:36:28 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 08:36:28 +0000
Subject: [issue15513] Correct __sizeof__ support for pickle
In-Reply-To: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za>
Message-ID: <1343723788.04.0.339042858272.issue15513@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file26617/pickle_sizeof-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15513>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:36:41 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Jul 2012 08:36:41 +0000
Subject: [issue15511] _decimal does not build in PGUpdate mode
In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>
Message-ID: <1343723801.76.0.909283688975.issue15511@psf.upfronthosting.co.za>


Stefan Krah added the comment:

_decimal-pgo.diff sort of solves the problem. It might be a good
idea to regenerate _decimal.vcproj using the GUI. I've created it
in true Unix fashion by modifying an existing vcproj...


I'm always building using the command line. If you say that the GUI
build works, I trust you of course. :)

----------
keywords: +patch
Added file: http://bugs.python.org/file26618/_decimal-pgo.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:40:04 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 08:40:04 +0000
Subject: [issue15514] Correct __sizeof__ support for cpu_set
Message-ID: <1343724004.49.0.263322089559.issue15514@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for cpu_set class in os module.

This is 3.3-only issue.

----------
components: Library (Lib)
files: cpu_set_sizeof.patch
keywords: patch
messages: 166981
nosy: loewis, storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for cpu_set
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26619/cpu_set_sizeof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15514>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:41:28 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 31 Jul 2012 08:41:28 +0000
Subject: [issue15507] test_subprocess assumes SIGINT is not being ignored.
In-Reply-To: <1343680541.23.0.308681373166.issue15507@psf.upfronthosting.co.za>
Message-ID: <1343724088.72.0.990071531856.issue15507@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Couldn't the preexec_fn argument of Popen be used instead?

Actually, since Python 3.2 you can just use "restore_signals=True".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15507>
_______________________________________

From report at bugs.python.org  Tue Jul 31 10:42:02 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Jul 2012 08:42:02 +0000
Subject: [issue15511] _decimal does not build in PGUpdate mode
In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>
Message-ID: <1343724122.72.0.0346182674761.issue15511@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
keywords: +needs review -patch
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 11:05:12 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Jul 2012 09:05:12 +0000
Subject: [issue15511] _decimal does not build in PGUpdate mode
In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>
Message-ID: <1343725512.65.0.777264053.issue15511@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Using MSVC Professional 2010 and the GUI, I'm getting the same error:

1) Select PGInstrument|x64. Clean the solution.

2) Select PGUpdate|x64. Clean the solution.

3) Select PGInstrument|x64. Build the solution.

4) Select PGUpdate|x64. Build the solution.  ->  error.


Note that PCbuild\amd64\python33.lib is not present, i.e. I did
not build Release|x64. This isn't a dependency I hope?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 11:13:55 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 09:13:55 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343726035.19.0.910588390816.issue14814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If this issue is not yet closed, here are a patch with few edits: using int.to_bytes/from_bytes instead struct.pack/unpack and using enumerate() instead range(len()).

----------
Added file: http://bugs.python.org/file26620/ipaddress-modernize.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 11:23:45 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 31 Jul 2012 09:23:45 +0000
Subject: [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>
Message-ID: <1343726625.19.0.329565614025.issue13498@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

So, IMHO if someone calls os.makedirs with a mode != 0o777, they expect to have the directories having those modes afterward. So raising no error if they exist and have the wrong mode would be a plain bug.

Python 3.3 already has a helpful error message:

FileExistsError: [Errno 17] File exists (mode 777 != expected mode 755): 'foo'

and it also handles the sticky issue gracefully: http://hg.python.org/cpython/file/3a08d766eee3/Lib/os.py#l270 

So this are an non-issues for 3.3. I'm not sure if it's severe enough to be back ported to 3.2.

So there?s only one thing left: the docs are wrong and should be fixed about exist_ok's behavior for both 3.2 & 3.3.


That said, I see the rationale for fixing the permissions but we can't just change os.makedirs at this point.

So I'd propose to add a "fix_permissions" bool flag that would allow the "no matter what the state is now, I want dir x with permissions y, do whatever is necessary workflow."

Opinions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13498>
_______________________________________

From report at bugs.python.org  Tue Jul 31 11:41:50 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 09:41:50 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343727710.03.0.126489028312.issue14814@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I disagree about the HOWTO vs. doc thing, but I don't see it as a major issue so I won't dwell on it.

I'm now in the process of throwing together a patch for the reference doc - also bundling the address objects together, the network objects together, etc.

BTW I saw there was disagreement about whether packed bytes should be accepted as addresses. ATM they are in the code, so should this be documented? I want to provide a precise documentation of what exactly is a valid address.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 12:45:05 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Jul 2012 10:45:05 +0000
Subject: [issue15511] VS 2010 "Professional": _decimal does not build in
	PGUpdate mode
In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>
Message-ID: <1343731505.95.0.210129776936.issue15511@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Ok, Microsoft dropped PGO support in VS 2010 "Professional". In
VS 2008 *Professional* it was present.

So I'll jump through the hoops of the marketing department and
install "Ultimate".


The patch is of limited value then: _decimal does build in the
"Professional" edition using PGUpdate, but using that mode is
probably pointless.

----------
title: _decimal does not build in PGUpdate mode -> VS 2010 "Professional": _decimal does not build in PGUpdate mode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 13:14:33 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Jul 2012 11:14:33 +0000
Subject: [issue15486] Standardised mechanism for stripping importlib frames
	from tracebacks
In-Reply-To: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>
Message-ID: <3WmZmR5vbdzPbV@mail.python.org>


Roundup Robot added the comment:

New changeset 62033490ca0f by Nick Coghlan in branch 'default':
Close #15486: Simplify the mechanism used to remove importlib frames from tracebacks when they just introduce irrelevant noise
http://hg.python.org/cpython/rev/62033490ca0f

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15486>
_______________________________________

From report at bugs.python.org  Tue Jul 31 13:39:57 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Jul 2012 11:39:57 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <3WmbKm4rqxzNbw@mail.python.org>


Roundup Robot added the comment:

New changeset 8a0eb395e725 by Nick Coghlan in branch 'default':
Issue #15425: Don't rely on the assumption that the current working directory is on sys.path (this will hopefully appease the XP buildbots)
http://hg.python.org/cpython/rev/8a0eb395e725

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Tue Jul 31 13:40:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Jul 2012 11:40:25 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343734825.77.0.923656661235.issue15425@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Tue Jul 31 13:56:22 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 11:56:22 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343735782.67.0.160318546006.issue14814@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Alright, attaching an attempt at improving the reference docs. This only handles the address objects for now:

1. Grouping address objects together, network objects together, interface objects together
2. Explain that everything IPv4Address exposes is also exposed by IPv6Address
3. Document v4's attributes in a generic manner
4. Document v6's specific attributes
5. Document operators
6. Precisely define the address format(s) accepted by the constructors

If this looks good to folks, I can commit and then proceed to similarly explaining the network and interface objects.

----------
Added file: http://bugs.python.org/file26621/ipaddr_refdoc.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 14:03:04 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 31 Jul 2012 12:03:04 +0000
Subject: [issue15498] Eliminate the use of deprecated OS X APIs in getpath.c
In-Reply-To: <1343633664.98.0.256476653975.issue15498@psf.upfronthosting.co.za>
Message-ID: <1343736184.46.0.527657145038.issue15498@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Removing the dependency on NSLookupAndBindSymbol (and related APIs) is easier than I expected.

The attached patch (issue15498-v1.txt) uses dladdr to get symbol information for Py_Initialize and that information includes the path for the library where that symbol is located (that is the framework).

The patch has seen only light testing, in particular: I've verified that the library path has the expected value, but haven't run the full test suite set.

TODO:
- Run test full test suite with a framework build (both before and after
  installing)
- Likewise for a regular unix build
- Likewise for a regular unix build with --enable-shared

This patch should work on OSX 10.4 or later, and may also work on OSX 10.3, the manpage for dladdr is not entirely clear on whether or not the symbol is available in libSystem on OSX 10.3.

----------
keywords: +needs review
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26622/issue15498-v1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15498>
_______________________________________

From report at bugs.python.org  Tue Jul 31 14:15:28 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 31 Jul 2012 12:15:28 +0000
Subject: [issue13759] Python 3.2.2 Mac installer version doesn't accept
	multibyte character in interactive mode
In-Reply-To: <1326267416.18.0.541225422796.issue13759@psf.upfronthosting.co.za>
Message-ID: <1343736928.21.0.176388872519.issue13759@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

To reproduce this issue you could use the "Unicode Hex Input" input source (enable this in the Language & Text prefpane, switch between sources either using CMD-space or the menu bar icon).

I can "?" by keeping ALT pressed and typing 3042.

This works fine with a self-built version of 3.2 (tip of tree), I haven't tested the 3.2 binary installer (yet).

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13759>
_______________________________________

From report at bugs.python.org  Tue Jul 31 14:18:47 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 31 Jul 2012 12:18:47 +0000
Subject: [issue11486] Add option to not install into /Applications
In-Reply-To: <1300051941.49.0.427500618783.issue11486@psf.upfronthosting.co.za>
Message-ID: <1343737127.9.0.941669297559.issue11486@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
keywords: +needs review
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11486>
_______________________________________

From report at bugs.python.org  Tue Jul 31 14:21:05 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 31 Jul 2012 12:21:05 +0000
Subject: [issue13371] Some Carbon extensions don't build on OSX 10.7
In-Reply-To: <1320762505.71.0.135818589622.issue13371@psf.upfronthosting.co.za>
Message-ID: <1343737265.47.0.0560362181835.issue13371@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Patch is already applied (ages ago), forgot to close this issue.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13371>
_______________________________________

From report at bugs.python.org  Tue Jul 31 14:22:44 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Jul 2012 12:22:44 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343737364.79.0.341739728117.issue14814@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks Eli, that looks like a great start to me.

And yeah, the separate vs integrated tutorial argument is an ongoing one that isn't going to be resolved by this issue :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 14:46:39 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Jul 2012 12:46:39 +0000
Subject: [issue15511] _decimal does not build in PGUpdate mode
In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>
Message-ID: <1343738799.42.0.274467079941.issue15511@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Well, I have Ultimate now and encounter the same problem. Also, when
I start PCbuild\x64-pgi\python.exe it exits immediately without
displaying an error.


The PC\VS9.0 PGUpdate build works fine.

----------
title: VS 2010 "Professional": _decimal does not build in PGUpdate mode -> _decimal does not build in PGUpdate mode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 14:59:17 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 31 Jul 2012 12:59:17 +0000
Subject: [issue12507] tkSimpleDialog problem
In-Reply-To: <1309972491.94.0.855067439806.issue12507@psf.upfronthosting.co.za>
Message-ID: <1343739557.53.0.50719489784.issue12507@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Closing because this issue is a bug in Tk, not a bug in Python.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12507>
_______________________________________

From report at bugs.python.org  Tue Jul 31 15:08:04 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Jul 2012 13:08:04 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343740084.76.0.0632744992859.issue15295@psf.upfronthosting.co.za>


Brett Cannon added the comment:

While saying "default path importer" vs. "meta path finder" somewhat muddles the term "importer", it definitely gets the point across that PathFinder does a lot more than any other default meta path finder. While _we_ might know that import does nothing more than call a method on sys.meta_path and has no concept of sys.path and friends, most people will consider the default path importer as part of import's semantics and thus not make the distinction.

IOW I like Nick's suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 16:03:07 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 31 Jul 2012 14:03:07 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1343538647.87.0.343802121082.issue15295@psf.upfronthosting.co.za>
Message-ID: <20120731100305.130fce9d@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Jul 29, 2012, at 05:10 AM, Nick Coghlan wrote:

>I would title the new section "Import system" rather than "Import machinery"
>as it is meant to be a specification documentation rather than an
>implementation description.

"Import system" it is.

>The statement that "from X import A" only performs a single import lookup is
>incorrect. The trick is that if A, B or C refers to a submodule of X then it
>will be imported.

I think I see where you and Eric are coming from on this.  Actually, I don't
think I changed the existing text in this regard, but probably once I
refactored out all the details, it reads in such a way as to be confusing.
I've tweaked the text under the import statement to hopefully be more clear.
It could probably still use improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 16:04:10 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 31 Jul 2012 14:04:10 +0000
Subject: [issue15511] _decimal does not build in PGUpdate mode
In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>
Message-ID: <1343743450.84.0.611868852379.issue15511@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Make sure you clean all build directories; then rebuild.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 16:07:42 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 31 Jul 2012 14:07:42 +0000
Subject: [issue15511] _decimal does not build in PGUpdate mode
In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>
Message-ID: <1343743662.82.0.138919261027.issue15511@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

"clean" = "manually delete, e.g. from explorer"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 16:22:22 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 14:22:22 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343744542.4.0.545768219648.issue14814@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks Nick. I've addressed your review comments and will be pushing the doc update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 16:23:34 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Jul 2012 14:23:34 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3WmfyX6FJTzPQf@mail.python.org>


Roundup Robot added the comment:

New changeset 586eb57e06ba by Eli Bendersky in branch 'default':
Issue #14814: reorganize ipaddress documentation and document all attributes of IPv[46]Address objects
http://hg.python.org/cpython/rev/586eb57e06ba

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 16:25:53 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Jul 2012 14:25:53 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <3Wmg1C6BXSzPQf@mail.python.org>


Roundup Robot added the comment:

New changeset 07ddf5ecaafa by Eli Bendersky in branch 'default':
Issue #14814: fix some typos in howto/ipaddress.rst
http://hg.python.org/cpython/rev/07ddf5ecaafa

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 16:32:13 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 14:32:13 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343745133.37.0.590552776676.issue14814@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

By the way, Nick, was not this module intended to be introduced as provisional in 3.3? At least PEP 411 lists it as one of the candidates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 16:55:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 14:55:57 +0000
Subject: [issue14803] Add feature to allow code execution prior to __main__
	invocation
In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>
Message-ID: <1343746557.77.0.765452759861.issue14803@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> However, the -C option doesn't cover the case of *implicit* invocation of subprocesses. This is where the PYTHONRUNFIRST suggestion comes in

Would a more general solution than PYTHONRUNFIRST be something like a suitably named PYTHONRUNINSTEAD? This would be an arbitrary script to run in place of python any time python was invoked. Alternatively (and less powerfully), it could be a default set of command options to pass to the Python executable.  Both of these seem more general than PYTHONRUNFIRST because the 'runas' command could itself be `python -C $PYTHONRUNFIRST ....`

> unless -E is specified, then -C $PYTHONRUNFIRST would be implied. To be honest, I *don't* think this latter capability should be built into the core implementation.... so that it doesn't inadvertently affect invocation of other applications (like hg)

It seems what you're saying is that you'd want PYTHONRUNFIRST to run only in special situations, rather than as the default.  Is there a sense then in which a functionality inverse to -E could be provided?  The idea would be that, when running Python, you could somehow instruct that an option like PYTHONRUN* would take effect only for the subprocesses spawned by the main process you're invoking (kind of like a context manager for the invocation of Python itself)?

The advantage of this approach would be that a special PYTHONRUNFIRST setting wouldn't take effect unless you explicitly say so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14803>
_______________________________________

From report at bugs.python.org  Tue Jul 31 16:56:49 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 14:56:49 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343746609.85.0.222490754463.issue15295@psf.upfronthosting.co.za>


Eric Snow added the comment:

Part of the problem with the import nomenclature is that PEP 302 doesn't really nail it down and mixes the terms up a bit.  This is understandable considering it broken ground in some regard.  However, at this point we have a more comfortable relationship with the import system.  Would it be feasible to lightly update PEP 302 to have a more concrete and consistent use of import terminology?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 17:20:40 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Jul 2012 15:20:40 +0000
Subject: [issue15511] _decimal does not build in PGUpdate mode
In-Reply-To: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>
Message-ID: <1343748040.39.0.0494733038188.issue15511@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Building from a fresh tree enables successful launching of PCbuild\x64-pgi\python.exe,
but _decimal is still not built. I literally ran the following commands,
so anyone can paste them into a command window and see for themselves:


# cpython is a pristine clone
hg clone cpython cpython-test
cd cpython-test
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=x64
msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platform=x64


"C:\Users\stefan\pydev\cpython-test\PCbuild\_decimal.vcxproj" (default target) (10) ->                            
(Link target) ->                                                                                                  
  LINK : fatal error LNK1181: cannot open input file 'C:\Users\stefan\pydev\cpython-test\PCbuild\\amd64\python33. 
lib' [C:\Users\stefan\pydev\cpython-test\PCbuild\_decimal.vcxproj]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15511>
_______________________________________

From report at bugs.python.org  Tue Jul 31 17:23:00 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 31 Jul 2012 15:23:00 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1343542183.14.0.0311024413828.issue15295@psf.upfronthosting.co.za>
Message-ID: <20120731112259.45e61497@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Jul 29, 2012, at 06:09 AM, Nick Coghlan wrote:

>runpy, pkgutil, et al should all get "See Also" links at the top pointing to
>the new import system section.

I've put an XXX in the import.rst file for this, but I probably won't get to
adding all the cross references.  Others can take that on once this lands.

>Opening section should refer to importlib.import_module(). Any mentions of
>__import__ should point out that its API is designed for the convenience of
>the interpreter, and thus it's a pain to use directly. However, we should
>also document explicitly that, unlike the import statement and calling
>__import__ directly, importlib.import_module will ignore any module level
>replacements of __import__.
>
>Replacing builtins.__import__ won't reliably override the entire import
>system (due to module level __import__ definitions, most notably
>importlib.__import__) and other tools that work with the process global
>import state directly (e.g. pkgutil, runpy).

While I've added a mention of import_module() in several places, I don't think
the above detail is appropriate for the introduction.  I don't want to
overload folks with all those details before they understand the basics of
Python's import model.

I would much rather add a section that goes into more detail about coarsely
overriding the import system, and there we can discuss replacing built-in
__import__() along with its implications and caveats, including any behavior
changes in Python 3.3 with the adoption of importlib.  I probably won't get to
that so feel free to add such a section later.

>Since we have the privilege of defining *the* standard terminology for
>old-style packages, I suggest we use the term "initialised" packages (since
>having an __init__.py is what makes them special). We should also note
>explicitly that an initialised package can also behave as a namespace
>package, by setting __path__ appropriately in __init__.py

I don't like the term "initialized package" (even with the Americanized
spelling :), because the term "initialized" means "set to the value or put in
the condition appropriate to the start of an operation", which clearly refers
to both types of packages.

What about "concrete package"?  In a sense, namespace packages are virtual, so
the opposite of that would be concrete.  OTOH, while "regular package" may
still not be the right term, it might be good enough.  The bike shed is
already looking pretty tie-died.

>Finally, I think this section needs to explicitly define the terms *import
>path* and *path entry*. The meta path docs later refer to find_module()
>accepting a module name and path, and the reader could be forgiven for
>thinking that meant a filesystem path, when it is actually an import path
>(which is a sequence of path entries, which may themselves by filesystem
>paths).

This is getting somewhere.  I like using the term "path importer" for the
thing that PathFinder is.  ("path finder" doesn't quite do it for me, but
maybe I'm clouded by same term used as a car model. ;)

What we have are several default finders, one that knows how to locate frozen
modules, one that knows how to locate built-in modules, and one that knows how
to search an "import path" (which consists of "path entries").  This latter
finder is the "path importer" and it has further extensibility so that new
types of path entries can be used.  A path entry is a location to search for
modules, and sequences of path entries exist on import paths.  When a search
occurs, typically the import path is taken from sys.path, but for subpackages,
it is taken from the __path__ attribute of its parent package.

This seems to make for much better reading, and while I've worded it
differently to fit better in the flow of the documentation, it's terminology
that feels more right to me.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 17:42:10 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Jul 2012 15:42:10 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343749330.92.0.935113251368.issue8847@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Here's a patch based on the analysis. All test cases given here
now raise TypeError.

----------
keywords: +patch
Added file: http://bugs.python.org/file26623/issue8847.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 17:52:33 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 15:52:33 +0000
Subject: [issue15490] Correct __sizeof__ support for StringIO
In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za>
Message-ID: <1343749953.88.0.538958971763.issue15490@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Do I understand correctly that for each Python subobject must be one of the following:
1) or it is visited in tp_traverse;
2) or it is accounted in __sizeof__ together with all its subobjects (if they cannot leak out)?

PyAccu can contains not only Unicode objects, but at least an instance of a Unicode subtype, which can has a reference to StringIO object, creating a cycle. Does this mean that PyAccu should be visited in tp_traverse and not be accounted in __sizeof__? Or should we tighten the control and ensure that PyAccu contains only exact Unicode objects?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15490>
_______________________________________

From report at bugs.python.org  Tue Jul 31 18:03:34 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 31 Jul 2012 16:03:34 +0000
Subject: [issue3177] Add shutil.open
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1343750614.61.0.0159128746572.issue3177@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

MacOSX provides functionality simular to os.startfile in the LaunchServices framework. 

I've tried to prototype a startfile implementation using this framework, (see issue3177-os_startfile_macosx.txt) but I'm not too happy about it because the APIs don't actually work as expected.

In particular:

* The patch implements "open" (default), "edit", "print" and
  "explore" actions.

* "open" and "explore" work fine

* "edit" does not work as I'd expect because the function used
   to retrieve the default editor for a file returns the default
   application that can open the file, not necessarily one that
   claims to be an editor for the file-type. As an example, 
   'os.startfile("file.html", "edit")' starts Safari instead of
   an editor.

* "print" works for some file type, but not others (depending on 
  whether or not the target application implements the required
  AppleScript API)

* "execute" is untested, I haven't found an application yet that claims
  this role.

Other notes:

* This patch links Python with the ApplicationServices framework
  (which contains the LaunchServices framework)

* Because the API uses Apple's application frameworks users might get
  annoying crashes when calling this function in a subprocess.

* The code attached code is a prototype, it should be correct w.r.t.
  resource management, but isn't fully baked yet. One example of that
  is the use of a generic RuntimeError exception to signal problems,
  others are the lack of documentation and tests.

----------
nosy: +ronaldoussoren
Added file: http://bugs.python.org/file26624/issue3177-os_startfile_macosx.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Tue Jul 31 18:08:19 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 31 Jul 2012 16:08:19 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1343750899.1.0.481086486424.issue10812@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

msg126598  says that waitid is broken on MacOSX. In what way it is broken? 

The code is currently disabled for OSX without any indication why this is so, that makes it hard to know how to test if new OSX releases (like the just released OSX 10.8) fix waitid.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Tue Jul 31 18:12:28 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 16:12:28 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343751148.32.0.444192581537.issue15425@psf.upfronthosting.co.za>


Eric Snow added the comment:

Looks like both XP buildbots are happy now.  (one is failing, but not for test_import).

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Tue Jul 31 18:13:10 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 16:13:10 +0000
Subject: [issue15425] Another strange Tracebacks with importlib
In-Reply-To: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>
Message-ID: <1343751190.82.0.0284294585521.issue15425@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15425>
_______________________________________

From report at bugs.python.org  Tue Jul 31 18:24:57 2012
From: report at bugs.python.org (Thomas Wouters)
Date: Tue, 31 Jul 2012 16:24:57 +0000
Subject: [issue15507] test_subprocess assumes SIGINT is not being ignored.
In-Reply-To: <1343680541.23.0.308681373166.issue15507@psf.upfronthosting.co.za>
Message-ID: <1343751897.66.0.293969468253.issue15507@psf.upfronthosting.co.za>


Thomas Wouters added the comment:

No, using preexec_fn leaves all kinds of races when mixing threads and processes (which is a bad idea, but people still sometimes do.) And no, restore_signals doesn't fix this; restore_signals only resets the signals the *Python interpreter itself* ignored: SIGFPE, SIGXFZ and SIGFSZ (and it defaults to True anyway.) It doesn't affect other signals at all, even if Python code ignored them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15507>
_______________________________________

From report at bugs.python.org  Tue Jul 31 18:29:22 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 31 Jul 2012 16:29:22 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1343752162.43.0.770583020884.issue10812@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

To elaborate: when I remove the "&& !defined(__APPLE__)" tests from posixmodule.c test_posix passes on OSX 10.8, including test_waitid.

I have no idea if this means that waitid is no longer "broken" in OSX 10.8 or that test_posix doesn't trigger the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Tue Jul 31 18:35:15 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 31 Jul 2012 16:35:15 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1343752515.21.0.446906365928.issue10812@psf.upfronthosting.co.za>


Ross Lagerwall added the comment:

I can't actually remember why I disabled waitid for OS X - that was message was rather a long time ago :-(

Unfortunately, I don't currently have access to an OS X machine to test it.

A google search shows the following comment in the v8 javascript engine:
// We're disabling usage of waitid in Mac OS X because it doens't work for us:
// a parent process hangs on waiting while a child process is already a zombie.
// See http://code.google.com/p/v8/issues/detail?id=401.

Do you have access to test an older release like Leopard?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Tue Jul 31 18:48:56 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 31 Jul 2012 16:48:56 +0000
Subject: [issue15510] textwrap.wrap('') returns empty list
In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za>
Message-ID: <1343753336.95.0.941180964689.issue15510@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

I think this is a bug.

Could you possibly write a patch for 2.7, 3.2 and 3.3?. With a test :-)

I am worried about changing a behaviour that somebody is depending of. Opinions?

Adding a couple of persons I think that could have an opinion about this.

----------
nosy: +gward, jcea, twouters
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15510>
_______________________________________

From report at bugs.python.org  Tue Jul 31 18:52:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Jul 2012 16:52:49 +0000
Subject: [issue9803] IDLE closes with save while breakpoint open
In-Reply-To: <1283974949.4.0.785258120567.issue9803@psf.upfronthosting.co.za>
Message-ID: <3WmkGm0pwVzPc6@mail.python.org>


Roundup Robot added the comment:

New changeset 47536beb7453 by Andrew Svetlov in branch '3.2':
Issue #9803: Don't close IDLE on saving if breakpoint is open.
http://hg.python.org/cpython/rev/47536beb7453

New changeset 28c935ded243 by Andrew Svetlov in branch 'default':
Issue #9803: Don't close IDLE on saving if breakpoint is open.
http://hg.python.org/cpython/rev/28c935ded243

New changeset 8f1a8e80f330 by Andrew Svetlov in branch '2.7':
Issue #9803: Don't close IDLE on saving if breakpoint is open.
http://hg.python.org/cpython/rev/8f1a8e80f330

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9803>
_______________________________________

From report at bugs.python.org  Tue Jul 31 18:54:06 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 31 Jul 2012 16:54:06 +0000
Subject: [issue9803] IDLE closes with save while breakpoint open
In-Reply-To: <1283974949.4.0.785258120567.issue9803@psf.upfronthosting.co.za>
Message-ID: <1343753646.69.0.754622908745.issue9803@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Thanks, Roger!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9803>
_______________________________________

From report at bugs.python.org  Tue Jul 31 19:09:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 17:09:57 +0000
Subject: [issue15510] textwrap.wrap('') returns empty list
In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za>
Message-ID: <1343754597.89.0.282887075145.issue15510@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Could you possibly write a patch for 2.7, 3.2 and 3.3?. With a test :-)

I would be happy to write a patch with tests (I think there may be a few edge cases we would want to test here).  Should be ready within the next one or two days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15510>
_______________________________________

From report at bugs.python.org  Tue Jul 31 19:55:29 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 31 Jul 2012 17:55:29 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1343757329.53.0.414924751693.issue10812@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I have VMs with earlier versions of OSX (at least 10.5 and 10.6). I cannot run those right now because they use enough resources to interfere with other activities. I'll try to test later this week.

BTW. I'd prefer to make waitid available on OSX unless it is totally non-functional. I'm not convinced that the Google problem is a good enough reason to avoid exposing the function.  If it is disabled there should be a clear description of why that is, preferable in the form of a (configure) test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Tue Jul 31 20:06:58 2012
From: report at bugs.python.org (Chris Calloway)
Date: Tue, 31 Jul 2012 18:06:58 +0000
Subject: [issue15454] Allow dircmp.report() output stream to be customized
In-Reply-To: <1343288932.25.0.229744443043.issue15454@psf.upfronthosting.co.za>
Message-ID: <1343758018.09.0.603602674726.issue15454@psf.upfronthosting.co.za>


Chris Calloway added the comment:

At the PyOhio sprints, I noticed this issue and found it interesting for low hanging fruit. First I went to make tests for this enhancement, only to find that report(), report_partial_closure(), and report_full_closure did not already have tests.

In adding tests for these methods, I also found that dircmp is only tested for one directory level, leaving out coverage for a pretty wide swath of dircmp.

The first patch I'm submitting here is just for the report methods for the level of dircmp testing which already exists. A subsequent patch will test the report methods a couple of directory levels deep to get full coverage for report_full_closure().

Even if this enhancement is not accepted, the report methods do need tests. I'm putting this patch here in advance of any other work to get feedback on the flavor of tests I have given the report methods on the existing one directory level of dircmp testing before proceeding with any deeper testing.

The tests in this patch all pass with the existing filecmp code without adding any significant execution time to test_filecmp.

Any deeper testing  of dircmp will also have to not be necessarily comprehensive, as the permutations of test inputs start to become too time-consuming. setUp and tearDown may also need some refactoring for deeper testing.

Should adding tests for the report methods be a separate issue from this enhancement?

----------
keywords: +patch
Added file: http://bugs.python.org/file26625/issue-15454-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15454>
_______________________________________

From report at bugs.python.org  Tue Jul 31 20:07:55 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 18:07:55 +0000
Subject: [issue14814] Implement PEP 3144 (the ipaddress module)
In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>
Message-ID: <1343758075.72.0.519164571184.issue14814@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Attaching part 1 of the patch for documenting the network objects. Contains general introduction, detailed documentation of constructors and all attributes.

Left to document: methods, operations (like iterating, "in", comparison operators)

----------
Added file: http://bugs.python.org/file26626/ipaddr_refdoc_network.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14814>
_______________________________________

From report at bugs.python.org  Tue Jul 31 20:08:58 2012
From: report at bugs.python.org (Caleb Rouleau)
Date: Tue, 31 Jul 2012 18:08:58 +0000
Subject: [issue15515] Regular expression match does not return
Message-ID: <1343758138.43.0.559829332434.issue15515@psf.upfronthosting.co.za>


New submission from Caleb Rouleau:

Version info: 2.7.1 (r271:86832, Feb  7 2011, 11:33:02) [MSC v.1500 64 bit (AMD64)]

The program included never prints "done" because it never returns from re.match(). 

 -- Caleb Rouleau

----------
components: Regular Expressions
files: RegexBug.py
messages: 167024
nosy: crouleau, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Regular expression match does not return
versions: Python 2.7
Added file: http://bugs.python.org/file26627/RegexBug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15515>
_______________________________________

From report at bugs.python.org  Tue Jul 31 20:26:02 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 18:26:02 +0000
Subject: [issue15454] Allow dircmp.report() output stream to be customized
In-Reply-To: <1343288932.25.0.229744443043.issue15454@psf.upfronthosting.co.za>
Message-ID: <1343759162.63.0.680983470624.issue15454@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Should adding tests for the report methods be a separate issue from this enhancement?

Yes, I would create separate issues for this.  I would even recommend separating this into one issue for the report() methods (could be done first), and another issue for adding tests for additional directory levels (see additional note below).

> Any deeper testing of dircmp will also have to not be necessarily comprehensive, as the permutations of test inputs start to become too time-consuming. setUp and tearDown may also need some refactoring for deeper testing.

For testing additional directory levels, you may want to wait until after issue 15403 is complete, which is slated for (hopefully) shortly after the 3.3 release.  That issue will add functions for the easy creation of arbitrarily nested directories of files, etc.  You will see I made a comment there about application to the filecmp tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15454>
_______________________________________

From report at bugs.python.org  Tue Jul 31 20:28:34 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 18:28:34 +0000
Subject: [issue15450] Allow dircmp.subdirs to behave well under subclassing
In-Reply-To: <1343260803.75.0.101432828571.issue15450@psf.upfronthosting.co.za>
Message-ID: <1343759314.0.0.695787627217.issue15450@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +cbc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15450>
_______________________________________

From report at bugs.python.org  Tue Jul 31 20:29:55 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 Jul 2012 18:29:55 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343759395.23.0.639096908833.issue8847@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I presume the previously crashing test cases should be added to the test suite, to detect reversion. Is there a method (faulthandler?) to keep tests going, or stop gracefully, when adding a once-crasher that could revert?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 20:42:10 2012
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 31 Jul 2012 18:42:10 +0000
Subject: [issue12370] Use of super overwrites use of __class__ in class
	namespace
In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za>
Message-ID: <1343760130.3.0.396305449597.issue12370@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12370>
_______________________________________

From report at bugs.python.org  Tue Jul 31 20:43:01 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 31 Jul 2012 18:43:01 +0000
Subject: [issue11486] Add option to not install into /Applications
In-Reply-To: <1300051941.49.0.427500618783.issue11486@psf.upfronthosting.co.za>
Message-ID: <1343760181.09.0.0618924154291.issue11486@psf.upfronthosting.co.za>


Ned Deily added the comment:

That would be nice although if you use your documented trick in Mac/README:

    ./configure --enable-framework=/Users/ronald/Library/Frameworks

everything including the Applications directory is installed relative to the frameworks directory, so, in this case, /Users/ronald/Applications.  It seems to work really well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11486>
_______________________________________

From report at bugs.python.org  Tue Jul 31 20:53:46 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 31 Jul 2012 18:53:46 +0000
Subject: [issue15502] Meta path finders and path entry finders are different, 
	but share an ABC
In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za>
Message-ID: <1343760826.15.0.00392866405908.issue15502@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/issue15502>
_______________________________________

From report at bugs.python.org  Tue Jul 31 20:59:38 2012
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 31 Jul 2012 18:59:38 +0000
Subject: [issue15515] Regular expression match does not return
In-Reply-To: <1343758138.43.0.559829332434.issue15515@psf.upfronthosting.co.za>
Message-ID: <1343761178.93.0.162421814441.issue15515@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

That's because it uses a pathological regular expression (catastrophic backtracking).

The problem lies here: (\\?[\w\.\-]+)+

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15515>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:06:45 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 31 Jul 2012 19:06:45 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1343684477.77.0.647520030121.issue15295@psf.upfronthosting.co.za>
Message-ID: <20120731150644.001a18b0@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Jul 30, 2012, at 09:41 PM, Brett Cannon wrote:

>As for the diagram(s), I have attached the overall PDF that I still have from
>my original Omnifgraffle file (which I don't have a license to anymore) that
>I built my PyCon 2008 presentation with. It's probably outdated at this
>point. I will have to redo them for my PyCon Argentina/Brasil (maybe US?)
>import talks anyway.

Thanks.  This isn't quite the level I was looking for, but we can add a
diagram later.

(I think I've improved the discussion on __package__ based on your feedback
and PEP 366.  Thanks!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:14:37 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 31 Jul 2012 19:14:37 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1343694484.08.0.513510031013.issue15295@psf.upfronthosting.co.za>
Message-ID: <20120731151436.4c63a071@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Jul 31, 2012, at 12:28 AM, Eric Snow wrote:

>> You ask in [2] whether "path importer" refers specifically to the callables
>> on sys.path_hooks.  Can you site a reference for this?  I found one
>> reference in PEP 302 to "path importer" but it's hard to tell exactly what
>> that is referring to.
>
>Unfortunately not.  There aren't many people that use import hook terminology
>and I already have a terrible memory. :) Regardless, I find "path importer" a
>little too ambiguous.

Dang.  I've grown to really like "path importer" for the thing on
sys.meta_path that provides sys.path and related functionality.  It seems
appropriate given the observation that we're talking about sys.path or
__path__ and what this thing does is manage that corner of the import
subsystem.

Thinking about Nick's suggestion then, the callables on sys.path_hooks would
be "path entry finders" since they are given a chance to find modules for each
entry on the import path (be it sys.path or __path__).

I think this terminology holds together well, and I think I'm going to land it
as such.  Then we can promote this terminology as we talk about the import
system in other documentation.

>>>* (glossary.rst) sys path finder: having "sys" is a nice touch, making it more distinct and more explicit.
>>
>> TBH, I'm not crazy about the term "sys path finder" either but I couldn't
>> think of anything better.
>
>What don't you like about the "sys path thingee" names?  I find them to be
>nice and explicit.  I'll mull this over some more.

Nick put his finger on it.  "sys path" implies that only sys.path is involved,
whereas __path__ is also involved.

>>>* (import_machinery.rst) Meta path loaders, end of paragraph 2: "The finder
>>>* could also be a classmethod that returns an instance of the class."
>>
>> I don't understand what you're suggesting here.
>
>Yeah, that was poorly worded.  I'd meant to suggest that you could document
>the alternative to find_module() and load_module() being regular methods of
>the same object.  For instance:
>
>class MyMetaHook:
>    @classmethod
>    def find_module(cls, name, path=None):
>        return cls()
>    def load_module(self, name):
>        raise ImportError("You lose!")
>
>Thus, the "finder" is the class, and the "loader" is the instance.

While true, it's not required in the specification, so I'd like to leave this
out.  Smart Pythonistas can figure details like that out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:14:56 2012
From: report at bugs.python.org (Tim Peters)
Date: Tue, 31 Jul 2012 19:14:56 +0000
Subject: [issue15515] Regular expression match does not return
In-Reply-To: <1343758138.43.0.559829332434.issue15515@psf.upfronthosting.co.za>
Message-ID: <1343762096.39.0.672429555027.issue15515@psf.upfronthosting.co.za>


Tim Peters added the comment:

Matthew is right:  the nested quantifiers can cause this to take a very long time when the regexp doesn't match.  Note that the example cannot match, because nothing in the regexp can match the space before "warning" in the example string.  But the nested quantifiers cause it to _try_ an enormous number of futile attempts.

Under Python 2.7.1, it eventually does return, but it took over 15 minutes when I tried it on my laptop.

Friedl's book "Mastering Regular Expressions" is a book-length treatment of how to write regexps that don't "take forever" when they fail to match, and that's highly recommended.  Or start a discussion on comp.lang.python, and I'm sure someone will help you flesh out exactly what it is you do and don't want to match, and how to write a regexp that performs well on both matching and non-matching text (the bug tracker isn't an appropriate place for this).

----------
nosy: +tim_one
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15515>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:21:22 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Jul 2012 19:21:22 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343762482.15.0.365523672134.issue15295@psf.upfronthosting.co.za>


Eric Snow added the comment:

Well, I'm more -0 than -1 on "path importer", though I do like "default path importer" better.  As to the rest,  sounds good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:33:39 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 31 Jul 2012 19:33:39 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1343749330.92.0.935113251368.issue8847@psf.upfronthosting.co.za>
Message-ID: <1343763072.3678.0.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Here's a patch based on the analysis. All test cases given here
> now raise TypeError.

I think we want to add those tests to the test suite as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:34:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 31 Jul 2012 19:34:54 +0000
Subject: [issue15490] Correct __sizeof__ support for StringIO
In-Reply-To: <1343749953.88.0.538958971763.issue15490@psf.upfronthosting.co.za>
Message-ID: <1343763151.3678.1.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Does this mean that PyAccu should be visited in tp_traverse and not be
> accounted in __sizeof__? Or should we tighten the control and ensure
> that PyAccu contains only exact Unicode objects?

IMO, the latter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15490>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:44:58 2012
From: report at bugs.python.org (Caleb Rouleau)
Date: Tue, 31 Jul 2012 19:44:58 +0000
Subject: [issue15515] Regular expression match does not return
In-Reply-To: <1343758138.43.0.559829332434.issue15515@psf.upfronthosting.co.za>
Message-ID: <1343763898.78.0.339822457756.issue15515@psf.upfronthosting.co.za>


Caleb Rouleau added the comment:

Thanks for the help. Apologies for the poor understanding of regular expressions. Closing this issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15515>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:46:57 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Jul 2012 19:46:57 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1343763072.3678.0.camel@localhost.localdomain>
Message-ID: <20120731194650.GA27974@sleipnir.bytereef.org>


Stefan Krah added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> I think we want to add those tests to the test suite as well.

What's a good place? Shall we just add one of the tests to test_tuple?

Also, the only person to run the tests with the PGO build will probably
be Martin just before the releases. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:48:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 31 Jul 2012 19:48:20 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <20120731194650.GA27974@sleipnir.bytereef.org>
Message-ID: <1343763951.3678.2.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Antoine Pitrou <report at bugs.python.org> wrote:
> > I think we want to add those tests to the test suite as well.
> 
> What's a good place? Shall we just add one of the tests to test_tuple?

Sounds good. And another of them to test_list perhaps as well :)

> Also, the only person to run the tests with the PGO build will probably
> be Martin just before the releases. :)

True, but other people may still run them *after* the release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:48:37 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 19:48:37 +0000
Subject: [issue15515] Regular expression match does not return
In-Reply-To: <1343758138.43.0.559829332434.issue15515@psf.upfronthosting.co.za>
Message-ID: <1343764117.01.0.860971818536.issue15515@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Make a distinction between a large number of infinity. You have a bad regexp, the matching time depends exponentially on the length of the string. Try with short strings. Use the regexp r"(\w:)(\\?[\w\.\-]+)((\\[\w\.\-]+)*)(\.[\w ]+): ".

It's not a bug.

----------
nosy: +storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15515>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:51:40 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Jul 2012 19:51:40 +0000
Subject: [issue15502] Meta path finders and path entry finders are different, 
	but share an ABC
In-Reply-To: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za>
Message-ID: <1343764300.78.0.600412700354.issue15502@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So I think Nick has the inheritance inverted and I would have Finder inherit from everything to stay backwards-compatible and to ease future deprecation (which could potentially happen starting in Python 3.3), although my approach weakens the usefulness of the ABCs to the point that Nick is probably right in the end. =)

Ideally you would have MetaPathFinder which has find_module(fullname, path). Nnotice there is no default value for path since meta path finders always have something passed in for 'path', even if it's None.

The other ABC would be PathImporter which defines find_loader(fullname). Notice how 'path' is no longer defined as it isn't used by PathFinder when calling a path importer.

importlib.abc.Finder would then inherit from both MetaPathFinder and PathImporter. This is because if someone wants to be compatible with both Python 3.2 and 3.3 without any trickery, they will want to simply inherit from Finder for either a meta path finder or a path importer. Otherwise in Python 3.2 you would have to do some conditional work or define a fake e.g. MetaPathFinder ABC in order to inherit from the new ABCs.

Finder would have find_module(fullname, path=None) defined but returning None by default. It would also inherit from PathImporter, but this is where it gets tricky since importlib decides whether to call find_loader() based on whether find_loader() is defined, which means PathImporter couldn't require it to instantiated. Otherwise some hack will be needed in Finder for it to claim that find_loader() is defined but while still failing a hasattr() check (which I can't think of how to do; maybe some insane metaclass which temporarily sets find_loader() so abstractmethod doesn't complain but then isn't defined in the end so __getattr__ still raises an AttributeError?).

IOW I don't see an ideal situation here and we will probably want to do what Nick suggested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15502>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:52:53 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 31 Jul 2012 19:52:53 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1343694484.08.0.513510031013.issue15295@psf.upfronthosting.co.za>
Message-ID: <20120731155251.0dcf0ede@limelight.wooz.org>


Barry A. Warsaw added the comment:

I think I was unclear in my previous follow up.  Here are the objects
involved, taken from the glossary.

   import path
      A list of locations (or :term:`path entries <path entry>`) that are
      searched by the :term:`path importer` for modules to import.  During
      import, this list of locations usually comes from :data:`sys.path`, but
      for subpackages it may also come from the parent package's ``__path__``
      attribute.

   meta path finder
      A finder returned by a search of :data:`sys.meta_path`.  Meta path
      finders are related to, but different from :term:`path entry finders
      <path entry finder>`.

   path entry
      A single location on the :term:`import path` which the :term:`path
      importer` consults to find modules for importing.

   path entry finder
      A :term:`finder` returned by a callable on :data:`sys.path_hooks`
      (i.e. a :term:`path entry hook`) which knows how to locate modules given
      a :term:`path entry`.

   path entry hook
      A callable on the :data:`sys.path_hook` list which returns a :term:`path
      entry finder` if it knows how to find modules on a specific :term:`path
      entry`.

   path importer
      One of the default :term:`meta path finders <meta path finder>` which
      searches an :term:`import path` for modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:57:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 31 Jul 2012 19:57:25 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343764645.56.0.505312415228.issue15295@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Shouldn't it be committed already? I don't see the point of refining documentation in a separate repo rather than in the main repo.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:58:13 2012
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 31 Jul 2012 19:58:13 +0000
Subject: [issue15515] Regular expression match does not return
In-Reply-To: <1343758138.43.0.559829332434.issue15515@psf.upfronthosting.co.za>
Message-ID: <1343764693.29.0.317058017544.issue15515@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

It's probably inappropriate for me to mention that the alternative 'regex' module on PyPI completes promptly, so I won't. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15515>
_______________________________________

From report at bugs.python.org  Tue Jul 31 21:59:40 2012
From: report at bugs.python.org (Tom Tromey)
Date: Tue, 31 Jul 2012 19:59:40 +0000
Subject: [issue15516] exception-handling bug in PyString_Format
Message-ID: <1343764780.71.0.604975878578.issue15516@psf.upfronthosting.co.za>


New submission from Tom Tromey:

In gdb we supply a class whose nb_int method can throw
an exception.

A user wrote code like this:

    return '%x' % value

... where "value" was an instance of this class.
This caused funny exception behavior later on.
You can see the original report here:

http://sourceware.org/bugzilla/show_bug.cgi?id=14320

I tracked down the odd behavior to this code in
stringobject.c:PyString_Format:

                        iobj = PyNumber_Int(v);
                        if (iobj==NULL) iobj = PyNumber_Long(v);

Here, PyNumber_Int fails and sets the exception.
I think this ought to be cleared before calling
PyNumber_Long.  In our case, PyNumber_Long succeeds,
and the program keeps executing until something happens
to call PyErr_Occurred.

I think this patch ought to fix the problem:

diff -r e0eb7dea245f Objects/stringobject.c
--- a/Objects/stringobject.c	Mon Jul 30 04:07:49 2012 -0700
+++ b/Objects/stringobject.c	Tue Jul 31 13:58:07 2012 -0600
@@ -4489,7 +4489,10 @@
                     }
                     else {
                         iobj = PyNumber_Int(v);
-                        if (iobj==NULL) iobj = PyNumber_Long(v);
+                        if (iobj==NULL) {
+			    PyErr_Clear();
+			    iobj = PyNumber_Long(v);
+			}
                     }
                     if (iobj!=NULL) {
                         if (PyInt_Check(iobj)) {

I haven't written a test case yet; David Malcolm suggested I file
a bug here first.

----------
components: None
messages: 167043
nosy: tromey
priority: normal
severity: normal
status: open
title: exception-handling bug in PyString_Format
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15516>
_______________________________________

From report at bugs.python.org  Tue Jul 31 22:01:29 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 31 Jul 2012 20:01:29 +0000
Subject: [issue15516] exception-handling bug in PyString_Format
In-Reply-To: <1343764780.71.0.604975878578.issue15516@psf.upfronthosting.co.za>
Message-ID: <1343764889.95.0.194094825044.issue15516@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15516>
_______________________________________

From report at bugs.python.org  Tue Jul 31 22:03:58 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 31 Jul 2012 20:03:58 +0000
Subject: [issue15516] exception-handling bug in PyString_Format
In-Reply-To: <1343764780.71.0.604975878578.issue15516@psf.upfronthosting.co.za>
Message-ID: <1343765038.86.0.311001218719.issue15516@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Hi, and thank you for reporting. The diagnosis looks good, please proceed and add a test case if possible.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15516>
_______________________________________

From report at bugs.python.org  Tue Jul 31 22:08:11 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 31 Jul 2012 20:08:11 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1343704869.56.0.834482644373.issue15295@psf.upfronthosting.co.za>
Message-ID: <20120731160807.528d6873@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Jul 31, 2012, at 03:21 AM, Eric Snow wrote:

>1. default path importer (a.k.a PathFinder),

+1, although currently I am refraining from using "default" when describing
this thing.

>2. path hook (lives on sys.path_hooks),

I have called these "path entry hooks"

>3. path entry handler (finder look-alike that a path hook returns),

I still call these "path entry finders".  I understand the ambiguity, and
despite supporting a slightly different protocol than meta path finders, they
still serve the role of finding a loader for a module.  So for now, I'm
keeping "path entry finder", though I'll leave the door slightly open to
persuasion. :)

>4. module loader (business as usual).

I've pulled "Loaders" out into a separate higher level section because as you
say, the loader API is the same for the things returned by both meta path
finders and path entry finders.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 22:10:22 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Jul 2012 20:10:22 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <3Wmpff0yx5zPcd@mail.python.org>


Roundup Robot added the comment:

New changeset c933ec7cafcf by Barry Warsaw in branch 'default':
Address substantially all of Eric Snow's comments in issue #15295, except for
http://hg.python.org/cpython/rev/c933ec7cafcf

New changeset d5317b8f455a by Barry Warsaw in branch 'default':
- Issue #15295: Reorganize and rewrite the documentation on the import system.
http://hg.python.org/cpython/rev/d5317b8f455a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 22:11:09 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 31 Jul 2012 20:11:09 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343765469.03.0.24748988012.issue15295@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/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 22:29:37 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 20:29:37 +0000
Subject: [issue15510] textwrap.wrap('') returns empty list
In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za>
Message-ID: <1343766577.94.0.257776629393.issue15510@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Attaching patch with test cases.

I added 6 new tests:

*test_empty_string
test_whitespace_trailing
*test_drop_whitespace__all_whitespace
*test_initial_indent__empty_string
test_subsequent_indent__trailing_whitespace
test_subsequent_indent__long_indent

The starred ones fail with the current code (the test cases are similar to the snippets I included in my first comment).  The others fail under a certain incorrect implementation of this issue.  (I'm adding them to increase coverage of edge cases and to protect against future regressions.)

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file26628/issue-15510-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15510>
_______________________________________

From report at bugs.python.org  Tue Jul 31 22:30:13 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Jul 2012 20:30:13 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343766613.48.0.230368371702.issue15295@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The import path definition is a little misleading as sys.path is only inferred when 'path' has None passed in. Otherwise 'path' is what __path__ in a package is set to, so technically sys.path never even comes into play except by choice from PathFinder as it just chooses to treat None to mean sys.path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 22:43:25 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 31 Jul 2012 20:43:25 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1343766613.48.0.230368371702.issue15295@psf.upfronthosting.co.za>
Message-ID: <20120731164317.06b777d5@resist.wooz.org>


Barry A. Warsaw added the comment:

On Jul 31, 2012, at 08:30 PM, Brett Cannon wrote:

>The import path definition is a little misleading as sys.path is only
>inferred when 'path' has None passed in. Otherwise 'path' is what __path__ in
>a package is set to, so technically sys.path never even comes into play
>except by choice from PathFinder as it just chooses to treat None to mean
>sys.path.

Do you think the glossary entry needs to be so precise?  It may be difficult
to explain all that in a concise definition.  Maybe it's best to just remove
the "During import...attribute" bit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 22:45:31 2012
From: report at bugs.python.org (Tom Tromey)
Date: Tue, 31 Jul 2012 20:45:31 +0000
Subject: [issue15516] exception-handling bug in PyString_Format
In-Reply-To: <1343764780.71.0.604975878578.issue15516@psf.upfronthosting.co.za>
Message-ID: <1343767531.48.0.0862767319046.issue15516@psf.upfronthosting.co.za>


Tom Tromey added the comment:

Here is a patch that includes a test case.
The test fails before the stringobject.c patch is applied,
and passes after.

----------
Added file: http://bugs.python.org/file26629/P

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15516>
_______________________________________

From report at bugs.python.org  Tue Jul 31 22:46:59 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Jul 2012 20:46:59 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>
Message-ID: <1343767619.28.0.162745984137.issue15295@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I guess just saying it can be None depending on context would be enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 23:04:24 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 31 Jul 2012 21:04:24 +0000
Subject: [issue15295] Import machinery documentation
In-Reply-To: <1343746609.85.0.222490754463.issue15295@psf.upfronthosting.co.za>
Message-ID: <20120731170413.5099e019@resist.wooz.org>


Barry A. Warsaw added the comment:

On Jul 31, 2012, at 02:56 PM, Eric Snow wrote:

>Part of the problem with the import nomenclature is that PEP 302 doesn't
>really nail it down and mixes the terms up a bit.  This is understandable
>considering it broken ground in some regard.  However, at this point we have
>a more comfortable relationship with the import system.  Would it be feasible
>to lightly update PEP 302 to have a more concrete and consistent use of
>import terminology?

Maybe not an update to PEP 302, but probably a big red warning that the
terminology is out of date, with a reference to the import system
documentation in the reference manual.

This also points out an interesting, more general problem, with PEPs that get
out of date doesn't it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15295>
_______________________________________

From report at bugs.python.org  Tue Jul 31 23:15:37 2012
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 31 Jul 2012 21:15:37 +0000
Subject: [issue15513] Correct __sizeof__ support for pickle
In-Reply-To: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za>
Message-ID: <1343769337.31.0.184709305967.issue15513@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

I reviewed the patch here

http://bugs.python.org/review/15513/#ps5596

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15513>
_______________________________________

From report at bugs.python.org  Tue Jul 31 23:16:18 2012
From: report at bugs.python.org (Tim Peters)
Date: Tue, 31 Jul 2012 21:16:18 +0000
Subject: [issue15515] Regular expression match does not return
In-Reply-To: <1343758138.43.0.559829332434.issue15515@psf.upfronthosting.co.za>
Message-ID: <1343769378.25.0.595595547221.issue15515@psf.upfronthosting.co.za>


Tim Peters added the comment:

Matthew, yes, PyPy's regex module implements regular expressions of the "computer science" (as opposed to POSIX) sense.  See Friedl's book for a full explanation.  Short course is that regex's flavor of regexp matching is linear-time, but cannot support "advanced" features like backreferences.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15515>
_______________________________________