From report at bugs.python.org  Wed Sep  1 00:16:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 31 Aug 2010 22:16:16 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283292976.5.0.979258468994.issue941346@psf.upfronthosting.co.za>


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

In dynamic builds, there seem to be lots of messages such as:

ld: 0711-224 WARNING: Duplicate symbol: .PyLong_FromString
ld: 0711-224 WARNING: Duplicate symbol: PyLong_FromString

Are you sure this is normal?

In any case, if you find a way to cleanup ld_so_aix, this should probably be checked in anyway. I doubt anybody else tests under AIX, so it's reasonable to trust you on this.

Even better if you manage to diagnose and/or fix some of the test failures, by the way. (if not, you can still open separate issues for each of them)

----------

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

From report at bugs.python.org  Wed Sep  1 00:23:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 31 Aug 2010 22:23:04 +0000
Subject: [issue9693] asynchat push_callable() patch
In-Reply-To: <1283282337.49.0.734756619317.issue9693@psf.upfronthosting.co.za>
Message-ID: <1283293378.3176.4.camel@localhost.localdomain>


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

> > - why override __bool__??
> 
> I did that for performance.
> Considering that initiate_send() method is called many times, and that
> it is almost always used to send data rather than firing functions I
> wanted to avoid to call isinstance(first, _Callable) (or
> hasattr(first,  '__call__')) on every loop.

This looks hackish... You should at least make the purpose very clear in
comments to the code.
Also, really, isinstance(..., _Callable) is better than the hasattr()
call, IMO.

> The API follows the exact same approach as push(),
> push_with_producer() and close_when_done() methods.
> It adds "something" to a fifo and that "something" will be processed
> (called) only when the previous producers are exhausted, respecting
> the order of what has been "pushed" first and later.
> This is different than a deferred.

Well, a deferred would be fired when a given piece of data has been sent
(or failed to send, in which case the errback would be run rather than
the callback). This is in the end equivalent, since I suppose the send
queue is sequential and never gets reordered.

In any case, I guess it's too late to change the overall design. I just
wanted to point out that the Deferred concept unified a lot of use cases
under a simple convenient abstraction. It avoids having to define ad hoc
methods such as push_callable().

> Something similar to Twisted deferreds is this:
> http://bugs.python.org/issue1641

This has nothing to do with Deferreds actually :)

----------

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

From report at bugs.python.org  Wed Sep  1 00:29:18 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Aug 2010 22:29:18 +0000
Subject: [issue9727] Add callbacks to be invoked when locale changes
In-Reply-To: <1283293758.47.0.775705269917.issue9727@psf.upfronthosting.co.za>
Message-ID: <1283293758.47.0.775705269917.issue9727@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As part of the PEP 384 discussion, it was noted that one of the problems with mixed C runtimes on Windows is that each C runtime in the process has it's own idea of the current locale setting.

This can be addressed to some degree by having extension modules query and modify the Python interpreter's locale setting rather than the C runtime setting, but doesn't help those modules react to *changes* in the setting.

Would it be worth adding a callback registration mechanism to the locale module to allow modules to be notified when the locale changes? (It seems like this may be useful even outside the context of PEP 384, e.g. to dynamically update displays in GUI applications)

----------
components: Library (Lib)
messages: 115281
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add callbacks to be invoked when locale changes
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Sep  1 00:29:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Aug 2010 22:29:52 +0000
Subject: [issue9713] Py_CompileString fails on non decode-able paths.
In-Reply-To: <1283154413.35.0.877915229941.issue9713@psf.upfronthosting.co.za>
Message-ID: <1283293792.55.0.37414088951.issue9713@psf.upfronthosting.co.za>


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

The problem is not specific to Py_CompileString(): all functions based (indirectly) on PyParser_ASTFromString() and PyParser_ASTFromFile() expect filenames encoded in utf-8 with the strict error handler.

If we choose to use something else than utf-8 in strict mode, here is an incomplete list of functions that have to be patched:
 - parser:
   * initerr()
   * err_input()
 - ast
   * ast_error_finish()

And the list of impacted functions (parsing functions accepting filenames):
 - PyParser_ParseStringFlagsFilename()
 - PyParser_ParseFile*()
 - PyParser_ASTFromString(), PyParser_ASTFromFile()
 - PyAST_FromNode()
 - PyRun_SimpleFile*()
 - PyRun_AnyFile*()
 - PyRun_InteractiveOneFlags()
 - etc.

All these functions are public and I don't think that it would be a good idea to change the encoding (eg. to iso-8859-1). We can use a different error handler (especially surrogateespace, as suggested in the initial message) and/or create new functions accepting unicode filenames.

--

I'm working on undecodable filenames in issues #8611 and #9425, especially on the import machinery part. When the import machinery will be fully unicode compliant, the last part will be the "parser machinery" (Parser/*.c). It is a little bit more complex to patch the parser because there is the bootstrap problem: the parser is compiled twice, once with a small subset of the C Python API (using some mockups), once with the full API.

----------

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

From report at bugs.python.org  Wed Sep  1 00:30:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Aug 2010 22:30:08 +0000
Subject: [issue9713] Py_CompileString fails on non decode-able paths.
In-Reply-To: <1283154413.35.0.877915229941.issue9713@psf.upfronthosting.co.za>
Message-ID: <1283293808.1.0.619982180143.issue9713@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Unicode -None
versions: +Python 3.2

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

From report at bugs.python.org  Wed Sep  1 00:43:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Aug 2010 22:43:51 +0000
Subject: [issue1552880] Unicode Imports
Message-ID: <1283294631.41.0.497532721908.issue1552880@psf.upfronthosting.co.za>


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

utf-8 codec (in strict mode) rejects surrogates in python3, and so you doesn't support undecodable filenames (filenames decoded using surrogateescape error handler which produces surrogate characters). It may be possible if you use surrogateescape everywhere.

Manipulate encoded filenames is not trivial because it may quickly lead to mojibake if the encodings are different (eg. if sys.path contains a bytes filename, you have to be careful). Use utf-8 means that you have to decode and then reencode (to the filesystem encoding) a filename before passing it to a system call (eg. mkdir()). #8611 problem is that Python3 doesn't work if the filesystem is *not* utf-8.

You solution is attractive because it is short, but I prefer to use directly the right solution to not patch Python twice: use unicode (with surrogates, PEP 383, for undecodable filenames) everywhere.

----------

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

From report at bugs.python.org  Wed Sep  1 03:23:15 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 01 Sep 2010 01:23:15 +0000
Subject: [issue1552880] Unicode Imports
Message-ID: <1283304195.04.0.0745873924129.issue1552880@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I conffess that I didn't follow the utf-8/surrogate discussion.
But the utf-8 encoding can encode all valid unicode characters:

UTF-8 may only legally be used to encode valid Unicode scalar values. According to the Unicode standard the high and low surrogate halves used by UTF-16 (U+D800 through U+DFFF) and values above U+10FFFF are not legal Unicode values, and the UTF-8 encoding of them is an invalid byte sequence and should be treated as described above. (from wikipedia)

If we encounter surrogate halves when encoding (unicode) to utf-8, it means that we are really trying to decode utf-16 and reencode it as utf-8.  (and that python is using 16 bits for its unicode chars).  the utf--8 codec should be smart enough to merge the surrogates into a utf-32 char, and encode that.

Anyway, as you remark, my approach is a _patch_, designed to make python (2.x) work in an unicode environment, with the least amount of code change, for those willing to commit such a patch.  In 3.x you may want to do things differently.

----------

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

From report at bugs.python.org  Wed Sep  1 03:49:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 01:49:09 +0000
Subject: [issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In Doc/extending/windows.rst, there's the following text:

------------------------------------------------------------------------
If your module creates a new type, you may have trouble with this line::

   PyVarObject_HEAD_INIT(&PyType_Type, 0)

Change it to::

   PyVarObject_HEAD_INIT(NULL, 0)

and add the following to the module initialization function::

   MyObject_Type.ob_type = &PyType_Type;

Refer to section 3 of the `Python FAQ <http://www.python.org/doc/faq>`_ for
details on why you must do this.
------------------------------------------------------------------------

If I assume that Section 3 means, the third link on the FAQ page, I can't find the FAQ that's being alluded to here.  There's a comment in Include/pyport.h that I believe to be related:

            /* Under Cygwin, auto-import functions to prevent compilation */
            /* failures similar to http://python.org/doc/FAQ.html#3.24 */

However, that link no longer goes to a particular question and I can't tell which question it once referred to.

I ran into this because I'm trying to understand the cause of the issue which I suspect is related to Issue #6672.

----------
assignee: docs at python
components: Documentation
messages: 115285
nosy: brian.curtin, docs at python, stutzbach, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: Docs point to FAQ Section 3, but FAQs are not numbered

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

From report at bugs.python.org  Wed Sep  1 04:32:24 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Wed, 01 Sep 2010 02:32:24 +0000
Subject: [issue9729] Unconnected SSLSocket.{send,
	recv} raises TypeError: 'member_descriptor' object is not callable
In-Reply-To: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>
Message-ID: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>


New submission from Andrew Bennetts <spiv at users.sourceforge.net>:

ython 2.6.6 (r266:84292, Aug 24 2010, 21:47:18) 
[GCC 4.4.5 20100816 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket, ssl
>>> s = socket.socket()
>>> wrapped = ssl.wrap_socket(s)
>>> wrapped.recv(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/ssl.py", line 217, in recv
    return socket.recv(self, buflen, flags)
TypeError: 'member_descriptor' object is not callable


What I expected was a more helpful error, like the unwrapped socket gives:

>> s.recv(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.error: [Errno 107] Transport endpoint is not connected


The full list of affected methods are all the _delegate_methods from socket.py:

_delegate_methods = ("recv", "recvfrom", "recv_into", "recvfrom_into",
                     "send", "sendto")

The cause is that the SSLSocket subclass is trying to upcall to the _socketobject base class, but the base does not have methods for those, just __slots__ for the instance to fill in with bound methods.

----------
messages: 115286
nosy: spiv
priority: normal
severity: normal
status: open
title: Unconnected SSLSocket.{send,recv} raises TypeError: 'member_descriptor' object is not callable
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Sep  1 04:32:43 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Wed, 01 Sep 2010 02:32:43 +0000
Subject: [issue9729] Unconnected SSLSocket.{send,
	recv} raises TypeError: 'member_descriptor' object is not callable
In-Reply-To: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>
Message-ID: <1283308363.42.0.762872316909.issue9729@psf.upfronthosting.co.za>


Changes by Andrew Bennetts <spiv at users.sourceforge.net>:


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

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

From report at bugs.python.org  Wed Sep  1 05:44:26 2010
From: report at bugs.python.org (JingCheng LIU)
Date: Wed, 01 Sep 2010 03:44:26 +0000
Subject: [issue9730] base64 encoding takes in bytes rather than string.
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>


New submission from JingCheng LIU <liuexp at gmail.com>:

http://docs.python.org/py3k/library/base64.html?highlight=base64
the examples given doesn't work

----------
assignee: docs at python
components: Documentation
messages: 115287
nosy: Dmitry.Jemerov, JingCheng.LIU, docs at python, ezio.melotti, orsenthil, pitrou
priority: normal
severity: normal
status: open
title: base64 encoding takes in bytes rather than string.
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Sep  1 08:59:18 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Sep 2010 06:59:18 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1283324358.3.0.244232901411.issue4356@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r84383.

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

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

From report at bugs.python.org  Wed Sep  1 13:56:49 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 11:56:49 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283342209.16.0.00907370316584.issue9730@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

The example can be fixed by placing a "b" before the two string literals.

However, pretty much the whole document refers to "strings" and should refer to "byte sequences" or the "bytes" type.

I thought there were automated tests that exercised the documentation examples.  Am I wrong about that?

----------
nosy: +stutzbach
resolution:  -> accepted
stage:  -> needs patch
title: base64 encoding takes in bytes rather than string. -> base64 docs refers to strings instead of bytes
versions: +Python 3.2

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

From report at bugs.python.org  Wed Sep  1 14:23:01 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 12:23:01 +0000
Subject: [issue7877] Iterators over _winreg EnumKey and EnumValue results
In-Reply-To: <1265578300.82.0.0744515010877.issue7877@psf.upfronthosting.co.za>
Message-ID: <1283343781.67.0.692900702808.issue7877@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

As most of the code in this patch was copied from EnumValue and EnumKey, it includes bugs from those functions that have since been fixed.  I'm thinking of Issue #2810, although there might have been other changes.

Instead of duplicating code, it would be better to abstract out some of the common elements so that in the future changes only need to be made in one place.

While winreg isn't very Pythonic, I imagine most users write a simple wrapper around the functions to give it a more Pythonic feel.  I have been using a home-brewed class that implements the MutableMapping ABC.  I just posted it as a recipe on ActiveState:

http://code.activestate.com/recipes/577381-collectionsmutablemapping-wrapper-around-_winreg/

----------
nosy: +stutzbach

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

From report at bugs.python.org  Wed Sep  1 14:27:58 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 12:27:58 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1283344078.88.0.560496709767.issue8743@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Raymond, do you agree with Ray's analysis?

----------

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

From report at bugs.python.org  Wed Sep  1 14:38:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 12:38:46 +0000
Subject: [issue9729] Unconnected SSLSocket.{send,
	recv} raises TypeError: 'member_descriptor' object is not callable
In-Reply-To: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>
Message-ID: <1283344726.61.0.98257790745.issue9729@psf.upfronthosting.co.za>


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

Note that 3.x will give you the expected error message:
>>> s = socket.socket()
>>> wrapped = ssl.wrap_socket(s)
>>> wrapped.recv(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/ssl.py", line 292, in recv
    return socket.recv(self, buflen, flags)
socket.error: [Errno 107] Transport endpoint is not connected

Do you have any idea how to solve it for 2.7? Do you want to provide a patch?

----------
components: +Library (Lib)
nosy: +pitrou
stage:  -> needs patch
versions:  -Python 2.6

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

From report at bugs.python.org  Wed Sep  1 15:02:33 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 13:02:33 +0000
Subject: [issue9731] ABCMeta.register should verify that methods are present
In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>
Message-ID: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In Issue 9212, I mused:

> I sort of wonder if .register() should verify that the concrete class
> provides all of the methods of the ABC.

?ric Araujo suggested I open that as an issue for consideration.  

I have found a few bugs in the standard library where a concrete class did not actually implement all of the methods of the ABC that it purported to implement.  Specifically:

dict's keys view claims to implement the Set ABC but doesn't provide the is_disjoint method (Issue 9212)

range objects claims to support the Sequence ABC but don't provide the count and index methods (Issue 9213)

Should ABCMeta.register verify that the type implements all of the appropriate methods?

On the one hand, that would prevent similar bugs from sneaking by.  On the other hand, it's extra code that would get executed every time Python started (site.py imports os.py which imports _abcoll.py).

Thoughts?

----------
components: Library (Lib)
messages: 115293
nosy: benjamin.peterson, eric.araujo, gvanrossum, stutzbach
priority: normal
severity: normal
status: open
title: ABCMeta.register should verify that methods are present
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Sep  1 15:03:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 13:03:12 +0000
Subject: [issue3101] global function _add_one_to_index_C
In-Reply-To: <1213342220.87.0.7161073703.issue3101@psf.upfronthosting.co.za>
Message-ID: <1283346192.57.0.70636259339.issue3101@psf.upfronthosting.co.za>


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

I've added a "_Py" prefix in r84391, and also made the `shape` argument const. If numpy people want this to be an official public API, they'll have to contribute. Thanks.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

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

From report at bugs.python.org  Wed Sep  1 15:07:53 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 01 Sep 2010 13:07:53 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1283346473.71.0.974476414415.issue8685@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

> I'll be looking at it shortly.  Py3.2 is still aways from release so there is no hurry.

I would consider reviewing and possibly apply this change, but I don't want to invade anyone's territory.

----------
nosy: +exarkun

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

From report at bugs.python.org  Wed Sep  1 15:21:10 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 01 Sep 2010 13:21:10 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347270.93.0.617041013711.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283347270.93.0.617041013711.issue9732@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

As discussed on python-dev, a version of getattr that does static lookups - bypassing the descriptor protocol, __getattr__, and __getattribute__. Initial implementation by Nick Coghlan, amended and tests added by me.

Phillip Eby objects to this code existing at all as it doesn't play well with proxy objects.

The purpose of getattr_static is for "passive introspection" without triggering code execution (as hasattr and getattr both do). Use cases include debugging and fetching docstrings from objects.

Caveats with the current implementation are:

Cases that will break `getattr_static`, all pathological enough not
to worry about (i.e. if you do any of these then you deserve to
have everything break anyway):

* `__dict__` existing (e.g. as a property) but not returning a
  dictionary
* classes created with `__slots__` that then have the `__slots__`
  member deleted from the class (or otherwise monkeyed with)

Cases handled incorrectly:

1. where a descriptor with a `__set__` method is shadowed by an
   instance member we return the instance member in preference to
   the descriptor, unlike `getattr`
2. types implemented in C may have neither `__dict__` nor `__slots__`,
   in this case we will be unable to find instance members and return
   the attribute descriptor instead
3. classes that inherit from a class with `__slots__` (whether or not
   they use `__slots__` themselves) will return the slot descriptor
   for instance members 'owned' by a slot on a base class
4. objects that lie about being a type by having __class__ as a
   descriptor (we traverse the mro of whatever type `obj.__class__`
   returns instead of the real type)

1 could be fixed but the code would be annoying. Is it worth fixing?

2 could be detected and where fetching an attribute from an instance
fails but an attribute descriptor is found on the type we could try
it's __get__ method. Worth it?

3 could be detected if we find a slot descriptor on a type trying
its __get__ method. Worth it?

4 could be fixed by using type everywhere instead of __class__.
We also can't use isinstance that uses __class__. If an object
is lying about __class__ then it obviously *intends* us to look
at the 'faked' version. However, this breaks the 'no code
execution' purpose of getattr_static and is inconsistent with
the rest of our behaviour. Worth fixing?

Fixing *all* of these (or any) will significantly complicate the
implimentation. 

Fetching an uninitialized instance member from an instance of a class
with __slots__ returns the slot descriptor rather than raising an
AttributeError as the descriptor does. As the slot descriptor is
a Python implementation detail perhaps we are better off propagating
the exception here. (?) On the other hand, the descriptor is
available on the class and the job of this function is to fetch
members when they are available...

I'm not aware of any other caveats / potential pitfalls. Please
point them out to me. :-)Cases that will break `getattr_static`, all pathological enough not
to worry about (i.e. if you do any of these then you deserve to
have everything break anyway):

* `__dict__` existing (e.g. as a property) but not returning a
  dictionary
* classes created with `__slots__` that then have the `__slots__`
  member deleted from the class (or otherwise monkeyed with)

Cases handled incorrectly:

1. where a descriptor with a `__set__` method is shadowed by an
   instance member we return the instance member in preference to
   the descriptor, unlike `getattr`
2. types implemented in C may have neither `__dict__` nor `__slots__`,
   in this case we will be unable to find instance members and return
   the attribute descriptor instead
3. classes that inherit from a class with `__slots__` (whether or not
   they use `__slots__` themselves) will return the slot descriptor
   for instance members 'owned' by a slot on a base class
4. objects that lie about being a type by having __class__ as a
   descriptor (we traverse the mro of whatever type `obj.__class__`
   returns instead of the real type)

1 could be fixed but the code would be annoying. Is it worth fixing?

2 could be detected and where fetching an attribute from an instance
fails but an attribute descriptor is found on the type we could try
it's __get__ method. Worth it?

3 could be detected if we find a slot descriptor on a type trying
its __get__ method. Worth it?

4 could be fixed by using type everywhere instead of __class__.
We also can't use isinstance that uses __class__. If an object
is lying about __class__ then it obviously *intends* us to look
at the 'faked' version. However, this breaks the 'no code
execution' purpose of getattr_static and is inconsistent with
the rest of our behaviour. Worth fixing?

Fixing *all* of these (or any) will significantly complicate the
implimentation. 

Fetching an uninitialized instance member from an instance of a class
with __slots__ returns the slot descriptor rather than raising an
AttributeError as the descriptor does. As the slot descriptor is
a Python implementation detail perhaps we are better off propagating
the exception here. (?) On the other hand, the descriptor is
available on the class and the job of this function is to fetch
members when they are available...

I'm not aware of any other caveats / potential pitfalls. Please
point them out to me. :-)

----------
assignee: michael.foord
components: Library (Lib)
files: static.py
keywords: needs review
messages: 115296
nosy: benjamin.peterson, michael.foord, ncoghlan
priority: normal
severity: normal
status: open
title: Addition of getattr_static for inspect module
versions: Python 3.2
Added file: http://bugs.python.org/file18699/static.py

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

From report at bugs.python.org  Wed Sep  1 15:22:01 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 01 Sep 2010 13:22:01 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347270.93.0.617041013711.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283347321.47.0.307841265126.issue9732@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Tests require Python 3. Implementation works with Python 2 as well.

----------
Added file: http://bugs.python.org/file18700/test_static.py

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

From report at bugs.python.org  Wed Sep  1 15:22:37 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 01 Sep 2010 13:22:37 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347270.93.0.617041013711.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283347357.49.0.588931568951.issue9732@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


Removed file: http://bugs.python.org/file18700/test_static.py

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

From report at bugs.python.org  Wed Sep  1 15:22:48 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 01 Sep 2010 13:22:48 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347270.93.0.617041013711.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283347368.32.0.995315189625.issue9732@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
Removed message: http://bugs.python.org/msg115297

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

From report at bugs.python.org  Wed Sep  1 15:23:06 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 01 Sep 2010 13:23:06 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347270.93.0.617041013711.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Tests require Python 3. Implementation works with Python 2 as well.

----------
Added file: http://bugs.python.org/file18701/test_static.py

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

From report at bugs.python.org  Wed Sep  1 15:27:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 13:27:52 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347270.93.0.617041013711.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283347672.56.0.933212470378.issue9732@psf.upfronthosting.co.za>


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

+1 on the principle. This could help things like pydoc, especially on modern Web frameworks which do incredibly ugly things (per-thread global variables, descriptors executing tons of code etc.).

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

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

From report at bugs.python.org  Wed Sep  1 15:30:19 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 01 Sep 2010 13:30:19 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283347819.8.0.752361565766.issue9732@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
Removed message: http://bugs.python.org/msg115296

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

From report at bugs.python.org  Wed Sep  1 15:30:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 01 Sep 2010 13:30:46 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283347846.63.0.017602134844.issue9732@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

(Reposted as text was entirely duplicated - oops.)

As discussed on python-dev, a version of getattr that does static lookups - bypassing the descriptor protocol, __getattr__, and __getattribute__. Initial implementation by Nick Coghlan, amended and tests added by me.

Phillip Eby objects to this code existing at all as it doesn't play well with proxy objects.

The purpose of getattr_static is for "passive introspection" without triggering code execution (as hasattr and getattr both do). Use cases include debugging and fetching docstrings from objects.

Caveats with the current implementation are:

Cases that will break `getattr_static`, all pathological enough not
to worry about (i.e. if you do any of these then you deserve to
have everything break anyway):

* `__dict__` existing (e.g. as a property) but not returning a
  dictionary
* classes created with `__slots__` that then have the `__slots__`
  member deleted from the class (or otherwise monkeyed with)

Cases handled incorrectly:

1. where a descriptor with a `__set__` method is shadowed by an
   instance member we return the instance member in preference to
   the descriptor, unlike `getattr`
2. types implemented in C may have neither `__dict__` nor `__slots__`,
   in this case we will be unable to find instance members and return
   the attribute descriptor instead
3. classes that inherit from a class with `__slots__` (whether or not
   they use `__slots__` themselves) will return the slot descriptor
   for instance members 'owned' by a slot on a base class
4. objects that lie about being a type by having __class__ as a
   descriptor (we traverse the mro of whatever type `obj.__class__`
   returns instead of the real type)

1 could be fixed but the code would be annoying. Is it worth fixing?

2 could be detected and where fetching an attribute from an instance
fails but an attribute descriptor is found on the type we could try
it's __get__ method. Worth it?

3 could be detected if we find a slot descriptor on a type trying
its __get__ method. Worth it?

4 could be fixed by using type everywhere instead of __class__.
We also can't use isinstance that uses __class__. If an object
is lying about __class__ then it obviously *intends* us to look
at the 'faked' version. However, this breaks the 'no code
execution' purpose of getattr_static and is inconsistent with
the rest of our behaviour. Worth fixing?

Fixing *all* of these (or any) will significantly complicate the
implimentation. 

Fetching an uninitialized instance member from an instance of a class
with __slots__ returns the slot descriptor rather than raising an
AttributeError as the descriptor does. As the slot descriptor is
a Python implementation detail perhaps we are better off propagating
the exception here. (?) On the other hand, the descriptor is
available on the class and the job of this function is to fetch
members when they are available...

I'm not aware of any other caveats / potential pitfalls. Please
point them out to me. :-)

----------

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

From report at bugs.python.org  Wed Sep  1 15:48:42 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 01 Sep 2010 13:48:42 +0000
Subject: [issue9212] dict_keys purports to implement the Set ABC,
	but is missing the isdisjoint method
In-Reply-To: <1278702217.69.0.69895367614.issue9212@psf.upfronthosting.co.za>
Message-ID: <1283348922.23.0.806297115666.issue9212@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Thanks for the corrections.  I'm attaching the new patch as issue9212b.diff.  I'm using PyAnySet_Check to determine if the other argument is really a set, but I'm not entirely sure, that this is correct. Please let me know if other corrections are needed.

----------
Added file: http://bugs.python.org/file18702/issue9212b.diff

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

From report at bugs.python.org  Wed Sep  1 15:51:20 2010
From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=)
Date: Wed, 01 Sep 2010 13:51:20 +0000
Subject: [issue9733] Can't iterate over multiprocessing.managers.DictProxy
In-Reply-To: <1283349080.83.0.871806054056.issue9733@psf.upfronthosting.co.za>
Message-ID: <1283349080.83.0.871806054056.issue9733@psf.upfronthosting.co.za>


New submission from Juan Jos? Conti <jjconti at gmail.com>:

I expected I could iterate over a DictProxy as I do over a regular dict.

>>> from multiprocessing import Manager
>>> m = Manager()
>>> d = m.dict()
>>> d
<DictProxy object, typeid 'dict' at 0x98a240c>
>>> for x in d:
...     print x
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 2, in __getitem__
  File "/usr/lib/python2.6/multiprocessing/managers.py", line 740, in _callmethod
    raise convert_to_error(kind, result)
KeyError: 0
>>> d['a'] = 1
>>> for x in d:
...     print x
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 2, in __getitem__
  File "/usr/lib/python2.6/multiprocessing/managers.py", line 740, in _callmethod
    raise convert_to_error(kind, result)
KeyError: 0

----------
components: Library (Lib)
messages: 115302
nosy: jjconti
priority: normal
severity: normal
status: open
title: Can't iterate over multiprocessing.managers.DictProxy
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Sep  1 16:40:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 14:40:21 +0000
Subject: [issue9549] Remove sys.setdefaultencoding()
In-Reply-To: <1281383453.04.0.233452795116.issue9549@psf.upfronthosting.co.za>
Message-ID: <1283352021.73.0.760867371698.issue9549@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep  1 16:44:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 14:44:32 +0000
Subject: [issue9711] ssl.SSLSocket's keyfile argument seems to be ignored if
	specified without certfile
In-Reply-To: <1283115004.18.0.127719277897.issue9711@psf.upfronthosting.co.za>
Message-ID: <1283352272.37.0.308237300058.issue9711@psf.upfronthosting.co.za>


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

I'm not sure which commit it is, but test_ssl has started failing on some buildbots:

======================================================================
ERROR: test_errors (test.test_ssl.BasicSocketTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ssl.py", line 186, in test_errors
    s = ssl.wrap_socket(sock, server_side=True, certfile=CERTFILE)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/ssl.py", line 414, in wrap_socket
    ciphers=ciphers)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/ssl.py", line 137, in __init__
    self.context.load_cert_chain(certfile, keyfile)
ssl.SSLError: [Errno 185057381] _ssl.c:1609: error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table

======================================================================
ERROR: test_protocol_sslv2 (test.test_ssl.ThreadedTests)
Connecting to an SSLv2 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ssl.py", line 80, in f
    return func(*args, **kwargs)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ssl.py", line 1100, in test_protocol_sslv2
    try_protocol_combo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv2, True)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ssl.py", line 969, in try_protocol_combo
    ctx.load_cert_chain(CERTFILE)
ssl.SSLError: [Errno 336445442] _ssl.c:1609: error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib

See e.g. http://www.python.org/dev/buildbot/builders/x86%20Ubuntu%203.x/builds/1870

----------
assignee:  -> giampaolo.rodola
status: closed -> open

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

From report at bugs.python.org  Wed Sep  1 16:48:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 14:48:07 +0000
Subject: [issue5506] io.BytesIO doesn't support the buffer protocol
In-Reply-To: <1237372813.02.0.863937398422.issue5506@psf.upfronthosting.co.za>
Message-ID: <1283352487.82.0.810736642174.issue5506@psf.upfronthosting.co.za>


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

Thinking about it, I'm not sure this would be a good idea to do this by default. There is an ambiguity where it's not obvious if the buffer would contain the whole data or only the bytes after the current position.

I think perhaps an explicit method (getbuffer()?) could be used to export a buffer-compatible object, without copying. Perhaps a memoryview; this would imply defining bf_releasebuffer without bf_getbuffer.

----------
stage: unit test needed -> needs patch

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

From report at bugs.python.org  Wed Sep  1 16:49:18 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 01 Sep 2010 14:49:18 +0000
Subject: [issue9731] ABCMeta.register should verify that methods are present
In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>
Message-ID: <1283352558.25.0.322938086909.issue9731@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

That would be too hard-headed. A complaint I often hear about Interfaces in Java is that classes have a hard time if they choose not to implement a certain method. It also would not be enough -- there are tons of ways you would be able to satisfy such a check to the letter while still breaking any call.

It may be a good idea for a lint-style tool to warn about these though.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Wed Sep  1 16:50:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 14:50:56 +0000
Subject: [issue9711] ssl.SSLSocket's keyfile argument seems to be ignored if
	specified without certfile
In-Reply-To: <1283115004.18.0.127719277897.issue9711@psf.upfronthosting.co.za>
Message-ID: <1283352656.78.0.757261511555.issue9711@psf.upfronthosting.co.za>


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

Actually, it started failing exactly after r84352 (issue #9706).

----------
status: open -> closed

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

From report at bugs.python.org  Wed Sep  1 16:52:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 14:52:02 +0000
Subject: [issue9706] ssl errors checking
In-Reply-To: <1283029306.3325.3.camel@localhost.localdomain>
Message-ID: <1283352722.9.0.771821388121.issue9706@psf.upfronthosting.co.za>


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

Some buildbots have started failing exactly after this commit:

======================================================================
ERROR: test_errors (test.test_ssl.BasicSocketTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ssl.py", line 186, in test_errors
    s = ssl.wrap_socket(sock, server_side=True, certfile=CERTFILE)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/ssl.py", line 414, in wrap_socket
    ciphers=ciphers)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/ssl.py", line 137, in __init__
    self.context.load_cert_chain(certfile, keyfile)
ssl.SSLError: [Errno 185057381] _ssl.c:1609: error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table

======================================================================
ERROR: test_protocol_sslv2 (test.test_ssl.ThreadedTests)
Connecting to an SSLv2 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ssl.py", line 80, in f
    return func(*args, **kwargs)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ssl.py", line 1100, in test_protocol_sslv2
    try_protocol_combo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv2, True)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ssl.py", line 969, in try_protocol_combo
    ctx.load_cert_chain(CERTFILE)
ssl.SSLError: [Errno 336445442] _ssl.c:1609: error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib

See e.g. http://www.python.org/dev/buildbot/builders/x86%20Ubuntu%203.x/builds/1870

This is probably dependent on the OpenSSL version.

----------
status: closed -> open

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

From report at bugs.python.org  Wed Sep  1 16:54:55 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 01 Sep 2010 14:54:55 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283352895.35.0.264588662039.issue9732@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Just jumping in here with commentary from the side bench... I noticed you say "this does not always return the same results as dir(x)". But since dir(x) exists, perhaps it would make sense to match dir(x) as closely as possible? I.e. if dir(x) doesn't know about it, don't return it, if dir(x) does know about it, do return it? Those would be ease rules to remember for sure.

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Wed Sep  1 17:01:59 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 15:01:59 +0000
Subject: [issue9731] ABCMeta.register should verify that methods are present
In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>
Message-ID: <1283353319.39.0.651386874255.issue9731@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Would it be useful to provide a separate function to perform the check, which could be used by lint-style tools as well as automated tests?

It would be great if every call to .register in the standard library had a corresponding test that verified that the appropriate methods were defined.  That would prevent future oversights where methods are missing entirely.

----------

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

From report at bugs.python.org  Wed Sep  1 17:06:04 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 01 Sep 2010 15:06:04 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283353564.01.0.130344241302.issue9732@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Since the addition of __dir__, dir(obj) can return arbitrary values. Typically (I guess) this will be used to add dynamically created attributes that this function will fail to find - so it is *more* likely that we will fail to find something in dir than the reverse.

__dir__ could also be  used to filter non-public members that getattr(...) would find. I would find it odd that getattr finds a member that exists but this function fails. I think this function is more akin to getattr than dir.

Perhaps a better warning would be that this function may fail to find members that getattr finds?

----------

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

From report at bugs.python.org  Wed Sep  1 17:10:27 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 01 Sep 2010 15:10:27 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283353827.11.0.296404733921.issue9732@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

(Or vice versa - getattr_static may succeed in finding members - like descriptors that raise AttributeError when fetched - when getattr fails.)

----------

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

From report at bugs.python.org  Wed Sep  1 17:16:27 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 01 Sep 2010 15:16:27 +0000
Subject: [issue9731] ABCMeta.register should verify that methods are present
In-Reply-To: <1283353319.39.0.651386874255.issue9731@psf.upfronthosting.co.za>
Message-ID: <AANLkTimrOyov=nFR798bjHkne_xYrNJoFQBRZJ5-AtDS@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

> Would it be useful to provide a separate function to perform the check, which could be used by lint-style tools as well as automated tests?
>
> It would be great if every call to .register in the standard library had a corresponding test that verified that the appropriate methods were defined. ?That would prevent future oversights where methods are missing entirely.

Yeah, that makes sense. You could put those checks in the unittests.

----------

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

From report at bugs.python.org  Wed Sep  1 17:17:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 15:17:14 +0000
Subject: [issue7415] PyUnicode_FromEncodedObject() uses PyObject_AsCharBuffer()
In-Reply-To: <1259648354.78.0.66746814248.issue7415@psf.upfronthosting.co.za>
Message-ID: <1283354234.27.0.706578947595.issue7415@psf.upfronthosting.co.za>


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

Patch committed in r84394 (py3k) and r84396 (3.1). Thank you Stefan!

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

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

From report at bugs.python.org  Wed Sep  1 17:17:54 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 01 Sep 2010 15:17:54 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283353564.01.0.130344241302.issue9732@psf.upfronthosting.co.za>
Message-ID: <AANLkTimftvyFyJOuHzzSC5YPKD+SPdzCrFcZ7KGv7BO9@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

> Since the addition of __dir__, dir(obj) can return arbitrary values. Typically (I guess) this will be used to add dynamically created attributes that this function will fail to find - so it is *more* likely that we will fail to find something in dir than the reverse.
>
> __dir__ could also be ?used to filter non-public members that getattr(...) would find. I would find it odd that getattr finds a member that exists but this function fails. I think this function is more akin to getattr than dir.

Gotcha.

> Perhaps a better warning would be that this function may fail to find members that getattr finds?

Ah, yes, and vice versa (well, just yesterday I wrote a descriptor
that always raises AttributeError :-).

----------

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

From report at bugs.python.org  Wed Sep  1 17:19:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 15:19:16 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1283354356.94.0.0326504471323.issue8685@psf.upfronthosting.co.za>


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

> I would consider reviewing and possibly apply this change, but I don't 
> want to invade anyone's territory.

I don't think there would be any invasion. I think the patch is simple enough, and seems to provide a nice benefit.

----------

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

From report at bugs.python.org  Wed Sep  1 17:31:17 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 15:31:17 +0000
Subject: [issue9731] Add ABCMeta.has_methods and tests that use it
In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>
Message-ID: <1283355077.18.0.617238375857.issue9731@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Re-opening and re-titling the issue to that effect.

Proposed syntax and usage:

# in Lib/abc.py
class ABCMeta(type):
    # ...

    def has_methods(cls, subclass):
        "Returns True iff subclass implements the appropriate methods"
        # ...

Usage within the unit tests:

# In Lib/test/test_collections.py
    def test_methods(self):
        self.assertTrue(Sequence.has_methods(range))
        self.assertTrue(MutableSet.has_methods(set))
        # ... and many more

----------
assignee:  -> stutzbach
components: +Tests
resolution: rejected -> accepted
stage:  -> needs patch
status: closed -> open
title: ABCMeta.register should verify that methods are present -> Add ABCMeta.has_methods and tests that use it

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

From report at bugs.python.org  Wed Sep  1 17:47:52 2010
From: report at bugs.python.org (v_peter)
Date: Wed, 01 Sep 2010 15:47:52 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1283356072.53.0.221037260245.issue9042@psf.upfronthosting.co.za>


v_peter <leanmeandonothingmachine at gmail.com> added the comment:

Any comments on the patch for 3.2?

----------

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

From report at bugs.python.org  Wed Sep  1 18:30:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Sep 2010 16:30:59 +0000
Subject: [issue9549] Remove sys.setdefaultencoding()
In-Reply-To: <1281383453.04.0.233452795116.issue9549@psf.upfronthosting.co.za>
Message-ID: <1283358659.86.0.481116130115.issue9549@psf.upfronthosting.co.za>


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

Ok to remove it from Python 3.2. I don't think that it is necessary to update Python 2.7 code/doc.

----------

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

From report at bugs.python.org  Wed Sep  1 19:24:07 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Sep 2010 17:24:07 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1283361847.92.0.360708723407.issue8685@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Please leave this for me.
Thank you.

----------

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

From report at bugs.python.org  Wed Sep  1 19:33:27 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 01 Sep 2010 17:33:27 +0000
Subject: [issue9549] Remove sys.setdefaultencoding()
In-Reply-To: <1281383453.04.0.233452795116.issue9549@psf.upfronthosting.co.za>
Message-ID: <1283362407.79.0.620101715312.issue9549@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/issue9549>
_______________________________________

From report at bugs.python.org  Wed Sep  1 20:00:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Sep 2010 18:00:45 +0000
Subject: [issue9212] dict_keys purports to implement the Set ABC,
	but is missing the isdisjoint method
In-Reply-To: <1278702217.69.0.69895367614.issue9212@psf.upfronthosting.co.za>
Message-ID: <1283364045.14.0.182218047828.issue9212@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It would be nice to get this fixed before the next release.

----------

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

From report at bugs.python.org  Wed Sep  1 20:09:33 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Sep 2010 18:09:33 +0000
Subject: [issue9731] Add ABCMeta.has_methods and tests that use it
In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>
Message-ID: <1283364573.09.0.928852395265.issue9731@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 for the basic idea.

It could use a better name, Sequence.has_methods(range) reads backwards to me.  Perhaps something like:  Sequence.implemented_by(range) or Sequence.verify_full_api(range) or some such.

Also, when the tests get added, they should go in the test file for the implementing class (like test_range for example.)

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

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

From report at bugs.python.org  Wed Sep  1 20:14:27 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 18:14:27 +0000
Subject: [issue9212] dict_keys purports to implement the Set ABC,
	but is missing the isdisjoint method
In-Reply-To: <1278702217.69.0.69895367614.issue9212@psf.upfronthosting.co.za>
Message-ID: <1283364867.0.0.214186827848.issue9212@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I will aim to spend some time with this (and the similar Issue #9213) today and/or tomorrow, so that it can be committed in time for 3.2a2.

----------
resolution:  -> accepted
stage: unit test needed -> patch review

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

From report at bugs.python.org  Wed Sep  1 20:46:13 2010
From: report at bugs.python.org (Jim Fulton)
Date: Wed, 01 Sep 2010 18:46:13 +0000
Subject: [issue9734] ABC issubclass/isinstance leaks in Python 2
In-Reply-To: <1283366773.54.0.691168683166.issue9734@psf.upfronthosting.co.za>
Message-ID: <1283366773.54.0.691168683166.issue9734@psf.upfronthosting.co.za>


New submission from Jim Fulton <jim at zope.com>:

I assume ABCs use some sort of cache for issubclass checks.

I also assume the cache doesn't use weakrefs, leading to leaks in classes created on the fly (as is common in tests).

The attached script demonstrates the leak.

The leak doesn't seem to occur in Python 3.1.2.

----------
files: abc_issubclass_leak.py
messages: 115323
nosy: j1m
priority: normal
severity: normal
status: open
title: ABC issubclass/isinstance leaks in Python 2
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file18703/abc_issubclass_leak.py

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

From report at bugs.python.org  Wed Sep  1 20:56:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 18:56:19 +0000
Subject: [issue9549] Remove sys.setdefaultencoding()
In-Reply-To: <1281383453.04.0.233452795116.issue9549@psf.upfronthosting.co.za>
Message-ID: <1283367379.98.0.690830686676.issue9549@psf.upfronthosting.co.za>


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

Done in r84397.

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

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

From report at bugs.python.org  Wed Sep  1 20:58:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 18:58:38 +0000
Subject: [issue9735] cheatsheet outdated
In-Reply-To: <1283367518.76.0.51890574432.issue9735@psf.upfronthosting.co.za>
Message-ID: <1283367518.76.0.51890574432.issue9735@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The Misc/cheatsheet file is totally outdated (the title ?Python 2.3 Quick Reference? already gives you a hint).
It is also not clear if it is meant for plain text viewing, or should be formatted using an external program...

----------
assignee: docs at python
components: Documentation
messages: 115325
nosy: docs at python, pitrou, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: cheatsheet outdated
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Sep  1 21:01:14 2010
From: report at bugs.python.org (Jim Fulton)
Date: Wed, 01 Sep 2010 19:01:14 +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: <1283367674.32.0.228375766546.issue9736@psf.upfronthosting.co.za>


New submission from Jim Fulton <jim at zope.com>:

We often run test suites repeatedly using a debug build of python
to look for memory leaks.

We also got in the bad habit of using a fork of doctest. Recently, we've switched away from our fork and have noticed a problem with the standard doctest's handling of test globs (globals).

DocTestSuite gets an initial set of globals from the module the doctest's came from.  After running the tests, it seems to clear these, leading to errors if the tests are run again.

I've attached a script that illustrates the problem.  The script runs a simple test twice and gets a spurious failure the second time.

----------
components: Library (Lib)
files: doctest_DocTestSuite_globs_breakage.py
messages: 115326
nosy: j1m
priority: normal
severity: normal
status: open
title: doctest.DocTestSuite doesn't handle test globs correctly
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18704/doctest_DocTestSuite_globs_breakage.py

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

From report at bugs.python.org  Wed Sep  1 21:02:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 19:02:09 +0000
Subject: [issue9733] Can't iterate over multiprocessing.managers.DictProxy
In-Reply-To: <1283349080.83.0.871806054056.issue9733@psf.upfronthosting.co.za>
Message-ID: <1283367729.45.0.233757502568.issue9733@psf.upfronthosting.co.za>


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


----------
assignee:  -> jnoller
nosy: +jnoller
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.1, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Wed Sep  1 21:04:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Sep 2010 19:04:17 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1283367857.18.0.112711540122.issue9116@psf.upfronthosting.co.za>


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


----------
keywords:  -patch

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

From report at bugs.python.org  Wed Sep  1 21:19:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Sep 2010 19:19:14 +0000
Subject: [issue9735] cheatsheet outdated
In-Reply-To: <1283367518.76.0.51890574432.issue9735@psf.upfronthosting.co.za>
Message-ID: <1283368754.21.0.70089866938.issue9735@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Misc/cheatsheet needs updating

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

From report at bugs.python.org  Wed Sep  1 21:20:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Sep 2010 19:20:39 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1283368839.28.0.570171247117.issue4819@psf.upfronthosting.co.za>


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

Merging nosy from duplicate report.

----------
nosy: +pitrou, rhettinger

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

From report at bugs.python.org  Wed Sep  1 21:31:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Sep 2010 19:31:09 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1283369469.17.0.747459652166.issue4819@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


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

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

From report at bugs.python.org  Wed Sep  1 21:31:33 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 01 Sep 2010 19:31:33 +0000
Subject: [issue9706] ssl errors checking
In-Reply-To: <1283029306.3325.3.camel@localhost.localdomain>
Message-ID: <1283369493.1.0.655133835245.issue9706@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Committed r84400 which should fix the first test failure.
I'll take a look at the buildbots to see how it goes.
As for the second failure I have no idea at the moment.

----------

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

From report at bugs.python.org  Wed Sep  1 21:33:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Sep 2010 19:33:13 +0000
Subject: [issue1552880] Unicode Imports
In-Reply-To: <1283304195.04.0.0745873924129.issue1552880@psf.upfronthosting.co.za>
Message-ID: <201009012133.02987.victor.stinner@haypocalc.com>


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

> According to the Unicode standard the high and low surrogate halves used
> by UTF-16 (...)

Yes, but in Python, U+DC80..D+DCFF range is used to store undecodable bytes. 
Eg. 'abc\xff'.decode('ascii', 'surrogateescape') gives 'abc\udcff'.

> Anyway, as you remark, my approach is a _patch_, designed to make python
> (2.x) work in an unicode environment, with the least amount of code
> change, for those willing to commit such a patch.

Python 2.7 is out and I think it is too late to fix Python2. Anyway, Python2 
uses bytes for sys.path or other paths, so the problem only occurs if the user 
specifies unicode paths.

> In 3.x you may want to do things differently.

I choosed to rewrite the C code to manipulate unicode paths instead of byte 
paths => #9425

----------

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

From report at bugs.python.org  Wed Sep  1 21:34:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Sep 2010 19:34:10 +0000
Subject: [issue1552880] Unicode Imports
Message-ID: <1283369650.53.0.523019652664.issue1552880@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/issue1552880>
_______________________________________

From report at bugs.python.org  Wed Sep  1 21:37:49 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 01 Sep 2010 19:37:49 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1283369869.08.0.215821822377.issue8685@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <invalid at example.invalid>:


----------
nosy:  -exarkun

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

From report at bugs.python.org  Wed Sep  1 21:53:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 19:53:26 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1283370806.65.0.688774884465.issue1856@psf.upfronthosting.co.za>


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

It is certainly still a problem with 3.x, but I don't find a way to exhibit it here.

----------
nosy: +pitrou
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Sep  1 21:59:59 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 01 Sep 2010 19:59:59 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1283371199.87.0.846812977466.issue4111@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/issue4111>
_______________________________________

From report at bugs.python.org  Wed Sep  1 22:28:07 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 01 Sep 2010 20:28:07 +0000
Subject: [issue9729] Unconnected SSLSocket.{send,
	recv} raises TypeError: 'member_descriptor' object is not callable
In-Reply-To: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>
Message-ID: <1283372887.46.0.741105094529.issue9729@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/issue9729>
_______________________________________

From report at bugs.python.org  Wed Sep  1 22:30:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 20:30:48 +0000
Subject: [issue8990] array constructor and array.fromstring should accept
	bytearray.
In-Reply-To: <1276458174.59.0.784735349158.issue8990@psf.upfronthosting.co.za>
Message-ID: <1283373048.67.0.830119845333.issue8990@psf.upfronthosting.co.za>


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

The patches were committed in r84403. Thank you very much!

----------
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed
versions:  -Python 3.1

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

From report at bugs.python.org  Wed Sep  1 23:03:03 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 01 Sep 2010 21:03:03 +0000
Subject: [issue9677] "Global Module Index" link dead
In-Reply-To: <1282685163.07.0.524302094141.issue9677@psf.upfronthosting.co.za>
Message-ID: <1283374983.15.0.47054882952.issue9677@psf.upfronthosting.co.za>


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

Fixed in r84407.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Sep  1 23:03:57 2010
From: report at bugs.python.org (Dino Viehland)
Date: Wed, 01 Sep 2010 21:03:57 +0000
Subject: [issue9737] Del on memoryview crashes CPython
In-Reply-To: <1283375036.96.0.490730881857.issue9737@psf.upfronthosting.co.za>
Message-ID: <1283375036.96.0.490730881857.issue9737@psf.upfronthosting.co.za>


New submission from Dino Viehland <dinov at microsoft.com>:

x = bytearray(b'abc')
y = memoryview(x)
del y[0:1]

This crashes CPython 3.1.1 and 2.7.

----------
components: Interpreter Core
messages: 115333
nosy: dino.viehland
priority: normal
severity: normal
status: open
title: Del on memoryview crashes CPython
type: crash
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Sep  1 23:20:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 21:20:15 +0000
Subject: [issue9737] Del on memoryview crashes CPython
In-Reply-To: <1283375036.96.0.490730881857.issue9737@psf.upfronthosting.co.za>
Message-ID: <1283376015.37.0.769169292998.issue9737@psf.upfronthosting.co.za>


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

Nice catch, thank you. I've fixed it in r84408 (py3k), r84410 (3.1) and r84411 (2.7).

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

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

From report at bugs.python.org  Wed Sep  1 23:20:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 21:20:52 +0000
Subject: [issue9737] Del on memoryview crashes CPython
In-Reply-To: <1283375036.96.0.490730881857.issue9737@psf.upfronthosting.co.za>
Message-ID: <1283376052.82.0.802282592474.issue9737@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

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

From report at bugs.python.org  Wed Sep  1 23:21:16 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 01 Sep 2010 21:21:16 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1283376076.26.0.494538455772.issue1856@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Wed Sep  1 23:29:40 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 21:29:40 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1283376580.4.0.416028943145.issue8685@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

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

From report at bugs.python.org  Wed Sep  1 23:30:18 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 21:30:18 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1283376618.01.0.209206789277.issue8425@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

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

From report at bugs.python.org  Wed Sep  1 23:33:00 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Sep 2010 21:33:00 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1283376780.15.0.831048812101.issue2986@psf.upfronthosting.co.za>


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

While refactoring the code for 2.7, I discovered that the description of the heuristic for 2.6 and in the code comments is off by 1. "items that appear more than 1% of the time" should actually be "items whose duplicates (after the first) appear more than 1% of the time". The discrepancy arises because in the following code

        for i, elt in enumerate(b):
            if elt in b2j:
                indices = b2j[elt]
                if n >= 200 and len(indices) * 100 > n:
                    populardict[elt] = 1
                    del indices[:]
                else:
                    indices.append(i)
            else:
                b2j[elt] = [i]

len(indices) is retrieved *before* the index i of the current elt is added. Whatever one might think the heuristic 'should' have been (and by the nature of heuristics, there is no right answer), the default behavior must remain as it is, so we adjusted the code and doc to match that.

----------

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

From report at bugs.python.org  Wed Sep  1 23:36:01 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 21:36:01 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1283376961.33.0.684031370538.issue2459@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

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

From report at bugs.python.org  Wed Sep  1 23:37:13 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 21:37:13 +0000
Subject: [issue9155] Reserve COMPARE_OP for rich comparisons
In-Reply-To: <1278273241.45.0.419435390146.issue9155@psf.upfronthosting.co.za>
Message-ID: <1283377033.34.0.328518317626.issue9155@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

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

From report at bugs.python.org  Wed Sep  1 23:39:58 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 21:39:58 +0000
Subject: [issue1569291] Speed-up in array_repeat()
Message-ID: <1283377198.73.0.85594237113.issue1569291@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

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

From report at bugs.python.org  Wed Sep  1 23:42:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 01 Sep 2010 21:42:15 +0000
Subject: [issue9695] Return from generators in Python 3.2
In-Reply-To: <1282859934.45.0.531494544052.issue9695@psf.upfronthosting.co.za>
Message-ID: <1283377335.91.0.83077171302.issue9695@psf.upfronthosting.co.za>


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

Uh, if I understand correctly, this is akin to what PEP 380 does with generator returns, just with a different exception.

As such, if I'm not mistaken, it is a) a new language feature for after the moratorium and b) needs a competing PEP.

----------
nosy: +georg.brandl
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Wed Sep  1 23:46:04 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 21:46:04 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1283377564.27.0.424301167078.issue2690@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

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

From report at bugs.python.org  Wed Sep  1 23:49:36 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 21:49:36 +0000
Subject: [issue5362] Add configure option to disable Py3k warnings
In-Reply-To: <1235516116.64.0.427185955219.issue5362@psf.upfronthosting.co.za>
Message-ID: <1283377776.66.0.865843781704.issue5362@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Since this issue doesn't apply in Python 3 and (as I understand it) the 2.7 branch is only open to bug fixes, can we close this performance issue?

----------
nosy: +stutzbach

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

From report at bugs.python.org  Wed Sep  1 23:52:17 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 01 Sep 2010 21:52:17 +0000
Subject: [issue5362] Add configure option to disable Py3k warnings
In-Reply-To: <1235516116.64.0.427185955219.issue5362@psf.upfronthosting.co.za>
Message-ID: <1283377937.47.0.45659577398.issue5362@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/issue5362>
_______________________________________

From report at bugs.python.org  Wed Sep  1 23:59:30 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 01 Sep 2010 21:59:30 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1283378370.79.0.147775730422.issue2690@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Thu Sep  2 00:01:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Sep 2010 22:01:29 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1283378489.05.0.927779490115.issue9042@psf.upfronthosting.co.za>


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

Relying on str(cls) breaks if two classes have the same name, but I guess this is not a concern outside of the interactive interpreter. Patch looks good to me.

----------
stage:  -> patch review

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

From report at bugs.python.org  Thu Sep  2 00:41:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Sep 2010 22:41:35 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>


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

Many C functions have bytes argument (char* type) but the encoding is not documented. If would not be a problem if the encoding was always the same, but it is not. Examples:
 - format of PyUnicode_FromFormat() should be encoded as ISO-8859-1
 - filename of PyParser_ASTFromString() should be encoded as utf-8
 - filename of PyErr_SetFromErrnoWithFilename() should be encoded to the filesystem encoding (with strict error handler, and not surrogateescape)
 - 's' argument of PyParser_ASTFromString() should be encoded as utf-8 if PyPARSE_IGNORE_COOKIE flag is set, otherwise the parser checks for #coding:xxx cookie (if there is no cookie, utf-8 is used)

Attached patch is a try to document most low level functions. I choosed to add the name of function arguments in the headers because I consider that a header can be used as a quick documentation. I only touched .c files to change argument names.

It is hard to get the right encoding, so I cannot ensure that my patch is correct. My patch is just a draft.

I don't know if "encoded to utf-8" is the right expression. Or should it be "decoded as utf-8"?

----------
assignee: docs at python
components: Documentation, Interpreter Core, Unicode
files: encodings.patch
keywords: patch
messages: 115339
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Document the encoding of functions bytes arguments of the C API
versions: Python 3.2
Added file: http://bugs.python.org/file18705/encodings.patch

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

From report at bugs.python.org  Thu Sep  2 01:01:55 2010
From: report at bugs.python.org (ipatrol)
Date: Wed, 01 Sep 2010 23:01:55 +0000
Subject: [issue2340] Backport PEP 3132 (extended iterable unpacking)
In-Reply-To: <1205776715.68.0.275061992416.issue2340@psf.upfronthosting.co.za>
Message-ID: <1283382115.83.0.909293130296.issue2340@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

Can this be added in a minor release? I came across wanting it while parsing some html forms.

----------
nosy: +ipatrol

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

From report at bugs.python.org  Thu Sep  2 01:14:10 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Sep 2010 23:14:10 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1283382850.47.0.965971821979.issue9042@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The patch looks fine.

----------
nosy: +rhettinger
resolution:  -> accepted

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

From report at bugs.python.org  Thu Sep  2 01:23:23 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 01 Sep 2010 23:23:23 +0000
Subject: [issue2340] Backport PEP 3132 (extended iterable unpacking)
In-Reply-To: <1205776715.68.0.275061992416.issue2340@psf.upfronthosting.co.za>
Message-ID: <1283383403.79.0.926126190588.issue2340@psf.upfronthosting.co.za>


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

No, only bugfixes can go into Python 2.7.

----------

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

From report at bugs.python.org  Thu Sep  2 01:45:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Sep 2010 23:45:58 +0000
Subject: [issue9425] Rewrite import machinery to work with unicode paths
In-Reply-To: <1280448814.73.0.312881779361.issue9425@psf.upfronthosting.co.za>
Message-ID: <1283384758.46.0.798938516065.issue9425@psf.upfronthosting.co.za>


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

r84429 creates Py_UNICODE_strcat() (change with the patch: return the right value).

r84430 creates PyUnicode_strdup() (change with the patch: rename the function from Py_UNICODE_strdup() to PyUnicode_strdup() and mangle the function name).

----------

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

From report at bugs.python.org  Thu Sep  2 01:46:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Sep 2010 23:46:05 +0000
Subject: [issue9425] Rewrite import machinery to work with unicode paths
In-Reply-To: <1280448814.73.0.312881779361.issue9425@psf.upfronthosting.co.za>
Message-ID: <1283384765.68.0.582532921346.issue9425@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file18672/Py_UNICODE_strdup.patch

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

From report at bugs.python.org  Thu Sep  2 01:46:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Sep 2010 23:46:11 +0000
Subject: [issue9425] Rewrite import machinery to work with unicode paths
In-Reply-To: <1280448814.73.0.312881779361.issue9425@psf.upfronthosting.co.za>
Message-ID: <1283384771.13.0.86021673567.issue9425@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file18671/Py_UNICODE_strcat.patch

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

From report at bugs.python.org  Thu Sep  2 02:07:32 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Sep 2010 00:07:32 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1283386052.99.0.523936343968.issue8743@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The operator methods in setobject.c should be liberalized to accept instances of collections.Set as arguments.  For speed, they should continue to check PyAnySet_Check(other) first and then if that fails, fall back to testing PyObject_IsInstance(other, collections.Set).  

Internally, the set methods will still need to process "other" as just an iterable container because it cannot rely on elements in "other" as being hashable (for example, the ListBasedSet in the docs does not require hashability) or unique (as perceived by setobject.c it may not work with some set implementing a key-function for an equivalence class whose key-function would be unknown to setobject.c which relies on __hash__ and __eq__).

To implement PyObject_IsInstance(other, collections.Set), there may be a bootstrap issue (with the C code being compiled and runnable before _abcoll.py is able to create the Set ABC).  If so, it may be necessary to create an internal _BaseSet object in setobject.c that can be used in collections.Set.  Alternatively, the code in setobject.c can lazily (at runtime) lookup collections.Set by name and cache it so that we only do one successful lookup per session.

Whatever approach is taken, it should be done with an eye towards the larger problem that Python is filled with concrete isinstance() checks that pre-date ABCs and many of those need to be liberalized (accepting a registered ABC and providing different execution paths for known and unknown concrete types).

----------
stage: unit test needed -> needs patch

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

From report at bugs.python.org  Thu Sep  2 02:23:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Sep 2010 00:23:48 +0000
Subject: [issue9155] Reserve COMPARE_OP for rich comparisons
In-Reply-To: <1278273241.45.0.419435390146.issue9155@psf.upfronthosting.co.za>
Message-ID: <1283387028.15.0.919042469028.issue9155@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm marking this one as rejected.  The timings have shown mixed results (some favorable, some not).  In general, there is a bias against expanding the number of opcodes because 1) there aren't that many codes available, 2) it grows the size of the switch-case (which has been problematic from some compilers on various systems), and because it complicates other optimization efforts such as the peephole optimizer or in other tools that depend on bytecode (such as the Unladen Swallow LLVM project, Psyco, or ByteCodeHacks). 

Also, the potential improvement is very small because it removes only one indirection out of long chain of events involved in a comparison.  Most of the time is consumed in abstract dispatch to a concrete comparison method and it that method itself.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Thu Sep  2 02:26:19 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Sep 2010 00:26:19 +0000
Subject: [issue9634] Add timeout parameter to Queue.join()
In-Reply-To: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za>
Message-ID: <1283387179.52.0.557497601491.issue9634@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Kelly, thanks for posting the idea.
I'm going to close this one for now
but it can be reopened if compelling
use cases arise.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Thu Sep  2 02:30:35 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Sep 2010 00:30:35 +0000
Subject: [issue7796] No way to find out if an object is an instance of a
	namedtuple
In-Reply-To: <1264608669.85.0.379125118171.issue7796@psf.upfronthosting.co.za>
Message-ID: <1283387435.05.0.730624863987.issue7796@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am deferring this to Py3.3.  There is a workaround available just using duck-typing and I would like to wait until more more has been done on StructSeq before setting committing to an new namedtuple Abstract Base Class (one released, it would be very hard to change).  Also, I would like to see how pprint() evolves (because it may also want to have special handling for named tuples).

----------
priority: high -> low
resolution:  -> later
versions: +Python 3.3 -Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Sep  2 02:33:40 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Sep 2010 00:33:40 +0000
Subject: [issue1818] Add named tuple reader to CSV module
In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za>
Message-ID: <1283387620.95.0.499732590726.issue1818@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Unassigning, this needs fresh thought and a fresh patch from someone who can devote a little deep thinking on how to solve this problem cleanly.  In the meantime, it is no problem to simply cast the CSV tuples into named tuples.

----------
assignee: rhettinger -> 
priority: normal -> low
stage: patch review -> needs patch
versions:  -Python 3.2

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

From report at bugs.python.org  Thu Sep  2 02:38:32 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Sep 2010 00:38:32 +0000
Subject: [issue9269] Cannot pickle self-referencing sets
In-Reply-To: <1279234902.88.0.629141543515.issue9269@psf.upfronthosting.co.za>
Message-ID: <1283387912.87.0.490001741383.issue9269@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority: normal -> low

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

From report at bugs.python.org  Thu Sep  2 02:43:54 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Sep 2010 00:43:54 +0000
Subject: [issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to
	just	be a LOAD_CONST
In-Reply-To: <1243466391.88.0.68447044966.issue6133@psf.upfronthosting.co.za>
Message-ID: <1283388234.23.0.0771795110424.issue6133@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This proposal hasn't gotten much love or support and I'm no longer interested in it.  Aside from ''.join and '{}'.format, there doesn't seem to be many common cases, so there's no big win here.

----------
assignee: rhettinger -> 
resolution:  -> later
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Thu Sep  2 02:45:05 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Sep 2010 00:45:05 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1283388305.64.0.20642554595.issue4395@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: rhettinger -> terry.reedy
priority: normal -> low

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

From report at bugs.python.org  Thu Sep  2 03:25:19 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Sep 2010 01:25:19 +0000
Subject: [issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to
	just	be a LOAD_CONST
In-Reply-To: <1243466391.88.0.68447044966.issue6133@psf.upfronthosting.co.za>
Message-ID: <1283390719.5.0.164746375855.issue6133@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

What's the point of '{}'.format() anyway given the format() builtin?

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Thu Sep  2 03:28:38 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Sep 2010 01:28:38 +0000
Subject: [issue9734] ABC issubclass/isinstance leaks in Python 2
In-Reply-To: <1283366773.54.0.691168683166.issue9734@psf.upfronthosting.co.za>
Message-ID: <1283390918.14.0.701612353601.issue9734@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Will be fixed in 2.7.1.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Thu Sep  2 03:30:02 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Sep 2010 01:30:02 +0000
Subject: [issue7141] 2to3 should add from __future__ import print_statement
In-Reply-To: <1255620514.04.0.970254237923.issue7141@psf.upfronthosting.co.za>
Message-ID: <1283391002.65.0.168506829137.issue7141@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't think this is very useful. You could just as well exclude the future fixer completely.

----------

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

From report at bugs.python.org  Thu Sep  2 03:35:35 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Sep 2010 01:35:35 +0000
Subject: [issue7141] 2to3 should add from __future__ import print_statement
In-Reply-To: <1255620514.04.0.970254237923.issue7141@psf.upfronthosting.co.za>
Message-ID: <1283391335.45.0.235954812557.issue7141@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Excluding the future fixer would only get me half of the way there.  I would still need to add "from __future__ import print_statement" to all of my scripts if I want them to continue to work under 2.6.

(Well, for me personally, I have already done exactly that, by hand.  Rather tedious.)

----------

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

From report at bugs.python.org  Thu Sep  2 03:37:13 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 02 Sep 2010 01:37:13 +0000
Subject: [issue1552880] Unicode Imports
Message-ID: <1283391433.4.0.153957259426.issue1552880@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

> Yes, but in Python, U+DC80..D+DCFF range is used to store undecodable bytes. 
> Eg. 'abc\xff'.decode('ascii', 'surrogateescape') gives 'abc\udcff'.

That's an inventive way of breaking the unicode standard :)
Anyway, why would you worry about that?  My patch doesn't use "surrogateescape" so there is no problem.  There are only two places where I "decode":  
1) module names and sys.path components in the system file encoding:  If they contain undecodable characters, then that is an error.  No reason to propagate that error into the import machinery.
2) when decoding utf-8 back into unicode, but that utf-8 is already leagal since _we_ generated it.

If a _unicode_ input (sys.path) contains a valid surrogate pair, then the utf-8 encoder just encodes it.
But if it finds a lone surrogate as you describe (python special) then that represends an undecodable chacater, something that should have been covered earlier and something we know nothing about.  Clearly, that makes that particular unicode sys.path component invalid.

(Hm, I notice that 2.7 happily encodes lone surrogates to utf-8)

> Python 2.7 is out and I think it is too late to fix Python2. Anyway, Python2 
> uses bytes for sys.path or other paths, so the problem only occurs if the user 
> specifies unicode paths.
Which is precisely the case that it is designed to solve.  When the chinese user installs EVE Online in a weird folder, then that should work.
Also, 2.x is not quite dead yet.  There are quite a few people doing their own patches for their private purposes.  Although my patch won't go into any official version, there might be others in the same situation like us:  Trying to support an _embedded_ python 2.x version in an internationalized enverionment (on windows :)

----------

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

From report at bugs.python.org  Thu Sep  2 03:37:25 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 02 Sep 2010 01:37:25 +0000
Subject: [issue7141] 2to3 should add from __future__ import print_statement
In-Reply-To: <1283391335.45.0.235954812557.issue7141@psf.upfronthosting.co.za>
Message-ID: <AANLkTim5Pd868bfvoSFg+ec+PU3i879-fyWLg9TQV+qK@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/9/1 Daniel Stutzbach <report at bugs.python.org>:
>
> Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:
>
> Excluding the future fixer would only get me half of the way there. ?I would still need to add "from __future__ import print_statement" to all of my scripts if I want them to continue to work under 2.6.

I'm still apprehensive because it's not really the point of 2to3 to
port apps to 2.6.

----------

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

From report at bugs.python.org  Thu Sep  2 04:26:22 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Sep 2010 02:26:22 +0000
Subject: [issue7141] 2to3 should add from __future__ import print_statement
In-Reply-To: <1255620514.04.0.970254237923.issue7141@psf.upfronthosting.co.za>
Message-ID: <1283394382.84.0.44775470919.issue7141@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Well, I grant you that it's a bit of scope-creep, and if you want to reject it on those grounds I can't blame you.

To me it seems like a relatively small change that would greatly help people like myself who want to update older code so that it will run under 2.6, 2.7, and 3.1+.  Of course, since I don't know how to make the change, I could also be wrong about how easy it would be for a knowledgeable person to fit it into the existing 2to3 framework.

----------

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

From report at bugs.python.org  Thu Sep  2 04:51:49 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Sep 2010 02:51:49 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1283395909.51.0.207846961272.issue8743@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> The operator methods in setobject.c should be liberalized to accept
> instances of collections.Set as arguments.

Under this plan, set() and collections.Set will still have slightly different behavior.  collections.Set will be more liberal and accept any iterable.  Are you okay with that?  I don't feel strongly about this point; I just want to make sure it's a conscious decision.

I do feel strongly that set and collections.Set should be able to inter-operate nicely and the proposal satisfies that requirement so I would be happy with it.

> To implement PyObject_IsInstance(other, collections.Set), there may
> be a bootstrap issue (with the C code being compiled and runnable
> before _abcoll.py is able to create the Set ABC). Alternatively, 
> the code in setobject.c can lazily (at runtime) lookup 
> collections.Set by name and cache it so that we only do one
> successful lookup per session.

I favor the lazy lookup approach.

> Whatever approach is taken, it should be done with an eye towards 
> the larger problem that Python is filled with concrete isinstance()
> checks that pre-date ABCs and many of those need to be liberalized
> (accepting a registered ABC and providing different execution paths
> for known and unknown concrete types).

Agreed.  Ideally, the "PyObject_IsInstance(other, collections.Set)" logic would be abstracted out as much as possible so other parts of Python can make similar checks without needing tons of boilerplate code in every spot.

For what it's worth, I don't think we will find as many inconsistency issues with ABCs other than Set.  Set has methods that take another Set and return a third Set.  That forces different concrete implementations of the Set ABC to interact in a way that won't come up for a Sequence or Mapping.

(I suppose that Sequence.extend or MutableMapping.update are somewhat similar, but list.extend and dict.update are already very liberal in what they accept as a parameter.)

----------
resolution:  -> accepted
versions: +Python 3.1

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

From report at bugs.python.org  Thu Sep  2 05:10:34 2010
From: report at bugs.python.org (Meador Inge)
Date: Thu, 02 Sep 2010 03:10:34 +0000
Subject: [issue9633] pdb go stack up/down
In-Reply-To: <1282133837.82.0.171010459939.issue9633@psf.upfronthosting.co.za>
Message-ID: <1283397034.45.0.051502634719.issue9633@psf.upfronthosting.co.za>


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

I believe this is slightly tricky because 'bdb.format_stack_entry' makes references to '.f_locals' and 'bdb.format_stack_entry' is invoked in several places in 'pdb'.  One option would be to add a extra parameter to 'bdb.format_stack_entry' to accept a dictionary of locals to operate with.

I implemented this approach and added a doctest to verify.  See attached patch.  I didn't update the 'bdb' documentation to note the new parameter, but will if this approach seems reasonable.

----------
keywords: +patch
Added file: http://bugs.python.org/file18706/issue9633.patch

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

From report at bugs.python.org  Thu Sep  2 07:01:41 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Thu, 02 Sep 2010 05:01:41 +0000
Subject: [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>


New submission from Case Van Horsen <casevh at gmail.com>:

In several modules, the output of help(some_module) is wider than 80 characters. This results in extra line wrapping and incorrect formatting of the help text.

I've attached a single patch (doc_width1.diff) that corrects the issue for math, cmath, tuple, datetime, and time modules. I can continue to create patches for a few modules at a time, or I can create patches for individual modules.

I'm not changing any text, only adding \n as needed.

----------
components: Extension Modules
files: doc_width1.diff
keywords: patch
messages: 115359
nosy: casevh
priority: normal
severity: normal
status: open
title: Output of help(...) is wider than 80 characters
type: behavior
Added file: http://bugs.python.org/file18707/doc_width1.diff

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

From report at bugs.python.org  Thu Sep  2 07:57:22 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 02 Sep 2010 05:57:22 +0000
Subject: [issue9726] logging.handlers.RotatingFileHandler: implement "preserve
	log file name extension" feature
In-Reply-To: <1283281887.54.0.818676292303.issue9726@psf.upfronthosting.co.za>
Message-ID: <1283407042.59.0.319406347.issue9726@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Only bug-fixes are supposed to go into 2.7, so reclassifying.

----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip
versions: +Python 3.2 -Python 2.7

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

From report at bugs.python.org  Thu Sep  2 08:51:01 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Sep 2010 06:51:01 +0000
Subject: [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283410261.28.0.275436167586.issue9739@psf.upfronthosting.co.za>


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

Aren't there tools that extract only the first line of help?

----------
assignee:  -> docs at python
components: +Documentation -Extension Modules
nosy: +amaury.forgeotdarc, docs at python

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

From report at bugs.python.org  Thu Sep  2 10:55:15 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 02 Sep 2010 08:55:15 +0000
Subject: [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283417715.93.0.931955817756.issue9739@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/issue9739>
_______________________________________

From report at bugs.python.org  Thu Sep  2 10:57:20 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 02 Sep 2010 08:57:20 +0000
Subject: [issue7141] 2to3 should add from __future__ import print_statement
In-Reply-To: <1255620514.04.0.970254237923.issue7141@psf.upfronthosting.co.za>
Message-ID: <1283417840.58.0.185813441478.issue7141@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> it's not really the point of 2to3 to port apps to 2.6.

+1

----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Thu Sep  2 10:58:17 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 02 Sep 2010 08:58:17 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1283417897.14.0.431534876596.issue2459@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/issue2459>
_______________________________________

From report at bugs.python.org  Thu Sep  2 11:04:23 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Sep 2010 09:04:23 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1283418263.3.0.634667533576.issue8743@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Rough cut at a first patch is attached.

Still thinking about whether Set operations should be accepting any iterable or whether they should be tightened to expect other Set instances.  The API for set() came from set.py which was broadly discussed and widely exercised.  Guido was insistent that non-sets be excluded from the operator interactions (list.__iadd__ being on his list of regrets).   That was probably a good decision, but the Set API violated this norm and it did not include named methods like difference(), update(), and intersection() to handle the iterable cases.

Also, still thinking about whether the comparison operators should be making tight or loose checks.

----------
keywords: +patch
Added file: http://bugs.python.org/file18708/prelim.patch

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

From report at bugs.python.org  Thu Sep  2 12:56:34 2010
From: report at bugs.python.org (Mitar)
Date: Thu, 02 Sep 2010 10:56:34 +0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1283424994.97.0.459019594261.issue1652@psf.upfronthosting.co.za>


Mitar <mmitar at gmail.com> added the comment:

GHC Haskell compiler is currently opting for a different solution: installing an default empty handler which is cleared by exec automatically and signal handler is restored back to SIG_DFL:

http://hackage.haskell.org/trac/ghc/ticket/4274

----------
nosy: +mitar

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

From report at bugs.python.org  Thu Sep  2 13:56:51 2010
From: report at bugs.python.org (ipatrol)
Date: Thu, 02 Sep 2010 11:56:51 +0000
Subject: [issue9740] Support for HTTP 1.1 persistent connections throughout
	the standard library
In-Reply-To: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za>
Message-ID: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za>


New submission from ipatrol <ipatrol6010 at yahoo.com>:

HTTP 1.1 introduced persistent connections nearly six years ago. Yet this resource saving and speed improving option is not available in the standard library. Can this be added?

----------
components: Library (Lib)
messages: 115365
nosy: ipatrol
priority: normal
severity: normal
status: open
title: Support for HTTP 1.1 persistent connections throughout the standard library
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Sep  2 14:03:48 2010
From: report at bugs.python.org (ipatrol)
Date: Thu, 02 Sep 2010 12:03:48 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1283429028.28.0.0381276411519.issue1673007@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

Can this be somehow implemented as a bugfix patch as well on other versions?

----------
nosy: +ipatrol
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Sep  2 14:08:54 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Sep 2010 12:08:54 +0000
Subject: [issue9740] Support for HTTP 1.1 persistent connections throughout
	the standard library
In-Reply-To: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za>
Message-ID: <1283429334.52.0.928254823952.issue9740@psf.upfronthosting.co.za>


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

It seems that httplib is exactly what you need:
http://docs.python.org/library/httplib.html#examples

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> pending

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

From report at bugs.python.org  Thu Sep  2 14:18:08 2010
From: report at bugs.python.org (ipatrol)
Date: Thu, 02 Sep 2010 12:18:08 +0000
Subject: [issue9740] Support for HTTP 1.1 persistent connections throughout
	the standard library
In-Reply-To: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za>
Message-ID: <1283429888.74.0.172735555872.issue9740@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

No, httplib actually creates a second connection with the same object. Neither is their support in urllib, urllib2, nor in any of the HTTP servers. This would be really useful for a bot connected to an API.

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

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

From report at bugs.python.org  Thu Sep  2 14:24:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Sep 2010 12:24:22 +0000
Subject: [issue9740] Support for HTTP 1.1 persistent connections throughout
	the standard library
In-Reply-To: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za>
Message-ID: <1283430262.92.0.814186848661.issue9740@psf.upfronthosting.co.za>


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

Do you think you could provide a patch?

----------
nosy: +orsenthil, pitrou
stage:  -> needs patch
versions:  -Python 3.3

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

From report at bugs.python.org  Thu Sep  2 15:00:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Sep 2010 13:00:11 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1283432411.24.0.876923366212.issue1673007@psf.upfronthosting.co.za>


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

Only stable (2.7 and 3.1) and development versions (3.2) get bug fixes.

----------

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

From report at bugs.python.org  Thu Sep  2 15:37:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Sep 2010 13:37:37 +0000
Subject: [issue7796] No way to find out if an object is an instance of a
	namedtuple
In-Reply-To: <1264608669.85.0.379125118171.issue7796@psf.upfronthosting.co.za>
Message-ID: <1283434657.61.0.921530904367.issue7796@psf.upfronthosting.co.za>


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

To make sure I understand: StructSeq is the C-pendent of named tuples, and a NamedTuple ABC would have to work with StructSeqs too?

----------

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

From report at bugs.python.org  Thu Sep  2 15:42:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Sep 2010 13:42:49 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1283434969.21.0.226601496956.issue1673007@psf.upfronthosting.co.za>


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

New features can only go in 3.2. From a quick look, the patch looks ok.

----------
nosy: +pitrou
versions:  -Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Sep  2 15:53:01 2010
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 02 Sep 2010 13:53:01 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1283435581.24.0.542996463699.issue9042@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

Wouldn't constructing the key as a tuple of (class_, mofile) be much cleaner than making up an artificial key?

----------
nosy: +lehmannro

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

From report at bugs.python.org  Thu Sep  2 15:54:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Sep 2010 13:54:43 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1283435683.1.0.261026350318.issue9042@psf.upfronthosting.co.za>


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

This would avoid the issue with different classes having the same name, but otherwise would not make that much of a difference.

----------

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

From report at bugs.python.org  Thu Sep  2 15:58:31 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 02 Sep 2010 13:58:31 +0000
Subject: [issue941346] AIX shared library fix
In-Reply-To: <1283292976.5.0.979258468994.issue941346@psf.upfronthosting.co.za>
Message-ID: <4C7FAD80.3060005@users.sourceforge.net>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Le 01/09/2010 00:16, Antoine Pitrou a ?crit :
> In dynamic builds, there seem to be lots of messages such as:
>
> ld: 0711-224 WARNING: Duplicate symbol: .PyLong_FromString
> ld: 0711-224 WARNING: Duplicate symbol: PyLong_FromString
>
> Are you sure this is normal?

This is not normal, but I always had this warning and this does not 
prevent the libraries from working OK.
I will try to see if I can clean that.

> In any case, if you find a way to cleanup ld_so_aix, this should probably be checked in anyway. I doubt anybody else tests under AIX, so it's reasonable to trust you on this.
>
> Even better if you manage to diagnose and/or fix some of the test failures, by the way. (if not, you can still open separate issues for each of them)

Great! this is the kind of answer I was looking for. I will cleanup my 
patch to make it compatible with Python 2.7 and Python 3.1.2 and test it 
with those 2 versions.

I will also correct as many unitary tests as possible with this platform.
I already have a patch for issue 4026.

----------

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

From report at bugs.python.org  Thu Sep  2 16:16:34 2010
From: report at bugs.python.org (Meador Inge)
Date: Thu, 02 Sep 2010 14:16:34 +0000
Subject: [issue5109] array.array constructor very slow when passed an array
	object.
In-Reply-To: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>
Message-ID: <1283436994.34.0.120941708655.issue5109@psf.upfronthosting.co.za>


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

Overall, this patch look reasonable.  I tested on py3k and the the tests pass.  I also did a few micro-benchmarks to verify the speedup.  

One question I do have, though, is whether the 'len' calculation modifications are necessary?  This looks like an attempt to optimize more by taking advantage of a particular type's 'len' implementation, but in practice I am not sure it pays off.  In addition, it complicates the patch slightly.  I did the micro-benchmarks with the old 'len' calculation and the results where more-or-less the same as with the new 'len' calculation.  However, perhaps there are other cases where it would pay off that this simple micro-benchmark will not show.

# Micro-benchmarks
# python --with-pydebug
# OS X 10.6
# 2.26 GHz Core 2 Duo

# without patch
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 10)))"
100000 loops, best of 3: 17.7 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 100)))"
10000 loops, best of 3: 106 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 1000)))"
1000 loops, best of 3: 1.57 msec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 10000)))"
100 loops, best of 3: 17.4 msec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 100000)))"
10 loops, best of 3: 178 msec per loop

# with patch
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 10)))"
100000 loops, best of 3: 11.9 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 100)))"
10000 loops, best of 3: 56.1 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 1000)))"
1000 loops, best of 3: 785 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 10000)))"
100 loops, best of 3: 8.69 msec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 100000)))"
10 loops, best of 3: 88.7 msec per loop

# with patch, but 'len' mods removed
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 10)))"
100000 loops, best of 3: 11.2 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 100)))"
10000 loops, best of 3: 54.6 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 1000)))"
1000 loops, best of 3: 782 usec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 10000)))"
100 loops, best of 3: 8.66 msec per loop
motherbrain:py3k minge$ ./python.exe -m timeit -s 'import array' "array.array('i', array.array('i', range(0, 100000)))"
10 loops, best of 3: 88.3 msec per loop

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

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

From report at bugs.python.org  Thu Sep  2 16:18:49 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 02 Sep 2010 14:18:49 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283437129.37.0.380415925921.issue4026@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Hi,

Here is a patch that solves this problem. It was tested with Python 2.6.6 on AIX 6.1.

The same problem applies to Python 2.7 and 3.x, but since the syntax has been changed in configure.in for Python 2.7 and 3.x, I need to adapt a little bit my patch (coming soon).

regards

----------
keywords: +patch
nosy: +sable
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18709/Python-2.6.6_flock_AIX.diff

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

From report at bugs.python.org  Thu Sep  2 16:31:42 2010
From: report at bugs.python.org (Timothy Lee)
Date: Thu, 02 Sep 2010 14:31:42 +0000
Subject: [issue9741] msgfmt.py generates invalid mo because msgfmt.make() does
	not clear dictionary
In-Reply-To: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>
Message-ID: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>


New submission from Timothy Lee <timothy.ty.lee at gmail.com>:

This bug can potentially lead to generation of invalid mo files when msgfmt.make() is invoked more than once.

The bug has always been present in the source code.  The included patch should be applied to all maintained branches.

----------
components: Demos and Tools
files: msgfmt-clear.diff
keywords: patch
messages: 115378
nosy: timothy.ty.lee
priority: normal
severity: normal
status: open
title: msgfmt.py generates invalid mo because msgfmt.make() does not clear dictionary
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18710/msgfmt-clear.diff

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

From report at bugs.python.org  Thu Sep  2 16:35:35 2010
From: report at bugs.python.org (Misael Henriquez)
Date: Thu, 02 Sep 2010 14:35:35 +0000
Subject: [issue9742] Python 2.7: math module fails to build on Solaris 9
In-Reply-To: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>
Message-ID: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>


New submission from Misael Henriquez <misael.henriquez at merchantlink.com>:

building 'math' extension$
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/python/Python-2.7/Include -I/usr/local/src/python/Python-2.7 -c /usr/local/src/python/Python-2.7/Modules/mathmodule.c -o build/temp.solaris-2.9-sun4u-2.7/usr/local/src/python/Python-2.7/Modules/mathmodule.o$
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/python/Python-2.7/Include -I/usr/local/src/python/Python-2.7 -c /usr/local/src/python/Python-2.7/Modules/_math.c -o build/temp.solaris-2.9-sun4u-2.7/usr/local/src/python/Python-2.7/Modules/_math.o$
gcc -shared build/temp.solaris-2.9-sun4u-2.7/usr/local/src/python/Python-2.7/Modules/mathmodule.obuild/temp.solaris-2.9-sun4u-2.7/usr/local/src/python/Python-2.7/Modules/_math.o -L/usr/local/lib -lm -o build/lib.solaris-2.9-sun4u-2.7/math.so$
*** WARNING: renaming "math" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.9-sun4u-2.7/math.so: symbol round: referenced symbol not found$

----------
components: Extension Modules
messages: 115379
nosy: mhenriq
priority: normal
severity: normal
status: open
title: Python 2.7: math module fails to build on Solaris 9
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep  2 16:36:34 2010
From: report at bugs.python.org (Lily)
Date: Thu, 02 Sep 2010 14:36:34 +0000
Subject: [issue9743] __call__.__call__ chain cause crash when long enough
In-Reply-To: <1283438194.03.0.720338364102.issue9743@psf.upfronthosting.co.za>
Message-ID: <1283438194.03.0.720338364102.issue9743@psf.upfronthosting.co.za>


New submission from Lily <2ch.owner at gmail.com>:

Recursively getting __call__ method from existing __call__ causes interpreter infinitely grow in memory and calling resulting __call__.__call__...__call__.__call__() chain results in crash.

Platform: Windows 7 (x64)
Version: Python 2.7 (r27:82525) win32

Suggested solution:
* let the obj.__call__.__call__ point to obj.__call__

----------
components: Interpreter Core
files: ###crasher.py
messages: 115380
nosy: modchan
priority: normal
severity: normal
status: open
title: __call__.__call__ chain cause crash when long enough
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file18711/###crasher.py

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

From report at bugs.python.org  Thu Sep  2 16:48:04 2010
From: report at bugs.python.org (Lily)
Date: Thu, 02 Sep 2010 14:48:04 +0000
Subject: [issue9744] calling __getattribute__ with wrong instance causes hang
	up
In-Reply-To: <1283438884.05.0.113900555872.issue9744@psf.upfronthosting.co.za>
Message-ID: <1283438884.05.0.113900555872.issue9744@psf.upfronthosting.co.za>


New submission from Lily <2ch.owner at gmail.com>:

Look for example file.

Current behaviour: one file is started, A.__getattribute__ will be called repeatedly. Entire application will not react on KeyboardInterrupt.

Expected behaviour: exception to be raised "TypeError: unbound method __getattribute__() must be called with A instance as first argument (got M instance instead)"

Platform: Windows 7 (x64)
Version: Python 2.7 (r27: 82525)

----------
components: Interpreter Core
files: ###hanger.py
messages: 115381
nosy: modchan
priority: normal
severity: normal
status: open
title: calling __getattribute__ with wrong instance causes hang up
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file18712/###hanger.py

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

From report at bugs.python.org  Thu Sep  2 16:50:50 2010
From: report at bugs.python.org (Lily)
Date: Thu, 02 Sep 2010 14:50:50 +0000
Subject: [issue9744] calling __getattribute__ with wrong instance causes hang
	up
In-Reply-To: <1283438884.05.0.113900555872.issue9744@psf.upfronthosting.co.za>
Message-ID: <1283439050.31.0.197142302948.issue9744@psf.upfronthosting.co.za>


Changes by Lily <2ch.owner at gmail.com>:


----------
versions: +Python 2.6

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

From report at bugs.python.org  Thu Sep  2 16:54:47 2010
From: report at bugs.python.org (Remi Broemeling)
Date: Thu, 02 Sep 2010 14:54:47 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1283439287.35.0.939401258442.issue7077@psf.upfronthosting.co.za>


Remi Broemeling <remi at broemeling.org> added the comment:

I was encountering the logging.handlers.SysLogHandler bug described by Georg Brandl yesterday/today -- it took quite a while to track down the issue as I assumed it would be in either my code or possibly the framework code (Django).  I didn't take into account that the issue might well be in Python's core logging library.

I've applied the patch (r84222) to my environment and it works, would vote this issue up as needing to be fixed in stable releases of Python ASAP.  Not much worse than sporadically failing logging (i.e. if you're logging both UTF and non-UTF log lines).

----------
nosy: +Remi.Broemeling

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

From report at bugs.python.org  Thu Sep  2 16:59:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Sep 2010 14:59:07 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1283439547.24.0.818477955267.issue7077@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


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

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

From report at bugs.python.org  Thu Sep  2 17:02:07 2010
From: report at bugs.python.org (v_peter)
Date: Thu, 02 Sep 2010 15:02:07 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1283439727.57.0.428272154045.issue9042@psf.upfronthosting.co.za>


v_peter <leanmeandonothingmachine at gmail.com> added the comment:

Here's a second patch with 

key = (class_, os.path.abspath(mofile)))

----------
Added file: http://bugs.python.org/file18713/class_cache2.diff

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

From report at bugs.python.org  Thu Sep  2 17:06:51 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Sep 2010 15:06:51 +0000
Subject: [issue9212] dict_keys purports to implement the Set ABC,
	but is missing the isdisjoint method
In-Reply-To: <1278702217.69.0.69895367614.issue9212@psf.upfronthosting.co.za>
Message-ID: <1283440011.93.0.092623829969.issue9212@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Committed to py3k in r84435.  Raymond, do you want to look the commit over before I merge it into 3.1 and 2.7?

----------

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

From report at bugs.python.org  Thu Sep  2 17:12:02 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Sep 2010 15:12:02 +0000
Subject: [issue9212] dict_keys purports to implement the Set ABC,
	but is missing the isdisjoint method
In-Reply-To: <1278702217.69.0.69895367614.issue9212@psf.upfronthosting.co.za>
Message-ID: <1283440322.73.0.503017771693.issue9212@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Meant to add:

I made some relatively minor changes to Daniel Urban's patch.  Mostly, I rearranged the order of a few things to avoid unnecessary work (e.g., only compute "len_other" if we've already checked that "other" is a set).

Thank you Daniel for the patch! :-)

----------

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

From report at bugs.python.org  Thu Sep  2 17:14:25 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Sep 2010 15:14:25 +0000
Subject: [issue9212] dict_keys purports to implement the Set ABC,
	but is missing the isdisjoint method
In-Reply-To: <1278702217.69.0.69895367614.issue9212@psf.upfronthosting.co.za>
Message-ID: <1283440465.09.0.787349938657.issue9212@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Also, credited Daniel Urban for the patch in r84436 (forgot that the first time around -- sorry!).

----------

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

From report at bugs.python.org  Thu Sep  2 17:19:31 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 02 Sep 2010 15:19:31 +0000
Subject: [issue9743] __call__.__call__ chain cause crash when long enough
In-Reply-To: <1283438194.03.0.720338364102.issue9743@psf.upfronthosting.co.za>
Message-ID: <1283440771.02.0.0592156405183.issue9743@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I can duplicate this as a segmentation fault under 2.7 on Mac OS, but not under Windows 2.6 (ActiveState).

What platform are you using, and what output do you see?

----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Sep  2 17:27:26 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Sep 2010 15:27:26 +0000
Subject: [issue9743] __call__.__call__ chain cause crash when long enough
In-Reply-To: <1283438194.03.0.720338364102.issue9743@psf.upfronthosting.co.za>
Message-ID: <1283441246.6.0.772204264992.issue9743@psf.upfronthosting.co.za>


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

On Windows, a stack overflow often causes the program to silently exit.
Try to add some print statement at the end and see if it executes.

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

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

From report at bugs.python.org  Thu Sep  2 17:52:15 2010
From: report at bugs.python.org (John Ehresman)
Date: Thu, 02 Sep 2010 15:52:15 +0000
Subject: [issue9745] MSVC .pdb files not created by python 2.7 distutils
In-Reply-To: <1283442735.74.0.917204488917.issue9745@psf.upfronthosting.co.za>
Message-ID: <1283442735.74.0.917204488917.issue9745@psf.upfronthosting.co.za>


New submission from John Ehresman <jpe at wingware.com>:

.pdb files are not created because /pdb:None is set as an option on line 415 of msvc9compiler.py.  Removing the /pdb:None works to write the .pdb file and allow symbols to be loaded in the VS 2008 debugger in the one extension I tried.  Anyone know why /pdb:None was added?

----------
components: Windows
messages: 115389
nosy: jpe
priority: normal
severity: normal
status: open
title: MSVC .pdb files not created by python 2.7 distutils
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep  2 17:55:47 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 02 Sep 2010 15:55:47 +0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1283442947.35.0.361899959054.issue1652@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

closing because it is too late to backport this to 2.7.  It is available as a backport in http://code.google.com/p/python-subprocess32/.

As for the idea of not using SIG_IGN and installing a default no-op handler, that is another approach.

signal.getsignal would need to be able to return it so that software wanting to temporarily handle its own sigpipes could restore that behavior afterwards.

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

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

From report at bugs.python.org  Thu Sep  2 18:01:16 2010
From: report at bugs.python.org (Misael Henriquez)
Date: Thu, 02 Sep 2010 16:01:16 +0000
Subject: [issue9742] Python 2.7: math module fails to build on Solaris 9
In-Reply-To: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>
Message-ID: <1283443276.95.0.419317395589.issue9742@psf.upfronthosting.co.za>


Misael Henriquez <misael.henriquez at merchantlink.com> added the comment:

The problem appears to be the lack of a round function in Solaris 9.  This compiles find in Solaris 10, but I need it in Solaris 9.

configure:11989: checking for round
configure:11989: gcc -o conftest -g -O2   conftest.c -lresolv -lsocket -lnsl -lrt -ldl  -lpthread -lm >&5
/var/tmp//ccWVF7bf.o: In function `main':
/usr/local/src/python/Python-2.7/conftest.c:287: undefined reference to `round'

----------

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

From report at bugs.python.org  Thu Sep  2 18:02:58 2010
From: report at bugs.python.org (Alex)
Date: Thu, 02 Sep 2010 16:02:58 +0000
Subject: [issue9743] __call__.__call__ chain cause crash when long enough
In-Reply-To: <1283438194.03.0.720338364102.issue9743@psf.upfronthosting.co.za>
Message-ID: <1283443378.25.0.257438622935.issue9743@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

This seems to be another case of "C stack depth not reflected in the stack counter".

----------
nosy: +alex

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

From report at bugs.python.org  Thu Sep  2 18:13:03 2010
From: report at bugs.python.org (Matt Kraai)
Date: Thu, 02 Sep 2010 16:13:03 +0000
Subject: [issue9664] Make gzip module not require that underlying file object
	support seek
In-Reply-To: <1282550810.11.0.164823540463.issue9664@psf.upfronthosting.co.za>
Message-ID: <1283443983.38.0.408438931014.issue9664@psf.upfronthosting.co.za>


Matt Kraai <kraai at ftbfs.org> added the comment:

I don't know the gzip format well enough, but I was hoping that it would be possible to iterate through the lines of a gzip-compressed stream without having to use any of the functions that would require seeking.

----------
nosy: +kraai

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

From report at bugs.python.org  Thu Sep  2 18:42:02 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 02 Sep 2010 16:42:02 +0000
Subject: [issue9743] __call__.__call__ chain cause crash when long enough
In-Reply-To: <1283438194.03.0.720338364102.issue9743@psf.upfronthosting.co.za>
Message-ID: <1283445722.86.0.365102847316.issue9743@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Amaury: Good point. The Windows version is failing, too. A print statement at the end doesn't get executed.

----------

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

From report at bugs.python.org  Thu Sep  2 18:45:28 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 02 Sep 2010 16:45:28 +0000
Subject: [issue8265] test_float fails on ARM Linux EABI with soft floating
	point
In-Reply-To: <1269946366.65.0.0501186219601.issue8265@psf.upfronthosting.co.za>
Message-ID: <1283445928.17.0.575004273249.issue8265@psf.upfronthosting.co.za>


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

I checked with gcc-4.4 from the 4.4 branch, and with a recent build from the trunk.  The check fails with -O0, and succeeds with -O1 and higher.

Is the testcode from r82957 really using the optimization flags?

----------

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

From report at bugs.python.org  Thu Sep  2 19:53:13 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 02 Sep 2010 17:53:13 +0000
Subject: [issue9742] Python 2.7: math module fails to build on Solaris 9
In-Reply-To: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>
Message-ID: <1283449993.14.0.472809567258.issue9742@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/issue9742>
_______________________________________

From report at bugs.python.org  Thu Sep  2 20:30:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Sep 2010 18:30:54 +0000
Subject: [issue9745] MSVC .pdb files not created by python 2.7 distutils
In-Reply-To: <1283442735.74.0.917204488917.issue9745@psf.upfronthosting.co.za>
Message-ID: <1283452254.04.0.809666336773.issue9745@psf.upfronthosting.co.za>


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


----------
assignee:  -> tarek
components: +Distutils
nosy: +eric.araujo, tarek
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Sep  2 20:34:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Sep 2010 18:34:27 +0000
Subject: [issue7299] setup.py install doesn't honor PYTHONUSERBASE
In-Reply-To: <1257857799.68.0.397965237537.issue7299@psf.upfronthosting.co.za>
Message-ID: <1283452467.66.0.867085579917.issue7299@psf.upfronthosting.co.za>


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


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: pending -> closed

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

From report at bugs.python.org  Thu Sep  2 20:36:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Sep 2010 18:36:01 +0000
Subject: [issue959576] Can't build Python on POSIX w/o $HOME
Message-ID: <1283452561.74.0.903342495955.issue959576@psf.upfronthosting.co.za>


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


----------
stage: unit test needed -> committed/rejected
status: pending -> closed

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

From report at bugs.python.org  Thu Sep  2 21:18:04 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Sep 2010 19:18:04 +0000
Subject: [issue9213] range purports to implement the Sequence ABC,
	but is missing index and count methods
In-Reply-To: <1278702375.23.0.863463663463.issue9213@psf.upfronthosting.co.za>
Message-ID: <1283455084.5.0.620679456196.issue9213@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Thank you for the patch.

The patch doesn't handle the case where the object being searched for is !PyLong_CheckExact.  For example, the user might pass in a sub-type of int.  The existing range_contains supports that case, so it seems like we should support it in range_index and range_count.

The Sequence ABC's .index method doesn't include the optional start and stop parameters that are present on list.index.  Since it's not part of the ABC, it's not mandatory that we implement those for range.index.  The patch includes support for start and stop.

Attached is a greatly revised patch, with two significant changes:
- Adds support for !PyLong_CheckExact (using _PySequence_IterSearch)
- Drops support for the start and stop parameters to index

Dropping support for the start and stop parameters greatly simplified the code.  If we want to support start and stop, then the code will need to get more complicated to handle the !PyLong_CheckExact case (since PySequence_IterSearch doesn't support start and stop).

My patch abstracts out most of the code that had originally been in range_contains into a new function range_contains_long so that it can be called by range_contains, range_count, and range_index.  The diff makes that part look like a large change, but it's mostly a whitespace change (the refactored code lost one indentation level but is otherwise unchanged).

I uploaded Daniel Urban's patch and mine to Rietveld:
http://codereview.appspot.com/2146041/

Any strong feelings on whether range.index should support the start and stop arguments provided by list.index, tuple.index, and str.index, but not by collections.Sequence.index?

----------
Added file: http://bugs.python.org/file18714/issue9213b.diff

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

From report at bugs.python.org  Thu Sep  2 21:19:19 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 02 Sep 2010 19:19:19 +0000
Subject: [issue9741] msgfmt.py generates invalid mo because msgfmt.make() does
	not clear dictionary
In-Reply-To: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>
Message-ID: <1283455159.74.0.216898029015.issue9741@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
stage:  -> patch review
versions:  -Python 2.5, Python 2.6, Python 3.3

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

From report at bugs.python.org  Thu Sep  2 21:19:26 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Sep 2010 19:19:26 +0000
Subject: [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In the list of operations supported by all sequence types, the .index and .count methods should be included.  They are defined by the collections.Sequence ABC that all sequences support.

(except for range objects, but that will be fixed in Issue9213)

----------
assignee: docs at python
components: Documentation
messages: 115397
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: All sequence types support .index and .count
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Sep  2 21:40:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Sep 2010 19:40:51 +0000
Subject: [issue9742] Python 2.7: math module fails to build on Solaris 9
In-Reply-To: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>
Message-ID: <1283456451.91.0.604160383177.issue9742@psf.upfronthosting.co.za>


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

Hmm.  There should be a configure-time test for 'round'.  Could you look for a line something like:

  checking for round... yes

in the configure output and tell me whether you've got a 'yes' or a 'no' there?

----------
assignee:  -> mark.dickinson

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

From report at bugs.python.org  Thu Sep  2 21:48:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Sep 2010 19:48:16 +0000
Subject: [issue9742] Python 2.7: math module fails to build on Solaris 9
In-Reply-To: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>
Message-ID: <1283456896.5.0.196357169036.issue9742@psf.upfronthosting.co.za>


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

Ah.  Reading your second message more closely, you're presumably getting a 'no' there.  Could you double check that 'HAVE_ROUND' is not defined in pyconfig.h?

In that case, what's supposed to happen is that there's a substitute 'round' function defined in Python/pymath.c that gets used.  That's clearly working okay in the Python core, since it looks like your build doesn't fail until you get to the module build stage, and 'round' is used in Objects/floatobject.c in the core.

But I'm guessing that for some reason your Python executable isn't exporting that 'round' symbol that's defined in pymath.c.  I'm not sure why that would be.

----------

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

From report at bugs.python.org  Thu Sep  2 21:50:19 2010
From: report at bugs.python.org (Misael Henriquez)
Date: Thu, 02 Sep 2010 19:50:19 +0000
Subject: [issue9742] Python 2.7: math module fails to build on Solaris 9
In-Reply-To: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>
Message-ID: <1283457019.08.0.622050159474.issue9742@psf.upfronthosting.co.za>


Misael Henriquez <misael.henriquez at merchantlink.com> added the comment:

The check for round failed during configure.  I included a bit of that in my second note above.  Here's a bit more of the output:

collect2: ld returned 1 exit status
configure:11989: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define _GNU_SOURCE 1
| #define _NETBSD_SOURCE 1
<snip>
| /* Override any GCC internal prototype to avoid an error.
|    Use char because int might match the return type of a GCC
|    builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char round ();
| /* The GNU C library defines this for functions which it implements
|     to always fail with ENOSYS.  Some functions are actually named
|     something starting with __ and the normal name is an alias.  */
| #if defined __stub_round || defined __stub___round
| choke me
| #endif
|
| int
| main ()
| {
| return round ();
|   ;
|   return 0;
| }
configure:11989: result: no

----------

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

From report at bugs.python.org  Thu Sep  2 21:55:57 2010
From: report at bugs.python.org (Misael Henriquez)
Date: Thu, 02 Sep 2010 19:55:57 +0000
Subject: [issue9742] Python 2.7: math module fails to build on Solaris 9
In-Reply-To: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>
Message-ID: <1283457357.7.0.295520703276.issue9742@psf.upfronthosting.co.za>


Misael Henriquez <misael.henriquez at merchantlink.com> added the comment:

Thanks for your attention to this issue.  It sounds like you're onto something regarding the stand-in function not getting exported.  I'm not sure what to check next, though.

>From pyconfig.h:

/* Define to 1 if you have the `round' function. */
/* #undef HAVE_ROUND */

>From Python/pymath.c:

#ifndef HAVE_ROUND
double
round(double x)
{
    double absx, y;
    absx = fabs(x);
    y = floor(absx);
    if (absx - y >= 0.5)
    y += 1.0;
    return copysign(y, x);
}
#endif /* HAVE_ROUND */

----------

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

From report at bugs.python.org  Thu Sep  2 22:19:41 2010
From: report at bugs.python.org (Remi Broemeling)
Date: Thu, 02 Sep 2010 20:19:41 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1283458781.99.0.358053128744.issue7077@psf.upfronthosting.co.za>


Remi Broemeling <remi at broemeling.org> added the comment:

Attaching UTFFixedSysLogHandler, which is a sub-class of logging.handlers.SysLogHandler.  The sub-class re-implements the emit() code to put the BOM in the right place (a re-implementation of r84218 and r84222).  Can be used with existing Python codebases as a bug-fixed drop-in-replacement for logging.handlers.SysLogHandler without having to edit the core python module.  Just use UTFFixedSysLogHandler instead of logging.handlers.SysLogHandler.

Online necessary until such time as the bug-fixes are pulled into stable versions of python.

----------
Added file: http://bugs.python.org/file18715/utffixedsysloghandler.py

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

From report at bugs.python.org  Thu Sep  2 22:20:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Sep 2010 20:20:52 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283458852.05.0.424116430434.issue9730@psf.upfronthosting.co.za>


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

See issue 4769, which would partially fix this problem if implemented correctly.  The docs should still be given a thorough review to use the appropriate bytes/string language.

There is a way to do automated testing of the code in the docs, but nobody has done the work to automate it yet.  Sphinx only recently got 3.x support, before which it wasn't even possible.  To run it by hand, do 'make doctest' in the Doc subdirectory of the checkout...the first step will be to fix all the failures....

----------
dependencies: +b64decode should accept strings or bytes
nosy: +r.david.murray

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

From report at bugs.python.org  Thu Sep  2 22:53:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Sep 2010 20:53:14 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1283460794.51.0.445894929075.issue9738@psf.upfronthosting.co.za>


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

I think either of these is correct:
- a UTF-8-encoded string
- a string encoded in UTF-8

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

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

From report at bugs.python.org  Thu Sep  2 23:13:14 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 02 Sep 2010 21:13:14 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1283461994.22.0.157742760148.issue9738@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> I think either of these is correct:
> - a UTF-8-encoded string
> - a string encoded in UTF-8

Possibly use the word "buffer" here, rather than "string", as "string" may suggest the "str" type.

Or even: "NUL-terminated buffer of UTF-8-encoded bytes", or whatnot.

(sorry for bikeshedding)

----------
nosy: +dmalcolm

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

From report at bugs.python.org  Thu Sep  2 23:13:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Sep 2010 21:13:25 +0000
Subject: [issue9740] Support for HTTP 1.1 persistent connections throughout
	the standard library
In-Reply-To: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za>
Message-ID: <1283462005.35.0.772373007471.issue9740@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Sep  2 23:47:07 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 02 Sep 2010 21:47:07 +0000
Subject: [issue9421] configparser.ConfigParser's getint,
	getboolean and getfloat don't accept `vars`
In-Reply-To: <1280428369.21.0.84678458473.issue9421@psf.upfronthosting.co.za>
Message-ID: <1283464027.65.0.426879171409.issue9421@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


Removed file: http://bugs.python.org/file18458/issue9421.diff

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

From report at bugs.python.org  Fri Sep  3 00:20:32 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 02 Sep 2010 22:20:32 +0000
Subject: [issue9421] configparser.ConfigParser's getint,
	getboolean and getfloat don't accept `vars`
In-Reply-To: <1280428369.21.0.84678458473.issue9421@psf.upfronthosting.co.za>
Message-ID: <1283466032.24.0.759907545906.issue9421@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Patch updated:
- _UNSET removed from docs in favor of a more natural syntax (square brackets around optional arguments)
- _COMPATIBLE left in the docs because I find less magical in that case (+ it's already covered in the docs what this special case means)
- fixed docs improperly specifying `comment_prefixes` for ConfigParser and SafeConfigParser
- docs include a remark on where to find explanation for 'vars' and 'default' in every coercing getter
- tortured code refactored
- _unify_boolean renamed to _convert_to_boolean
- _UNSET and _COMPATIBLE moved to module level (test updates)
- _boolean_states renamed to BOOLEAN_STATES (for consistency with regular expression constants)
- _convert_to_boolean and BOOLEAN_STATES left in RawConfigParser class to enable users customize them (e.g. by specifying locale-specific 'yes'/'no' pairs or things like 'enable'/'disable', etc. etc.). Customization should be instance-specific.

----------
Added file: http://bugs.python.org/file18716/issue9421.diff

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

From report at bugs.python.org  Fri Sep  3 00:29:20 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 02 Sep 2010 22:29:20 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1283466560.03.0.116963785291.issue7005@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

This one is strange. Trying to set a None value through set() raises 'TypeError: option values must be strings' on both Python 3.2 and 2.7. A string value of 'None' behaves as expected (e.g. correctly).

----------

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

From report at bugs.python.org  Fri Sep  3 00:48:40 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 02 Sep 2010 22:48:40 +0000
Subject: [issue5404] Cross-compiling Python
In-Reply-To: <1235984629.04.0.168155698084.issue5404@psf.upfronthosting.co.za>
Message-ID: <1283467720.48.0.0127838768987.issue5404@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy: +gvanrossum

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

From report at bugs.python.org  Fri Sep  3 01:13:10 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 02 Sep 2010 23:13:10 +0000
Subject: [issue843590] 'macintosh' encoding alias for 'mac_roman'
Message-ID: <1283469190.57.0.375034804651.issue843590@psf.upfronthosting.co.za>


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

Martin, the typo was fixed subsequently by r84231.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Fri Sep  3 01:34:38 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 02 Sep 2010 23:34:38 +0000
Subject: [issue9719] build_ssl.py: cannot find 'asm64/*.*'
In-Reply-To: <1283202305.21.0.603628878344.issue9719@psf.upfronthosting.co.za>
Message-ID: <1283470478.35.0.83819727003.issue9719@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

When I disabled r83335, openssl build fails:

 set ASM=ml64 /c /Cp /Cx /Zi
  crypto\x86_64cpuid.pl tmp64\x86_64cpuid.asm
 ml64 /c /Cp /Cx /Zi /Fotmp64\x86_64cpuid.obj tmp64\x86_64cpuid.asm
 Assembling: tmp64\x86_64cpuid.asm
MASM : fatal error A1000:cannot open file : tmp64\x86_64cpuid.asm

I guess the real question is - where I do get the ./asm64/ directory from? It is not found in the openssl-1.0.0a.tar.gz source.

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

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

From report at bugs.python.org  Fri Sep  3 02:50:11 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 03 Sep 2010 00:50:11 +0000
Subject: [issue7141] 2to3 should add from __future__ import print_statement
In-Reply-To: <1255620514.04.0.970254237923.issue7141@psf.upfronthosting.co.za>
Message-ID: <1283475011.72.0.859717468429.issue7141@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I rejecting, mostly to avoid feature creep. (This shouldn't be too difficult to accomplish with a shell script.) You could also look at 3to2.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Fri Sep  3 04:06:09 2010
From: report at bugs.python.org (Neil Tallim)
Date: Fri, 03 Sep 2010 02:06:09 +0000
Subject: [issue9747] os.getresgid() documentation mentions "user ids",
	not "group ids"
In-Reply-To: <1283479568.94.0.540639670687.issue9747@psf.upfronthosting.co.za>
Message-ID: <1283479568.94.0.540639670687.issue9747@psf.upfronthosting.co.za>


New submission from Neil Tallim <red.hamsterx at gmail.com>:

Super-low-priority (it's obvious from context and unlike to confuse anyone who knows what they're looking at), but the os module's description for getresgid() is "Return a tuple (rgid, egid, sgid) denoting the current process?s real, effective, and saved user ids."

It should be "Return a tuple (rgid, egid, sgid) denoting the current process?s real, effective, and saved group ids."

----------
assignee: docs at python
components: Documentation
messages: 115411
nosy: Red HamsterX, docs at python
priority: normal
severity: normal
status: open
title: os.getresgid() documentation mentions "user ids", not "group ids"
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Sep  3 04:11:16 2010
From: report at bugs.python.org (stephenk)
Date: Fri, 03 Sep 2010 02:11:16 +0000
Subject: [issue9748] .inputrc magic-space breaks interactive mode
Message-ID: <1283479876.86.0.00626935361608.issue9748@psf.upfronthosting.co.za>


Changes by stephenk <krauth.spam1 at gmail.com>:


----------
components: None
nosy: stephenk
priority: normal
severity: normal
status: open
title: .inputrc magic-space breaks interactive mode
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Sep  3 04:17:05 2010
From: report at bugs.python.org (stephenk)
Date: Fri, 03 Sep 2010 02:17:05 +0000
Subject: [issue9748] .inputrc magic-space breaks interactive mode
In-Reply-To: <1283480225.9.0.883250017145.issue9748@psf.upfronthosting.co.za>
Message-ID: <1283480225.9.0.883250017145.issue9748@psf.upfronthosting.co.za>


New submission from stephenk <krauth.spam1 at gmail.com>:

Adding the following line to ~/.inputrc for bash commandline usage will break the python interactive interpreter.  Specifically, you can no longer type "space" characters:

Space: magic-space

This is fairly serious for bash users, because once you've lived with magic-space you don't ever want to live without it.

This was tested under 2 different operating systems (Ubuntu 9.10, FreeBSD 6.0) and 3 different python versions, so the problem seems widespread.

----------

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

From report at bugs.python.org  Fri Sep  3 04:57:03 2010
From: report at bugs.python.org (=?utf-8?b?UHlyeSBTw6RpbMOk?=)
Date: Fri, 03 Sep 2010 02:57:03 +0000
Subject: [issue9749] tuple-to-list conversion
In-Reply-To: <1283482623.34.0.524181543079.issue9749@psf.upfronthosting.co.za>
Message-ID: <1283482623.34.0.524181543079.issue9749@psf.upfronthosting.co.za>


New submission from Pyry S?il? <roadrunnahz at gmail.com>:

As I am new to Python and programming as a whole, I do not have extensive knowledge of how to correctly report a bug. And as such I must apologize for the inconvenience.

My lack of knowledge makes this only an assumption, but...

---

>>>l
[(1, 4, 7), (2, 5, 8), (3, 6, 9)]
>>>q = r = s = []
>>>for i in range(len(l)):
...    for x in l[i]:
...        q.append(x)
...    s = q
...    q = []
...    print s,    # print used to increase clarity
...    r.append(s)
...    print r    # and the next is printed out as:
...
[1, 4, 7] [1, 4, 7, [...]]
[2, 5, 8] [1, 4, 7, [...], [2, 5, 8]]
[3, 6, 9] [1, 4, 7, [...], [2, 5, 8], [3, 6, 9]]
>>>r
[1, 4, 7, [...], [2, 5, 8], [3, 6, 9]]
>>>r[3]    # for extra
[1, 4, 7, [...], [2, 5, 8], [3, 6, 9]]

---

Supposed outcome for r being [[1, 4, 7], [2, 5, 8], [3, 6, 9]]

----------
components: None
messages: 115413
nosy: Pyry.S?il?
priority: normal
severity: normal
status: open
title: tuple-to-list conversion
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Sep  3 04:58:21 2010
From: report at bugs.python.org (=?utf-8?b?UHlyeSBTw6RpbMOk?=)
Date: Fri, 03 Sep 2010 02:58:21 +0000
Subject: [issue9749] tuple-to-list conversion
In-Reply-To: <1283482623.34.0.524181543079.issue9749@psf.upfronthosting.co.za>
Message-ID: <1283482701.57.0.211920011836.issue9749@psf.upfronthosting.co.za>


Changes by Pyry S?il? <roadrunnahz at gmail.com>:


----------
components:  -None

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

From report at bugs.python.org  Fri Sep  3 05:25:27 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 03 Sep 2010 03:25:27 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1283484327.58.0.338245250619.issue7005@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

I've attached a diagnostic script that I ran with Python 2.4..3.2 (current py3k HEAD); there are two output variants:

"old style":

    [section]
    option = None

"new style":

    [section]
    option

This is the output I get when running this script for each of those Python versions:

    2.4.6 RawConfigParser: old-style output
    2.4.6 SafeConfigParser: raised TypeError on set
    2.4.6 ConfigParser: old-style output

    2.5.5 RawConfigParser: old-style output
    2.5.5 SafeConfigParser: raised TypeError on set
    2.5.5 ConfigParser: old-style output

    2.6.5 RawConfigParser: old-style output
    2.6.5 SafeConfigParser: raised TypeError on set
    2.6.5 ConfigParser: old-style output

    2.7 RawConfigParser: new-style output
    2.7 SafeConfigParser: raised TypeError on set
    2.7 ConfigParser: new-style output

    3.1.1 RawConfigParser: old-style output
    3.1.1 SafeConfigParser: raised TypeError on set
    3.1.1 ConfigParser: old-style output

    3.2a1+ RawConfigParser: new-style output
    3.2a1+ SafeConfigParser: raised TypeError on set
    3.2a1+ ConfigParser: new-style output

Essentially: For the RawConfigParser and ConfigParser classes, the output changes in 2.7 and 3.2, and in a way that should be considered incorrect because it conflicts with the allow_no_values setting.

This is a bug and should be fixed in both 2.7 and 3.2.

The TypeError-on-set is consistently raised only for SafeConfigParser, and should remain unchanged.  (Why this was handled differently for SafeConfigParser I don't recall offhand.)

----------
Added file: http://bugs.python.org/file18717/cpsample.py

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

From report at bugs.python.org  Fri Sep  3 05:25:50 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Fri, 03 Sep 2010 03:25:50 +0000
Subject: [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283484350.26.0.371901300111.issue9739@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

According to PEP 7, the first line of the doc string should contain the signature of the function, then there should be a blank line, and then the rest of the doc string. There may be tools that extract the signature line. The patch just decreases the line length of the remaining lines of the doc string so they don't wrap when displayed on an 80 character wide terminal window.

For an example, look at the text for modf(...) in help(math).

I just noticed that the math module uses "modf(x)" for the signature line but PEP 7 recommends including the return type, say "modf(x) -> (frac, int)".

The simplest change would be to fix the wrapping issue and leave the signature line alone. It would be more effort to make all the doc strings PEP 7 compliant by standardizing the signature line to include the return type.

I'm willing to work through the standard library and create patches for either option.

----------

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

From report at bugs.python.org  Fri Sep  3 05:50:45 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 03 Sep 2010 03:50:45 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1283485845.9.0.964039477366.issue7005@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Attached fix & test for Python 2; adjusting to Python 3 is trivial.

The test could be added to 2.6 as well to protect against regressions there, though that's unlikely to be a significant issue.

----------
Added file: http://bugs.python.org/file18718/issue-7005.patch

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

From report at bugs.python.org  Fri Sep  3 06:24:04 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 03 Sep 2010 04:24:04 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1283487844.26.0.881611896212.issue7005@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Commited as r84443 (release27-maint), r84444 (py3k)

----------
status: open -> closed

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

From report at bugs.python.org  Fri Sep  3 06:39:17 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Sep 2010 04:39:17 +0000
Subject: [issue9749] tuple-to-list conversion
In-Reply-To: <1283482623.34.0.524181543079.issue9749@psf.upfronthosting.co.za>
Message-ID: <1283488757.84.0.785022265484.issue9749@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Sorry, this isn't a bug.  I think you've rediscovered a property of mutable objects.  See http://docs.python.org/tutorial/controlflow.html#default-argument-values for an example.

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Sep  3 06:46:08 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 03 Sep 2010 04:46:08 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1283489168.13.0.986759877687.issue2986@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a patch (developed jointly with Terry Reedy) for 2.7 that adds an 'autojunk' parameter to SequenceMatcher's constructor. The parameter is True by default which retains the current behavior in 2.6 and earlier, but can be set by the user to False to disable the popularity heuristic. The patch also fixes some documentation inconsistencies that Terry raised in this message.

Notes:
1. Tests run successfully. Added new test class in test_difflib for testing with the new autojunk parameter False
2. Patch generated vs. Hg mirror

----------
Added file: http://bugs.python.org/file18719/issue2986.fix27.4.patch

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

From report at bugs.python.org  Fri Sep  3 08:15:26 2010
From: report at bugs.python.org (Marko Kohtala)
Date: Fri, 03 Sep 2010 06:15:26 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>


New submission from Marko Kohtala <marko.kohtala at gmail.com>:

Sqlite3 fails to dump a database with column names that are keywords.

----------
components: Extension Modules
files: sqlite3bug.py
messages: 115420
nosy: Marko.Kohtala
priority: normal
severity: normal
status: open
title: sqlite3 iterdump fails on column with reserved name
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18720/sqlite3bug.py

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

From report at bugs.python.org  Fri Sep  3 08:17:37 2010
From: report at bugs.python.org (Marko Kohtala)
Date: Fri, 03 Sep 2010 06:17:37 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1283494657.07.0.112904125164.issue9750@psf.upfronthosting.co.za>


Marko Kohtala <marko.kohtala at gmail.com> added the comment:

Here is a patch that may resolve the bug.

----------
keywords: +patch
Added file: http://bugs.python.org/file18721/sqlite3bug.patch

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

From report at bugs.python.org  Fri Sep  3 09:15:13 2010
From: report at bugs.python.org (=?utf-8?b?UHlyeSBTw6RpbMOk?=)
Date: Fri, 03 Sep 2010 07:15:13 +0000
Subject: [issue9749] tuple-to-list conversion
In-Reply-To: <1283482623.34.0.524181543079.issue9749@psf.upfronthosting.co.za>
Message-ID: <1283498113.15.0.79554572636.issue9749@psf.upfronthosting.co.za>


Pyry S?il? <roadrunnahz at gmail.com> added the comment:

Ah, I see. What a stupid error. My apologies.

----------

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

From report at bugs.python.org  Fri Sep  3 10:12:11 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Sep 2010 08:12:11 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1283501531.71.0.17723863775.issue9750@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ghaering
versions: +Python 3.2

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

From report at bugs.python.org  Fri Sep  3 10:16:57 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 03 Sep 2010 08:16:57 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1283501817.54.0.995131612967.issue9750@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
assignee:  -> ghaering

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

From report at bugs.python.org  Fri Sep  3 10:17:42 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 03 Sep 2010 08:17:42 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1283501862.74.0.868467479935.issue4111@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
nosy: +techtonik

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

From report at bugs.python.org  Fri Sep  3 10:35:01 2010
From: report at bugs.python.org (Marko Kohtala)
Date: Fri, 03 Sep 2010 08:35:01 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1283502901.87.0.766371901288.issue9750@psf.upfronthosting.co.za>


Marko Kohtala <marko.kohtala at gmail.com> added the comment:

The second patch contains also fixes for some places where the rules described in http://www.sqlite.org/lang_keywords.html are not followed.

----------
Added file: http://bugs.python.org/file18722/sqlite3ident.patch

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

From report at bugs.python.org  Fri Sep  3 11:10:04 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 03 Sep 2010 09:10:04 +0000
Subject: [issue7077] SysLogHandler can't handle Unicode
In-Reply-To: <1254919358.82.0.721761611674.issue7077@psf.upfronthosting.co.za>
Message-ID: <1283505004.82.0.361137236033.issue7077@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix backported to release27-maint (r84445).

Python 2.6 and earlier are in security-fix-only mode.

----------

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

From report at bugs.python.org  Fri Sep  3 11:14:05 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 03 Sep 2010 09:14:05 +0000
Subject: [issue9576] logging.addLevelName in file-based configurations
In-Reply-To: <1281627893.73.0.657800338781.issue9576@psf.upfronthosting.co.za>
Message-ID: <1283505245.88.0.508586450916.issue9576@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

No feedback on this after two weeks, so closing.

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

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

From report at bugs.python.org  Fri Sep  3 11:30:12 2010
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 03 Sep 2010 09:30:12 +0000
Subject: [issue9751] _PyInstance_Lookup() defeats its purpose
In-Reply-To: <1283506212.5.0.831864167364.issue9751@psf.upfronthosting.co.za>
Message-ID: <1283506212.5.0.831864167364.issue9751@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

_PyInstance_Lookup() is documented as follows:

    The point of this routine is that it never calls arbitrary Python
    code, so is always "safe":  all it does is dict lookups.

But of course dict lookups can call arbitrary Python code.  This function has no purpose, because it's not possible to be "safe".  I checked in a crasher:

http://svn.python.org/projects/python/branches/release27-maint/Lib/test/crashers/gc_has_finalizer.py

----------
components: Interpreter Core
messages: 115426
nosy: arigo
priority: low
severity: normal
stage: needs patch
status: open
title: _PyInstance_Lookup() defeats its purpose
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  3 11:32:43 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 03 Sep 2010 09:32:43 +0000
Subject: [issue9576] logging.addLevelName in file-based configurations
In-Reply-To: <1281627893.73.0.657800338781.issue9576@psf.upfronthosting.co.za>
Message-ID: <1283506363.0.0.606345517536.issue9576@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

You set it to "won't fix", that's why I didn't give you any feedback.

In general, if you provides features programatically *and* via configuration, it makes sense to provide the whole set on both sides.

IOW, if you don't want a feature to be used by third-party apps, it should not be exposed at all.

----------

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

From report at bugs.python.org  Fri Sep  3 11:42:33 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 09:42:33 +0000
Subject: [issue9752] MSVC Compiler warning in Python\import.c
In-Reply-To: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>
Message-ID: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

7>..\Python\import.c(1158) : warning C4013: 'mkdir' undefined; assuming extern returning int

----------
assignee: stutzbach
components: Interpreter Core, Windows
keywords: easy
messages: 115428
nosy: stutzbach
priority: low
severity: normal
stage: needs patch
status: open
title: MSVC Compiler warning in Python\import.c
versions: Python 3.2

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

From report at bugs.python.org  Fri Sep  3 11:48:08 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 03 Sep 2010 09:48:08 +0000
Subject: [issue9726] logging.handlers.RotatingFileHandler: implement "preserve
	log file name extension" feature
In-Reply-To: <1283281887.54.0.818676292303.issue9726@psf.upfronthosting.co.za>
Message-ID: <1283507288.88.0.212063372176.issue9726@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

You can do this by subclassing RotatingFileHandler and overriding doRollover, as per this example:

http://plumberjack.blogspot.com/2010/09/using-custom-file-naming-scheme-for.html

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

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

From report at bugs.python.org  Fri Sep  3 12:07:42 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Sep 2010 10:07:42 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1283508462.78.0.131793903041.issue8420@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r84447

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

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

From report at bugs.python.org  Fri Sep  3 12:10:07 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 03 Sep 2010 10:10:07 +0000
Subject: [issue9576] logging.addLevelName in file-based configurations
In-Reply-To: <1281627893.73.0.657800338781.issue9576@psf.upfronthosting.co.za>
Message-ID: <1283508607.12.0.667987504071.issue9576@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I set to "pending" and "wontfix" to indicate what my proposed resolution was, and to await feedback - sorry for the misunderstanding.

The custom levels feature is not intended to be used casually (as it will cause unpredictable behaviour when used differently in different third-party libraries), but there are less common application-level scenarios (where logging interoperability is less of an issue) where custom levels might be needed - which is why they are provided.

It seems acceptable to me to have different conventions for third-party code and application code. For example, NullHandler is recommended for use with third-party libraries but is not especially useful for applications.

Configuration is not intended to *completely* cover the programmatic API - just to make it easier to do the most commonly-required things.

----------

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

From report at bugs.python.org  Fri Sep  3 12:16:06 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 10:16:06 +0000
Subject: [issue9753] test_socket.testDup, testFromFd fail on Windows
In-Reply-To: <1283508966.85.0.609620029281.issue9753@psf.upfronthosting.co.za>
Message-ID: <1283508966.85.0.609620029281.issue9753@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The errors below show up on my XP machine in Python 3.1 as well as a recent build from the py3k branch.  I'm not sure why they *don't* show up on the XP buildbot.

fromfd() ultimately calls dup(), so the underlying problem is likely the same for all the failures.  dup() support was added for Windows in issue1378.

======================================================================
ERROR: testDup (test.test_socket.BasicTCPTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python31\lib\test\test_socket.py", line 628, in testDup
    msg = sock.recv(1024)
socket.error: [Errno 10038] An operation was attempted on something that is not a socket

======================================================================
ERROR: testFromFd (test.test_socket.BasicTCPTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python31\lib\test\test_socket.py", line 619, in testFromFd
    msg = sock.recv(1024)
socket.error: [Errno 10038] An operation was attempted on something that is not a socket

======================================================================
ERROR: testDup (test.test_socket.BasicTCPTest2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python31\lib\test\test_socket.py", line 628, in testDup
    msg = sock.recv(1024)
socket.error: [Errno 10045] The attempted operation is not supported for the type of object referenced

======================================================================
ERROR: testFromFd (test.test_socket.BasicTCPTest2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python31\lib\test\test_socket.py", line 619, in testFromFd
    msg = sock.recv(1024)
socket.error: [Errno 10038] An operation was attempted on something that is not a socket

----------------------------------------------------------------------

----------
components: Library (Lib), Windows
messages: 115432
nosy: brian.curtin, christian.heimes, roudkerk, stutzbach, tim.golden
priority: normal
severity: normal
status: open
title: test_socket.testDup, testFromFd fail on Windows
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Sep  3 12:23:00 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 03 Sep 2010 10:23:00 +0000
Subject: [issue9744] calling __getattribute__ with wrong instance causes hang
	up
In-Reply-To: <1283438884.05.0.113900555872.issue9744@psf.upfronthosting.co.za>
Message-ID: <1283509380.69.0.483297269868.issue9744@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Actually, Python behaves the way you expect it. The problem is that when that exception is created, Python tries to look up the involved class names. To do that, it tries to get the "__class__" attribute (hapens in `getinstclassname()`, which will call again into A's `__getattibute__`, which will raise again, and for that new exception, "__class__" will be looked up, which will call into `__getattribute__` again, which will raise again and that goes on and on until finally the recursion limit is hit and a recursion error is raised. That recursion error will be discarded by `getinstclassname()`. Hence it's not really a hangup, it just takes a lot of time due to the recursive calls. Try your example with a recursion limit set to a really small value to see the expected behaviour.

----------
nosy: +Trundle

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

From report at bugs.python.org  Fri Sep  3 12:50:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 10:50:17 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Similar to assertRaises and assertRaisesRegexp, unittest should provide assertWarns and assertWarnsRegexp, to check that a given callable (or piece of code) triggers a particular warning.

Currently, you have to do that manually using a mixture of warnings.catch_warnings and warnings.filterwarnings, which is pretty annoying.

----------
components: Library (Lib)
messages: 115434
nosy: brett.cannon, michael.foord, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: assertWarns and assertWarnsRegexp
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Sep  3 12:52:20 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Sep 2010 10:52:20 +0000
Subject: [issue8649] Py_UNICODE_* functions are undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1283511140.18.0.429977986765.issue8649@psf.upfronthosting.co.za>


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

For this one, I suggest adding something to http://docs.python.org/dev/c-api/unicode.html#plain-py-unicode

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

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

From report at bugs.python.org  Fri Sep  3 13:04:17 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 03 Sep 2010 11:04:17 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283511857.51.0.667851951224.issue9754@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

+1

----------

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

From report at bugs.python.org  Fri Sep  3 13:05:25 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 11:05:25 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1283511925.66.0.0891042754262.issue8654@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I just noticed that the previous "new" patch I uploaded was actually my original patch.  Oops.  Anyway...

In a discussion on the capi list, a few people objected to compiling in Unicode-agnostic mode by default (e.g., it would be annoying for Cython).  Attached is a new patch that compiles in Unicode-agnostic mode only when Py_UNICODE_AGNOSTIC is defined (and brings the patch up to date with other changes to the py3k branch).

It includes automated tests, and I have tested UCS2 Linux, UCS4 Linux, and Windows builds.

After the patch, trying to import a module with a mismatched Unicode setting looks like this:

>>> import _testunicodemismatched
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: module's Unicode representation does not match the interpreter's

Here's a birds-eye view of the patch:

moduleobject.h: Add a flags field to PyModuleDef_Base
moduleobject.c: Detect import with mismatched Unicode setting
pyunicode.h: New file; non-agnostic code from unicodeobject.h moved here
unicodeobject.h: Deleted ~150 lines of #defines (yay!)
Everything else: tests

I'm pretty happy with the patch.  In the earlier discussion here, there was generally positive feedback for the overall idea.  Someone want to do a patch review?

----------
keywords: +needs review
stage: needs patch -> patch review
Added file: http://bugs.python.org/file18723/unicode-2.patch

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

From report at bugs.python.org  Fri Sep  3 13:15:10 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Sep 2010 11:15:10 +0000
Subject: [issue9753] test_socket.testDup, testFromFd fail on Windows
In-Reply-To: <1283508966.85.0.609620029281.issue9753@psf.upfronthosting.co.za>
Message-ID: <1283512510.32.0.737339375208.issue9753@psf.upfronthosting.co.za>


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

test_socket.py passes here.
I run: python_d.exe -m test.regrtest -v test_socket

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

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

From report at bugs.python.org  Fri Sep  3 13:16:34 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 11:16:34 +0000
Subject: [issue9753] test_socket.testDup, testFromFd fail on Windows
In-Reply-To: <1283508966.85.0.609620029281.issue9753@psf.upfronthosting.co.za>
Message-ID: <1283512594.22.0.816420497296.issue9753@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I run it the same way.

I wonder what's different? :-(  I will try to find some time to investigate further.

----------

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

From report at bugs.python.org  Fri Sep  3 13:25:24 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 11:25:24 +0000
Subject: [issue9753] test_socket.testDup, testFromFd fail on Windows
In-Reply-To: <1283508966.85.0.609620029281.issue9753@psf.upfronthosting.co.za>
Message-ID: <1283513124.86.0.726815535299.issue9753@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Windows, socket.dup is implemented using DuplicateHandle.  The documentation for DuplicateHandle reads:

You should not use DuplicateHandle to duplicate handles to the following objects:

    * I/O completion ports. No error is returned, but the duplicate handle cannot be used.
    * Sockets. No error is returned, but the duplicate handle may not be recognized by Winsock at the target process. Also, using DuplicateHandle interferes with internal reference counting on the underlying object. To duplicate a socket handle, use the WSADuplicateSocket function.

----------

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

From report at bugs.python.org  Fri Sep  3 13:32:33 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 03 Sep 2010 11:32:33 +0000
Subject: [issue9744] calling __getattribute__ with wrong instance causes hang
	up
In-Reply-To: <1283438884.05.0.113900555872.issue9744@psf.upfronthosting.co.za>
Message-ID: <1283513553.37.0.0853317623956.issue9744@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


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

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

From report at bugs.python.org  Fri Sep  3 13:43:44 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Sep 2010 11:43:44 +0000
Subject: [issue9755] Fix refcounting details in Py3k C API documentation
In-Reply-To: <1283514224.53.0.325600320074.issue9755@psf.upfronthosting.co.za>
Message-ID: <1283514224.53.0.325600320074.issue9755@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As noted in [1] the refcount data for the C API documentation is contained in a separate file at Doc/data/refcounts.dat.

This file is not mentioned in "Documenting Python" and hence has not been correctly updated for Py3k (e.g. none of the PyString methods have been renamed to PyUnicode in that file, so the relevant refcount changes are not documented correctly).

There are several possible improvements to be considered in this area
1. Mention this file and its purpose in "Documenting Python"
2. Update the Sphinx extension to warn if a C API function is not found in this file
3. Update the Sphinx extension to allow this information to be expressed inline in the function definition rather than off in a separate file (if practical)
4. Address Skip's comment from that file by allowing "-0" to indicate stolen references for arguments and "+0" for borrowed references as return values
5. Perhaps add a mechanism to indicate when PyMem_Free needs to be called on a return value or pointer output value.

[1] http://mail.python.org/pipermail/python-dev/2010-September/103429.html

----------
messages: 115441
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Fix refcounting details in Py3k C API documentation

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

From report at bugs.python.org  Fri Sep  3 13:44:30 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Sep 2010 11:44:30 +0000
Subject: [issue9755] Fix refcounting details in Py3k C API documentation
In-Reply-To: <1283514224.53.0.325600320074.issue9755@psf.upfronthosting.co.za>
Message-ID: <1283514270.94.0.474613121645.issue9755@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> docs at python
nosy: +docs at python

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

From report at bugs.python.org  Fri Sep  3 13:51:20 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 11:51:20 +0000
Subject: [issue9753] test_socket.testDup, testFromFd fail on Windows
In-Reply-To: <1283508966.85.0.609620029281.issue9753@psf.upfronthosting.co.za>
Message-ID: <1283514680.35.0.378654549426.issue9753@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Following the advice of DuplicateHandle's documentation, I reimplemented dup on Windows using WSADuplicateHandle.  Attached is a patch.  With the patch, the tests pass on my Windows machine.

Would someone like to review the patch?

----------
assignee:  -> stutzbach
keywords: +needs review, patch
resolution:  -> accepted
stage:  -> patch review

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

From report at bugs.python.org  Fri Sep  3 13:51:49 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 11:51:49 +0000
Subject: [issue9753] test_socket.testDup, testFromFd fail on Windows
In-Reply-To: <1283508966.85.0.609620029281.issue9753@psf.upfronthosting.co.za>
Message-ID: <1283514709.58.0.898948699942.issue9753@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Added file: http://bugs.python.org/file18724/issue9753.patch

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

From report at bugs.python.org  Fri Sep  3 14:05:27 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Sep 2010 12:05:27 +0000
Subject: [issue9753] test_socket.testDup, testFromFd fail on Windows
In-Reply-To: <1283508966.85.0.609620029281.issue9753@psf.upfronthosting.co.za>
Message-ID: <1283515527.35.0.827566371835.issue9753@psf.upfronthosting.co.za>


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

The documentation of WSASocket(), and the code of PyBluez
http://code.google.com/p/pybluez/source/browse/trunk/msbt/_msbt.c#374
both suggest to use the FROM_PROTOCOL_INFO constant.
Otherwise, the patch looks good.

----------

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

From report at bugs.python.org  Fri Sep  3 14:08:18 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 12:08:18 +0000
Subject: [issue9751] _PyInstance_Lookup() defeats its purpose
In-Reply-To: <1283506212.5.0.831864167364.issue9751@psf.upfronthosting.co.za>
Message-ID: <1283515698.51.0.0787734144542.issue9751@psf.upfronthosting.co.za>


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

I'm not sure anyone will be interested in this: it doesn't affect 3.x.

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

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

From report at bugs.python.org  Fri Sep  3 14:09:11 2010
From: report at bugs.python.org (Marko Kohtala)
Date: Fri, 03 Sep 2010 12:09:11 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1283515751.22.0.780132230696.issue9750@psf.upfronthosting.co.za>


Marko Kohtala <marko.kohtala at gmail.com> added the comment:

It also fails if table or column names contain double quote.

----------
Added file: http://bugs.python.org/file18725/sqlite3bug2.py

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

From report at bugs.python.org  Fri Sep  3 14:13:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 03 Sep 2010 12:13:04 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

I found this crash while playing with proxies (thanks haypo).
http://code.activestate.com/recipes/496741-object-proxying/


class MyClass(object):

    def __init__(self):
        self.pwn = None

    def __getattribute__(self, name):
        print('MyClass.__getattribute__(self, %r)' % name)
        return getattr('abc', name)

instance = MyClass()
str.strip(instance)

----------
components: Interpreter Core
messages: 115446
nosy: flox, haypo
priority: normal
severity: normal
stage: needs patch
status: open
title: Crash with custom __getattribute__
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Sep  3 14:18:31 2010
From: report at bugs.python.org (Marko Kohtala)
Date: Fri, 03 Sep 2010 12:18:31 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1283516311.14.0.993525960436.issue9750@psf.upfronthosting.co.za>


Changes by Marko Kohtala <marko.kohtala at gmail.com>:


Added file: http://bugs.python.org/file18726/sqlite3dump.patch

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

From report at bugs.python.org  Fri Sep  3 14:33:16 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 03 Sep 2010 12:33:16 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1283517196.84.0.572893097492.issue9756@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

It's because you can fool `PyObject_IsInstance()` that way:

>>> class Spam(object):
...     def __getattribute__(self, name):
...         if name == '__class__':
...             return str
...         raise AttributeError
... 
>>> isinstance(Spam(), str)
True

----------
nosy: +Trundle

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

From report at bugs.python.org  Fri Sep  3 14:43:07 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 12:43:07 +0000
Subject: [issue9753] test_socket.testDup, testFromFd fail on Windows
In-Reply-To: <1283508966.85.0.609620029281.issue9753@psf.upfronthosting.co.za>
Message-ID: <1283517787.2.0.980199887305.issue9753@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Thanks!  Updated as you suggested and committed as r84450 and r84451.

----------
keywords:  -needs review
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Sep  3 14:44:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 12:44:56 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283517896.15.0.369993773524.issue9754@psf.upfronthosting.co.za>


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

The __warningregistry__ stuff looks horrible.

----------

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

From report at bugs.python.org  Fri Sep  3 14:51:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 03 Sep 2010 12:51:07 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283518267.02.0.345493083323.issue9754@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> unittest should provide assertWarns and assertWarnsRegexp

+1
(the internal helpers in test.support could be refactored)

> The __warningregistry__ stuff looks horrible.

+1
(and it does not behave exactly the same in all Python versions)

----------
nosy: +flox

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

From report at bugs.python.org  Fri Sep  3 14:55:20 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 03 Sep 2010 12:55:20 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283518520.38.0.553902402825.issue9754@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

+1 from me as well.

----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Fri Sep  3 15:46:42 2010
From: report at bugs.python.org (Nick Dowell)
Date: Fri, 03 Sep 2010 13:46:42 +0000
Subject: [issue8746] *chflags detection broken on FreeBSD 9-CURRENT
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1283521602.83.0.771354916039.issue8746@psf.upfronthosting.co.za>


Nick Dowell <nickdowell at gmail.com> added the comment:

We've just noticed this same problem with Python 3.1.2 on Mac OS X.

The problem is that the program source in the configure script has extraneous '[' and ']' characters in it, causing compilation to fail.
Excerpt of configure from line 17357:
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  [
  #include <sys/stat.h>
  #include <unistd.h>
  int main(int argc, char*argv[])
  {
    if(chflags(argv[0], 0) != 0)
      return 1;
    return 0;
  }
  ]
  _ACEOF

These extra '[' and ']' characters were added to configure.in in revision 74038:
http://svn.python.org/view/python/trunk/configure.in?r1=74033&r2=74038

I have locally modified my configure.in and configure scripts to back out that change, and found it resolves the issue.

----------
nosy: +Nick.Dowell

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

From report at bugs.python.org  Fri Sep  3 15:59:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 13:59:47 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283522387.45.0.384025792036.issue9754@psf.upfronthosting.co.za>


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

Here is a patch. The approach is different from support.check_warnings(), and tries to mimic assertRaises* instead.

----------
keywords: +patch
Added file: http://bugs.python.org/file18727/assertwarns.patch

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

From report at bugs.python.org  Fri Sep  3 16:02:40 2010
From: report at bugs.python.org (Douglas Leeder)
Date: Fri, 03 Sep 2010 14:02:40 +0000
Subject: [issue8746] *chflags detection broken on FreeBSD 9-CURRENT
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1283522560.62.0.441889669167.issue8746@psf.upfronthosting.co.za>


Changes by Douglas Leeder <douglas.leeder at gmail.com>:


----------
nosy: +Douglas.Leeder

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

From report at bugs.python.org  Fri Sep  3 16:07:59 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 03 Sep 2010 14:07:59 +0000
Subject: [issue7231] Windows installer does not add \Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1283522879.98.0.908038872251.issue7231@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The big problem with adding the %python%\scripts directory to the path is it makes a lot of assumptions about how Python is deployed.

And it raises some questions. What should the precedence be? What should happen if multiple versions of Python are installed? Should the latest version take precedence? Should the latest version remove the path for the previous version?

Personally, I'm -1 on this idea unless it's a checkbox that can easily be deselected (or not selected by default). I install multiple different versions of Python to my system and I symlink \Python to the "active" version and I add "\Python\Scripts" to the path, so I can easily switch between my active version of Python. Adding \Python26\Scripts and \Python26-64\Scripts and \Python27\Scripts and ... to the path could become very messy.

Perhaps a better solution would be to provide a link in the start menu or a script to be run which adds the scripts to the path for that instance of Python... so it could be easily and painlessly added after the fact.

----------
nosy: +jaraco

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

From report at bugs.python.org  Fri Sep  3 16:13:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 14:13:09 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283523189.81.0.223571315593.issue9754@psf.upfronthosting.co.za>


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

There was some dead code in the patch.

----------
Added file: http://bugs.python.org/file18728/assertwarns.patch

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

From report at bugs.python.org  Fri Sep  3 16:13:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 14:13:13 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283523193.84.0.43752794973.issue9754@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18727/assertwarns.patch

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

From report at bugs.python.org  Fri Sep  3 16:38:25 2010
From: report at bugs.python.org (sorin)
Date: Fri, 03 Sep 2010 14:38:25 +0000
Subject: [issue7231] Windows installer does not add \Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1283524705.56.0.447696322975.issue7231@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

Important tools (like ease_install, pypm) from `Script` directory are already including version prefixes in their names (tool-2.7.exe).

This means that it should not be a big problem having several Scripts directories on your path.

Most python users are not installing several versions, but we could expect that most of them will want to run a tool from scripts.

----------

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

From report at bugs.python.org  Fri Sep  3 16:57:22 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 03 Sep 2010 14:57:22 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1283525842.42.0.911790593025.issue8654@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Fri Sep  3 16:58:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Sep 2010 14:58:38 +0000
Subject: [issue7231] Windows installer does not add \Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1283525918.33.0.0461255419059.issue7231@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

> Important tools (like ease_install, pypm) from `Script` directory are
> already including version prefixes in their names (tool-2.7.exe).
> 
> This means that it should not be a big problem having several Scripts
> directories on your path.

Just adding all Script directories to the path would penalize those projects who don't add versions to their file names. We should not do that.

If we're going to add any type of path manipulation, it should have the options to replace existing paths, append existing paths, or do nothing.


> Most python users are not installing several versions, but we could
> expect that most of them will want to run a tool from scripts.

Neither of these are true from my experience. Since 3.0 came out, I have always had a 2.x and 3.x installed concurrently, and come across many coworkers who have numerous versions installed. As for most people using something in Scripts, I've rarely interacted with anyone who uses it or knows about it besides myself.

----------
nosy: +brian.curtin
stage:  -> needs patch
versions:  -Python 3.3

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

From report at bugs.python.org  Fri Sep  3 16:59:49 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Sep 2010 14:59:49 +0000
Subject: [issue7231] Windows installer does not add \Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1283525989.93.0.304094457742.issue7231@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

s/append existing paths/append new paths/

----------

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

From report at bugs.python.org  Fri Sep  3 17:11:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 15:11:04 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283526664.21.0.538599282287.issue9757@psf.upfronthosting.co.za>
Message-ID: <1283526664.21.0.538599282287.issue9757@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This adds the context manager protocol to memoryview objects, as proposed on python-dev. Once the `with` block has finished, the underlying buffer is released and any operation on the memoryview raises a ValueError.

----------
components: Interpreter Core
files: memcontext.patch
keywords: patch
messages: 115459
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Add context manager protocol to memoryviews
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18729/memcontext.patch

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

From report at bugs.python.org  Fri Sep  3 17:19:43 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 03 Sep 2010 15:19:43 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283527183.68.0.667799885654.issue9754@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

(Note that in general I am against extending the TestCase API with more asserts given how wide it is and how much it has expanded in recent versions. I've written warning checking code enough times for third party projects that I think this is worth it though.)

----------

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

From report at bugs.python.org  Fri Sep  3 17:38:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 15:38:46 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1283528326.42.0.201845886794.issue8654@psf.upfronthosting.co.za>


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

+#undef HAVE_USABLE_CHAR_T

Isn't it HAVE_USABLE_WCHAR_T?

+struct PY_UNICODE_STRUCT;
+typedef struct PY_UNICODE_STRUCT Py_UNICODE_STRUCT;
+#define Py_UNICODE Py_UNICODE_STRUCT

Why not simply `typedef struct PY_UNICODE_STRUCT Py_UNICODE`?

The _testunicodeagnostic module could have a simple test method making a couple of calls to PyUnicode_* functions.

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

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

From report at bugs.python.org  Fri Sep  3 18:12:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 16:12:57 +0000
Subject: [issue9727] Add callbacks to be invoked when locale changes
In-Reply-To: <1283293758.47.0.775705269917.issue9727@psf.upfronthosting.co.za>
Message-ID: <1283530377.31.0.738983633961.issue9727@psf.upfronthosting.co.za>


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


----------
nosy: +lemburg, loewis

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

From report at bugs.python.org  Fri Sep  3 18:27:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 16:27:34 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1283531254.38.0.207301369427.issue1521950@psf.upfronthosting.co.za>


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

Thanks for the report. Would you like to work on a patch, or translate your examples into unit tests?

The docs do not mention ?&? at all, and platform discrepancies have to be taken into account too, so I really don?t know if this is a bug fix for the normal mode, the POSIX mode, or a feature request requiring a new argument to the shlex function to preserve compatibility.

----------
nosy: +eric.araujo, eric.smith

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

From report at bugs.python.org  Fri Sep  3 18:33:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 16:33:05 +0000
Subject: [issue9723] pipes.quote() needs to be documented
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1283531585.36.0.886282994674.issue9723@psf.upfronthosting.co.za>


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

Eric referred to this thread: http://mail.python.org/pipermail/stdlib-sig/2010-May/thread.html

----------
nosy: +eric.araujo
versions:  -Python 2.5, Python 2.6, Python 3.3

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

From report at bugs.python.org  Fri Sep  3 18:44:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 16:44:53 +0000
Subject: [issue9721] urlparse.urljoin() cuts off last base character with
	semicolon at url start
In-Reply-To: <1283232058.13.0.308353601536.issue9721@psf.upfronthosting.co.za>
Message-ID: <1283532293.24.0.402284433582.issue9721@psf.upfronthosting.co.za>


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

The versions getting bug fixes are 2.7, 3.1 (stable versions) and 3.2 (active). 2.6 is in security mode now.

Can someone write a test (as a standalone script or a diff against Lib/test/test_urlparse.py) and tell if 3.1 and 3.2 have the bug too?

More importantly, can someone quote the latest URI RFC about that? The semicolon is related to the mysterious param component IIRC.

----------
nosy: +eric.araujo
versions:  -Python 2.6

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

From report at bugs.python.org  Fri Sep  3 18:45:58 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 03 Sep 2010 16:45:58 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283532358.91.0.652365975312.issue9754@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Patch looks good. However tests do not pass with -Werror (while test_warnings and others pass).


Is there a way to catch multiple warnings on a single logical line?
(With assertRaises we don't have such use case)

----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Sep  3 18:53:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 16:53:48 +0000
Subject: [issue9720] zipfile writes incorrect local file header for large
	files in zip64
In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za>
Message-ID: <1283532828.41.0.772085693042.issue9720@psf.upfronthosting.co.za>


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

A tip about versions: Development happens on the current active branch, py3k (future 3.2 version), and bug or doc fixes are backported to the stable versions 2.7 and 3.1. Security fixes go into 2.6 too.

Can you reproduce your bug in 2.7, 3.1 and 3.2?

Adding Alan to nosy since he?s listed in Misc/maintainers.rst.

----------
nosy: +alanmcintyre, eric.araujo
versions:  -Python 2.5, Python 2.6, Python 3.3

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

From report at bugs.python.org  Fri Sep  3 18:54:12 2010
From: report at bugs.python.org (Grzegorz Kulewski)
Date: Fri, 03 Sep 2010 16:54:12 +0000
Subject: [issue9758] ioctl mutable buffer copying problem
In-Reply-To: <1283532852.64.0.959169848478.issue9758@psf.upfronthosting.co.za>
Message-ID: <1283532852.64.0.959169848478.issue9758@psf.upfronthosting.co.za>


New submission from Grzegorz Kulewski <grzegorz at kulewski.pl>:

Hello,

It looks like something is broken in ioctl in 3.2 when the supplied (mutable) bytearray is exactly 1024 bytes long - the result is not copied into the buffer after the ioctl succedes:

def open_tuntap(type, name):
        TUN_TYPE = {
                'TUN' : 0x0001,
                'TAP' : 0x0002
        }

        TUNSETIFF = 0x400454ca

        dev = os.open('/dev/net/tun', os.O_RDWR)
        buf = bytearray(SET_LEN_HERE)
        name = name[:16]
        buf[:len(name)] = name
        buf[16:18] = TUN_TYPE[type].to_bytes(2, sys.byteorder)
        fcntl.ioctl(dev, TUNSETIFF, buf, True)
        print(buf)
        print(len(buf))

open_tuntap('TAP', b'madtun%d')

Now try it with SET_LEN_HERE = 1024, 1023, 1025 and any other values. For < 1024 it copies to the static buffer and back, for > 1024 it operates on the buffer itself (hopefully) and for 1024 it ignores the modified buffer completely. It's probably some corner case bug.

The example was tested under Linux 2.6.35.

Python 3.2a1+ (py3k:84054, Sep  3 2010, 01:45:35) 
[GCC 4.4.2] on linux2

----------
components: Library (Lib)
messages: 115467
nosy: gkulewski
priority: normal
severity: normal
status: open
title: ioctl mutable buffer copying problem
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Sep  3 18:56:22 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 03 Sep 2010 16:56:22 +0000
Subject: [issue9710] 2to3 could remove "-*- coding: utf-8 -*-"
In-Reply-To: <1283111290.18.0.408621476951.issue9710@psf.upfronthosting.co.za>
Message-ID: <1283532982.68.0.934290558816.issue9710@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

PEP8 fixed with r84354

----------

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

From report at bugs.python.org  Fri Sep  3 19:00:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 03 Sep 2010 17:00:04 +0000
Subject: [issue9708] cElementTree iterparse does not support "parser" argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <1283533204.25.0.893797744462.issue9708@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +effbot
stage:  -> unit test needed
type:  -> behavior
versions: +Python 3.2

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

From report at bugs.python.org  Fri Sep  3 19:05:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 17:05:05 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283532358.91.0.652365975312.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283533501.3223.1.camel@localhost.localdomain>


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

> Patch looks good. However tests do not pass with -Werror (while test_warnings and others pass).
> 
> 
> Is there a way to catch multiple warnings on a single logical line?

I thought we could beef up the API with additional arguments.
That would be at the expense of removing the "callable" argument (and
mandating the use as a context manager), though, otherwise the signature
gets too complicated.

----------

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

From report at bugs.python.org  Fri Sep  3 19:08:37 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 03 Sep 2010 17:08:37 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283533717.01.0.456323752029.issue9754@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Why not accepting a tuple of warnings? That doesn't make sense for assertWarnsRegexp of course.

----------

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

From report at bugs.python.org  Fri Sep  3 19:13:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 17:13:01 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283533717.01.0.456323752029.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283533975.3223.2.camel@localhost.localdomain>


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

> Why not accepting a tuple of warnings?

It already does (and there's a test!).

> That doesn't make sense for assertWarnsRegexp of course.

True.

----------

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

From report at bugs.python.org  Fri Sep  3 19:20:59 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 03 Sep 2010 17:20:59 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1283534459.96.0.378378118986.issue9756@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

At least two tests in `test.test_descr` consider that behaviour as a feature: "test_isinst_isclass" and "test_proxy_super".

----------

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

From report at bugs.python.org  Fri Sep  3 19:36:31 2010
From: report at bugs.python.org (Alain Kalker)
Date: Fri, 03 Sep 2010 17:36:31 +0000
Subject: [issue9759] GzipFile object should raise ValueError on .read() after
	.close()
In-Reply-To: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>
Message-ID: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>


New submission from Alain Kalker <miki at dds.nl>:

>>> f = open("test2.gz")
>>> d = f.read()
>>> f.close()
>>> e = f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file
import gzip
>>> f = gzip.open("test2.gz")
>>> d = f.read()
>>> f.close()
>>> e = f.read()
>>> e
''

To remain consistent with other file(-like) objects, I think 'GzipFile's should also raise a ValueError in cases like this.

----------
components: Library (Lib)
messages: 115473
nosy: ack
priority: normal
severity: normal
status: open
title: GzipFile object should raise ValueError on .read() after .close()
type: behavior

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

From report at bugs.python.org  Fri Sep  3 19:36:50 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 17:36:50 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1283535410.12.0.41644247293.issue8654@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Thanks, Antoine.  Those are all good suggestions.  Attached is an updated patch.

Marc-Andre, Martin: would you like to look this over as well?

----------
Added file: http://bugs.python.org/file18730/unicode-3.patch

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

From report at bugs.python.org  Fri Sep  3 19:40:01 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 03 Sep 2010 17:40:01 +0000
Subject: [issue9755] Fix refcounting details in Py3k C API documentation
In-Reply-To: <1283514224.53.0.325600320074.issue9755@psf.upfronthosting.co.za>
Message-ID: <1283535601.01.0.434295192387.issue9755@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I thought Fred Drake wrote the code that generated that file, but that
was a long time ago in a galaxy far, far away.  Perhaps Georg has
subsumed it into his Sphinx/Python doc workflow?

(making Fred "nosy" so he sees this thread...)

S

----------
nosy: +fdrake, skip.montanaro

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

From report at bugs.python.org  Fri Sep  3 19:49:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 17:49:15 +0000
Subject: [issue5506] io.BytesIO doesn't support the buffer protocol
In-Reply-To: <1237372813.02.0.863937398422.issue5506@psf.upfronthosting.co.za>
Message-ID: <1283536155.19.0.116214924862.issue5506@psf.upfronthosting.co.za>


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

Here is a patch implementing getbuffer(), together with tests.

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

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

From report at bugs.python.org  Fri Sep  3 19:49:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 17:49:47 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283526664.21.0.538599282287.issue9757@psf.upfronthosting.co.za>
Message-ID: <1283536187.81.0.119225964765.issue9757@psf.upfronthosting.co.za>


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

Guido expressed skepticism at the idea:
http://mail.python.org/pipermail/python-dev/2010-September/103442.html

----------

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

From report at bugs.python.org  Fri Sep  3 19:51:35 2010
From: report at bugs.python.org (Jason Baker)
Date: Fri, 03 Sep 2010 17:51:35 +0000
Subject: [issue9760] Suggestion for improving with documentation
In-Reply-To: <1283536295.47.0.948659460721.issue9760@psf.upfronthosting.co.za>
Message-ID: <1283536295.47.0.948659460721.issue9760@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

http://docs.python.org/reference/compound_stmts.html#with

This documentation refers to "context expressions" in two places.  However, it never really defines what a context expression is.  The formal syntax that's presented is this:

with_stmt ::=  "with" with_item ("," with_item)* ":" suite
with_item ::=  expression ["as" target]

As best I can tell, the context expression is essentially the with_item.  If that's the case, I propose one of the following:

 1) The formal syntax is changed so that "with_item" becomes "context_expression".
 2) References to "context expression" change to "with item".
 3) The "context expression" is defined to be the with_item in the formal syntax at some point in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 115478
nosy: Jason.Baker, docs at python
priority: normal
severity: normal
status: open
title: Suggestion for improving with documentation
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  3 19:53:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 17:53:26 +0000
Subject: [issue5506] io.BytesIO doesn't support the buffer protocol
In-Reply-To: <1237372813.02.0.863937398422.issue5506@psf.upfronthosting.co.za>
Message-ID: <1283536406.28.0.839208321466.issue5506@psf.upfronthosting.co.za>


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

There was an unused "weakreflist" member.

----------
Added file: http://bugs.python.org/file18732/bytesiobuf2.patch

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

From report at bugs.python.org  Fri Sep  3 19:53:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 17:53:33 +0000
Subject: [issue5506] io.BytesIO doesn't support the buffer protocol
In-Reply-To: <1237372813.02.0.863937398422.issue5506@psf.upfronthosting.co.za>
Message-ID: <1283536413.32.0.0210574175579.issue5506@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18731/bytesiobuf2.patch

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

From report at bugs.python.org  Fri Sep  3 19:53:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 17:53:48 +0000
Subject: [issue5506] io.BytesIO doesn't support the buffer protocol
In-Reply-To: <1237372813.02.0.863937398422.issue5506@psf.upfronthosting.co.za>
Message-ID: <1283536428.65.0.20160215494.issue5506@psf.upfronthosting.co.za>


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


----------
components: +IO
nosy: +amaury.forgeotdarc, benjamin.peterson

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

From report at bugs.python.org  Fri Sep  3 20:22:40 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 03 Sep 2010 18:22:40 +0000
Subject: [issue7231] Windows installer does not add \Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1283538160.83.0.455688526641.issue7231@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

FWIW, since last year ActivePython 2.6/2.7 puts C:\PythonXY\Scripts and %APPDATA%\Python\Scripts in %PATH% and we haven't had any complaints so far.

In addition, we also create a versioned interpreter executable - C:\PythonXY\pythonxy.exe - that is something the official installer can do as well, as it makes it possible to just type, say, "python27" when multiple Python versions are installed ... similar to typing 'python2.7' on *nix.

----------

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

From report at bugs.python.org  Fri Sep  3 20:33:32 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 03 Sep 2010 18:33:32 +0000
Subject: [issue9193] PEP 3149 (versioned .so files) reference implementation
In-Reply-To: <1278527607.97.0.766712002778.issue9193@psf.upfronthosting.co.za>
Message-ID: <1283538812.37.0.952460141971.issue9193@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


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

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

From report at bugs.python.org  Fri Sep  3 20:40:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 18:40:26 +0000
Subject: [issue3805] sslobj.read py3k takes odd arguments
In-Reply-To: <1220902607.94.0.0236135682272.issue3805@psf.upfronthosting.co.za>
Message-ID: <1283539226.32.0.794399221617.issue3805@psf.upfronthosting.co.za>


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

Cleanup done in r84464 (py3k), r84465 (3.1).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2 -Python 3.0

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

From report at bugs.python.org  Fri Sep  3 20:42:28 2010
From: report at bugs.python.org (Dan Christian)
Date: Fri, 03 Sep 2010 18:42:28 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
In-Reply-To: <AANLkTik9h5YDeaEUnciSQt2wW5nV6m+ihCLdF86TrSfT@mail.gmail.com>
Message-ID: <AANLkTin+CJRSeLNuEc675y91eZ+PvhxmPUdhPoFSnXfk@mail.gmail.com>


Dan Christian <robodan at users.sourceforge.net> added the comment:

It's been a while since I looked at this. ?I'm not really in a
position to contribute code/tests right now; but I can comment.

I don't think POSIX mode existed when I first reported this, but
that's where it makes sense. ?I think all POSIX shells (borne, C,
korne), will behave the same way for the issues mentioned.

There are really two cases in one bug.

The first part is that the shell will split tokens at characters that
shlex doesn't. ?The handling of &, |, ;, >, and < could be done by
adjusting the definition of shlex.wordchars. ?The shell may also
understands things like: &&, ||, |&, and >&. ?The exact definition of
these depends on the shell, so maybe it's best to just split them out
as separate tokens and let the user figure out the compound meanings.

The proper handling of quotes/escapes requires some kind of new
interface. ?You need to distinguish between tokens that were modified
by the quote/escape rules and those that were not. ?One suggestion is
to add a new method as such:

shlex.get_token2()
? ?Return a tuple of the token and the original text of the token
(including quotes and escapes). ?Otherwise, this is the same as
shlex.get_token().

Comparing the two values for equality (or maybe identity) would tell
you if something special was going on. ?You can always pass the second
value to a reconstructed command line without losing any of the
original parsing information.

-Dan

On Fri, Sep 3, 2010 at 10:27 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Thanks for the report. Would you like to work on a patch, or translate your examples into unit tests?
>
> The docs do not mention ?&? at all, and platform discrepancies have to be taken into account too, so I really don?t know if this is a bug fix for the normal mode, the POSIX mode, or a feature request requiring a new argument to the shlex function to preserve compatibility.
>
> ----------
> nosy: +eric.araujo, eric.smith
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1521950>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Sep  3 20:45:44 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Sep 2010 18:45:44 +0000
Subject: [issue8746] *chflags detection broken on FreeBSD 9-CURRENT
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1283539544.5.0.470495877533.issue8746@psf.upfronthosting.co.za>


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

Nick, can you provide a unit test and a patch file for the issue against the currently maintained versions?  Adding Alexandre to comment on why the configure change was made.

----------
components: +Build
nosy: +alexandre.vassalotti, ned.deily
stage:  -> unit test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Fri Sep  3 21:14:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 19:14:28 +0000
Subject: [issue9717] operator module - "in place" operators documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1283541268.23.0.479208479524.issue9717@psf.upfronthosting.co.za>


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

I agree that the docs for augmented assignments and the corresponding method and funciton can and should be improved.

But I do not like this as is. In particular, Python does not have in-place operators; it has methods that optionally do an operation in-place if the first argument (self) is mutable. I think adding "" is insufficient to avoid the confusion of the incorrect term. What I think should be said is that the ixxx methods and the corresponding operator.ixxx functions implement the operation part of operation-augmented assignments.

For the operator doc, I think we should expand the initial paragraph ("The operator module ...") a bit so that less needs to said specifically for the ixxx functions.

Also, most of your explanation is really about augmented assignment and the .__ixxx__ special methods, not specifically about operator.ixxx functions, and might better be added to the subsection 3.3.6. Emulating numeric typesof the special methods section (and cross-referenced from the operator doc) or even used to improve 6.2.1. Augmented assignment statements, and not buried in the operator doc. If people are confused about the .ixxx functions, they are probably confused also about a.a. and .__ixxx__ methods.

So I would like to attack the whole problem and expand this issue to "Improve operator-augmented assginment docs." and cover all three relevant doc areas, starting with
6.2.1. Augmented assignment statements. As already hinted, I would like to expand the title to "Operator-augmented assignment statements.".

I would like there to be a prototype example near the top: either "target_arg op= arg", with op explained as one of +-*/... or "target_arg += arg" as a specific example, or both. Since the target is also an arg reference, it obviously must refer to a single existing object. Then discuss the two cases of target immutable and mutable, as the current doc and your proposal does.

Otherwise in this section, I am mystified by the reference of "(See section Primaries for the syntax definitions for the last three symbols.)". I have also forgotten the meaning of "With the exception of assigning to tuples "; i should just be stated.

As already stated, I also believe the explanation of .__ixxx__ methods in 3.3.6. Emulating numeric types could be improved a bit.

----------
nosy: +terry.reedy
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.3

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

From report at bugs.python.org  Fri Sep  3 21:27:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Sep 2010 19:27:22 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1283542042.38.0.10656637554.issue9756@psf.upfronthosting.co.za>


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

<< I found this crash while playing with proxies (thanks haypo).
http://code.activestate.com/recipes/496741-object-proxying/ >>

My question was: why does isinstance(Proxy('abc'), str) works (give True), whereas re.match('abc', Proxy('abc')) fail.

It looks like you gave me the answer ;-)

----------

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

From report at bugs.python.org  Fri Sep  3 21:31:32 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Sep 2010 19:31:32 +0000
Subject: [issue9717] operator module - "in place" operators documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1283542292.72.0.789973584388.issue9717@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Consider breaking the operator module documents into sections, grouping all of the in-place ops into the last section.  Start that section with a full description of how in-place works in python and show some examples of successful way to use the in-place operators.

Right now, the docs are somewhat misleading because they imply that the i-functions can be used in the same was as their counterparts.

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

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

From report at bugs.python.org  Fri Sep  3 21:32:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Sep 2010 19:32:01 +0000
Subject: [issue9717] operator module - "in place" operators documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1283542321.07.0.601179114796.issue9717@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger

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

From report at bugs.python.org  Fri Sep  3 21:32:27 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 19:32:27 +0000
Subject: [issue9731] Add ABCMeta.has_methods and tests that use it
In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>
Message-ID: <1283542347.22.0.00800174301085.issue9731@psf.upfronthosting.co.za>


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

Good idea!

I see Raymond's point about the name. How about .method_check?
To me Sequence.method_check(range) means "Abstract Seqeunce class, please method-check the concrete range class."

If Sequence.register(range) is in the range source file, I would expect to find the test of the range class in test_range.

If all collection registrations were bundled together in collections.py, I think I would expect the tests to be in test_collections. But I could still be presuaded that the range method check should be in test_range where all the individual methods are (should be!) tested.

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

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

From report at bugs.python.org  Fri Sep  3 21:33:04 2010
From: report at bugs.python.org (Steve Thompson)
Date: Fri, 03 Sep 2010 19:33:04 +0000
Subject: [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>
Message-ID: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>


New submission from Steve Thompson <steve.f.thompson at gmail.com>:

I'm running pythong 2.6.1 on Windows XP SP3.

On many occasions I have ran into cases where I've installed a new package via the package's setup.py (pylint, logilab-common, etc) and new .pyc files don't get generated when I attempt to run the tools/packages.  I'm not sure if this should be considered a package issue or an interpreter issue.  I'd like to see the interpreter regenerate the .pyc file as expected so my colleagues and I don't burn time on "broken" packages we know nothing about only to find out it was due to some stale .pyc files.  A quick fix would be to make the packages in question clean out their installation directories or regenerate all the pyc files manually.

How should this issue be handled?

----------
components: Interpreter Core, Windows
messages: 115488
nosy: Steve.Thompson
priority: normal
severity: normal
status: open
title: stale .pyc files aren't cleaned out
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Sep  3 21:40:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 19:40:18 +0000
Subject: [issue9762] build failures
In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>
Message-ID: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

After a `make distclean` and a whole recompile I still get these:

building 'crypt' extension
gcc -pthread -fPIC -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -I/usr/local/include -IInclude -I/home/antoine/py3k/debug -c /home/antoine/py3k/debug/Modules/cryptmodule.c -o build/temp.linux-x86_64-3.2-pydebug/home/antoine/py3k/debug/Modules/cryptmodule.o
gcc -pthread -shared build/temp.linux-x86_64-3.2-pydebug/home/antoine/py3k/debug/Modules/cryptmodule.o -L/usr/local/lib -o build/lib.linux-x86_64-3.2-pydebug/crypt.cpython-32dm.so
*** WARNING: renaming "crypt" since importing it failed: build/lib.linux-x86_64-3.2-pydebug/crypt.cpython-32dm.so: undefined symbol: crypt

building 'nis' extension
gcc -pthread -fPIC -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -I/usr/local/include -IInclude -I/home/antoine/py3k/debug -c /home/antoine/py3k/debug/Modules/nismodule.c -o build/temp.linux-x86_64-3.2-pydebug/home/antoine/py3k/debug/Modules/nismodule.o
gcc -pthread -shared build/temp.linux-x86_64-3.2-pydebug/home/antoine/py3k/debug/Modules/nismodule.o -L/usr/local/lib -o build/lib.linux-x86_64-3.2-pydebug/nis.cpython-32dm.so
*** WARNING: renaming "nis" since importing it failed: build/lib.linux-x86_64-3.2-pydebug/nis.cpython-32dm.so: undefined symbol: yp_get_default_domain

Failed to build these modules:
crypt              nis

----------
assignee: barry
components: Build
messages: 115489
nosy: barry, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: build failures
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Fri Sep  3 21:41:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 19:41:17 +0000
Subject: [issue9293] Unsupported IO operations should raise
	UnsupportedOperation
In-Reply-To: <1279462171.13.0.608517762148.issue9293@psf.upfronthosting.co.za>
Message-ID: <1283542877.65.0.901208234142.issue9293@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/file18733/unsupported.patch

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

From report at bugs.python.org  Fri Sep  3 21:42:53 2010
From: report at bugs.python.org (William Barr)
Date: Fri, 03 Sep 2010 19:42:53 +0000
Subject: [issue9763] Crashes upon run after syntax error encountered in OSX
	10.5.8
In-Reply-To: <1283542973.95.0.133487128669.issue9763@psf.upfronthosting.co.za>
Message-ID: <1283542973.95.0.133487128669.issue9763@psf.upfronthosting.co.za>


New submission from William Barr <webmaster961 at gmail.com>:

Steps for reproduction:
1.  Open a new code window
2.  Enter python code which contains a syntax error
3.  F5 and attempt to run the file (This was done without saving first)
4.  Close the syntax error dialog.  
5.  Fix the syntax error and try to F5 again without saving again.  
6.  IDLE will encounter an error and unexpectedly close.  

I'm reporting this after having tested this on 4 different OSX 10.5.8 machines.  I'm not sure if other versions of Python are also susceptible to this as well.

----------
components: IDLE
messages: 115491
nosy: Webs961
priority: normal
severity: normal
status: open
title: Crashes upon run after syntax error encountered in OSX 10.5.8
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Fri Sep  3 21:45:26 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Sep 2010 19:45:26 +0000
Subject: [issue9759] GzipFile object should raise ValueError on .read() after
	.close()
In-Reply-To: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>
Message-ID: <1283543126.2.0.20172660782.issue9759@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/issue9759>
_______________________________________

From report at bugs.python.org  Fri Sep  3 21:48:29 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 19:48:29 +0000
Subject: [issue9731] Add ABCMeta.has_methods and tests that use it
In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>
Message-ID: <1283543309.51.0.574100161542.issue9731@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I agree that my original name proposal is terrible. :-)  method_check and verify_full_api both look fine to me.

> If all collection registrations were bundled together in 
> collections.py, I think I would expect the tests to be in 
> test_collections. But I could still be presuaded that the range method
> check should be in test_range where all the individual methods are 
> (should be!) tested.

All of the registrations are bundled together in _abcoll.py, which collections.py imports into collections.py's namespace.  (It's in a separate file to get around some bootstrapping issues.)

I favor putting them in test_collections to make it slightly easier to check for a 1:1 correlation between registrations and tests, but it's not something I feel strongly about.

----------

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

From report at bugs.python.org  Fri Sep  3 21:54:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 19:54:52 +0000
Subject: [issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1283543692.41.0.780662382884.issue9728@psf.upfronthosting.co.za>


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

As I remember, the FAQ was once that, *the* (giant) FAQ, with numbered sections. When broken into pieces, the order may have been re-arranged.

Given that the broken reference is in extending/windows, I would look in both the Extending and Windows FAQs. However, I found neither 'PyType_Type' nor 'PyVarObject_HEAD_INIT' nor 'initialization' in either.

Besides removing the dead reference, you could either look through the revision history of the file or ask on pydev if you need the info.

The split-up FAQs first appear in a release doc set in Python 2.6.4, documentation released on 25 October 2009. I do not know if the earlier, unitary FAQ is in the repository or not.

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

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

From report at bugs.python.org  Fri Sep  3 21:57:25 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 03 Sep 2010 19:57:25 +0000
Subject: [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>
Message-ID: <1283543845.65.0.429158052248.issue9761@psf.upfronthosting.co.za>


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

So are you installing new versions of a package you already have installed using ``python setup.py install``? Exactly what command are you using to do the install?

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Fri Sep  3 21:58:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 19:58:19 +0000
Subject: [issue9762] build failures
In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>
Message-ID: <1283543899.8.0.897163733718.issue9762@psf.upfronthosting.co.za>


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

The normal build lines for the crypt and nis modules contain additional library linkage ("normal", that is before your commit :-)):

gcc -pthread -shared build/temp.linux-x86_64-3.2/home/antoine/py3k/__svn__/Modules/cryptmodule.o -L/home/antoine/py3k/__svn__/usr/lib -L/usr/local/lib -lcrypt -o build/lib.linux-x86_64-3.2/crypt.so

gcc -pthread -shared build/temp.linux-x86_64-3.2/home/antoine/py3k/__svn__/Modules/nismodule.o -L/home/antoine/py3k/__svn__/usr/lib -L/usr/local/lib -lnsl -o build/lib.linux-x86_64-3.2/nis.so

("-lcrypt" in the former, "-lnsl" in the latter)

----------

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

From report at bugs.python.org  Fri Sep  3 22:00:27 2010
From: report at bugs.python.org (Steve Thompson)
Date: Fri, 03 Sep 2010 20:00:27 +0000
Subject: [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <AANLkTi=AP11eFGtxH3CdY3n2CZCtm+jJ7P8vuh7COkx3@mail.gmail.com>
Message-ID: <AANLkTi=5oMW36OFnJJCFo9-2uSkPtLWH9BQbw4say4N4@mail.gmail.com>


Steve Thompson <steve.f.thompson at gmail.com> added the comment:

"Setup.py install". We've also seen this happen when checking our python
files out of our version control system.  Also seen a .pyc get used when the
.py no longer exists, but I could see that being intentional behavior.

On Sep 3, 2010 2:57 PM, "Brett Cannon" <report at bugs.python.org> wrote:

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

So are you installing new versions of a package you already have installed
using ``python setup.py install``? Exactly what command are you using to do
the install?

----------
nosy: +brett.cannon

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

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9761>
_______________________________________
-------------- next part --------------
<p>&quot;Setup.py install&quot;. We&#39;ve also seen this happen when checking our python files out of our version control system.?? Also seen a .pyc get used when the .py no longer exists, but I could see that being intentional behavior.</p>

<p><blockquote type="cite">On Sep 3, 2010 2:57 PM, &quot;Brett Cannon&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br><br><br>
Brett Cannon &lt;<a href="mailto:brett at python.org">brett at python.org</a>&gt; added the comment:<br>
<br>
So are you installing new versions of a package you already have installed using ``python setup.py install``? Exactly what command are you using to do the install?<br>
<br>
----------<br>
nosy: +brett.cannon<br>
<p><font color="#500050"><br>_______________________________________<br>Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.">http://bugs.python.</a>..</font></p>
</blockquote></p>

From report at bugs.python.org  Fri Sep  3 22:14:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 20:14:56 +0000
Subject: [issue9731] Add ABCMeta.has_methods and tests that use it
In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>
Message-ID: <1283544896.49.0.851949832352.issue9731@psf.upfronthosting.co.za>


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

I wanted to propose the name check_methods, but then I thought that some people could read too much in that name, for example that arguments and return value are checked for correct type and value (see how Web people misunderstand ?HTML validation?). That said, ?check? promises less than ?validate?, and ABCs being a middle-to-advanced topic, we could trust people using this method to read the docstring and not expect too much.

----------

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

From report at bugs.python.org  Fri Sep  3 22:16:59 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Sep 2010 20:16:59 +0000
Subject: [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>
Message-ID: <1283545019.19.0.236634032397.issue9761@psf.upfronthosting.co.za>


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

Does your version control system let the files read-only by default?
In this case, see issue6074.

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

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

From report at bugs.python.org  Fri Sep  3 22:22:51 2010
From: report at bugs.python.org (Steve Thompson)
Date: Fri, 03 Sep 2010 20:22:51 +0000
Subject: [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <AANLkTi=HogD6pD2891JquU4AScPPB+wyR85Lj9zCn8kK@mail.gmail.com>
Message-ID: <AANLkTikOVyBtNkFO9zu4ja6Dzu8ZYVL3zvt_O+=kcUyC@mail.gmail.com>


Steve Thompson <steve.f.thompson at gmail.com> added the comment:

Hmmm... this definitely sounds like the issue for version controlled files,
but does not explain the issue when installing packages from source.

On Sep 3, 2010 3:16 PM, "Amaury Forgeot d&apos;Arc" <report at bugs.python.org>
wrote:

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

Does your version control system let the files read-only by default?
In this case, see issue6074.

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

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

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9761>
_______________________________________
-------------- next part --------------
<p>Hmmm... this definitely sounds like the issue for version controlled files, but does not explain the issue when installing packages from source.</p>
<p><blockquote type="cite">On Sep 3, 2010 3:16 PM, &quot;Amaury Forgeot d&amp;apos;Arc&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br><br><br>
Amaury Forgeot d&#39;Arc &lt;<a href="mailto:amauryfa at gmail.com">amauryfa at gmail.com</a>&gt; added the comment:<br>
<br>
Does your version control system let the files read-only by default?<br>
In this case, see issue6074.<br>
<br>
----------<br>
nosy: +amaury.forgeotdarc<br>
<p><font color="#500050"><br>_______________________________________<br>Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.">http://bugs.python.</a>..</font></p>
</blockquote></p>

From report at bugs.python.org  Fri Sep  3 22:27:59 2010
From: report at bugs.python.org (Steve Thompson)
Date: Fri, 03 Sep 2010 20:27:59 +0000
Subject: [issue6074] .pyc files created readonly if .py file is readonly,
	python won't overwrite
In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za>
Message-ID: <1283545679.09.0.801112951674.issue6074@psf.upfronthosting.co.za>


Steve Thompson <steve.f.thompson at gmail.com> added the comment:

So what's the current status of this on Windows Platforms?

----------
nosy: +Steve.Thompson

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

From report at bugs.python.org  Fri Sep  3 22:29:38 2010
From: report at bugs.python.org (Nick Dowell)
Date: Fri, 03 Sep 2010 20:29:38 +0000
Subject: [issue8746] *chflags detection broken on FreeBSD 9-CURRENT
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1283545778.98.0.883240466931.issue8746@psf.upfronthosting.co.za>


Changes by Nick Dowell <nickdowell at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file18736/8746-3.1.2.patch

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

From report at bugs.python.org  Fri Sep  3 22:29:52 2010
From: report at bugs.python.org (Nick Dowell)
Date: Fri, 03 Sep 2010 20:29:52 +0000
Subject: [issue8746] *chflags detection broken on FreeBSD 9-CURRENT
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1283545792.03.0.397146850648.issue8746@psf.upfronthosting.co.za>


Changes by Nick Dowell <nickdowell at gmail.com>:


Added file: http://bugs.python.org/file18737/8746-2.7.patch

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

From report at bugs.python.org  Fri Sep  3 22:30:09 2010
From: report at bugs.python.org (Nick Dowell)
Date: Fri, 03 Sep 2010 20:30:09 +0000
Subject: [issue8746] *chflags detection broken on FreeBSD 9-CURRENT
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1283545809.57.0.326260266876.issue8746@psf.upfronthosting.co.za>


Changes by Nick Dowell <nickdowell at gmail.com>:


Added file: http://bugs.python.org/file18738/8746-2.6.6.patch

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

From report at bugs.python.org  Fri Sep  3 22:36:30 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Sep 2010 20:36:30 +0000
Subject: [issue6074] .pyc files created readonly if .py file is readonly,
	python won't overwrite
In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za>
Message-ID: <1283546190.96.0.389810289369.issue6074@psf.upfronthosting.co.za>


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

This is still the case: on Windows, if foo.py is readonly,
    python -c "import foo"
generates foo.pyc with the readonly attribute.

Tested with 3.1 and current py3k (where the file is named __pycache__\foo.cpython-32.pyc)

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

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

From report at bugs.python.org  Fri Sep  3 22:38:50 2010
From: report at bugs.python.org (Steve Thompson)
Date: Fri, 03 Sep 2010 20:38:50 +0000
Subject: [issue6074] .pyc files created readonly if .py file is readonly,
	python won't overwrite
In-Reply-To: <1283546190.96.0.389810289369.issue6074@psf.upfronthosting.co.za>
Message-ID: <AANLkTimi0Ofxq0CgJyxUmrFBTdZwbdD93SA36AA1fa7t@mail.gmail.com>


Steve Thompson <steve.f.thompson at gmail.com> added the comment:

Any idea if this will be fixed (at all) and/or back ported to 2.6.x or
2.7.x?

On Fri, Sep 3, 2010 at 3:36 PM, Amaury Forgeot d'Arc <report at bugs.python.org
> wrote:

>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> This is still the case: on Windows, if foo.py is readonly,
>    python -c "import foo"
> generates foo.pyc with the readonly attribute.
>
> Tested with 3.1 and current py3k (where the file is named
> __pycache__\foo.cpython-32.pyc)
>
> ----------
> nosy: +amaury.forgeotdarc
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6074>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________
-------------- next part --------------
Any idea if this will be fixed (at all) and/or back ported to 2.6.x or 2.7.x?<br><br><div class="gmail_quote">On Fri, Sep 3, 2010 at 3:36 PM, Amaury Forgeot d&#39;Arc <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Amaury Forgeot d&#39;Arc &lt;<a href="mailto:amauryfa at gmail.com">amauryfa at gmail.com</a>&gt; added the comment:<br>
<br>
This is still the case: on Windows, if foo.py is readonly,<br>
 ?? ??python -c &quot;import foo&quot;<br>
generates foo.pyc with the readonly attribute.<br>
<br>
Tested with 3.1 and current py3k (where the file is named __pycache__\foo.cpython-32.pyc)<br>
<br>
----------<br>
nosy: +amaury.forgeotdarc<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue6074" target="_blank">http://bugs.python.org/issue6074</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Fri Sep  3 22:44:21 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 20:44:21 +0000
Subject: [issue9764] Tools/buildbot/external.bat should download and built tix
In-Reply-To: <1283546660.96.0.0013695103683.issue9764@psf.upfronthosting.co.za>
Message-ID: <1283546660.96.0.0013695103683.issue9764@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

external.bat and external-common.bat take care of downloading most external packages such as tcl, tk, and openssl.  However, the tix package is missing, but needed to build the msi.

----------
components: Build, Windows
messages: 115503
nosy: loewis, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Tools/buildbot/external.bat should download and built tix
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Sep  3 22:46:17 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 20:46:17 +0000
Subject: [issue9765] tcl-8 vs tcl8
In-Reply-To: <1283546777.07.0.320688875982.issue9765@psf.upfronthosting.co.za>
Message-ID: <1283546777.07.0.320688875982.issue9765@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Tools/buildbot/external-common.bat creates tcl-8.5.2.1, but Tools/msi/msi.py looks for tcl8*.  Consequently, Tools/buildbot/buildmsi.py does not work on a fresh machine.

tk has the same problem.

I encountered this on the py3k branch but have not checked other branches.

Attached is a simple patch to Tools/msi/msi.py.

----------
components: Build, Windows
files: tcl.patch
keywords: patch
messages: 115504
nosy: loewis, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: tcl-8 vs tcl8
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18740/tcl.patch

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

From report at bugs.python.org  Fri Sep  3 22:48:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 20:48:55 +0000
Subject: [issue9766] warnings has "onceregistry" and "once_registry"
In-Reply-To: <1283546935.08.0.780554208103.issue9766@psf.upfronthosting.co.za>
Message-ID: <1283546935.08.0.780554208103.issue9766@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The warnings module has both "onceregistry" and "once_registry", while _warnings only has the latter. There's probably a typo.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 115505
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: warnings has "onceregistry" and "once_registry"
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Sep  3 22:55:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 20:55:34 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283547334.94.0.598926205062.issue9730@psf.upfronthosting.co.za>


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

PATCH
Specifically, in section 17.6. base64..., near bottom, example should be

>>> import base64
>>> encoded = base64.b64encode(b'data to be encoded') #hang
>>> encoded
b'ZGF0YSB0byBiZSBlbmNvZGVk'
>>> data = base64.b64decode(encoded)
>>> data
b'data to be encoded'

with the first and third 'b' prefixes added.

I confirmed that doctest works with above.

I am a bit puzzled about Sphinx and 3.x comment, as doctest just need a plain ascii file and does not care how it was produced. (I used browser Save As text file function.) However, moot now.

----------
keywords: +patch
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Sep  3 23:03:01 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 21:03:01 +0000
Subject: [issue1303434] Please include pdb with windows distribution
Message-ID: <1283547781.78.0.0402358827803.issue1303434@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Attached is a slightly improved patch.  It cleans up some whitespace issues with James's patch and filters out *_d.pdb files if they exist.  I tested it on my system and it correctly produces a .zip file containing the .pdb files, next to the .msi file

Martin, do you need this patch to have any other functionality in order to make the python-*-pdb.zip file available after a release?

----------
Added file: http://bugs.python.org/file18741/pdb.patch

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

From report at bugs.python.org  Fri Sep  3 23:05:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 03 Sep 2010 21:05:20 +0000
Subject: [issue9766] warnings has "onceregistry" and "once_registry"
In-Reply-To: <1283546935.08.0.780554208103.issue9766@psf.upfronthosting.co.za>
Message-ID: <1283547920.41.0.620395144944.issue9766@psf.upfronthosting.co.za>


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

"defaultaction" and "default_action" is in the same situation. I think there may have been a circular import/ref problem as _warnings pulls from warnings the objects to use for the variables in question. Or at least that's what makes sense. =)

That means the _warnings versions should simply be renamed to "_onceregistry" and "_defaultaction" instead of their current names. Work for you?

----------

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

From report at bugs.python.org  Fri Sep  3 23:07:13 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 03 Sep 2010 21:07:13 +0000
Subject: [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>
Message-ID: <1283548033.1.0.534625282368.issue9761@psf.upfronthosting.co.za>


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

This could still be an issue with the .pyc files being set with permissions that prevent them from being re-generated. Double-check the .pyc files are read-write and have the proper owners to allow them to be overwritten.

----------

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

From report at bugs.python.org  Fri Sep  3 23:10:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 21:10:46 +0000
Subject: [issue9766] warnings has "onceregistry" and "once_registry"
In-Reply-To: <1283547920.41.0.620395144944.issue9766@psf.upfronthosting.co.za>
Message-ID: <1283548242.3223.3.camel@localhost.localdomain>


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

> That means the _warnings versions should simply be renamed to
> "_onceregistry" and "_defaultaction" instead of their current names.
> Work for you?

Certainly.

----------

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

From report at bugs.python.org  Fri Sep  3 23:31:05 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 03 Sep 2010 21:31:05 +0000
Subject: [issue9766] warnings has "onceregistry" and "once_registry"
In-Reply-To: <1283546935.08.0.780554208103.issue9766@psf.upfronthosting.co.za>
Message-ID: <1283549465.57.0.635687687874.issue9766@psf.upfronthosting.co.za>


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

OK, so I will fix this in 3.2 but not any other versions as someone might be foolishly relying on the name. Hopefully I can get to this over the weekend.

----------
keywords: +easy
versions:  -Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Sep  3 23:32:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 21:32:52 +0000
Subject: [issue9767] Failures in json doc examples
In-Reply-To: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>
Message-ID: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

I ran doctest on LibRef 17.2 json saved as .txt. There are 4 failures: 2 are clearly doc issues, the other 2 I do not know. I hope someone reads this who is already familiar

DOC PATCHES
    dumps(2 + 1j, cls=ComplexEncoder)
should be
    json.dumps(2 + 1j, cls=ComplexEncoder)
and
    JSONEncoder().encode({"foo": ["bar", "baz"]})
should be
    json.JSONEncoder().encode({"foo": ["bar", "baz"]})

Needing similar additions in example code (not caught by doctest) are
           return JSONEncoder.default(self, o)
        for chunk in JSONEncoder().iterencode(bigobject):

Those fixes leave 2 failures I an unclear about and hope a json expert will comment on.

1.'''
Failed example:
    print(json.dumps({'4': 5, '6': 7}, sort_keys=True, indent=4))
Expected:
    {
        "4": 5,
        "6": 7
    }
Got:
    {
        "4": 5, 
        "6": 7
    }
'''
The difference is that json puts a trailing space after '5,'. Should it? or should one be added to the doc?

2. '''
Failed example:
    list(ComplexEncoder().iterencode(2 + 1j))
Expected:
    ['[', '2.0', ', ', '1.0', ']']
Got:
    ['[2.0', ', 1.0', ']']
'''
Without knowing how the default iterencode interacts with the overwridden .default() method, I have no idea.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 115512
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Failures in json doc examples
type: behavior

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

From report at bugs.python.org  Fri Sep  3 23:47:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 21:47:04 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283550424.55.0.449047417082.issue9730@psf.upfronthosting.co.za>


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

As an experiment, I ran doctest on 17.2 json saved as .txt, See #9767
4 failures, 2 obvious doc faults, 2 unclear to me.
Their were 2 similar doc faults in non-interactive code examples, so doctest is not enough to catch all bad code.

We clearly need to do this for the entire doc, preferably before 3.2 is released. A master issue is the wrong format, at least by itself. What I think is needed is a repository doc like Misc/maintainers.rst, call it Misc/doctests or Misc/docdoctests. It should have a line for each doc section with current status (blank for unchecked, n/a for no interactive example, issue number for fixes in progress). A master issue could then be a place where non-committers can report changes that committers could apply. What do you others think?

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

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

From report at bugs.python.org  Fri Sep  3 23:47:14 2010
From: report at bugs.python.org (Craig de Stigter)
Date: Fri, 03 Sep 2010 21:47:14 +0000
Subject: [issue9720] zipfile writes incorrect local file header for large
	files in zip64
In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za>
Message-ID: <1283550434.76.0.674631772134.issue9720@psf.upfronthosting.co.za>


Craig de Stigter <craig.ds at gmail.com> added the comment:

Yes, the bug still exists in Python 3.1.2. However, struct.pack() no longer silently ignores overflow, so I get this error instead:


>>> z.write('foo.txt')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/zipfile.py", line 1095, in write
    zinfo.file_size))
struct.error: argument out of range

----------

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

From report at bugs.python.org  Sat Sep  4 00:03:04 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 03 Sep 2010 22:03:04 +0000
Subject: [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1283551384.23.0.97120057602.issue8678@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/issue8678>
_______________________________________

From report at bugs.python.org  Sat Sep  4 00:08:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Sep 2010 22:08:26 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1283551706.49.0.0252323264007.issue9756@psf.upfronthosting.co.za>


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

>>> class Spam(object):
...     def __getattribute__(self, name):
...         if name == '__class__':
...             return str
...         raise AttributeError
... 
>>> spam = Spam('spam')
>>> isinstance(spam, str)
True

isinstance(spam, str) calls str.__instancecheck__(spam) (type___instancecheck__) which checks spam.__class__, and spam.__class__ is str.

--

>>> import re
>>> re.match('spam', spam)
TypeError: expected string or buffer

Here the result is different because _sre.compile(spam) calls getstring() which uses PyUnicode_Check(spam) (-> False) and does checks on the buffer API (-> False).

--

About str.title(spam): it calls methoddescr_call() which checks the type using... PyObject_IsInstance() (and not PyUnicode_Check()).

----------

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

From report at bugs.python.org  Sat Sep  4 00:09:34 2010
From: report at bugs.python.org (Kristoffer F)
Date: Fri, 03 Sep 2010 22:09:34 +0000
Subject: [issue9768] IDLE / Black frame in active window
In-Reply-To: <1283551774.16.0.36540025292.issue9768@psf.upfronthosting.co.za>
Message-ID: <1283551774.16.0.36540025292.issue9768@psf.upfronthosting.co.za>


New submission from Kristoffer F <kkf628 at gmail.com>:

Hi 

I am new to python and have installed python 3.1.2. I have began using 
IDLE and like it very good. 

But when an IDLE window is active. There is a "thick" black frame around 
the white text field. Is this a know issue? And is there some way I can get rid of this frame? 

The frame is very distracting when I write. 

Kristoffer

----------
components: IDLE
messages: 115516
nosy: kfollesdal
priority: normal
severity: normal
status: open
title: IDLE / Black frame in active window
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat Sep  4 00:14:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 22:14:11 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za>
Message-ID: <1283552051.56.0.00416137087272.issue9598@psf.upfronthosting.co.za>


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

Fixed encoding error in r84472 through r84474.

This bug should be reassessed and retitled. If untabify fails because a file has an incorrect encoding, is it really a problem in untabify? This is a developer?s tool, so getting a traceback here seems okay to me. Alexander, please close if you agree.

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

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

From report at bugs.python.org  Sat Sep  4 00:14:32 2010
From: report at bugs.python.org (Kristoffer F)
Date: Fri, 03 Sep 2010 22:14:32 +0000
Subject: [issue9768] IDLE / Black frame in active window
In-Reply-To: <1283551774.16.0.36540025292.issue9768@psf.upfronthosting.co.za>
Message-ID: <1283552072.12.0.125379675642.issue9768@psf.upfronthosting.co.za>


Kristoffer F <kkf628 at gmail.com> added the comment:

Hi 

I am new to python and have installed python 3.1.2. I have began using 
IDLE and like it very good. 

But when an IDLE window is active. There is a "thick" black frame around 
the white text field. Is this a know issue? And is there some way I can get rid of this frame? 

The frame is very distracting when I write. 

Kristoffer

*I forgot to tell that I am using a Mac with Snow Leopard.

----------

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

From report at bugs.python.org  Sat Sep  4 00:21:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 22:21:04 +0000
Subject: [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283552464.97.0.558432683918.issue9739@psf.upfronthosting.co.za>


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

Although this is not a problem in IDLE where the window can easily be expanded beyond 80 chars, I am in favor of the idea for other uses. The command line interpreter on Windows defaults to 80 chars and is not so easy to change, and one must be admin to make the change 'permanent' (until the next install reverts the change). In particular, the 82 char line for math.trun results in 'd.' of 'method.' wrapped to a line by itself with no indent. Pretty ugly.

However, I am puzzled why you edited the 74 char line for math.modf, which displays as 78 chars with a 4 char indent. This
'''\    
    Return the fractional and integer parts of x.  Both results carry the sign'''
displays fine on one line as is. The tracker, unfortunately, displays
123456789012345678901234567890123456789012345678901234567890123456789012 only 72 chars.
    of x and are floats.

I agree that
    trunc(x:Real) -> Integral
is more helpful (and therefore better) than
    modf(x)

For something like
-"T.index(value, [start, [stop]]) -> integer -- return first index of value.\n"

I personally think '->' and 'return are redundant, so I would argue that this could be shortened to
-"T.index(value, [start, [stop]]) -> integer (first index of value).\n"
instead of by wrapping.

Since I am not yet in a position to apply patches, I am not (yet) in a position to tell you whether or how to produce more patches.

----------
nosy: +terry.reedy
stage:  -> patch review
versions: +Python 3.2

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

From report at bugs.python.org  Sat Sep  4 00:29:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 22:29:14 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283552954.47.0.946257612507.issue9730@psf.upfronthosting.co.za>


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

It seems there are three ways of testing the docs:

1) ./python -m doctest Doc/library/json.rst
2) make doctest (a.k.a. sphinx-build -b doctest)
3) http://sphinx.pocoo.org/ext/doctest.html

Manually running 1) or 2) and fixing things seems okay for a first step, and when everything is fixed, we could add automation to prevent regressions. Georg is in the best place to say how to do it (through a thin test_docs.py integration layer between doctest and regrtest, with sphinx.ext.doctest, or by editing the test target of the makefile to run make doctest -C Doc).

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

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

From report at bugs.python.org  Sat Sep  4 00:30:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 22:30:56 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283553056.41.0.724115438314.issue9730@psf.upfronthosting.co.za>


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

Note also that some docs (turtle) require running Tcl, which may be unwanted on headless machines like buildbots.

----------

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

From report at bugs.python.org  Sat Sep  4 00:38:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 22:38:23 +0000
Subject: [issue9767] Failures in json doc examples
In-Reply-To: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>
Message-ID: <1283553503.14.0.508973836805.issue9767@psf.upfronthosting.co.za>


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

r84481 should fix all except the whitespace one.  I don't think this is worth fixing; I will not add a trailing whitespace to the docs, and adding a "doctest: NORMALIZE_WHITESPACE" directive does not help readability, especially since nobody actually runs these doctest-like examples.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Sep  4 00:38:39 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 22:38:39 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1283553519.84.0.638183558151.issue9738@psf.upfronthosting.co.za>


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

Better specifying requirements is good. A few comments:

-   The second argument is an error message; it is converted to a string object.
+   The second argument is an error message; it is decoded to a string object
+   with ``'utf-8'`` encoding.
 
I would write the change as
+   The second argument is a utf-8 encoded error message; it is decoded to a string object. 

I the second part (what the function will do with the arg) really needed? I think in the current version, it serves to indirectly specify that the arg in not to be a string, but bytes. If the specific encoding required is specified, that also says bytes, making 'will be decoded' redundant and irrelevant.
-------------------------------

+   a Python exception (class, not an instance). *format* should be a string
+   encoded to ISO-8859-1, containing format codes, 

*format* should be ISO-8859-1 encoded bytes containing format codes,

although I am not clear about the implications of that. Are not all format code ascii chars?
--------------------------------

I do not really like 'encoded to', but 'decoded to' is wrong. 'will be decoded from xxx bytes' is better. I think there should be a general discussion somewhere about bytes arguments and the terminology that will be used.

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

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

From report at bugs.python.org  Sat Sep  4 00:40:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 22:40:38 +0000
Subject: [issue9760] Suggestion for improving with documentation
In-Reply-To: <1283536295.47.0.948659460721.issue9760@psf.upfronthosting.co.za>
Message-ID: <1283553638.76.0.351729801039.issue9760@psf.upfronthosting.co.za>


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

Actually, the with_item contains the context expression *and* the optional "as target" clause, so they are not equivalent

I committed a clarification in r84482.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Sep  4 00:43:49 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 03 Sep 2010 22:43:49 +0000
Subject: [issue9421] configparser.ConfigParser's getint,
	getboolean and getfloat don't accept `vars`
In-Reply-To: <1280428369.21.0.84678458473.issue9421@psf.upfronthosting.co.za>
Message-ID: <1283553829.6.0.323688956026.issue9421@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

On IRC Fred asked:
> Why are delimiters and comment_prefixes in the constructor signatures?

Like most configurable options, they were added to the initializer one by one (after `allow_no_value`). Only later did I notice that actually things like optionxform, _boolean_states, etc. are configurable by assignment. So this is a design decision whether one way should be preferred over the other. In a way that's unfortunate that we now have two obvious ways to do it.

I believe that keyword arguments are far better because they are more declarative, e.g.:

parser = SafeConfigParser(delimiters=(':=',),
                          comment_prefixes=('//',))

vs.

parser = SafeConfigParser()
parser._delimiters = (':=',)
parser._comment_prefixes = ('//',)

It's the way ORMs and many other frameworks do it and it feels natural.

----------

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

From report at bugs.python.org  Sat Sep  4 00:45:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 22:45:24 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283553924.23.0.945278993936.issue9730@psf.upfronthosting.co.za>


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

Generally: +1 on making sure examples in the docs are up to date.  If someone wants to do the tedious work of making sure that a "make doctest" succeeds, I'm all for it, it may involve adding a few (in HTML output invisible) testsetup blocks.

Eric: I'm not sure what the difference between your methods 2 and 3 is :)

As Terry already mentioned, by far not all example code is covered by that, and I don't think there's anything we can do about it.  We can of course try converting more doc examples to doctest format, however:

a) for longer examples and especially function/class definitions this really hurts readability and usability (think copy/paste)

b) many examples are also not easily runnable (Tk is a good example, many more can be found in those for network services)

----------

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

From report at bugs.python.org  Sat Sep  4 00:47:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Sep 2010 22:47:06 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za>
Message-ID: <1283554026.29.0.926824675179.issue9598@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> If untabify fails because a file has an incorrect encoding, is it really
> a problem in untabify? This is a developer?s tool, so getting a
> traceback here seems okay to me.

I disagree.  I think we should use this opportunity to clarify preferred encoding for C language source files in python and make untabify produce meaningful diagnostic in case of encoding errors.

As a matter of policy, I see two possibilities:

1. Restrict C sources to 7-bit ASCII.  (A pedantic reading of ANSI C standard would probably suggest even more restricted character set, but practically, I don't think 7-bit ASCII in C comments is likely to cause problems for any tools.

2. Require UTF-8 encoding for non-ASCII characters.  Given that this is the default for python source code, it is likely that tools that are used for python development can handle UTF-8.

My vote is for #1.  Display of non-ascii characters is still not universally supported and they are likely to be clobbered when diffs are copied in e-mails etc.

----------

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

From report at bugs.python.org  Sat Sep  4 00:48:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 22:48:32 +0000
Subject: [issue9421] configparser.ConfigParser's getint,
	getboolean and getfloat don't accept `vars`
In-Reply-To: <1280428369.21.0.84678458473.issue9421@psf.upfronthosting.co.za>
Message-ID: <1283554112.03.0.227293438402.issue9421@psf.upfronthosting.co.za>


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

I agree with msg115525.

----------

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

From report at bugs.python.org  Sat Sep  4 00:51:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 22:51:25 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283553924.23.0.945278993936.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283554281.3223.4.camel@localhost.localdomain>


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

> Generally: +1 on making sure examples in the docs are up to date.  If
> someone wants to do the tedious work of making sure that a "make
> doctest" succeeds, I'm all for it, it may involve adding a few (in
> HTML output invisible) testsetup blocks.

I'm not sure that's a good idea. It may add a lot of spurious imports
which only make the examples longer and less readable.

----------

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

From report at bugs.python.org  Sat Sep  4 00:54:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 22:54:29 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283554469.28.0.018992090132.issue9730@psf.upfronthosting.co.za>


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

2) works without changing anything, 3) requires using specific directives IIUC.

----------

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

From report at bugs.python.org  Sat Sep  4 00:55:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 22:55:53 +0000
Subject: [issue7862] fileio.c: ValueError vs. IOError with impossible
	operations
In-Reply-To: <1265405300.06.0.973184216127.issue7862@psf.upfronthosting.co.za>
Message-ID: <1283554553.43.0.912136883527.issue7862@psf.upfronthosting.co.za>


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

See #9293, where there's a patch.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Unsupported IO operations should raise UnsupportedOperation

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

From report at bugs.python.org  Sat Sep  4 00:56:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 22:56:15 +0000
Subject: [issue9293] Unsupported IO operations should raise
	UnsupportedOperation
In-Reply-To: <1279462171.13.0.608517762148.issue9293@psf.upfronthosting.co.za>
Message-ID: <1283554575.24.0.797782354445.issue9293@psf.upfronthosting.co.za>


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


----------
nosy: +skrah, stutzbach

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

From report at bugs.python.org  Sat Sep  4 00:57:17 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 22:57:17 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283554637.01.0.167836774867.issue9730@psf.upfronthosting.co.za>


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

>> Generally: +1 on making sure examples in the docs are up to date.  If
>> someone wants to do the tedious work of making sure that a "make
>> doctest" succeeds, I'm all for it, it may involve adding a few (in
>> HTML output invisible) testsetup blocks.
> 
> I'm not sure that's a good idea. It may add a lot of spurious imports
> which only make the examples longer and less readable.

That's why I said to use "testsetup" directives -- they are not visible in the HTML/PDF/... output, but used when running the tests.

----------

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

From report at bugs.python.org  Sat Sep  4 00:57:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 22:57:48 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283554668.59.0.333733823367.issue9730@psf.upfronthosting.co.za>


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

> 2) works without changing anything, 3) requires using specific directives IIUC.

No.  The doctest extension is what "make doctest" calls.

----------

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

From report at bugs.python.org  Sat Sep  4 00:58:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 22:58:58 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za>
Message-ID: <1283554738.59.5.58570763409e-06.issue9598@psf.upfronthosting.co.za>


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

I agree about the need to define the encoding for comments. My vote goes to #2, since I wouldn?t want to see names of authors/contributors mangled in the source. I would reconsider if a specification explicitly forbade that.

I repeat that the title of this bug is misleading: untabify does not fail with non-ASCII bytes, it failed because of invalid bytes.

----------

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

From report at bugs.python.org  Sat Sep  4 01:00:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 23:00:36 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283554836.45.0.632599429741.issue9730@psf.upfronthosting.co.za>


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

Thanks for clearing this misunderstanding of mine.

----------

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

From report at bugs.python.org  Sat Sep  4 01:02:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Sep 2010 23:02:12 +0000
Subject: [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1283554932.48.0.240030577776.issue8678@psf.upfronthosting.co.za>


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

I am able to reproduce the crash with z > 4:

# (magic, type (rle, bpp), dim, x, y, z)
open('image', 'wb').write(struct.pack('>hhhhhh', 0732, 1, 1, 1, 1, 10))
rgbimg.longimagedata('image')

--

But not the "xsize = ysize = 0x8000" integer overflow. longimagedata() begins by checking that xsize * ysize * zsize * sizeof(Py_Int32) doesn't overflow:

	tablen = xsize * ysize * zsize * sizeof(Py_Int32);
        if (xsize != (((tablen / ysize) / zsize) / sizeof(Py_Int32))) {
		PyErr_NoMemory();
		goto finally;
        }

If xsize * ysize * zsize * sizeof(Py_Int32) doesn't overflow, there is no reason that xsize * ysize * sizeof(Py_Int32) does overflow.

--

I am too tired to check the two RLE bugs.

----------

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

From report at bugs.python.org  Sat Sep  4 01:06:41 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 03 Sep 2010 23:06:41 +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: <1283555201.48.0.0487930110825.issue8273@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Issue #9754 proposes to implement assertWarns / assertWarnsRegexp

----------
dependencies: +assertWarns and assertWarnsRegexp

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

From report at bugs.python.org  Sat Sep  4 01:07:03 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 03 Sep 2010 23:07:03 +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: <1283555223.64.0.475603383705.issue8273@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
title: move generally useful test_support functions into the unittest package -> move generally useful test.support functions into the unittest package

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

From report at bugs.python.org  Sat Sep  4 01:15:52 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 03 Sep 2010 23:15:52 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1283555752.69.0.748450383096.issue7723@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I propose to close this, since 2.7 is released and the situation is better in Python 3.

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

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

From report at bugs.python.org  Sat Sep  4 01:16:03 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Sep 2010 23:16:03 +0000
Subject: [issue9763] Crashes upon run after syntax error encountered in OSX
	10.5.8
In-Reply-To: <1283542973.95.0.133487128669.issue9763@psf.upfronthosting.co.za>
Message-ID: <1283555763.17.0.788588743114.issue9763@psf.upfronthosting.co.za>


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

Following your test case, I am able to produce a deadlocked IDLE when using the python.org 3.1.2 OS X installer on 10.5.8 when using just the Apple-supplied Tk 8.4 framework.  After installing a recent ActiveState Tcl/Tk 8.4 framework (the python.org installers are built to dynamically link with either), the hang is no longer reproducible.  There doesn't seem to be a problem with either 2.6.6 or 2.7, with either version of Tcl/Tk, nor is there on 10.6 but the Apple-supplied 8.4 there is much newer than that in 10.5. I'm doing some more triage work on this issue with 3.1 and 3.2.

In the interim, a workaround may be to install the ActiveState Tcl/Tk 8.4 on your systems if that is acceptable.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sat Sep  4 01:18:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Sep 2010 23:18:09 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za>
Message-ID: <1283555889.51.0.540117206096.issue9598@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> I wouldn?t want to see names of authors/contributors mangled
> in the source.

This is a reason to write names in ASCII.   While Latin-1 is a grey area because most of it's characters look familiar to English-speaking developers, I don't think you will easily recognize my name if I write it in Cyrillic and even if you do, chances are you would not be able to search for it.  On the other hand, everyone who uses e-mail is likely to have a preferred ASCII spelling of his/her name.

----------

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

From report at bugs.python.org  Sat Sep  4 01:19:21 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 23:19:21 +0000
Subject: [issue9767] Failures in json doc examples
In-Reply-To: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>
Message-ID: <1283555961.51.0.163007751306.issue9767@psf.upfronthosting.co.za>


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

Well, anyone who does try that example will see the correct output and not notice the trailing whitespace difference. It will only be an issue if and when automated doc doctests are run repeatedly. Worry about it then. Thanks for the quick response.

----------

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

From report at bugs.python.org  Sat Sep  4 01:23:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 23:23:15 +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: <1283556195.24.0.797600072912.issue2122@psf.upfronthosting.co.za>


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


----------
nosy: +brian.curtin, tim.golden
versions:  -Python 2.6

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

From report at bugs.python.org  Sat Sep  4 01:45:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 23:45:39 +0000
Subject: [issue9535] Pending signals are inherited by child processes
In-Reply-To: <1281105795.17.0.408658965128.issue9535@psf.upfronthosting.co.za>
Message-ID: <1283557539.66.0.612246952678.issue9535@psf.upfronthosting.co.za>


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


----------
components: +Interpreter Core -Extension Modules
nosy: +gregory.p.smith
stage:  -> patch review
versions: +Python 3.1, Python 3.2 -Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Sep  4 01:48:03 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Sep 2010 23:48:03 +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: <1283557683.21.0.84384870305.issue2122@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee:  -> brian.curtin

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

From report at bugs.python.org  Sat Sep  4 01:53:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Sep 2010 23:53:01 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>


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

I'm trying to document the encoding of all bytes argument of the C API: see #9738. I tried to understand which encoding is used by PyUnicode_FromFormat*() (and PyErr_Format() which calls PyUnicode_FromFormatV()). It looks like ISO-8859-1, see unicodeobject.c near line 1106:

    for (f = format; *f; f++) {
        if (*f == '%') {
            ...
        } else
            *s++ = *f; <~~~~ here
    }

... oh wait, it doesn't work for non-ascii text! Test in gdb:

(gdb) print _PyObject_Dump(PyUnicodeUCS2_FromFormat("iso-8859-1:\xd0\xff"))
object  : 'iso-8859-1:\uffd0\uffff'
type    : str
refcount: 1
address : 0x83d5d80

b'\xd0\xff' is decoded '\uffd0\xffff' :-( It's a bug.

--

PyUnicode_FromFormatV() should raise an error on non-ascii format character, or decode it correctly as... ISO-8859-1 or something else. It's difficult to support multi byte encodings (like utf-8), ISO-8859-1 is fine. If we choose to raise an error, how can the user format a non-ascii string? Using its_unicode_format.format(...arguments...) or its_unicode_format % arguments? Is it easy to call these methods in C?

----------
components: Interpreter Core, Unicode
messages: 115542
nosy: haypo
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormatV() doesn't handle non-ascii text correctly
versions: Python 3.2

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

From report at bugs.python.org  Sat Sep  4 01:53:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Sep 2010 23:53:47 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1283558027.24.0.678070537645.issue9738@psf.upfronthosting.co.za>


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

About PyErr_Format() and PyUnicode_FromFormat*() encoding: it's not exactly ISO-8859-1... there is a bug => issue #9769.

----------

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

From report at bugs.python.org  Sat Sep  4 02:01:49 2010
From: report at bugs.python.org (Kevin Thibedeau)
Date: Sat, 04 Sep 2010 00:01:49 +0000
Subject: [issue9770] curses.isblank function doesn't match ctype.h
In-Reply-To: <1283558509.74.0.494754089018.issue9770@psf.upfronthosting.co.za>
Message-ID: <1283558509.74.0.494754089018.issue9770@psf.upfronthosting.co.za>


New submission from Kevin Thibedeau <kevinpt at yahoo.com>:

The isblank() function defined in curses.ascii is incorrect and doesn't match the output from C's isblank() from ctype.h

Incorrect definition:
  def isblank(c): return _ctoi(c) in (8,32)

Should be:
  def isblank(c): return _ctoi(c) in (9,32)

This most likely affects all versions of Python, not just 2.7.

----------
components: Library (Lib)
messages: 115544
nosy: kevinpt
priority: normal
severity: normal
status: open
title: curses.isblank function doesn't match ctype.h
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Sep  4 02:06:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 00:06:26 +0000
Subject: [issue8734] msvcrt get_osfhandle crash on bad FD
In-Reply-To: <1274034133.01.0.249446827178.issue8734@psf.upfronthosting.co.za>
Message-ID: <1283558786.06.0.153968240707.issue8734@psf.upfronthosting.co.za>


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

Should this be checked in?

----------
nosy: +pitrou
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Sep  4 02:06:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 00:06:59 +0000
Subject: [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1283558819.54.0.0327868252911.issue6916@psf.upfronthosting.co.za>


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


----------
assignee: josiahcarlson -> giampaolo.rodola
stage:  -> patch review
versions:  -Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Sep  4 02:09:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 00:09:11 +0000
Subject: [issue8594] Add a "source_address" option to ftplib
In-Reply-To: <1272745982.51.0.743868524528.issue8594@psf.upfronthosting.co.za>
Message-ID: <1283558951.34.0.765704339337.issue8594@psf.upfronthosting.co.za>


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


----------
assignee:  -> giampaolo.rodola

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

From report at bugs.python.org  Sat Sep  4 02:09:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 00:09:40 +0000
Subject: [issue8597] build out-of-line asm on Windows
In-Reply-To: <1272779131.33.0.179650713526.issue8597@psf.upfronthosting.co.za>
Message-ID: <1283558980.49.0.643932526796.issue8597@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/issue8597>
_______________________________________

From report at bugs.python.org  Sat Sep  4 02:10:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Sep 2010 00:10:46 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1283559046.81.0.144759455469.issue9630@psf.upfronthosting.co.za>


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

Another possibility is to use _Py_char2wchar() + PyUnicode_FromWideChar() / _Py_wchar2char() + PyUnicode_AsWideChar() to decode / encode filenames. These functions use the locale encoding. This solution was possible in Python 3.1, but no more in Python 3.2 because of the PYTHONFSENCODING environment variable.

Even if I don't like my own solution, I don't see better solution.

----------

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

From report at bugs.python.org  Sat Sep  4 02:13:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 00:13:27 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1283559207.86.0.347781070038.issue8401@psf.upfronthosting.co.za>


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


----------
stage: unit test needed -> patch review
versions:  -Python 2.6

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

From report at bugs.python.org  Sat Sep  4 02:23:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Sep 2010 00:23:37 +0000
Subject: [issue9632] Remove sys.setfilesystemencoding()
In-Reply-To: <1282132564.59.0.094866961442.issue9632@psf.upfronthosting.co.za>
Message-ID: <1283559817.19.0.284213164993.issue9632@psf.upfronthosting.co.za>


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

> In such environments you cannot expect the user to configure the
> system properly (i.e. set an environment variable).

Why would it be different for embeded python?

> Instead, the application has to provide an educated guess 
> to the Python interpreter in some way, ...

How can the application guess the encoding better than Python? If the user doesn't configure correctly its environment, I don't see how the application can get the real (correct) environment config?!

If Python is unable to start because of the filesystem encoding, it is a bug (see #8611). If Python starts but displays incorrectly filenames, it is the user fault: the user have to setup its environment.

----------

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

From report at bugs.python.org  Sat Sep  4 02:25:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Sep 2010 00:25:50 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za>
Message-ID: <1283559950.11.0.737575971908.issue9598@psf.upfronthosting.co.za>


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

>> I wouldn?t want to see names of authors/contributors mangled
>> in the source.
> 
> This is a reason to write names in ASCII.

Oh, sorry, by ?mangled? I meant ?forced into ASCII?. I was not speaking about mojibake.

> While Latin-1 is a grey area because most of [its] characters look familiar
> to English-speaking developers,

I don?t think there is an argument for Latin-1. Also, Latin-1 does not have characters but bytes, which are displayed as characters by good editors, like UTF-8 bytes are. The discussion is about ASCII versus UTF-8 in my opinion, let Latin-1 rest in peace.

> I don't think you will easily recognize my name if I write it in Cyrillic
> and even if you do, chances are you would not be able to search for it.

Not so good example, since I?ve seen your name in the thread about Misc/ACKS sorting and could recognize it, by I get your idea :)

To search, I would use the ?search for word under cursor? functionality.

> On the other hand, everyone who uses e-mail is likely to have a preferred
> ASCII spelling of his/her name.

Well, some languages have rules to handle constrained environments, like German who may use oe for ? or Italian E' for ?, but for example in French there is no such workaround. Leaving accents out of words is a spelling error, nothing more or less. When I?m forced to change my name because of broken old tools I really feel the programmers behind the tool could do better. (I happen to have an ASCII-compatible nickname, which I prefer using to the ASCII-maimed version of my name where I can.)

I feel 2010 is very late to accept that we live in a wide world and that people should be able to just use their names with computer systems.

By the way, you still haven?t retitled this bug to address my other remark :)

----------

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

From report at bugs.python.org  Sat Sep  4 02:27:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 00:27:28 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1283560048.08.0.824010708262.issue6394@psf.upfronthosting.co.za>


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


----------
nosy: +brian.curtin, tim.golden
stage:  -> patch review
versions: +Python 3.2 -Python 2.7

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

From report at bugs.python.org  Sat Sep  4 02:32:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Sep 2010 00:32:36 +0000
Subject: [issue8597] build out-of-line asm on Windows
In-Reply-To: <1272779131.33.0.179650713526.issue8597@psf.upfronthosting.co.za>
Message-ID: <1283560356.15.0.402096411283.issue8597@psf.upfronthosting.co.za>


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

I have a hard time reading old-style diffs, so a unified diff would be a win. Alternatively, a Mercurial clone URI would do.

Can someone confirm this is a duplicate of #7546 as hinted by Stefan or explain the difference? I?m a bit too sleepy to do that and anyway know nearly nothing about assembler.

----------
nosy: +josip

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

From report at bugs.python.org  Sat Sep  4 02:32:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Sep 2010 00:32:54 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1283560374.29.0.919776669574.issue7546@psf.upfronthosting.co.za>


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


----------
nosy: +josip

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

From report at bugs.python.org  Sat Sep  4 02:33:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Sep 2010 00:33:04 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1283560384.94.0.854983750776.issue9756@psf.upfronthosting.co.za>


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

PyUnicode_Check(op) checks op->ob_type->tp_flags & Py_TPFLAGS_UNICODE_SUBCLASS.

----------

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

From report at bugs.python.org  Sat Sep  4 02:33:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 00:33:32 +0000
Subject: [issue4905] Use INVALID_FILE_ATTRIBUTES instead of magic numbers
In-Reply-To: <1231580515.2.0.210154432041.issue4905@psf.upfronthosting.co.za>
Message-ID: <1283560412.33.0.367323499268.issue4905@psf.upfronthosting.co.za>


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


----------
components: +Extension Modules, Windows -Interpreter Core
nosy: +brian.curtin, tim.golden
stage:  -> patch review
versions: +Python 3.2 -Python 2.7

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

From report at bugs.python.org  Sat Sep  4 02:34:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 00:34:01 +0000
Subject: [issue4379] Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing
In-Reply-To: <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za>
Message-ID: <1283560441.18.0.648951043657.issue4379@psf.upfronthosting.co.za>


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


----------
nosy: +belopolsky

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

From report at bugs.python.org  Sat Sep  4 02:35:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 00:35:27 +0000
Subject: [issue3899] test_ssl.py doesn't properly test ssl integration with
	asyncore
In-Reply-To: <1221744950.78.0.538519688245.issue3899@psf.upfronthosting.co.za>
Message-ID: <1283560527.85.0.553502647704.issue3899@psf.upfronthosting.co.za>


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

This has been integrated long ago.

----------
nosy: +pitrou
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Sat Sep  4 02:38:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Sep 2010 00:38:57 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1283560737.83.0.915719946226.issue9756@psf.upfronthosting.co.za>


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

I have different questions:
 - Should we trust PyObject_IsInstance() or PyUnicode_Check() (because they give different results)?
 - Should PyObject_IsInstance() and PyUnicode_Check() give the same result?
 - Should we fix the segfault?

To fix the segfault, I suppose that we use a more strict validation on the input type. Eg. Use PyUnicode_Check() instead of PyObject_IsInstance()?

----------

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

From report at bugs.python.org  Sat Sep  4 03:00:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Sep 2010 01:00:41 +0000
Subject: [issue1552880] [Python2] Use utf-8 in the import machinery on Windows
	to support unicode paths
Message-ID: <1283562041.55.0.916372457027.issue1552880@psf.upfronthosting.co.za>


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

Oh, I didn't see that the issue was specific to Python2. I updated the issue's title. If I understood correctly, the issue is also specific to Windows.

Do you know if your patch changes the public API? (break the compatibility)

--

FYI about Python3:

> That's an inventive way of breaking the unicode standard :)

It is described in the PEP 383 and it does solve a real and common issue: store a filename that cannot be decoded with the filesystem encoding. The operation is reversible. In Python 3.2, there are os.fsdecode() and os.fsencode() functions. On UNIX/BSD, os.encode(os.fsdecode(x)) is x, if x is a bytes object.

The PEP 383 introduces the surrogateescape error handler which does create surrogates on decode, and convert back surrogates to bytes on encode.

> Anyway, why would you worry about that? My patch doesn't use
> "surrogateescape" so there is no problem.

In Python3, filenames are stored as unicode. On UNIX/BSD, if a filename cannot be decode, it is encoded with surrogates. To get a full unicode support in Python3, you have to support surrogates.

----------
title: Unicode Imports -> [Python2] Use utf-8 in the import machinery on Windows to support unicode paths

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

From report at bugs.python.org  Sat Sep  4 05:30:00 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Sep 2010 03:30:00 +0000
Subject: [issue9768] IDLE / Black frame in active window
In-Reply-To: <1283552072.12.0.125379675642.issue9768@psf.upfronthosting.co.za>
Message-ID: <1283571000.82.0.0228972542912.issue9768@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg115516

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

From report at bugs.python.org  Sat Sep  4 05:35:01 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Sep 2010 03:35:01 +0000
Subject: [issue9768] IDLE / Black frame in active window
In-Reply-To: <1283552072.12.0.125379675642.issue9768@psf.upfronthosting.co.za>
Message-ID: <1283571301.31.0.234978532481.issue9768@psf.upfronthosting.co.za>


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

I am not sure what problem you are seeing.  How did you install Python 3.1.2?  Using the python.org 3.1.2 installer for OS X? MacPorts?  From source?  If so, which version of Tcl/Tk is IDLE using?  Perhaps you can take a screen shot (/Applications/Utilities/Grab.app) and attach it to this issue.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sat Sep  4 05:36:58 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 04 Sep 2010 03:36:58 +0000
Subject: [issue9421] configparser.ConfigParser's getint,
	getboolean and getfloat don't accept `vars`
In-Reply-To: <1280428369.21.0.84678458473.issue9421@psf.upfronthosting.co.za>
Message-ID: <1283571418.71.0.372107967847.issue9421@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

My question in IRC wasn't intended to mean "why are we passing settings to the constructor" so my much as "why are these configuration settings"; sorry I wasn't clear.

Have we encountered actual use cases that are not covered by the existing code?  I don't recall ever seeing a request for more flexibility in that regard.

----------

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

From report at bugs.python.org  Sat Sep  4 05:43:36 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 04 Sep 2010 03:43:36 +0000
Subject: [issue9421] configparser.ConfigParser's getint,
	getboolean and getfloat don't accept `vars`
In-Reply-To: <1280428369.21.0.84678458473.issue9421@psf.upfronthosting.co.za>
Message-ID: <1283571816.4.0.978089378339.issue9421@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Regardless, my concerns about including delimiters and comment_prefixes as settings is irrelevant to this issue.  The changes to them probably shouldn't have been part of this issue to begin with, but I'll try not to lose sleep over it at this point.

----------

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

From report at bugs.python.org  Sat Sep  4 05:55:15 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Sep 2010 03:55:15 +0000
Subject: [issue9770] curses.isblank function doesn't match ctype.h
In-Reply-To: <1283558509.74.0.494754089018.issue9770@psf.upfronthosting.co.za>
Message-ID: <1283572515.16.0.116933725134.issue9770@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +akuchling

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

From report at bugs.python.org  Sat Sep  4 05:55:44 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Sep 2010 03:55:44 +0000
Subject: [issue9770] curses.isblank function doesn't match ctype.h
In-Reply-To: <1283558509.74.0.494754089018.issue9770@psf.upfronthosting.co.za>
Message-ID: <1283572544.39.0.32924280591.issue9770@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Sep  4 06:06:29 2010
From: report at bugs.python.org (Samuel Neves)
Date: Sat, 04 Sep 2010 04:06:29 +0000
Subject: [issue8597] build out-of-line asm on Windows
In-Reply-To: <1272779131.33.0.179650713526.issue8597@psf.upfronthosting.co.za>
Message-ID: <1283573189.95.0.979223389695.issue8597@psf.upfronthosting.co.za>


Samuel Neves <sneves at dei.uc.pt> added the comment:

I was unaware of patch #7456 when this was submitted. As far as I can tell, there is no difference and no reason to maintain both.

----------
nosy: +sneves

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

From report at bugs.python.org  Sat Sep  4 06:37:31 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 04 Sep 2010 04:37:31 +0000
Subject: [issue9421] configparser.ConfigParser's getint,
	getboolean and getfloat don't accept `vars`
In-Reply-To: <1280428369.21.0.84678458473.issue9421@psf.upfronthosting.co.za>
Message-ID: <1283575051.89.0.90970691293.issue9421@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

The patch has been commited largely as-is (r84486).

I'm not happy with the documentation yet:

- Markup like this:

    .. method:: ConfigParser.getint(section, option, raw=False,
                [vars, default])

  doesn't sit well with me.  I'm going to dig around current practice
  a bit and discuss with Georg sometime over the next few days, and
  see how best to adjust that.

- Inclusion of references to internal names in the API docs, like this
  in the signatures:

    comment_prefixes=_COMPATIBLE

  is just bad form.  Again, we need a better way.  I suspect there is
  little if any considered precedent, so we'll come up with something.

Neither of these are blockers; we can adjust this independently of the
code and doocumentation content.  (It's not part of the feature.)

Leaving this issue open for the completion of these changes.

----------
resolution:  -> accepted

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

From report at bugs.python.org  Sat Sep  4 08:38:21 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 04 Sep 2010 06:38:21 +0000
Subject: [issue8734] msvcrt get_osfhandle crash on bad FD
In-Reply-To: <1274034133.01.0.249446827178.issue8734@psf.upfronthosting.co.za>
Message-ID: <1283582301.54.0.942656490074.issue8734@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

I guess it should, shouldn't it ?

----------

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

From report at bugs.python.org  Sat Sep  4 10:02:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 04 Sep 2010 08:02:38 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1283587358.86.0.762623135135.issue8401@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> georg.brandl

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

From report at bugs.python.org  Sat Sep  4 10:03:41 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Sep 2010 08:03:41 +0000
Subject: [issue8597] build out-of-line asm on Windows
In-Reply-To: <1272779131.33.0.179650713526.issue8597@psf.upfronthosting.co.za>
Message-ID: <1283587421.38.0.242693176449.issue8597@psf.upfronthosting.co.za>


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

The patches are very similar. This one always chooses ml64 on a 64 bit
platform, even when a user has executed `vcvarsall x86`.

The patch in #7546 attempts to honor the environment and has unit tests,
so I'm making #7546 the superseder.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> msvc9compiler.py: add .asm extension

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

From report at bugs.python.org  Sat Sep  4 10:05:23 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 04 Sep 2010 08:05:23 +0000
Subject: [issue9421] configparser.ConfigParser's getint,
	getboolean and getfloat don't accept `vars`
In-Reply-To: <1280428369.21.0.84678458473.issue9421@psf.upfronthosting.co.za>
Message-ID: <1283587523.74.0.898700954331.issue9421@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Actually the square bracket form is how `range()` is documented so there is some limited precedent in that regard.

----------

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

From report at bugs.python.org  Sat Sep  4 10:14:49 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Sep 2010 08:14:49 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1283588089.01.0.0133449351056.issue7546@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18681/vcasm2.patch

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

From report at bugs.python.org  Sat Sep  4 10:15:35 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Sep 2010 08:15:35 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1283588135.56.0.0595678416533.issue7546@psf.upfronthosting.co.za>


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

Minor cleanups in vcasm2.patch.

----------
Added file: http://bugs.python.org/file18742/vcasm2.patch

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

From report at bugs.python.org  Sat Sep  4 10:27:00 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Sep 2010 08:27:00 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1283588820.88.0.345325464297.issue7546@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18742/vcasm2.patch

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

From report at bugs.python.org  Sat Sep  4 10:28:39 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Sep 2010 08:28:39 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1283588919.84.0.332524542803.issue7546@psf.upfronthosting.co.za>


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

Further cleanup (sorry for the mail volume!).

----------
Added file: http://bugs.python.org/file18743/vcasm2.patch

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

From report at bugs.python.org  Sat Sep  4 10:32:52 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Sep 2010 08:32:52 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1283589172.51.0.681920992432.issue7546@psf.upfronthosting.co.za>


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


----------
nosy: +brian.curtin, sneves, zooko
versions:  -Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Sep  4 11:39:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Sep 2010 09:39:35 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1283593175.19.0.84014783195.issue7546@psf.upfronthosting.co.za>


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

(distutils2 bugs have all versions set)

----------
versions: +Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Sep  4 11:51:01 2010
From: report at bugs.python.org (Kristoffer F)
Date: Sat, 04 Sep 2010 09:51:01 +0000
Subject: [issue9768] IDLE / Black frame in active window
In-Reply-To: <1283552072.12.0.125379675642.issue9768@psf.upfronthosting.co.za>
Message-ID: <1283593861.41.0.585518453103.issue9768@psf.upfronthosting.co.za>


Kristoffer F <kkf628 at gmail.com> added the comment:

Hi

I installed python from the python.org installer. I have now taken a screen shot, with two IDLE windows open. So you can se that it is only the active window that get the frame. 

I see that you have also responded to my posts at comp.lang.python. Would you like to only use this post?

Kristoffer

----------
Added file: http://bugs.python.org/file18744/IDLE_frame.jpg

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

From report at bugs.python.org  Sat Sep  4 12:11:05 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Sep 2010 10:11:05 +0000
Subject: [issue9768] IDLE / Black frame in active window
In-Reply-To: <1283552072.12.0.125379675642.issue9768@psf.upfronthosting.co.za>
Message-ID: <1283595065.88.0.14891611405.issue9768@psf.upfronthosting.co.za>


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

The black line border in the screen shot is the indication of which IDLE window currently has the keyboard focus.  Note that if you click on the IDLE shell window or open and select other text windows, the black line border appears around the currently selected window.  That seems to be an essential UI element.  I don't know of any documented way to change it but you could explore the source code of idlelib.

----------

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

From report at bugs.python.org  Sat Sep  4 13:32:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 04 Sep 2010 11:32:10 +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: <1283599930.65.0.476914851505.issue9771@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The function tokenize.detect_encoding() detects the encoding either in the coding cookie or in the BOM.  If no encoding is found, it returns 'utf-8':

When result is 'utf-8', there's no (easy) way to know if the encoding was really detected in the file, or if it falls back to the default value.

Cases (with utf-8):

 - UTF-8 BOM found, returns ('utf-8-sig', [])
 - cookie on 1st line, returns ('utf-8', [line1])
 - cookie on 2nd line, returns ('utf-8', [line1, line2])
 - no cookie found, returns ('utf-8', [line1, line2])


The proposal is to allow to call the function with a different default value (None or ''), in order to know if the encoding is really detected.

For example, this function could be used by the Tools/scripts/findnocoding.py script.

Patch attached.

----------
components: Library (Lib)
files: detect_encoding_default.diff
keywords: patch
messages: 115567
nosy: flox
priority: normal
severity: normal
stage: patch review
status: open
title: add an optional "default" argument to tokenize.detect_encoding
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18745/detect_encoding_default.diff

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

From report at bugs.python.org  Sat Sep  4 13:45:19 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 04 Sep 2010 11:45:19 +0000
Subject: [issue9731] Add ABCMeta.has_methods and tests that use it
In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>
Message-ID: <1283600719.55.0.341042348385.issue9731@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

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

From report at bugs.python.org  Sat Sep  4 14:01:25 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 04 Sep 2010 12:01:25 +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: <1283601685.6.0.819525034936.issue9772@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

This failure occurs on AMD64 debian parallel buildbot.
It is not the same failure as OS X Tiger buildbot (issue 8423).


======================================================================
FAIL: test_listdir (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_pep277.py", line 157, in test_listdir
    self.assertEqual(sf0, sf2)
AssertionError: Items in the first set but not the second:
'@test_21179_tmp/Gr????-Gott'
Items in the second set but not the first:
'@test_21179_tmp/Gr\udcfc\udcdf-Gott'

======================================================================
FAIL: test_listdir (test.test_pep277.UnicodeNFCFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_pep277.py", line 157, in test_listdir
    self.assertEqual(sf0, sf2)
AssertionError: Items in the first set but not the second:
'@test_21179_tmp/Gr????-Gott'
Items in the second set but not the first:
'@test_21179_tmp/Gr\udcfc\udcdf-Gott'

======================================================================
FAIL: test_listdir (test.test_pep277.UnicodeNFKCFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_pep277.py", line 157, in test_listdir
    self.assertEqual(sf0, sf2)
AssertionError: Items in the first set but not the second:
'@test_21179_tmp/Gr????-Gott'
Items in the second set but not the first:
'@test_21179_tmp/Gr\udcfc\udcdf-Gott'

----------------------------------------------------------------------
Ran 30 tests in 1.576s


http://www.python.org/dev/buildbot/builders/AMD64%20debian%20parallel%203.x/builds/94/steps/test/logs/stdio

----------
components: Tests, Unicode
keywords: buildbot
messages: 115568
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: test_pep277 failure on AMD64 debian parallel buildbot
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Sep  4 14:13:19 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 04 Sep 2010 12:13:19 +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: <1283602399.09.0.660649968872.issue9773@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

Occurs repeatedly on AMD64 debian parallel.

======================================================================
FAIL: test_extractall (test.test_tarfile.MiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 331, in test_extractall
    self.assertEqual(tarinfo.mtime, os.path.getmtime(path))
AssertionError: 1041808783 != 1041808783.000001

======================================================================
FAIL: test_extractall (test.test_tarfile.GzipMiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 331, in test_extractall
    self.assertEqual(tarinfo.mtime, os.path.getmtime(path))
AssertionError: 1041808783 != 1041808783.000003

======================================================================
FAIL: test_extractall (test.test_tarfile.Bz2MiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 331, in test_extractall
    self.assertEqual(tarinfo.mtime, os.path.getmtime(path))
AssertionError: 1041808783 != 1041808783.000005

----------------------------------------------------------------------
Ran 230 tests in 6.681s

FAILED (failures=3)
test test_tarfile crashed -- <class 'OSError'>: [Errno 16] Device or resource busy: '/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/build/test_python_21179/@test_21179_tmp/.nfs000000000004f3b30000060b'
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 1560, in test_main
    support.run_unittest(*tests)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/support.py", line 1078, in run_unittest
    _run_suite(suite)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/support.py", line 1061, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 942, in runtest_inner
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 1563, in test_main
    shutil.rmtree(TEMPDIR)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/shutil.py", line 283, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/shutil.py", line 281, in rmtree
    os.remove(fullname)
OSError: [Errno 16] Device or resource busy: '/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/build/test_python_21179/@test_21179_tmp/.nfs000000000004f3b30000060b'

http://www.python.org/dev/buildbot/builders/AMD64%20debian%20parallel%203.x/builds/94

----------
components: Tests
keywords: buildbot
messages: 115569
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: test_tarfile fails because of inaccurate mtime on AMD64 debian parallel buildbot
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Sep  4 14:22:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 04 Sep 2010 12:22:07 +0000
Subject: [issue9774] test_smtpnet fails with "[110] Connection timed out" on
	AMD64 debian parallel buildbot
In-Reply-To: <1283602927.92.0.540080511811.issue9774@psf.upfronthosting.co.za>
Message-ID: <1283602927.92.0.540080511811.issue9774@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

Repeated failure on AMD64 debian parallel buildbot.

[329/346] test_smtpnet
test test_smtpnet failed -- Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_smtpnet.py", line 15, in test_connect
    server = smtplib.SMTP_SSL(self.testServer, self.remotePort)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/smtplib.py", line 758, in __init__
    SMTP.__init__(self, host, port, local_hostname, timeout)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/smtplib.py", line 239, in __init__
    (code, msg) = self.connect(host, port)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/smtplib.py", line 295, in connect
    self.sock = self._get_socket(host, port, self.timeout)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/smtplib.py", line 763, in _get_socket
    new_socket = socket.create_connection((host, port), timeout)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/socket.py", line 319, in create_connection
    raise error(msg)
socket.error: [Errno 110] Connection timed out

http://www.python.org/dev/buildbot/builders/AMD64%20debian%20parallel%203.x/builds/94

----------
components: Tests
messages: 115570
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: test_smtpnet fails with "[110] Connection timed out" on AMD64 debian parallel buildbot
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Sep  4 15:16:01 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 04 Sep 2010 13:16:01 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283606161.9.0.875522778629.issue9732@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

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

From report at bugs.python.org  Sat Sep  4 15:19:46 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 04 Sep 2010 13:19:46 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za>
Message-ID: <1283606386.52.0.923037427419.issue9598@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Other C files converted from latin-1 to utf-8 with r84485.

----------
components: +Unicode
nosy: +flox

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

From report at bugs.python.org  Sat Sep  4 15:23:06 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 04 Sep 2010 13:23:06 +0000
Subject: [issue7962] Demo and Tools need to be tested and pruned
In-Reply-To: <1266531589.82.0.915519058153.issue7962@psf.upfronthosting.co.za>
Message-ID: <1283606586.53.0.00899114867031.issue7962@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
dependencies: +add an optional "default" argument to tokenize.detect_encoding

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

From report at bugs.python.org  Sat Sep  4 16:23:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 14:23:26 +0000
Subject: [issue9764] Tools/buildbot/external.bat should download and built tix
In-Reply-To: <1283546660.96.0.0013695103683.issue9764@psf.upfronthosting.co.za>
Message-ID: <1283610206.34.0.316229817551.issue9764@psf.upfronthosting.co.za>


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

Unfortunately, Tix just won't build that easily. Patches are welcome.

It may be worthwhile to rely on build_tkinter.py exclusively (but that often doesn't work, either).

----------

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

From report at bugs.python.org  Sat Sep  4 16:26:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 14:26:06 +0000
Subject: [issue9765] tcl-8 vs tcl8
In-Reply-To: <1283546777.07.0.320688875982.issue9765@psf.upfronthosting.co.za>
Message-ID: <1283610366.72.0.0307290944803.issue9765@psf.upfronthosting.co.za>


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

This patch is incorrect. The naming of the directories as in msi.py is correct; the naming in Tools/buildbot is slightly inappropriate.

Tix relies on the specific directory names referred-to by msi.py, hence I use a different in my buildarea than Tools/buildbot.

----------

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

From report at bugs.python.org  Sat Sep  4 16:39:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 14:39:14 +0000
Subject: [issue1303434] Please include pdb with windows distribution
Message-ID: <1283611154.66.0.916604819699.issue1303434@psf.upfronthosting.co.za>


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

Thanks for the patch, committed as r84487. I'll try it out with the next 3.2 alpha release.

Leaving this open for possible backports.

----------

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

From report at bugs.python.org  Sat Sep  4 16:39:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 14:39:20 +0000
Subject: [issue1303434] Please include pdb with windows distribution
Message-ID: <1283611160.44.0.57736192767.issue1303434@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> accepted

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

From report at bugs.python.org  Sat Sep  4 16:44:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 14:44:14 +0000
Subject: [issue1552880] [Python2] Use utf-8 in the import machinery on Windows
	to support unicode paths
Message-ID: <1283611454.65.0.340106579657.issue1552880@psf.upfronthosting.co.za>


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

As this was never meant for inclusion in Python, and apparently confuses people, I'm closing it - it couldn't go into 2.x, anyway.

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

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

From report at bugs.python.org  Sat Sep  4 17:14:25 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 15:14:25 +0000
Subject: [issue9745] MSVC .pdb files not created by python 2.7 distutils
In-Reply-To: <1283442735.74.0.917204488917.issue9745@psf.upfronthosting.co.za>
Message-ID: <1283613265.51.0.172054325453.issue9745@psf.upfronthosting.co.za>


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

See the subversion history. It was added in r14344, which supposedly originated from Thomas Heller, so he should know.

Thomas, what's the reason for suppressing PDB files?

----------
nosy: +loewis, theller

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

From report at bugs.python.org  Sat Sep  4 17:22:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 15:22:04 +0000
Subject: [issue9719] build_ssl.py: cannot find 'asm64/*.*'
In-Reply-To: <1283202305.21.0.603628878344.issue9719@psf.upfronthosting.co.za>
Message-ID: <1283613724.98.0.25347578163.issue9719@psf.upfronthosting.co.za>


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

http://svn.python.org/projects/external/openssl-1.0.0a/asm64/

Please follow the instructions in PCbuild/readme.txt carefully. Thanks.

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

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

From report at bugs.python.org  Sat Sep  4 17:32:09 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 04 Sep 2010 15:32:09 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

It's hard to say what exactly is to blame here, but I will try to outline the problem as good as I can and try to track it down:

A library of mine is using a Thread that is getting entries from a multiprocessing.Queue periodically.  What I find when the python interpreter is shutting down is this on stderr:

Error in sys.exitfunc:
Traceback (most recent call last):
  File "python2.6/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "python2.6/multiprocessing/util.py", line 270, in _exit_function
    info('process shutting down')
TypeError: 'NoneType' object is not callable

Tracking down the issue shows that something has a __del__ [i have not found the object, i was under the impression the ProcessAwareLogger monkeypatch was, but apprently it's not the culprit] and clears out the module.  When the exit handler is running info is already set to None.  It can be easily checked if that is the issue when a weird monkepatch is added:

def fix_logging_in_multiprocesing():
    from multiprocessing import util, process
    import logging
    util._check_logger_class()
    old_class = logging.getLoggerClass()
    def __del__(self):
        util.info = util.debug = lambda *a, **kw: None
        process._cleanup = lambda *a, **kw: None
    old_class.__del__ = __del__
  
I originally thought that the destructor of the ProcessAwareLogger class was the issue, but apparently not so because it does not have one.

Interestingly if one looks into the util.py module the following comment can be found:

def _check_logger_class():
    '''
    Make sure process name is recorded when loggers are used
    '''
    # XXX This function is unnecessary once logging is patched
    import logging
    if hasattr(logging, 'multiprocessing'):
        return
    ...

This is interesting because the logging monkeypatch is unused if logging is multiprocessing aware (which it should be in 2.6 at least).  However apparently at one point the toplevel multiprocessing import was removed which makes this test fall all the time.  Looking at the current 26 branch it appears that the monkeypatch was removed by jesse noller in [68737] over a year ago.

With the current development version (and I suppose a later release than 2.6.1 which I am currently testing) the error disappears as well.

However the core issue would come back as soon as the atexit call moves past a destructor again I suppose.  Because of that I would recommend aliasing info to _info and debug to _debug and then calling the underscored methods in the atexit handler.

Any reasons for not doing that?  Otherwise I would like to propose committing that patch.

----------
components: Library (Lib)
messages: 115578
nosy: aronacher
priority: normal
severity: normal
status: open
title: Multiprocessing, logging and atexit play not well together
versions: Python 2.6

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

From report at bugs.python.org  Sat Sep  4 17:32:29 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 04 Sep 2010 15:32:29 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1283614349.71.0.27762472095.issue9775@psf.upfronthosting.co.za>


Changes by Armin Ronacher <armin.ronacher at active-4.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file18746/9775-fix.patch

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

From report at bugs.python.org  Sat Sep  4 17:42:22 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 04 Sep 2010 15:42:22 +0000
Subject: [issue9758] ioctl mutable buffer copying problem
In-Reply-To: <1283532852.64.0.959169848478.issue9758@psf.upfronthosting.co.za>
Message-ID: <1283614942.87.0.595553134653.issue9758@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/file18747/ioctl_1024_mutable.patch

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

From report at bugs.python.org  Sat Sep  4 17:47:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 15:47:17 +0000
Subject: [issue9758] ioctl mutable buffer copying problem
In-Reply-To: <1283532852.64.0.959169848478.issue9758@psf.upfronthosting.co.za>
Message-ID: <1283615237.55.0.669205293822.issue9758@psf.upfronthosting.co.za>


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

Do you think there is a simple, generic way to test for this (see Lib/test/test_ioctl.py)?

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

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

From report at bugs.python.org  Sat Sep  4 17:49:34 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 04 Sep 2010 15:49:34 +0000
Subject: [issue9747] os.getresgid() documentation mentions "user ids",
	not "group ids"
In-Reply-To: <1283479568.94.0.540639670687.issue9747@psf.upfronthosting.co.za>
Message-ID: <1283615374.87.0.232306379182.issue9747@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

This mistake is also in the docstring, I've attached a path to fix both.

----------
keywords: +patch
nosy: +bbrazil
Added file: http://bugs.python.org/file18748/getresgid_group_not_user.patch

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

From report at bugs.python.org  Sat Sep  4 17:57:08 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 04 Sep 2010 15:57:08 +0000
Subject: [issue9776] Inconsistent spacing in fcntl.fcntl docstring
In-Reply-To: <1283615828.17.0.964870505124.issue9776@psf.upfronthosting.co.za>
Message-ID: <1283615828.17.0.964870505124.issue9776@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

The spacing in fcntl.fcntl's docstring isn't consistent, the attached patch fixes this.

----------
assignee: docs at python
components: Documentation
files: fcntl_docstring_spacing.patch
keywords: patch
messages: 115582
nosy: bbrazil, docs at python
priority: normal
severity: normal
status: open
title: Inconsistent spacing in fcntl.fcntl docstring
versions: Python 3.2
Added file: http://bugs.python.org/file18749/fcntl_docstring_spacing.patch

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

From report at bugs.python.org  Sat Sep  4 18:04:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 16:04:30 +0000
Subject: [issue9762] build failures
In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>
Message-ID: <1283616270.9.0.276311786327.issue9762@psf.upfronthosting.co.za>


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

Oh, I just noticed that many other modules weren't built either: _ssl, _hashlib, _sqlite, _tkinter. Apparently setup.py cannot find the relevant "bits" anymore.

Bisecting shows that this happened with the PEP 3149 commit.

----------
nosy: +georg.brandl
priority: normal -> critical

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

From report at bugs.python.org  Sat Sep  4 18:10:03 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 04 Sep 2010 16:10:03 +0000
Subject: [issue9758] ioctl mutable buffer copying problem
In-Reply-To: <1283532852.64.0.959169848478.issue9758@psf.upfronthosting.co.za>
Message-ID: <1283616603.53.0.148054709209.issue9758@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

I'd already had a look around, and my knowledge of ioctls is not sufficient to answer that question but I suspect the answer is no. 

Does someone know of a ioctl that works across platforms, doesn't require specific hardware or privileges and that does some form of read operation?

----------

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

From report at bugs.python.org  Sat Sep  4 18:15:36 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 16:15:36 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1283616936.12.0.162822219327.issue9775@psf.upfronthosting.co.za>


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

IIUC, you are proposing to fix Python 2.6 only. Please understand that this branch is closed for bug fixes (unless they are security issues, which this issue is not).

As for 2.7: please try explaining again what specific issue the patch is meant to resolve? What monkey-patching are you referring to? What destructor? Why is aliasing these functions going to solve a problem?

As for "a reason not to do the change": lacking a clear problem definition, the aliasing seems pointless.

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

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

From report at bugs.python.org  Sat Sep  4 18:28:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 16:28:48 +0000
Subject: [issue9762] build failures
In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>
Message-ID: <1283617728.56.0.975964991757.issue9762@psf.upfronthosting.co.za>


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

I've committed a workaround in r84488. Feel free to improve.

----------

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

From report at bugs.python.org  Sat Sep  4 18:28:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 16:28:56 +0000
Subject: [issue9762] build failures
In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>
Message-ID: <1283617736.47.0.66277033688.issue9762@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep  4 18:35:11 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 04 Sep 2010 16:35:11 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1283618111.24.0.568923428804.issue9775@psf.upfronthosting.co.za>


Changes by Armin Ronacher <armin.ronacher at active-4.com>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Sat Sep  4 18:39:10 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 04 Sep 2010 16:39:10 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1283618350.03.0.086188747558.issue9775@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

This also affects 2.7, I just worked on 2.6 because this is where I encountered the issue.

> As for 2.7: please try explaining again what specific issue the patch
> is meant to resolve? What monkey-patching are you referring to? What 
> destructor? Why is aliasing these functions going to solve a problem?

As mentioned above I cannot provide more information because I am unable to find the root of the issue.  All I know is that if the atexit handler is executed after the module globals were set to None it fails to shutdown properly.

The old monkey patch can be found here: http://svn.python.org/view/python/tags/r261/Lib/multiprocessing/util.py?revision=71601&view=markup

I am pretty sure that this is one way to trigger the issue but by itself not the root of the problem.

----------

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

From report at bugs.python.org  Sat Sep  4 18:41:48 2010
From: report at bugs.python.org (Jeremy Thurgood)
Date: Sat, 04 Sep 2010 16:41:48 +0000
Subject: [issue9217] 2to3 crashes with some doctests
In-Reply-To: <1278790070.07.0.615684286831.issue9217@psf.upfronthosting.co.za>
Message-ID: <1283618508.22.0.881045082834.issue9217@psf.upfronthosting.co.za>


Jeremy Thurgood <firxen at gmail.com> added the comment:

This seems to be fixed in 3.2 and the 2.7 maintenance branch, but here's a (one-liner) patch for people who want to fix their local installations.

----------
keywords: +patch
nosy: +jerith
Added file: http://bugs.python.org/file18750/2to3_log_fix.patch

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

From report at bugs.python.org  Sat Sep  4 19:16:03 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 04 Sep 2010 17:16:03 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283620563.62.0.691642788903.issue9732@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Sat Sep  4 19:27:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 17:27:52 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do
	not	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1283621272.04.0.0600256059758.issue7736@psf.upfronthosting.co.za>


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

Committed in r84489 (3.x), r84490 (3.1) and r84491 (2.7). Thank you!

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

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

From report at bugs.python.org  Sat Sep  4 19:29:42 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 17:29:42 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283618350.03.0.086188747558.issue9775@psf.upfronthosting.co.za>
Message-ID: <4C828203.3040903@v.loewis.de>


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

> As mentioned above I cannot provide more information because I am
> unable to find the root of the issue.  All I know is that if the
> atexit handler is executed after the module globals were set to None
> it fails to shutdown properly.

Ok - but this is not supposed to happen. The exitfuncs are called
*before* any other interpreter shutdown happens.

> 
> The old monkey patch can be found here:
> http://svn.python.org/view/python/tags/r261/Lib/multiprocessing/util.py?revision=71601&view=markup
>
>  I am pretty sure that this is one way to trigger the issue but by
> itself not the root of the problem.

Indeed, this is not part of Python anymore, so we should remove it from
the discussion.

In any case, unless you can come up with a reproducible test case,
I'm closing this as "works for me".

----------

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

From report at bugs.python.org  Sat Sep  4 19:31:31 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 17:31:31 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1283621491.44.0.116956229232.issue9775@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


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

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

From report at bugs.python.org  Sat Sep  4 19:34:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 17:34:43 +0000
Subject: [issue9581] PosixGroupsTester fails as root
In-Reply-To: <1281646042.28.0.438449918806.issue9581@psf.upfronthosting.co.za>
Message-ID: <1283621683.79.0.315643865038.issue9581@psf.upfronthosting.co.za>


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

I've committed modified patches for 3.x, 3.1 and 2.7. Thanks again George.

----------
assignee: ronaldoussoren -> nobody
nosy: +nobody
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 2.6

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

From report at bugs.python.org  Sat Sep  4 19:53:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 17:53:17 +0000
Subject: [issue1100562] deepcopying listlike and dictlike objects
Message-ID: <1283622797.94.0.555928845497.issue1100562@psf.upfronthosting.co.za>


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

Committed in r84495 (3.x), r84498 (3.1), r84499 (2.7). Thank you!

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

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

From report at bugs.python.org  Sat Sep  4 20:10:18 2010
From: report at bugs.python.org (David Watson)
Date: Sat, 04 Sep 2010 18:10:18 +0000
Subject: [issue9777] test_socket.GeneralModuleTests.test_idna should require
	the "network" resource
In-Reply-To: <1283623818.68.0.121585037056.issue9777@psf.upfronthosting.co.za>
Message-ID: <1283623818.68.0.121585037056.issue9777@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

This test requires network access as it tries to resolve a domain name at python.org.  Patch attached.

----------
components: Tests
files: idna-test-resource.diff
keywords: patch
messages: 115593
nosy: baikie
priority: normal
severity: normal
status: open
title: test_socket.GeneralModuleTests.test_idna should require the "network" resource
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18751/idna-test-resource.diff

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

From report at bugs.python.org  Sat Sep  4 20:14:07 2010
From: report at bugs.python.org (Arnaud Delobelle)
Date: Sat, 04 Sep 2010 18:14:07 +0000
Subject: [issue9717] operator module - "in place" operators documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1283624047.97.0.345207248895.issue9717@psf.upfronthosting.co.za>


Arnaud Delobelle <arnodel at googlemail.com> added the comment:

Terry: I agree that augmented assignement should be described better in the language reference.  I guess that would warrant opening another issue?

However I tend to think that the term "in-place operation" is a good one.

BTW:

- the reference of "(See section Primaries for the syntax definitions for the last three symbols.)" is probably there to point to the definition of what can go on the left side of the augmented assignement symbol (what used to be called an "lvalue")

- "With the exception of assigning to tuples ": this refers to the fact that whereas x, y, z = l is correct syntax, x, y, z += l isn't.

Raymond: I agree that the operator doc would be clearer if better structured.

So I put forward another patch to operator.rst, structuring it more clearly and providing a more detailed introduction to the "In-place operations" section, but not trying to detail the workings of augmented assignement in general.

----------
Added file: http://bugs.python.org/file18752/operator_structured.diff

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

From report at bugs.python.org  Sat Sep  4 20:19:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 18:19:25 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1283624365.52.0.618634514921.issue8372@psf.upfronthosting.co.za>


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

With the patches applied except linux-pass-unterminated.diff, I get the following test failure:

======================================================================
ERROR: testMaxPathLen (test.test_socket.TestLinuxPathLen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_socket.py", line 1435, in testMaxPathLen
    self.sock.bind(path)
socket.error: AF_UNIX path too long

I guess this test should simply removed.
In any case, here is an up-to-date patch against 3.x.

----------
nosy: +pitrou
Added file: http://bugs.python.org/file18753/issue8372.patch

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

From report at bugs.python.org  Sat Sep  4 20:24:21 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 04 Sep 2010 18:24:21 +0000
Subject: [issue9766] warnings has "onceregistry" and "once_registry"
In-Reply-To: <1283546935.08.0.780554208103.issue9766@psf.upfronthosting.co.za>
Message-ID: <1283624661.98.0.522256761296.issue9766@psf.upfronthosting.co.za>


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

r84500

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

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

From report at bugs.python.org  Sat Sep  4 20:31:25 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 04 Sep 2010 18:31:25 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1283625085.5.0.120084991524.issue9775@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Put the stuff from an older version back in with a monkeypatch and you will see the issue again.  There are certainly many more ways to trigger that issue, that was just the easiest.  I will try to create a simpler test case.

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

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

From report at bugs.python.org  Sat Sep  4 20:31:59 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Sep 2010 18:31:59 +0000
Subject: [issue9717] operator module - "in place" operators documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1283625119.52.0.537123069419.issue9717@psf.upfronthosting.co.za>


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

Since Raymond has grabbed this, I will let him decide on its scope.
I agree with sectioning the operator doc and intended to suggest that.

The term 'in-place operation' is fine when accurate. The term 'in-place operator', which is what you wrote and what I criticized, is not as it is never accurate and has confused and mislead people. For one thing, it leads them to forget that augmented assignment statements are statements that *always* do an assignment. For another, they forget that the operation can only be in-place for mutables. That is my observation based on years of reading c.l.p./python-list. An 'in-place operator' would do an operation in-place without any assighment and would only work for mutables. Python has neither operators nor functions nor syntax with those characteristics.

----------

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

From report at bugs.python.org  Sat Sep  4 20:40:57 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 04 Sep 2010 18:40:57 +0000
Subject: [issue788931] resolving relative paths for external entities with
	xml.sax
Message-ID: <1283625657.31.0.914583728504.issue788931@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg114256.

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

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

From report at bugs.python.org  Sat Sep  4 20:42:18 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 04 Sep 2010 18:42:18 +0000
Subject: [issue837046] pyport.h redeclares gethostname() if SOLARIS is defined
Message-ID: <1283625738.18.0.475384557489.issue837046@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg114296.

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

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

From report at bugs.python.org  Sat Sep  4 20:43:00 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 04 Sep 2010 18:43:00 +0000
Subject: [issue902151] Thread start - strange error under Cygwin
Message-ID: <1283625780.01.0.391103799303.issue902151@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg114327.

----------
status: pending -> open

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

From report at bugs.python.org  Sat Sep  4 20:43:42 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 04 Sep 2010 18:43:42 +0000
Subject: [issue1015254] Create cgi.FieldStorage._get_new_instance method as
	factory
Message-ID: <1283625822.11.0.544737010023.issue1015254@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg114373.

----------
status: pending -> open

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

From report at bugs.python.org  Sat Sep  4 20:44:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 18:44:20 +0000
Subject: [issue9225] Replace DUP_TOPX with DUP_TOP_TWO
In-Reply-To: <1278874181.81.0.745105188712.issue9225@psf.upfronthosting.co.za>
Message-ID: <1283625860.23.0.528645531198.issue9225@psf.upfronthosting.co.za>


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

Modified patch committed in r84501. Thanks!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: performance -> resource usage

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

From report at bugs.python.org  Sat Sep  4 20:44:34 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 04 Sep 2010 18:44:34 +0000
Subject: [issue1058305] HTMLParser.locatestartagend regex too stringent
Message-ID: <1283625874.97.0.601816213303.issue1058305@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg114390.

----------
status: pending -> open

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

From report at bugs.python.org  Sat Sep  4 20:45:53 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 04 Sep 2010 18:45:53 +0000
Subject: [issue1103350] send/recv SEGMENT_SIZE should be used more in
	socketmodule
Message-ID: <1283625953.7.0.785588440581.issue1103350@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg114485.

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

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

From report at bugs.python.org  Sat Sep  4 20:46:44 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 04 Sep 2010 18:46:44 +0000
Subject: [issue902151] Thread start - strange error under Cygwin
Message-ID: <1283626004.39.0.465368168292.issue902151@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


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

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

From report at bugs.python.org  Sat Sep  4 20:47:02 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 04 Sep 2010 18:47:02 +0000
Subject: [issue1015254] Create cgi.FieldStorage._get_new_instance method as
	factory
Message-ID: <1283626022.83.0.940481901445.issue1015254@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


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

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

From report at bugs.python.org  Sat Sep  4 20:47:21 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 04 Sep 2010 18:47:21 +0000
Subject: [issue1058305] HTMLParser.locatestartagend regex too stringent
Message-ID: <1283626041.12.0.782127325429.issue1058305@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


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

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

From report at bugs.python.org  Sat Sep  4 20:48:46 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 18:48:46 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated
	AF_UNIX	addresses
In-Reply-To: <1283624365.52.0.618634514921.issue8372@psf.upfronthosting.co.za>
Message-ID: <4C82948B.9060909@v.loewis.de>


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

> I guess this test should simply removed.

(not sure which test you are referring to: the test case, or the
test for too long path names:) I think both tests need to stay.

Instead, I think that testMaxPathLen is incorrect: it doesn't
take into account the terminating NUL, which also must fit
into the 108 bytes (IIUC). baikie: why did the test pass for
you?

----------
title: socket: Buffer overrun while reading unterminated AF_UNIX addresses -> socket: Buffer overrun while reading unterminated AF_UNIX	addresses

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

From report at bugs.python.org  Sat Sep  4 20:51:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 18:51:16 +0000
Subject: [issue9777] test_socket.GeneralModuleTests.test_idna should require
	the "network" resource
In-Reply-To: <1283623818.68.0.121585037056.issue9777@psf.upfronthosting.co.za>
Message-ID: <1283626276.11.0.847293647187.issue9777@psf.upfronthosting.co.za>


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

Fixed in r84504, thank you!

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Sep  4 20:54:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 18:54:27 +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: <1283626467.51.0.225066124918.issue9771@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/issue9771>
_______________________________________

From report at bugs.python.org  Sat Sep  4 20:59:24 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 04 Sep 2010 18:59:24 +0000
Subject: [issue9762] build failures
In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>
Message-ID: <1283626764.56.0.421196951775.issue9762@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/issue9762>
_______________________________________

From report at bugs.python.org  Sat Sep  4 21:07:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Sep 2010 19:07:15 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1283627235.8.0.430715292937.issue9775@psf.upfronthosting.co.za>


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

I don't see the issue at all; the attached script runs just fine.

----------
Added file: http://bugs.python.org/file18754/t.py

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

From report at bugs.python.org  Sat Sep  4 21:08:39 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 04 Sep 2010 19:08:39 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1283627319.81.0.065229009432.issue9630@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/issue9630>
_______________________________________

From report at bugs.python.org  Sat Sep  4 21:26:17 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 04 Sep 2010 19:26:17 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1283628377.12.0.268361458051.issue9769@psf.upfronthosting.co.za>


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

2 remarks: 
- PyUnicode_FromFormat("%s", text) expects a utf-8 buffer.
- Very recently (r84472, r84485), some C files of CPython source code were converted to utf-8.  And most of the time, the format given to PyUnicode_FromFormat is a string literal.

So it would make sense for PyUnicode_FromFormat to consider the format string as encoded in utf-8.  This is worth asking on python-dev though.

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

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

From report at bugs.python.org  Sat Sep  4 21:31:22 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 04 Sep 2010 19:31:22 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1283628682.72.0.480727372132.issue9630@psf.upfronthosting.co.za>


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

> Python is installed in a directory called b'py3k\xc3\xa9'
> and your locale is C
Do we really want to support this kind of configuration?

----------

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

From report at bugs.python.org  Sat Sep  4 22:12:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 20:12:47 +0000
Subject: [issue7451] improve json decoding performance
In-Reply-To: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>
Message-ID: <1283631167.25.0.141505775006.issue7451@psf.upfronthosting.co.za>


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

Updated patch against py3k.

----------
stage: patch review -> commit review
versions:  -Python 2.7
Added file: http://bugs.python.org/file18755/json-opts4.patch

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

From report at bugs.python.org  Sat Sep  4 22:17:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 20:17:13 +0000
Subject: [issue7451] improve json decoding performance
In-Reply-To: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>
Message-ID: <1283631433.14.0.483002145443.issue7451@psf.upfronthosting.co.za>


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

Committed in r84505.

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

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

From report at bugs.python.org  Sat Sep  4 22:26:03 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 04 Sep 2010 20:26:03 +0000
Subject: [issue9129] DoS smtpd module vulnerability
In-Reply-To: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>
Message-ID: <1283631963.65.0.896443881542.issue9129@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Security fixes are allowed in 2.6 branch, so could you backport the fix also to 2.6 branch?

----------
versions: +Python 2.6

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

From report at bugs.python.org  Sat Sep  4 22:33:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 20:33:54 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283632434.57.0.159211584373.issue9754@psf.upfronthosting.co.za>


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

Updated patch so that the tests pass with -Werror.
Do you think this should be committed before the next alpha?

----------
Added file: http://bugs.python.org/file18756/assertwarns2.patch

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

From report at bugs.python.org  Sat Sep  4 22:48:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 20:48:18 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated
	AF_UNIX	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1283633298.45.0.00628307713651.issue8372@psf.upfronthosting.co.za>


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

> baikie: why did the test pass for you?

The test passes (I assume) if linux-pass-unterminated.diff is applied. The latter patch is only meant to exhibit the issue, though, not to be checked in.

----------

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

From report at bugs.python.org  Sat Sep  4 23:25:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 21:25:51 +0000
Subject: [issue8734] msvcrt get_osfhandle crash on bad FD
In-Reply-To: <1274034133.01.0.249446827178.issue8734@psf.upfronthosting.co.za>
Message-ID: <1283635551.2.0.717377210537.issue8734@psf.upfronthosting.co.za>


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

Ok, I've committed the patch in r84506 (3.x), r84507 (3.1) and r84508 (2.7). Thank you!

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

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

From report at bugs.python.org  Sun Sep  5 00:11:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 22:11:31 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Currently, Python produces hash values with fit in a C "long". This is fine at first sight, but in the context of dict and set implementations, it means that
1) holding hashes and indices in the same field of a structure requires some care (see issue1646068)
2) on platforms where a long is smaller than a Py_ssize_t (e.g. Win64), very big hash tables could suffer from lots of artificial collisions (the hash table being bigger than the range of possible hash values)
3) when a long is smaller than Py_ssize_t, we don't save any size anyway, since having some pointers follow a C "long" in a structure implies some padding to keep all fields naturally aligned

A future-proof option would be to change all hash values to be of Py_ssize_t values rather than C longs. Either directly, or by defining a new dedicated alias Py_hash_t. This would also impact the ABI, I suppose.

----------
components: Interpreter Core
messages: 115617
nosy: belopolsky, georg.brandl, jimjjewett, ked-tao, loewis, mark.dickinson, pitrou, rhettinger, tim_one
priority: normal
severity: normal
status: open
title: Make hash values the same width as a pointer (or Py_ssize_t)
type: feature request
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Sep  5 00:12:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 22:12:42 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1283638362.94.0.53061666956.issue9778@psf.upfronthosting.co.za>


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

As an example of padding behaviour (under Win64 with 32-bit longs and 64-bit pointers):

Python 3.2a1+ (py3k, Sep  4 2010, 22:50:10) [MSC v.1500 64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.calcsize("l")
4
>>> struct.calcsize("lP")
16
>>> struct.calcsize("lPP")
24

----------

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

From report at bugs.python.org  Sun Sep  5 00:14:41 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Sep 2010 22:14:41 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1283638481.68.0.0959672607207.issue9778@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 for PyObject_Hash returning a Py_ssize_t.

Nothing good can come from having a hash table larger than the range of a hash value.  Tests may pass but performance would degrade catastrophically.

----------

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

From report at bugs.python.org  Sun Sep  5 01:21:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 23:21:52 +0000
Subject: [issue6768] asyncore file_wrapper leaking file descriptors?
In-Reply-To: <1251061355.88.0.439878311774.issue6768@psf.upfronthosting.co.za>
Message-ID: <1283642512.65.0.369905849917.issue6768@psf.upfronthosting.co.za>


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


----------
assignee:  -> giampaolo.rodola
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Sun Sep  5 01:49:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 23:49:00 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1283644140.56.0.920059595532.issue3526@psf.upfronthosting.co.za>


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

> I guess there are not that many people running Python applications with 
> a big memory footprint on AIX or SunOS, otherwise this problem would be 
> more popular.

Not only, but integrating a big chunk of foreign code in something as critical as the memory allocation routines is not an easy decision to make. Also, the dlmalloc copy should then be regularly kept in sync with upstream.

----------

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

From report at bugs.python.org  Sun Sep  5 02:34:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 05 Sep 2010 00:34:16 +0000
Subject: [issue1397] mysteriously failing test_bsddb3 threading test in other
	threads
In-Reply-To: <1194352164.91.0.707733802252.issue1397@psf.upfronthosting.co.za>
Message-ID: <1283646856.8.0.562046612675.issue1397@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


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

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

From report at bugs.python.org  Sun Sep  5 02:34:41 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 05 Sep 2010 00:34:41 +0000
Subject: [issue5553] Py_LOCAL_INLINE(type) doesn't actually inline except
	using MSC
In-Reply-To: <1237906159.31.0.817735827451.issue5553@psf.upfronthosting.co.za>
Message-ID: <1283646881.65.0.727203271095.issue5553@psf.upfronthosting.co.za>


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

Note: autoreconf failure caused by r84379 was fixed by r84512.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sun Sep  5 04:32:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Sep 2010 02:32:48 +0000
Subject: [issue837046] pyport.h redeclares gethostname() if SOLARIS is defined
Message-ID: <1283653968.51.0.934676386354.issue837046@psf.upfronthosting.co.za>


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

I'm not sure it was appropriate to close this bug in isolation without confirmation that it is no longer a problem, but I'm also guessing that it is in fact no longer a problem due to the fix to issue 1759169.  So because that seems likely I'm leaving it closed as out of date.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sun Sep  5 04:45:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Sep 2010 02:45:07 +0000
Subject: [issue1058305] HTMLParser.locatestartagend regex too stringent
Message-ID: <1283654707.62.0.364580713008.issue1058305@psf.upfronthosting.co.za>


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

Closing this issue as out of date was inappropriate.  It may be a duplicate, but someone with an interest should go through and evaluate all the related 'tolerant HTML parser' issues.

Issue 1486713 could perhaps serve as a master issue for this set.

----------
nosy: +r.david.murray
resolution: out of date -> 
status: closed -> open

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

From report at bugs.python.org  Sun Sep  5 04:46:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Sep 2010 02:46:23 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1283654783.59.0.413621530337.issue1486713@psf.upfronthosting.co.za>


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

See also issue 1058305, which may be a duplicate.

----------

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

From report at bugs.python.org  Sun Sep  5 06:43:24 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 05 Sep 2010 04:43:24 +0000
Subject: [issue5553] Py_LOCAL_INLINE(type) doesn't actually inline except
	using MSC
In-Reply-To: <1237906159.31.0.817735827451.issue5553@psf.upfronthosting.co.za>
Message-ID: <1283661804.79.0.436011288897.issue5553@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Ned, thanks for bringing that to my attention.  I might have missed it otherwise.

I had run "autoconf" but had not known to run "autoreconf", so I had missed the failure there.  *embarrassed*

Benjamin, thanks for fixing my error!

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Sun Sep  5 08:46:11 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 05 Sep 2010 06:46:11 +0000
Subject: [issue9778] Make hash values the same width as	a pointer
	(or	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <4C833CAE.6030704@v.loewis.de>


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

> This would also impact the ABI, I suppose.

Correct. So it either needs to happen before 3.2, or wait until 4.0,
or the introduction of "wide" hashes needs to be done in a compatible
manner, likely requiring two parallel hashing infrastructures.

----------
title: Make hash values the same width as a pointer (or Py_ssize_t) -> Make hash values the same width as	a pointer (or	Py_ssize_t)

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

From report at bugs.python.org  Sun Sep  5 09:06:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 07:06:07 +0000
Subject: [issue9767] Failures in json doc examples
In-Reply-To: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>
Message-ID: <1283670367.77.0.0539087271816.issue9767@psf.upfronthosting.co.za>


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

FWIW if something is fixed, it should be the json output.  However, I can imagine (without looking at the code) that this would mean a lot of special casing.

----------

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

From report at bugs.python.org  Sun Sep  5 09:08:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 07:08:55 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1283670535.83.0.239791130054.issue9775@psf.upfronthosting.co.za>


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

I'll sort this out with Armin.

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

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

From report at bugs.python.org  Sun Sep  5 09:12:14 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 07:12:14 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1283670734.43.0.717923777252.issue9775@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> georg.brandl
priority: normal -> high
versions: +Python 3.2 -Python 2.6

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

From report at bugs.python.org  Sun Sep  5 09:14:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 07:14:49 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1283670889.62.0.542256727279.issue9662@psf.upfronthosting.co.za>


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

I don't think this should block 3.2a2.

+1 for supporting LLVM in general.  BTW, why doesn't it build because of warnings?

----------
nosy: +georg.brandl
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Sun Sep  5 09:36:10 2010
From: report at bugs.python.org (gkraser)
Date: Sun, 05 Sep 2010 07:36:10 +0000
Subject: [issue9779] argparse.ArgumentParser not support unicode in print help
In-Reply-To: <1283672170.42.0.322683308746.issue9779@psf.upfronthosting.co.za>
Message-ID: <1283672170.42.0.322683308746.issue9779@psf.upfronthosting.co.za>


New submission from gkraser <gkraser at gmail.com>:

argparse.ArgumentParser not support unicode in print help.

Example:

# -*- coding: utf-8 -*-
import argparse
import unittest

class Test1(unittest.TestCase):
    def test_unicode_desc(self):
        h = u'Rus ???'      # unicode
        print h             # ok
        parser = argparse.ArgumentParser(description=h)
        parser.print_help() # error

----------
components: Library (Lib)
files: test_ap.py
messages: 115630
nosy: gkraser
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser not support unicode in print help
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file18757/test_ap.py

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

From report at bugs.python.org  Sun Sep  5 09:43:12 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 05 Sep 2010 07:43:12 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1283672592.49.0.542865024997.issue9662@psf.upfronthosting.co.za>


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

It's not just LLVM.  Building a standard OS X installer on OS X 10.5 or 10.6 (gcc-4.0, 10.4u SDK, i386/ppc, deployment target=10.3), _ctypes fails:

*** WARNING: renaming "_ctypes" since importing it failed: dlopen(build/lib.macosx-10.3-fat-3.2/_ctypes.so, 2): Symbol not found: _ffi_closure_alloc

That is definitely a regression.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sun Sep  5 09:48:01 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 05 Sep 2010 07:48:01 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1283672881.37.0.508854912645.issue9662@psf.upfronthosting.co.za>


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

It's not just LLVM.  Building a standard OS X installer on OS X 10.5 (gcc-4.0, 10.4u SDK, i386/ppc, deployment target=10.3) or 10.6 (gcc-4.2, 10.6 SDK, i386/x86_64, dept target 10.6), _ctypes fails:

*** WARNING: renaming "_ctypes" since importing it failed: dlopen(build/lib.macosx-10.3-fat-3.2/_ctypes.so, 2): Symbol not found: _ffi_closure_alloc

That is definitely a regression.

----------

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

From report at bugs.python.org  Sun Sep  5 09:48:07 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 05 Sep 2010 07:48:07 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1283672887.5.0.520620174269.issue9662@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg115631

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

From report at bugs.python.org  Sun Sep  5 10:11:28 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 08:11:28 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1283674288.57.0.606649968054.issue9662@psf.upfronthosting.co.za>


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

OK.  Assigning to Ronald for now; he'll have to deal with it when building the binaries anyway.

----------
assignee: theller -> ronaldoussoren
nosy: +ronaldoussoren

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

From report at bugs.python.org  Sun Sep  5 10:12:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 08:12:58 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1283674378.9.0.182349528652.issue9437@psf.upfronthosting.co.za>


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

Patch looks like it at least can't make things worse to me.  linker_exe should probably also get LDFLAGS (but not LDSHARED).

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

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

From report at bugs.python.org  Sun Sep  5 10:14:10 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 08:14:10 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1283674450.34.0.316795823176.issue9116@psf.upfronthosting.co.za>


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

Once again, this is not important enough block 3.2a2.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Sun Sep  5 10:15:04 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 08:15:04 +0000
Subject: [issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning
	correctly in Python 2.7
In-Reply-To: <1276153559.93.0.766128008061.issue8959@psf.upfronthosting.co.za>
Message-ID: <1283674504.67.0.765834268658.issue8959@psf.upfronthosting.co.za>


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

Deferring for 3.2a2.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Sun Sep  5 10:16:00 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 08:16:00 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1283674560.11.0.286656962989.issue8611@psf.upfronthosting.co.za>


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

The Unicode import system won't be put in place before 3.2a2, deferring.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Sun Sep  5 10:16:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 08:16:32 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1283674592.89.0.169448938453.issue9437@psf.upfronthosting.co.za>


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

It is however not important enough to block 3.2a2.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Sun Sep  5 13:12:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Sep 2010 11:12:54 +0000
Subject: [issue9778] Make hash values the same width as	a pointer
	(or	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1283685174.27.0.655606349586.issue9778@psf.upfronthosting.co.za>


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

> Correct. So it either needs to happen before 3.2, or wait until 4.0,

Shouldn't there be a provision for ABI versioning?
Or do you suggest bumping to the next major number (4.0, 5.0...) be done on the basis of ABI changes?

----------

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

From report at bugs.python.org  Sun Sep  5 13:37:36 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 05 Sep 2010 11:37:36 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1283686656.31.0.487995485992.issue9437@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

This was broken in r83837 with a patch for issue #5504.

----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Sun Sep  5 13:39:34 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 05 Sep 2010 11:39:34 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1283686774.0.0.745514528417.issue9437@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
Removed message: http://bugs.python.org/msg115640

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

From report at bugs.python.org  Sun Sep  5 13:40:11 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 05 Sep 2010 11:40:11 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1283686811.36.0.405697841512.issue9662@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

This was broken in r83837 with a patch for issue #5504.

----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Sun Sep  5 13:53:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Sep 2010 11:53:44 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1283687624.96.0.466318361659.issue9437@psf.upfronthosting.co.za>


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

Other patch, fixes all failures.

----------
Added file: http://bugs.python.org/file18758/m32-2.patch

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

From report at bugs.python.org  Sun Sep  5 14:49:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Sep 2010 12:49:02 +0000
Subject: [issue3978] ZipFileExt.read() can be incredibly slow; patch included
In-Reply-To: <1222457019.27.0.267576306603.issue3978@psf.upfronthosting.co.za>
Message-ID: <1283690942.56.0.905412739576.issue3978@psf.upfronthosting.co.za>


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

The patch has been outdated by other independent performance work on the zipfile module. In Python 3.2, the zipfile module is actually slightly faster than the "unzip" program:

- first with the supplied "zeroes.zip" file:

$ rm -f zeroes && time -p unzip -e zeroes.zip
Archive:  zeroes.zip
  inflating: zeroes                  
real 0.56
user 0.50
sys 0.06

$ time -p ./python -m zipfile -e zeroes.zip .
real 0.45
user 0.34
sys 0.10

- Then with a 100MB random file:

$ rm -f random && time -p unzip -e random.zip
Archive:  random.zip
  inflating: random                  
real 0.69
user 0.61
sys 0.07

$ rm -f random && time -p ./python -m zipfile -e random.zip .
real 0.33
user 0.18
sys 0.14

----------
resolution:  -> out of date
status: open -> closed
versions: +Python 3.2 -Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Sep  5 14:59:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Sep 2010 12:59:27 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1283691567.81.0.999991875536.issue4941@psf.upfronthosting.co.za>


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

The whole approach doesn't seem to bear much fruit. I tried to apply again likely_decref.diff and got a 0% performance change on 3.2 (on a Core i3 processor).

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Sun Sep  5 15:08:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Sep 2010 13:08:45 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <1283692125.2.0.216476623034.issue4194@psf.upfronthosting.co.za>


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

The subprocess doc now has a note about buffering and performance issues, closing.

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

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

From report at bugs.python.org  Sun Sep  5 15:38:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Sep 2010 13:38:51 +0000
Subject: [issue1568] PATCH: Armin's attribute lookup caching for 3.0
In-Reply-To: <1197034097.09.0.871896219058.issue1568@psf.upfronthosting.co.za>
Message-ID: <1283693931.8.0.0581995311492.issue1568@psf.upfronthosting.co.za>


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

Closing: Neil's algorithm is not different from what is already in 3.2, except for the additional type_attrcache_callback() which probably doesn't make a difference in normal workloads.

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

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

From report at bugs.python.org  Sun Sep  5 15:44:46 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 05 Sep 2010 13:44:46 +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: <1283694286.89.0.107146705576.issue5504@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixing the alloc_closure error is easy enough:


Index: ../setup.py
===================================================================
--- ../setup.py	(revision 84528)
+++ ../setup.py	(working copy)
@@ -1653,7 +1653,9 @@
                    '_ctypes/callbacks.c',
                    '_ctypes/callproc.c',
                    '_ctypes/stgdict.c',
-                   '_ctypes/cfield.c']
+                   '_ctypes/cfield.c',
+                   '_ctypes/malloc_closure.c',
+                   ]
         depends = ['_ctypes/ctypes.h']
 
         if sys.platform == 'darwin':


That's not enough to make it possible to build ctypes on OSX though, I now get the same error for a different symbol:


*** WARNING: renaming "_ctypes" since importing it failed: dlopen(build/lib.macosx-10.6-fat-3.2/_ctypes.so, 2): Symbol not found: _ffi_prep_closure_loc
  Referenced from: /Users/ronald/Projects/python/python-3.x/build/build/lib.macosx-10.6-fat-3.2/_ctypes.so
  Expected in: flat namespace
 in /Users/ronald/Projects/python/python-3.x/build/build/lib.macosx-10.6-fat-3.2/_ctypes.so

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Sun Sep  5 15:46:50 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 05 Sep 2010 13:46:50 +0000
Subject: [issue5504] ctypes should work with systems where mmap can't
	be	PROT_WRITE and PROT_EXEC
In-Reply-To: <1283694286.89.0.107146705576.issue5504@psf.upfronthosting.co.za>
Message-ID: <5CE08FA9-367C-48A5-8EF9-E1700DFB7ED6@langa.pl>


??ukasz Langa <lukasz at langa.pl> added the comment:

Please find attached a "fix" for #9662. Some explanation is in order:

- the Windows, Linux and OS X implementations of FFI included in the SVN are different in terms of maturity
- Thomas originally when fixing #5504 used a bit of functionality regarding closures that wasn't there in the Windows and OS X versions
- he did some dirty hacking on the Windows version to make it work: changed the ffi_prep_closure function header to ffi_prep_closure_loc (leaving the old implementation) and introduced names for ffi_closure_alloc and ffi_closure_free
- he didn't touch the OS X version so it failed

I did more-less the same thing but in case of OS X we have many ffi_prep_closure implementations for different archs so I simply did an #ifdef in the place ffi_prep_closure is used.

I think a better solution ultimately would be to update all implementation to FFI 3.0.9 and be done with it. Still, the current patch works for me.

----------
Added file: http://bugs.python.org/file18759/issue9662.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5504>
_______________________________________
-------------- next part --------------
Index: setup.py
===================================================================
--- setup.py	(revision 84528)
+++ setup.py	(working copy)
@@ -1657,6 +1657,7 @@
         depends = ['_ctypes/ctypes.h']
 
         if sys.platform == 'darwin':
+            sources.append('_ctypes/malloc_closure.c')
             sources.append('_ctypes/darwin/dlfcn_simple.c')
             extra_compile_args.append('-DMACOSX')
             include_dirs.append('_ctypes/darwin')
Index: Modules/_ctypes/libffi_osx/include/ffi.h
===================================================================
--- Modules/_ctypes/libffi_osx/include/ffi.h	(revision 84528)
+++ Modules/_ctypes/libffi_osx/include/ffi.h	(working copy)
@@ -264,6 +264,9 @@
 	void			(*fun)(ffi_cif*,void*,void**,void*),
 	void*			user_data);
 
+void ffi_closure_free(void *);
+void *ffi_closure_alloc (size_t size, void **code);
+
 typedef struct ffi_raw_closure {
 	char		tramp[FFI_TRAMPOLINE_SIZE];
 	ffi_cif*	cif;
@@ -349,4 +352,4 @@
 }
 #endif
 
-#endif	// #ifndef LIBFFI_H
\ No newline at end of file
+#endif	// #ifndef LIBFFI_H
Index: Modules/_ctypes/malloc_closure.c
===================================================================
--- Modules/_ctypes/malloc_closure.c	(revision 84528)
+++ Modules/_ctypes/malloc_closure.c	(working copy)
@@ -106,7 +106,6 @@
         return NULL;
     item = free_list;
     free_list = item->next;
-	*codeloc = (void *)item;
+    *codeloc = (void *)item;
     return (void *)item;
 }
-
Index: Modules/_ctypes/callbacks.c
===================================================================
--- Modules/_ctypes/callbacks.c	(revision 84528)
+++ Modules/_ctypes/callbacks.c	(working copy)
@@ -416,9 +416,13 @@
                      "ffi_prep_cif failed with %d", result);
         goto error;
     }
+#if defined(X86_DARWIN) || defined(POWERPC_DARWIN)
+    result = ffi_prep_closure(p->pcl_write, &p->cif, closure_fcn, p);
+#else
     result = ffi_prep_closure_loc(p->pcl_write, &p->cif, closure_fcn,
 				  p,
 				  p->pcl_exec);
+#endif
     if (result != FFI_OK) {
         PyErr_Format(PyExc_RuntimeError,
                      "ffi_prep_closure failed with %d", result);

From report at bugs.python.org  Sun Sep  5 15:50:57 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 05 Sep 2010 13:50:57 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1283694657.47.0.898501814817.issue9662@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm looking into this issue.

One problem is that the version of libffi used on OSX is no longer in sync with the version that is used on other platforms. The version that is used on OSX does not have some of the symbols expected by ctypes, such as 'ffi_prep_closure_loc'.

----------

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

From report at bugs.python.org  Sun Sep  5 15:52:01 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 05 Sep 2010 13:52:01 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1283694721.6.0.844762004384.issue9662@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Ronald, please see #5504.

----------

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

From report at bugs.python.org  Sun Sep  5 15:58:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Sep 2010 13:58:09 +0000
Subject: [issue1677872] Efficient reverse line iterator
Message-ID: <1283695089.91.0.137350047154.issue1677872@psf.upfronthosting.co.za>


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

Suggestions:

- do it on BufferedReader, rather than TextIOWrapper: if you want full-speed scanning of log files, you probably want to open them in binary mode

- rather than implementing a full-blown iterator, you can start with simple primitives: e.g. a method called readprevline() (or even scan_back() if you want to make the stop character(s) configurable)

----------

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

From report at bugs.python.org  Sun Sep  5 16:19:28 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 05 Sep 2010 14:19:28 +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: <1283696368.08.0.417977335434.issue5504@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

?ukasz' patch fixes the issue for me.

As the patch only affects code-paths used on OSX (patches to the libffi version for OSX and an #ifdef that makes OSX use ffi_prep_closure instead of ffi_prep_closure_loc) I intend to commit the patch later today to be able to build a working copy of the OSX installer for the next alpha release.

I'm at best -0 on moving all platforms to libffi 3.0.9. 'libffi_osx' works properly on OSX and I have no idea whether all changes in that fork of libffi have been merged back into the canonical version.

----------

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

From report at bugs.python.org  Sun Sep  5 16:20:15 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 05 Sep 2010 14:20:15 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1283696415.71.0.749597996146.issue9662@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Thanks! That patch fixes the issue for me and I will commit it later today.

----------

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

From report at bugs.python.org  Sun Sep  5 17:33:55 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 05 Sep 2010 15:33:55 +0000
Subject: [issue1677872] Efficient reverse line iterator
Message-ID: <1283700835.89.0.417133983419.issue1677872@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Sun Sep  5 17:42:26 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 05 Sep 2010 15:42:26 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1283701346.49.0.876384181149.issue5412@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


Removed file: http://bugs.python.org/file18441/issue5412.diff

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

From report at bugs.python.org  Sun Sep  5 17:45:21 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 05 Sep 2010 15:45:21 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1283701521.04.0.351319962472.issue5412@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Patch updated to avoid fuzzes from other commits.

----------
Added file: http://bugs.python.org/file18760/issue5412.diff

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

From report at bugs.python.org  Sun Sep  5 18:37:19 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Sun, 05 Sep 2010 16:37:19 +0000
Subject: [issue9778] Make hash values the same width as	a pointer
	(or	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1283704639.45.0.0350037184166.issue9778@psf.upfronthosting.co.za>


Changes by Case Van Horsen <casevh at gmail.com>:


----------
nosy: +casevh

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

From report at bugs.python.org  Sun Sep  5 18:47:39 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Sun, 05 Sep 2010 16:47:39 +0000
Subject: [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283705259.49.0.246416945725.issue9739@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I edited the doc string for math.modf since an indent of 8 spaces is used for the doc string with help(math). An indent of 4 spaces is used with help(math.modf).

I've attached a new patch for just the math module that includes the return type as part of signature line, corrects the width issues, and uses a consistent format for defining the doc strings.

----------
Added file: http://bugs.python.org/file18761/math_docstring.diff

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

From report at bugs.python.org  Sun Sep  5 18:59:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 05 Sep 2010 16:59:08 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283685174.27.0.655606349586.issue9778@psf.upfronthosting.co.za>
Message-ID: <4C83CC58.7020203@v.loewis.de>


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

Am 05.09.2010 13:12, schrieb Antoine Pitrou:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> Correct. So it either needs to happen before 3.2, or wait until 4.0,
> 
> Shouldn't there be a provision for ABI versioning?

There is certainly support for ABI versioning; the ABI version defined
in the PEP is called "python3.dll".

> Or do you suggest bumping to the next major 
> number (4.0, 5.0...) be done on the basis of ABI changes?

No, vice versa. The PEP promises that the ABI won't change until Python
4. For any change that might break the ABI, either a
backwards-compatible solution needs to be found, or the change be
deferred to Python 4.

----------
title: Make hash values the same width as	a pointer (or	Py_ssize_t) -> Make hash values the same width as	a pointer	(or Py_ssize_t)

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

From report at bugs.python.org  Sun Sep  5 19:03:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 17:03:23 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1283706203.07.0.878283074739.issue9778@psf.upfronthosting.co.za>


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

I would suggest making this change before the ABI freeze starts, then.

----------

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

From report at bugs.python.org  Sun Sep  5 19:07:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 17:07:36 +0000
Subject: [issue9747] os.getresgid() documentation mentions "user ids",
	not "group ids"
In-Reply-To: <1283479568.94.0.540639670687.issue9747@psf.upfronthosting.co.za>
Message-ID: <1283706456.78.0.965545409697.issue9747@psf.upfronthosting.co.za>


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

Thanks, fixed in r84530.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Sep  5 19:09:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 17:09:27 +0000
Subject: [issue9776] Inconsistent spacing in fcntl.fcntl docstring
In-Reply-To: <1283615828.17.0.964870505124.issue9776@psf.upfronthosting.co.za>
Message-ID: <1283706567.89.0.0325978378124.issue9776@psf.upfronthosting.co.za>


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

Thanks, applied in r84531.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Sep  5 19:42:19 2010
From: report at bugs.python.org (Alan McIntyre)
Date: Sun, 05 Sep 2010 17:42:19 +0000
Subject: [issue9720] zipfile writes incorrect local file header for large
	files in zip64
In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za>
Message-ID: <1283708539.03.0.0845807834942.issue9720@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

Thanks for the patch, Craig; I should have some time later today or tomorrow to do a review.  Did you have a patch for the test suite(s) as well?  If not, I can just make sure your test case is covered in test_zipfile64.

----------

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

From report at bugs.python.org  Sun Sep  5 19:48:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Sep 2010 17:48:05 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1283708885.37.0.901716381828.issue9437@psf.upfronthosting.co.za>


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

I agree with Georg: The patch seems not to make things worse, and if it makes the tests pass, I think it should be committed. Antoine, you decide if you want to commit it now or wait for Tarek?s review.

----------

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

From report at bugs.python.org  Sun Sep  5 19:53:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Sep 2010 17:53:01 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1283708885.37.0.901716381828.issue9437@psf.upfronthosting.co.za>
Message-ID: <1283709176.3545.8.camel@localhost.localdomain>


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

> I agree with Georg: The patch seems not to make things worse, and if
> it makes the tests pass, I think it should be committed. Antoine, you
> decide if you want to commit it now or wait for Tarek?s review.

Well, ideally, someone should have knowledge of what is precisely needed
for these configuration variables. Otherwise the overall robustness of
distutils and friends won't really progress.

----------

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

From report at bugs.python.org  Sun Sep  5 20:01:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Sep 2010 18:01:54 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1283709714.51.0.184501300689.issue9437@psf.upfronthosting.co.za>


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

I agree. This expert is not me, and my reply was only pragmatic.

Martin: This is a bug about LDSHARED vs. LDFLAGS vs. PY_LDFLAGS vs. CONFIGURE_LDFLAGS. Could you maybe shed some light about the difference between these configure variables and review the small patch made by Antoine? Thanks.

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

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

From report at bugs.python.org  Sun Sep  5 20:03:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Sep 2010 18:03:52 +0000
Subject: [issue9217] 2to3 crashes with some doctests
In-Reply-To: <1278790070.07.0.615684286831.issue9217@psf.upfronthosting.co.za>
Message-ID: <1283709832.85.0.697160126624.issue9217@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Sep  5 20:11:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Sep 2010 18:11:02 +0000
Subject: [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>
Message-ID: <1283710262.29.0.74439675254.issue9761@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18734/unnamed

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

From report at bugs.python.org  Sun Sep  5 20:11:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Sep 2010 18:11:04 +0000
Subject: [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>
Message-ID: <1283710264.89.0.0187165400195.issue9761@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18735/unnamed

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

From report at bugs.python.org  Sun Sep  5 20:15:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Sep 2010 18:15:05 +0000
Subject: [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>
Message-ID: <1283710505.16.0.454287734073.issue9761@psf.upfronthosting.co.za>


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

Can you reproduce the bug with a newer Python? 2.6 only gets security fixes now, bug fixes go into stable (2.7 and 3.1) and active (3.2) versions.

(Minor remarks: Could you set up your email client not to send HTML email to the tracker? It creates unnamed files which are useless and distracting. Also, kindly strip email quotes before sending. Top-posting hinders readability. Thanks in advance, and thanks for the bug report.)

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

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

From report at bugs.python.org  Sun Sep  5 20:15:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Sep 2010 18:15:29 +0000
Subject: [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>
Message-ID: <1283710529.01.0.737709169169.issue9761@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.6

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

From report at bugs.python.org  Sun Sep  5 20:15:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Sep 2010 18:15:52 +0000
Subject: [issue6074] .pyc files created readonly if .py file is readonly,
	python won't overwrite
In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za>
Message-ID: <1283710552.37.0.859695169624.issue6074@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18739/unnamed

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

From report at bugs.python.org  Sun Sep  5 20:18:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Sep 2010 18:18:49 +0000
Subject: [issue6074] .pyc files created readonly if .py file is readonly,
	python won't overwrite
In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za>
Message-ID: <1283710729.63.0.690401973236.issue6074@psf.upfronthosting.co.za>


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

Bug fixes go into 2.7 but not 2.6. See msg115664.

----------
nosy: +eric.araujo
versions:  -Python 2.6

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

From report at bugs.python.org  Sun Sep  5 20:43:28 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 05 Sep 2010 18:43:28 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1283712208.08.0.0759216826138.issue9662@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've committed the patch in #5504 in r84535 (3.2) and that fixes this issue. 

The same problem affects 2.7, I'm currently running the testsuite with the backport of this commit.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
versions: +Python 2.7

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

From report at bugs.python.org  Sun Sep  5 21:23:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Sep 2010 19:23:04 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1283714584.24.0.332924030447.issue8420@psf.upfronthosting.co.za>


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

I?m doing the backport, I?ll assign back to Raymond when the patch is ready.

----------
assignee: rhettinger -> eric.araujo
nosy: +eric.araujo
versions:  -Python 2.6

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

From report at bugs.python.org  Sun Sep  5 21:40:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 05 Sep 2010 19:40:11 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1283715611.27.0.240930951916.issue9630@psf.upfronthosting.co.za>


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

> Do we really want to support this kind of configuration?

There is also a problem is the directory name is b'py3k\xe9': at startup (utf-8 encoding), the name is decoded to 'py3k\udce9'. When the locale encoding is set to iso-8859-1: the name should be reencoded to 'py3k\xe9' to avoid the surrogate character.

----------

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

From report at bugs.python.org  Sun Sep  5 21:47:57 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 05 Sep 2010 19:47:57 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1283633298.45.0.00628307713651.issue8372@psf.upfronthosting.co.za>
Message-ID: <20100905194751.GA2928@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

> > baikie: why did the test pass for you?
> 
> The test passes (I assume) if linux-pass-unterminated.diff is applied. The latter patch is only meant to exhibit the issue, though, not to be checked in.

No, I meant for linux-pass-unterminated.diff to be checked in so
that applications could always send datagrams back to the address
they got them from, even when it was 108 bytes long.  As it is
run only on Linux, testMaxPathLen does not leave space for a null
terminator because Linux just ignores it (that is what makes it
possible to bind to a 108-byte address and thus trigger the bug).

----------
title: socket: Buffer overrun while reading unterminated AF_UNIX	addresses -> socket: Buffer overrun while reading unterminated AF_UNIX addresses

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

From report at bugs.python.org  Sun Sep  5 21:48:29 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 05 Sep 2010 19:48:29 +0000
Subject: [issue9748] .inputrc magic-space breaks interactive mode
In-Reply-To: <1283480225.9.0.883250017145.issue9748@psf.upfronthosting.co.za>
Message-ID: <1283716109.86.0.657233712091.issue9748@psf.upfronthosting.co.za>


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

I didn't know what "magic space" is. But a quick google search shows that it is specific to Bash.

in http://www.ukuug.org/events/linux2003/papers/bash_tips/#S16
"""
There are other readline-based programs without this feature, so make it only apply in Bash:

$if Bash
  Space: magic-space
$endif

For example the MySQL client and the Perl debugger can also use the readline library.
"""

Python also uses the readline library; you should add the "$if Bash".

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Sun Sep  5 22:36:39 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 05 Sep 2010 20:36:39 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1283718999.43.0.278522453453.issue9756@psf.upfronthosting.co.za>


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

> To fix the segfault, I suppose that we use a more strict validation on 
> the input type. Eg. Use PyUnicode_Check() instead of 
> PyObject_IsInstance()?

Where would the more strict validation take place?  This problem is not unique to Unicode objects:

motherbrain:py3k minge$ ./python.exe 
Python 3.2a2 (py3k:84541, Sep  5 2010, 15:11:19) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class MyClass(object):
...    def __init__(self):
...       self.pwn = None
...    def __getattribute__(self, name):
...       return getattr(187, name)
... 
[49633 refs]
>>> instance = MyClass()
[49640 refs]
>>> int.bit_length(instance)
Assertion failed: (PyLong_Check(v)), function long_bit_length, file Objects/longobject.c, line 4397.
Abort trap

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

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

From report at bugs.python.org  Sun Sep  5 23:16:40 2010
From: report at bugs.python.org (Craig de Stigter)
Date: Sun, 05 Sep 2010 21:16:40 +0000
Subject: [issue9720] zipfile writes incorrect local file header for large
	files in zip64
In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za>
Message-ID: <1283721400.29.0.404873110135.issue9720@psf.upfronthosting.co.za>


Craig de Stigter <craig.ds at gmail.com> added the comment:

Hi, sorry no I haven't had time to add a real test for this

----------

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

From report at bugs.python.org  Sun Sep  5 23:21:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 05 Sep 2010 21:21:47 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1283721707.31.0.906100666451.issue8372@psf.upfronthosting.co.za>


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

baikie, coming back to your original message: what precisely makes you believe that sun_path does not need to be null-terminated on Linux?

----------

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

From report at bugs.python.org  Mon Sep  6 00:11:43 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 05 Sep 2010 22:11:43 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1283724703.2.0.0285844873335.issue4388@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Any progress on this?  Is the best thing to just set LANG?

----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Mon Sep  6 00:41:06 2010
From: report at bugs.python.org (stephenk)
Date: Sun, 05 Sep 2010 22:41:06 +0000
Subject: [issue9748] .inputrc magic-space breaks interactive mode
In-Reply-To: <1283480225.9.0.883250017145.issue9748@psf.upfronthosting.co.za>
Message-ID: <1283726466.58.0.0689022775232.issue9748@psf.upfronthosting.co.za>


stephenk <krauth.spam1 at gmail.com> added the comment:

Didn't know about the inputrc conditional; that works.  I verified that magic-space (without the conditional) also interferes with mysql, so this seems like less of an oversight on the side of python and more of a bash-user-beware situation.

Anyway, thanks for the workaround!

----------
status: pending -> open

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

From report at bugs.python.org  Mon Sep  6 00:48:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Sep 2010 22:48:41 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1283726921.24.0.150178100642.issue6656@psf.upfronthosting.co.za>


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

Well, I let this bake so long I missed 2.6, but I've backported the fix to 3.1 in r84543.

----------
status: open -> closed

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

From report at bugs.python.org  Mon Sep  6 01:02:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 05 Sep 2010 23:02:59 +0000
Subject: [issue1467619] Header.decode_header eats up spaces
Message-ID: <1283727779.36.0.892596737073.issue1467619@psf.upfronthosting.co.za>


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


----------
priority: high -> normal

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

From report at bugs.python.org  Mon Sep  6 01:05:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Sep 2010 23:05:19 +0000
Subject: [issue9293] Unsupported IO operations should raise
	UnsupportedOperation
In-Reply-To: <1279462171.13.0.608517762148.issue9293@psf.upfronthosting.co.za>
Message-ID: <1283727919.41.0.462841510161.issue9293@psf.upfronthosting.co.za>


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

Committed in r84544.

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

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

From report at bugs.python.org  Mon Sep  6 02:11:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 06 Sep 2010 00:11:23 +0000
Subject: [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

According to the documentation:
"The fill character can be any character other than ?}? (which signifies the end of the field)."
http://docs.python.org/dev/library/string.html#format-specification-mini-language


However the format() builtin accepts both '{' and '}' characters:

>>> format(42, '}^6')
'}}42}}'

>>> format(42, '{^6')
'{{42{{'


And the string method rejects both characters.

>>> '{:}^6}'.format(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Single '}' encountered in format string

>>> '{:{^6}'.format(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unmatched '{' in format

----------
assignee: docs at python
components: Documentation
messages: 115678
nosy: docs at python, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: fill character cannot be '{'
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Sep  6 03:04:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Sep 2010 01:04:45 +0000
Subject: [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283735085.87.0.231193137415.issue9780@psf.upfronthosting.co.za>


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

Looks more like a behavior bug than a doc bug to me. Does the doc comply with the PEP?

----------
nosy: +eric.araujo, eric.smith

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

From report at bugs.python.org  Mon Sep  6 03:06:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Sep 2010 01:06:29 +0000
Subject: [issue1343] XMLGenerator: nice <empty/> elements
In-Reply-To: <1193492035.12.0.0580891111126.issue1343@psf.upfronthosting.co.za>
Message-ID: <1283735189.19.0.816556122733.issue1343@psf.upfronthosting.co.za>


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

Patch looks good to me.

----------

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

From report at bugs.python.org  Mon Sep  6 03:12:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Sep 2010 01:12:05 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1283735525.13.0.86324834318.issue1222585@psf.upfronthosting.co.za>


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


----------
nosy: +eric.araujo
versions: +Python 2.5, Python 2.6, Python 3.1 -Python 3.3

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

From report at bugs.python.org  Mon Sep  6 03:21:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 06 Sep 2010 01:21:30 +0000
Subject: [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283736090.19.0.854974367939.issue9780@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The PEP 3101 does not prohibit any character for the 'fill' argument.

Another example which just works:

>>> '{:{fill}^6}'.format(42, fill='{')
'{{42{{'

>>> '{:{fill}^6}'.format(42, fill='}')
'}}42}}'


I don't care if '{' and '}' are prohibited when using simple formatting syntax.  This is not a common use case, and there are workarounds (either using format() builtin or the recursive formatting).

A documentation fix could be enough.

----------

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

From report at bugs.python.org  Mon Sep  6 03:43:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Sep 2010 01:43:21 +0000
Subject: [issue8524] SSL sockets do not retain the parent socket's attributes
In-Reply-To: <1272142067.91.0.0552245215724.issue8524@psf.upfronthosting.co.za>
Message-ID: <1283737401.62.0.595195316224.issue8524@psf.upfronthosting.co.za>


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

In case someone lands here from the 3.2 what?s new document: The method has been renamed to detach.

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

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

From report at bugs.python.org  Mon Sep  6 03:47:39 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 06 Sep 2010 01:47:39 +0000
Subject: [issue1552880] [Python2] Use utf-8 in the import machinery on Windows
	to support unicode paths
Message-ID: <1283737659.98.0.366184951392.issue1552880@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Well, it was, originally, but it met with so little interest that I couldn't be bothered to polish it to inclusion standards.  Anyway, there was the incompatibility problem of what to do with the __file__ attribute, and the fact that the patch was Windows only.

Do we have a place where we can put in working patches for people to use at their own risk, without going through all the hoops of a successful python.org checkin?

----------

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

From report at bugs.python.org  Mon Sep  6 03:49:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Sep 2010 01:49:47 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1283737787.07.0.316575979942.issue7418@psf.upfronthosting.co.za>


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

Could the module also grow an attribute listing all available algos, or non-guaranteed algos? (Please tell me if I should open a new report.)

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

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

From report at bugs.python.org  Mon Sep  6 03:57:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Sep 2010 01:57:39 +0000
Subject: [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283738259.04.0.576124658715.issue9780@psf.upfronthosting.co.za>


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

Thanks for clarifying.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9780>
_______________________________________

From report at bugs.python.org  Mon Sep  6 03:58:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Sep 2010 01:58:22 +0000
Subject: [issue1552880] [Python2] Use utf-8 in the import machinery on Windows
	to support unicode paths
Message-ID: <1283738302.32.0.595160297758.issue1552880@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There is no such place that I know of, sorry.

----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1552880>
_______________________________________

From report at bugs.python.org  Mon Sep  6 04:29:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Sep 2010 02:29:51 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1283740191.61.0.97969220367.issue1466065@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Comments on patch:

1) if I'm reading the RFC correctly, to be validating strictly in compliance with the RFC \r and \n should also raise an error.  Do you agree?

2) We've pretty much dropped the convention of adding history notes to the file itself.

3) The original code documented a TypeError on incorrect padding but in py3k in fact raises a binascii.Error, as you noted in the patch.  I wonder if it would be better to raise a binascii.Error on invalid data as well, since it isn't, strictly speaking, a TypeError.  That would also make it easier to move the code into the C module later if that is deemed desirable.

4) The negative in the doc language ("If validate is not set to True...") is awkward and confusing.  Better would be "If validate is False (the default)..."

Since the patch does add an API change (AKA a feature) I think this can only go into 3.2.

I have some additional concerns when considering this in the context of email6.  email6 will have a 'strict' mode where it would be sensible for invalid base64 to raise an error.  But in non-strict mode, it would be ideal to have a way to (a) know if there is invalid input, but still decode it, and (b) decode it even if the padding is off after ignoring the invalid data.  I'm not saying that this patch should try to address those issues, I just want to put them on record in case I want to do something about them later.

----------
assignee:  -> r.david.murray
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Mon Sep  6 05:10:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Sep 2010 03:10:48 +0000
Subject: [issue9733] Can't iterate over multiprocessing.managers.DictProxy
In-Reply-To: <1283349080.83.0.871806054056.issue9733@psf.upfronthosting.co.za>
Message-ID: <1283742648.9.0.457715339764.issue9733@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9733>
_______________________________________

From report at bugs.python.org  Mon Sep  6 05:19:05 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 06 Sep 2010 03:19:05 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1283743145.69.0.390211063854.issue7418@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Sounds like a good idea.  frozensets for both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7418>
_______________________________________

From report at bugs.python.org  Mon Sep  6 05:21:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Sep 2010 03:21:28 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1283743288.92.0.949393873218.issue7418@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the reply. Reopening.

I cannot propose a patch since I don?t know how to introspect OpenSSL (or how to write C, for that matter).

----------
stage:  -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7418>
_______________________________________

From report at bugs.python.org  Mon Sep  6 05:40:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Sep 2010 03:40:42 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1283744442.79.0.742458293658.issue4769@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

After thinking about it, I'm inclined to reject this and say that quopri should be fixed to reject string input to decode.  On python-dev Guido opined that a kind of polymorphism in the stdlib was good (bytes in --> bytes out, string in --> string out).  string in --> bytes out and bytes in --> string out was considered bad, to my understanding (except for unicode encode/decode, of course).

As you say, all one has to do is encode the string as ascii to get the bytes to pass in.  It is better, I think, to maintain the clear distinction between bytes and strings in the programmers mind.  That's what Python3 is all about, really.

As for "the whole point of base64 is to safely encode binary data into text characters", that is not true.  The point is to encode binary data into a subset of *ascii*, which is *not* text, it is bytes.  The fact that this is also useful for transferring binary data through unicode is pretty much an unintended consequence of the way unicode is designed.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> pending
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Mon Sep  6 05:59:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Sep 2010 03:59:14 +0000
Subject: [issue9741] msgfmt.py generates invalid mo because msgfmt.make() does
	not clear dictionary
In-Reply-To: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>
Message-ID: <1283745554.8.0.494808337946.issue9741@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9741>
_______________________________________

From report at bugs.python.org  Mon Sep  6 08:25:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Sep 2010 06:25:26 +0000
Subject: [issue1552880] [Python2] Use utf-8 in the import machinery on Windows
	to support unicode paths
Message-ID: <1283754326.47.0.553806730229.issue1552880@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Having patches in the tracker is fine to me. Even if the patch is closed, it's still available.

Of course, there are many ways to publish code on the net: you could post the patch to Rietveld, to the Python wiki, or publish an entire clone to bitbucket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1552880>
_______________________________________

From report at bugs.python.org  Mon Sep  6 08:50:17 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Sep 2010 06:50:17 +0000
Subject: [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283755817.01.0.757437345656.issue9780@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed docs in r84553.

(That builtin format() supports this is no surprise, and has no influence on the validity in format strings.)

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9780>
_______________________________________

From report at bugs.python.org  Mon Sep  6 10:26:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Sep 2010 08:26:11 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1283761571.53.0.550217102184.issue9116@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9116>
_______________________________________

From report at bugs.python.org  Mon Sep  6 10:26:17 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Sep 2010 08:26:17 +0000
Subject: [issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning
	correctly in Python 2.7
In-Reply-To: <1276153559.93.0.766128008061.issue8959@psf.upfronthosting.co.za>
Message-ID: <1283761577.29.0.0289803943798.issue8959@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Mon Sep  6 10:26:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Sep 2010 08:26:23 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1283761583.6.0.100826196474.issue9437@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Mon Sep  6 10:26:29 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Sep 2010 08:26:29 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1283761589.53.0.600004180741.issue9662@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9662>
_______________________________________

From report at bugs.python.org  Mon Sep  6 10:26:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Sep 2010 08:26:36 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1283761596.91.0.472498507713.issue8611@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Mon Sep  6 10:34:49 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 06 Sep 2010 08:34:49 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1283762089.37.0.916031812938.issue7418@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Implemented in py3k r84554.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7418>
_______________________________________

From report at bugs.python.org  Mon Sep  6 11:57:55 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 06 Sep 2010 09:57:55 +0000
Subject: [issue4499] redefinition of TILDE macro on AIX platform
In-Reply-To: <1228258808.76.0.068417078821.issue4499@psf.upfronthosting.co.za>
Message-ID: <1283767075.37.0.501425721618.issue4499@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I can confirm that this problem is still present with Python 3.1.2 on AIX 6.1. This is just a compilation warning, but the patch in
msg110771 correctly cleans it.

xlc_r -c  -DNDEBUG -O  -I. -IInclude -I./Include -I/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/include -I/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/include/ncurses -I/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/include  -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c
"Include/token.h", line 42.9: 1506-236 (W) Macro name TILDE has been redefined.
"Include/token.h", line 42.9: 1506-358 (I) "TILDE" is defined on line 270 of /usr/include/sys/ioctl.h.

----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4499>
_______________________________________

From report at bugs.python.org  Mon Sep  6 12:15:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 06 Sep 2010 10:15:25 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1283768125.17.0.173587052767.issue9778@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> ... change all hash values to be of Py_ssize_t values rather than C longs ...

Yes, please!  (Provided this change can go in before 3.2.)  For the numeric types at least, this should be a straightforward adjustment.

And while we're at it, we could clean up some of the undefined behaviour from integer overflow that's in the current hash functions (tuple.__hash__, for example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Sep  6 12:59:02 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 06 Sep 2010 10:59:02 +0000
Subject: [issue6768] asyncore file_wrapper leaking file descriptors?
In-Reply-To: <1251061355.88.0.439878311774.issue6768@psf.upfronthosting.co.za>
Message-ID: <1283770742.47.0.0539310585271.issue6768@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Closing out because no response has been provided by the OP.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6768>
_______________________________________

From report at bugs.python.org  Mon Sep  6 13:03:14 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 06 Sep 2010 11:03:14 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1283770994.03.0.216665115348.issue8684@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Josiah are you still interested in this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Mon Sep  6 14:41:02 2010
From: report at bugs.python.org (Arialdo Martini)
Date: Mon, 06 Sep 2010 12:41:02 +0000
Subject: [issue9781] Dead link
In-Reply-To: <1283776862.85.0.667935106717.issue9781@psf.upfronthosting.co.za>
Message-ID: <1283776862.85.0.667935106717.issue9781@psf.upfronthosting.co.za>


New submission from Arialdo Martini <arialdo.martini at gmail.com>:

In the Italian version of the Official  Turorial, the link to  Python Bug Tracker is dead.

----------
assignee: docs at python
components: Documentation
messages: 115698
nosy: Arialdo.Martini, docs at python
priority: normal
severity: normal
status: open
title: Dead link
type: resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9781>
_______________________________________

From report at bugs.python.org  Mon Sep  6 14:42:09 2010
From: report at bugs.python.org (Arialdo Martini)
Date: Mon, 06 Sep 2010 12:42:09 +0000
Subject: [issue9781] Dead link in Italian Tutorial
In-Reply-To: <1283776862.85.0.667935106717.issue9781@psf.upfronthosting.co.za>
Message-ID: <1283776929.7.0.437441008597.issue9781@psf.upfronthosting.co.za>


Changes by Arialdo Martini <arialdo.martini at gmail.com>:


----------
title: Dead link -> Dead link in Italian Tutorial

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9781>
_______________________________________

From report at bugs.python.org  Mon Sep  6 14:43:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 12:43:05 +0000
Subject: [issue9782] _multiprocessing.c warnings under 64-bit Windows
In-Reply-To: <1283776985.14.0.464453735202.issue9782@psf.upfronthosting.co.za>
Message-ID: <1283776985.14.0.464453735202.issue9782@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

There are various warnings when compiling the _multiprocessing extension in 64-bit mode under Windows. Many seem related to the fact that read() and friends under Windows take "int" size arguments rather than "size_t".

20>------ Build started: Project: _multiprocessing, Configuration: Release x64 ------
20>Compiling...
20>multiprocessing.c
20>win32_functions.c
20>socket_connection.c
20>..\Modules\_multiprocessing\socket_connection.c(32) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(54) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(126) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(137) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(145) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(139) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(183) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(237) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(285) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(323) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>semaphore.c
20>pipe_connection.c
20>..\Modules\_multiprocessing\pipe_connection.c(24) : warning C4267: 'function' : conversion from 'size_t' to 'DWORD', possible loss of data
20>..\Modules\_multiprocessing\pipe_connection.c(50) : warning C4267: 'function' : conversion from 'size_t' to 'DWORD', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(139) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(183) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(237) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(285) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(323) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>Linking...
20>   Creating library Z:\py3k\__svn__\PCbuild\\amd64\\_multiprocessing.lib and object Z:\py3k\__svn__\PCbuild\\amd64\\_multiprocessing.exp
20>Generating code
20>Finished generating code
20>Build log was saved at "file://Z:\py3k\__svn__\PCbuild\x64-temp-Release\_multiprocessing\BuildLog.htm"
20>_multiprocessing - 0 error(s), 17 warning(s)

----------
components: Extension Modules, Windows
messages: 115699
nosy: brian.curtin, jnoller, pitrou, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: _multiprocessing.c warnings under 64-bit Windows
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9782>
_______________________________________

From report at bugs.python.org  Mon Sep  6 14:49:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 12:49:53 +0000
Subject: [issue9783] _elementtree.c warnings under 64-bit Windows
In-Reply-To: <1283777393.95.0.65520363014.issue9783@psf.upfronthosting.co.za>
Message-ID: <1283777393.95.0.65520363014.issue9783@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Some of these warnings could be serious (e.g. the one where the 64-bit "self" is converted to a 32-bit "long"):

13>..\Modules\_elementtree.c(696) : warning C4244: 'function' : conversion from 'Py_uintptr_t' to 'long', possible loss of data
13>..\Modules\_elementtree.c(1239) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(1372) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(1414) : warning C4244: '+=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(2076) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(2663) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

----------
components: Extension Modules, Windows
messages: 115700
nosy: effbot, flox, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: _elementtree.c warnings under 64-bit Windows
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9783>
_______________________________________

From report at bugs.python.org  Mon Sep  6 14:55:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 12:55:42 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I'm posting this in case it is a sign of a problem. Apparently some variable named "hf" is an INT_PTR used as an int (according to Visual Studio), but "hf" doesn't seem to be defined or declared in _msi.c at all.

12>..\PC\_msi.c(66) : warning C4244: 'function' : conversion from 'INT_PTR' to 'int', possible loss of data
12>..\PC\_msi.c(74) : warning C4244: 'function' : conversion from 'INT_PTR' to 'int', possible loss of data
12>..\PC\_msi.c(82) : warning C4244: 'function' : conversion from 'INT_PTR' to 'int', possible loss of data
12>..\PC\_msi.c(90) : warning C4244: 'function' : conversion from 'INT_PTR' to 'int', possible loss of data

----------
components: Extension Modules
messages: 115701
nosy: loewis, pitrou
priority: normal
severity: normal
status: open
title: _msi.c warnings under 64-bit Windows
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Mon Sep  6 15:25:11 2010
From: report at bugs.python.org (Trigve Siver)
Date: Mon, 06 Sep 2010 13:25:11 +0000
Subject: [issue9785] _PyUnicode_New(), throw and memory problem
In-Reply-To: <1283779511.86.0.882093197661.issue9785@psf.upfronthosting.co.za>
Message-ID: <1283779511.86.0.882093197661.issue9785@psf.upfronthosting.co.za>


New submission from Trigve Siver <trigves at gmail.com>:

I'm using C++ with python embeding.
I'm creating a couple of unicode objects and then some
exception is thrown. While handling exception I create othet unicode objects. Then when creating some unicode object crash occurs. The problem is in _PyUnicode_New():325 on line (1):

if (free_list) {
    unicode = free_list; /*<- (1)*/
    free_list = *(PyUnicodeObject **)unicode;

In statement "unicode = free_list;" "unicode" pointer is bad pointer, in fact it's address is 5 bytes "lower" (i.e. should be 0x030bc3ff but is 0x030bc3fa).

It looks like this only happens when exception is thrown.

When python exception is set I throw C++ exception to signal C++ code that py exception was set. Next in C++ exception handler I format the python exception using some python unicode objects and then the problem occurs.
Without the C++ throw (Only python exception formatting) it looks like everything is working OK.

I'm using python 3.1.2 on Vista with MSVS 2010. I've also tried python 3.2a2 but it was the same.

I've tried to isolate the problem in some simple example but haven't been successful yet.

----------
components: Library (Lib)
messages: 115702
nosy: Trigve.Siver
priority: normal
severity: normal
status: open
title: _PyUnicode_New(), throw and memory problem
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9785>
_______________________________________

From report at bugs.python.org  Mon Sep  6 15:57:08 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 06 Sep 2010 13:57:08 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283781428.06.0.389870523807.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Hi,

I have updated the patch and adapted it for Python 3.1.2:

* this time ld_so_aix is moved to ld_so_aix.in which is converted to ld_so_aix by 'configure' so that it has the right version number for the python library

* there are no more warnings for 'Duplicate symbol': I changed build_ext.py to not link extensions with libpython since the symbols are already defined by python.exp

* I made a modification to ld_so_aix specifically for Python 3 as according to pep-3121 the entry function has been renamed from init<modulname> to PyInit_<modulename>

I will provide another patch for Python 2.7 (nearly the same, but without the modification needed by pep-3121).
I also attach the build log for Python 3.1.2 without and with this patch.

regards

----------
Added file: http://bugs.python.org/file18762/Python-3.1.2_shared_AIX.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Mon Sep  6 15:58:07 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 06 Sep 2010 13:58:07 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283781487.3.0.233114941901.issue941346@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Added file: http://bugs.python.org/file18763/python312_AIX61_static_nopatch.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Mon Sep  6 15:58:39 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 06 Sep 2010 13:58:39 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283781519.91.0.756602268088.issue941346@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Added file: http://bugs.python.org/file18764/python312_AIX61_static_patch_shared.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Mon Sep  6 15:59:06 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 06 Sep 2010 13:59:06 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283781546.35.0.0112065533768.issue941346@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Added file: http://bugs.python.org/file18765/python312_AIX61_shared_patch_shared.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Mon Sep  6 15:59:40 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 06 Sep 2010 13:59:40 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283781580.53.0.82873259002.issue941346@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Mon Sep  6 16:03:59 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 06 Sep 2010 14:03:59 +0000
Subject: [issue9781] Dead link in Italian Tutorial
In-Reply-To: <1283776862.85.0.667935106717.issue9781@psf.upfronthosting.co.za>
Message-ID: <1283781839.67.0.538735971131.issue9781@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

We don't maintain an Italian version of the tutorial. You'll have to contact its maintainer.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9781>
_______________________________________

From report at bugs.python.org  Mon Sep  6 16:06:24 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 06 Sep 2010 14:06:24 +0000
Subject: [issue9129] DoS smtpd module vulnerability
In-Reply-To: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>
Message-ID: <1283781984.21.0.703649889505.issue9129@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

This is already in 2.6 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9129>
_______________________________________

From report at bugs.python.org  Mon Sep  6 16:17:53 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 06 Sep 2010 14:17:53 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283782673.71.0.481186730806.issue4026@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is the version of the patch for Python 2.7.
I had to change AC_TRY_COMPILE to AC_COMPILE_IFELSE and AC_TRY_LINK to AC_LINK_IFELSE.

The syntax in configure.in is the same between Python 2.7 and the trunk. It is also the same between Python 2.6.6 and Python 3.1.2.

So this patch can be applied on the trunk and the patch Python-2.6.6_flock_AIX.diff can be applied on Python 3.1.2.

----------
Added file: http://bugs.python.org/file18766/Python-2.7_flock_AIX.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Mon Sep  6 16:27:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 14:27:34 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283783254.83.0.207217358832.issue941346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you. For the record, here is the patch adapted for 3.2 development branch. It looks ok to me.

----------
stage: unit test needed -> patch review
versions: +Python 3.2 -Python 2.6
Added file: http://bugs.python.org/file18767/aix32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Mon Sep  6 16:35:19 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 06 Sep 2010 14:35:19 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283783719.91.0.826804250756.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is the patch for Python 2.7.

The only difference compared to Python 3.1.2 is that we don't rename init<modulname> to PyInit_<modulename>.

----------
versions: +Python 2.6 -Python 3.2
Added file: http://bugs.python.org/file18768/Python-2.7_shared_AIX.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Mon Sep  6 16:59:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 14:59:20 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283785160.72.0.829258620371.issue941346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> * there are no more warnings for 'Duplicate symbol': I changed
> build_ext.py to not link extensions with libpython since the symbols
> are already defined by python.exp

Could this affect building extensions with gcc under AIX? Or does gcc delegate to the AIX linker?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Mon Sep  6 17:09:02 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 06 Sep 2010 15:09:02 +0000
Subject: [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283785742.97.0.849974007776.issue9780@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Sorry to respond late.

The reason for this is that the parsing of the string (as delimited by "{" and "}") happens before the results are then interpreted as format specifiers. There's no way around it, short of the parser understanding every object's formatting language, which is of course not possible. It could be special cased for string, int, and float format specifiers, but that doesn't make much sense.

I think the doc change is good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9780>
_______________________________________

From report at bugs.python.org  Mon Sep  6 17:12:26 2010
From: report at bugs.python.org (Michael Haubenwallner)
Date: Mon, 06 Sep 2010 15:12:26 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283785946.19.0.697872250955.issue4026@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

While I've not tested these patches myself, I do think there still is an unhandled case: building a 64bit python.
As libbsd.a contains 32bit objects only, there is no 64bit flock().
So AC_CHECK_LIB(bsd,flock) may still fail, which should result in have_flock=no then.
Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Mon Sep  6 17:21:26 2010
From: report at bugs.python.org (Jonas H.)
Date: Mon, 06 Sep 2010 15:21:26 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1283786486.35.0.624898487913.issue1731717@psf.upfronthosting.co.za>


Changes by Jonas H. <jonas at lophus.org>:


----------
nosy: +jonash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Mon Sep  6 18:05:55 2010
From: report at bugs.python.org (Greg Malcolm)
Date: Mon, 06 Sep 2010 16:05:55 +0000
Subject: [issue9607] Test file 'test_keyword.py' submission for use with
	keyword.py
In-Reply-To: <1281849348.53.0.810648733764.issue9607@psf.upfronthosting.co.za>
Message-ID: <1283789155.24.0.586728700468.issue9607@psf.upfronthosting.co.za>


Changes by Greg Malcolm <greg at gregmalcolm.com>:


Removed file: http://bugs.python.org/file18537/test_keyword.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9607>
_______________________________________

From report at bugs.python.org  Mon Sep  6 18:10:59 2010
From: report at bugs.python.org (Greg Malcolm)
Date: Mon, 06 Sep 2010 16:10:59 +0000
Subject: [issue9607] Test file 'test_keyword.py' submission for use with
	keyword.py
In-Reply-To: <1281849348.53.0.810648733764.issue9607@psf.upfronthosting.co.za>
Message-ID: <1283789459.65.0.887531387574.issue9607@psf.upfronthosting.co.za>


Greg Malcolm <greg at gregmalcolm.com> added the comment:

Thanks for the feedback David! I've replaced the old patch with a new version that uses Popen/sys.executable as suggested.

- Greg

----------
Added file: http://bugs.python.org/file18769/test_keyword_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9607>
_______________________________________

From report at bugs.python.org  Mon Sep  6 18:18:21 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 06 Sep 2010 16:18:21 +0000
Subject: [issue9324] signal.signal(bogus_signal, handler) segfaults on Windows
In-Reply-To: <1279738256.92.0.653078709511.issue9324@psf.upfronthosting.co.za>
Message-ID: <1283789901.15.0.595873881075.issue9324@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Checked in the suggested fixes in r84556 (py3k), r84557 (release27-maint), and r84558 (release27-maint).

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9324>
_______________________________________

From report at bugs.python.org  Mon Sep  6 18:27:54 2010
From: report at bugs.python.org (Trigve Siver)
Date: Mon, 06 Sep 2010 16:27:54 +0000
Subject: [issue9785] _PyUnicode_New(), throw and memory problem
In-Reply-To: <1283779511.86.0.882093197661.issue9785@psf.upfronthosting.co.za>
Message-ID: <1283790474.5.0.294280552279.issue9785@psf.upfronthosting.co.za>


Trigve Siver <trigves at gmail.com> added the comment:

I've tried to examine it in more depth.

Setting the python exception isn't necessary, only throwing the C++ exception is needed for demonstrating the problem.

Also sometimes the address is 6 bytes "lower" than should be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9785>
_______________________________________

From report at bugs.python.org  Mon Sep  6 18:31:57 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 06 Sep 2010 16:31:57 +0000
Subject: [issue8956] Incorrect ValueError message for
	subprocess.Popen.send_signal() on Windows
In-Reply-To: <1276107936.75.0.980203852578.issue8956@psf.upfronthosting.co.za>
Message-ID: <1283790717.63.0.201897620413.issue8956@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in r84559 (py3k) and r84560 (release27-maint).

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8956>
_______________________________________

From report at bugs.python.org  Mon Sep  6 18:42:16 2010
From: report at bugs.python.org (David Watson)
Date: Mon, 06 Sep 2010 16:42:16 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1283721707.31.0.906100666451.issue8372@psf.upfronthosting.co.za>
Message-ID: <20100906164205.GA18491@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

> baikie, coming back to your original message: what precisely makes you believe that sun_path does not need to be null-terminated on Linux?

That's the way I demonstrated the bug - the only way to bind to a
108-byte path is to pass it without null termination, because
Linux will not accept an oversized sockaddr_un structure (e.g. a
108-byte path plus null terminator).  Also, unless it's on OS/2,
Python's existing code never includes the null terminator in the
address size it passes to the system call, so a correctly-
behaving OS should never see it.

However, it does now occur to me that a replacement libc
implementation for Linux could try to do something with sun_path
during the call and assume it's null-terminated even though the
kernel doesn't, so it may be best to keep the null termination
requirement after all.  In that case, there would be no way to
test for the bug from within Python, so the test problems would
be somewhat moot (although the test code could still be used by
changing UNIX_PATH_MAX from 108 to 107).

Attaching four-space-indent versions of the original patches (for
2.x and 3.x), and tests incorporating Antoine's use of
assertRaisesRegexp.

----------
Added file: http://bugs.python.org/file18770/linux-pass-unterminated-4spc.diff
Added file: http://bugs.python.org/file18771/return-unterminated-2.x-4spc.diff
Added file: http://bugs.python.org/file18772/return-unterminated-3.x-4spc.diff
Added file: http://bugs.python.org/file18773/addrlen-2.x-4spc.diff
Added file: http://bugs.python.org/file18774/addrlen-3.x-4spc.diff
Added file: http://bugs.python.org/file18775/test-2.x-new.diff
Added file: http://bugs.python.org/file18776/test-3.x-new.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________
-------------- next part --------------
Allow AF_UNIX pathnames up to the maximum 108 bytes on Linux,
since it does not require sun_path to be null terminated.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -1187,27 +1187,16 @@ getsockaddrarg(PySocketSockObject *s, Py
 
         addr = (struct sockaddr_un*)addr_ret;
 #ifdef linux
-        if (len > 0 && path[0] == 0) {
-            /* Linux abstract namespace extension */
-            if (len > sizeof addr->sun_path) {
-                PyErr_SetString(socket_error,
-                                "AF_UNIX path too long");
-                return 0;
-            }
-        }
-        else
-#endif /* linux */
-        {
-            /* regular NULL-terminated string */
-            if (len >= sizeof addr->sun_path) {
-                PyErr_SetString(socket_error,
-                                "AF_UNIX path too long");
-                return 0;
-            }
-            addr->sun_path[len] = 0;
+        if (len > sizeof(addr->sun_path)) {
+#else
+        if (len >= sizeof(addr->sun_path)) {
+#endif
+            PyErr_SetString(socket_error, "AF_UNIX path too long");
+            return 0;
         }
         addr->sun_family = s->sock_family;
         memcpy(addr->sun_path, path, len);
+        memset(addr->sun_path + len, 0, sizeof(addr->sun_path) - len);
 #if defined(PYOS_OS2)
         *len_ret = sizeof(*addr);
 #else
-------------- next part --------------
When parsing sockaddr_un structures returned by accept(), etc.,
only examine bytes up to supplied addrlen and do not require null
termination.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -998,19 +998,22 @@ makesockaddr(int sockfd, struct sockaddr
 #if defined(AF_UNIX)
     case AF_UNIX:
     {
+        Py_ssize_t len, splen;
         struct sockaddr_un *a = (struct sockaddr_un *) addr;
+        splen = addrlen - offsetof(struct sockaddr_un, sun_path);
 #ifdef linux
-        if (a->sun_path[0] == 0) {  /* Linux abstract namespace */
-            addrlen -= offsetof(struct sockaddr_un, sun_path);
-            return PyString_FromStringAndSize(a->sun_path,
-                                              addrlen);
+        if (splen > 0 && a->sun_path[0] == 0) {
+            /* Linux abstract namespace */
+            len = splen;
         }
         else
 #endif /* linux */
         {
-            /* regular NULL-terminated string */
-            return PyString_FromString(a->sun_path);
+            /* String, up to null terminator if present */
+            for (len = 0; len < splen && a->sun_path[len] != 0; len++)
+                ;
         }
+        return PyString_FromStringAndSize(a->sun_path, len);
     }
 #endif /* AF_UNIX */
 
-------------- next part --------------
When parsing sockaddr_un structures returned by accept(), etc.,
only examine bytes up to supplied addrlen and do not require null
termination.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -962,18 +962,22 @@ makesockaddr(SOCKET_T sockfd, struct soc
 #if defined(AF_UNIX)
     case AF_UNIX:
     {
+        Py_ssize_t len, splen;
         struct sockaddr_un *a = (struct sockaddr_un *) addr;
+        splen = addrlen - offsetof(struct sockaddr_un, sun_path);
 #ifdef linux
-        if (a->sun_path[0] == 0) {  /* Linux abstract namespace */
-            addrlen -= offsetof(struct sockaddr_un, sun_path);
-            return PyBytes_FromStringAndSize(a->sun_path, addrlen);
+        if (splen > 0 && a->sun_path[0] == 0) {
+            /* Linux abstract namespace */
+            return PyBytes_FromStringAndSize(a->sun_path, splen);
         }
         else
 #endif /* linux */
         {
-            /* regular NULL-terminated string */
-            return PyUnicode_FromString(a->sun_path);
+            /* String, up to null terminator if present */
+            for (len = 0; len < splen && a->sun_path[len] != 0; len++)
+                ;
         }
+        return PyUnicode_FromStringAndSize(a->sun_path, len);
     }
 #endif /* AF_UNIX */
 
-------------- next part --------------
If accept(), etc. return a larger addrlen than was supplied,
ignore it and use the original buffer length.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -1608,6 +1608,7 @@ sock_accept(PySocketSockObject *s)
     sock_addr_t addrbuf;
     SOCKET_T newfd;
     socklen_t addrlen;
+    socklen_t buflen;
     PyObject *sock = NULL;
     PyObject *addr = NULL;
     PyObject *res = NULL;
@@ -1615,6 +1616,7 @@ sock_accept(PySocketSockObject *s)
 
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
 
 #ifdef MS_WINDOWS
@@ -1656,7 +1658,7 @@ sock_accept(PySocketSockObject *s)
         goto finally;
     }
     addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
-                        addrlen, s->sock_proto);
+                        (addrlen > buflen) ? buflen : addrlen, s->sock_proto);
     if (addr == NULL)
         goto finally;
 
@@ -2154,17 +2156,19 @@ sock_getsockname(PySocketSockObject *s)
     sock_addr_t addrbuf;
     int res;
     socklen_t addrlen;
+    socklen_t buflen;
 
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
     Py_BEGIN_ALLOW_THREADS
     res = getsockname(s->sock_fd, SAS2SA(&addrbuf), &addrlen);
     Py_END_ALLOW_THREADS
     if (res < 0)
         return s->errorhandler();
-    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen,
-                        s->sock_proto);
+    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
+                        (addrlen > buflen) ? buflen : addrlen, s->sock_proto);
 }
 
 PyDoc_STRVAR(getsockname_doc,
@@ -2183,17 +2187,19 @@ sock_getpeername(PySocketSockObject *s)
     sock_addr_t addrbuf;
     int res;
     socklen_t addrlen;
+    socklen_t buflen;
 
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
     Py_BEGIN_ALLOW_THREADS
     res = getpeername(s->sock_fd, SAS2SA(&addrbuf), &addrlen);
     Py_END_ALLOW_THREADS
     if (res < 0)
         return s->errorhandler();
-    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen,
-                        s->sock_proto);
+    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
+                        (addrlen > buflen) ? buflen : addrlen, s->sock_proto);
 }
 
 PyDoc_STRVAR(getpeername_doc,
@@ -2515,11 +2521,13 @@ sock_recvfrom_guts(PySocketSockObject *s
     int timeout;
     ssize_t n = -1;
     socklen_t addrlen;
+    socklen_t buflen;
 
     *addr = NULL;
 
     if (!getsockaddrlen(s, &addrlen))
         return -1;
+    buflen = addrlen;
 
     if (!IS_SELECTABLE(s)) {
         select_error();
@@ -2555,7 +2563,8 @@ sock_recvfrom_guts(PySocketSockObject *s
     }
 
     if (!(*addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
-                               addrlen, s->sock_proto)))
+                               (addrlen > buflen) ? buflen : addrlen,
+                               s->sock_proto)))
         return -1;
 
     return n;
-------------- next part --------------
If accept(), etc. return a larger addrlen than was supplied,
ignore it and use the original buffer length.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -1572,6 +1572,7 @@ sock_accept(PySocketSockObject *s)
     sock_addr_t addrbuf;
     SOCKET_T newfd = INVALID_SOCKET;
     socklen_t addrlen;
+    socklen_t buflen;
     PyObject *sock = NULL;
     PyObject *addr = NULL;
     PyObject *res = NULL;
@@ -1579,6 +1580,7 @@ sock_accept(PySocketSockObject *s)
 
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
 
     if (!IS_SELECTABLE(s))
@@ -1605,7 +1607,7 @@ sock_accept(PySocketSockObject *s)
     }
 
     addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
-                        addrlen, s->sock_proto);
+                        (addrlen > buflen) ? buflen : addrlen, s->sock_proto);
     if (addr == NULL)
         goto finally;
 
@@ -2055,17 +2057,19 @@ sock_getsockname(PySocketSockObject *s)
     sock_addr_t addrbuf;
     int res;
     socklen_t addrlen;
+    socklen_t buflen;
 
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
     Py_BEGIN_ALLOW_THREADS
     res = getsockname(s->sock_fd, SAS2SA(&addrbuf), &addrlen);
     Py_END_ALLOW_THREADS
     if (res < 0)
         return s->errorhandler();
-    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen,
-                        s->sock_proto);
+    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
+                        (addrlen > buflen) ? buflen : addrlen, s->sock_proto);
 }
 
 PyDoc_STRVAR(getsockname_doc,
@@ -2084,17 +2088,19 @@ sock_getpeername(PySocketSockObject *s)
     sock_addr_t addrbuf;
     int res;
     socklen_t addrlen;
+    socklen_t buflen;
 
     if (!getsockaddrlen(s, &addrlen))
         return NULL;
+    buflen = addrlen;
     memset(&addrbuf, 0, addrlen);
     Py_BEGIN_ALLOW_THREADS
     res = getpeername(s->sock_fd, SAS2SA(&addrbuf), &addrlen);
     Py_END_ALLOW_THREADS
     if (res < 0)
         return s->errorhandler();
-    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen,
-                        s->sock_proto);
+    return makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
+                        (addrlen > buflen) ? buflen : addrlen, s->sock_proto);
 }
 
 PyDoc_STRVAR(getpeername_doc,
@@ -2354,11 +2360,13 @@ sock_recvfrom_guts(PySocketSockObject *s
     int timeout;
     Py_ssize_t n = -1;
     socklen_t addrlen;
+    socklen_t buflen;
 
     *addr = NULL;
 
     if (!getsockaddrlen(s, &addrlen))
         return -1;
+    buflen = addrlen;
 
     if (!IS_SELECTABLE(s)) {
         select_error();
@@ -2394,7 +2402,8 @@ sock_recvfrom_guts(PySocketSockObject *s
     }
 
     if (!(*addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
-                               addrlen, s->sock_proto)))
+                               (addrlen > buflen) ? buflen : addrlen,
+                               s->sock_proto)))
         return -1;
 
     return n;
-------------- next part --------------
Test handling of unterminated AF_UNIX addresses on Linux.

diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py
--- a/Lib/test/test_socket.py
+++ b/Lib/test/test_socket.py
@@ -1261,6 +1261,43 @@ class TestExceptions(unittest.TestCase):
         self.assertTrue(issubclass(socket.gaierror, socket.error))
         self.assertTrue(issubclass(socket.timeout, socket.error))
 
+class TestLinuxPathLen(unittest.TestCase):
+
+    # Test AF_UNIX path length limits on Linux.
+
+    UNIX_PATH_MAX = 108
+
+    def setUp(self):
+        self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
+        self.to_unlink = []
+
+    def tearDown(self):
+        self.sock.close()
+        for name in self.to_unlink:
+            test_support.unlink(name)
+
+    def pathname(self, length):
+        # Return a pathname of the given length.
+        path = os.path.abspath(test_support.TESTFN)
+        return path + "a" * (length - len(path))
+
+    def testPathTooLong(self):
+        # Check we can't bind to a path longer than the assumed maximum.
+        path = self.pathname(self.UNIX_PATH_MAX + 1)
+        with self.assertRaisesRegexp(socket.error, "AF_UNIX path too long"):
+            self.sock.bind(path)
+            self.to_unlink.append(path)
+
+    def testMaxPathLen(self):
+        # Test binding to a path of the maximum length and reading the
+        # address back.  In this case, sun_path is not null terminated,
+        # and makesockaddr() used to read past the end of it.
+        path = self.pathname(self.UNIX_PATH_MAX)
+        self.sock.bind(path)
+        self.to_unlink.append(path)
+        self.assertEqual(self.sock.getsockname(), path)
+        os.stat(path)
+
 class TestLinuxAbstractNamespace(unittest.TestCase):
 
     UNIX_PATH_MAX = 108
@@ -1456,6 +1493,7 @@ def test_main():
         tests.append(BasicSocketPairTest)
     if sys.platform == 'linux2':
         tests.append(TestLinuxAbstractNamespace)
+        tests.append(TestLinuxPathLen)
     if isTipcAvailable():
         tests.append(TIPCTest)
         tests.append(TIPCThreadableTest)
-------------- next part --------------
Test handling of unterminated AF_UNIX addresses on Linux.

diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py
--- a/Lib/test/test_socket.py
+++ b/Lib/test/test_socket.py
@@ -1392,6 +1392,53 @@ class TestExceptions(unittest.TestCase):
         self.assertTrue(issubclass(socket.gaierror, socket.error))
         self.assertTrue(issubclass(socket.timeout, socket.error))
 
+class TestLinuxPathLen(unittest.TestCase):
+
+    # Test AF_UNIX path length limits on Linux.
+
+    UNIX_PATH_MAX = 108
+
+    def setUp(self):
+        self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
+        self.to_unlink = []
+
+    def tearDown(self):
+        self.sock.close()
+        for name in self.to_unlink:
+            support.unlink(name)
+
+    def pathEncodingArgs(self):
+        # Return the encoding and error handler used to encode/decode
+        # pathnames.
+        encoding = sys.getfilesystemencoding()
+        if encoding is None:
+            encoding = sys.getdefaultencoding()
+        return encoding, "surrogateescape"
+
+    def pathname(self, length):
+        # Return a bytes pathname of the given length.
+        path = os.path.abspath(support.TESTFN)
+        path_bytes = path.encode(*self.pathEncodingArgs())
+        return path_bytes + b"a" * (length - len(path_bytes))
+
+    def testPathTooLong(self):
+        # Check we can't bind to a path longer than the assumed maximum.
+        path = self.pathname(self.UNIX_PATH_MAX + 1)
+        with self.assertRaisesRegexp(socket.error, "AF_UNIX path too long"):
+            self.sock.bind(path)
+            self.to_unlink.append(path)
+
+    def testMaxPathLen(self):
+        # Test binding to a path of the maximum length and reading the
+        # address back.  In this case, sun_path is not null terminated,
+        # and makesockaddr() used to read past the end of it.
+        path = self.pathname(self.UNIX_PATH_MAX)
+        self.sock.bind(path)
+        self.to_unlink.append(path)
+        self.assertEqual(self.sock.getsockname(),
+                         path.decode(*self.pathEncodingArgs()))
+        os.stat(path)
+
 class TestLinuxAbstractNamespace(unittest.TestCase):
 
     UNIX_PATH_MAX = 108
@@ -1583,6 +1630,7 @@ def test_main():
         tests.append(BasicSocketPairTest)
     if sys.platform == 'linux2':
         tests.append(TestLinuxAbstractNamespace)
+        tests.append(TestLinuxPathLen)
     if isTipcAvailable():
         tests.append(TIPCTest)
         tests.append(TIPCThreadableTest)

From report at bugs.python.org  Mon Sep  6 19:08:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 06 Sep 2010 17:08:12 +0000
Subject: [issue7566] Add ntpath.sameopenfile support for Windows
In-Reply-To: <1261529807.86.0.672662668527.issue7566@psf.upfronthosting.co.za>
Message-ID: <1283792892.01.0.940102814046.issue7566@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Added in r84561.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7566>
_______________________________________

From report at bugs.python.org  Mon Sep  6 19:09:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 17:09:27 +0000
Subject: [issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.
In-Reply-To: <1280384767.75.0.12386540434.issue9410@psf.upfronthosting.co.za>
Message-ID: <1283792967.7.0.472071972929.issue9410@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch doesn't apply cleanly anymore. Furthermore, I discovered some additional issues:
- load, dump, loads and dumps from the _pickle module were never used because they were shadowed by the same functions in pickle.py
- once the C functions above are enabled, they produce some bugs

I'm working on an updated patch, fixing the aforementioned bugs and adding a buffer size limit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9410>
_______________________________________

From report at bugs.python.org  Mon Sep  6 19:09:46 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Sep 2010 17:09:46 +0000
Subject: [issue9763] Crashes upon run after syntax error encountered in OSX
	10.5.8
In-Reply-To: <1283542973.95.0.133487128669.issue9763@psf.upfronthosting.co.za>
Message-ID: <1283792986.44.0.933760751804.issue9763@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

IDLE from the Python 3.2s2 OS X installer exhibits the same buggy behavior on 10.5 as 3.1.2 (hangs with system Tk 8.4, OK with ActiveState Tk 8.4).  There also seem to be some unexpected differences in IDLE behavior between 2.7 and 3.x as if some changes were not backported.  Will triage further.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9763>
_______________________________________

From report at bugs.python.org  Mon Sep  6 19:11:49 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Sep 2010 17:11:49 +0000
Subject: [issue9763] Crashes upon run after syntax error encountered in OSX
	10.5.8
In-Reply-To: <1283542973.95.0.133487128669.issue9763@psf.upfronthosting.co.za>
Message-ID: <1283793109.03.0.575298623821.issue9763@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

IDLE from the Python 3.2a2 OS X installer exhibits the same buggy behavior on 10.5 as 3.1.2 (hangs with system Tk 8.4, OK with ActiveState Tk 8.4).  There also seem to be some unexpected differences in IDLE behavior between 2.7 and 3.x as if some changes were not backported.  Will triage further.

----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9763>
_______________________________________

From report at bugs.python.org  Mon Sep  6 19:12:01 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Sep 2010 17:12:01 +0000
Subject: [issue9763] Crashes upon run after syntax error encountered in OSX
	10.5.8
In-Reply-To: <1283542973.95.0.133487128669.issue9763@psf.upfronthosting.co.za>
Message-ID: <1283793121.74.0.296154186929.issue9763@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg115719

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9763>
_______________________________________

From report at bugs.python.org  Mon Sep  6 19:18:00 2010
From: report at bugs.python.org (Trigve Siver)
Date: Mon, 06 Sep 2010 17:18:00 +0000
Subject: [issue9785] _PyUnicode_New(), throw and memory problem
In-Reply-To: <1283779511.86.0.882093197661.issue9785@psf.upfronthosting.co.za>
Message-ID: <1283793480.55.0.993661085115.issue9785@psf.upfronthosting.co.za>


Trigve Siver <trigves at gmail.com> added the comment:

Nevermind, I found out it was problem with ref count while using PyTuple_SetItem()

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9785>
_______________________________________

From report at bugs.python.org  Mon Sep  6 19:18:42 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 06 Sep 2010 17:18:42 +0000
Subject: [issue9768] IDLE / Black frame in active window
In-Reply-To: <1283552072.12.0.125379675642.issue9768@psf.upfronthosting.co.za>
Message-ID: <1283793522.78.0.474357819514.issue9768@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Closing as "works for me".  If you have a suggestion for a change to IDLE behavior, suggest discussing on the IDLE development list or opening a new issue and supply a patch.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9768>
_______________________________________

From report at bugs.python.org  Mon Sep  6 19:28:21 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 06 Sep 2010 17:28:21 +0000
Subject: [issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.
In-Reply-To: <1280384767.75.0.12386540434.issue9410@psf.upfronthosting.co.za>
Message-ID: <1283794101.92.0.831398939436.issue9410@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Antoine, I fixed these issues in the latest patch posted on Rietveld. Also, Skip added the buffer limit in Unladen Swallow (see msg112956). We just need to merge that.

----------
Added file: http://bugs.python.org/file18777/issue1694050_19001.diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9410>
_______________________________________

From report at bugs.python.org  Mon Sep  6 19:35:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 17:35:15 +0000
Subject: [issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.
In-Reply-To: <1280384767.75.0.12386540434.issue9410@psf.upfronthosting.co.za>
Message-ID: <1283794515.72.0.0243022927379.issue9410@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. Benchmark numbers:

* dumps():

./python -m timeit -s "import pickle, io; d={(x, 'a'): x  for x in range(10000)}" "pickle.dumps(d)"

-> before: 100 loops, best of 3: 7.47 msec per loop
-> after: 100 loops, best of 3: 2.45 msec per loop

* loads():

./python -m timeit -s "import pickle, io; d={(x, 'a'): x  for x in range(10000)}; d=pickle.dumps(d)" "pickle.loads(d)"

-> before: 100 loops, best of 3: 12.1 msec per loop
-> after: 100 loops, best of 3: 2.62 msec per loop

* dump():

./python -m timeit -s "import pickle, io; d={(x, 'a'): x  for x in range(10000)}" "pickle.dump(d, io.BytesIO())"
-> before: 100 loops, best of 3: 13.2 msec per loop
-> after: 100 loops, best of 3: 2.54 msec per loop

* load():

./python -m timeit -s "import pickle, io; d={(x, 'a'): x  for x in range(10000)}; d=pickle.dumps(d)" "pickle.load(io.BytesIO(d))"
-> before: 100 loops, best of 3: 12.7 msec per loop
-> after: 100 loops, best of 3: 11.6 msec per loop


As you can see, load() doesn't really benefit from the buffering improvements. The three methods see quite massive speedups.

----------
Added file: http://bugs.python.org/file18778/pickle_optimizations4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9410>
_______________________________________

From report at bugs.python.org  Mon Sep  6 19:36:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 17:36:56 +0000
Subject: [issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.
In-Reply-To: <1280384767.75.0.12386540434.issue9410@psf.upfronthosting.co.za>
Message-ID: <1283794616.46.0.503444850688.issue9410@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Gosh. My patch is based on an outdated patch :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9410>
_______________________________________

From report at bugs.python.org  Mon Sep  6 20:20:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 18:20:01 +0000
Subject: [issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.
In-Reply-To: <1280384767.75.0.12386540434.issue9410@psf.upfronthosting.co.za>
Message-ID: <1283797201.53.0.0637056749447.issue9410@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, this patch merges my changes with Alexandre's previous patch. Performance is similar as the previous posted patch.

----------
Added file: http://bugs.python.org/file18779/pickle_optimizations5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9410>
_______________________________________

From report at bugs.python.org  Mon Sep  6 20:43:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Sep 2010 18:43:25 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1283798605.59.0.0282584616655.issue7418@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great, thank you!

----------
resolution: accepted -> fixed
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7418>
_______________________________________

From report at bugs.python.org  Mon Sep  6 20:50:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 18:50:13 +0000
Subject: [issue5506] io.BytesIO doesn't support the buffer protocol
In-Reply-To: <1237372813.02.0.863937398422.issue5506@psf.upfronthosting.co.za>
Message-ID: <1283799013.33.0.287580812151.issue5506@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This was committed in r84562.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5506>
_______________________________________

From report at bugs.python.org  Mon Sep  6 21:22:30 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 06 Sep 2010 19:22:30 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283800950.08.0.258540115891.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Yes Antoine, gcc only handles compilation; the linker is explicitly called through the ld_so_aix script which handles calling the native ld with the right flags to import symbols.

I will check with gcc and attach the log on Wednesday (not at work tomorrow) but there should be no problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Mon Sep  6 21:26:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 19:26:17 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283801177.86.0.271161929415.issue9754@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r84563!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9754>
_______________________________________

From report at bugs.python.org  Mon Sep  6 21:40:50 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 06 Sep 2010 19:40:50 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283802050.37.0.751805723857.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Hum, forget my previous note;I checked ld_so_aix and it actually calls $CC to handle linking not ld. I suppose gcc will call the native ld.

Anyway, I will run the test with gcc on Wednesday and know for sure if that works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Mon Sep  6 22:00:01 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 06 Sep 2010 20:00:01 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283803201.62.0.445637453781.issue4026@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

[rant: grrr, AIX is really a crappy platform; no consistency between releases; there are dozens of obvious bugs like that... anyway...]

The fact that there is no 64 bits objects in libbsd.a on AIX 6.1 is a documented bug:
http://www-01.ibm.com/support/docview.wss?uid=isg1IZ45155

They recommend to install patch APAR IZ45155.

I suppose there is nothing more we can do if the function is not available on the system. Maybe we could display a warning or error message and suggest to upgrade to a more recent patchlevel if we are on AIX and flock cannot be found?

Though if the installation is relatively up to date, there should be no problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Mon Sep  6 22:11:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 20:11:11 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283803871.89.0.235334244266.issue4026@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, I suppose if flock needs libbsd on AIX (which is quite weird in itself), and AIX fails to ship libbsd for some executable formats, then it's AIX's problem.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Mon Sep  6 22:22:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 20:22:31 +0000
Subject: [issue941346] AIX shared library fix
In-Reply-To: <1283802050.37.0.751805723857.issue941346@psf.upfronthosting.co.za>
Message-ID: <1283804547.3203.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Anyway, I will run the test with gcc on Wednesday and know for sure if
> that works.

Thank you! If it works, it's good for commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Mon Sep  6 22:23:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Sep 2010 20:23:55 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1283804635.66.0.814491587378.issue6484@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for contributing this; sorry it took so long to get a review.  Overall the tests look good (I didn't work through the logic of each test that looks up data; I'm trusting you on that part :)

Here are some comments:

1) In test_listmailcapfiles, you can use test.support.EnvironmentVarGuard and inside the test set the value of MAILCAPS.  That way you can test both cases (set and not set).

2) I notice that the listmailcapfiles docstring is inaccurate (it actually lists the *possible* locations of mailcap files, and applies only to unix).  You could file a doc bug for that, but it is not an API method so it isn't a huge deal.

3) In test_lookup I think it might be better to hardcode the expected value rather than computing it.  It would make it clearer what the test was expecting, and remove any chance that you are just repeating the algorithm that the code itself is using to compute the value.

4) Your use of EnvironmentVarGuard in GetcapsTest is not technically correct, though it does happen to work.  You should really be doing self.env = test.support.EnvironmentVarGuard().__enter__() to mimic the 'with' protocol.  It is a detail of the implementation that __enter__ returns self.

5) Why conditionalize your test on the existence of a system mailcap file?  You want a controlled environment for testing, so it is better, IMO, to just use your test mailcap file.  This will simplify your tests.
Or you could add a second test method that also does the simple checks if and only if one of the possible system mailcap files does exist, if your goal is to test that part of the code path.  (In that case you should skip the test with an appropriate message if no system mailcap files are found).

6) I don't see any reason why the test file needs to be named ".mailcap", you can specify its filename in any test where you need it.  It would indeed be better not to have a test file with a leading '.'.  Current convention would be to create a directory named 'mailcaptestdata' and put your test data files in there, but since you have only one it would in fact be OK to just put it directly in the test directory if you can come up with a clear name for it.  Alternatively you could group those tests that need it into a single test case and use the new setUpClass to create it from an embedded string and tearDownClass to delete it afterward.

Thanks again for working on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Tue Sep  7 05:02:02 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 07 Sep 2010 03:02:02 +0000
Subject: [issue9721] urlparse.urljoin() cuts off last base character with
	semicolon at url start
In-Reply-To: <1283232058.13.0.308353601536.issue9721@psf.upfronthosting.co.za>
Message-ID: <1283828522.92.0.797651443292.issue9721@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Simply applying the patch would break the testsuite of urlparse ( test_RFC3986 case of urljoin for ';' starting joinurls). The expected behavior should be trim off all receding chars until a '/'  and then join the semi-colon starting url. 2.5 behavior is the correct one.

----------
assignee:  -> orsenthil
priority: normal -> high
resolution:  -> accepted
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9721>
_______________________________________

From report at bugs.python.org  Tue Sep  7 05:26:50 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 07 Sep 2010 03:26:50 +0000
Subject: [issue1479626] Uninstall does not clean registry
Message-ID: <1283830010.56.0.600184267698.issue1479626@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

#3778 covers the same issue and has more discussion. Closing this as a duplicate.

----------
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
status: open -> closed
superseder:  -> python uninstaller leave registry entries

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1479626>
_______________________________________

From report at bugs.python.org  Tue Sep  7 05:27:28 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 07 Sep 2010 03:27:28 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1283830048.4.0.661963779238.issue3778@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +tebeka
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3778>
_______________________________________

From report at bugs.python.org  Tue Sep  7 06:06:58 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 07 Sep 2010 04:06:58 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1283832418.14.0.326536168167.issue1731717@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Tue Sep  7 06:47:28 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Sep 2010 04:47:28 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1283834848.65.0.566376501845.issue9025@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Put in a fix with r84576.  May come back to it to see if it can or should be optimized with C.  For now, this gets the job done.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Tue Sep  7 06:48:30 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Sep 2010 04:48:30 +0000
Subject: [issue9379] random.randrange behaviour problems
In-Reply-To: <1280085533.93.0.218883892309.issue9379@psf.upfronthosting.co.za>
Message-ID: <1283834910.25.0.832606391031.issue9379@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Added a doc fix to r84576.
Advice is "don't do that" ;-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9379>
_______________________________________

From report at bugs.python.org  Tue Sep  7 06:51:37 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Sep 2010 04:51:37 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1283835097.68.0.949327698412.issue7889@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r84574 and r84576.  The seed function no longer uses hash() for str, bytes, or bytearray arguments.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7889>
_______________________________________

From report at bugs.python.org  Tue Sep  7 06:57:48 2010
From: report at bugs.python.org (Alan McIntyre)
Date: Tue, 07 Sep 2010 04:57:48 +0000
Subject: [issue9720] zipfile writes incorrect local file header for large
	files in zip64
In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za>
Message-ID: <1283835468.24.0.874482196307.issue9720@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

Here's an updated patch for the py3k trunk with tests.  This pretty much doubles the runtime of test_zipfile64.py.  The patch also removes some unnecessary code from the existing test_zipfile64 tests.

Note: It looks like writestr will also suffer from a struct.pack overflow if it's given a ZipInfo with the third general purpose flag bit set.  I won't have time to address that until next weekend, probably.

----------
Added file: http://bugs.python.org/file18780/zipfile-huge-files.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9720>
_______________________________________

From report at bugs.python.org  Tue Sep  7 07:28:56 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 07 Sep 2010 05:28:56 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The following patch adds native TLS implementation for pthreads, avoiding the relatively slow and clunky default tls implemented in thread.c

----------
components: Interpreter Core
files: pthread_tls.patch
keywords: needs review, patch, patch
messages: 115742
nosy: krisvale
priority: normal
severity: normal
status: open
title: Native TLS support for pthreads
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18781/pthread_tls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Tue Sep  7 08:03:06 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 07 Sep 2010 06:03:06 +0000
Subject: [issue9787] Release the TLS lock during allocations
In-Reply-To: <1283839386.17.0.522591872287.issue9787@psf.upfronthosting.co.za>
Message-ID: <1283839386.17.0.522591872287.issue9787@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Holding the "keymutex" lock during malloc and free operations is not a good idea.  The reason is, that custom implementations of malloc and free, can use the TLS themselves.  This is, for example, true in embedded situations, where one wants to replace malloc with, e.g. appMalloc, (to monitor the memory useage of Python) and appMalloc itself uses python TLS to find the current python State.

This change makes the malloc and free calls outside the lock.  The change in PyThread_set_key_value, requiring an extra lock allocate, has no significant performance impact since this is a rare api.

----------
components: Interpreter Core
files: tlspatch.patch
keywords: patch, patch
messages: 115743
nosy: krisvale
priority: normal
severity: normal
status: open
title: Release the TLS lock during allocations
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18782/tlspatch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9787>
_______________________________________

From report at bugs.python.org  Tue Sep  7 08:43:20 2010
From: report at bugs.python.org (Michael Haubenwallner)
Date: Tue, 07 Sep 2010 06:43:20 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283841800.77.0.55356178705.issue4026@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

While I do agree this being an AIX bug, it is not a blocker here:
fcntl extension does not _depend_ on flock, it just does _prefer_ flock:
If not available, fcntl extension uses something else (fcntl IIRC), as it did (even without linking libbsd) before the AIX5.3-patch, which just added flock to the headers (the implementation in libbsd already has been there before the patch).
The problem after that AIX5.3-patch was that the compile-check found flock, and then fcntl extension failed to link due to missing libbsd.
So it's just for how to detect flock, where the most safe variant is both the compile- and link-check. When one of them fails, flock should not be flagged as available and the alternative gets used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Tue Sep  7 12:12:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Sep 2010 10:12:53 +0000
Subject: [issue9664] Make gzip module not require that underlying file object
	support seek
In-Reply-To: <1282550810.11.0.164823540463.issue9664@psf.upfronthosting.co.za>
Message-ID: <1283854373.85.0.153071483458.issue9664@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Matt: if you want to learn the file format and propose a patch, I think it would be OK for gzip to duck-type the file object and only raise an error when a seek is explicitly requested.  After all, that's the way real file objects work.  A quick glance at the code, though, indicates this isn't a trivial refactoring.  I think it should be possible in theory since one can pipe a gzipped file into gunzip, and I don't think it buffers the whole file to unzip it...but I don't know for sure. Another issue is that if the patch substantially changes the memory/performance footprint it might get rejected on that basis.

If you (or anyone else) wants to work on a patch let me know and I'll reopen the issue.

----------
nosy: +r.david.murray
type:  -> behavior
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9664>
_______________________________________

From report at bugs.python.org  Tue Sep  7 12:16:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Sep 2010 10:16:53 +0000
Subject: [issue9759] GzipFile object should raise ValueError on .read() after
	.close()
In-Reply-To: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>
Message-ID: <1283854613.19.0.362191561977.issue9759@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +easy
nosy: +pitrou
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9759>
_______________________________________

From report at bugs.python.org  Tue Sep  7 12:22:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Sep 2010 10:22:14 +0000
Subject: [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>
Message-ID: <1283854934.99.0.9284956823.issue9761@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that issue 6074 may be relevant to your problem.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9761>
_______________________________________

From report at bugs.python.org  Tue Sep  7 12:27:14 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 10:27:14 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

import atexit

@atexit.register
def goodbye1():
    print(1)
    
@atexit.register
def goodbye2():
    print(2)

The code above prints:

2
1

...that is, the last registered function is executed first.
Wouldn't the contrary be better?

----------
components: Library (Lib)
messages: 115747
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: atexit and execution order
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Tue Sep  7 12:54:39 2010
From: report at bugs.python.org (desolat)
Date: Tue, 07 Sep 2010 10:54:39 +0000
Subject: [issue6074] .pyc files created readonly if .py file is readonly,
	python won't overwrite
In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za>
Message-ID: <1283856879.37.0.339103639849.issue6074@psf.upfronthosting.co.za>


Changes by desolat <nuabaranda at web.de>:


----------
nosy: +desolat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6074>
_______________________________________

From report at bugs.python.org  Tue Sep  7 12:54:53 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Sep 2010 10:54:53 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1283856893.07.0.0963933176126.issue9786@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good.
Apart from PyGILState_Ensure(), are there other parts of the code that use these functions?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Tue Sep  7 12:59:18 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 07 Sep 2010 10:59:18 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1283857158.43.0.208976118383.issue9788@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I'm sure you can craft cases where one order is preferable to
another, but I don't think you can make the case in general
that first in, first out is preferable to last in, first out,
or any other ordering of exit functions.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Tue Sep  7 13:07:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Sep 2010 11:07:25 +0000
Subject: [issue9748] .inputrc magic-space breaks interactive mode
In-Reply-To: <1283480225.9.0.883250017145.issue9748@psf.upfronthosting.co.za>
Message-ID: <1283857645.55.0.972554496832.issue9748@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/issue9748>
_______________________________________

From report at bugs.python.org  Tue Sep  7 13:15:51 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Sep 2010 11:15:51 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1283858151.8.0.440353059252.issue9784@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

FNFCIREAD &co are macros to help the definition of callback functions:
http://msdn.microsoft.com/en-us/library/ff797940.aspx

"hf" is defined as INT_PTR, but the value it receives is the result of FNFCIOPEN(), which fits in int.
It is safe to cast "hf" to an int if you want to disable the warning.

----------
keywords: +easy
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Tue Sep  7 13:32:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Sep 2010 11:32:46 +0000
Subject: [issue9763] Crashes upon run after syntax error encountered in OSX
	10.5.8
In-Reply-To: <1283542973.95.0.133487128669.issue9763@psf.upfronthosting.co.za>
Message-ID: <1283859166.26.0.36732240241.issue9763@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If this is a problem with the Apple supplied tk there isn't much we can do about it from the Python end.  We've had a number of other bugs like that...

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9763>
_______________________________________

From report at bugs.python.org  Tue Sep  7 13:59:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 11:59:43 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1283860783.96.0.961106404451.issue9788@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/issue9788>
_______________________________________

From report at bugs.python.org  Tue Sep  7 14:51:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 12:51:52 +0000
Subject: [issue8772] sysconfig: _get_default_scheme can be made public?
In-Reply-To: <1274315831.51.0.95937905223.issue8772@psf.upfronthosting.co.za>
Message-ID: <1283863912.15.0.484204549757.issue8772@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I wonder if the scheme names could be made more consistent, removing the need for a function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8772>
_______________________________________

From report at bugs.python.org  Tue Sep  7 14:53:15 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Sep 2010 12:53:15 +0000
Subject: [issue9789] Explicit buffer release for memoryview objects
In-Reply-To: <1283863995.38.0.252730681612.issue9789@psf.upfronthosting.co.za>
Message-ID: <1283863995.38.0.252730681612.issue9789@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

memoryview objects currently offer no way to explicitly release the underlying buffer.

This may cause problems for mutable objects that are locked while PEP 3118 buffer references remain unreleased (e.g. in 3.2, io.BytesIO supports getbuffer() for direct access to the underlying memory, but disallows resizing until the associated memoryview goes away).

This isn't too bad in CPython due to explicit refcounting, but may be an issue when using other implementations since the time between release of the last reference and actual garbage collection is indeterminate. For example, the new test_getbuffer in the BytesIOMixin class in the test suite relies on "del buf" promptly releasing the underlying PEP 3118 buffer, which may not be the case on other implementations.

So there are two separate questions here:
1. Whether or not to add an explicit "release()" method to memoryview objects (this would be sufficient to address the problem)
2. Whether or not to add direct context management support to memoryview objects (this isn't really necessary, since a short context manager can do the same thing, but may be a nice convenience)

Nosy list members added based on relevant python-dev discussion where GvR previously nixed part 2 of the idea. At the time, I hadn't really separated the two questions properly in my mind, but I suspect the failing to do something about the first one will prove problematic in the long run (or even the short run, as the test suite issue suggests).

----------
messages: 115753
nosy: gvanrossum, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Explicit buffer release for memoryview objects
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9789>
_______________________________________

From report at bugs.python.org  Tue Sep  7 14:55:22 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Sep 2010 12:55:22 +0000
Subject: [issue9789] Explicit buffer release for memoryview objects
In-Reply-To: <1283863995.38.0.252730681612.issue9789@psf.upfronthosting.co.za>
Message-ID: <1283864122.76.0.631109397279.issue9789@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The test suite actually does force a GC collection cycle, so the test may be more portable than I first thought, but the need to do that suggests an explicit buffer release API may be a more appropriate solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9789>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:10:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 13:10:14 +0000
Subject: [issue9789] Explicit buffer release for memoryview objects
In-Reply-To: <1283863995.38.0.252730681612.issue9789@psf.upfronthosting.co.za>
Message-ID: <1283865014.25.0.859056033149.issue9789@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

See the context management patch at #9757.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9789>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:20:48 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 13:20:48 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1283865648.4.0.675789084242.issue9788@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I think it's not a matter of "preferable" but "most expected" and I see FIFO as the most expected behavior in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:28:18 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Sep 2010 13:28:18 +0000
Subject: [issue9789] Explicit buffer release for memoryview objects
In-Reply-To: <1283863995.38.0.252730681612.issue9789@psf.upfronthosting.co.za>
Message-ID: <1283866098.44.0.252822502358.issue9789@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for that link. Compared to what either of us managed in the original thread, I think my first post here better articulates why the ability to explicitly release the buffer is important - not because of general memory usage, but because the object owning the buffer (e.g. a BytesIO instance) may behave differently while the buffer reference exists.

It wasn't until I saw the actual getbuffer() patch on python-checkins that this rationale actually clicked for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9789>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:31:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 13:31:56 +0000
Subject: [issue919238] Recursive variable definition causes sysconfig infinite
	loop
Message-ID: <1283866316.12.0.428230586054.issue919238@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the patch. Review:

1) Why not raise an exception? A recursive variable definition is an error. Tarek, is this behavior change OK?

2) Does this apply to the new top-level sysconfig module and/or distutils.sysconfig?

3) I?d use a more specific name for the test method: test_bogus_variable instead of test_parse_makefile. I would also add a test for SELF=$(SELF) (currently there is only a test for cyclic definition, not recursive).

4) os.unlink(makefile) is not guaranteed to run, for example if the test is stopped or crashes. Put self.addCleanup(os.unlink, makefile) after the mkstemp call instead.

5) I didn?t know there was no ?if __name__ == '__main__'? block in this test file, nice catch. There is no need for the intermediate test_main function, though: unittest.main() should be enough.

6) Minor style issues: You can use textwrap.dedent to keep the file contents in the os.write call indented; s/you're/your/; no need to del fd; put spaces around operators (here == and =); don?t add tree blank lines. See PEP 8 for more info.

----------
assignee:  -> tarek
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue919238>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:32:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 13:32:50 +0000
Subject: [issue9031] distutils uses invalid "-Wstrict-prototypes" flag when
	compiling C++ extension module
In-Reply-To: <1276891952.43.0.0434978352487.issue9031@psf.upfronthosting.co.za>
Message-ID: <1283866370.43.0.620734862697.issue9031@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
stage:  -> committed/rejected
superseder:  -> C++ compilation support for distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9031>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:37:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Sep 2010 13:37:10 +0000
Subject: [issue9789] Explicit buffer release for memoryview objects
In-Reply-To: <1283863995.38.0.252730681612.issue9789@psf.upfronthosting.co.za>
Message-ID: <1283866630.98.0.184457758732.issue9789@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9789>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:37:30 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Sep 2010 13:37:30 +0000
Subject: [issue9789] Explicit buffer release for memoryview objects
In-Reply-To: <1283863995.38.0.252730681612.issue9789@psf.upfronthosting.co.za>
Message-ID: <1283866650.19.0.547925147703.issue9789@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
superseder:  -> Add context manager protocol to memoryviews

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9789>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:41:15 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Sep 2010 13:41:15 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283526664.21.0.538599282287.issue9757@psf.upfronthosting.co.za>
Message-ID: <1283866875.99.0.781499966507.issue9757@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I closed 9789 as a duplicate of this. Bringing the details from that issue over here:
====================================
memoryview objects currently offer no way to explicitly release the underlying buffer.

This may cause problems for mutable objects that are locked while PEP 3118 buffer references remain unreleased (e.g. in 3.2, io.BytesIO supports getbuffer() for direct access to the underlying memory, but disallows resizing until the associated memoryview goes away).

This isn't too bad in CPython due to explicit refcounting, but may be an issue when using other implementations since the time between release of the last reference and actual garbage collection is indeterminate. For example, the new test_getbuffer in the BytesIOMixin class in the test suite can't rely on "del buf" promptly releasing the underlying PEP 3118 buffer, so it is forced to also invoke a full GC collection cycle in order to be portable to other implementations.

So there are two separate questions here:
1. Whether or not to add an explicit "release()" method to memoryview objects (this would be sufficient to address the problem)
2. Whether or not to add direct context management support to memoryview objects (this isn't really necessary, since a short context manager can do the same thing, but may be a nice convenience)

Guido was -0 on the idea of supporting the context management protocol, but the rationale presented to him at the time was lacking the key concept of behavioural changes in the object owning the buffer based on whether or not there were any outstanding buffer references.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9757>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:42:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 13:42:21 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1283866941.43.0.513902623456.issue9786@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Just tried to apply the patch:
- test_capi now freezes in auto-thread-state
- test_threading now freezes in test_finalize_runnning_thread

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:44:03 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 07 Sep 2010 13:44:03 +0000
Subject: [issue9790] ntpath contains imports inside functions
In-Reply-To: <1283867043.1.0.607515525376.issue9790@psf.upfronthosting.co.za>
Message-ID: <1283867043.1.0.607515525376.issue9790@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

As pointed out by Nick Coghlan on python-dev, ntpath.samefile and ntpath.sameopenfile are vulnerable to deadlock because they contain imports.

----------
assignee: brian.curtin
components: Extension Modules, Windows
files: review_email.txt
messages: 115761
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: ntpath contains imports inside functions
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18783/review_email.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9790>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:48:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 13:48:09 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1283867289.22.0.658567274515.issue1222585@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Arfrever?s patch looks good. There is no tests for detect_language now; should the patch be blocked by that?

(Note: Remember to use ?hg import --user 'Arfrever Frehtes Taifersar Arahesis <preferred email>'? to give proper credit)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Tue Sep  7 16:17:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 14:17:26 +0000
Subject: [issue9787] Release the TLS lock during allocations
In-Reply-To: <1283839386.17.0.522591872287.issue9787@psf.upfronthosting.co.za>
Message-ID: <1283869046.04.0.862791562332.issue9787@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You have a bug in PyThread_delete_key_value() (to_free = NULL?).
Also, you should move the "/* NB This does *not* free p->value! */" comments at the right places.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9787>
_______________________________________

From report at bugs.python.org  Tue Sep  7 16:20:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 14:20:40 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1283869240.7.0.681341164759.issue9788@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

LIFO looks preferable if you want your setup/teardown code to be properly nested (that is, if I set up A before B, I want B to be torn down before A).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Tue Sep  7 16:37:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 14:37:02 +0000
Subject: [issue9270] distutils.util.getplatform and sysconfig.getplatform
	differ
In-Reply-To: <1279250878.74.0.870585975763.issue9270@psf.upfronthosting.co.za>
Message-ID: <1283870222.81.0.52259563.issue9270@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report. I just checked 2.7 and 3.2 (by monkey-patching os.uname to return something with a space and calling the two get_platform) and this is fixed (both use an underscore), probably thanks to the freeze and revert of distutils.

----------
nosy: +eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9270>
_______________________________________

From report at bugs.python.org  Tue Sep  7 16:38:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 14:38:17 +0000
Subject: [issue9250] sys.modules changes size during iteration in regrtest
	module
In-Reply-To: <1279038973.54.0.16228117882.issue9250@psf.upfronthosting.co.za>
Message-ID: <1283870297.64.0.785756601369.issue9250@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9250>
_______________________________________

From report at bugs.python.org  Tue Sep  7 16:46:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 14:46:53 +0000
Subject: [issue1299] distutils.sysconfig is not cross-platform compatible
In-Reply-To: <1192727810.38.0.522851261061.issue1299@psf.upfronthosting.co.za>
Message-ID: <1283870813.1.0.779992714232.issue1299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is this still relevant for the new sysconfig module? Tests would be a valuable addition.

----------
components: +Library (Lib) -Build, Distutils
nosy: +eric.araujo
type: compile error -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1299>
_______________________________________

From report at bugs.python.org  Tue Sep  7 16:47:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 14:47:07 +0000
Subject: [issue1299] distutils.sysconfig is not cross-platform compatible
In-Reply-To: <1192727810.38.0.522851261061.issue1299@psf.upfronthosting.co.za>
Message-ID: <1283870827.94.0.974685407097.issue1299@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1299>
_______________________________________

From report at bugs.python.org  Tue Sep  7 16:50:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 14:50:27 +0000
Subject: [issue3992] remove custom log module from distutils2
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1283871027.05.0.0506758252711.issue3992@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Status update:

- site does not depend on distutils anymore in 2.7 and 3.2, now that distutils.sysconfig has been move to sysconfig.

- distutils is frozen, so it won?t get a refactor.

- Tarek is nearly done removing log in distutils2. Command.warn can also just use logging.warn to make things consistent.

----------
components: +Distutils2 -Distutils
title: removed custom log from distutils -> remove custom log module from distutils2
versions: +Python 2.5, Python 2.6, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Tue Sep  7 16:51:18 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 07 Sep 2010 14:51:18 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283871078.3.0.375167820076.issue4026@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is a new test for flock. HAVE_FLOCK is defined if we can link a C application calling flock, or if flock is defined in libbsd.
FLOCK_NEEDS_LIBBSD is also defined in the second case.

AC_MSG_CHECKING(for flock)
have_flock=no
AC_TRY_LINK([
#include "confdefs.h" 
#include <sys/file.h>
], [void* p = flock; flock(0, 0)],
  [AC_CHECK_LIB(bsd,flock, [
    AC_DEFINE(FLOCK_NEEDS_LIBBSD, 1, Define if flock needs to be linked with bsd library.)
    have_flock=yes
    ])],
  [have_flock=yes]
)
if test "$have_flock" = yes ; then
  AC_DEFINE(HAVE_FLOCK, 1, Define if you have the 'flock' function.)
fi
AC_MSG_RESULT($have_flock)

I think that this new test would also cover your case with a broken AIX libbsd? [I haven't actually tried to compile it yet, if the behavior is OK I will test it in both autoconf formats and provide some new patches tomorrow]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Tue Sep  7 16:59:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 14:59:12 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1283871552.26.0.809714499377.issue9788@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It seems to me that atexit is simple by design: It registers callables that do one thing, period. If you have dependencies in your cleanup code, you should write a function doing the Right Thing? and register that. This keeps the implementation simple, otherwise we?d have to debate LIFO vs. FIFO, adding an argument to register vs. exposing the list of callables,?etc.

If you agree, I could make a patch to make the docs more explicit about atexit?s simplicity and lack of guarantee about run order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:02:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 15:02:21 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283871741.54.0.639972369458.issue4026@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've just merged S?bastien's patches in r84584 (3.x), r84585 (2.7) and r84586 (3.1). If you'd like to improve the fixes (as per your latest message), please say so, otherwise I'll close the issue.

(and thanks for your contributions!)

----------
resolution:  -> fixed
status: open -> pending
versions:  -Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:12:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 15:12:42 +0000
Subject: [issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.
In-Reply-To: <1280384767.75.0.12386540434.issue9410@psf.upfronthosting.co.za>
Message-ID: <1283872362.08.0.210599904856.issue9410@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, here are the unladen swallow benchmark results against stock py3k:

### pickle ###
Min: 1.644222 -> 0.812691: 2.0232x faster
Avg: 1.652311 -> 0.814994: 2.0274x faster
Significant (t=297.660908)
Stddev: 0.00594 -> 0.00207: 2.8732x smaller

### unpickle ###
Min: 2.802217 -> 0.751013: 3.7312x faster
Avg: 2.807074 -> 0.752646: 3.7296x faster
Significant (t=980.311525)
Stddev: 0.00446 -> 0.00145: 3.0831x smaller

### pickle_dict ###
Min: 0.744259 -> 0.543992: 1.3681x faster
Avg: 0.747806 -> 0.545883: 1.3699x faster
Significant (t=114.070170)
Stddev: 0.00266 -> 0.00293: 1.1014x larger

### pickle_list ###
Min: 2.058899 -> 1.212566: 1.6980x faster
Avg: 2.066486 -> 1.216711: 1.6984x faster
Significant (t=269.964154)
Stddev: 0.00534 -> 0.00459: 1.1635x smaller

### unpickle_list ###
Min: 1.458531 -> 0.313154: 4.6576x faster
Avg: 1.464023 -> 0.319126: 4.5876x faster
Significant (t=425.745063)
Stddev: 0.00476 -> 0.00367: 1.2976x smaller

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9410>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:18:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 15:18:17 +0000
Subject: [issue1053365] nntplib: add support for NNTP over SSL
Message-ID: <1283872697.41.0.508672437998.issue1053365@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch in #1926 is more modern and up-to-date, closing as duplicate.

----------
nosy: +pitrou
resolution:  -> duplicate
stage: unit test needed -> 
status: open -> closed
superseder:  -> NNTPS support in nntplib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1053365>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:18:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 15:18:53 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1283872733.1.0.389274900361.issue8324@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Implemented by Konrad and merged into the main repo.

----------
resolution: accepted -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:21:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 15:21:53 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1283872913.45.0.531008270379.issue1926@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch might need a little reworking to make it work under 3.x, although probably not much.
It should also, IMHO, take an instance of the new SSLContext class (*) as a parameter, rather than the keyfile and certfile args.

(*) http://docs.python.org/dev/library/ssl.html#ssl-contexts

----------
assignee: janssen -> 
nosy: +giampaolo.rodola
stage: unit test needed -> patch review
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:23:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 15:23:03 +0000
Subject: [issue8312] Add post/pre hooks for distutils commands
In-Reply-To: <1270418101.32.0.698965190272.issue8312@psf.upfronthosting.co.za>
Message-ID: <1283872983.73.0.864978069714.issue8312@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hooks implemented for any command by Konrad and merged into the main repo.

----------
resolution: accepted -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8312>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:24:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Sep 2010 15:24:12 +0000
Subject: [issue9664] Make gzip module not require that underlying file object
	support seek
In-Reply-To: <1282550810.11.0.164823540463.issue9664@psf.upfronthosting.co.za>
Message-ID: <1283873052.44.0.217663291463.issue9664@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

It is possible that only a fixed-size buffer is needed. If so, use of an alternate read mechanism could be conditioned on the underlying file(like) object not having seek.

It is also possible to direct a stream to a temporary file, but I think having the user do so explicitly is better so there are no surprises and so that the user has file reference for any further work.

Or their could be a context manager class for creating temp files from streams (or urls specifically) and deleting when done. One could then write

with TempStreamFile(urlopen('xxx') as f:
  for line in Gzipfile(fileobj=f):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9664>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:27:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Sep 2010 15:27:02 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283873222.65.0.0694267409761.issue9730@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I hope the trivial 2-byte fix does not get lost in the general issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9730>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:28:29 2010
From: report at bugs.python.org (sorin)
Date: Tue, 07 Sep 2010 15:28:29 +0000
Subject: [issue9080] Provide list prepend method (even though it's not
	efficient)
In-Reply-To: <1277467249.03.0.329544397504.issue9080@psf.upfronthosting.co.za>
Message-ID: <1283873309.16.0.511984753022.issue9080@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

+1 for adding it because it will make the code easier to read/understand.
Bad performance could be documented and it's related about internal representation.

----------
nosy: +sorin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9080>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:33:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 15:33:48 +0000
Subject: [issue7894] too aggressive dependency tracking in distutils
In-Reply-To: <1265741724.72.0.383807580582.issue7894@psf.upfronthosting.co.za>
Message-ID: <1283873628.45.0.685820559025.issue7894@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I understand this is not a bug but a nicety/performance issue, so I?m reassigning to distutils2.

----------
components:  -Distutils
nosy: +eric.araujo
versions: +Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7894>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:34:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 15:34:24 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1283873664.91.0.564701525298.issue8933@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8933>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:38:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 15:38:36 +0000
Subject: [issue5411] add xz compression support to distutils
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1283873916.5.0.311795794968.issue5411@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, the distutils2 repo is http://bitbucket.org/tarek/distutils2. distutils2.tests.support contains helper to create temp directories and run commands; see docstrings and example uses in the tests for more info.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:44:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 15:44:44 +0000
Subject: [issue4673] Distutils should provide an uninstall command
In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>
Message-ID: <1283874284.29.0.517194794231.issue4673@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Status update: Josip implemented PEP 376 to provide the installation database and Alexis is working on distutils2.install_tools to provide an uninstall function. User-level tools like pip can reuse this code to provide an uninstall functionality.

----------
nosy: +alexis, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4673>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:46:56 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 07 Sep 2010 15:46:56 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283526664.21.0.538599282287.issue9757@psf.upfronthosting.co.za>
Message-ID: <1283874416.49.0.75140900093.issue9757@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Given this explanation, of course I am +1 on an explicit release() method.  But I'm still skeptical that a context manager adds much (not sure if that counts as -0 or +0 :-).

I suppose after release() is called all accesses through the memoryview object should be invalid, right?  Is this not covered by PEP 3118 at all?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9757>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:49:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Sep 2010 15:49:05 +0000
Subject: [issue7894] too aggressive dependency tracking in distutils
In-Reply-To: <1265741724.72.0.383807580582.issue7894@psf.upfronthosting.co.za>
Message-ID: <1283874545.81.0.52674526087.issue7894@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/issue7894>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:52:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 15:52:20 +0000
Subject: [issue8680] Add a sandbox in Distutils2
In-Reply-To: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>
Message-ID: <1283874740.8.0.97236676773.issue8680@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I talked a bit about that with haypo. A strong sandbox would have to intercept a number of C and Python calls to catch everything. The sandbox module in setuptools/distribute does that in 250 lines. I?m not sure it catches C code run from extension modules being built, but we could test that with haypo?s pysandbox.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8680>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:54:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 15:54:49 +0000
Subject: [issue5243] Missing dependency in distutils build
In-Reply-To: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
Message-ID: <1283874889.9.0.200349537337.issue5243@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils
nosy: +eric.araujo
versions:  -Python 2.5, Python 2.6, Python 3.0, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5243>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:55:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 15:55:55 +0000
Subject: [issue5243] Missing dependency in distutils build
In-Reply-To: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
Message-ID: <1283874955.32.0.0998400088662.issue5243@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adding back distutils1. This is a bug, not a feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5243>
_______________________________________

From report at bugs.python.org  Tue Sep  7 17:56:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 15:56:27 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283874416.49.0.75140900093.issue9757@psf.upfronthosting.co.za>
Message-ID: <1283874980.3234.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Given this explanation, of course I am +1 on an explicit release()
> method.  But I'm still skeptical that a context manager adds much (not
> sure if that counts as -0 or +0 :-).

Ok, release() is probably enough.

> I suppose after release() is called all accesses through the
> memoryview object should be invalid, right?

Indeed. The patch tests for that (it uses "with" to release the
memoryview, but it wouldn't be hard to change it for a release()
method).

> Is this not covered by PEP 3118 at all?

The PEP says ?this memory view object holds on to the memory of base
[i.e. the object the buffer was acquired from] until it is deleted?.
Apparently issues pertaining to delayed garbage collection weren't
raised at the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9757>
_______________________________________

From report at bugs.python.org  Tue Sep  7 18:01:24 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Sep 2010 16:01:24 +0000
Subject: [issue9080] Provide list prepend method (even though it's not
	efficient)
In-Reply-To: <1277467249.03.0.329544397504.issue9080@psf.upfronthosting.co.za>
Message-ID: <1283875284.69.0.120626620034.issue9080@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Sorry, this needs to stay closed.
It has no chance.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9080>
_______________________________________

From report at bugs.python.org  Tue Sep  7 18:02:29 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Sep 2010 16:02:29 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1283875349.99.0.968427179331.issue2986@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The patch changes the internal function that constructs the dict mapping b items to indexes to read as follows:
  create b2j mapping
  if isjunk function, move junk items to junk set
  if autojunk, move popular items to popular set

I helped write and test the 2.7 patch and verify that default behavior remains unchanged. I believe it is ready to commit.

3.1 and 3.2 patches will follow.

----------
stage: unit test needed -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Tue Sep  7 18:36:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 16:36:28 +0000
Subject: [issue9758] ioctl mutable buffer copying problem
In-Reply-To: <1283532852.64.0.959169848478.issue9758@psf.upfronthosting.co.za>
Message-ID: <1283877388.41.0.257123589721.issue9758@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, writing a test ended up quite easy (by re-using an existing test in test_ioctl and simply enlarging its buffer). I've committed an updated patch in r84589 (3.x), r84590 (3.1) and r84591 (2.7).
Thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9758>
_______________________________________

From report at bugs.python.org  Tue Sep  7 18:44:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 16:44:14 +0000
Subject: [issue3402] test_nis is hanging on Solaris
In-Reply-To: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za>
Message-ID: <1283877854.01.0.498398886324.issue3402@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis
versions: +Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3402>
_______________________________________

From report at bugs.python.org  Tue Sep  7 19:39:53 2010
From: report at bugs.python.org (Michael Haubenwallner)
Date: Tue, 07 Sep 2010 17:39:53 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283881193.97.0.999212290568.issue4026@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

Sorry to be pedantic - but it looks like (don't have a build environment at hand at the moment) it will fail to build as 64bit on the not-so-up-to-date AIX with missing 64bit flock implementation:
There, the compile-check will succeed and define HAVE_FLOCK, but the link-check will fail - which really should reset have_flock to 'no'.
IMO, HAVE_FLOCK should be defined when _both_ checks succeed only, not upon the compile-check only as it is done now.
Thank you!

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Tue Sep  7 20:07:10 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 07 Sep 2010 18:07:10 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1283882830.45.0.134568719936.issue9788@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't think the order should be defined.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Tue Sep  7 20:37:49 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 18:37:49 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1283884669.52.0.37614417079.issue9788@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Ok, I'll shut up then. =)

> If you agree, I could make a patch to make the docs more explicit about 
> atexit?s simplicity and lack of guarantee about run order.

Sure, go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Tue Sep  7 20:47:29 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 18:47:29 +0000
Subject: [issue9791] nntplib.py lacks a test suite
In-Reply-To: <1283885249.67.0.188742256424.issue9791@psf.upfronthosting.co.za>
Message-ID: <1283885249.67.0.188742256424.issue9791@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

A very simple test suite which tests at least basic features and methods should be written.
test_ftplib.py and test_smtplib.py can be taken as an example.
Assigning this to me as a reminder.

----------
assignee: giampaolo.rodola
components: Tests
messages: 115792
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: nntplib.py lacks a test suite
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9791>
_______________________________________

From report at bugs.python.org  Tue Sep  7 20:53:04 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 18:53:04 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1283885584.35.0.195865622021.issue1926@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Unfortunately nntplib lacks a test suite.
I created #9791 to address this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Tue Sep  7 20:59:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 18:59:20 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1283885960.7.0.291028602153.issue9360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Note that according to RFC 3977, ?The character set for all NNTP commands is UTF-8?.

But it also says this about multi-line data blocks:

   Note that texts using an encoding (such as UTF-16 or UTF-32) that may
   contain the octets NUL, LF, or CR other than a CRLF pair cannot be
   reliably conveyed in the above format (that is, they violate the MUST
   requirement above).  However, except when stated otherwise, this
   specification does not require the content to be UTF-8, and therefore
   (subject to that same requirement) it MAY include octets above and
   below 128 mixed arbitrarily.

IMO, it should decode/encode by default using utf-8 (with the "surrogateescape" error handler for easy round-tripping with non-compliant servers), except for raw articles (bodies / envelopes) where bytes should be returned.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Tue Sep  7 21:00:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 19:00:52 +0000
Subject: [issue9791] nntplib.py lacks a test suite
In-Reply-To: <1283885249.67.0.188742256424.issue9791@psf.upfronthosting.co.za>
Message-ID: <1283886052.57.0.370494335557.issue9791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, I just noticed there's some beginnings of a test file in #9360.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9791>
_______________________________________

From report at bugs.python.org  Tue Sep  7 21:07:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 19:07:32 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1283881193.97.0.999212290568.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283886447.3234.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Sorry to be pedantic - but it looks like (don't have a build
> environment at hand at the moment) it will fail to build as 64bit on
> the not-so-up-to-date AIX with missing 64bit flock implementation:
> There, the compile-check will succeed and define HAVE_FLOCK, but the
> link-check will fail - which really should reset have_flock to 'no'.
> IMO, HAVE_FLOCK should be defined when _both_ checks succeed only, not
> upon the compile-check only as it is done now.

It might be better indeed. Patches against the current SVN branches are
welcome (I don't have an AIX system to test them on, and besides I'm not
an autoconf expert).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Tue Sep  7 21:16:42 2010
From: report at bugs.python.org (Jon Anglin)
Date: Tue, 07 Sep 2010 19:16:42 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1283887002.95.0.468590701208.issue6394@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

Here is a unit test for os.getppid on Windows.  The test_os.diff file is the diff of the Lib/test/test.os.py file from the py3k svn branch.

----------
Added file: http://bugs.python.org/file18784/test_os.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Tue Sep  7 21:50:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 19:50:14 +0000
Subject: [issue9792] create_connection() recasts timeout errors
In-Reply-To: <1283889014.5.0.630828935384.issue9792@psf.upfronthosting.co.za>
Message-ID: <1283889014.5.0.630828935384.issue9792@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

When you call socket.create_connection() and it fails because it hits the socket timeout, the socket.timeout error is recast as a generic socket.error, which makes analyzing the failure more difficult (also, it means the "errno" attribute is lost for other types of errors):

>>> socket.setdefaulttimeout(0.000001)
>>> s = socket.socket()
>>> s.connect(("www.yahoo.fr", 80))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.timeout: timed out
>>> socket.create_connection(("www.yahoo.fr", 80))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/socket.py", line 319, in create_connection
    raise err
socket.error: timed out

----------
components: Library (Lib)
messages: 115798
nosy: exarkun, facundobatista, giampaolo.rodola, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: create_connection() recasts timeout errors
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9792>
_______________________________________

From report at bugs.python.org  Tue Sep  7 22:01:15 2010
From: report at bugs.python.org (Jon Anglin)
Date: Tue, 07 Sep 2010 20:01:15 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1283889675.05.0.604906558194.issue6394@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

I have uploaded a new diff file (from the py3k svn trunk) that has all of the changes in Doc/library/os.rst, Modules/posixmodule.c, and Lib/test/test_os.py.  It is called 6394.diff. Let me know if I can do anything else to make this happen.

----------
Added file: http://bugs.python.org/file18785/6394.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Tue Sep  7 22:06:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Sep 2010 20:06:50 +0000
Subject: [issue9779] argparse.ArgumentParser not support unicode in print help
In-Reply-To: <1283672170.42.0.322683308746.issue9779@psf.upfronthosting.co.za>
Message-ID: <1283890010.05.0.0947303475299.issue9779@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9779>
_______________________________________

From report at bugs.python.org  Tue Sep  7 22:14:25 2010
From: report at bugs.python.org (Dag Odenhall)
Date: Tue, 07 Sep 2010 20:14:25 +0000
Subject: [issue9793] Typo fix in What's New for 3.2: dynmaic -> dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>


New submission from Dag Odenhall <dag.odenhall at gmail.com>:

Spotted a typo reading the What's New for 3.2a2 and thought I should give contributing a fix a try. Please excuse me if I failed to follow some procedure; this is my first contribution to the core source tree.

----------
assignee: docs at python
components: Documentation
files: dynmaic.patch
keywords: patch
messages: 115800
nosy: dag.odenhall, docs at python
priority: normal
severity: normal
status: open
title: Typo fix in What's New for 3.2: dynmaic -> dynamic
versions: Python 3.2
Added file: http://bugs.python.org/file18786/dynmaic.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9793>
_______________________________________

From report at bugs.python.org  Tue Sep  7 22:15:19 2010
From: report at bugs.python.org (Michael Haubenwallner)
Date: Tue, 07 Sep 2010 20:15:19 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283890519.44.0.600081201295.issue4026@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

Using this patch based on current py3k branch I've been able now to build the fcntl module for 32bit aix5.3 (with flock) and 64bit aix5.3 (without flock), both using an old gcc-3.3.6, as well as for 64bit linux.
If necessary, I should be able to create a similar patch for the other branches tomorrow.

----------
Added file: http://bugs.python.org/file18787/flock-check-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Tue Sep  7 22:17:45 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 20:17:45 +0000
Subject: [issue9792] create_connection() recasts timeout errors
In-Reply-To: <1283889014.5.0.630828935384.issue9792@psf.upfronthosting.co.za>
Message-ID: <1283890665.37.0.503621520739.issue9792@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

On Ubuntu 10.04:

giampaolo at ubuntu:~/svn/python-3.2$ ./python 
Python 3.2a1+ (py3k:84457, Sep  3 2010, 20:18:38) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> import socket
>>> socket.setdefaulttimeout(0.000001)
>>> s = socket.socket()
>>> s.connect(("www.yahoo.fr", 80))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.timeout: timed out
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9792>
_______________________________________

From report at bugs.python.org  Tue Sep  7 22:19:04 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Sep 2010 20:19:04 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1283890744.08.0.0113125921965.issue6394@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I'm currently working on it.  I'll certainly commit it shortly with a few changes:
- no need to say that a function fails with WindowsError, at least in the docstring.
- return error sooner to reduce indentation.
- in tests, use subprocess instead of multiprocessing.
- other minor formatting nits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Tue Sep  7 22:20:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 20:20:59 +0000
Subject: [issue9792] create_connection() recasts timeout errors
In-Reply-To: <1283889014.5.0.630828935384.issue9792@psf.upfronthosting.co.za>
Message-ID: <1283890859.37.0.872075227665.issue9792@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/file18788/createconn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9792>
_______________________________________

From report at bugs.python.org  Tue Sep  7 22:50:00 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 07 Sep 2010 20:50:00 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283892600.15.0.688444911927.issue4026@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I inverted the actions in the test I proposed in msg115768 (quick note from home, should have tested at work before posting). It should be:

AC_MSG_CHECKING(for flock)
have_flock=no
AC_TRY_LINK([
#include "confdefs.h" 
#include <sys/file.h>
], [void* p = flock; flock(0, 0)],
  [have_flock=yes],
  [AC_CHECK_LIB(bsd,flock, [
    AC_DEFINE(FLOCK_NEEDS_LIBBSD, 1, Define if flock needs to be linked with bsd library.)
    have_flock=yes
    ])]
)
if test "$have_flock" = yes ; then
  AC_DEFINE(HAVE_FLOCK, 1, Define if you have the 'flock' function.)
fi
AC_MSG_RESULT($have_flock)

Mickael, does that new test works for you? I am not sure I follow your explanation: there is no more 'compile-check' (AC_TRY_COMPILE) in the new test I provided; just a 'link-check' (AC_TRY_LINK - which tests that compilation and link did work).
HAVE_FLOCK is undefined by default.
If the link-check succeeds, then HAVE_FLOCK is defined.
If it fails, then we try to look for flock in libbsd; if that test works, then HAVE_FLOCK is defined as well as FLOCK_NEEDS_LIBBSD.

In the case of broken AIX 64 bits, the link-check will fail (no flock in default C libraries); then the test to find flock in libbsd will also fail (no 64 bits objets in libbsd). So HAVE_FLOCK will be undefined, which is what you expect.

m4/autoconf is quite unintuitive so I may have made a mistake, or it may be easily misunderstood. But I intend my test to define HAVE_FLOCK only if compilation _and_ linking works, like you expect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Tue Sep  7 22:57:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Sep 2010 20:57:40 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1283893060.67.0.626696241577.issue9509@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Tue Sep  7 23:06:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 21:06:22 +0000
Subject: [issue9792] create_connection() recasts timeout errors
In-Reply-To: <1283889014.5.0.630828935384.issue9792@psf.upfronthosting.co.za>
Message-ID: <1283893582.38.0.358535800081.issue9792@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r84598. Needs backporting to 3.1 and 2.7.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9792>
_______________________________________

From report at bugs.python.org  Tue Sep  7 23:10:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 21:10:09 +0000
Subject: [issue8574] transient_internet() (test_support): use
	socket.setdefaulttimeout() and test_robotparser failure
In-Reply-To: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>
Message-ID: <1283893809.94.0.903910040626.issue8574@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Improved again and committed in r84597 and r84599. Needs backporting.

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8574>
_______________________________________

From report at bugs.python.org  Tue Sep  7 23:33:17 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Sep 2010 21:33:17 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1283895197.59.0.375746401618.issue6394@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r84601. Thanks for the patch and your perseverance!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Tue Sep  7 23:33:41 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Sep 2010 21:33:41 +0000
Subject: [issue6394] getppid support in os module on Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1283895221.49.0.754942894187.issue6394@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________

From report at bugs.python.org  Tue Sep  7 23:40:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 21:40:32 +0000
Subject: [issue8574] transient_internet() (test_support): use
	socket.setdefaulttimeout() and test_robotparser failure
In-Reply-To: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>
Message-ID: <1283895632.11.0.785047917847.issue8574@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8574>
_______________________________________

From report at bugs.python.org  Tue Sep  7 23:40:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 21:40:36 +0000
Subject: [issue9792] create_connection() recasts timeout errors
In-Reply-To: <1283889014.5.0.630828935384.issue9792@psf.upfronthosting.co.za>
Message-ID: <1283895636.37.0.533682898236.issue9792@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9792>
_______________________________________

From report at bugs.python.org  Tue Sep  7 23:41:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 21:41:51 +0000
Subject: [issue9793] Typo fix in What's New for 3.2: dynmaic -> dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1283895711.39.0.12550690048.issue9793@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed in r84602, thanks.

Note that for such small things, you don?t have to make a patch, it?s actually faster to just open the file at the right line and fix it than download and apply a patch. You can also send an email to docs at python.org instead of opening a bug, whatever is easier for you.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9793>
_______________________________________

From report at bugs.python.org  Wed Sep  8 00:03:45 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Sep 2010 22:03:45 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283874980.3234.4.camel@localhost.localdomain>
Message-ID: <AANLkTi=KsZ+NW8kQJmO=sXsRyOez+8Uiat5gtptj3-8r@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

>> Is this not covered by PEP 3118 at all?
>
> The PEP says ?this memory view object holds on to the memory of base
> [i.e. the object the buffer was acquired from] until it is deleted?.
> Apparently issues pertaining to delayed garbage collection weren't
> raised at the time.

As with a few(!) other things in relation to this PEP, the primary
consumers were most interested in the C API side of things, so we
collectively missed relevant details on the Python side.

+1 on adding release() (obviously), and +1 on direct support for
context management (it seems very analogous to file.close to me, so
direct support makes more sense than leaving it out).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9757>
_______________________________________

From report at bugs.python.org  Wed Sep  8 00:07:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 22:07:01 +0000
Subject: [issue9707] Reworked threading.local reference implementation
In-Reply-To: <1283027196.81.0.843812441705.issue9707@psf.upfronthosting.co.za>
Message-ID: <1283897221.19.0.295815825926.issue9707@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r84607.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9707>
_______________________________________

From report at bugs.python.org  Wed Sep  8 00:23:56 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 22:23:56 +0000
Subject: [issue9794] socket.create_connection context manager
In-Reply-To: <1283898235.48.0.353601830008.issue9794@psf.upfronthosting.co.za>
Message-ID: <1283898235.48.0.353601830008.issue9794@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Patch in attachment adds a context manager to socket.socket class so that  socket.create_connection() can be used with "with" statement.

----------
components: Library (Lib)
files: socket_ctx_mgr.patch
keywords: patch
messages: 115812
nosy: amaury.forgeotdarc, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: socket.create_connection context manager
versions: Python 3.2
Added file: http://bugs.python.org/file18789/socket_ctx_mgr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9794>
_______________________________________

From report at bugs.python.org  Wed Sep  8 00:28:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 22:28:32 +0000
Subject: [issue1718574] build_clib --build-clib/--build-temp option bugs
Message-ID: <1283898512.33.0.115553542287.issue1718574@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The bug has been present since the addition of those options in 2000. It is now fixed in py3k (r84608), 3.1 (r84609), 2.7 (r84610) and distutils2 (374a277616d8). Thanks!

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1718574>
_______________________________________

From report at bugs.python.org  Wed Sep  8 00:30:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 22:30:54 +0000
Subject: [issue9794] socket.create_connection context manager
In-Reply-To: <1283898235.48.0.353601830008.issue9794@psf.upfronthosting.co.za>
Message-ID: <1283898654.17.0.673527111588.issue9794@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You don't need to use socketserver. Take a look at how the other tests in test_socket are written. Inheriting from ThreadedTCPSocketTest should be easy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9794>
_______________________________________

From report at bugs.python.org  Wed Sep  8 00:41:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 22:41:07 +0000
Subject: [issue9793] Typo fix in What's New for 3.2: dynmaic -> dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1283899267.6.0.270587961006.issue9793@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9793>
_______________________________________

From report at bugs.python.org  Wed Sep  8 00:42:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 22:42:55 +0000
Subject: [issue9795] nntplib.NNTP should support the context protocol
In-Reply-To: <1283899375.28.0.82339837152.issue9795@psf.upfronthosting.co.za>
Message-ID: <1283899375.28.0.82339837152.issue9795@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

As the title says. __exit__() simply has to call self.quit(), AFAICT.

----------
components: Library (Lib)
messages: 115815
nosy: pitrou
priority: normal
severity: normal
status: open
title: nntplib.NNTP should support the context protocol
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9795>
_______________________________________

From report at bugs.python.org  Wed Sep  8 00:46:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 22:46:11 +0000
Subject: [issue9795] nntplib.NNTP should support the context protocol
In-Reply-To: <1283899375.28.0.82339837152.issue9795@psf.upfronthosting.co.za>
Message-ID: <1283899571.1.0.864250811331.issue9795@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/issue9795>
_______________________________________

From report at bugs.python.org  Wed Sep  8 01:06:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Sep 2010 23:06:22 +0000
Subject: [issue8518] small typo in http://docs.python.org/howto/doanddont.html
In-Reply-To: <1272119128.07.0.474354873892.issue8518@psf.upfronthosting.co.za>
Message-ID: <1283900782.33.0.0013652949483.issue8518@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've included my take on this in my proposed patch for issue 9608.

----------
stage:  -> committed/rejected
superseder:  -> Re-phrase best way of using exceptions in doanddont.rst
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8518>
_______________________________________

From report at bugs.python.org  Wed Sep  8 01:06:49 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 23:06:49 +0000
Subject: [issue9794] socket.create_connection context manager
In-Reply-To: <1283898235.48.0.353601830008.issue9794@psf.upfronthosting.co.za>
Message-ID: <1283900809.43.0.358800782117.issue9794@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

It wasn't easy but here it is. =)
I'll submit a patch which updates the doc tomorrow.

----------
Added file: http://bugs.python.org/file18790/socket_ctx_mgr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9794>
_______________________________________

From report at bugs.python.org  Wed Sep  8 01:07:52 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 23:07:52 +0000
Subject: [issue9794] socket.create_connection context manager
In-Reply-To: <1283898235.48.0.353601830008.issue9794@psf.upfronthosting.co.za>
Message-ID: <1283900872.51.0.805351776572.issue9794@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
assignee:  -> giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9794>
_______________________________________

From report at bugs.python.org  Wed Sep  8 01:13:04 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 23:13:04 +0000
Subject: [issue9795] nntplib.NNTP should support the context protocol
In-Reply-To: <1283899375.28.0.82339837152.issue9795@psf.upfronthosting.co.za>
Message-ID: <1283901184.61.0.236597664253.issue9795@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Assigning this to me.
Hopefully this should go into the plan of adding a context manager to all network libs (ftplib, smptlib, imaplib, etc..) in time for Python 3.2.

----------
assignee:  -> giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9795>
_______________________________________

From report at bugs.python.org  Wed Sep  8 01:15:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Sep 2010 23:15:12 +0000
Subject: [issue9608] Re-phrase best way of using exceptions in doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1283901312.89.0.891980412233.issue9608@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a more extensive rewrite that I think makes things clearer and (I hope) makes the text read better.  I also updated the preceding section per the confusion expressed in issue 8518.

Note that this patch is somewhat Python3 specific, since it assumes that all non-BaseException exceptions inherit from Exception.  If someone wants to backport it to 2.7 a paragraph or footnote should be added about that problem.

Opinions welcome.

----------
nosy: +r.david.murray
Added file: http://bugs.python.org/file18791/doanddont-except.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9608>
_______________________________________

From report at bugs.python.org  Wed Sep  8 01:21:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Sep 2010 23:21:48 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1283901708.12.0.503970600634.issue9769@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> PyUnicode_FromFormat("%s", text) expects a utf-8 buffer.

Really? I don't see how "*s++ = *f;" (where s is Py_UNICODE* and f is char*) can decode utf-8. It looks more like ISO-8859-1.

> Very recently (r84472, r84485), some C files of CPython source code
> were converted to utf-8

Python source code (C and Python) is written in ASCII except maybe some headers or some tests written in Python with #coding:xxx header (or without the header, but in utf-8, for Python3). I don't think that a C file calls PyErr_Format() or PyUnicode_FromFormat(V)() with a non-ascii format string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Wed Sep  8 01:27:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Sep 2010 23:27:05 +0000
Subject: [issue9632] Remove sys.setfilesystemencoding()
In-Reply-To: <1282132564.59.0.094866961442.issue9632@psf.upfronthosting.co.za>
Message-ID: <1283902025.8.0.929911534367.issue9632@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About "embedded Python interpreters or py2exe-style applications": do you mean that the application calls a C function to set the encoding before starting the interpreter? Or you mean the Python function, sys.setfilesystemencoding()?

I would like to remove the Python function just because it doesn't work (it doesn't reencode filenames from all Python objects). But we might keep the C function if you really want to :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9632>
_______________________________________

From report at bugs.python.org  Wed Sep  8 01:30:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Sep 2010 23:30:41 +0000
Subject: [issue9632] Remove sys.setfilesystemencoding()
In-Reply-To: <1282132564.59.0.094866961442.issue9632@psf.upfronthosting.co.za>
Message-ID: <1283902241.08.0.27605573041.issue9632@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"keep the C function"

Hum, currently, Python3 only has a *private* function called _Py_SetFileSystemEncoding() which can only be called after _Py_InitializeEx() (because it relies on the codecs API). If you consider that there is a real use case, we should create a function to set the filesystem encoding, function that should (have to?) be called before Py_InitializeEx().

I still think that Python knows better than the application how to set the encoding (when, how to choose it, etc.).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9632>
_______________________________________

From report at bugs.python.org  Wed Sep  8 01:31:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 23:31:44 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1283902304.39.0.209760907951.issue9042@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good. Another +1 from a core dev and I commit this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9042>
_______________________________________

From report at bugs.python.org  Wed Sep  8 01:44:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 07 Sep 2010 23:44:30 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za>
Message-ID: <1283903070.84.0.794258494461.issue9598@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

>From IRC:

Me: UTF-8 was not strictly valid in ANSI C comments, so it is a bug in untabify to assume UTF-8 in C files.

Merwok: Works for me.

I am lowering the priority because it looks like untabify does not fail on the current code base.  I'll follow up on python-dev to find out whether ASCII or UTF-8 should be enforced by untabify.

----------
assignee:  -> belopolsky
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9598>
_______________________________________

From report at bugs.python.org  Wed Sep  8 01:54:13 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Sep 2010 23:54:13 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1283903653.58.0.315895543376.issue9769@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> > PyUnicode_FromFormat("%s", text) expects a utf-8 buffer.
> Really?

The *format* looks more like latin-1, right. But the payload of a "%s" item is decoded as utf-8.

> I don't think that a C file calls PyErr_Format() or
> PyUnicode_FromFormat(V)() with a non-ascii format string.

At the moment, it's true. My remark is that utf-8 tend to be applied to all kind of files; if someone once decide that non-ascii chars are allowed in (some) string constants, they will be stored in utf-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:04:21 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Sep 2010 00:04:21 +0000
Subject: [issue9793] Typo fix in What's New for 3.2: dynmaic -> dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1283904261.79.0.681445255407.issue9793@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The sort of editing should be done *much* later.
I expect to be updating the file every few days
and occasionally running the out through a spelling
and grammar checker.  Right now, it's a work in progress
that doesn't benefit from micro-edits.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9793>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:07:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:07:00 +0000
Subject: [issue9793] Typo fix in What's New for 3.2: dynmaic -> dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1283904420.58.0.299356349848.issue9793@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry about that. I wanted to give a quick response to Dag, so I grepped for other instances of the same typo and committed; it was hasty.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9793>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:08:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:08:30 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za>
Message-ID: <1283904510.52.0.209826265325.issue9598@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Why would it be the job of untabify to report invalid non-ASCII characters in C files?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9598>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:19:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:19:08 +0000
Subject: [issue9199] distutils upload command crashes when displaying server
	response
In-Reply-To: <1278596334.3.0.531936724428.issue9199@psf.upfronthosting.co.za>
Message-ID: <1283905148.04.0.526572807372.issue9199@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed in py3k, 3.1, 2.7 (r84611 through r84616) and distutils2 (ea174f2c7d8e). Thanks for the report.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9199>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:29:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Sep 2010 00:29:53 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1283904510.52.0.209826265325.issue9598@psf.upfronthosting.co.za>
Message-ID: <AANLkTinKczQg6JzRgr6hht5m_zM8K7g3e2_TVyvwnEyo@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Sep 7, 2010 at 8:08 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> Why would it be the job of untabify to report invalid non-ASCII characters in C files?
>
Since untabify works by loading C code as text, it has to assume some
encoding.   Failing with uncaught decode error (as it currently does
on non UTF-8 source) is not very user friendly.  For example, the
diagnostic does not report the position of the offending character and
does not explain how to fix the source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9598>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:31:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:31:54 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za>
Message-ID: <1283905914.86.0.530234840954.issue9598@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My real question was: Shouldn?t this be a VCS hook instead of untabify?s job? (or in addition to untabify if you insist)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9598>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:36:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:36:42 +0000
Subject: [issue9424] Disable unittest.TestCase.assertEquals and assert_ during
	a regrtest run
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1283906202.03.0.158064964214.issue9424@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #5846

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9424>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:43:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:43:41 +0000
Subject: [issue9796] Add summary tables for unittest API
In-Reply-To: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>
Message-ID: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Suggestion from Raymond: Add a table summarizing all assert* methods of TestCase. I will make a patch in some days or weeks. I think I?ll also add one table for the most useful objects from a user viewpoint (Loader, TestCase, main). See the docs of itertools and collections for examples of such summary tables.

----------
assignee: eric.araujo
components: Documentation
messages: 115833
nosy: eric.araujo, michael.foord, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add summary tables for unittest API
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9796>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:49:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:49:56 +0000
Subject: [issue9608] Re-phrase best way of using exceptions in doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1283906996.33.0.0622228061386.issue9608@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Your rewrite makes the text much clearer in my opinion. Here are some nits for you to grind, cheers :)

1) I?d say ?using a bare ``except:``? and maybe add an index entry for ?bare except? referring to that section, to make indexing and maybe googling find this.

2) To make the bad examples clearer, I would remove the second inline comment (?will be changed as soon as we run it?). The wording is confusing: Does that mean the code will be changed by Python at runtime? The text after this code example is clear enough, this comment doesn?t help.

3) ?except catches all errors, including GeneratorExit which is not even an error?: Isn?t this confusing for beginners?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9608>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:51:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:51:55 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1283907115.93.0.326161404771.issue4947@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:56:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:56:05 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1283907365.69.0.328306567137.issue9788@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> eric.araujo
components: +Documentation -Library (Lib)
resolution:  -> accepted
stage:  -> needs patch
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:58:31 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 08 Sep 2010 00:58:31 +0000
Subject: [issue9762] build failures
In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>
Message-ID: <1283907511.48.0.224634127293.issue9762@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

What platform/OS is this happening on?  I've tested the PEP 3149 patch on various Ubuntu, OS X, and Debian systems and never needed this.  Not saying it's a bad patch, I just think there's something else environmental going on that I never saw for some reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9762>
_______________________________________

From report at bugs.python.org  Wed Sep  8 03:10:42 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 08 Sep 2010 01:10:42 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1283908242.39.0.434460853407.issue9786@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

The code may need a little bit of extra work:  The pthreads machine that I have to work with is a PS3 :).
And, despite the documentation not saying, I suspect that pthread_getspecific() actually does mess with "errno", making it necessary to preserve "errno" when calling PyThread_get_key_value().  (The reason for this is documented in thread_nt.h)

I'll do some tests and let you know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Wed Sep  8 03:11:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Sep 2010 01:11:43 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1283905914.86.0.530234840954.issue9598@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=93bkpLAvW4G1q-DxCJa-NVD=TbmKd=xHVdusM@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Sep 7, 2010 at 8:31 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> My real question was: Shouldn?t this be a VCS hook instead of untabify?s job? (or in addition to untabify if you insist)
>

Yes,  VCS hook makes sense (and may almost eliminate the need to
handle invalid bytestreams in untabify).  The hard question is still
the same, though: are non-ascii characters allowed in python C code?
My answer is "no".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9598>
_______________________________________

From report at bugs.python.org  Wed Sep  8 03:13:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 01:13:14 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za>
Message-ID: <1283908394.65.0.576393704423.issue9598@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree with your reply (that?s what I meant with ?works for me?, the question about untabify vs. hooks only occurred to me after our IRC exchange).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9598>
_______________________________________

From report at bugs.python.org  Wed Sep  8 03:16:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Sep 2010 01:16:42 +0000
Subject: [issue9608] Re-phrase best way of using exceptions in doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1283908602.26.0.881794173078.issue9608@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

(1) and (2) are good ideas.  For (3), would it be clear enough if it read "``except:`` catches *all* exceptions, [...] and GeneratorExit (which is not an error and should not normally be caught by user code)."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9608>
_______________________________________

From report at bugs.python.org  Wed Sep  8 03:25:25 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 08 Sep 2010 01:25:25 +0000
Subject: [issue7402] reduce() is an anti-example in "Idioms and Anti-Idioms"
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1283909125.92.0.698908555026.issue7402@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7402>
_______________________________________

From report at bugs.python.org  Wed Sep  8 03:57:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 01:57:12 +0000
Subject: [issue7402] Imrpove reduce example in doanddont.rst
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1283911032.43.0.240045577484.issue7402@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree with Raymond that the example should be kept. We could add a comment explaining the difference with sum: reduce + operator.add works with all types. (sum would be marked up so that a link gets generated.)

Is there a subsection about functional programming yet? reduce, filter and map are not always easy to use, especially now that they are lazy and thus can?t be used as a poor man?s for loop (i.e. for side effects, no to build a list). Such a section would be short and link to the functional programming howto.

In the long term, integrating David Goodger?s document into the main docs so that it gets more exposure and more updates seems very useful to me.

----------
title: reduce() is an anti-example in "Idioms and Anti-Idioms" -> Imrpove reduce example in doanddont.rst
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7402>
_______________________________________

From report at bugs.python.org  Wed Sep  8 03:57:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 01:57:19 +0000
Subject: [issue7402] Improve reduce example in doanddont.rst
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1283911039.87.0.546515654916.issue7402@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Imrpove reduce example in doanddont.rst -> Improve reduce example in doanddont.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7402>
_______________________________________

From report at bugs.python.org  Wed Sep  8 03:58:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 01:58:31 +0000
Subject: [issue9608] Re-phrase best way of using exceptions in doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1283911111.9.0.341831628223.issue9608@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It would.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9608>
_______________________________________

From report at bugs.python.org  Wed Sep  8 04:11:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 02:11:38 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1283911898.53.0.404085765464.issue4359@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the future sysconfig module (http://bitbucket.org/tarek/distutils2/src/tip/docs/design/wiki.rst) addresses part of the issue: It will use a configparser file to store installation directories. There is nothing about other build-time variables, though; this could be added to finally remove the brittle Makefile parsing in sysconfig.

There is no bug to track this work that I know of.

----------
components: +Distutils2, Library (Lib) -Distutils
nosy: +eric.araujo, fdrake
versions: +Python 3.2 -Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4359>
_______________________________________

From report at bugs.python.org  Wed Sep  8 04:42:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 02:42:19 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1283913739.54.0.654731625837.issue6087@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What ./configure line did you use?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Wed Sep  8 04:49:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 02:49:24 +0000
Subject: [issue6114] distutils build_ext path comparison only based on strings
In-Reply-To: <1243335359.03.0.865660639037.issue6114@psf.upfronthosting.co.za>
Message-ID: <1283914164.3.0.757118826373.issue6114@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report and patch.

I just tested that When the executable itself is symlinked (not installed, just linked from an existing installation), sys.exec_prefix and sys.executable are different. This means that a unit test (to prevent regressions) will be easy to write with the helpers in test.test_support (2.7)/test.support (3.x)/distutils2.tests.support.

os.path.samefile is not supported on Windows before 3.2; I guess we?ll have to live with that bug and just document it :(

Do you want to add tests for this? I?ll do it if you don?t.

(Out of curiosity, why are there three signed-off-by lines? Is there a secret community of distutils bug fixers using git?)

----------
assignee: tarek -> eric.araujo
components: +Distutils2
keywords: +easy
nosy: +eric.araujo
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6114>
_______________________________________

From report at bugs.python.org  Wed Sep  8 04:53:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 02:53:34 +0000
Subject: [issue6114] distutils build_ext path comparison only based on strings
In-Reply-To: <1243335359.03.0.865660639037.issue6114@psf.upfronthosting.co.za>
Message-ID: <1283914414.1.0.12245231547.issue6114@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

symlinks are not supported at all on Windows before 3.2, so we?re good, except for cygwin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6114>
_______________________________________

From report at bugs.python.org  Wed Sep  8 05:00:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 03:00:57 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1283914857.2.0.428431340901.issue8420@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Wed Sep  8 05:01:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 03:01:31 +0000
Subject: [issue9261] include higher (../../) dirs fails
In-Reply-To: <1279124437.89.0.789068978786.issue9261@psf.upfronthosting.co.za>
Message-ID: <1283914891.96.0.44042558533.issue9261@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9261>
_______________________________________

From report at bugs.python.org  Wed Sep  8 05:04:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 03:04:11 +0000
Subject: [issue4459] bdist_rpm should enable --fix-python by default
In-Reply-To: <1227969751.28.0.990351219395.issue4459@psf.upfronthosting.co.za>
Message-ID: <1283915051.74.0.944311633615.issue4459@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> rejected
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4459>
_______________________________________

From report at bugs.python.org  Wed Sep  8 06:14:48 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 08 Sep 2010 04:14:48 +0000
Subject: [issue9796] Add summary tables for unittest API
In-Reply-To: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>
Message-ID: <1283919288.97.0.718904265574.issue9796@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/issue9796>
_______________________________________

From report at bugs.python.org  Wed Sep  8 06:37:07 2010
From: report at bugs.python.org (Jon Anglin)
Date: Wed, 08 Sep 2010 04:37:07 +0000
Subject: [issue9752] MSVC Compiler warning in Python\import.c
In-Reply-To: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>
Message-ID: <1283920627.71.0.918487964932.issue9752@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

Windows provides two versions of mkdir in direct.h:
    int mkdir(const char* dirname)
    int _mkdir(const char* dirname)
The latter is the preferred function because it is conformant to the ISO C++ standard.  As you can see, neither function has a mode parameter like the Unix system call.  The directory permissions are inherited from the parent directory.

I simply defined a macro that expands to the correct version of mkdir for the system that Python is being compiled upon.  I found other instances in the Python source where similar things were done so I hope my solution is acceptable.

I have tested my solution on 32 and 64 bit builds of Python from the py3k svn trunk.

----------
keywords: +patch
nosy: +janglin
Added file: http://bugs.python.org/file18792/9752.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9752>
_______________________________________

From report at bugs.python.org  Wed Sep  8 06:49:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 08 Sep 2010 04:49:13 +0000
Subject: [issue9752] MSVC Compiler warning in Python\import.c
In-Reply-To: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>
Message-ID: <1283921353.32.0.324308741023.issue9752@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

What about using CreateDirectory?

----------
components: +Build
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9752>
_______________________________________

From report at bugs.python.org  Wed Sep  8 07:09:46 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 08 Sep 2010 05:09:46 +0000
Subject: [issue9787] Release the TLS lock during allocations
In-Reply-To: <1283839386.17.0.522591872287.issue9787@psf.upfronthosting.co.za>
Message-ID: <1283922586.19.0.0733294015521.issue9787@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

You're right.
Added a new version of the patch.

----------
Added file: http://bugs.python.org/file18793/tlspatch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9787>
_______________________________________

From report at bugs.python.org  Wed Sep  8 07:15:17 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 08 Sep 2010 05:15:17 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1283922917.47.0.983968808499.issue9786@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

"errno" is preserved by PyEval_RestoreThread(), so this isn't the issue.
What you are probably seeing is latent race conditions in the test suite, made apparent by a non-locking TLS implementation.  The test suite isn't free from those, see for example issue 8799

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Wed Sep  8 07:27:43 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 08 Sep 2010 05:27:43 +0000
Subject: [issue9752] MSVC Compiler warning in Python\import.c
In-Reply-To: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>
Message-ID: <1283923663.25.0.222695490807.issue9752@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

As far as I can tell, _mkdir(name) is equivalent to CreateDirectoryA(name, NULL), except one uses errno and the other uses GetLastErrno.  It is definitely possible that there's something I don't know, though, and the documentation doesn't explicitly state that they're equivalent.

With regard to the mode parameter, I noticed that the implementation of os.mkdir for Windows doesn't do anything with it, which probably means we can not worry about the mode parameter here as well?

os.mkdir's implementation just calls CreateDirectory(path, NULL).  The code is in a #ifdef MS_WINDOWS in posix_mkdir() in Modules/posixmodule.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9752>
_______________________________________

From report at bugs.python.org  Wed Sep  8 08:03:45 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 08 Sep 2010 06:03:45 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1283925825.87.0.526505596532.issue9786@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Hm, both the test you mention are using the (non-recursive) lock to synchronize threads.  I can't see anything wrong there.

Could you please try to replace the cod in pthread_getspecific() with this:

int err = errno
void *result = pthread_getspecific(key);
errno = err;
return result;

If this fixes those cases, then there is code somewhere that relies on errno being maintained across these calls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Wed Sep  8 09:12:07 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Sep 2010 07:12:07 +0000
Subject: [issue9796] Add summary tables for unittest API
In-Reply-To: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>
Message-ID: <1283929927.42.0.993564738731.issue9796@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Just focus on the table for assert* methods.  This is the one category that users will need to look-up over and over again.  The goal is to make the docs more usable, not more voluminous.

Also, I suggest finding meaningful groupings (don't stick with alpha order) and including a short plain assert-statement equivalents to show what the methods actual do (this is important because many are new, some are obscure, and not all have obvious semantics):

 | assertEqual(x, y)          | assert x == y                      |
 | assertGreaterThan(x, y)    | assert x > y                       |
 | assertItemsEqual(act, exp) | assert sorted(exp) == sorted(act)  |

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9796>
_______________________________________

From report at bugs.python.org  Wed Sep  8 09:36:38 2010
From: report at bugs.python.org (Sven Rebhan)
Date: Wed, 08 Sep 2010 07:36:38 +0000
Subject: [issue6114] distutils build_ext path comparison only based on strings
In-Reply-To: <1243335359.03.0.865660639037.issue6114@psf.upfronthosting.co.za>
Message-ID: <1283931398.04.0.427442482989.issue6114@psf.upfronthosting.co.za>


Sven Rebhan <OdinsHorse at googlemail.com> added the comment:

Of course there is a secret distutils comunity using git! ;-) The three ppl mentioned there found and fixed the problem, that's why.

But back to the issue: Can we use a switch or wrapper function to change the test method for this path dependent on the OS? I'm asking because in windows there might be no symlink either and everything just works(tm).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6114>
_______________________________________

From report at bugs.python.org  Wed Sep  8 09:54:14 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 08 Sep 2010 07:54:14 +0000
Subject: [issue9632] Remove sys.setfilesystemencoding()
In-Reply-To: <1283902241.08.0.27605573041.issue9632@psf.upfronthosting.co.za>
Message-ID: <4C874121.1040407@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> "keep the C function"
> 
> Hum, currently, Python3 only has a *private* function called _Py_SetFileSystemEncoding() which can only be called after _Py_InitializeEx() (because it relies on the codecs API). If you consider that there is a real use case, we should create a function to set the filesystem encoding, function that should (have to?) be called before Py_InitializeEx().
> 
> I still think that Python knows better than the application how to set the encoding (when, how to choose it, etc.).

If you embed Python into another application, say as scripting
language for that application, that other application may have
completely different requirements for the user setup than Python
expects, e.g. for a Windows GUI application it's not feasible to
ask the user to change the environment variables via the registry
in order for Python to pick up the right encoding information.

What we'd need is a way for the embedding application to provide this
information in a way that doesn't require setting up the environment
in some special way. The application will likely have its own way
of configuring things like file system or I/O stream encodings. Think
of e.g. GTK or Qt applications as example.

The Py_InitializeEx() function sounds like a good idea to pass the
information about such important extra parameters to Python. This
could take arguments for setting the file system encoding as
well as the I/O encoding. The arguments would then override the env var
settings.

So you can remove the function, but have to keep a backdoor open
for use cases like the one I described above.

The Py_InitializeEx()
function approach would also avoid all the issues that you have
with calling _Py_SetFileSystemEncoding() after the interpreter
has been initialized.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9632>
_______________________________________

From report at bugs.python.org  Wed Sep  8 11:54:51 2010
From: report at bugs.python.org (Pete Bartlett)
Date: Wed, 08 Sep 2010 09:54:51 +0000
Subject: [issue2745] Add support for IsWow64Process
In-Reply-To: <1209774164.99.0.662005480368.issue2745@psf.upfronthosting.co.za>
Message-ID: <1283939691.52.0.432379473375.issue2745@psf.upfronthosting.co.za>


Pete Bartlett <peter.bartlett at nomura.com> added the comment:

Hi,

I am a Python user seeking an implementation of iswow64 and found this tracker. Unfortunately I don't think Martin's suggested alternative approach works.

os.environ["PROCESSOR_ARCHITECTURE"]

returns "x86" on my system when run from a 32-bit python, even though if I look at my "real" environment I see 

D:\>echo %PROCESSOR_ARCHITECTURE%
AMD64

i.e it appears that Windows is passing "false information", if you will, to whatever populates os.environ in 32-bit windows.

Perhaps Mark's patch should be resurrected. Or is there a further way to get this information?

[My Python version information:
D:\>python
ActivePython 2.6.5.12 (ActiveState Software Inc.) based on
Python 2.6.5 (r265:79063, Mar 20 2010, 14:22:52) [MSC v.1500 32 bit (Intel)] on win32
]

----------
nosy: +pcb21

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2745>
_______________________________________

From report at bugs.python.org  Wed Sep  8 12:10:00 2010
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Wed, 08 Sep 2010 10:10:00 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1283940600.53.0.605203741689.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

sorry to have to ask, but could we get some feedback please so that this issue may move forward?  currently there is a conflict between what is required and what is stated as being "absolute law".

let's imagine that it is reasonable to expect distutils2 to be used.  python proceeds with the mingw32 patches using distutils2, python 2.N is compiled and released.  an average user installs python 2.N mingw32 and they run "python setup.py install" on a package - what happens?

they get a compile error, don't they?

why do they get a compile error?

because the setup.py tries to build some c code, and at the top of *their* setup.py is "import distutils".

so you now force thousands of developers to patch allll their setup.py scripts - scripts which have worked for years - _just_ so that those packages can cope with the use of distutils2 for the mingw32 platform?

so we have another "reducto ad absurdum" which demonstrates that it is impractical to expect distutils to be frozen.

thus, we are forced to consider alternative options, such as "monkey-patching" of distutils, to satisfy the requirements.

would the following be acceptable, to be inserted somewhere in the path so that it is guaranteed to work at all times?

import mingw32_distutils_compiler
import sys
if "distutils.compiler" in sys.modules:
    sys.modules['distutils.compiler'] = mingw32_distutils_compiler


where mingw32_distutils_compiler performs an import of distutils.compiler and performs a monkey-patch mish-mash to combine and replace various parts of the compiler module at run-time, to get round the "freeze" objections.

would that be acceptable?  please say no, because the long-term viability and maintainability of such practices is virtually nil.

basically i'm pointing out to you, eric, that the freeze on distutils is unworkable and impractical and unnecessary.

this isn't "bug-fixing" of distutils, it's absolutely necessary and critically required because this is an entirely new platform.

* it's not cygwin: cygwin uses standard gcc but with weird outputs and quirks.

* it's not standard unix gcc: you need to output ".dll" not ".so"

* it's not msvc: mingw32-gcc doesn't accept "/this /that" for options.

therefore i'm very sorry to have to spell it out but a new compiler and linker type - a NEW compiler and linker type - an ADDITIONAL compiler and linker type - IS required in order to cater for this platform, and there's no getting away from that fact.

please could we have some acknowledgement of this fact, and acceptance of this fact, and a plan for moving forward with careful review of this patch, so that LRN and others do not have their time spent pursuing a direction involving distutils2 which will be completely fruitless?

many many thanks,

l.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Sep  8 12:51:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Sep 2010 10:51:54 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1283943114.38.0.164184329379.issue4947@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited my patch (with a new test, iso-8859-1:replace) to 2.7: r84621. I will no backport to 2.6 because this branch now only accept security fixes.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Wed Sep  8 13:11:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 11:11:21 +0000
Subject: [issue9797] wrong assumption in pystate.c
In-Reply-To: <1283944281.59.0.280980525234.issue9797@psf.upfronthosting.co.za>
Message-ID: <1283944281.59.0.280980525234.issue9797@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

pystate.c assumes that when autoTLSkey is 0, it hasn't been created yet. However, some TLS implementations can return 0 as a valid key value. Lots of interesting things then happen.

Here is a patch.

----------
files: autotlskey.patch
keywords: patch
messages: 115858
nosy: amaury.forgeotdarc, krisvale, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: wrong assumption in pystate.c
type: crash
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18794/autotlskey.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9797>
_______________________________________

From report at bugs.python.org  Wed Sep  8 13:12:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 11:12:39 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1283944359.06.0.491804436321.issue9786@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem turns out to be in pystate.c (my system returns 0 as a valid key number). See issue #9797.

----------
dependencies: +wrong assumption in pystate.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Wed Sep  8 13:49:06 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 08 Sep 2010 11:49:06 +0000
Subject: [issue9797] wrong assumption in pystate.c
In-Reply-To: <1283944281.59.0.280980525234.issue9797@psf.upfronthosting.co.za>
Message-ID: <1283946546.22.0.577410176028.issue9797@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Couldn't the patch use autoInterpreterState instead?
It is already modified at the same times as autoTLSkey.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9797>
_______________________________________

From report at bugs.python.org  Wed Sep  8 13:57:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 11:57:02 +0000
Subject: [issue9797] wrong assumption in pystate.c
In-Reply-To: <1283944281.59.0.280980525234.issue9797@psf.upfronthosting.co.za>
Message-ID: <1283947022.45.0.325498010542.issue9797@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, it is simpler indeed. Here is an updated patch.

----------
Added file: http://bugs.python.org/file18795/autotlskey2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9797>
_______________________________________

From report at bugs.python.org  Wed Sep  8 14:24:40 2010
From: report at bugs.python.org (Jon Anglin)
Date: Wed, 08 Sep 2010 12:24:40 +0000
Subject: [issue9752] MSVC Compiler warning in Python\import.c
In-Reply-To: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>
Message-ID: <1283948680.94.0.334579228473.issue9752@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

Visual Studio ships with the source code for the CRT (\Program Files\Microsoft Visual Studio 9.0\VC\crt\src). I looked up _mkdir. It does just call CreateDirectory(path, NULL).  If no error occurs it returns zero. If an error occurs, it then converts the result of GetLastError to an appropriate errno code and returns -1.

Thus the following calls are equivalent:
    _mkdir(dirname);
    CreateDirectory(dirname, NULL);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9752>
_______________________________________

From report at bugs.python.org  Wed Sep  8 14:33:20 2010
From: report at bugs.python.org (=?utf-8?b?0KDRg9GB0LvQsNC9INCY0LbQsdGD0LvQsNGC0L7Qsg==?=)
Date: Wed, 08 Sep 2010 12:33:20 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1283949200.85.0.564145977233.issue3871@psf.upfronthosting.co.za>


?????? ????????? <lrn1986 at gmail.com> added the comment:

A small correction to previous post: two new compiler-and-linker types, not one.

First - MinGW toolset without MSys, working with normal Windows command interpreter, which can be invoked simply by calling "cmd" (or whatever we get from %ComSpec%). Obviously, it doesn't work. Well, it works, but only ~5% of all software packages will have a makefile that doesn't have to be generated by configure script (which we can't run, since this variant of MinGW doesn't have bash) and that doesn't call any shell builtins or *nix tools. On the other hand, SCons, CMake and other build systems not based on autotools should work fine without bash and/or should be able to generate makefiles that don't rely on bash or *nix tools.

Second - MinGW toolset with MSys, working with bash, which can't be invoked by calling "sh.exe" (even if you have full absolute path to sh.exe), because you must cast a few black magic spells by calling sh.exe with "--login" to hook up /etc/profile, which sets up PATH and other environment variables; without it you won't be able to run anything that isn't in c:/msys/1.0/bin - including mingw32-gcc.exe, which lives in c:/mingw/bin, unless you'd want to duplicate /etc/profile in Python (which is possible, remind me to try that), and you have to be careful to not give it any \-separated paths (even in scaped form) at command line, because bash won't understand them, and path mangling doesn't kick in until you're *within* bash, and that includes the name of the script you want to run - it must be /-separated and not absolute (because bash will pass it as $0 without mangling).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Sep  8 14:41:36 2010
From: report at bugs.python.org (Peter Simons)
Date: Wed, 08 Sep 2010 12:41:36 +0000
Subject: [issue9798] time.tzset() doesn't properly reset the time.timezone
	variable
In-Reply-To: <1283949696.36.0.623259626087.issue9798@psf.upfronthosting.co.za>
Message-ID: <1283949696.36.0.623259626087.issue9798@psf.upfronthosting.co.za>


New submission from Peter Simons <simons at cryp.to>:

Attached are two programs that I would expect to produce the same output, but they don't.

$ python --version
Python 2.6.5

$ cat test-timezone-1.py 
import os, time

os.environ["TZ"] = "Europe/Berlin"
time.tzset()
print "time.timezone =", time.timezone

os.environ["TZ"] = "Egypt"
time.tzset()
print "time.timezone =", time.timezone

$ cat test-timezone-2.py 
import os
from time import tzset, timezone

os.environ["TZ"] = "Europe/Berlin"
tzset()
print "timezone =", timezone

os.environ["TZ"] = "Egypt"
tzset()
print "timezone =", timezone

$ python test-timezone-1.py 
time.timezone = -3600
time.timezone = -7200

$ python test-timezone-2.py 
timezone = -3600
timezone = -3600

----------
components: Library (Lib)
messages: 115864
nosy: simons
priority: normal
severity: normal
status: open
title: time.tzset() doesn't properly reset the time.timezone variable
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9798>
_______________________________________

From report at bugs.python.org  Wed Sep  8 14:42:16 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 08 Sep 2010 12:42:16 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283949736.11.0.61175132375.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here are the build logs for Python 3.1.2 modified with this patch and compiled with gcc.
The extensions are correctly built.

I also compiled an extension not directly provided in Python source (cx_Oracle) and it worked fine also.

----------
Added file: http://bugs.python.org/file18796/python312_AIX61_static_gcc_patchshared.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Wed Sep  8 14:43:13 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 08 Sep 2010 12:43:13 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283949793.71.0.233181038753.issue941346@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Added file: http://bugs.python.org/file18797/python312_AIX61_shared_gcc_patchshared.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Wed Sep  8 14:49:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 12:49:25 +0000
Subject: [issue9797] wrong assumption in pystate.c
In-Reply-To: <1283944281.59.0.280980525234.issue9797@psf.upfronthosting.co.za>
Message-ID: <1283950165.0.0.0567396459867.issue9797@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r84623 (3.x), r84627 (2.7) and r84628 (3.1).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9797>
_______________________________________

From report at bugs.python.org  Wed Sep  8 15:02:57 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 08 Sep 2010 13:02:57 +0000
Subject: [issue5416] str.replace does strange things when given a negative
	count
In-Reply-To: <1236163931.77.0.818123555808.issue5416@psf.upfronthosting.co.za>
Message-ID: <1283950977.36.0.711985058813.issue5416@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Reverted the changes in r84626 (release27-maint), r84629(py3k), r84630 (release31-maint).

- Minor doc clarification included wherein maxreplace is the argument instead of maxsplit in py27.

- Also, did not bother to remove -1 in maxreplace. It is used as sentinel value for an optional argument. As it is not explicitly documented, the negative value for arg should not be relied upon.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5416>
_______________________________________

From report at bugs.python.org  Wed Sep  8 15:29:17 2010
From: report at bugs.python.org (Michael Haubenwallner)
Date: Wed, 08 Sep 2010 13:29:17 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283952557.33.0.996373834711.issue4026@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

S?bastien, while this gives expected results on the AIX box here, it still has one subtle problem:
AC_TRY_LINK may fail due to missing declaration in <sys/file.h> _or_ due to missing implementation in libc.
The subsequent AC_CHECK_LIB won't fail when the implementation is in libbsd but the declaration is missing - this is the case on not-so-recent AIX5.3 (and the reason python worked there before).

Another minor nit is configure's output when libbsd is needed:
> checking for flock... checking for flock in -lbsd... yes
> yes

Anyway - I've hacked up another variant (with recent autoconf manual at hand), which really should cover all known situations now (additionally using cache-checks):

AC_CACHE_CHECK([for flock declaration], [ac_cv_flock_decl],
  [AC_COMPILE_IFELSE(
    [AC_LANG_PROGRAM(
      [#include <sys/file.h>],
      [void* p = flock]
    )],
    [ac_cv_flock_decl=yes],
    [ac_cv_flock_decl=no]
  )
])
if test "x${ac_cv_flock_decl}" = xyes; then
  AC_CHECK_FUNCS(flock,,
    AC_CHECK_LIB(bsd,flock,
      [AC_DEFINE(HAVE_FLOCK)
       AC_DEFINE(FLOCK_NEEDS_LIBBSD, 1, Define if flock needs to be linked with bsd library.)
    ])
  )
fi

Thank you anyway!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Wed Sep  8 15:35:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 08 Sep 2010 13:35:16 +0000
Subject: [issue9752] MSVC Compiler warning in Python\import.c
In-Reply-To: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>
Message-ID: <1283952916.78.0.528404006542.issue9752@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Thanks for looking into that.

Since we now know that there is no use for the mode parameter on Windows, let's just remove the mode related stuff (of course leaving it for other OSes). We could then remove the macro and do the #ifdef dance around the mkdir/_mkdir call.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9752>
_______________________________________

From report at bugs.python.org  Wed Sep  8 15:42:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 13:42:26 +0000
Subject: [issue9798] time.tzset() doesn't properly reset the time.timezone
	variable
In-Reply-To: <1283949696.36.0.623259626087.issue9798@psf.upfronthosting.co.za>
Message-ID: <1283953346.39.0.376793386366.issue9798@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The name ?timezone? you imported in test-timezone is bound to the object that was bound to time.timezone at the time of import. When time.timezone is bound to a new object, test-timezone.timezone does not change.

----------
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9798>
_______________________________________

From report at bugs.python.org  Wed Sep  8 15:43:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 13:43:47 +0000
Subject: [issue9798] time.tzset() doesn't properly reset the time.timezone
	variable
In-Reply-To: <1283949696.36.0.623259626087.issue9798@psf.upfronthosting.co.za>
Message-ID: <1283953427.56.0.0329294711226.issue9798@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

More information here: http://docs.python.org/tutorial/classes#a-word-about-names-and-objects

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9798>
_______________________________________

From report at bugs.python.org  Wed Sep  8 15:50:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 08 Sep 2010 13:50:02 +0000
Subject: [issue9798] time.tzset() doesn't properly reset the time.timezone
	variable
In-Reply-To: <1283949696.36.0.623259626087.issue9798@psf.upfronthosting.co.za>
Message-ID: <1283953802.68.0.132667931643.issue9798@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

#6478 looks related

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9798>
_______________________________________

From report at bugs.python.org  Wed Sep  8 15:52:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 13:52:21 +0000
Subject: [issue9798] time.tzset() doesn't properly reset the time.timezone
	variable
In-Reply-To: <1283949696.36.0.623259626087.issue9798@psf.upfronthosting.co.za>
Message-ID: <1283953941.51.0.761725856794.issue9798@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the link, but I don?t think it?s related :). Look at the sample code again, this is just a regular name/variable confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9798>
_______________________________________

From report at bugs.python.org  Wed Sep  8 16:01:26 2010
From: report at bugs.python.org (Jon Anglin)
Date: Wed, 08 Sep 2010 14:01:26 +0000
Subject: [issue9752] MSVC Compiler warning in Python\import.c
In-Reply-To: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>
Message-ID: <1283954486.67.0.0288183168221.issue9752@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

How about this: see no-macro.diff
BTW: should I be using the .patch extension or .diff extension?

----------
Added file: http://bugs.python.org/file18798/no-macro.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9752>
_______________________________________

From report at bugs.python.org  Wed Sep  8 16:23:38 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 08 Sep 2010 14:23:38 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following error when compiling the last rev of branch py3k on an AIX 6 system:

./Modules/makexp_aix Modules/python.exp . libpython3.2.a;  xlc_r -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib  -L/sgbd_product/oracle/10.2.0/lib32 -L/sgbd_product/oracle/10.2.0/lib32 -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib  -L/sgbd_product/oracle/10.2.0/lib32 -L/sgbd_product/oracle/10.2.0/lib32 -Wl,-bE:Modules/python.exp -lld -o python Modules/python.o libpython3.2.a -lintl -ldl    -lm  
ld: 0711-596 SEVERE ERROR: Object libpython3.2.a[ceval.o]
        An RLD for section 2 (.data) refers to symbol 0,
        but the storage class of the symbol is not C_EXT or C_HIDEXT.

Python 3.1.2 or Python 2.7 both compile fine.

I also tried rev 73580 of this branch which compiled fine also.

I will try to find the rev number where this problem started.

----------
messages: 115875
nosy: sable
priority: normal
severity: normal
status: open
title: Compilation error for branch py3k on AIX 6
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Wed Sep  8 16:26:16 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 08 Sep 2010 14:26:16 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1283955976.3.0.177069658055.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Antoine, I wanted to test this improvement (and others) on the branch py3k (I was using Python 2.7 and Python 3.1.2 for the moment). But I have some issues compiling this branch, even without any patch (see issue 9799).

So you may want to wait for the other issue to be resolved before to commit this patch on branch py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Wed Sep  8 16:50:40 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 08 Sep 2010 14:50:40 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1283957440.44.0.196976607662.issue9786@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ah, good to hear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Wed Sep  8 16:58:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 14:58:53 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1283957933.7.0.950049800349.issue9799@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would suggest trying r80723 and then r80724.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Wed Sep  8 17:02:01 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 08 Sep 2010 15:02:01 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1283958121.27.0.587221025447.issue6087@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Just plain

./configure

as far as I remember.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Wed Sep  8 17:19:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Sep 2010 15:19:46 +0000
Subject: [issue8849] python.exe problem with cvxopt
In-Reply-To: <4C007915.6020901@internode.on.net>
Message-ID: <1283959186.01.0.562921537638.issue8849@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

cvxopt looks like it includes a C-based extension module.  Have you reported the bug to cvxopt?  They are more likely to be able to spot the problem and determine if it is a bug in Python or their code.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8849>
_______________________________________

From report at bugs.python.org  Wed Sep  8 17:28:24 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 08 Sep 2010 15:28:24 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1283959704.9.0.980924886173.issue9799@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

For the moment I have:

r73580 = OK
r83318 = OK
r83584 = OK
r83800 = OK

r84000 = ERR
r84522 = ERR

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Wed Sep  8 17:31:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 15:31:45 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283959704.9.0.980924886173.issue9799@psf.upfronthosting.co.za>
Message-ID: <1283959900.3195.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mercredi 08 septembre 2010 ? 15:28 +0000, S?bastien Sabl? a ?crit :
> S?bastien Sabl? <sable at users.sourceforge.net> added the comment:
> 
> For the moment I have:
> 
> r73580 = OK
> r83318 = OK
> r83584 = OK
> r83800 = OK
> 
> r84000 = ERR

Then perhaps r83985 / r83986.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Wed Sep  8 18:09:54 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 08 Sep 2010 16:09:54 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1283962194.04.0.0467777730829.issue9799@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Bingo, you got it.

r73580 = OK
r83318 = OK
r83584 = OK
r83800 = OK
r83900 = OK
r83950 = OK
r83985 = OK
r83986 = ERR
r84000 = ERR
r84522 = ERR

It was commited by some guy named "antoine.pitrou" ;)

The linker thinks that we have some symbol named "0" or something like that.
I guess the xlc compiler is not happy with one of the uses of the USE_COMPUTED_GOTOS constant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Wed Sep  8 18:33:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 16:33:04 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283962194.04.0.0467777730829.issue9799@psf.upfronthosting.co.za>
Message-ID: <1283963579.3195.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Bingo, you got it.
> 
> r73580 = OK
> r83318 = OK
> r83584 = OK
> r83800 = OK
> r83900 = OK
> r83950 = OK
> r83985 = OK
> r83986 = ERR
> r84000 = ERR
> r84522 = ERR
> 
> It was commited by some guy named "antoine.pitrou" ;)
> 
> The linker thinks that we have some symbol named "0" or something like that.
> I guess the xlc compiler is not happy with one of the uses of the USE_COMPUTED_GOTOS constant.

So if you configure --without-computed-gotos, does it compile fine?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Wed Sep  8 18:52:07 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 08 Sep 2010 16:52:07 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1283964727.99.0.291901614235.issue9799@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Yes it works if I explicitly specify --without-computed-gotos

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Wed Sep  8 18:53:34 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 08 Sep 2010 16:53:34 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1283964814.65.0.798694472261.issue4026@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Thanks Michael, your new test looks fine to me.

I wanted to test it on my AIX system with branch py3k but I had some other issues (issue 9799), but I will test it tomorrow.

----------
versions: +Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Wed Sep  8 19:04:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 17:04:08 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1283965448.12.0.167860781562.issue9799@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, all traces of 0711-596 on the Web seem to point to IBM compiler errata. Apparently xlc tries to support computed gotos (which is originally a GCC-specific feature) but doesn't do it very well.

The support for computed gotos is detected automatically by the configure script; --without-computed-gotos helps override the detection.

I would close this issue as a compiler bug, especially given that there's a configure switch to circumvent it.

----------
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Wed Sep  8 20:04:04 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 08 Sep 2010 18:04:04 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1283969044.85.0.232039148909.issue6087@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/issue6087>
_______________________________________

From report at bugs.python.org  Wed Sep  8 20:07:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 18:07:10 +0000
Subject: [issue9800] Fast path for small int-indexing of lists and tuples
In-Reply-To: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>
Message-ID: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is an experiment which turns out to yield little benefits, except on micro-benchmarks such as:

$ ./python -m timeit -s "a=[1,2,3]" "a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];"

-> before: 1000000 loops, best of 3: 1.14 usec per loop
-> after: 1000000 loops, best of 3: 0.759 usec per loop

On IRC, Raymond pointed out that the long representation is not very friendly to direct manipulation for small ints, but even then it's not obvious it would benefit a lot: a large amount of time is certainly spent accessing the Python stack, manipulating reference counts, decoding opcodes and checking array bounds.

The conclusion could be that such special-casing is futile when the body of code it avoids executing isn't big enough. Also, adding runtime checks has its own performance cost (more CPU instructions to execute, possible pipeline flushes due to branch misprediction, and pollution of branch prediction caches).

----------
components: Interpreter Core
files: evalsubscr.patch
keywords: patch
messages: 115888
nosy: mark.dickinson, pitrou, rhettinger
priority: low
severity: normal
status: open
title: Fast path for small int-indexing of lists and tuples
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18799/evalsubscr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9800>
_______________________________________

From report at bugs.python.org  Wed Sep  8 20:17:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Sep 2010 18:17:18 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1283969838.58.0.438644096176.issue9769@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> My remark is that utf-8 tend to be applied to all kind of files;
> if someone once decide that non-ascii chars are allowed in (some) 
> string constants, they will be stored in utf-8.

In this case, it will be better to raise an error on non-ascii byte (character) in the format string. It's better to raise an error than to interpret utf-8 as iso-8859-1 (mojibake!). Since nobody noticed this bug (PyFormat_FromString/PyErr_Format expects ISO-8859-1), I suppose that nobody uses non-ASCII format string is always ascii.

Python builtin errors are not localised. If an application uses gettext, I suppose that the error will be raised in the Python code, not in the C API.

Attached patch changes PyFormat_FromStringV (and so PyFormat_FromString and PyErr_Format) to reject non-ascii byte (character) in the format string. I added a test and documented the format string encoding (which is now ASCII). See also #9738 for the documentation about function argument encoding.

----------
keywords: +patch
Added file: http://bugs.python.org/file18800/pyunicode_fromformat_ascii.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Wed Sep  8 20:21:47 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 08 Sep 2010 18:21:47 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1283970107.56.0.239024561322.issue9786@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/issue9786>
_______________________________________

From report at bugs.python.org  Wed Sep  8 21:14:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 19:14:16 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283526664.21.0.538599282287.issue9757@psf.upfronthosting.co.za>
Message-ID: <1283973256.28.0.309069654366.issue9757@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch adding the release() method as well.

----------
Added file: http://bugs.python.org/file18801/memcontext2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9757>
_______________________________________

From report at bugs.python.org  Wed Sep  8 21:23:22 2010
From: report at bugs.python.org (James Hutchison)
Date: Wed, 08 Sep 2010 19:23:22 +0000
Subject: [issue9801] Can not use append/extend to lists in a multiprocessing
	manager dict
In-Reply-To: <1283973802.38.0.869176624785.issue9801@psf.upfronthosting.co.za>
Message-ID: <1283973802.38.0.869176624785.issue9801@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

tested python 3.1.2

Man = multiprocessing.Manager();
d = man.dict();
d['l'] = list();
d['l'].append("hey");
print(d['l']);
>>> []

using debugger reveals a KeyError. Extend also does not work. Only thing that works is += which means you can't insert actual tuples or lists into the list. This was all done on a single process

----------
components: Library (Lib)
messages: 115891
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: Can not use append/extend to lists in a multiprocessing manager dict
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9801>
_______________________________________

From report at bugs.python.org  Wed Sep  8 21:30:31 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Wed, 08 Sep 2010 19:30:31 +0000
Subject: [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>


New submission from Matthew Woodcraft <matthew at woodcraft.me.uk>:

In CPython, the builtin max() and min() have the property that if there are items with equal keys, the first item is returned. From a quick look at their source, I think this is true for Jython and IronPython too.

I propose making this a documented guarantee.

On Python-dev, Raymond Hettinger said:
<<
That seems like a reasonable request. This behavior has been around for a very long time is unlikely to change. Elsewhere, we've made efforts to document sort stability (i.e. sorted(), heapq.nlargest(), heapq.nsmallest, merge(), etc).
>>
(<http://mail.python.org/pipermail/python-dev/2010-September/103543.html>)

I'm attaching a patch with a concrete suggestion for a change to
functions.rst, modelled on the documentation of heapq.nlargest().

----------
assignee: docs at python
components: Documentation
files: maxmin.patch
keywords: patch
messages: 115892
nosy: docs at python, mattheww
priority: normal
severity: normal
status: open
title: Document 'stability' of builtin min() and max()
type: feature request
Added file: http://bugs.python.org/file18802/maxmin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9802>
_______________________________________

From report at bugs.python.org  Wed Sep  8 21:40:34 2010
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 08 Sep 2010 19:40:34 +0000
Subject: [issue9054] pyexpat configured with "--with-system-expat" is
	incompatible with expat 2.0.1
In-Reply-To: <1277158370.27.0.787157062055.issue9054@psf.upfronthosting.co.za>
Message-ID: <1283974834.29.0.919413027772.issue9054@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

validated with 3.2, the interpreter doesn't crash anymore and all expat tests succeed.

should be applied for 2.7, 3.1 and 3.2.

----------
nosy: +doko
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9054>
_______________________________________

From report at bugs.python.org  Wed Sep  8 21:42:29 2010
From: report at bugs.python.org (James Hutchison)
Date: Wed, 08 Sep 2010 19:42:29 +0000
Subject: [issue9803] IDLE closes with save while breakpoint open
In-Reply-To: <1283974949.4.0.785258120567.issue9803@psf.upfronthosting.co.za>
Message-ID: <1283974949.4.0.785258120567.issue9803@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

I have multiple versions of python - 2.6.1 and 3.1.2. 2.6.1 is the primary install (i.e., right click on a file and "edit with IDLE" brings up 2.6), and was installed first. This issue occurs on 3.1.2, Windows XP 32-bit

If I highlight a breakpoint, run with the debugger, make a change, then save, IDLE will close all windows after saving without an error message. If I clear the breakpoint and then save, IDLE will not close. Reopening the file reveals that the save was successful. I do not need to actually be stopped at a highlighted breakpoint for this to occur (i.e. this will occur if I save at the beginning before the script has ran). If I run with 2.6.1 I do not see this issue. The save difference could be something simple, such as adding a space somewhere random.

----------
components: IDLE
messages: 115894
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: IDLE closes with save while breakpoint open
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9803>
_______________________________________

From report at bugs.python.org  Wed Sep  8 22:31:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 20:31:23 +0000
Subject: [issue9188] test_gdb fails for UCS2 builds with UCS2 gdb
In-Reply-To: <1278508669.56.0.292835810608.issue9188@psf.upfronthosting.co.za>
Message-ID: <1283977883.36.0.281942072008.issue9188@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is a patch for 3.x, tested in the following situations:
- gdb: UCS2, inferior: UCS2
- gdb: UCS2, inferior: UCS4

----------
Added file: http://bugs.python.org/file18803/test_gdb2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9188>
_______________________________________

From report at bugs.python.org  Wed Sep  8 22:48:33 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Sep 2010 20:48:33 +0000
Subject: [issue9188] test_gdb fails for UCS2 builds with UCS2 gdb
In-Reply-To: <1278508669.56.0.292835810608.issue9188@psf.upfronthosting.co.za>
Message-ID: <1283978913.0.0.795019746479.issue9188@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Tested with UCS4 gdb:
(gdb) python import sys; print hex(sys.maxunicode)
0x10ffff

using latest py3k.

Works with both UCS2 and UCS4 builds of py3k

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9188>
_______________________________________

From report at bugs.python.org  Wed Sep  8 22:49:24 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Sep 2010 20:49:24 +0000
Subject: [issue9188] test_gdb fails for UCS2 builds with UCS2 gdb
In-Reply-To: <1278508669.56.0.292835810608.issue9188@psf.upfronthosting.co.za>
Message-ID: <1283978964.85.0.835302621638.issue9188@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

where "works" means: all tests in test_gdb.py were run, and passed.

This was with a --with-pydebug-build in each case

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9188>
_______________________________________

From report at bugs.python.org  Wed Sep  8 22:52:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Sep 2010 20:52:10 +0000
Subject: [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1283979130.47.0.636947330453.issue9802@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch!

Comments:

(1) Shouldn't 'reverse=True' be omitted in the second doc addition?

(2) I'd also suggest adding a brief comment about what this means for distinct, but equal, objects;  otherwise it's not really obvious what the point of the doc addition is.

(3) As a matter of clarity, perhaps replace "this is" with "max(iterable, key=key) is", and similarly for min.

As an aside, I still like Jeffrey Yasskin's suggestion on the python-dev mailing list that the sensible definition for max would maintain the invariant that max(iterable) be equivalent to sorted(iterable)[-1];  see Alexander Stepanov's writings in e.g., http://www.cs.rpi.edu/~musser/gsd/notes-on-programming-2006-10-13.pdf for more.  But that's (a) another issue, and (b) perhaps not a significant enough benefit to be worth changing Python's semantics for.

----------
nosy: +jyasskin, mark.dickinson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9802>
_______________________________________

From report at bugs.python.org  Wed Sep  8 22:57:10 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Sep 2010 20:57:10 +0000
Subject: [issue9188] test_gdb fails for UCS2 builds with UCS2 gdb
In-Reply-To: <1278508669.56.0.292835810608.issue9188@psf.upfronthosting.co.za>
Message-ID: <1283979430.13.0.88892179187.issue9188@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

One minor quibble with the patch:

In the line:
   while i < field_length:
you're trusting that field_length has a sane value.  If field_str points somewhere readable, and field_length is huge (e.g. 0xfffffff), then gdb could sit there for a while reading all that data until it either completes, or hits memory that it can't read (leading to a python exception within gdb).

In other places in that code I used safe_range() to limit iterations to a safety threshold; I suggest the use of
  safety_limit(field_length)

But this is a minor nit.


I don't think this

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9188>
_______________________________________

From report at bugs.python.org  Wed Sep  8 23:00:26 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Sep 2010 21:00:26 +0000
Subject: [issue9188] test_gdb fails for UCS2 builds with UCS2 gdb
In-Reply-To: <1278508669.56.0.292835810608.issue9188@psf.upfronthosting.co.za>
Message-ID: <1283979626.06.0.948215142835.issue9188@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

"I don't think this" was of course a browser misfire; I meant to type "I don't think this should block committing this fix"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9188>
_______________________________________

From report at bugs.python.org  Wed Sep  8 23:01:17 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 08 Sep 2010 21:01:17 +0000
Subject: [issue9129] DoS smtpd module vulnerability
In-Reply-To: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>
Message-ID: <1283979677.59.0.862391343236.issue9129@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

No, it isn't in 2.6 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9129>
_______________________________________

From report at bugs.python.org  Wed Sep  8 23:12:14 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 08 Sep 2010 21:12:14 +0000
Subject: [issue2745] Add support for IsWow64Process
In-Reply-To: <1209774164.99.0.662005480368.issue2745@psf.upfronthosting.co.za>
Message-ID: <1283980334.91.0.504266140283.issue2745@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

os.environ["PROCESSOR_ARCHITEW6432"] will tell you the true underlying processor architecture when under WOW. Therefore, if you find that this variable exists, you are under WOW.

Example, on my 64-bit machine with a 32-bit compiled Python:

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ["PROCESSOR_ARCHITECTURE"]
'x86'
>>> os.environ["PROCESSOR_ARCHITEW6432"]
'AMD64'

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2745>
_______________________________________

From report at bugs.python.org  Wed Sep  8 23:22:50 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 08 Sep 2010 21:22:50 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283526664.21.0.538599282287.issue9757@psf.upfronthosting.co.za>
Message-ID: <1283980970.56.0.201729797352.issue9757@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On an eyeball review, the structure of do_release seems a little questionable to me. I'd be happier if view.obj and view.buf were copied to C locals and then set to NULL at the start of the function before any real work is done.

I believe the buffer release process can trigger __del__ methods (and possibly other Python code), which may currently see the memoryview in a slightly inconsistent state when reference cycles are involved. Setting these two references to NULL early should keep that from happening (the idea of using C locals to avoid this is the same concept as is employed by the Py_CLEAR macro)

For the test code, I suggest including:
- a test where release() is called inside the cm to check that __exit__ does not raise ValueError.
- check getbuffer() correctly raises ValueError
- tests that the other properties correctly raise ValueError (ndim, shape, strides, format, itemsize, suboffsets)

(For the properties, perhaps using a list of strings, a loop and getattr rather than writing each one out separately)

_check_released should perhaps also take a second argument that is used for the last two NotEqual checks. That is:

def _check_released(self, m, tp):
  ...
  self.assertNotEqual(m, memoryview(tp()))
  self.assertNotEqual(m, tp())

And then pass in tp as well as m for the respective tests.

There's also a minor typo in a comment in the tests: "called at second" should be "called a second".

Other than that, looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9757>
_______________________________________

From report at bugs.python.org  Wed Sep  8 23:24:39 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 08 Sep 2010 21:24:39 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283526664.21.0.538599282287.issue9757@psf.upfronthosting.co.za>
Message-ID: <1283981079.99.0.646122488841.issue9757@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

One other question: should IS_RELEASED use "||" rather than "&&"?

Is there any case where either of those pointers can be NULL and we still want to continue on rather than bailing out with a ValueError?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9757>
_______________________________________

From report at bugs.python.org  Wed Sep  8 23:47:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 21:47:49 +0000
Subject: [issue9804] ascii() does not always join surrogate pairs
In-Reply-To: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>
Message-ID: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is on an UCS-2 py3k build:

>>> ascii('\U00012FFF')
"'\\U00012fff'"
>>> ascii('\U0001D121')
"'\\ud834\\udd21'"

----------
components: Interpreter Core, Unicode
messages: 115905
nosy: haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: ascii() does not always join surrogate pairs
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9804>
_______________________________________

From report at bugs.python.org  Wed Sep  8 23:54:34 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 08 Sep 2010 21:54:34 +0000
Subject: [issue9129] DoS smtpd module vulnerability
In-Reply-To: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>
Message-ID: <1283982874.67.0.0891023080695.issue9129@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

You're right, I'm sorry. I looked at "Versions" field which has 2.6 set but it's not correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9129>
_______________________________________

From report at bugs.python.org  Thu Sep  9 00:06:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Sep 2010 22:06:45 +0000
Subject: [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1283983605.26.0.00251327068621.issue9802@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9802>
_______________________________________

From report at bugs.python.org  Thu Sep  9 00:08:38 2010
From: report at bugs.python.org (Ken Basye)
Date: Wed, 08 Sep 2010 22:08:38 +0000
Subject: [issue9805] Documentation on old-style formatting of dicts is overly
	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>


New submission from Ken Basye <ken.basye at gmail.com>:

>From http://docs.python.org/library/stdtypes.html#string-formatting-operations :

"When the right argument is a dictionary (or other mapping type), then the formats in the string must include a parenthesised mapping key into that dictionary inserted immediately after the '%' character."  
(with emphasis on 'must' in the HTML, BTW).  

This isn't correct:  "%s" % dict() is a perfectly legal expression with a dictionary as the right argument and no mapping key in the formats.  Indeed, if the current doc were correct, there would apparently be no way to format an empty dictionary.

How about this one-word fix:

"When the right argument is a dictionary (or other mapping type), then the formats in the string may include ..." and so on into the next sentence, and no emphasis on 'may'.






P.S. Not sure about the Type of this issue, and it's present in both 2.7 and current 3.X doc.

----------
assignee: docs at python
components: Documentation
messages: 115907
nosy: Ken.Basye, docs at python
priority: normal
severity: normal
status: open
title: Documentation on old-style formatting of dicts is overly restrictive
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9805>
_______________________________________

From report at bugs.python.org  Thu Sep  9 00:12:35 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 08 Sep 2010 22:12:35 +0000
Subject: [issue9129] DoS smtpd module vulnerability
In-Reply-To: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>
Message-ID: <1283983955.32.0.185026366723.issue9129@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Reopening. I'll backport this at some point during this week, I hope.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9129>
_______________________________________

From report at bugs.python.org  Thu Sep  9 00:28:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 22:28:02 +0000
Subject: [issue9188] test_gdb fails for UCS2 builds with UCS2 gdb
In-Reply-To: <1278508669.56.0.292835810608.issue9188@psf.upfronthosting.co.za>
Message-ID: <1283984882.85.0.419600348078.issue9188@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r84635, r84636, r84638 (3.x) and r84637 (2.7). Also prompted the creation of issue9804.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9188>
_______________________________________

From report at bugs.python.org  Thu Sep  9 00:29:00 2010
From: report at bugs.python.org (Ken Basye)
Date: Wed, 08 Sep 2010 22:29:00 +0000
Subject: [issue9805] Documentation on old-style formatting of dicts is overly
	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1283984940.33.0.465087277404.issue9805@psf.upfronthosting.co.za>


Ken Basye <ken.basye at gmail.com> added the comment:

If someone's going to fix this, perhaps they might consider also adding the following clarification sentence after 'The mapping key selects the value to be formatted from the mapping.'  

The mapping key is interpreted as a string; a key error is raised if the dictionary does not have a matching string key. 

I don't think it's worth adding it, but consider this example:
>>> d = {2:2, '2':'two'}
>>> '%(2)s' % d
'two'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9805>
_______________________________________

From report at bugs.python.org  Thu Sep  9 00:35:23 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 08 Sep 2010 22:35:23 +0000
Subject: [issue9794] socket.create_connection context manager
In-Reply-To: <1283898235.48.0.353601830008.issue9794@psf.upfronthosting.co.za>
Message-ID: <1283985323.51.0.590119528095.issue9794@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch which updates doc is in attachment.

----------
Added file: http://bugs.python.org/file18804/socket_ctx_mgr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9794>
_______________________________________

From report at bugs.python.org  Thu Sep  9 00:44:54 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 08 Sep 2010 22:44:54 +0000
Subject: [issue9794] socket.create_connection context manager
In-Reply-To: <1283898235.48.0.353601830008.issue9794@psf.upfronthosting.co.za>
Message-ID: <1283985894.87.0.317851941025.issue9794@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Committed in r84639.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9794>
_______________________________________

From report at bugs.python.org  Thu Sep  9 00:49:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 22:49:04 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283980970.56.0.201729797352.issue9757@psf.upfronthosting.co.za>
Message-ID: <1283986136.3195.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> On an eyeball review, the structure of do_release seems a little
> questionable to me. I'd be happier if view.obj and view.buf were
> copied to C locals and then set to NULL at the start of the function
> before any real work is done.

You can't do that, since PyBuffer_Release() needs the information (at
least `obj`, and then the underlying object might rely on `buf` in its
bf_releasebuffer method).

(note, this code is simply factored out from tp_dealloc)

> For the test code, I suggest including:
> - a test where release() is called inside the cm to check that
> __exit__ does not raise ValueError.
> - check getbuffer() correctly raises ValueError
> - tests that the other properties correctly raise ValueError (ndim,
> shape, strides, format, itemsize, suboffsets)

Ok. I was bit too lazy and didn't include all the API.

> (For the properties, perhaps using a list of strings, a loop and
> getattr rather than writing each one out separately)

It's more clever but less practical if there's a failure: you can't know
up front which property failed the test.

> _check_released should perhaps also take a second argument that is
> used for the last two NotEqual checks. That is:

Hmm, why not.

> There's also a minor typo in a comment in the tests: "called at
> second" should be "called a second".

Ah, thanks.

> One other question: should IS_RELEASED use "||" rather than "&&"?
> 
> Is there any case where either of those pointers can be NULL and we
> still want to continue on rather than bailing out with a ValueError?

Well, view.obj can be NULL in case the buffer has been filled by hand by
some C code which simply wants to export a lazy view to some chunk of
memory (the IO lib uses this).

I could simply test for view.buf. I was thinking that maybe NULL could
be a proper data pointer on some platforms, but that would probably be
crazy (since using NULL as "non initialized" or "failed doing something"
is so common in C code).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9757>
_______________________________________

From report at bugs.python.org  Thu Sep  9 00:50:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Sep 2010 22:50:58 +0000
Subject: [issue9804] ascii() does not always join surrogate pairs
In-Reply-To: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>
Message-ID: <1283986258.88.0.514374492661.issue9804@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

For unicode, ascii(x) is implemented as repr(x).encode('ascii', 'backslashreplace').decode('ascii').

repr(x) is "'" + x + "'" for printable characters (eg. U+1D121), and "'U+%08x'" % ord(x) for not printable characters (eg. U+12FFF).

About the unexpected output, the problem is that ascii+backslashreplace encodes non-BMP printable characters as b'\\uXXXX\\uXXXX' in narrow builds.

I don't see simple solution to encode non-BMP characters as b'\\UXXXXXXXX' because the principle of error handler is that it escapes non encodable characters one by one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9804>
_______________________________________

From report at bugs.python.org  Thu Sep  9 00:56:41 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 08 Sep 2010 22:56:41 +0000
Subject: [issue9805] Documentation on old-style formatting of dicts is overly
	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1283986601.0.0.25543806229.issue9805@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9805>
_______________________________________

From report at bugs.python.org  Thu Sep  9 01:04:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 23:04:53 +0000
Subject: [issue9804] ascii() does not always join surrogate pairs
In-Reply-To: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>
Message-ID: <1283987093.93.0.563531611442.issue9804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

How about the following solution:

>>> def a(s):
...    s = s.encode('unicode-escape').decode('ascii')
...    s = s.replace("'", r"\'")
...    return "'" + s + "'"
... 
>>> s = "'\0\"\n\r\t abcd\x85?\U00012fff\U0001D121xxx\uD800."
>>> print(ascii(s)); print(a(s)); print(repr(s))
'\'\x00"\n\r\t abcd\x85\xe9\U00012fff\ud834\udd21xxx\ud800.'
'\'\x00"\n\r\t abcd\x85\xe9\U00012fff\U0001d121xxx\ud800.'
'\'\x00"\n\r\t abcd\x85?\U00012fff?xxx\ud800.'


(I think I've included everything:
- normal chars
- control chars
- one-byte non-ASCII
- two-byte non-ASCII (and lone surrogate)
- printable and non-printable surrogate pairs)
- single and double quotes)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9804>
_______________________________________

From report at bugs.python.org  Thu Sep  9 01:12:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 23:12:03 +0000
Subject: [issue9804] ascii() does not always join surrogate pairs
In-Reply-To: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>
Message-ID: <1283987523.79.0.00705167038095.issue9804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, it would probably be simpler to export a _PyUnicode_Repr(PyUnicodeObject *, int only_ascii) function since all the code is already there in unicodeobject.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9804>
_______________________________________

From report at bugs.python.org  Thu Sep  9 01:16:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 23:16:35 +0000
Subject: [issue9804] ascii() does not always join surrogate pairs
In-Reply-To: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>
Message-ID: <1283987795.55.0.476279078119.issue9804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Or perhaps not, since we would like surrogate pairs to be fused in other cases (ascii() of other types) as well.

So "backslashreplace" would need to be changed instead:

>>> print("\U00012345".encode('ascii', 'backslashreplace'))
b'\\ud808\\udf45'

Expected result (already works in UCS4 builds):

>>> print("\U00012345".encode('ascii', 'backslashreplace'))
b'\\U00012345'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9804>
_______________________________________

From report at bugs.python.org  Thu Sep  9 01:34:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 23:34:39 +0000
Subject: [issue9804] ascii() does not always join surrogate pairs
In-Reply-To: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>
Message-ID: <1283988879.68.0.124183260784.issue9804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch (lacking tests for now).

----------
keywords: +patch
Added file: http://bugs.python.org/file18805/backslashsurrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9804>
_______________________________________

From report at bugs.python.org  Thu Sep  9 01:43:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 23:43:54 +0000
Subject: [issue9801] Can not use append/extend to lists in a multiprocessing
	manager dict
In-Reply-To: <1283973802.38.0.869176624785.issue9801@psf.upfronthosting.co.za>
Message-ID: <1283989434.77.0.0998726322992.issue9801@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> jnoller
nosy: +jnoller
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9801>
_______________________________________

From report at bugs.python.org  Thu Sep  9 01:45:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 23:45:39 +0000
Subject: [issue9801] Can not use append/extend to lists in a multiprocessing
	manager dict
In-Reply-To: <1283973802.38.0.869176624785.issue9801@psf.upfronthosting.co.za>
Message-ID: <1283989539.99.0.465797141464.issue9801@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Similarly:

>>> x = man.list()
>>> x.append({})
>>> x[0]
{}
>>> x[0]['a'] = 5
>>> x[0]
{}

Lots of fun!

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9801>
_______________________________________

From report at bugs.python.org  Thu Sep  9 01:57:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 23:57:51 +0000
Subject: [issue8655] Problem with getpeercert in the ssl module when
	retrieving client side certs
In-Reply-To: <1273265394.09.0.646660549737.issue8655@psf.upfronthosting.co.za>
Message-ID: <1283990271.32.0.67676121609.issue8655@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/issue8655>
_______________________________________

From report at bugs.python.org  Thu Sep  9 02:12:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Sep 2010 00:12:53 +0000
Subject: [issue9804] ascii() does not always join surrogate pairs
In-Reply-To: <1283987093.93.0.563531611442.issue9804@psf.upfronthosting.co.za>
Message-ID: <201009090212.41356.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> >>> s = "'\0\"\n\r\t abcd\x85?\U00012fff\U0001D121xxx\uD800."
> (...)
> (I think I've included everything:
> - normal chars
> - control chars
> - one-byte non-ASCII
> - two-byte non-ASCII (and lone surrogate)
> - printable and non-printable surrogate pairs)
> - single and double quotes)

Add maybe a lone suroggate followed directly by a surrogate pair, eg. 
'\uD800\U0001D121'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9804>
_______________________________________

From report at bugs.python.org  Thu Sep  9 02:48:27 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 09 Sep 2010 00:48:27 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1283993307.16.0.415974551493.issue9116@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

After creating experimental patch, I could supress dialog
and error message on VS8.0. But it seems there is no way to
suppress error message on VC6. That is,

FAILED (failures=1)
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "e:\python-dev\py3k\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "e:\python-dev\py3k\lib\test\test_capi.py", line 182, in <module>
    test_main()
  File "e:\python-dev\py3k\lib\test\test_capi.py", line 143, in test_main
    support.run_unittest(CAPITest)
  File "e:\python-dev\py3k\lib\test\support.py", line 1127, in run_unittest
    _run_suite(suite)
  File "e:\python-dev\py3k\lib\test\support.py", line 1110, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_capi.py", line 50, in test_no_FatalErro
r_infinite_loop
    b'Fatal Python error:'
AssertionError: b'Fatal Python error: PyThreadState_Get: no current thread\r\n\r
\nabnormal program termination' != b'Fatal Python error: PyThreadState_Get: no c
urrent thread'

This happens because "abnormal program termination" is output to
stderr. Another capable sink to output error message into is
messagebox, of cause it is not what we want. There is no way to
silent this.

I think there are a few options to take.
* Skip this test on VC6 (And probably VS7.1)
* Check not equality, but if stderr starts with "Fatal Python ...."

----------
nosy: +ocean-city
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9116>
_______________________________________

From report at bugs.python.org  Thu Sep  9 03:05:42 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 09 Sep 2010 01:05:42 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

the SOABI is always defined, no need to try loading an extension without the SOABI in its name.

ok to commit?

----------
components: Interpreter Core
files: dynload.diff
keywords: patch
messages: 115922
nosy: barry, doko
priority: normal
severity: normal
status: open
title: no need to try loading posix extensions without SOABI
versions: Python 3.2
Added file: http://bugs.python.org/file18806/dynload.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Thu Sep  9 03:06:09 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 09 Sep 2010 01:06:09 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1283994369.15.0.86988331947.issue9806@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Thu Sep  9 03:24:25 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 09 Sep 2010 01:24:25 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

currently, much of the configuration information is fetched by opening the config.h and the Makefile for the build. The locations of these files are derived from the prefix given at configure time.

If you want to have two distinct builds with the same prefix, but with different configuration options, this kind of configuration information is unsufficient.  The current use case is a normal build and a debug build, as used for the Fedora and Debian/Ubuntu python packages.

Fedora and Debian/Ubuntu carry a patch, adding a sys.pydebug attribute and patching "some" things to get the correct information for these builds using the same prefix.

This kind of information should not be derived by following some paths names, but be contained in the python binary itself, without needing to read the Makefile and the config.h files.

Attached is a patch currently applied in Debian/Ubuntu (and some variant for Fedora) which introduces a sys.pydebug attribute and derives the correct locations for the config.h and Makefile files. It's not meant as a patch ready to apply, but to get an idea what is needed to have two different python installations with the same prefix.

----------
components: Build
files: debug-build.diff
keywords: patch
messages: 115923
nosy: barry, doko
priority: normal
severity: normal
stage: needs patch
status: open
title: deriving configuration information for different builds with the same prefix
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18807/debug-build.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 03:25:58 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 09 Sep 2010 01:25:58 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1283995558.9.0.562029033353.issue9807@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 03:52:47 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 09 Sep 2010 01:52:47 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1283997167.04.0.504145884796.issue9807@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 04:15:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Sep 2010 02:15:38 +0000
Subject: [issue9805] Documentation on old-style formatting of dicts is overly
	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1283998538.57.0.159508718882.issue9805@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Python 3.2a2+ (py3k:84613, Sep  7 2010, 19:17:31) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "%s %(abc)s" % dict(abc=2)
"{'abc': 2} 2"

I did not expect this result.  Looks like a bug to me.

>>> "%s %(abc)s" % (dict(abc=2), 4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: format requires a mapping
>>> "%d %(abc)s" % dict(abc=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: %d format: a number is required, not dict
>>> "%s %s %(abc)s" % dict(abc=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: not enough arguments for format string

So, the only case which "works" (but is arguably buggy) is a single %s mixed in with dict lookups.  'may' does not adequately describe this reality.  'must' is much closer.  If it weren't a backward incompatible change I'd suggest making a single dict (i.e.: non-tuple) argument to % with non-dict-lookup patterns an error.  As it is, we'll just live with the quirk, and probably with the bug as well.

I'm not sure it is worth explaining all these quirks in the main docs.  Perhaps in a footnote?

----------
nosy: +r.david.murray
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9805>
_______________________________________

From report at bugs.python.org  Thu Sep  9 04:16:34 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 09 Sep 2010 02:16:34 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1283998594.47.0.334993371709.issue9806@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I guess I'm concerned about any compatibility issues e.g. an extension built for 3.1 trying to load into 3.2.  But that'll probably fail anyway.  So I guess it's impossible to build a bare .so extension for Python 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Thu Sep  9 04:26:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Sep 2010 02:26:02 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1283999162.78.0.834605400448.issue9807@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 04:32:40 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 09 Sep 2010 02:32:40 +0000
Subject: [issue9805] Documentation on old-style formatting of dicts is overly
	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1283999560.76.0.282253799723.issue9805@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think this might be a dupe of issue 1467929.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9805>
_______________________________________

From report at bugs.python.org  Thu Sep  9 05:20:25 2010
From: report at bugs.python.org (Jon Anglin)
Date: Thu, 09 Sep 2010 03:20:25 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>


New submission from Jon Anglin <janglin at fortresgrand.com>:

This is a feature request to implement the os.getlogin function on Windows systems.  This may not be a widely used function, but implementing on Windows will bring Python on Windows one step closer to Python on Unix (like) systems.  The os_getlogin.diff file contains my proposed patch to add this functionality for Windows.

----------
components: Library (Lib), Windows
files: os_getlogin.diff
keywords: patch
messages: 115927
nosy: janglin
priority: normal
severity: normal
status: open
title: Implement os.getlogin on Windows
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18808/os_getlogin.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Thu Sep  9 07:06:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Sep 2010 05:06:42 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1284008802.29.0.696446194505.issue9808@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Thu Sep  9 07:18:40 2010
From: report at bugs.python.org (Alan McIntyre)
Date: Thu, 09 Sep 2010 05:18:40 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1284009520.73.0.917076801705.issue1757072@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

Maybe ZipFile should have an option to handle archives in a non-strict mode, in which it would raise warnings or just completely ignore a small set of minor violations of the spec.  That way people that want behavior that's in compliance with the spec will have it (by default), but those that need to handle ZIP files that bend the rules can still choose to use the Python standard libraries to get their work done.

If there's any interest in this I can work up a patch, tests, and documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_______________________________________

From report at bugs.python.org  Thu Sep  9 07:19:53 2010
From: report at bugs.python.org (GreY FoX)
Date: Thu, 09 Sep 2010 05:19:53 +0000
Subject: [issue9809] Wrong Registery Entries on win64
In-Reply-To: <1284009593.81.0.159283716249.issue9809@psf.upfronthosting.co.za>
Message-ID: <1284009593.81.0.159283716249.issue9809@psf.upfronthosting.co.za>


New submission from GreY FoX <greyfoxgti at gmail.com>:

Priority:  3 Keywords:      6

well python on installation on win64 adds the following registry keys:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Python]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\Help]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\Help\Main Python Documentation]
@="C:\\Python27\\Doc\\python27.chm"

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath]
@="C:\\Python27\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath\InstallGroup]
@="Python 2.7"

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\Modules]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\PythonPath]
@="C:\\Python27\\Lib;C:\\Python27\\DLLs;C:\\Python27\\Lib\\lib-tk"



but to be found by the programs searching for it it should be:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Help]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Help\Main Python Documentation]
@="C:\\Python27\\Doc\\python27.chm"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\InstallPath]
@="C:\\Python27\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\InstallPath\InstallGroup]
@="Python 2.7"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Modules]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\PythonPath]
@="C:\\Python27\\Lib;C:\\Python27\\DLLs;C:\\Python27\\Lib\\lib-tk"



this would fix the installer of the setuptools
thanks

----------
components: Installation
messages: 115929
nosy: GreYFoX
priority: normal
severity: normal
status: open
title: Wrong Registery Entries on win64
versions: Python 2.5, 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/issue9809>
_______________________________________

From report at bugs.python.org  Thu Sep  9 09:38:11 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 09 Sep 2010 07:38:11 +0000
Subject: [issue9810] bzip2 build sometimes fails (VS8.0)
In-Reply-To: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>
Message-ID: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

bzip2 project sometimes fails to build pyd file. This is because

(snip)
nmake /nologo /f makefile.msc lib
(snip)
nmake /nologo /f makefile.msc clean

is run by bzip2.vcproj, but "lib" command won't create
bzip2.exe nor bzip2recover.exe, wheres "clean" will try
to delete these files without checking their existence.

Technically it is easy to fix this. (Replace "del ..." with
if exists ... del .....    in bzip2-1.0.5/makefile.msc)
But is it allowed to modify external project files? Thank you.

----------
components: Build
messages: 115930
nosy: ocean-city
priority: normal
severity: normal
status: open
title: bzip2 build sometimes fails (VS8.0)
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9810>
_______________________________________

From report at bugs.python.org  Thu Sep  9 09:42:05 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 09 Sep 2010 07:42:05 +0000
Subject: [issue9609] make cProfile multi-stack aware
In-Reply-To: <1281884976.7.0.103613520648.issue9609@psf.upfronthosting.co.za>
Message-ID: <1284018125.22.0.428746061472.issue9609@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/issue9609>
_______________________________________

From report at bugs.python.org  Thu Sep  9 09:47:35 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 09 Sep 2010 07:47:35 +0000
Subject: [issue9622] Allow to set profile/trace function globally
In-Reply-To: <1281979035.75.0.299243674716.issue9622@psf.upfronthosting.co.za>
Message-ID: <1284018455.93.0.826166272476.issue9622@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/issue9622>
_______________________________________

From report at bugs.python.org  Thu Sep  9 09:55:55 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 09 Sep 2010 07:55:55 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1284018955.89.0.000206587345207.issue9116@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is the patch. On VS8.0 or above,
* Avoid DebugBreak() call by IsDebuggerPresent().
* Tell abort() not to print message to console or window.

----------
keywords: +patch
Added file: http://bugs.python.org/file18809/py3k_fix_test_capi_crash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9116>
_______________________________________

From report at bugs.python.org  Thu Sep  9 10:24:48 2010
From: report at bugs.python.org (Ask Solem)
Date: Thu, 09 Sep 2010 08:24:48 +0000
Subject: [issue9733] Can't iterate over multiprocessing.managers.DictProxy
In-Reply-To: <1283349080.83.0.871806054056.issue9733@psf.upfronthosting.co.za>
Message-ID: <1284020688.18.0.0720350704791.issue9733@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

> I expected I could iterate over a DictProxy as I do over a
> regular dict.

DictProxy doesn't support iterkeys(), itervalues(), or iteritems() either.
So while

    iter(d)

could do
     iter(d.keys())

behind the scenes, it would mask the fact that this would not return
an *iterator* over the keys, but send a potentially long list of keys back to the client.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9733>
_______________________________________

From report at bugs.python.org  Thu Sep  9 11:59:05 2010
From: report at bugs.python.org (Sverre Johansen)
Date: Thu, 09 Sep 2010 09:59:05 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>


New submission from Sverre Johansen <sverre.johansen at gmail.com>:

There seems to be a platform difference in the way stftime handles 
unknown format codes.

In OSX Python removes the percentage sign from the returned string when the format code is unknown. In Linux it leaves it.

Look at the following example:

This is Python 3.1.2 in Ubuntu:

    Python 3.1.2 (r312:79147, Apr 15 2010, 15:35:48) 
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import datetime
    >>> datetime.datetime.now().strftime("%q")
    '%q'

And this is Python 3.1.2 on Max OSX:

    Python 3.1.2 (r312:79147, Sep  9 2010, 11:11:24) 
    [GCC 4.2.1 (Apple Inc. build 5664)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import datetime
    >>> datetime.datetime.now().strftime("%q")
    'q'

I've gotten the same result in 2.5, 2.6 and 3.1.

FYI, this broke some code that parsed the same string first with strftime, and then used string interpolation (The mac version
deleted all percentage signs before '('):

    >>> datetime.datetime.now().strftime("%Y - %(foobar)s") % {"foobar": "egg"}

This does not work in OSX.

----------
components: Library (Lib)
messages: 115933
nosy: sverrejoh
priority: normal
severity: normal
status: open
title: strftime strips '%' from unknown format codes on OS X
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Thu Sep  9 12:21:02 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 09 Sep 2010 10:21:02 +0000
Subject: [issue9796] Add summary tables for unittest API
In-Reply-To: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>
Message-ID: <1284027662.63.0.353999364194.issue9796@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This has been on my 'todo list' for a long time. Feel free to get to it before me. Please *don't* include the now deprecated assert* methods in the table. I'd like to move all the deprecated methods to a separate section of the documentation.

As Raymond says - just the assert* methods from TestCase will be the biggest value for the unittest docs, so +1 to his comment (and suggestion on grouping and including example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9796>
_______________________________________

From report at bugs.python.org  Thu Sep  9 12:31:01 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 09 Sep 2010 10:31:01 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1284028261.61.0.622454993716.issue9799@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

OK for me to close it as a compiler bug since there is a workaround.

It would be great if we could detect this compiler and deactivate this optimization automatically, but I am too lazy to search the xlc compiler documentation for a way to do that.

I suppose that the people who will be confronted to this problem (the 4 of us in the world who compile Python on AIX with xlc) will find this issue and the correct flag to make it work.

Also I am using xlc instead of gcc because it provides some better optimization for this architecture. If the computed gotos optimization only works with gcc, then it may be more interesting to use the gcc compiler instead (I will do some benchs).

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Thu Sep  9 12:35:23 2010
From: report at bugs.python.org (Sverre Johansen)
Date: Thu, 09 Sep 2010 10:35:23 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284028523.24.0.527304613802.issue9811@psf.upfronthosting.co.za>


Sverre Johansen <sverre.johansen at gmail.com> added the comment:

This is because of differences in GNU and BSD C stdlib; I get the same results using the BSD and GNU versions of `date`.

    $ date +"%q"

What does Python typically do in cases like this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Thu Sep  9 12:56:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Sep 2010 10:56:40 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1284029800.07.0.267591996723.issue9799@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/issue9799>
_______________________________________

From report at bugs.python.org  Thu Sep  9 13:18:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Sep 2010 11:18:03 +0000
Subject: [issue9804] ascii() does not always join surrogate pairs
In-Reply-To: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>
Message-ID: <1284031083.39.0.425980286514.issue9804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch with tests.

----------
Added file: http://bugs.python.org/file18810/backslashsurrogates2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9804>
_______________________________________

From report at bugs.python.org  Thu Sep  9 13:32:29 2010
From: report at bugs.python.org (Ask Solem)
Date: Thu, 09 Sep 2010 11:32:29 +0000
Subject: [issue3125] test_multiprocessing causes test_ctypes to fail
In-Reply-To: <1213637497.57.0.0550109069119.issue3125@psf.upfronthosting.co.za>
Message-ID: <1284031949.11.0.254365866238.issue3125@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

As no one has been able to confirm that this is still an issue, I'm closing it as "out of date". The issue can be reopened if necessary.

----------
resolution: accepted -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3125>
_______________________________________

From report at bugs.python.org  Thu Sep  9 13:34:39 2010
From: report at bugs.python.org (Ask Solem)
Date: Thu, 09 Sep 2010 11:34:39 +0000
Subject: [issue3111] multiprocessing ppc Debian/ ia64 Ubuntu compilation error
In-Reply-To: <1213472808.51.0.731079646072.issue3111@psf.upfronthosting.co.za>
Message-ID: <1284032079.49.0.245294203157.issue3111@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

As no one is able to confirm that this is still an issue, I'm closing it. It can be reopened if necessary.

----------
resolution:  -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3111>
_______________________________________

From report at bugs.python.org  Thu Sep  9 14:32:45 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 09 Sep 2010 12:32:45 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283986136.3195.11.camel@localhost.localdomain>
Message-ID: <AANLkTimSQ_RLYAzomsGDvYoyA1vCfAwtU0xDg2j2+QLY@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Sounds good - I'd say just commit whenever you're happy with it then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9757>
_______________________________________

From report at bugs.python.org  Thu Sep  9 14:47:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Sep 2010 12:47:27 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1284036447.49.0.742048160117.issue9738@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

#6543 changed the encoding of the filename argument of PyRun_SimpleFileExFlags() (and all functions based on PyRun_SimpleFileExFlags) and c_filename attribute of the compiler (private) structure in Python 3.1.3: use utf-8 in strict mode instead of filesystem encoding with surrogateescape.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9738>
_______________________________________

From report at bugs.python.org  Thu Sep  9 14:49:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Sep 2010 12:49:28 +0000
Subject: [issue9713] Py_CompileString fails on non decode-able paths.
In-Reply-To: <1283154413.35.0.877915229941.issue9713@psf.upfronthosting.co.za>
Message-ID: <1284036568.5.0.345777716477.issue9713@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

#6543 changed the encoding of the filename argument of PyRun_SimpleFileExFlags() (and all functions based on PyRun_SimpleFileExFlags) and c_filename attribute of the compiler (private) structure in Python 3.1.3: use utf-8 in strict mode instead of filesystem encoding with surrogateescape.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9713>
_______________________________________

From report at bugs.python.org  Thu Sep  9 14:50:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Sep 2010 12:50:11 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1284036611.47.0.762239960059.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #9713 (Py_CompileString fails on non decode-able paths) and #9738 (Document the encoding of functions bytes arguments of the C API).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Thu Sep  9 15:00:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Sep 2010 13:00:06 +0000
Subject: [issue9757] Add context manager protocol to memoryviews
In-Reply-To: <1283526664.21.0.538599282287.issue9757@psf.upfronthosting.co.za>
Message-ID: <1284037206.09.0.156153328969.issue9757@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r84649. Thanks for the comments!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9757>
_______________________________________

From report at bugs.python.org  Thu Sep  9 15:24:34 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 09 Sep 2010 13:24:34 +0000
Subject: [issue9609] make cProfile multi-stack aware
In-Reply-To: <1281884976.7.0.103613520648.issue9609@psf.upfronthosting.co.za>
Message-ID: <1284038674.95.0.975797087505.issue9609@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9609>
_______________________________________

From report at bugs.python.org  Thu Sep  9 16:09:11 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 09 Sep 2010 14:09:11 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1284041351.37.0.0946724568847.issue9808@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

After a quick glance the patch looks alright, just cleaned a few things up in issue9808.diff (moved the #include up with others, removed 'is not None' from tests).

The test skip decorator could also be moved to the LoginTests class level. Is there any reason the variables could legitimately be different from what getlogin reports?

----------
assignee:  -> brian.curtin
stage:  -> patch review
Added file: http://bugs.python.org/file18811/issue9808.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Thu Sep  9 16:11:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Sep 2010 14:11:49 +0000
Subject: [issue2745] Add support for IsWow64Process
In-Reply-To: <1209774164.99.0.662005480368.issue2745@psf.upfronthosting.co.za>
Message-ID: <1284041509.17.0.164325256472.issue2745@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also Issue7860.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2745>
_______________________________________

From report at bugs.python.org  Thu Sep  9 16:23:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Sep 2010 14:23:34 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284042214.18.0.386728866619.issue9811@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Python's strftime is a thin wrapper around the system strftime.  This means, for example, that a slightly different set of % codes is supported on windows vs linux.  So, from Python's point of view this is at *most* a doc bug.

That said, I think there have been some rumblings about writing our own strftime, but I don't know if anyone is serious about it.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +belopolsky, docs at python, r.david.murray
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Thu Sep  9 16:33:11 2010
From: report at bugs.python.org (Ken Basye)
Date: Thu, 09 Sep 2010 14:33:11 +0000
Subject: [issue9805] Documentation on old-style formatting of dicts is overly
	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1284042791.11.0.984204676726.issue9805@psf.upfronthosting.co.za>


Ken Basye <ken.basye at gmail.com> added the comment:

I think Eric is correct; it's a dupe.  And I was wrong about not otherwise being able to format an empty dictionary - "%s" % (d,) will always work and is arguably the right thing to do anyway.

----------
type: behavior -> 
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9805>
_______________________________________

From report at bugs.python.org  Thu Sep  9 17:03:22 2010
From: report at bugs.python.org (Kenneth Dombrowski)
Date: Thu, 09 Sep 2010 15:03:22 +0000
Subject: [issue9812] cPickle segfault with nested dicts in threaded env
In-Reply-To: <1284044601.98.0.223579173983.issue9812@psf.upfronthosting.co.za>
Message-ID: <1284044601.98.0.223579173983.issue9812@psf.upfronthosting.co.za>


New submission from Kenneth Dombrowski <kdombrowski at gmail.com>:

FreeBSD 8.0-RELEASE-p2
Python 2.5.5
amd64

attached diff provides a test for cpickle which reproduces a segfault when pickling >15 nested dicts in a threaded environment 

cpickle.patch attached to http://bugs.python.org/issue3640 applys cleanly to the 2.5 source and fixes this issue

i understand 2.5 is no longer maintained except for security fixes, i leave it up to the maintainers to decide if this segfault warrants a security patch 

thank you

----------
components: Extension Modules
files: test_cpickle.nested_dicts_in_threaded_env.diff
keywords: patch
messages: 115950
nosy: kdombrowski
priority: normal
severity: normal
status: open
title: cPickle segfault with nested dicts in threaded env
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file18812/test_cpickle.nested_dicts_in_threaded_env.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9812>
_______________________________________

From report at bugs.python.org  Thu Sep  9 17:05:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 09 Sep 2010 15:05:58 +0000
Subject: [issue9809] Wrong Registery Entries on win64
In-Reply-To: <1284009593.81.0.159283716249.issue9809@psf.upfronthosting.co.za>
Message-ID: <1284044758.92.0.639192100307.issue9809@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Wow6432Node registry entries are for applications running WOW - aka 32-bit applications on a 64-bit platform. The 64-bit Python installer is placing its entries in the appropriate location.

See the winreg documentation for information that might help fixing this setuptools bug, in particular this section: http://docs.python.org/py3k/library/winreg#bit-specific

----------
components: +Windows
nosy: +brian.curtin
resolution:  -> invalid
stage:  -> committed/rejected
type:  -> behavior
versions:  -Python 2.5, 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/issue9809>
_______________________________________

From report at bugs.python.org  Thu Sep  9 17:29:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Sep 2010 15:29:46 +0000
Subject: [issue9805] Documentation on old-style formatting of dicts is overly
	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1284046186.33.0.757748960303.issue9805@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> %-formatting and dicts

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9805>
_______________________________________

From report at bugs.python.org  Thu Sep  9 17:47:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Sep 2010 15:47:49 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284047269.19.0.615941948435.issue9811@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> I think there have been some rumblings about writing our own strftime

Yes, see issue #3173.

Another related issue is #9650 which discusses how to properly document strftime codes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Thu Sep  9 17:49:37 2010
From: report at bugs.python.org (Jon Anglin)
Date: Thu, 09 Sep 2010 15:49:37 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1284047377.32.0.85578228319.issue9808@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

I can't answer that for the 'LOGNAME' environment variable on non-Windows systems, I was just keying off of what the docs claimed. As for Windows, I just came across this article http://support.microsoft.com/kb/273633 that shows we can not rely on this in the test.  

I only put those environment variables in the test because I thought this test was a little weak (what else can we do?)

    user_name = os.getlogin()
    self.assertNotEqual(0, len(user_name))

Even though %USERNAME% == os.getlogin() MOST of the time. It should be removed from the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Thu Sep  9 17:50:45 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 09 Sep 2010 15:50:45 +0000
Subject: [issue9609] make cProfile multi-stack aware
In-Reply-To: <1281884976.7.0.103613520648.issue9609@psf.upfronthosting.co.za>
Message-ID: <1284047445.38.0.173293087136.issue9609@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Here is a new patch.  When 'allthreads' is specified to cProfile.Profile.enable(), profling is enabled on all threads.
The testsuite tests to see that all threads do indeed register, it does not attempt to validate the timings.

It turns it on for all threads (in all interpreter states).  Maybe this is overdoing it.  Interpreter states is something new to me, a py3k feature?

Now, the problem with this approach is that it only works with threads already in existence when called.  The "global" appcoach that we used to solve a similar problem in Stackless Python, however, will invoke the tracing/profiling functionality for all tasklets, even if they were new.  The same would be useful for threads in regular python, especially in long running server applications.

However, this patch stands on its own.  This particular shortcoming could be fixed later.

----------
Added file: http://bugs.python.org/file18813/cprofile2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9609>
_______________________________________

From report at bugs.python.org  Thu Sep  9 18:51:28 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 09 Sep 2010 16:51:28 +0000
Subject: [issue9609] make cProfile multi-stack aware
In-Reply-To: <1281884976.7.0.103613520648.issue9609@psf.upfronthosting.co.za>
Message-ID: <1284051088.34.0.822075658662.issue9609@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +georg.brandl
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9609>
_______________________________________

From report at bugs.python.org  Thu Sep  9 19:20:44 2010
From: report at bugs.python.org (Jon Anglin)
Date: Thu, 09 Sep 2010 17:20:44 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1284052844.74.0.763175301716.issue9808@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

Here is an updated patch with the updated test.  This test does not use either the LOGNAME or USERNAME environment variables.

----------
Added file: http://bugs.python.org/file18814/issue9808.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Thu Sep  9 20:15:16 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Sep 2010 18:15:16 +0000
Subject: [issue9812] cPickle segfault with nested dicts in threaded env
In-Reply-To: <1284044601.98.0.223579173983.issue9812@psf.upfronthosting.co.za>
Message-ID: <1284056116.26.0.650470943327.issue9812@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Python has several known crashers, they are not considered as security holes.
It seems that FreeBSD has a small stack size for threads (64k); did you try to increase it with thread.stack_size(10**6)?

----------
nosy: +amaury.forgeotdarc, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9812>
_______________________________________

From report at bugs.python.org  Thu Sep  9 20:33:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Sep 2010 18:33:59 +0000
Subject: [issue9410] Add Unladen Swallow's optimizations to Python 3's pickle.
In-Reply-To: <1280384767.75.0.12386540434.issue9410@psf.upfronthosting.co.za>
Message-ID: <1284057239.95.0.906351153649.issue9410@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch was finally committed in r84653. Thanks to everyone who participated in this.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9410>
_______________________________________

From report at bugs.python.org  Thu Sep  9 20:59:52 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Sep 2010 18:59:52 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284058792.07.0.418117538083.issue9807@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

IMO there should not be any need to fetch information from config.h or the Makefile.
What about a sys.build_config dictionary containing all the necessary data?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:04:19 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Sep 2010 19:04:19 +0000
Subject: [issue7300] Unicode arguments in str.format()
In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
Message-ID: <1284059059.04.0.579740590724.issue7300@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/issue7300>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:05:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Sep 2010 19:05:54 +0000
Subject: [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1284059154.26.0.520553603667.issue8556@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/issue8556>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:11:28 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Sep 2010 19:11:28 +0000
Subject: [issue9804] ascii() does not always join surrogate pairs
In-Reply-To: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>
Message-ID: <1284059488.0.0.980547090597.issue9804@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I agree with the feature and the patch, with two minor nits:
- Py_UCS4 should be used in place of "unsigned long"
- "*p >= 0xD800" is the most selective test and should be the first

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9804>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:13:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Sep 2010 19:13:34 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1284059614.22.0.705863352625.issue8913@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/issue8913>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:15:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Sep 2010 19:15:15 +0000
Subject: [issue9195] Link in docs from "String Formatting Operations" to
	"Template Strings"
In-Reply-To: <1278571007.55.0.304215462236.issue9195@psf.upfronthosting.co.za>
Message-ID: <1284059715.08.0.310500682407.issue9195@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/issue9195>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:17:03 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Sep 2010 19:17:03 +0000
Subject: [issue9418] Move _formatter_* methods from string type into _string
	module
In-Reply-To: <1280416899.1.0.0890176421306.issue9418@psf.upfronthosting.co.za>
Message-ID: <1284059823.65.0.797815339884.issue9418@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/issue9418>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:20:44 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Sep 2010 19:20:44 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1284060044.72.0.913991512934.issue6081@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/issue6081>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:30:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Sep 2010 19:30:26 +0000
Subject: [issue7951] Should str.format allow negative indexes when used for
	__getitem__ access?
In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za>
Message-ID: <1284060626.43.0.546564699738.issue7951@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/issue7951>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:35:48 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Sep 2010 19:35:48 +0000
Subject: [issue1467929] %-formatting and dicts
Message-ID: <1284060948.71.0.551040932181.issue1467929@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Too late for 2.x and 3.1.

----------
nosy: +flox
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1467929>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:39:33 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 09 Sep 2010 19:39:33 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284061173.79.0.476459267145.issue9807@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:47:49 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 09 Sep 2010 19:47:49 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284061669.41.0.788770489412.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Amaury, you mention a sys.build_config dictionary, but I think it should actually be baked into the sysconfig module, possibly as a _sysconfig extension module.  sysconfig is the new goodness for getting at this, and I don't think it ought to have to go through a sys dictionary to get the information.

I'd be willing to work on this, if we can get some consensus.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:51:50 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 09 Sep 2010 19:51:50 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284061910.7.0.222560976604.issue9807@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

For reference, the patch that I'm currently applying to Fedora's build of Python-3.2a1 can be seen at:
  http://pkgs.fedoraproject.org/gitweb/?p=python3.git;a=blob_plain;f=python-3.2a1-debug-build.patch;hb=HEAD

It appears to be very similar to Matthias' patch (it was originally based on an earlier version of Debian's python 2 patch, which I fixed up against Fedora's python 2, changed some aspects I wasn't happy with, then ported to python 3.1, then fixed up to 3.2a1 IIRC)

For further reference, Fedora's python3.spec has these comments that I wrote on the patch:
# Patch to support building both optimized vs debug stacks DSO ABIs, sharing
# the same .py and .pyc files, using "_d.so" to signify a debug build of an
# extension module.
#
# Based on Debian's patch for the same, 
#  http://patch-tracker.debian.org/patch/series/view/python2.6/2.6.5-2/debug-build.dpatch
# 
# (which was itself based on the upstream Windows build), but with some
# changes:
#
#   * Debian's patch to dynload_shlib.c looks for module_d.so, then module.so,
# but this can potentially find a module built against the wrong DSO ABI.  We
# instead search for just module_d.so in a debug build
#
#   * We remove this change from configure.in's build of the Makefile:
#   SO=$DEBUG_EXT.so
# so that sysconfig.py:customize_compiler stays with shared_lib_extension='.so'
# on debug builds, so that UnixCCompiler.find_library_file can find system
# libraries (otherwise "make sharedlibs" fails to find system libraries,
# erroneously looking e.g. for "libffi_d.so" rather than "libffi.so")
#
#   * We change Lib/distutils/command/build_ext.py:build_ext.get_ext_filename
# to add the _d there, when building an extension.  This way, "make sharedlibs"
# can build ctypes, by finding the sysmtem libffi.so (rather than failing to
# find "libffi_d.so"), and builds the module as _ctypes_d.so
#   
#   * Similarly, update build_ext:get_libraries handling of Py_ENABLE_SHARED by
# appending "_d" to the python library's name for the debug configuration
#
#   * We modify Modules/makesetup to add the "_d" to the generated Makefile
# rules for the various Modules/*.so targets
#
# This may introduce issues when building an extension that links directly
# against another extension (e.g. users of NumPy?), but seems more robust when
# searching for external libraries
#
#   * We don't change Lib/distutils/command/build.py: build.build_purelib to
# embed plat_specifier, leaving it as is, as pure python builds should be
# unaffected by these differences (we'll be sharing the .py and .pyc files)
#
#   * We introduce DEBUG_SUFFIX as well as DEBUG_EXT:
#     - DEBUG_EXT is used by ELF files (names and SONAMEs); it will be "_d" for
# a debug build
#     - DEBUG_SUFFIX is used by filesystem paths; it will be "-debug" for a
# debug build
#
#   Both will be empty in an optimized build.  "_d" contains characters that
# are valid ELF metadata, but this leads to various ugly filesystem paths (such
# as the include path), and DEBUG_SUFFIX allows these paths to have more natural
# names.  Changing this requires changes elsewhere in the distutils code.
#
#   * We add DEBUG_SUFFIX to PYTHON in the Makefile, so that the two
# configurations build parallel-installable binaries with different names
# ("python-debug" vs "python").
#
#   * Similarly, we add DEBUG_SUFFIX within python-config and
#  python$(VERSION)-config, so that the two configuration get different paths
#  for these.
#
#  * Patch runtests.sh to support supplying a value for PYTHON, so that we can
# run the tests against each of the builds

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:55:59 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Sep 2010 19:55:59 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284062159.62.0.437664454429.issue9807@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You are right; but the data could not be appended to sysconfig.py, because this file is shared by the different builds.
A new built-in C module is probably necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:58:39 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 09 Sep 2010 19:58:39 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284062319.73.0.0515422601282.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

@dmalcolm: I suspect you can reduce your diff for Python 3.2 now that PEP 3149 has landed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 21:59:45 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 09 Sep 2010 19:59:45 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1284061910.7.0.222560976604.issue9807@psf.upfronthosting.co.za>
Message-ID: <4C893CA8.2020609@debian.org>


Matthias Klose <doko at debian.org> added the comment:

On 09.09.2010 21:51, Dave Malcolm wrote:
> #   * Debian's patch to dynload_shlib.c looks for module_d.so, then module.so,
> # but this can potentially find a module built against the wrong DSO ABI.  We
> # instead search for just module_d.so in a debug build

right, by design/complaint: people did complain that locally built debug 
extensions wouldn't be found in this case.  This is now obsolete for 3.2, 
because the debug extension has always added the "d" modifier.

----------
title: deriving configuration information for different builds with the same prefix -> deriving configuration information for different builds	with the same prefix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 22:01:00 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 09 Sep 2010 20:01:00 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284062460.79.0.132045534339.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

@Amaury: yes, that makes perfect sense.  With PEP 3149, a debug (or any differently built) interpreter will pick up only the _sysconfig.blah.so that's appropriate for it, so baking it into there, with public API exposure through sysconfig seems like the right thing to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 22:01:10 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 09 Sep 2010 20:01:10 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284062470.92.0.256286258916.issue9807@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

In reply to Barry A. Warsaw:
>@dmalcolm: I suspect you can reduce your diff for Python 3.2 now that PEP 3149 has landed.
Yeah, the patch I linked to is against the 3.2a1 tarball; I hoped to regenerate it for 3.2a2 but have been swamped this week :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 22:27:42 2010
From: report at bugs.python.org (Mark Hirota)
Date: Thu, 09 Sep 2010 20:27:42 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1284064062.03.0.0445830592145.issue1757072@psf.upfronthosting.co.za>


Mark Hirota <markhirota at users.sourceforge.net> added the comment:

Yes, I'd be interested in this functionality. Anything that makes it more flexible to use with a wide variety of zipfiles (even bad ones :D) allows for increased reusability.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_______________________________________

From report at bugs.python.org  Thu Sep  9 22:33:51 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Sep 2010 20:33:51 +0000
Subject: [issue9752] MSVC Compiler warning in Python\import.c
In-Reply-To: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>
Message-ID: <1284064431.83.0.771389495238.issue9752@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is good, and fixes an incorrect call to the mkdir function.

----------
nosy: +amaury.forgeotdarc
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9752>
_______________________________________

From report at bugs.python.org  Thu Sep  9 22:34:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Sep 2010 20:34:40 +0000
Subject: [issue9804] ascii() does not always join surrogate pairs
In-Reply-To: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>
Message-ID: <1284064480.96.0.320617290496.issue9804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Modified patch committed in r84655 (3.x) and r84656 (3.1). Thanks!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9804>
_______________________________________

From report at bugs.python.org  Thu Sep  9 22:34:55 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 09 Sep 2010 20:34:55 +0000
Subject: [issue9752] MSVC Compiler warning in Python\import.c
In-Reply-To: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>
Message-ID: <1284064495.21.0.239694544325.issue9752@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> BTW: should I be using the .patch extension or .diff extension?
Both extensions are fine and handled the same way

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9752>
_______________________________________

From report at bugs.python.org  Thu Sep  9 22:39:37 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 09 Sep 2010 20:39:37 +0000
Subject: [issue5985] Implement os.path.samefile and os.path.sameopenfile on
	Windows
In-Reply-To: <1241949768.79.0.988490949056.issue5985@psf.upfronthosting.co.za>
Message-ID: <1284064777.63.0.378188008147.issue5985@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Both os.path.samefile and os.path.sameopenfile are now in py3k.
And release27-maint is in feature freeze, so I think this issue
should be closed.

# Implemented on
os.path.samefile: #1578269
os.path.sameopenfile: #7566

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5985>
_______________________________________

From report at bugs.python.org  Thu Sep  9 22:51:13 2010
From: report at bugs.python.org (Tim Golden)
Date: Thu, 09 Sep 2010 20:51:13 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284008802.49.0.678751004901.issue9808@psf.upfronthosting.co.za>
Message-ID: <4C89488D.50809@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

+1 on the idea in general; I'm away at the moment
and not in a position to review the patch. Hopefully
Brian can review/commit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Thu Sep  9 23:18:50 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 09 Sep 2010 21:18:50 +0000
Subject: [issue9752] MSVC Compiler warning in Python\import.c
In-Reply-To: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>
Message-ID: <1284067130.86.0.519773320536.issue9752@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Committed as r84659.  Thanks for the patch!

----------
stage: patch review -> committed/rejected
status: open -> closed
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9752>
_______________________________________

From report at bugs.python.org  Thu Sep  9 23:25:44 2010
From: report at bugs.python.org (Charles M Norton)
Date: Thu, 09 Sep 2010 21:25:44 +0000
Subject: [issue9813] Module Name Changed
In-Reply-To: <1284067544.87.0.0157628070586.issue9813@psf.upfronthosting.co.za>
Message-ID: <1284067544.87.0.0157628070586.issue9813@psf.upfronthosting.co.za>


New submission from Charles M Norton <old_road_farm at verizon.net>:

In Python 2.6, I could import 
from mx.DateTime.ISO import ParseDateTimeUTC
With 2.7 I cannot.

Here is the error:

  File "util_lib.py", line 46, in <module>
    from mx.DateTime.ISO import ParseDateTimeUTC
ImportError: No module named mx.DateTime.ISO


What changes do I need to make, to import on pre-2.7 and 2.7?

----------
components: Library (Lib)
messages: 115976
nosy: octopusgrabbus
priority: normal
severity: normal
status: open
title: Module Name Changed
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9813>
_______________________________________

From report at bugs.python.org  Thu Sep  9 23:34:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Sep 2010 21:34:05 +0000
Subject: [issue9813] Module Name Changed
In-Reply-To: <1284067544.87.0.0157628070586.issue9813@psf.upfronthosting.co.za>
Message-ID: <1284068045.07.0.204170680043.issue9813@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Do you think that it is a Python bug? You should first try to report a bug on eGenenix bug tracker: http://www.egenix.com/services/support/

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9813>
_______________________________________

From report at bugs.python.org  Thu Sep  9 23:38:48 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 09 Sep 2010 21:38:48 +0000
Subject: [issue9813] Module Name Changed
In-Reply-To: <1284067544.87.0.0157628070586.issue9813@psf.upfronthosting.co.za>
Message-ID: <1284068328.57.0.523957800574.issue9813@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/issue9813>
_______________________________________

From report at bugs.python.org  Thu Sep  9 23:44:06 2010
From: report at bugs.python.org (Charles M Norton)
Date: Thu, 09 Sep 2010 21:44:06 +0000
Subject: [issue9813] Module Name Changed
In-Reply-To: <1284067544.87.0.0157628070586.issue9813@psf.upfronthosting.co.za>
Message-ID: <1284068646.24.0.394191617142.issue9813@psf.upfronthosting.co.za>


Charles M Norton <old_road_farm at verizon.net> added the comment:

The download page said to report problems here. I don't know whether this is a bug or not. The problem exists in 2.66, but not in 2.6.5. I'm looking for a workaround. If not, here, where should I post my request?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9813>
_______________________________________

From report at bugs.python.org  Fri Sep 10 00:58:34 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 09 Sep 2010 22:58:34 +0000
Subject: [issue9814] subprocess isn't friendly to other Python implementations
	with different GCs
In-Reply-To: <1284073114.59.0.931577015567.issue9814@psf.upfronthosting.co.za>
Message-ID: <1284073114.59.0.931577015567.issue9814@psf.upfronthosting.co.za>


New submission from Dino Viehland <dinov at microsoft.com>:

subprocess isn't very friendly to implementations with different GCs then CPython and in general relies on behavior that's not going to be very stable.  I noticed the following issues but was able to work around all of them.

First Popen is a finalizable object which holds onto another finalizable object (the process handle).  In __del__ Popen calls internal poll which attempts to wait on the handle.  But because both the handle and the POpen object can go out of scope at the same time the handle can be finalized first.  The end result is that you cannot get the return code and therefore the Popen class will resurrect it's self.  That will at the very least leak the Popen object and when running the subprocess tests will eventually start failing all of the tests.  For me this was happening because test_cwd doesn't call wait and therefore never explicitly gets the exit code.

Resurrecting finalizable objects seems like a pretty bad idea and seems to be there only for test purposes - after all who cares if you collect the exit code after no one refers to the object.  Unless _active is supposed to be publicly exposed?  

Another issue is relying on CPython's reference counting garbage collcetion.  In particular _get_handles on Windows does "p2cread = self._make_inheritable(p2cread)" where stdin == PIPE.  On CPython this is going to remove the 1 reference to the previous p2cread and close it immediately.  With other GCs this reference will linger around only to be closed at some point.  Usually that's not a problem but because this handle remains in the parent process the pipe does not get closed when it should resulting in hangs.  This is effectively a duplicated handle of the handle _execute_child closes after the child is launched.

----------
components: Library (Lib)
messages: 115979
nosy: dino.viehland
priority: low
severity: normal
status: open
title: subprocess isn't friendly to other Python implementations with different GCs
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9814>
_______________________________________

From report at bugs.python.org  Fri Sep 10 01:04:28 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 09 Sep 2010 23:04:28 +0000
Subject: [issue9813] Module Name Changed
In-Reply-To: <1284067544.87.0.0157628070586.issue9813@psf.upfronthosting.co.za>
Message-ID: <1284073468.94.0.906823744762.issue9813@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Suggest you post your issue on the egenix-users mailing list (described here http://www.egenix.com/support/mailing-lists/) first and return here if there is agreement there that there might be a problem with a current version of Python itself.

----------
nosy: +ned.deily
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9813>
_______________________________________

From report at bugs.python.org  Fri Sep 10 01:55:07 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Sep 2010 23:55:07 +0000
Subject: [issue7951] Should str.format allow negative indexes when used for
	__getitem__ access?
In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za>
Message-ID: <1284076507.7.0.364644078631.issue7951@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

After more thought, I'm -1 on this.  "Consistency" is a weak argument in favor of this.  We need to be more use case drivenm and it there is no evidence that this is needed.  Also, there is a reasonable concern that using negative indices in a format string would be a bad design pattern that should not be encouraged by the language.  And, there is a maintenance burden (just getting it right in the first place; having other implementations try to get it right; and a burden to custom formatters to have to support negative indices).

I do think we have a documentation issue.  This thread shows a number of experienced Python programmers who get "surprised" or perceive "consistency issues" perhaps because there isn't a clear mental picture  of Python's layer structure (separation of concerns) and where the responsibility lies for the supporting negative indices.

For the record, here are a few notes on where negative index handling fits into the hierarchy:

Negative index support is not guaranteed by the collections.Sequence ABC nor by the grammar (see the "subscript" rule in Grammar/Grammar).  It does not appear in opcode handling (see BINARY_SUBSCR in Python/ceval.c) nor in the top abstract layer (see PyObject_GetItem() in abstract.c).  Instead, the support for slicing and negative index handling appears at the concrete layer (see listindex() in Objects/listobject.c for example).

We do guarantee negative index handling for builtin sequences and their subclasses (as long as they don't override __getitem__), and we provide a fast path for their execution (via an intermediate abstract layer function, PySequence_GetItem() in Objects/abstract.c), but other sequence-like objects are free to make their own decisions about slices and negative indices at the concrete layer.

Knowing this, a person should not be "surprised" when one sequence has support for negative indices or slicing and another does not.  The choice belongs to the implementer of the concrete class, not to the caller of "a[x]".  There is no "consistency" issue here.

IOW, we're not required to implement negative slice handling and are free to decide whether it is a good idea or not for the use-case of string formatting.  There is some question about whether it is a bad practice for people to use negative indices for string formatting.  If so, that would be a reason not to do it.  And if available, it would only work for builtin sequences, but not sequence like items in general.  There is also a concern about placing a burden on other implementations of Python (to match what we do in CPython) and on placing a burden on people writing their own custom formatters (to closely as possible mimic builtin formatters).  If so, those would be reasons not to do it.

my-two-cents,

Raymond

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Fri Sep 10 08:49:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 10 Sep 2010 06:49:25 +0000
Subject: [issue9503] print statement hangs Windows service
In-Reply-To: <1280907256.09.0.953862220014.issue9503@psf.upfronthosting.co.za>
Message-ID: <1284101365.71.0.968971414874.issue9503@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Closing as a duplicate of issue706263.

Instead of changing all print statements, you could set sys.stdout to another file, for example:
    sys.stdout=StringIO()
or another object that simply discards written data.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> print raises exception when no console available

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9503>
_______________________________________

From report at bugs.python.org  Fri Sep 10 08:57:23 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 06:57:23 +0000
Subject: [issue9318] Py3k compilation on old MSVC
In-Reply-To: <1279691347.62.0.710756316078.issue9318@psf.upfronthosting.co.za>
Message-ID: <1284101843.31.0.858345102794.issue9318@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Patch for import.c was checked in (#9752), so last piece is just patch
for Include/pythread.h. I'll commit this near future. I believe this is
not problematic.

----------
assignee:  -> ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9318>
_______________________________________

From report at bugs.python.org  Fri Sep 10 09:18:20 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 07:18:20 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remoe dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I noticed regrtest claimed it cannot delete folder after test_tarfile
ran. It was like this.

Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "e:\python-dev\py3k\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "e:\python-dev\py3k\lib\test\test_tarfile.py", line 1566, in <module>
    test_main()
  File "e:\python-dev\py3k\lib\test\test_tarfile.py", line 1563, in test_main
    shutil.rmtree(TEMPDIR)
  File "e:\python-dev\py3k\lib\shutil.py", line 283, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "e:\python-dev\py3k\lib\shutil.py", line 281, in rmtree
    os.remove(fullname)
WindowsError: [Error 32] ???????????????????????????
??????: 'E:\\PYTHON~1\\py3k\\@test_5276_tmp\\tmp.tar'

# It says "Process cannot access the file. Another process is using it."

I tried to reproduce this by running test_tarfile alone, but failed.
But I succeeded to do it with following command.
  py3k -m test.regrtest test_capi test_tarfile

(Probably there is timing problem like GC... The reason why I think
so is below)

I think _Stream object left opened after exception occured in (even
after returned from function Tarfile#open) because it lives in stack
frame. Because t._extfileobj is True by default, TarFile object won't close it explicitly.

----------
components: Extension Modules
files: py3k_fix_tarfile.patch
keywords: patch
messages: 115984
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_tarfile sometimes ends with error "Cannot remoe dir"
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18815/py3k_fix_tarfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Fri Sep 10 09:19:04 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 07:19:04 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remoe dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1284103144.12.0.669156569643.issue9815@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Fri Sep 10 09:29:31 2010
From: report at bugs.python.org (Joseph Schaeffer)
Date: Fri, 10 Sep 2010 07:29:31 +0000
Subject: [issue9816] random.jumpahead and PRNG sequence independence
In-Reply-To: <1284103771.84.0.522023819888.issue9816@psf.upfronthosting.co.za>
Message-ID: <1284103771.84.0.522023819888.issue9816@psf.upfronthosting.co.za>


New submission from Joseph Schaeffer <thiryal at gmail.com>:

Reading the Python 2.6 docs, it appeared that using random.jumpahead would allow the initialization of several generators with the same seed but having much different internal states. While the resulting PRNG appear to have different internal states, the produced random numbers [via .random()] are exactly the same after a small initial segment.

Attached is some example code which shows the first point at which they all agree - in my testing (Mac OS X, Python versions 2.5, 2.6, 2.7) the generated numbers all agreed on the 12th number generated. For smaller differences in jumpahead it was noticeable a lot earlier - n=1,2 differ only in the first sample from each.

The internal state of the PRNGs is indeed different even after the successive sampling, so it may be that this is intended - however if so the docs may cause confusion: my particular case was where I need random numbers for a stochastic markov process and in addition needed many such generators [one for each trajectory] and was hoping to use random.jumpahead to have indepedent PRNG's without having to generate [and prove] my own independent set of seeds. Thus having a long sequence of non-independent random numbers near the initial start condition causes random.jumpahead to be unusable for my situation.

It appears that Python 3.1 removed random.jumpahead - if so, it may be useful to note in the 2.6 docs why this was / the issues with random.jumpahead: reading how it changed after 2.3 made it sound like it was exactly what I wanted. 

Possible cause: I suspect the issue may be related to how a Mersenne Twister algorithm can take a while to recover from poor seeding (excessive 0's), but do not know enough to explore that idea.

----------
components: Library (Lib)
files: random_test.py
messages: 115985
nosy: Joseph.Schaeffer
priority: normal
severity: normal
status: open
title: random.jumpahead and PRNG sequence independence
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file18816/random_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9816>
_______________________________________

From report at bugs.python.org  Fri Sep 10 10:28:37 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 10 Sep 2010 08:28:37 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1284107317.09.0.414166302211.issue9808@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/issue9808>
_______________________________________

From report at bugs.python.org  Fri Sep 10 10:30:25 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Sep 2010 08:30:25 +0000
Subject: [issue9816] random.jumpahead and PRNG sequence independence
In-Reply-To: <1284103771.84.0.522023819888.issue9816@psf.upfronthosting.co.za>
Message-ID: <1284107425.09.0.32688594007.issue9816@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +rhettinger
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9816>
_______________________________________

From report at bugs.python.org  Fri Sep 10 10:36:35 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Sep 2010 08:36:35 +0000
Subject: [issue9816] random.jumpahead and PRNG sequence independence
In-Reply-To: <1284103771.84.0.522023819888.issue9816@psf.upfronthosting.co.za>
Message-ID: <1284107795.68.0.590981953308.issue9816@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9816>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:15:11 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 10 Sep 2010 09:15:11 +0000
Subject: [issue9817] expat copyright/license file is missing
In-Reply-To: <1284110111.54.0.68745930028.issue9817@psf.upfronthosting.co.za>
Message-ID: <1284110111.54.0.68745930028.issue9817@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

files in Modules/expat reference a file COPYING for the copyright/license, but this is file is not included in the Python sources.

Proposing to add the attached file, taken from the expat sources.

----------
assignee: doko
components: None
files: COPYING
messages: 115986
nosy: doko
priority: normal
severity: normal
status: open
title: expat copyright/license file is missing
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18817/COPYING

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9817>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:24:41 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 09:24:41 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1284110681.11.0.505857864024.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Antoine, I tested this patch on py3k with both gcc and xlc in static and shared mode and I did not notice any issue.

I attach the build and test logs.

I think you can safely commit it.

----------
Added file: http://bugs.python.org/file18818/py3k_aix61_static_xlc_nopatch.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:25:05 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 09:25:05 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1284110705.25.0.795137621357.issue941346@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Added file: http://bugs.python.org/file18819/py3k_aix61_static_xlc_patchshared.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:25:29 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 09:25:29 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1284110729.33.0.653903067387.issue941346@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Added file: http://bugs.python.org/file18820/py3k_aix61_shared_xlc_pathshared.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:25:52 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 09:25:52 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1284110752.76.0.69322207593.issue941346@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Added file: http://bugs.python.org/file18821/py3k_aix61_static_gcc_patchshared.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:26:07 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 09:26:07 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1284110767.9.0.728307858128.issue941346@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Added file: http://bugs.python.org/file18822/py3k_aix61_shared_gcc_patchshared.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:31:06 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 10 Sep 2010 09:31:06 +0000
Subject: [issue9818] build files to build Lib/distutils/command/wininst-9.0*
	are missing
In-Reply-To: <1284111065.95.0.0437799903447.issue9818@psf.upfronthosting.co.za>
Message-ID: <1284111065.95.0.0437799903447.issue9818@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

PC/V[CS]* contain the information to build the wininst-[678]* files, but I don't see any information how to build wininst-9.0*.

----------
components: Build
messages: 115988
nosy: doko
priority: normal
severity: normal
status: open
title: build files to build Lib/distutils/command/wininst-9.0* are missing
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9818>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:37:30 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 10 Sep 2010 09:37:30 +0000
Subject: [issue9706] ssl errors checking
In-Reply-To: <1283029306.3325.3.camel@localhost.localdomain>
Message-ID: <1284111450.01.0.200632872692.issue9706@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9706>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:39:53 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 09:39:53 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Hello. I noticed test suite reports WARNING every time.

///////////////////////////////////////////////////

E:\python-dev>py3k -m test.regrtest test_os
WARNING: The filename '@test_464_tmp-?????' CAN be encoded by the filesyste
m encoding (mbcs). Unicode filename tests may not be effective
(snip)

///////////////////////////////////////////////////

This happens because TESTFN_UNICODE_UNDECODABLE in Lib/test/support.py
*is* decodable on Japanese environment (cp932).

It is easy to make this really undecodable in Japanese.
Using the characters like "\u2661" or "\u2668" (Former is heart mark,
latter is "Onsen" - Hot spring mark) I could remove the warning by this.
    TESTFN_UNENCODABLE = TESTFN + "-\u5171\u6709\u3055\u308c\u308b\u2661\u2668"

///////////////////////////////////////////////////

And another issue. This happens only on test_unicode_file,

///////////////////////////////////////////////////

E:\python-dev>py3k -m test.test_unicode_file
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_unicode_file.py", line 12, in <module>
    TESTFN_UNICODE.encode(TESTFN_ENCODING)
UnicodeEncodeError: 'mbcs' codec can't encode characters in position 0--1: inval
id character

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "e:\python-dev\py3k\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "e:\python-dev\py3k\lib\test\test_unicode_file.py", line 16, in <module>
    raise unittest.SkipTest("No Unicode filesystem semantics on this platform.")

unittest.case.SkipTest: No Unicode filesystem semantics on this platform.

///////////////////////////////////////////////////

This happens because TESTFN_UNICODE cannot be encoded in Japanese.

E:\python-dev>py3k
Python 3.2a2+ (py3k:84663M, Sep 10 2010, 13:24:41) [MSC v.1400 32 bit (Intel)] o
n win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print("-\xe0\xf2")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'cp932' codec can't encode character '\xe0' in position 1: i
llegal multibyte sequence

But interesting, this bytes sequence "\xe0\xf2" can be read as
cp932 multibyte characters.

E:\python-dev>python
Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print "\xe0\xf2"
?
>>> "\xe0\xf2".decode("cp932")
u'\u7463'

E:\python-dev>py3k
Python 3.2a2+ (py3k:84663M, Sep 10 2010, 13:24:41) [MSC v.1400 32 bit (Intel)] o
n win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print('\u7463')
?

I believe this value "\xe0\xf2" came from python2.x, maybe "\u7463"
should be used here? I'm not sure it can be decoded everywhere using
other encodings, though.

----------
components: Tests, Unicode
messages: 115989
nosy: ocean-city
priority: normal
severity: normal
status: open
title: TESTFN_UNICODE and TESTFN_UNDECODABLE
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:41:43 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Sep 2010 09:41:43 +0000
Subject: [issue9816] random.jumpahead and PRNG sequence independence
In-Reply-To: <1284103771.84.0.522023819888.issue9816@psf.upfronthosting.co.za>
Message-ID: <1284111703.58.0.692636312669.issue9816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the report.  Something does appear to be broken.  When the states are different, the random numbers should be different.  Am looking in to it.

In the mean time, I recommend against using jumpahead() with MT.  It is better to separately seed three different generators and rely on the huge period of MT to keep the sequences from overlapping.

If you do use jumpahead(), it is intended to be supplied with large values of n (not 1, 11, or 21).

The function/method was removed in 3.x because it was an API defect.  The jumpahead concept as originally intended (move ahead n-steps) was something that could really only work with a generator like Wichmann-Hill.  Newer and more advanced generators aren't usually amenable to direct computation of a state that is n-steps forward.

----------
priority: low -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9816>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:42:13 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 09:42:13 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284111733.07.0.572872347009.issue9819@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

And one little thing. I noticed variable name varies in
python2.x and python3.x.
TESTFN_UNICODE_UNDECODEABLE (2.x)
TESTFN_UNICODE_UNDECODABLE  (3.x)

I think 2.x should be unified into 3.x name. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:48:09 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 10 Sep 2010 09:48:09 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284112089.13.0.486431520473.issue9819@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> haypo
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 12:11:05 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 10 Sep 2010 10:11:05 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1284113465.66.0.409006460527.issue9806@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm not in favor of this change.  PEP 3179 was accepted because it presented an optional additional feature that doesn't break compatibility.

For example, build tools of third-party external modules that do not use distutils would break.

----------
nosy: +benjamin.peterson, georg.brandl, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Fri Sep 10 12:23:18 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 10 Sep 2010 10:23:18 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1284114198.7.0.615880824516.issue9806@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Martin might be able to provide some insight from when (IIRC) Windows dynamic DLLs were restricted to .pyd extension only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Fri Sep 10 12:27:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 10:27:56 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284114476.73.0.517566073397.issue9819@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> WARNING: The filename '@test_464_tmp-?????' CAN be encoded 
> by (...) cp932

We should find character not encodable in any Windows code page, but accepted as filenames.

> characters like "\u2661" or "\u2668" (...)

mbcs uses "ANSI" code pages: cp1250..cp1258 and cp874 (and maybe others because you wrote that your setup uses cp932):
http://en.wikipedia.org/wiki/Code_page#Windows_.28ANSI.29_code_pages

I wrote a short script to find a unencodable filename (attached to this issue). Output:

u'\u0301' is encodable to cp1258
u'\u0363' is not encodable to any code page
u'\u2661' is encodable to cp949
u'\u5171' is encodable to cp932, cp936, cp949, cp950

(CODE_PAGES constant of the script might be incomplete)

u'\u2661' is not a good candidate. u'\u0363' looks better. Be we can mix different characters to limit the probability that the whole string is encodable. Example:

u'\u2661\u5171' is encodable to cp949
u'\u0301\u0363\u2661\u5171' is not encodable to any code page

> TESTFN_UNICODE_UNDECODEABLE (2.x)

This is a typo fixed by r83987 in py3k.

----------
Added file: http://bugs.python.org/file18823/find_unencode_filename.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 12:42:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 10:42:59 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an error for
	unencodable filenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In Python 3.2, mbcs encoding (default filesystem encoding on Windows) is now strict: raise an error on unencodable/undecodable characters/bytes. But os.listdir(b'.') encodes unencodable bytes as b'?'.

Example:

>>> os.mkdir('listdir')
>>> open('listdir\\xxx-\u0363', 'w').close()
>>> filename = os.listdir(b'listdir')[0]
>>> filename
b'xxx-?'
>>> open(filename, 'r').close()
IOError: [Errno 22] Invalid argument: 'xxx-?'

os.listdir(b'listdir') should raise an error (and not ignore the filename or replaces unencodable characters by b'?').

I think that we should list the directory using the wide character API (FindFirstFileW) but encode the filename using PyUnicode_EncodeFSDefault() if the directory name type is bytes, instead of using the ANSI API (FindFirstFileA).

----------
components: Library (Lib), Unicode, Windows
messages: 115995
nosy: haypo, loewis
priority: normal
severity: normal
status: open
title: Windows : os.listdir(b'.') doesn't raise an error for unencodable filenames
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Fri Sep 10 12:45:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 10:45:14 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an error for
	unencodable filenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284115514.48.0.35652949903.issue9820@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I found this bug while trying to find an unencodable filename for #9819 (TESTFN_UNDECODABLE).

Anyway, the bytes API should be avoided on Windows since Windows native filename type is unicode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Fri Sep 10 12:45:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 10:45:35 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284115535.41.0.887920723263.issue9819@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #9820.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 12:48:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Sep 2010 10:48:53 +0000
Subject: [issue9816] random.jumpahead and PRNG sequence independence
In-Reply-To: <1284103771.84.0.522023819888.issue9816@psf.upfronthosting.co.za>
Message-ID: <1284115733.71.0.48098407523.issue9816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I see the problem now.  Random.jumpahead(n) does a very poor job of shuffling MT's state when n is small.  The first few numbers of the state are different but some of the later ones are not.  When random() crawls across parts of the state that are identical, it produces identical output.  Later when has wrapped around, the random() calls diverge again.

Fixed by salting the jumpahead value.  See r84665.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9816>
_______________________________________

From report at bugs.python.org  Fri Sep 10 12:57:39 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 10:57:39 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284116259.68.0.713223006837.issue9819@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you for a reply.

> u'\u2661' is encodable to cp949
Doh!

I can imagine it's difficult to find out such character. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:01:50 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 11:01:50 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284116510.02.0.273114192016.issue9819@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I also confirmed '\u0363' can be used as filename.
"dir" command cannot print filename correctly, though.

 E:\python-dev\foo ???????

2010/09/10  19:44       <DIR>          .
2010/09/10  19:44       <DIR>          ..
2010/09/10  19:44                    3 ?
               1 ??????                   3 ???
               2 ????????   2,788,741,120 ????????

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:04:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 11:04:41 +0000
Subject: [issue9821] Support PEP 383 on Windows: mbcs support of
	surrogateescape error handler
In-Reply-To: <1284116681.52.0.20336510367.issue9821@psf.upfronthosting.co.za>
Message-ID: <1284116681.52.0.20336510367.issue9821@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

It would be nice to support PEP 383 (surrogateescape) on Windows, but the mbcs codec doesn't support it for performance reason. The Windows functions to encode/decode MBCS don't give the index of the unencodable/undecodable character/byte. For encoding, we can try to encode character by character (but be careful of surrogate pairs) and check that the character is a Python lone surrogate character or not (character in range U+DC80..U+DCFF). For decoding, it is more complex because MBCS can be a multibyte encoding, eg. cp65001 (Microsoft variant of utf-8, see #6058). So it's not possible to encode byte per byte and we should write an heuristic to guess the right number of bytes for each call to the decode function.

--

A completly different solution is to get the MBCS code page and use the Python code page codec (eg. "cp1252") instead of "mbcs" encoding, because Python cpXXXX codecs support all Python error handlers. Example (with Python 2.6):

>>> print(u"abc?def".encode("cp1252", "replace"))
abc?def
>>> print(u"abc?def".encode("cp1252", "ignore"))
abcdef
>>> print(u"abc?def".encode("cp1252", "backslashreplace"))
abc\u0141def

See also #8611 for the problem if the Python path cannot be encoded to mbcs (work in progress, see #9425).

----------
components: Interpreter Core, Library (Lib), Unicode, Windows
messages: 116001
nosy: haypo, loewis
priority: normal
severity: normal
status: open
title: Support PEP 383 on Windows: mbcs support of surrogateescape error handler
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9821>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:06:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 11:06:26 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an error for
	unencodable filenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284116786.01.0.32389952197.issue9820@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> os.listdir(b'listdir') should raise an error (and not ignore 
> the filename or replaces unencodable characters by b'?').

To avoid the error, a solution is to support the PEP 383 on Windows (for the mbcs encoding). I opened a separated issue for that: #9821.

But support PEP 383 will not fix this issue because the current implementation of listdir(b'.') doesn't use the Python codec, but use raw bytes filenames (use the ANSI API).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:08:24 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 11:08:24 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1284116904.46.0.295903366729.issue8533@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Hello. How about this patch? I just mimicked create_stdio() in
Python/pythonrun.c. (Mostly) Newlines looks correct as well as
python2.x. I tested this on windows.

----------
nosy: +ocean-city
Added file: http://bugs.python.org/file18824/py3k_regrtest_newline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:10:45 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 11:10:45 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1284117045.91.0.456028621547.issue8533@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

And here is more advanced (?) patch. More closer to Python/pythonrun.c
's implementaion.

I tried regrtest_stdout_newline.patch, but it doesn't work.
# AttributeError: '_io.TextIOWrapper' object has no attribute '_writenl'

----------
Added file: http://bugs.python.org/file18825/py3k_regrtest_newline_more.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:14:04 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 11:14:04 +0000
Subject: [issue9295] test_close_open_print_buffered(test_file) sometimes
	crashes
In-Reply-To: <1279465176.3.0.233257918018.issue9295@psf.upfronthosting.co.za>
Message-ID: <1284117244.61.0.352706416796.issue9295@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I believe attached patch will fix this issue. Please forget
previous patch.

----------
Added file: http://bugs.python.org/file18826/py27_fix_threaded_file_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9295>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:15:00 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 10 Sep 2010 11:15:00 +0000
Subject: [issue9821] Support PEP 383 on Windows: mbcs support
	of	surrogateescape error handler
In-Reply-To: <1284116681.52.0.20336510367.issue9821@psf.upfronthosting.co.za>
Message-ID: <4C8A1331.7010603@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner at haypocalc.com>:
> 
> It would be nice to support PEP 383 (surrogateescape) on Windows, but the mbcs codec doesn't support it for performance reason. The Windows functions to encode/decode MBCS don't give the index of the unencodable/undecodable character/byte. For encoding, we can try to encode character by character (but be careful of surrogate pairs) and check that the character is a Python lone surrogate character or not (character in range U+DC80..U+DCFF). For decoding, it is more complex because MBCS can be a multibyte encoding, eg. cp65001 (Microsoft variant of utf-8, see #6058). So it's not possible to encode byte per byte and we should write an heuristic to guess the right number of bytes for each call to the decode function.
> 
> --
> 
> A completly different solution is to get the MBCS code page and use the Python code page codec (eg. "cp1252") instead of "mbcs" encoding, because Python cpXXXX codecs support all Python error handlers. Example (with Python 2.6):
> 
>>>> print(u"abc?def".encode("cp1252", "replace"))
> abc?def
>>>> print(u"abc?def".encode("cp1252", "ignore"))
> abcdef
>>>> print(u"abc?def".encode("cp1252", "backslashreplace"))
> abc\u0141def

That would certainly be a better approach, provided that our
cp-encodings are indeed compatible with the Windows variants
(which unfortunately tend to often use slightly different
mappings).

We could then also alias 'mbcs' to the cp-encoding (sort of
like the reverse of what we do in site.py:aliasmbcs().

----------
nosy: +lemburg
title: Support PEP 383 on Windows: mbcs support of surrogateescape error handler -> Support PEP 383 on Windows: mbcs support of	surrogateescape error handler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9821>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:25:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 11:25:09 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284117909.06.0.159808502364.issue9819@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> "dir" command cannot print filename correctly, though.

Who cares? We just have to be able to create a file with a name containing non encodable characters, list the directory, and then remove this evil file.

--

With r84666, Python uses "-\u5171\u6709\u3055\u308c\u308b" suffix for TESTFN_UNENCODABLE. Does it fix the issue on your host?

I attached an improved version of find_unencode_filename.py (with more code pages).

--

> > TESTFN_UNICODE_UNDECODEABLE (2.x)
> This is a typo fixed by r83987 in py3k.

I backported the fix to 2.7 (r84667).

----------
Added file: http://bugs.python.org/file18827/find_unencode_filename-2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:25:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 11:25:17 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284117917.03.0.0682523581334.issue9819@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file18823/find_unencode_filename.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:27:51 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 11:27:51 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1284118071.4.0.0871855695402.issue9116@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Maybe is #5619 related?

----------
dependencies: +Pass MS CRT debug flags into subprocesses

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9116>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:37:00 2010
From: report at bugs.python.org (sorin)
Date: Fri, 10 Sep 2010 11:37:00 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>


New submission from sorin <sorin.sbarnea at gmail.com>:

Currently most batch files from Tools\buildbot do fail to run if you do not call them from the python source root directory.


I already have patched files, but the question is against which branch should I make them, considering that this bug is valid for all versions?

Do you prefer patch or just the entire files?

----------
components: Build
messages: 116009
nosy: sorin
priority: normal
severity: normal
status: open
title: windows batch files are dependent on cmd current directory
type: compile error
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/issue9822>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:38:51 2010
From: report at bugs.python.org (sorin)
Date: Fri, 10 Sep 2010 11:38:51 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1284118731.92.0.77175181093.issue9822@psf.upfronthosting.co.za>


Changes by sorin <sorin.sbarnea at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file18828/buildbot_curdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:43:57 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 11:43:57 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284119037.63.0.587832969496.issue9819@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you for the fix.

> Who cares? We just have to be able to create a file with a name
> containing non encodable characters, list the directory, and then
> remove this evil file.

I won't. ;-)
Sorry, that was not compliant. I just thought it's
interesting to see such a white box in console, and see it can be
opened and deleted correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 14:16:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 12:16:22 +0000
Subject: [issue9821] Support PEP 383 on Windows: mbcs support
	of	surrogateescape error handler
In-Reply-To: <1284116681.52.0.20336510367.issue9821@psf.upfronthosting.co.za>
Message-ID: <1284120982.1.0.702350627217.issue9821@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh wait. PEP 383 is a solution to store undecodable bytes in an unicode string, but for mbcs I'm trying to get the opposite: store unicode in bytes and this is not possible (at least with PEP 383).

Example with Python 3.1:

>>> print("abc?def".encode("cp1252", "surrogateescape"))
...
UnicodeEncodeError: 'charmap' codec can't encode character '\u0141' in position 3: character maps to <undefined>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9821>
_______________________________________

From report at bugs.python.org  Fri Sep 10 14:21:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 12:21:57 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284121317.23.0.0151861551767.issue9819@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> With r84666, Python uses "-\u5171\u6709\u3055\u308c\u308b" 
> suffix for TESTFN_UNENCODABLE.

Backported to 3.1 as r84668. I don't want to patch Python 2.x (its unicode support is lower and the code is too different than Python3) and so I close the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 14:29:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Sep 2010 12:29:48 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1284121788.19.0.998403007822.issue9822@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The general rule for submitting patches is to make them against development trunk (which is currently the py3k branch).  Unified diffs from the top level of the checkout are preferred; whole files are not useful.

However, it is not clear what bug you are trying to fix here.  Why would the buildbot scripts ever get executed from anywhere except the checkout directory?  They are obviously working just fine as they are, since the buildbots are using them successfully.

----------
nosy: +r.david.murray
versions:  -Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Fri Sep 10 14:43:25 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 10 Sep 2010 12:43:25 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1284122605.45.0.0498254212018.issue9806@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Indeed, PEP 3179 is only supposed to add support for people who wish to version their modules.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Fri Sep 10 14:46:55 2010
From: report at bugs.python.org (sorin)
Date: Fri, 10 Sep 2010 12:46:55 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1284122815.89.0.415437108155.issue9822@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

In this case I made the patch on the right branch (py3k).

These scripts could be called manually and it doesn't make any sense not to make them work in all cases.

Not every Windows developer is using Visual Studio to build things, 'some' of them are using the command line, and in this case it does make a sense to be able to call this scripts without these 'strange' limitations.

Implementing this would simplify dev setup/usage on Windows. Also I updated the PCbuild/readme.txt file.

----------
Added file: http://bugs.python.org/file18829/readme.txt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Fri Sep 10 15:05:56 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 13:05:56 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1284123956.44.0.974202422297.issue4026@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I tested Michael test in msg115868 on my AIX system (AIX 6.1 with flock correctly present in libbsd) with py3k and it works fine:

checking for flock declaration... yes
checking for flock... no
checking for flock in -lbsd... yes

[103/344] test_fcntl
= OK

I attach it as a patch against py3k.

----------
Added file: http://bugs.python.org/file18830/patch_Michael_Haubenwallner_flock_msg115868.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Fri Sep 10 15:12:46 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 10 Sep 2010 13:12:46 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1284124366.71.0.415245989909.issue9806@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

s/3179/3149/ 

:)

The point about building w/o distutils is a good one and touches on my concerns in my comment above.  It would be nice to know whether there's any measurable practical benefit to the change, i.e. measure startup time for an application that loads lots of modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Fri Sep 10 15:30:44 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 10 Sep 2010 13:30:44 +0000
Subject: [issue9213] range purports to implement the Sequence ABC,
	but is missing index and count methods
In-Reply-To: <1278702375.23.0.863463663463.issue9213@psf.upfronthosting.co.za>
Message-ID: <1284125444.35.0.184373830594.issue9213@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> Attached is a greatly revised patch, with two significant changes:
> - Adds support for !PyLong_CheckExact (using _PySequence_IterSearch)

Thanks, indeed, we should support that.

> Any strong feelings on whether range.index should support the start and
> stop arguments provided by list.index, tuple.index, and str.index, but
> not by collections.Sequence.index?

I don't think that this is very important.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9213>
_______________________________________

From report at bugs.python.org  Fri Sep 10 15:36:00 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 10 Sep 2010 13:36:00 +0000
Subject: [issue8699] Equality and hashing for functools.partial
In-Reply-To: <1273676448.87.0.841686829268.issue8699@psf.upfronthosting.co.za>
Message-ID: <1284125760.74.0.847683522886.issue8699@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Is there anybody, who is interested in this?
There are some substantial problems with it (hashing a dict), so I suggest that this should be closed, unless somebody is interested.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8699>
_______________________________________

From report at bugs.python.org  Fri Sep 10 15:46:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Sep 2010 13:46:39 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1284126399.18.0.460221190984.issue9822@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I did not realize the build instructions recommended using the buildbot tool.  It is clearly past time I got around to doing windows build myself.  

Please regenerate the diffs from the top level of the checkout, and we'll see if one of the windows devs feels like checking it in.

----------
nosy: +brian.curtin, loewis, tim.golden
type: compile error -> feature request
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Fri Sep 10 16:16:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 10 Sep 2010 14:16:08 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1284128168.96.0.265754683964.issue9822@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This is just a guess, but it might have to do with how buildbot works, so I'd be careful of changing this. A lot of things (everything?) in that Tools\buildbot folder depend on being run from the top-level directory in order to work correctly.

Another example: If you run Tools\buildbot\external.bat from a directory other than the top-level, the checkouts will end up in a place that pcbuild.sln doesn't know about, thus various subprojects will not build because they can't find the source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Fri Sep 10 16:23:46 2010
From: report at bugs.python.org (Charles M Norton)
Date: Fri, 10 Sep 2010 14:23:46 +0000
Subject: [issue9813] Module Name Changed
In-Reply-To: <1284067544.87.0.0157628070586.issue9813@psf.upfronthosting.co.za>
Message-ID: <1284128626.45.0.213298831658.issue9813@psf.upfronthosting.co.za>


Charles M Norton <old_road_farm at verizon.net> added the comment:

Solved. I needed to download a separate packed. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9813>
_______________________________________

From report at bugs.python.org  Fri Sep 10 16:34:11 2010
From: report at bugs.python.org (sorin)
Date: Fri, 10 Sep 2010 14:34:11 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1284129251.85.0.151685675052.issue9822@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

This is true, that this can impact the build process but the changes are assuring that it will always chdir to the right directory.

BTW, %~dp0 is the directory when the batch file is located.

----------
Added file: http://bugs.python.org/file18831/path_for_bug_9822_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Fri Sep 10 16:34:22 2010
From: report at bugs.python.org (sorin)
Date: Fri, 10 Sep 2010 14:34:22 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1284129262.09.0.391347791344.issue9822@psf.upfronthosting.co.za>


Changes by sorin <sorin.sbarnea at gmail.com>:


Removed file: http://bugs.python.org/file18829/readme.txt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Fri Sep 10 16:34:28 2010
From: report at bugs.python.org (sorin)
Date: Fri, 10 Sep 2010 14:34:28 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1284129268.25.0.99829965052.issue9822@psf.upfronthosting.co.za>


Changes by sorin <sorin.sbarnea at gmail.com>:


Removed file: http://bugs.python.org/file18828/buildbot_curdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Fri Sep 10 16:44:14 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 10 Sep 2010 14:44:14 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za>
Message-ID: <1284129854.02.0.00936560345389.issue4617@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> amaury.forgeotdarc
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4617>
_______________________________________

From report at bugs.python.org  Fri Sep 10 17:40:07 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 15:40:07 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1284133207.35.0.319367933733.issue941346@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Removed file: http://bugs.python.org/file18820/py3k_aix61_shared_xlc_pathshared.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Sep 10 17:40:29 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 15:40:29 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1284133229.71.0.389881319157.issue941346@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Added file: http://bugs.python.org/file18832/py3k_aix61_shared_xlc_pathshared.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Sep 10 17:54:13 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 15:54:13 +0000
Subject: [issue3876] multiprocessing does not compile on systems which do not
	define sem_timedwait
In-Reply-To: <1221541852.59.0.453473189868.issue3876@psf.upfronthosting.co.za>
Message-ID: <1284134053.75.0.708955881006.issue3876@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

For info: I have no problem compiling _multiprocessing and passing the unittest test_multiprocessing with py3k rev84631 on AIX 6.1 with xlc_r compiler without the patch proposed here.

I don't know if this is due to some updates in Python (3.2alpha2+) or AIX (6.1).

----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3876>
_______________________________________

From report at bugs.python.org  Fri Sep 10 18:04:22 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 16:04:22 +0000
Subject: [issue6742] Embedding python into shared library crash on AIX
In-Reply-To: <1250775122.87.0.638132535261.issue6742@psf.upfronthosting.co.za>
Message-ID: <1284134662.2.0.0555287011164.issue6742@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

You may want to take a look at issue 941346 in order to compile libpython2.6.so on AIX.

I also embed python in my AIX application, and I had no problem once python was compiled as share thanks to the patch provided in the other issue.

----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6742>
_______________________________________

From report at bugs.python.org  Fri Sep 10 18:10:04 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 16:10:04 +0000
Subject: [issue3053] test_shutil fails under AIX
In-Reply-To: <1212763867.85.0.395528995267.issue3053@psf.upfronthosting.co.za>
Message-ID: <1284135004.09.0.367724749941.issue3053@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

For info: I have no problem with test_shutil on AIX 6.1 with python 2.6.6 or python 3.2alpha2.
There may be no problem anymore.

----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3053>
_______________________________________

From report at bugs.python.org  Fri Sep 10 18:15:23 2010
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 10 Sep 2010 16:15:23 +0000
Subject: [issue9823] OrderedDict is comparable to dict
In-Reply-To: <1284135323.35.0.651506099343.issue9823@psf.upfronthosting.co.za>
Message-ID: <1284135323.35.0.651506099343.issue9823@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

OrderedDict is currently comparable to dict.

I think this is not logical, because a dict doesn't have order, and having an identical order is a necessary condition for a match.

I think that comparing an OrderedDict with a dict makes as much sense as comparing a tuple with a set, and that's currently not allowed. (Always returns False)

Here's a disturbing code snippet executed in Python 3.2a1:

>>> from collections import OrderedDict
>>> d1 = OrderedDict(((1, 2), (3, 4)))
>>> d2 = OrderedDict(((3, 4), (1, 2)))
>>> d1 == d2
False
>>> d1 == {1: 2, 3: 4} == d2
True

----------
components: Library (Lib)
messages: 116027
nosy: cool-RR
priority: normal
severity: normal
status: open
title: OrderedDict is comparable to dict
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9823>
_______________________________________

From report at bugs.python.org  Fri Sep 10 18:20:19 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 10 Sep 2010 16:20:19 +0000
Subject: [issue9823] OrderedDict is comparable to dict
In-Reply-To: <1284135323.35.0.651506099343.issue9823@psf.upfronthosting.co.za>
Message-ID: <1284135619.53.0.467458571584.issue9823@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This was purposeful. See PEP 372.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9823>
_______________________________________

From report at bugs.python.org  Fri Sep 10 18:29:45 2010
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 10 Sep 2010 16:29:45 +0000
Subject: [issue9823] OrderedDict is comparable to dict
In-Reply-To: <1284135323.35.0.651506099343.issue9823@psf.upfronthosting.co.za>
Message-ID: <1284136185.79.0.33443781608.issue9823@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Thanks Benjamin. Was there a discussion about this in the mailing list? If so can you give me a link to it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9823>
_______________________________________

From report at bugs.python.org  Fri Sep 10 18:50:10 2010
From: report at bugs.python.org (Luke Plant)
Date: Fri, 10 Sep 2010 16:50:10 +0000
Subject: [issue9824] SimpleCookie should escape commas and semi-colons
In-Reply-To: <1284137410.37.0.376622837409.issue9824@psf.upfronthosting.co.za>
Message-ID: <1284137410.37.0.376622837409.issue9824@psf.upfronthosting.co.za>


New submission from Luke Plant <L.Plant.98 at cantab.net>:

In developing Django, we found that some browsers don't treat commas and semi-colons in cookie values (i.e. the Set-Cookie header) the way that RFC 2109 says they should. (Safari splits the header on a comma followed by space, Internet Explorer splits on semi-colons - both irrespective of any 'quoting').

The result is that if you use SimpleCookie to create Set-Cookie headers, where the cookie value contains a comma or semi-colon, you can get all kinds of breakage. 

In the end, we realised that the RFCs are kind of irrelevant, and we have to look at what browsers actually do.  So, it would be much more useful if semi-colons and commas were escaped the way that other characters are by SimpleCookie.

Our discussion/findings are here:
http://code.djangoproject.com/ticket/12470#comment:4
http://groups.google.com/group/django-developers/msg/2cb729938e8e67ca

The patch to Cookie.py (Python 2.X) or http/cookies.py (Python 3.X) is simple and follows. I'm assuming that this applies to Python 3.2 and 3.3, but I haven't checked.

----------
components: Library (Lib)
files: simplecookie_fix.diff
keywords: patch
messages: 116030
nosy: spookylukey
priority: normal
severity: normal
status: open
title: SimpleCookie should escape commas and semi-colons
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18833/simplecookie_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9824>
_______________________________________

From report at bugs.python.org  Fri Sep 10 19:08:54 2010
From: report at bugs.python.org (Luke Plant)
Date: Fri, 10 Sep 2010 17:08:54 +0000
Subject: [issue9824] SimpleCookie should escape commas and semi-colons
In-Reply-To: <1284137410.37.0.376622837409.issue9824@psf.upfronthosting.co.za>
Message-ID: <1284138534.02.0.950342053029.issue9824@psf.upfronthosting.co.za>


Luke Plant <L.Plant.98 at cantab.net> added the comment:

I forgot to mention backwards compatibility:

In the context of Cookie being used in a web application, if developers were relying on literal commas and semi-colons being present in the client side cookie value (e.g. in javascript), the patch will introduce an incompatibility.

A quick review of cookies on my computer shows that 22 out of 3079 have commas in them, and none have semi-colons in them.  For those with commas, there would still only be a problem if they were reading them client side, or not using Python's Cookie library to decode the values server side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9824>
_______________________________________

From report at bugs.python.org  Fri Sep 10 19:25:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Sep 2010 17:25:07 +0000
Subject: [issue3053] test_shutil fails under AIX
In-Reply-To: <1212763867.85.0.395528995267.issue3053@psf.upfronthosting.co.za>
Message-ID: <1284139507.6.0.37360399132.issue3053@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, closing. The original install was on a rather strange setup.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3053>
_______________________________________

From report at bugs.python.org  Fri Sep 10 20:14:49 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Sep 2010 18:14:49 +0000
Subject: [issue8699] Equality and hashing for functools.partial
In-Reply-To: <1273676448.87.0.841686829268.issue8699@psf.upfronthosting.co.za>
Message-ID: <1284142489.03.0.451536874215.issue8699@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the interesting thread.
I do agree with your suggestion to close this one though.

----------
nosy: +rhettinger
resolution:  -> rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8699>
_______________________________________

From report at bugs.python.org  Fri Sep 10 20:20:46 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Sep 2010 18:20:46 +0000
Subject: [issue9823] OrderedDict is comparable to dict
In-Reply-To: <1284135323.35.0.651506099343.issue9823@psf.upfronthosting.co.za>
Message-ID: <1284142846.9.0.956699854831.issue9823@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

That is the documented and tested behavior:  http://docs.python.org/library/collections.html#ordereddict-objects

"""
Equality tests between OrderedDict objects are order-sensitive and are implemented as list(od1.items())==list(od2.items()). Equality tests between OrderedDict objects and other Mapping objects are order-insensitive like regular dictionaries. This allows OrderedDict objects to be substituted anywhere a regular dictionary is used.
"""

It was a basic design objective for OrderedDicts to be substitutable for regular dictionaries (that is why it subclasses from dict).  This lets an OD be used just about anywhere in Python where a regular dict is expected.

Also look at:  http://en.wikipedia.org/wiki/Liskov_substitution_principle

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9823>
_______________________________________

From report at bugs.python.org  Fri Sep 10 20:48:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Sep 2010 18:48:15 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1284144495.18.0.927177749229.issue4026@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, thank you. The improvement has been committed in all three branches (3.2, 3.1, 2.7).

----------
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Fri Sep 10 21:04:04 2010
From: report at bugs.python.org (jason kirtland)
Date: Fri, 10 Sep 2010 19:04:04 +0000
Subject: [issue9825] OrderedDict ref cycles cause memory leak
In-Reply-To: <1284145444.07.0.163314050875.issue9825@psf.upfronthosting.co.za>
Message-ID: <1284145444.07.0.163314050875.issue9825@psf.upfronthosting.co.za>


New submission from jason kirtland <jek at discorporate.us>:

Circular graphs of collections.OrderedDict are uncollectable due to the presence of OrderedDict.__del__.

>>> from collections import OrderedDict
>>> import gc
>>> left, right = OrderedDict(), OrderedDict()
>>> left['other'] = right
>>> right['other'] = left
>>> assert not gc.garbage
>>> del left, right
>>> gc.collect()
10
>>> assert not gc.garbage
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError

Not an issue in 3.1.1, have not verified with 3.1.2.

----------
components: Library (Lib)
files: odicttest.py
messages: 116036
nosy: jek
priority: normal
severity: normal
status: open
title: OrderedDict ref cycles cause memory leak
type: resource usage
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file18834/odicttest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9825>
_______________________________________

From report at bugs.python.org  Fri Sep 10 21:10:02 2010
From: report at bugs.python.org (jason kirtland)
Date: Fri, 10 Sep 2010 19:10:02 +0000
Subject: [issue9826] OrderedDict ref cycles break repr()
In-Reply-To: <1284145802.06.0.781537031861.issue9826@psf.upfronthosting.co.za>
Message-ID: <1284145802.06.0.781537031861.issue9826@psf.upfronthosting.co.za>


New submission from jason kirtland <jek at discorporate.us>:

repr of circular graphs of collections.OrderedDicts fails with 'RuntimeError: maximum recursion depth exceeded while calling a Python object'.

>>> from collections import OrderedDict
>>> left, right = OrderedDict(), OrderedDict()
>>> left['other'] = right
>>> right['other'] = left
>>> left
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  ...
  File "lib/python2.7/collections.py", line 137, in __repr__
    return '%s(%r)' % (self.__class__.__name__, self.items())
RuntimeError: maximum recursion depth exceeded in __subclasscheck__

----------
components: Library (Lib)
files: odictcyclerepr.py
messages: 116037
nosy: jek
priority: normal
severity: normal
status: open
title: OrderedDict ref cycles break repr()
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18835/odictcyclerepr.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9826>
_______________________________________

From report at bugs.python.org  Fri Sep 10 21:10:05 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 10 Sep 2010 19:10:05 +0000
Subject: [issue9825] OrderedDict ref cycles cause memory leak
In-Reply-To: <1284145444.07.0.163314050875.issue9825@psf.upfronthosting.co.za>
Message-ID: <1284145805.88.0.651922082724.issue9825@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9825>
_______________________________________

From report at bugs.python.org  Fri Sep 10 21:28:35 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Sep 2010 19:28:35 +0000
Subject: [issue9826] OrderedDict ref cycles break repr()
In-Reply-To: <1284145802.06.0.781537031861.issue9826@psf.upfronthosting.co.za>
Message-ID: <1284146915.16.0.456840200625.issue9826@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9826>
_______________________________________

From report at bugs.python.org  Fri Sep 10 21:34:59 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Sep 2010 19:34:59 +0000
Subject: [issue9826] OrderedDict ref cycles break repr()
In-Reply-To: <1284145802.06.0.781537031861.issue9826@psf.upfronthosting.co.za>
Message-ID: <1284147299.51.0.266983601024.issue9826@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Patch?

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9826>
_______________________________________

From report at bugs.python.org  Fri Sep 10 21:38:36 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Sep 2010 19:38:36 +0000
Subject: [issue9825] OrderedDict ref cycles cause memory leak
In-Reply-To: <1284145444.07.0.163314050875.issue9825@psf.upfronthosting.co.za>
Message-ID: <1284147516.73.0.783046213535.issue9825@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This is an unfortunate aspect of using __del__.
I don't see a way around it without reintroducing
weak references.

Of course, your code can also use weak ref proxies
to avoid creating uncollectible circular garbage.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9825>
_______________________________________

From report at bugs.python.org  Fri Sep 10 22:07:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Sep 2010 20:07:11 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1284149231.57.0.840275373412.issue941346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the latest patch in r84680 (3.x), r84682 (3.1) and r84683 (2.7). Perhaps you want to check it's ok. Thank you anyway!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Sep 10 22:19:13 2010
From: report at bugs.python.org (jason kirtland)
Date: Fri, 10 Sep 2010 20:19:13 +0000
Subject: [issue9825] OrderedDict ref cycles cause memory leak
In-Reply-To: <1284145444.07.0.163314050875.issue9825@psf.upfronthosting.co.za>
Message-ID: <1284149953.7.0.219710181131.issue9825@psf.upfronthosting.co.za>


jason kirtland <jek at discorporate.us> added the comment:

I find the behavior surprising compared to dict and other containers, where this is not an issue and weakrefs are not required in user code.  I would not be surprised, however, to have to wait for a gc.collect() to clean up my cycles like I do for regular objects.

For what it's worth, the pure-python alternative linked in the docs uses neither __del__ nor weakrefs, though it is undoubtably less efficient than this implementation.  And the workaround 'del OrderedDict.__del__' seems to work as well, if one is willing to wait for a gc collection.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9825>
_______________________________________

From report at bugs.python.org  Fri Sep 10 23:09:35 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 10 Sep 2010 21:09:35 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1284152975.85.0.0753920283173.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Great! Thanks Antoine.

I checked quickly and there is a small correction to do on the 2.7 branch: this branch is different because there has been a change between python 2.x and 3.x in pep-3121 concerning the name of the entry function in a module (init<modulname> to PyInit_<modulename>)

So you need to change this line in Modules/ld_so_aix.in from:
  entry=PyInit_`echo $filename | sed "s/module.*//"`
to
  entry=init`echo $filename | sed "s/module.*//"`

Except for that it looks fine.

I will continue to try to make all unitary tests pass on AIX. And I would like to setup a buildbot that will compile and test the trunk every day and post the log on a public web site, in order to help keep this platform well supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Sep 10 23:30:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 21:30:22 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an error for
	unencodable filenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284154222.85.0.283363431979.issue9820@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch:
 - Remove the bytes version of listdir(): reuse the unicode version but converts the filename to bytes using PyUnicode_EncodeFSDefault() if the directory name is not unicode
 - use Py_XDECREF(d) instead of Py_DECREF(d) at the end (because d=NULL on error)
 - use Py_CLEAR(d) instead of "Py_DECREF(d); d=NULL;"
 - remove "char namebuf[MAX_PATH+5]" buffer (use less stack memory)

----------
keywords: +patch
Added file: http://bugs.python.org/file18836/listdir_windows_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Fri Sep 10 23:36:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 21:36:48 +0000
Subject: [issue9821] Support PEP 383 on Windows: mbcs support
	of	surrogateescape error handler
In-Reply-To: <1284116681.52.0.20336510367.issue9821@psf.upfronthosting.co.za>
Message-ID: <1284154608.41.0.32266500696.issue9821@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Close this issue: PEP 383 is specific to filesystem using bytes, it is useless on Windows (the problem on Windows is on encoding, not on decoding).

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9821>
_______________________________________

From report at bugs.python.org  Fri Sep 10 23:37:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 21:37:59 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1284154679.83.0.0893859706889.issue9769@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@amaury: Do you agree to reject non-ascii bytes?

TODO: document format encoding in Doc/c-api/*.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Fri Sep 10 23:52:15 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 10 Sep 2010 21:52:15 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1284155535.63.0.0283242255265.issue9769@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, let's be conservative and reject non-ascii bytes in the format string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Fri Sep 10 23:59:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 21:59:25 +0000
Subject: [issue9632] Remove sys.setfilesystemencoding()
In-Reply-To: <1282132564.59.0.094866961442.issue9632@psf.upfronthosting.co.za>
Message-ID: <1284155965.76.0.632230831431.issue9632@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I didn't proposed to add a new parameter to Py_InitializeEx() (which means create a new function to not break the API), I just wrote that _Py_SetFileSystemEncoding() doesn't work for your use case.

> If you embed Python into another application, say as scripting
> language for that application, that other application may have
> completely different requirements for the user setup than Python
> expects, e.g. for a Windows GUI application it's not feasible to
> ask the user to change the environment variables via the registry
> in order for Python to pick up the right encoding information.

Is this usecase really realistic? Except you, nobody asked for this feature.

> The application will likely have its own way
> of configuring things like file system or I/O stream encodings.
> Think of e.g. GTK or Qt applications as example.

Qt uses the unicode API on Windows: nativeOpen() uses CreateFile() (in wide chararacter mode), see src/corelib/io/qfsengine_win.cpp.

Gtk+ (glib) uses also the unicode API on Windows: g_fopen() uses _wfopen(), see glib/gstdio.c.

Python3 doesn't support your usecase currently (it doesn't work). If you consider it important, please open a new issue.

--

I commited my patch to 3.2 (r84687).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9632>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:02:33 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 10 Sep 2010 22:02:33 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za>
Message-ID: <1284156153.43.0.646302891825.issue4617@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r84685, with tests and doc updates.

----------
resolution: accepted -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4617>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:08:03 2010
From: report at bugs.python.org (Neil Tallim)
Date: Fri, 10 Sep 2010 22:08:03 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1284156483.37.0.746233698078.issue1466065@psf.upfronthosting.co.za>


Neil Tallim <red.hamsterx at gmail.com> added the comment:

I agree that it does look like RFC 3548 implicitly denies the use of \r and \n. A few *very* simple tests also makes it look like ommitting them breaks nothing, but we'd need to add a test that includes them before applying the patch.

Other than that, I agree with everything and find the email6 notes intruiging.

Would you like me to update the patch, or do you want to do it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:08:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Sep 2010 22:08:31 +0000
Subject: [issue8835] buildbot: support.transient_internet() doesn't catch DNS
	socket.gaierror
In-Reply-To: <1274996857.49.0.779391183304.issue8835@psf.upfronthosting.co.za>
Message-ID: <1284156511.08.0.0750585831229.issue8835@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8835>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:19:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 22:19:04 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1284157144.1.0.499511836823.issue8603@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If you still consider that the change on .data as a bug, 
> I think that the fix is to remove .data (mark it as 
> protected: environ.data => environ._data).

r84690 marks os.environ.data as protected. Close this issue again.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8603>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:25:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 22:25:58 +0000
Subject: [issue9402] pyexpat: replace PyObject_DEL() by Py_DECREF() to fix a
	crash in pydebug mode
In-Reply-To: <1280350428.05.0.23614798147.issue9402@psf.upfronthosting.co.za>
Message-ID: <1284157558.91.0.206449306217.issue9402@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r84692.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9402>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:29:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 22:29:30 +0000
Subject: [issue8197] Fatal error on thread creation in low memory condition:
	local storage
In-Reply-To: <1269220105.24.0.324130937649.issue8197@psf.upfronthosting.co.za>
Message-ID: <1284157770.47.0.75407218126.issue8197@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't know how to fix this issue, and I don't know if it can be fixed. As the issue is very unlikely, I prefer to close it.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8197>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:35:38 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Sep 2010 22:35:38 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284158138.65.0.757951804533.issue8746@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks Garrett for reporting the problem and thank Nick for the patches.  It turns out the problem is more involved though the solution is similar. I've spent some time figuring out what went wrong here and documenting it in this issue so that no one else has to.  Ugh.

The relevant checkin events:

(1) (2009-07-16) r74038 changed the autoconf tests for chflags and lchflags to be m4a double-quoted (from '[' to '[[') to "ensure they don't get mangled".  The test continues to use the AC_TRY_RUN macro and is working correctly.

(2) (2009-11-02) r76050 checked in a modified version of a patch from Gentoo to help support cross-compiling. The original patch was against a pre-r74038 version; it wrapped the AC_TRY_RUN macro in an AC_CACHE_CHECK and a layer of quotes. In updating the patch for the then-current trunk (2.7), the significance of the r74038 change was apparently overlooked, resulting in an extra and faulty level of [...] quotes which end up in the configure test C source.  The test now gets compile errors on all Unix-y platforms but it is only significant on those that do support chflags and/or lchflags, i.e. BSD ones and OS X.

(3) (2010-01-30) The buggy test from trunk is merged into py3k (3.2) r77862, 3.1 r77863, and 2.6 r77864.

(4) (2010-05-08) As part of Issue8510 updates to configure.in to work with autoconf 2.65, r80478 for py3k (3.2) and r80969 for trunk (2.7) converted the AC_TRY_RUN macro calls to ones using AC_RUN_IFELSE and AC_LANG_SOURCE. An extra level of quoting is added to preserve the existing, albeit buggy syntax.  The net effect is that the configure test C code generated is the same and still always fails with a compile error.

While I have not tested this on any BSD-like systems other than OS X, I believe this means that os.chflags and/or os.lchflags have been missing-in-action from builds on OSes where they should be supported for the following releases (i.e since 2009-11-02):

2.6.5
2.6.6
2.7
3.1.2
3.2a2

A side note for OS X: Apple first introduced lchflags() support in OS X 10.5.  Since the python.org OS X installer pythons are traditionally built to an 10.3/10.4 ABI, none of the OS X installers for the above Python releases would have had os.lchflags anyway (only os.chflags), except for the new 2.7 32-bit/64-bit installer if the 2.7 test weren't otherwise broken.

The solution is to fix the buggy configure.in macros along the lines suggested by Nick.  I have created and tested three new patches to do this:

    issue8746-py3k.patch    for py3k (3.2a2+)
    issue8746-27.patch      for release-27-maint (2.7+)
    issue8746-31.patch      for release-31-maint (3.1.2+)

A variant of the 3.1 patch should apply to release-26-maint (2.6.6+) however 2.6 is now in security-fix-only mode.

In each case, the patch only modifies configure.in.  It is necessary to run autoreconf after applying and before checkin.  A simple test of the fix is to do ./configure before and after:

    $ rm -f config.log config.status
    $ ./configure
    $ grep "expected identifier or '(' before " config.log
    conftest.c:191: error: expected identifier or '(' before '[' token
    conftest.c:200: error: expected identifier or '(' before ']' token
    conftest.c:191: error: expected identifier or '(' before '[' token
    conftest.c:200: error: expected identifier or '(' before ']' token
    $ patch <issue8746-[...].patch
    $ autoreconf
    $ rm -f config.log config.status
    $ ./configure
    $ grep "expected identifier or '(' before " config.log
    $

Note that I have not attempted any cross-compiling testing either with or without the patches.

----------
nosy: +doko, gregory.p.smith
priority: normal -> release blocker
stage: unit test needed -> patch review
title: *chflags detection broken on FreeBSD 9-CURRENT -> os.chflags() and os.lchflags() are not built when they should be be
Added file: http://bugs.python.org/file18837/issue8746-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:36:19 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Sep 2010 22:36:19 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284158179.39.0.666151803584.issue8746@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file18838/issue8746-31.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:36:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 22:36:47 +0000
Subject: [issue7093] xmlrpclib.ServerProxy() doesn't support unicode uri
In-Reply-To: <1255100147.66.0.74499268339.issue7093@psf.upfronthosting.co.za>
Message-ID: <1284158207.22.0.334947470796.issue7093@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Well, it was trivial to workaround this bug in my application (convert host to bytes using explicit host = str(host)). Python3 doesn't have this issue and Python 2.7 is released, I prefer to close this bug as wont fix.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7093>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:36:48 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Sep 2010 22:36:48 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284158208.88.0.228102367704.issue8746@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file18839/issue8746-27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:36:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 22:36:55 +0000
Subject: [issue7093] xmlrpclib.ServerProxy() doesn't support unicode uri
In-Reply-To: <1255100147.66.0.74499268339.issue7093@psf.upfronthosting.co.za>
Message-ID: <1284158215.2.0.643161366581.issue7093@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: fixed -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7093>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:36:56 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Sep 2010 22:36:56 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284158216.95.0.65643138699.issue8746@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file18736/8746-3.1.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:37:02 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Sep 2010 22:37:02 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284158222.27.0.43383411496.issue8746@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file18737/8746-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:37:08 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Sep 2010 22:37:08 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284158228.25.0.90737643553.issue8746@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file18738/8746-2.6.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:37:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 22:37:56 +0000
Subject: [issue5934] fix gcc warnings: explicit type conversion for uid/gid in
	posix
In-Reply-To: <1241484258.44.0.246331146842.issue5934@psf.upfronthosting.co.za>
Message-ID: <1284158276.92.0.923836775024.issue5934@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Well, it's not a bug, just a gcc warning. We don't need this patch.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5934>
_______________________________________

From report at bugs.python.org  Sat Sep 11 00:39:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 22:39:55 +0000
Subject: [issue9408] curses: Link against libncursesw instead of libncurses
In-Reply-To: <1280360992.02.0.384889308435.issue9408@psf.upfronthosting.co.za>
Message-ID: <1284158395.62.0.140696932344.issue9408@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Does anyone agree with me?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9408>
_______________________________________

From report at bugs.python.org  Sat Sep 11 01:14:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 23:14:38 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1284160478.57.0.986716498019.issue8589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It should be fixed by r84694.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Sat Sep 11 01:21:04 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 10 Sep 2010 23:21:04 +0000
Subject: [issue9408] curses: Link against libncursesw instead of libncurses
In-Reply-To: <1280360992.02.0.384889308435.issue9408@psf.upfronthosting.co.za>
Message-ID: <1284160864.04.0.410251060181.issue9408@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Just a short explanation: 

In #7384 I used the strict version of the patch for 2.7/3.2 because Thomas Dickey recommended not to load readline+ncurses and ncursesw
at the same time.

Actually the distros should either link readline against libtinfo
(Fedora) or only use ncursesw (DragonFly).


If someone feels confident that on Linux the linker can safely handle
conflicting global symbols in this situation, the patch for 2.6/3.1
could be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9408>
_______________________________________

From report at bugs.python.org  Sat Sep 11 01:22:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 23:22:10 +0000
Subject: [issue5016] FileIO.seekable() can return False
In-Reply-To: <1232494718.16.0.105569040712.issue5016@psf.upfronthosting.co.za>
Message-ID: <1284160930.05.0.985594631272.issue5016@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It is fixed in 2.7 with the backport of the Python3's io library (r73394).

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5016>
_______________________________________

From report at bugs.python.org  Sat Sep 11 01:32:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 23:32:17 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1284161537.25.0.691221422057.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New patch:
 - add encoding option to TextFile constructor
 - parse_makefile() uses the heuristic from text_file.diff

Note: sys.getfilesystemencoding() is always set in Python 3.2 (but it may be None in Python 2.x and Python < 3.2).

----------
Added file: http://bugs.python.org/file18840/distutils_makefile_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Sat Sep 11 01:33:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 23:33:35 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1284161615.8.0.147641124542.issue9561@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I attached a patch to #6011 to set the encoding to read the Makefile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Sat Sep 11 01:50:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 23:50:49 +0000
Subject: [issue9579] In 3.x,
	os.confstr() returns garbage if value is longer than 255 bytes
In-Reply-To: <1281640334.52.0.33251169247.issue9579@psf.upfronthosting.co.za>
Message-ID: <1284162649.61.0.849190377091.issue9579@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed in r84696+r84697: confstr-minimal.diff + PyUnicode_DecodeFSDefaultAndSize().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9579>
_______________________________________

From report at bugs.python.org  Sat Sep 11 01:50:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 23:50:57 +0000
Subject: [issue9579] In 3.x,
	os.confstr() returns garbage if value is longer than 255 bytes
In-Reply-To: <1281640334.52.0.33251169247.issue9579@psf.upfronthosting.co.za>
Message-ID: <1284162657.43.0.288570716522.issue9579@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9579>
_______________________________________

From report at bugs.python.org  Sat Sep 11 01:51:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 23:51:45 +0000
Subject: [issue9580] os.confstr() doesn't decode result according to PEP 383
In-Reply-To: <1281640616.02.0.101199550238.issue9580@psf.upfronthosting.co.za>
Message-ID: <1284162705.83.0.140649804231.issue9580@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed in r84696+r84697: confstr-minimal.diff from #9579 + PyUnicode_DecodeFSDefaultAndSize().

Thanks for the patch, sorry for the delay.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9580>
_______________________________________

From report at bugs.python.org  Sat Sep 11 01:51:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 23:51:51 +0000
Subject: [issue9580] os.confstr() doesn't decode result according to PEP 383
In-Reply-To: <1281640616.02.0.101199550238.issue9580@psf.upfronthosting.co.za>
Message-ID: <1284162711.2.0.212726737783.issue9580@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: duplicate -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9580>
_______________________________________

From report at bugs.python.org  Sat Sep 11 02:10:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Sep 2010 00:10:39 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284163839.47.0.976327216356.issue767645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_pep277.patch removes the usage of os.path.supports_unicode_filenames from test_pep277: the test still pass on Debian Sid (Linux). Can someone test the patch on Mac OS X, FreeBSD and Solaris (and maybe other POSIX/UNIX OSes)?

About Windows: supports_unicode_filenames is False if sys.getwindowsversion().platform < 2: win32s (0) or Windows 9x/ME (1). I don't know win32s, but I know that Windows 9x/ME is not more supported.

----------
Added file: http://bugs.python.org/file18841/test_pep277.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Sat Sep 11 02:15:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Sep 2010 00:15:48 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284164148.19.0.065146310182.issue767645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, forget test_pep277.patch: I misunderstood r81149 (new way to detect if the filesystem supports unicode or not). test_pep277 fails with my patch on Linux with LC_CTYPE=C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Sat Sep 11 02:18:48 2010
From: report at bugs.python.org (Joseph Schaeffer)
Date: Sat, 11 Sep 2010 00:18:48 +0000
Subject: [issue9816] random.jumpahead and PRNG sequence independence
In-Reply-To: <1284103771.84.0.522023819888.issue9816@psf.upfronthosting.co.za>
Message-ID: <1284164328.62.0.59056581995.issue9816@psf.upfronthosting.co.za>


Joseph Schaeffer <thiryal at gmail.com> added the comment:

Thanks for looking into it! I'm glad that issue will be fixed, as at least one website was actually recommending using .jumpahead(i) for i in 1..100 for independent seed. 

I suspect in my use case I'll want to continue my previous methods; I work with stochastic Markov processes and I need to seed a large number (10k+) of generators - one per trajectory - and also have the requirement of needing a deterministic PRNG. So having a single Mersenne Twister seed plus salting values that worked with .jumpahead would be a simpler representation; my previous code in C did basically that with a LCG to create those seeding values for the Mersenne Twister. So that's roughly equivalent [I think?] to the fixed random.jumpahead. 

Thanks again!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9816>
_______________________________________

From report at bugs.python.org  Sat Sep 11 02:20:13 2010
From: report at bugs.python.org (Chris Leary)
Date: Sat, 11 Sep 2010 00:20:13 +0000
Subject: [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>


New submission from Chris Leary <christopher.leary at cornell.edu>:

I tried to clear this section up a bit in light of the confusion here: http://stackoverflow.com/q/3687864/3594

Not sure if it applies to 3k trunk.

First documentation patch, be sure to lmk what I'm doing wrong! :-)

----------
assignee: docs at python
components: Documentation
files: pyloggingdoc.diff
keywords: patch
messages: 116067
nosy: cdleary, docs at python
priority: normal
severity: normal
status: open
title: Clarify LogRecord documentation
versions: Python 2.7
Added file: http://bugs.python.org/file18842/pyloggingdoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9827>
_______________________________________

From report at bugs.python.org  Sat Sep 11 02:24:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Sep 2010 00:24:49 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284164689.85.0.35263011824.issue767645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r84701 fixes supports_unicode_filenames's definition in Python 3.2 (and r84702 in Python 3.1): os.listdir(str) now always return unicode filenames (including non-ascii characters).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Sat Sep 11 02:37:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Sep 2010 00:37:13 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284165433.49.0.234813791168.issue767645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Maybe os.path.supports_unicode_filenames should be deprecated.
> The doc currently says:
> "True if arbitrary Unicode strings can be used as file names 
> (within limitations imposed by the file system), and if os.listdir()
> returns Unicode strings for a Unicode argument."
>
> On Linux both the things work, even if the value of 
> os.path.supports_unicode_filenames is still False:
> (...)

It depends on the locale encoding:

$ LC_CTYPE=C ./python
Python 3.2a2+ (py3k, Sep 11 2010, 01:48:43) 
>>> import sys; sys.getfilesystemencoding()
'ascii'
>>> open('\xe9', 'w').close()
...
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 0: ordinal not in range(128)

With utf-8, surrogates are forbidden. Eg.

$ ./python
Python 3.2a2+ (py3k, Sep 11 2010, 01:48:43) 
>>> import sys; sys.getfilesystemencoding()
'utf-8'
>>> open('\uDC00', 'w').close()
...
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc00' in position 0: surrogates not allowed

On Windows, Python uses the unicode API and so the unicode support doesn't depend on the locale encoding (on the ansi code page). Surrogates are accepted on Windows: '\uDC00' is a valid filename.

I think that supports_unicode_filenames is still useful to check if the filesystem API uses bytes (Linux, FreeBSD, Solaris, ...) or characters (Mac OS X, Windows). Mac OS X is a special case because the C API uses char* (byte string), but the filesystem encoding is fixed to utf-8 and it doesn't accept invalid utf-8 filenames. So I would like to say that supports_unicode_filenames should be True on Mac OS X (which was the initial request).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Sat Sep 11 02:39:05 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 11 Sep 2010 00:39:05 +0000
Subject: [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284165545.87.0.749802926217.issue9827@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: docs at python -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9827>
_______________________________________

From report at bugs.python.org  Sat Sep 11 02:42:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Sep 2010 00:42:49 +0000
Subject: [issue9408] curses: Link against libncursesw instead of libncurses
In-Reply-To: <1280360992.02.0.384889308435.issue9408@psf.upfronthosting.co.za>
Message-ID: <1284165769.93.0.911429051104.issue9408@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

$ ldd $(/usr/bin/python3.1 -c 'import readline; print(readline.__file__)')|grep curses
        libncurses.so.5 => /lib/libncurses.so.5 (0xb7537000)
$ ldd /lib/libreadline.so.6|grep curses
        libncurses.so.5 => /lib/libncurses.so.5 (0xb76a6000)

> Actually the distros should either link readline 
> against libtinfo (Fedora) or only use ncursesw (DragonFly).

Ok, I should maybe open a *Debian* bug to ask to link readline to ncursesw (and another to ensure that Python3 is also liked to ncursesw).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9408>
_______________________________________

From report at bugs.python.org  Sat Sep 11 02:55:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Sep 2010 00:55:12 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1284166512.93.0.813861788658.issue9769@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r84704 in Python 3.2.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Sat Sep 11 03:35:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Sep 2010 01:35:04 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1284168904.17.0.161091107186.issue1466065@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you could update it that would be great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Sat Sep 11 04:43:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Sep 2010 02:43:58 +0000
Subject: [issue9608] Re-phrase best way of using exceptions in doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1284173038.68.0.776881510127.issue9608@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is another edit pass, incorporating ?ric's suggestions and adding some additional tweaks.  In particular, I eliminated the anti-pattern of catching (IOError, OSError) in one of the earlier examples in favor of the correct EnvironmentError, and also improved the error message generated in that case :)

----------
Added file: http://bugs.python.org/file18843/doanddont-except.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9608>
_______________________________________

From report at bugs.python.org  Sat Sep 11 05:55:05 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Sep 2010 03:55:05 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284177305.94.0.396242740027.issue9819@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

How about TESTFN_UNICODE (test_unicode_file) issue?
Should I reopen this entry or invalid?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Sat Sep 11 06:37:46 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Sep 2010 04:37:46 +0000
Subject: [issue9828] Repeated Py_Initialize and Py_Finalize usage brings fatal
	error?
In-Reply-To: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>
Message-ID: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

When I ran the code in #6869 (msg95444) on py3k, I noticed
Fatal Python error occurs.

# Actually, I need to copy created executable file into
# PC/VC6 directoly where python32_d.dll exists. Otherwise,
# the error "encoding.utf-8 was not found" occured even if
# PC/VC6 was added to environment variable PATH. But probably
# it is another issue.

E:\python-dev\py3k\PC\VC6>foo
--- 0 ---
[34859 refs]
--- 1 ---
Fatal Python error: drop_gil: wrong thread state

... And here is stacktrace.

_NMSG_WRITE(int 10) line 221
abort() line 44 + 7 bytes
Py_FatalError(const char * 0x1e371878) line 2109
drop_gil(_ts * 0x00920d90) line 321 + 10 bytes
PyEval_SaveThread() line 424 + 6 bytes
0012ff30()
PyCFunction_Call(_object * 0x00b99378, _object * 0x00afcc40, _object * 0x00000000) line 89 + 9 bytes
PyObject_Call(_object * 0x00b99378, _object * 0x00afcc40, _object * 0x00000000) line 2149 + 15 bytes
call_function_tail(_object * 0x00b99378, _object * 0x00afcc40) line 2181 + 15 bytes
_PyObject_CallMethod_SizeT(_object * 0x00bf6838, char * 0x1e332898, char * 0x00000000) line 2297 + 13 bytes
io_open(_object * 0x00c17f78, _object * 0x00ae0f88, _object * 0x00000000) line 423 + 16 bytes
PyCFunction_Call(_object * 0x00b0cab8, _object * 0x00ae0f88, _object * 0x00000000) line 84 + 15 bytes
PyObject_Call(_object * 0x00b0cab8, _object * 0x00ae0f88, _object * 0x00000000) line 2149 + 15 bytes
call_function_tail(_object * 0x00b0cab8, _object * 0x00ae0f88) line 2181 + 15 bytes
PyObject_CallMethod(_object * 0x00bf6138, char * 0x1e3d6abc, char * 0x1e3d6ab4) line 2258 + 13 bytes
create_stdio(_object * 0x00bf6138, int 0, int 0, char * 0x1e3d6968, char * 0x00000000, char * 0x00000000) line 808 + 48 bytes
initstdio() line 931 + 28 bytes
Py_InitializeEx(int 1) line 303 + 5 bytes
Py_Initialize() line 314 + 7 bytes
main() line 10 + 8 bytes
mainCRTStartup() line 206 + 25 bytes
KERNEL32! 77e789d5()

Because first run succeeded, Py_Finalize might not do enough
work to reset thread state, I guess.

I didn't try this on other platforms. (thread_nt.h was used here)

----------
components: Interpreter Core
messages: 116075
nosy: ocean-city
priority: normal
severity: normal
status: open
title: Repeated Py_Initialize and Py_Finalize usage brings fatal error?
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9828>
_______________________________________

From report at bugs.python.org  Sat Sep 11 07:06:26 2010
From: report at bugs.python.org (bsidhom)
Date: Sat, 11 Sep 2010 05:06:26 +0000
Subject: [issue9829] Unexpected Fraction.from_float() Behavior
In-Reply-To: <1284181586.06.0.381689525187.issue9829@psf.upfronthosting.co.za>
Message-ID: <1284181586.06.0.381689525187.issue9829@psf.upfronthosting.co.za>


New submission from bsidhom <bsidhom at gmail.com>:

The Fractions.from_float() call returns an incorrect value when run on certain numbers. Some test runs have been listed below. Note that this problem does not exist when the same float is converted to a string and then passed to the standard Fraction() constructor; I do not know if this is an inherent problem due to the structure of the float itself or an implementation issue.

>>> for x in [1.23, 1.24, 1.25, 1.26, 1.27]:
	print(Fraction.from_float(x))
	print(Fraction(str(x)))

	
2769713770832855/2251799813685248
123/100
5584463537939415/4503599627370496
31/25
5/4
5/4
5674535530486825/4503599627370496
63/50
2859785763380265/2251799813685248
127/100

The problem does not exist if a string literal is passed either:

>>> print(Fraction('1.23'))
123/100

----------
components: Library (Lib)
messages: 116076
nosy: bsidhom
priority: normal
severity: normal
status: open
title: Unexpected Fraction.from_float() Behavior
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9829>
_______________________________________

From report at bugs.python.org  Sat Sep 11 07:16:49 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 11 Sep 2010 05:16:49 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284182209.83.0.0352830236965.issue8746@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

That definitely fixes detection for FreeBSD CURRENT with 2.7 and py3k for me.

I'm looking into providing some unit-tests, but the problem is that whether or not chflags functions on the underlying filesystem is problematic. For instance, it won't function on msdosfs (Linux calls it vfat), it won't function on ext[23] (AFAIK), and it didn't function on ZFS (until recently? I'm not sure whether or not the latest patches for ZFS enhance the filesystem to support this functionality). So unfortunately adding tests for this feature (while nice) would potentially be error prone.

Something I tried was:

>>> UF_IMMUTABLE = 2
>>> import tempfile
>>> f = tempfile.mkstemp()[1]
>>> os.getuid()
1000
>>> os.chflags('/tmp', UF_IMMUTABLE)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 1] Operation not permitted: '/tmp'
>>> os.chflags(f, UF_IMMUTABLE)
>>> fd = open(f, 'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 1] Operation not permitted: '/tmp/tmpi_hwY7'
>>> fd = open(f, 'r')
>>> fd = open(f, 'r')
>>> fd.read()
''
>>> os.chflags(f, 0)
>>> fd = open(f, 'w')
>>> fd.write('foo')
>>> fd.close()
>>> fd = open(f, 'r')
>>> fd.read()
'foo'
>>> fd.close()

Also, the flags are missing that are described in the manpage. I'll provide a patch for those.

Otherwise, it looks like everything's functioning as expected for basic end-to-end tests with chflags(2).

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 07:21:32 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 11 Sep 2010 05:21:32 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284182492.32.0.350185952878.issue8746@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Additional tests would be great.  It is probably reasonable to make some simplifying assumptions about which file systems the test directory would be run on.  I'm guessing other similar file system function tests are not bulletproof on all potential file system types on any modern OS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 07:36:37 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Sep 2010 05:36:37 +0000
Subject: [issue9828] Repeated Py_Initialize and Py_Finalize usage brings fatal
	error?
In-Reply-To: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>
Message-ID: <1284183397.29.0.512769173314.issue9828@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, msg92444

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9828>
_______________________________________

From report at bugs.python.org  Sat Sep 11 07:56:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Sep 2010 05:56:40 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284184600.44.0.842772419991.issue9819@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> How about TESTFN_UNICODE (test_unicode_file) issue?

  File "e:\python-dev\py3k\lib\test\test_unicode_file.py", line 12, in <module>
    TESTFN_UNICODE.encode(TESTFN_ENCODING)
UnicodeEncodeError: 'mbcs' codec can't encode characters in position 0--1: invalid character

That's because mbcs encoding is more strict on Windows. But this test is not needed on Windows. Please try attached patch (unicode_file.patch).

----------
keywords: +patch
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Sat Sep 11 07:56:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Sep 2010 05:56:51 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284184611.31.0.605654295671.issue9819@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file18845/unicode_file.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Sat Sep 11 09:23:42 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Sep 2010 07:23:42 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284189822.51.0.943065201121.issue9819@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you, your patch works.

E:\python-dev\py3k>py3k -m test.test_unicode_file
test_directories (__main__.TestUnicodeFiles) ... ok
test_single_files (__main__.TestUnicodeFiles) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.611s

OK
[69875 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Sat Sep 11 11:13:40 2010
From: report at bugs.python.org (Marco Buccini)
Date: Sat, 11 Sep 2010 09:13:40 +0000
Subject: [issue9830] Python 2.7 x64 not properly installed on Windows 7
	(registry)
In-Reply-To: <1284196420.02.0.512208117975.issue9830@psf.upfronthosting.co.za>
Message-ID: <1284196420.02.0.512208117975.issue9830@psf.upfronthosting.co.za>


New submission from Marco Buccini <marcusbu at gmail.com>:

I've just installed Python 2.7 x86-64, on my 64-bit Windows 7, then I've tried to install some packages - such as setuptools and pyside - but a message during the installation said something like "Cannot find Python2.7 in the windows registry".

So I've removed the 64-bit version of Python, then I've installed that one of 32-bit and, as expected, it works fine.

I've also tried to search on google to see if it's a Python bug or not, but I've found only this unreachable link: http://bugs.python.org/setuptools/issue2

Do you confirm this bug?

----------
components: Installation
messages: 116083
nosy: markon
priority: normal
severity: normal
status: open
title: Python 2.7 x64 not properly installed on Windows 7 (registry)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9830>
_______________________________________

From report at bugs.python.org  Sat Sep 11 11:46:20 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 11 Sep 2010 09:46:20 +0000
Subject: [issue9831] test_distutils fails on MacOSX 10.6
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

Using py3k branch revision 84707, on Mac OSX 10.6, case-sensitive HFS+ filesystem.


======================================================================
FAIL: test_package_data (distutils.tests.test_build_py.BuildPyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/distutils/tests/test_build_py.py", line 56, in test_package_data
    self.assertTrue("__init__.pyc" in files)
AssertionError: False is not True

----------
components: Tests
messages: 116084
nosy: cartman
priority: normal
severity: normal
status: open
title: test_distutils fails on MacOSX 10.6
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sat Sep 11 11:47:18 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 11 Sep 2010 09:47:18 +0000
Subject: [issue9832] test_unicodedata fails on MacOSX 10.6
In-Reply-To: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>
Message-ID: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

Using py3k branch revision 84707, on Mac OSX 10.6, case-sensitive HFS+ filesystem.


======================================================================
FAIL: test_ucd_510 (test.test_unicodedata.UnicodeMiscTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/test/test_unicodedata.py", line 266, in test_ucd_510
    self.assertTrue("\u1d79".upper()=='\ua77d')
AssertionError: False is not True

======================================================================
FAIL: test_method_checksum (test.test_unicodedata.UnicodeMethodsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/test/test_unicodedata.py", line 67, in test_method_checksum
    self.assertEqual(result, self.expectedchecksum)
AssertionError: '72252619bcc5d47da59734c1a2bc8f8dd34e14f8' != '4504dffd035baea02c5b9de82bebc3d65e0e0baf'
- 72252619bcc5d47da59734c1a2bc8f8dd34e14f8
+ 4504dffd035baea02c5b9de82bebc3d65e0e0baf

----------
components: Tests
messages: 116085
nosy: cartman
priority: normal
severity: normal
status: open
title: test_unicodedata fails on MacOSX 10.6
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9832>
_______________________________________

From report at bugs.python.org  Sat Sep 11 11:48:13 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 11 Sep 2010 09:48:13 +0000
Subject: [issue9833] test_ttk_guionly fails on MacOSX 10.6
In-Reply-To: <1284198493.67.0.22042162237.issue9833@psf.upfronthosting.co.za>
Message-ID: <1284198493.67.0.22042162237.issue9833@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

Using py3k branch revision 84707, on Mac OSX 10.6, case-sensitive HFS+ filesystem.


======================================================================
ERROR: test_tab_identifiers (tkinter.test.test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/tkinter/test/test_ttk/test_widgets.py", line 560, in test_tab_identifiers
    self.assertEqual(self.nb.tab('@5,5'), self.nb.tab('current'))
  File "/Users/cartman/Sources/py3k/Lib/tkinter/ttk.py", line 922, in tab
    return _val_or_dict(kw, self.tk.call, self._w, "tab", tab_id)
  File "/Users/cartman/Sources/py3k/Lib/tkinter/ttk.py", line 318, in _val_or_dict
    res = func(*(args + options))
_tkinter.TclError: tab '@5,5' not found

======================================================================
FAIL: test_identify (tkinter.test.test_ttk.test_widgets.WidgetTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/tkinter/test/test_ttk/test_widgets.py", line 27, in test_identify
    self.assertEqual(self.widget.identify(5, 5), "label")
AssertionError: 'Button.button' != 'label'
- Button.button
+ label


======================================================================
FAIL: test_traversal (tkinter.test.test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/tkinter/test/test_ttk/test_widgets.py", line 721, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child1))
AssertionError: '.4320099472' != '.4320099600'
- .4320099472
?         ^^^
+ .4320099600
?         ^^^

----------
components: Tests
messages: 116086
nosy: cartman
priority: normal
severity: normal
status: open
title: test_ttk_guionly fails on MacOSX 10.6
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9833>
_______________________________________

From report at bugs.python.org  Sat Sep 11 12:21:39 2010
From: report at bugs.python.org (Baptiste Carvello)
Date: Sat, 11 Sep 2010 10:21:39 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1284200499.23.0.470161805746.issue6011@psf.upfronthosting.co.za>


Baptiste Carvello <baptiste13z at free.fr> added the comment:

Hello,

I just tried your patch on latest svn (r84707), but I found out that the problem I reported can no more be reproduced. First, '_locale' seems now to be built earlier. Also, a fallback has been introduced in 'locale.getpreferredencoding'. When '_locale' cannot be imported, the encoding is now parsed from the environment variables (cf 'Lib/locale.py', line 558 and below). It looks like 'locale.getpreferredencoding' is now no more likely to fail than 'sys.getfilesystemencoding'. So I'm not sure if a patch is still needed at all.

In case a patch still makes sense, pay attention that there now also is a 'Lib/sysconfig.py', which also has a '_parse_makefile' function. This function uses a logic similar to the one in 'Lib/distutils/sysconfig.py', even thought it uses the builtin 'open', so it would need the same fix, if one is needed.

Cheers, B.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Sat Sep 11 12:27:29 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 11 Sep 2010 10:27:29 +0000
Subject: [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284200849.87.0.404993203557.issue9827@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Chris, thanks for the patch. I applied it to release27-maint and py3k branches with only minor changes (listed attributes in alphabetical order, and expanded on getMessage a bit).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9827>
_______________________________________

From report at bugs.python.org  Sat Sep 11 12:50:10 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 11 Sep 2010 10:50:10 +0000
Subject: [issue9632] Remove sys.setfilesystemencoding()
In-Reply-To: <1284155965.76.0.632230831431.issue9632@psf.upfronthosting.co.za>
Message-ID: <4C8B5EDD.9010405@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> I didn't proposed to add a new parameter to Py_InitializeEx() (which means create a new function to not break the API), I just wrote that _Py_SetFileSystemEncoding() doesn't work for your use case.

Yes, it would be a new function. I was under the impression that
you wanted to use this approach to resolve the problem of not being
able to set the encoding before any file objects get opened in
Python.

>> If you embed Python into another application, say as scripting
>> language for that application, that other application may have
>> completely different requirements for the user setup than Python
>> expects, e.g. for a Windows GUI application it's not feasible to
>> ask the user to change the environment variables via the registry
>> in order for Python to pick up the right encoding information.
> 
> Is this usecase really realistic? Except you, nobody asked for this feature.

That's more likely due to the fact that no one is embedding
Python 3.x into their apps yet...

>> The application will likely have its own way
>> of configuring things like file system or I/O stream encodings.
>> Think of e.g. GTK or Qt applications as example.
> 
> Qt uses the unicode API on Windows: nativeOpen() uses CreateFile() (in wide chararacter mode), see src/corelib/io/qfsengine_win.cpp.
> 
> Gtk+ (glib) uses also the unicode API on Windows: g_fopen() uses _wfopen(), see glib/gstdio.c.

That's not the point: the applications will have their own way
of configuring themselves and in GUI apps you most likely do not
use environment variable to setup your application. As a result,
the application has to tell the embedded Python how it was configured
in a way that overrides Python's encoding finding magic.

With your patch, the only way to do this is by having the embedded
application change the OS environment. That's not exactly a very
Pythonic way of doing interfacing.

> Python3 doesn't support your usecase currently (it doesn't work). If you consider it important, please open a new issue.
>
> I commited my patch to 3.2 (r84687).

Since you are removing a function that has been around since 3.0,
please make sure that you add proper warnings to 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9632>
_______________________________________

From report at bugs.python.org  Sat Sep 11 12:50:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Sep 2010 10:50:26 +0000
Subject: [issue9832] test_unicodedata fails on MacOSX 10.6
In-Reply-To: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>
Message-ID: <1284202226.08.0.553431506143.issue9832@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Did you run `make distclean` before?

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +flox, ronaldoussoren
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9832>
_______________________________________

From report at bugs.python.org  Sat Sep 11 12:52:01 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 11 Sep 2010 10:52:01 +0000
Subject: [issue9832] test_unicodedata fails on MacOSX 10.6
In-Reply-To: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>
Message-ID: <1284202321.98.0.229757010835.issue9832@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Yes I did make distclean before building (to cleanup old build files).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9832>
_______________________________________

From report at bugs.python.org  Sat Sep 11 13:24:46 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 11 Sep 2010 11:24:46 +0000
Subject: [issue9834] PySequence_GetSlice() lacks a NULL check
In-Reply-To: <1284204286.26.0.294776311301.issue9834@psf.upfronthosting.co.za>
Message-ID: <1284204286.26.0.294776311301.issue9834@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

PySequence_GetSlice() in Objects/abstract.c contains the following code:

    mp = s->ob_type->tp_as_mapping;
    if (mp->mp_subscript) {

This crashes when the type's "tp_as_mapping" is NULL. The obvious fix is to simply write

    if (mp && mp->mp_subscript)

as basically everywhere else around that function. The problem seems to have occurred during a rewrite for Python 3, it's ok in the 2.x series.

----------
components: Interpreter Core
messages: 116092
nosy: scoder
priority: normal
severity: normal
status: open
title: PySequence_GetSlice() lacks a NULL check
type: crash
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9834>
_______________________________________

From report at bugs.python.org  Sat Sep 11 14:12:00 2010
From: report at bugs.python.org (Thomas Sondergaard)
Date: Sat, 11 Sep 2010 12:12:00 +0000
Subject: [issue9835] ZipFile unix external attributes incorrect for entry
	written with writestr
In-Reply-To: <1284207120.65.0.876260441068.issue9835@psf.upfronthosting.co.za>
Message-ID: <1284207120.65.0.876260441068.issue9835@psf.upfronthosting.co.za>


New submission from Thomas Sondergaard <thomas at sondergaard.cc>:

For entries written with writestr ZipFile doesn't record the file type in the unix external attributes block. It should set it to "regular file" (S_IFREG).

The attached sample creates a zip file. If you inspect it with zipinfo -v, you will see that the unix file type is not correct for the entry stored with writestr.

[ts at roadrunner ~]$ zipinfo -v test.zip |grep "Unix file attributes"
  Unix file attributes (000600 octal):              ?rw-------
  Unix file attributes (100664 octal):              -rw-rw-r--

----------
components: Library (Lib)
files: test.py
messages: 116093
nosy: Thomas.Sondergaard
priority: normal
severity: normal
status: open
title: ZipFile unix external attributes incorrect for entry written with writestr
type: behavior
Added file: http://bugs.python.org/file18846/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9835>
_______________________________________

From report at bugs.python.org  Sat Sep 11 14:53:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Sep 2010 12:53:22 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284209602.25.0.0999528861181.issue9819@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Thank you, your patch works.

Ok, patch commited to 3.2 as r84710. Thanks for your feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Sat Sep 11 15:54:45 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Sep 2010 13:54:45 +0000
Subject: [issue9836] Refleak in PyUnicode_FormatV
In-Reply-To: <1284213285.44.0.689496664907.issue9836@psf.upfronthosting.co.za>
Message-ID: <1284213285.44.0.689496664907.issue9836@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I noticed following refleak.

http://mail.python.org/pipermail/python-checkins/2010-September/097438.html

py3k results for svn r84704 (hg cset 4ffcca0d1896)
--------------------------------------------------

test_unicode leaked [2, 2, 2] references, sum=6

This refleak seems to be introduced in r84704.
I hope attached patch will fix this.

----------
components: Unicode
messages: 116095
nosy: ocean-city
priority: normal
severity: normal
status: open
title: Refleak in PyUnicode_FormatV
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9836>
_______________________________________

From report at bugs.python.org  Sat Sep 11 15:55:02 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Sep 2010 13:55:02 +0000
Subject: [issue9836] Refleak in PyUnicode_FormatV
In-Reply-To: <1284213285.44.0.689496664907.issue9836@psf.upfronthosting.co.za>
Message-ID: <1284213302.72.0.158429276128.issue9836@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords: +patch
Added file: http://bugs.python.org/file18847/py3k_fix_PyUnicode_Format.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9836>
_______________________________________

From report at bugs.python.org  Sat Sep 11 15:57:30 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Sep 2010 13:57:30 +0000
Subject: [issue9836] Refleak in PyUnicode_FormatV
In-Reply-To: <1284213285.44.0.689496664907.issue9836@psf.upfronthosting.co.za>
Message-ID: <1284213450.64.0.815072056416.issue9836@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9836>
_______________________________________

From report at bugs.python.org  Sat Sep 11 16:00:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Sep 2010 14:00:04 +0000
Subject: [issue9829] Unexpected Fraction.from_float() Behavior
In-Reply-To: <1284181586.06.0.381689525187.issue9829@psf.upfronthosting.co.za>
Message-ID: <1284213604.99.0.951397230743.issue9829@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please read about floating point arithmetic in the tutorial:

   http://docs.python.org/tutorial/floatingpoint.html

Also observe that this works:

    >>> Fraction(Decimal('1.23'))
    Fraction(123, 100)

So yes, it is a limitation in how floating point is represented...in all languages and platforms that use binary floating point.

----------
nosy: +r.david.murray
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9829>
_______________________________________

From report at bugs.python.org  Sat Sep 11 16:13:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Sep 2010 14:13:17 +0000
Subject: [issue9830] Python 2.7 x64 not properly installed on Windows 7
	(registry)
In-Reply-To: <1284196420.02.0.512208117975.issue9830@psf.upfronthosting.co.za>
Message-ID: <1284214397.84.0.0853622363321.issue9830@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That bug (the link works fine for me) leads to this bug: Issue6792.  Closing this one as duplicate.

----------
nosy: +r.david.murray
resolution:  -> duplicate
status: open -> closed
superseder:  -> Distutils-based installer does not detect 64bit versions of Python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9830>
_______________________________________

From report at bugs.python.org  Sat Sep 11 16:21:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Sep 2010 14:21:44 +0000
Subject: [issue9835] ZipFile unix external attributes incorrect for entry
	written with writestr
In-Reply-To: <1284207120.65.0.876260441068.issue9835@psf.upfronthosting.co.za>
Message-ID: <1284214904.2.0.212137250799.issue9835@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not very familiar with zipfile, but my immediate reaction is, why should it?  It can't know that the file is a unix file, and indeed if the program is running on windows it may not be.

Perhaps instead there's something missing in the API to allow you to set the correct value when using writestr?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9835>
_______________________________________

From report at bugs.python.org  Sat Sep 11 17:08:46 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 11 Sep 2010 15:08:46 +0000
Subject: [issue9832] test_unicodedata fails on MacOSX 10.6
In-Reply-To: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>
Message-ID: <1284217726.07.0.643641904805.issue9832@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Btw I configured with;

./configure --with-wctype-functions --with-fpectl --with-wide-unicode --with-computed-gotos --enable-ipv6 --with-universal-archs=64-bit MACOSX_DEPLOYMENT_TARGET=10.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9832>
_______________________________________

From report at bugs.python.org  Sat Sep 11 17:10:14 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 11 Sep 2010 15:10:14 +0000
Subject: [issue9831] test_distutils fails on MacOSX 10.6
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1284217814.43.0.202892220213.issue9831@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Btw I configure with;

./configure --with-wctype-functions --with-fpectl --with-wide-unicode --with-computed-gotos --enable-ipv6 --with-universal-archs=64-bit MACOSX_DEPLOYMENT_TARGET=10.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sat Sep 11 17:10:32 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 11 Sep 2010 15:10:32 +0000
Subject: [issue9833] test_ttk_guionly fails on MacOSX 10.6
In-Reply-To: <1284198493.67.0.22042162237.issue9833@psf.upfronthosting.co.za>
Message-ID: <1284217832.45.0.191368020438.issue9833@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Btw I configured with;

./configure --with-wctype-functions --with-fpectl --with-wide-unicode --with-computed-gotos --enable-ipv6 --with-universal-archs=64-bit MACOSX_DEPLOYMENT_TARGET=10.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9833>
_______________________________________

From report at bugs.python.org  Sat Sep 11 17:18:52 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Sep 2010 15:18:52 +0000
Subject: [issue9832] test_unicodedata fails on MacOSX 10.6
In-Reply-To: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>
Message-ID: <1284218332.22.0.327508304564.issue9832@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +michael.foord, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9832>
_______________________________________

From report at bugs.python.org  Sat Sep 11 17:20:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Sep 2010 15:20:37 +0000
Subject: [issue9833] test_ttk_guionly fails on MacOSX 10.6
In-Reply-To: <1284198493.67.0.22042162237.issue9833@psf.upfronthosting.co.za>
Message-ID: <1284218437.4.0.530420684758.issue9833@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This is a duplicate of #8445

----------
nosy: +flox
resolution:  -> duplicate
status: open -> closed
superseder:  -> buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9833>
_______________________________________

From report at bugs.python.org  Sat Sep 11 17:24:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Sep 2010 15:24:37 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1284218677.07.0.89150238619.issue8445@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +cartman, flox, ronaldoussoren
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sat Sep 11 17:28:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Sep 2010 15:28:34 +0000
Subject: [issue9831] test_distutils fails on MacOSX 10.6
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1284218914.39.0.320952491862.issue9831@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
assignee:  -> tarek
components: +Distutils, Macintosh
nosy: +eric.araujo, michael.foord, ned.deily, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sat Sep 11 17:32:52 2010
From: report at bugs.python.org (Thomas Sondergaard)
Date: Sat, 11 Sep 2010 15:32:52 +0000
Subject: [issue9835] ZipFile unix external attributes incorrect for entry
	written with writestr
In-Reply-To: <1284207120.65.0.876260441068.issue9835@psf.upfronthosting.co.za>
Message-ID: <1284219172.42.0.921687382498.issue9835@psf.upfronthosting.co.za>


Thomas Sondergaard <thomas at sondergaard.cc> added the comment:

It does know that the entry is a regular file, and that is the bit of information that is missing in the unix external file attributes. Having said that you do have a point - perhaps it shouldn't record unix external file attributes at all, when the entry isn't picked up from the file system. What it does now is to create unix external file attributes that are invalid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9835>
_______________________________________

From report at bugs.python.org  Sat Sep 11 18:00:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Sep 2010 16:00:39 +0000
Subject: [issue8448] buildbot: test_subprocess failure (test_no_leaking,
	Broken pipe)
In-Reply-To: <1271629678.61.0.824360658357.issue8448@psf.upfronthosting.co.za>
Message-ID: <1284220839.74.0.830302957343.issue8448@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It still happens on the same builder, occasionally.

http://www.python.org/dev/buildbot/builders/sparc%20Debian%203.1/builds/24

----------
components: +Tests
nosy: +flox
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8448>
_______________________________________

From report at bugs.python.org  Sat Sep 11 18:02:22 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 11 Sep 2010 16:02:22 +0000
Subject: [issue9834] PySequence_GetSlice() lacks a NULL check
In-Reply-To: <1284204286.26.0.294776311301.issue9834@psf.upfronthosting.co.za>
Message-ID: <1284220942.59.0.441788027561.issue9834@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r84714

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9834>
_______________________________________

From report at bugs.python.org  Sat Sep 11 18:18:52 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Sep 2010 16:18:52 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1284221932.88.0.943170675642.issue8589@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Still happens with r84709 on PPC Tiger 3.x


======================================================================
FAIL: test_nonascii (test.test_warnings.CEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_warnings.py", line 731, in test_nonascii
    "['ignore:Deprecaci\xf3nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\xc3\x83\xc2\xb3nWarning']" != b"['ignore:Deprecaci\xc3\xb3nWarning']"

======================================================================
FAIL: test_nonascii (test.test_warnings.PyEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_warnings.py", line 731, in test_nonascii
    "['ignore:Deprecaci\xf3nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\xc3\x83\xc2\xb3nWarning']" != b"['ignore:Deprecaci\xc3\xb3nWarning']"

----------------------------------------------------------------------
Ran 71 tests in 9.113s

FAILED (failures=2)



http://www.python.org/dev/buildbot/builders/PPC%20Tiger%203.x/builds/566

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Sat Sep 11 18:52:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 11 Sep 2010 16:52:44 +0000
Subject: [issue9836] Refleak in PyUnicode_FormatV
In-Reply-To: <1284213285.44.0.689496664907.issue9836@psf.upfronthosting.co.za>
Message-ID: <1284223964.86.0.478676477075.issue9836@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> haypo
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9836>
_______________________________________

From report at bugs.python.org  Sat Sep 11 18:52:52 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 11 Sep 2010 16:52:52 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284223972.67.0.8059097965.issue8746@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

I'll add new tests in the next submit for the bug, but here's the code to add the relevant symbols for common to *BSD and OSX, and the Snow Leopard+ and FreeBSD specific chflags of importance for python 2.7 and py3k.

----------
Added file: http://bugs.python.org/file18848/issue8746-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 18:53:31 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 11 Sep 2010 16:53:31 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284224011.4.0.314424465054.issue8746@psf.upfronthosting.co.za>


Changes by Garrett Cooper <yanegomi at gmail.com>:


Added file: http://bugs.python.org/file18849/issue8746-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 18:56:07 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 11 Sep 2010 16:56:07 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284224167.72.0.372628477285.issue8746@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Do you prefer exhaustive tests, or just smoke tests? Honestly IMO, the OS should come prepackaged with tests to ensure that things function according to the requirements set forth in the manpage, so I would prefer the latter because the os methods in the posixmodule are nothing more than thin wrappers above the actual OS syscalls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 19:20:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Sep 2010 17:20:24 +0000
Subject: [issue5729] Allows tabs for indenting JSON output
In-Reply-To: <1239297330.19.0.24635332127.issue5729@psf.upfronthosting.co.za>
Message-ID: <1284225624.06.0.922376017855.issue5729@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Is this merge going to happen before 3.2 beta?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5729>
_______________________________________

From report at bugs.python.org  Sat Sep 11 19:39:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 17:39:40 +0000
Subject: [issue6114] distutils build_ext path comparison only based on strings
In-Reply-To: <1243335359.03.0.865660639037.issue6114@psf.upfronthosting.co.za>
Message-ID: <1284226780.88.0.655976769525.issue6114@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The three ppl mentioned there found and fixed the problem, that's why.
The real question behind the joke was: Are you part of the same community? Where does this fix come from?

> But back to the issue: Can we use a switch or wrapper function to
> change the test method for this path dependent on the OS?
Symlink support detection is not trivial, it depends on platform, version and user rights (the docs say Windows Vista has a notion of ?right to create a symlink?). See Lib/test/symlink_support.py for some scary code.  For our bug, I have hope that a simple ?hasattr(os.path, 'samefile'? will be enough to decide whether to use this function or string comparison.

Do you want to add tests for this bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6114>
_______________________________________

From report at bugs.python.org  Sat Sep 11 20:08:44 2010
From: report at bugs.python.org (David Watson)
Date: Sat, 11 Sep 2010 18:08:44 +0000
Subject: [issue8373] socket: AF_UNIX socket paths not handled according to PEP
	383
In-Reply-To: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>
Message-ID: <1284228524.9.0.75129216022.issue8373@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

Updated the patches for Python 3.2 - these are now simpler as
they do not support bytearray arguments, as these are no longer
used for filenames (the existing code does not support bytearrays
either).

I've put the docs and tests in one patch, and made separate
patches for the code, one for if the linux-pass-unterminated
patch from issue #8372 is applied, and one for if it isn't.

One point I neglected to comment on before is the ability to
specify an address in the Linux abstract namespace as a
filesystem-encoded string prefixed with a null character.  This
may seem strange, but as well as simplifying the code, it does
support an actual use case, as on Linux systems the abstract
namespace is sometimes used to hold names based on real
filesystem paths such as "\x00/var/run/hald/dbus-XAbemUfDyQ", or
imaginary ones, such as "\x00/com/ubuntu/upstart".  In fact,
running "netstat" on my own system did not reveal any non-textual
abstract names in use (although they are of course allowed).

----------
Added file: http://bugs.python.org/file18850/af_unix-pep383-docs-tests-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Sat Sep 11 20:10:04 2010
From: report at bugs.python.org (David Watson)
Date: Sat, 11 Sep 2010 18:10:04 +0000
Subject: [issue8373] socket: AF_UNIX socket paths not handled according to PEP
	383
In-Reply-To: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>
Message-ID: <1284228604.83.0.827085275718.issue8373@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file18851/af_unix-pep383-3.2-with-linux-unterminated.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Sat Sep 11 20:10:35 2010
From: report at bugs.python.org (David Watson)
Date: Sat, 11 Sep 2010 18:10:35 +0000
Subject: [issue8373] socket: AF_UNIX socket paths not handled according to PEP
	383
In-Reply-To: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>
Message-ID: <1284228635.82.0.836894375436.issue8373@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file18852/af_unix-pep383-3.2-without-linux-unterminated.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Sat Sep 11 20:11:55 2010
From: report at bugs.python.org (David Watson)
Date: Sat, 11 Sep 2010 18:11:55 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1284228715.43.0.185122881725.issue8372@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

I've updated the PEP 383 patches at issue #8373 with separate
versions for if the linux-pass-unterminated patch is applied or
not.

If it's not essential to have unit tests for the overrun issue,
I'd suggest applying just the return-unterminated and addrlen
patches and omitting linux-pass-unterminated, for now at least.
This will leave Linux no worse off than a typical BSD-derived
platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sat Sep 11 20:55:12 2010
From: report at bugs.python.org (Chris Leary)
Date: Sat, 11 Sep 2010 18:55:12 +0000
Subject: [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284231312.09.0.316996460398.issue9827@psf.upfronthosting.co.za>


Chris Leary <christopher.leary at cornell.edu> added the comment:

Okay, neat! I put them in that order so that they would correspond to the parameters to ``LogRecord.__init__`` -- do we usually do alphabetical instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9827>
_______________________________________

From report at bugs.python.org  Sat Sep 11 20:59:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Sep 2010 18:59:12 +0000
Subject: [issue9608] Re-phrase best way of using exceptions in doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1284231552.43.0.45581207265.issue9608@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r84719 and r84720, backported to 2.7 in r84721 with the addition of a sentence admitting that sometimes you need a bare except to catch third-party exceptions that don't inherit from Exception.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9608>
_______________________________________

From report at bugs.python.org  Sat Sep 11 21:11:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 19:11:22 +0000
Subject: [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284232282.73.0.791761327806.issue9827@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Vinay, would you mind adding references to the commits (in the form ?rNNN?) so that roundup makes a link?  Thanks in advance.  Also, is this not fixed in 3.1?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9827>
_______________________________________

From report at bugs.python.org  Sat Sep 11 21:13:02 2010
From: report at bugs.python.org (David Watson)
Date: Sat, 11 Sep 2010 19:13:02 +0000
Subject: [issue8373] socket: AF_UNIX socket paths not handled according to PEP
	383
In-Reply-To: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>
Message-ID: <1284232382.74.0.751922996479.issue8373@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

One of the tests got broken by the removal of sys.setfilesystemencoding().  Replaced it.

----------
Added file: http://bugs.python.org/file18853/af_unix-pep383-docs-tests-3.2-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Sat Sep 11 21:14:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 19:14:35 +0000
Subject: [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1284232475.41.0.772298602375.issue9746@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For the person wanting to make a patch: Beware that the abstract collections.Sequence.index method does not support the start and stop arguments, even though concrete methods may (list.index, tuple.index and str.index for example).

----------
keywords: +easy
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9746>
_______________________________________

From report at bugs.python.org  Sat Sep 11 22:43:52 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Sep 2010 20:43:52 +0000
Subject: [issue9210] remove --with-wctype-functions configure option
In-Reply-To: <1278666917.19.0.275398438928.issue9210@psf.upfronthosting.co.za>
Message-ID: <1284237832.18.0.925148936289.issue9210@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I would say, go ahead and apply for 3.2.

----------
nosy: +georg.brandl
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9210>
_______________________________________

From report at bugs.python.org  Sat Sep 11 22:45:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 20:45:11 +0000
Subject: [issue9210] remove --with-wctype-functions configure option
In-Reply-To: <1278666917.19.0.275398438928.issue9210@psf.upfronthosting.co.za>
Message-ID: <1284237911.71.0.654619219843.issue9210@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/issue9210>
_______________________________________

From report at bugs.python.org  Sat Sep 11 23:16:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Sep 2010 21:16:40 +0000
Subject: [issue5729] Allows tabs for indenting JSON output
In-Reply-To: <1239297330.19.0.24635332127.issue5729@psf.upfronthosting.co.za>
Message-ID: <1284239800.09.0.418860245937.issue5729@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That would be nice.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5729>
_______________________________________

From report at bugs.python.org  Sat Sep 11 23:18:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Sep 2010 21:18:16 +0000
Subject: [issue9213] range purports to implement the Sequence ABC,
	but is missing index and count methods
In-Reply-To: <1278702375.23.0.863463663463.issue9213@psf.upfronthosting.co.za>
Message-ID: <1284239896.18.0.156841233786.issue9213@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'd like to have this in 3.2.

----------
nosy: +georg.brandl
priority: high -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9213>
_______________________________________

From report at bugs.python.org  Sat Sep 11 23:20:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Sep 2010 21:20:06 +0000
Subject: [issue9824] SimpleCookie should escape commas and semi-colons
In-Reply-To: <1284137410.37.0.376622837409.issue9824@psf.upfronthosting.co.za>
Message-ID: <1284240006.12.0.138646511534.issue9824@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I will have a look at this, it looks like it could at least use a few tests.

----------
assignee:  -> georg.brandl
nosy: +georg.brandl
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9824>
_______________________________________

From report at bugs.python.org  Sat Sep 11 23:21:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Sep 2010 21:21:38 +0000
Subject: [issue9318] Py3k compilation on old MSVC
In-Reply-To: <1279691347.62.0.710756316078.issue9318@psf.upfronthosting.co.za>
Message-ID: <1284240098.27.0.642242718358.issue9318@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree.

----------
nosy: +georg.brandl
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9318>
_______________________________________

From report at bugs.python.org  Sat Sep 11 23:27:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Sep 2010 21:27:26 +0000
Subject: [issue9054] pyexpat configured with "--with-system-expat" is
	incompatible with expat 2.0.1
In-Reply-To: <1277158370.27.0.787157062055.issue9054@psf.upfronthosting.co.za>
Message-ID: <1284240446.18.0.275714087253.issue9054@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Raising priority.

----------
nosy: +georg.brandl
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9054>
_______________________________________

From report at bugs.python.org  Sat Sep 11 23:30:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 21:30:27 +0000
Subject: [issue5729] Allows tabs for indenting JSON output
In-Reply-To: <1239297330.19.0.24635332127.issue5729@psf.upfronthosting.co.za>
Message-ID: <1284240627.51.0.919132417612.issue5729@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/issue5729>
_______________________________________

From report at bugs.python.org  Sat Sep 11 23:41:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 21:41:35 +0000
Subject: [issue1467929] %-formatting and dicts
Message-ID: <1284241295.46.0.491459873054.issue1467929@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/issue1467929>
_______________________________________

From report at bugs.python.org  Sat Sep 11 23:59:33 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 11 Sep 2010 21:59:33 +0000
Subject: [issue9832] test_unicodedata fails on MacOSX 10.6
In-Reply-To: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>
Message-ID: <1284242373.05.0.670860270743.issue9832@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

According to issue #9210, "--with-wctype-functions" is pending removal.
Could you retry without this switch?

----------
nosy: +amaury.forgeotdarc, lemburg
superseder:  -> remove --with-wctype-functions configure option

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9832>
_______________________________________

From report at bugs.python.org  Sun Sep 12 00:23:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 22:23:40 +0000
Subject: [issue1475523] gettext breaks on plural-forms header
Message-ID: <1284243820.14.0.82464947114.issue1475523@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Could you follow the guidelines at http://www.python.org/dev/patches/ to create patches?  Thanks in advance.

I wonder why you call tearDown from setUp.  Doesn?t unittest do that for you when there is a failure in setUp?  Also, you could use a with statement instead of try/finally.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475523>
_______________________________________

From report at bugs.python.org  Sun Sep 12 00:34:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 22:34:09 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1284244449.26.0.144175785868.issue6792@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Removing 2.6 which only gets security fixes now.

----------
nosy: +eric.araujo
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Sun Sep 12 00:34:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 22:34:57 +0000
Subject: [issue9826] OrderedDict ref cycles break repr()
In-Reply-To: <1284145802.06.0.781537031861.issue9826@psf.upfronthosting.co.za>
Message-ID: <1284244497.47.0.824449750451.issue9826@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9826>
_______________________________________

From report at bugs.python.org  Sun Sep 12 00:36:26 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Sep 2010 22:36:26 +0000
Subject: [issue9318] Py3k compilation on old MSVC
In-Reply-To: <1279691347.62.0.710756316078.issue9318@psf.upfronthosting.co.za>
Message-ID: <1284244586.67.0.493613808578.issue9318@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you, fixed in r84724(py3k).

----------
assignee: ocean-city -> 
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9318>
_______________________________________

From report at bugs.python.org  Sun Sep 12 00:44:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 22:44:32 +0000
Subject: [issue9825] OrderedDict ref cycles cause memory leak
In-Reply-To: <1284145444.07.0.163314050875.issue9825@psf.upfronthosting.co.za>
Message-ID: <1284245072.04.0.0706982282235.issue9825@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

On #python-dev, Raymond, Amaury and Benjamin agreed that __del__ should be removed, with the rationale that this method should be used to release resources other than memory.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9825>
_______________________________________

From report at bugs.python.org  Sun Sep 12 00:50:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 22:50:57 +0000
Subject: [issue9818] build files to build Lib/distutils/command/wininst-9.0*
	are missing
In-Reply-To: <1284111065.95.0.0437799903447.issue9818@psf.upfronthosting.co.za>
Message-ID: <1284245457.81.0.586897895664.issue9818@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, loewis, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9818>
_______________________________________

From report at bugs.python.org  Sun Sep 12 01:03:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 23:03:46 +0000
Subject: [issue9817] expat copyright/license file is missing
In-Reply-To: <1284110111.54.0.68745930028.issue9817@psf.upfronthosting.co.za>
Message-ID: <1284246226.32.0.502302433393.issue9817@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t see a reason not to include this file.  Where would you like to put it?  In Modules/expat?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9817>
_______________________________________

From report at bugs.python.org  Sun Sep 12 01:07:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 23:07:42 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remove dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1284246462.85.0.70250593663.issue9815@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Just to be sure: Have you checked this bug doesn?t apply to 2.7?  Can you add a regression test?

----------
nosy: +eric.araujo
title: test_tarfile sometimes ends with error "Cannot remoe dir" -> test_tarfile sometimes ends with error "Cannot remove dir"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Sun Sep 12 01:18:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 23:18:31 +0000
Subject: [issue9814] subprocess isn't friendly to other Python implementations
	with different GCs
In-Reply-To: <1284073114.59.0.931577015567.issue9814@psf.upfronthosting.co.za>
Message-ID: <1284247111.04.0.976297289985.issue9814@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think all developers agree that we should play nice with all VMs.  Do you want to make patches for these problems?

----------
nosy: +astrand, eric.araujo
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9814>
_______________________________________

From report at bugs.python.org  Sun Sep 12 01:26:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 23:26:30 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284247590.89.0.0602725713943.issue9811@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think supporting different specifiers is one thing, dropping the % character is another.  This is how I understand the bug report.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Sun Sep 12 01:37:26 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 11 Sep 2010 23:37:26 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284248246.19.0.413289182063.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100912.zip is a new version of the regex module.

More speedups. I've been comparing the speed against Perl wherever possible. In some cases Perl is lightning fast, probably because regex is built into the language and it doesn't have to parse method arguments (for some short regexes a large part of the processing time is spent in PyArg_ParseTupleAndKeywords!). In other cases, where it has to use Unicode codepoints outside the 8-bit range, or character properties such as \p{Alpha}, its performance is simply appalling! :-)

----------
Added file: http://bugs.python.org/file18854/issue2636-20100912.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Sep 12 01:43:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 23:43:32 +0000
Subject: [issue9810] bzip2 build sometimes fails (VS8.0)
In-Reply-To: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>
Message-ID: <1284248612.03.0.0909238291211.issue9810@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +brian.curtin, loewis, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9810>
_______________________________________

From report at bugs.python.org  Sun Sep 12 01:46:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 23:46:56 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1284248816.06.0.181105258749.issue9806@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/issue9806>
_______________________________________

From report at bugs.python.org  Sun Sep 12 01:50:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 23:50:42 +0000
Subject: [issue9779] argparse.ArgumentParser not support unicode in print help
In-Reply-To: <1283672170.42.0.322683308746.issue9779@psf.upfronthosting.co.za>
Message-ID: <1284249042.41.0.843204491932.issue9779@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do the docs say this should be supported?  I?m a die-hard unicode user, but this treads the line between fix and feature, so if the docs don?t restrict help to str, this could be fixed, otherwise we?re out of luck for the 2.x series.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9779>
_______________________________________

From report at bugs.python.org  Sun Sep 12 01:54:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 23:54:56 +0000
Subject: [issue9765] tcl-8 vs tcl8
In-Reply-To: <1283546777.07.0.320688875982.issue9765@psf.upfronthosting.co.za>
Message-ID: <1284249296.45.0.93044587559.issue9765@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/issue9765>
_______________________________________

From report at bugs.python.org  Sun Sep 12 01:58:43 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 11 Sep 2010 23:58:43 +0000
Subject: [issue9825] OrderedDict ref cycles cause memory leak
In-Reply-To: <1284145444.07.0.163314050875.issue9825@psf.upfronthosting.co.za>
Message-ID: <1284249523.93.0.821907717792.issue9825@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

?ric, I've got this one.  Thx.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9825>
_______________________________________

From report at bugs.python.org  Sun Sep 12 02:00:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 00:00:56 +0000
Subject: [issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284249656.85.0.739403994866.issue9728@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I tried to find the old FAQ in the Debian package for 2.5 but failed.  It looks like this require a fair bit of version control exploration.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9728>
_______________________________________

From report at bugs.python.org  Sun Sep 12 02:12:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 00:12:38 +0000
Subject: [issue6672] Add Mingw recognition to pyport.h to allow building
	extensions
In-Reply-To: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>
Message-ID: <1284250358.56.0.766749014602.issue6672@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A tip about versions: Bugs are fixed on the active branch, py3k (which will become 3.2), then backported to 3.1 and 2.7.  Security fixes go into 2.5 and 2.6 too.

----------
nosy: +brian.curtin, eric.araujo, jlt63, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6672>
_______________________________________

From report at bugs.python.org  Sun Sep 12 02:15:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 00:15:43 +0000
Subject: [issue9759] GzipFile object should raise ValueError on .read() after
	.close()
In-Reply-To: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>
Message-ID: <1284250543.77.0.715995644211.issue9759@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Should this be fixed in 3.1 and 2.7 too?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9759>
_______________________________________

From report at bugs.python.org  Sun Sep 12 02:18:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 00:18:18 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1284250698.3.0.644535108704.issue9756@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9756>
_______________________________________

From report at bugs.python.org  Sun Sep 12 02:22:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 00:22:28 +0000
Subject: [issue9751] _PyInstance_Lookup() defeats its purpose
In-Reply-To: <1283506212.5.0.831864167364.issue9751@psf.upfronthosting.co.za>
Message-ID: <1284250948.59.0.247860756626.issue9751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It?s not clear whether you want a doc fix or a behavior change.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9751>
_______________________________________

From report at bugs.python.org  Sun Sep 12 02:27:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 00:27:33 +0000
Subject: [issue9608] Re-phrase best way of using exceptions in doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1284251253.97.0.782830742589.issue9608@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nice, thanks!

----------
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9608>
_______________________________________

From report at bugs.python.org  Sun Sep 12 02:28:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 00:28:01 +0000
Subject: [issue9608] Re-phrase best way of using exceptions in doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1284251281.05.0.258348804679.issue9608@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9608>
_______________________________________

From report at bugs.python.org  Sun Sep 12 02:54:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Sep 2010 00:54:58 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284252898.91.0.896417865952.issue9811@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

But if it is a bug, it is a bug in OS/X, not in Python.  Python could potentially fix it for python programs by providing our own strftime, but until someone does that the best we can do is a doc mention of this platform quirk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Sun Sep 12 02:59:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 00:59:52 +0000
Subject: [issue9824] SimpleCookie should escape commas and semi-colons
In-Reply-To: <1284137410.37.0.376622837409.issue9824@psf.upfronthosting.co.za>
Message-ID: <1284253192.14.0.21053483599.issue9824@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for forwarding this upstream.  A tip about Python versions: Bugs are fixed on the active branch, py3k (which will become 3.2), then backported to 3.1 and 2.7.  Security fixes go into 2.5 and 2.6 too.  3.3 means that something won?t make it to 3.2 and is delayed.

----------
nosy: +eric.araujo
versions:  -Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9824>
_______________________________________

From report at bugs.python.org  Sun Sep 12 03:04:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 01:04:09 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284253449.87.0.441068892156.issue9811@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, I understand your first reply now.  Thanks.  Agreed on all your points.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Sun Sep 12 03:07:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 01:07:13 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1284253633.6.0.935650604811.issue9750@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the report and patch.  Some bug tracker tips:

1) It?s possible to replace a file, so that there is always one bug.py and one diff, which is easier for reviewers to understand than a long list of files (possibly all with the same name).  It?s also possible to remove obsolete files so that nobody loses time commenting on them.

2) Can you turn your bug reproducer into a patch for Lib/test/test_sqlite.py?

3) Please follow guidelines on http://www.python.org/dev/patches/ to make patches.

Regarding the code itself:

a) I don?t understand why you added quotes around names that seemed fine without them (for example in ?SELECT name?).

b) I find the master line difficult to read: ?q += ",".join(["'||quote(\"" + col.replace('"', '""') + "\")||'" for col in column_names])?.  You?re using backslashes since there are both single and double quotes, but I would use triple-quoted strings here.  I also find string formatting more readable than string concatenation: 'blah blah "{}" blah'.format(thing.replace('"', '""')).

c) Minor style thing: A generator expression works as fine as a list comprehension in str.join (that is, ",".join(i for i in source) == ";".join([i for i in source])).

Thanks again!

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Sun Sep 12 03:08:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 01:08:59 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1284253739.25.0.252795484593.issue4359@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

#9807 has been recently opened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4359>
_______________________________________

From report at bugs.python.org  Sun Sep 12 05:52:54 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 12 Sep 2010 03:52:54 +0000
Subject: [issue9213] range purports to implement the Sequence ABC,
	but is missing index and count methods
In-Reply-To: <1278702375.23.0.863463663463.issue9213@psf.upfronthosting.co.za>
Message-ID: <1284263574.34.0.888368031482.issue9213@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Thanks, Georg, for prodding.  As a new committer, I have possibly been erring a little too far on the side of having my patches thoroughly reviewed before committing.

I'll commit the patch on Monday if no one raises objections (after re-testing, of course).

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9213>
_______________________________________

From report at bugs.python.org  Sun Sep 12 06:17:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 04:17:37 +0000
Subject: [issue9832] test_unicodedata fails on MacOSX 10.6
In-Reply-To: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>
Message-ID: <1284265057.09.0.768458181439.issue9832@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/issue9832>
_______________________________________

From report at bugs.python.org  Sun Sep 12 06:23:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Sep 2010 04:23:01 +0000
Subject: [issue9825] OrderedDict ref cycles cause memory leak
In-Reply-To: <1284145444.07.0.163314050875.issue9825@psf.upfronthosting.co.za>
Message-ID: <1284265381.6.0.0136080177367.issue9825@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

For 2.7, removed __del__ in r84725.
For 3.2, replaced __del__ with weakrefs in r84727.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9825>
_______________________________________

From report at bugs.python.org  Sun Sep 12 06:25:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 04:25:03 +0000
Subject: [issue1538778] pyo's are not overwritten by different optimization
	levels
Message-ID: <1284265503.43.0.546982491055.issue1538778@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +barry, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1538778>
_______________________________________

From report at bugs.python.org  Sun Sep 12 06:33:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 04:33:46 +0000
Subject: [issue9831] test_distutils fails on MacOSX 10.6
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1284266026.45.0.0393292183982.issue9831@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the report.  Can you apply this change and paste the new, more useful output?

-    self.assertTrue("__init__.pyc" in files)
+    self.assertIn("__init__.pyc", files)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sun Sep 12 07:09:59 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 12 Sep 2010 05:09:59 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remove dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1284268199.88.0.956757433089.issue9815@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I created separate small test case to reproduce, and I tried it on
Python2.7, I couldn't reproduce the issue. And tried it on Python3.1,
I couldn't there neither. (Sorry about that... I included 3.1 in
version box)

And exception might not be related. Because error still occurred
even if I removed "#" before exc_clear() in my attached script.

But if I removed "#" before gc.collect(), test case runs fine.

And I copied Python3.1's Lib/tarfile.py into Python3.2's Lib,
still error occurred. Maybe it's not problem of tarfile module
itself ....?

----------
versions:  -Python 3.1
Added file: http://bugs.python.org/file18855/test_tar_pipe_open_read_error.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Sun Sep 12 07:29:20 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Sep 2010 05:29:20 +0000
Subject: [issue9826] OrderedDict ref cycles break repr()
In-Reply-To: <1284145802.06.0.781537031861.issue9826@psf.upfronthosting.co.za>
Message-ID: <1284269360.96.0.228071176168.issue9826@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r84728 and r84729.
Will backport to 2.7 shortly.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9826>
_______________________________________

From report at bugs.python.org  Sun Sep 12 08:47:14 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 12 Sep 2010 06:47:14 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284274034.05.0.086146843575.issue2636@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

(?flags) are still scoping by default... a new flag to activate that behavior would really by helpful  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Sep 12 09:07:13 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 12 Sep 2010 07:07:13 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284275233.51.0.15112642111.issue8746@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Actually the flags do already exist: note "(as defined in the stat module)" (http://docs.python.org/py3k/library/os.html#os.chflags).  Other than the new UF_HIDDEN, it looks like they are all hardwired there in Lib/stat.py.  There is something to be said for the approach in your patch in that it guarantees that the flags match the build OS definitions; the downside is some lack of portability and cross-testing.  Considering that there are other stat flags in there and have been for a long time, I'd be inclined to not change things other than throwing in UF_HIDDEN.

Regarding testing, perhaps the single most important thing would be to add a test that os.chflags is in fact present on systems where it is expected (to catch any future build problems like the one in this issue).  As you say, these are relatively transparent wrappers and we have to accept the OS's implementation.  Testing for the presence of os.lchflags is a bit trickier in that on OS X it should only be present if Python was built with a MACOSX_DEPLOYMENT_TARGET of 10.5 or higher.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sun Sep 12 10:09:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Sep 2010 08:09:09 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1284278949.88.0.802160574126.issue8589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Still happens with r84709 on PPC Tiger 3.x

It's not the same error, PYTHONWARNINGS is decoded from the wrong encoding: locale encodind instead of utf-8. r84731 should fix this bug (at least, it restores the encoding used because my last commit, r84694).

With r84731, Python decodes PYTHONWARNINGS with strict error handler on Mac OS X, instead of surrogateescape error handler. I don't think that it matters because PYTHONWARNINGS is not supposed to contain raw bytes, and anyway, Mac OS X rejects invalid utf-8 filenames.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Sun Sep 12 10:21:45 2010
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 12 Sep 2010 08:21:45 +0000
Subject: [issue9751] _PyInstance_Lookup() defeats its purpose
In-Reply-To: <1283506212.5.0.831864167364.issue9751@psf.upfronthosting.co.za>
Message-ID: <1284279705.91.0.861959325404.issue9751@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

I propose that we first attempt to fix the crasher; depending on the solution we might then either fix the doc or the code for _PyInstance_Lookup().

If no-one is willing to fix this bug I am fine to let it go.  But somehow I am sure that there is code *somewhere* that sticks non-string keys in old-style classes or instances, and whose __eq__ has side-effects, like caching.  This would create hard-to-reproduce and hard-to-diagnose segfaults.  That's mainly the reason why I think that it should be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9751>
_______________________________________

From report at bugs.python.org  Sun Sep 12 10:29:52 2010
From: report at bugs.python.org (Marko Kohtala)
Date: Sun, 12 Sep 2010 08:29:52 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1284280192.19.0.887616897535.issue9750@psf.upfronthosting.co.za>


Changes by Marko Kohtala <marko.kohtala at gmail.com>:


Removed file: http://bugs.python.org/file18721/sqlite3bug.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Sun Sep 12 10:30:00 2010
From: report at bugs.python.org (Marko Kohtala)
Date: Sun, 12 Sep 2010 08:30:00 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1284280200.5.0.483877529609.issue9750@psf.upfronthosting.co.za>


Changes by Marko Kohtala <marko.kohtala at gmail.com>:


Removed file: http://bugs.python.org/file18722/sqlite3ident.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Sun Sep 12 10:57:22 2010
From: report at bugs.python.org (Marko Kohtala)
Date: Sun, 12 Sep 2010 08:57:22 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1284281842.64.0.959923298138.issue9750@psf.upfronthosting.co.za>


Marko Kohtala <marko.kohtala at gmail.com> added the comment:

Thank you for the review.

I have very limited time to use on this. So even when I'd like to make everything easy for you, have the time you give to python be as productive as possible, I can not.

But I'll respond to your comments on the patch.

a) I added the quotes to every identifier based on a comment in sqlite documentation "SQLite adds new keywords from time to time when it takes on new features. So to prevent your code from being broken by future enhancements, you should normally quote any identifier that is an English language word, even if you do not have to." While fixing one place, I fixed it to follow this recommendation in other places as well.

b) I added quotes using backslashes because it was consistent. The table name was already quoted like that. I agree it could be clearer.

c) I know. I only tried to make minimal changes targeted only to the issues at hand. I did not want to hide the fixes in middlde of changes to style.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Sun Sep 12 10:58:18 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 12 Sep 2010 08:58:18 +0000
Subject: [issue9832] test_unicodedata fails on MacOSX 10.6
In-Reply-To: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>
Message-ID: <1284281898.56.0.128531471702.issue9832@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

On a similar systems (10.6, HFS+ case-sensitive), I was able to reproduce this failure when using those non-standard ./configure params.  The test does not fail after removing --with-wctype-functions.  As noted, --with-wctype-functions is planned to be removed before 3.2 releases. The solution is to not use it.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9832>
_______________________________________

From report at bugs.python.org  Sun Sep 12 10:58:51 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 12 Sep 2010 08:58:51 +0000
Subject: [issue9832] test_unicodedata fails on MacOSX 10.6
In-Reply-To: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>
Message-ID: <1284281931.26.0.504335485792.issue9832@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
stage: unit test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9832>
_______________________________________

From report at bugs.python.org  Sun Sep 12 11:02:41 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 12 Sep 2010 09:02:41 +0000
Subject: [issue9831] test_distutils fails on MacOSX 10.6
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1284282161.04.0.144165417422.issue9831@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I am not able to reproduce that failure running on 10.6 (case-sensitive HFS+) using your ./configure options and running the tests in the build directory (make test).  How are you running the tests?  Could there be a file or directory permissions issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sun Sep 12 11:28:15 2010
From: report at bugs.python.org (Black Dew)
Date: Sun, 12 Sep 2010 09:28:15 +0000
Subject: [issue9837] ZipFileExt.read() reads more data than requested
In-Reply-To: <1284283695.55.0.592905912112.issue9837@psf.upfronthosting.co.za>
Message-ID: <1284283695.55.0.592905912112.issue9837@psf.upfronthosting.co.za>


New submission from Black Dew <blackdew at gmail.com>:

ZipFileExt.read() can return more data than requested, unlike file and other file-like objects.

This function calls read1() in a loop, passing the original requested size even if part of the data was already read thus reading and returning more than the caller requested.

This should be fixed by requesting n-len(buf) or something similar, or at least properly documented.

----------
components: Library (Lib)
messages: 116158
nosy: Black.Dew
priority: normal
severity: normal
status: open
title: ZipFileExt.read() reads more data than requested
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9837>
_______________________________________

From report at bugs.python.org  Sun Sep 12 11:33:35 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 12 Sep 2010 09:33:35 +0000
Subject: [issue9831] test_distutils fails on MacOSX 10.6
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1284284015.42.0.855112109022.issue9831@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Problem is I set PYTHONDONTWRITEBYTECODE to 1, tests should disable this environmental variable before testing for *.pyc files. Closing as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sun Sep 12 11:36:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Sep 2010 09:36:34 +0000
Subject: [issue9836] Refleak in PyUnicode_FormatV
In-Reply-To: <1284213285.44.0.689496664907.issue9836@psf.upfronthosting.co.za>
Message-ID: <1284284194.1.0.701192422042.issue9836@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r84730, thanks for the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9836>
_______________________________________

From report at bugs.python.org  Sun Sep 12 11:38:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Sep 2010 09:38:39 +0000
Subject: [issue9837] ZipFileExt.read() reads more data than requested
In-Reply-To: <1284283695.55.0.592905912112.issue9837@psf.upfronthosting.co.za>
Message-ID: <1284284319.54.0.651707600181.issue9837@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/issue9837>
_______________________________________

From report at bugs.python.org  Sun Sep 12 11:54:22 2010
From: report at bugs.python.org (Nick Dowell)
Date: Sun, 12 Sep 2010 09:54:22 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284285262.62.0.296936511363.issue8746@psf.upfronthosting.co.za>


Nick Dowell <nickdowell at gmail.com> added the comment:

Why should it only be available on OS X if built with MACOSX_DEPLOYMENT_TARGET of 10.5 or higher?
chflags() should be available in earlier versions of the OS:
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/10.3/man2/chflags.2.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sun Sep 12 12:21:57 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 12 Sep 2010 10:21:57 +0000
Subject: [issue903339] OpenVMS file system and UNIVERSAL_NEWLINES support
Message-ID: <1284286917.18.0.349495774927.issue903339@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg114328.

----------
resolution:  -> out of date
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue903339>
_______________________________________

From report at bugs.python.org  Sun Sep 12 12:23:59 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 12 Sep 2010 10:23:59 +0000
Subject: [issue1379804] HP-UX thread stack size needs to be increased
Message-ID: <1284287039.52.0.858909462561.issue1379804@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg114998.

----------
resolution:  -> out of date
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1379804>
_______________________________________

From report at bugs.python.org  Sun Sep 12 12:26:56 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 12 Sep 2010 10:26:56 +0000
Subject: [issue1172011] BaseCookie should call value_decode from __getitem__
Message-ID: <1284287216.69.0.883881006917.issue1172011@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Nor reply to msg114679.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1172011>
_______________________________________

From report at bugs.python.org  Sun Sep 12 12:31:35 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 12 Sep 2010 10:31:35 +0000
Subject: [issue1076515] shutil.move clobbers read-only files.
Message-ID: <1284287495.33.0.0823259845403.issue1076515@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg114985.

----------
resolution:  -> invalid
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1076515>
_______________________________________

From report at bugs.python.org  Sun Sep 12 12:41:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 10:41:18 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1284288078.39.0.746288802576.issue9806@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I agree with msg115992. People do use make to build extension modules, with hard-coded file names in the make targets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Sun Sep 12 12:43:34 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 12 Sep 2010 10:43:34 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1284288214.69.0.722859849135.issue9806@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

however we should expose the name of the SOABI string/extension in python-config, so that people can build with this name if they want to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Sun Sep 12 12:48:25 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 12 Sep 2010 10:48:25 +0000
Subject: [issue1520831] urrlib2 max_redirections=0 disables redirects
Message-ID: <1284288505.24.0.517876343468.issue1520831@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Senthil/John has this simply slipped under the radar?

----------
nosy: +BreamoreBoy
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1520831>
_______________________________________

From report at bugs.python.org  Sun Sep 12 12:54:03 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 12 Sep 2010 10:54:03 +0000
Subject: [issue9828] Repeated Py_Initialize and Py_Finalize usage brings fatal
	error?
In-Reply-To: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>
Message-ID: <1284288843.41.0.947307103555.issue9828@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> pitrou
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9828>
_______________________________________

From report at bugs.python.org  Sun Sep 12 12:56:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 12 Sep 2010 10:56:48 +0000
Subject: [issue9817] expat copyright/license file is missing
In-Reply-To: <1284110111.54.0.68745930028.issue9817@psf.upfronthosting.co.za>
Message-ID: <1284289008.37.0.647555859881.issue9817@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Same here.

We also have sections "Licenses and Acknowledgements for incorporated software", e.g. in Doc/license.rst; the text should be added there too.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9817>
_______________________________________

From report at bugs.python.org  Sun Sep 12 13:01:54 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 12 Sep 2010 11:01:54 +0000
Subject: [issue1521051] Extra configurability for doctest TestCases
Message-ID: <1284289314.25.0.720607110116.issue1521051@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

The patch appears to be way out of date.  Is there any interest in the concept of this patch, has something similar already been done or what?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521051>
_______________________________________

From report at bugs.python.org  Sun Sep 12 13:02:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 12 Sep 2010 11:02:24 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1284289344.66.0.278446023348.issue9806@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It is available via sysconfig, so that would not be a problem.

Patch is attached; I'm not sure if the option name --so is the best one though.

----------
Added file: http://bugs.python.org/file18856/pc-so.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Sun Sep 12 13:24:03 2010
From: report at bugs.python.org (Marien Zwart)
Date: Sun, 12 Sep 2010 11:24:03 +0000
Subject: [issue8652] Minor improvements to the "Handling Exceptions" part of
	the tutorial
In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>
Message-ID: <1284290643.1.0.683496424344.issue8652@psf.upfronthosting.co.za>


Marien Zwart <m_zwart at 123mail.org> added the comment:

Sorry for forgetting about this for so long.

The attached patch makes the following changes:

Removes the two instances I noticed of treating exception instances as sequences. This no longer works in python 3 and is not very useful in python 2, so best avoided.

Adds a warning explaining ``except FooException, BarException:`` does not do what you might think. I think this is a good warning to have (because you *can* omit those parens in many other places) and it mentions the pre-python 2.6 syntax for "as" by side effect.

There are two things I'm not entirely happy about:

I initially wrote ``print "I/O error({0.errno}): {0.strerror}".format(e)``, but then noticed this string formatting trick is not mentioned in the previous chapter of the tutorial. Dict access (``"{0[foo]}".format(d)``) is, but attribute access is not. Is this worth adding to that chapter, so it can be used here?

Binding an exception instance to a variable (using "as") is explained near the bottom of the section on catching exceptions, well before it is used. Perhaps this could do with a bit of reordering? I felt it better to keep my initial patch more minimal though.

Comments? :)

----------
keywords: +patch
Added file: http://bugs.python.org/file18857/errors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8652>
_______________________________________

From report at bugs.python.org  Sun Sep 12 13:25:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 11:25:32 +0000
Subject: [issue9782] _multiprocessing.c warnings under 64-bit Windows
In-Reply-To: <1283776985.14.0.464453735202.issue9782@psf.upfronthosting.co.za>
Message-ID: <1284290732.89.0.325557300982.issue9782@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It seems that multiprocessing is fairly conservative wrt. 64-bit support. For example, conn_send_string has a string limit of 0x7fffffff. Therefore, several of the warnings are harmless; the respective lengths fit into int just fine.

I recommend that the size_t parameters are converted to int in the places where this is actually known to be correct from control flow (e.g. both cases of conn_send_string), along with an assert() that the value being cast is <= INT_MAX. 

IIUC, _conn_recvall can legitimately return int, no need to return Py_ssize_t: it will only return error codes (possibly MP_SUCCESS). Also, it might be sufficient to restrict the length of _conn_recvall to MAX_INT.

The alternate route would be to actually widen socket_connection to support 64 bit transmits (*); this would be Jesse's call. It's probably acceptable to defer this until somebody needs this enough to contribute a patch. Copying 2GiB over a pipe takes 1.5s on my system.

(*) My protocol proposal would be this: a length with the highest bit set (i.e. >= 0x80000000) indicates a huge message, where another four bytes of of length follow, for a total of 63 bits of length (MSB is unavailable as it serves as the length-of-length indicator). This would not waste bytes for small messages, and be backwards compatible.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9782>
_______________________________________

From report at bugs.python.org  Sun Sep 12 13:35:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 11:35:05 +0000
Subject: [issue9828] Repeated Py_Initialize and Py_Finalize usage brings fatal
	error?
In-Reply-To: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>
Message-ID: <1284291305.24.0.190603686939.issue9828@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't reproduce under Linux. Is 3.1 also affected?
Can you try the following patch:

Index: Python/pythonrun.c
===================================================================
--- Python/pythonrun.c	(r?vision 84718)
+++ Python/pythonrun.c	(copie de travail)
@@ -219,6 +219,8 @@
 
     /* auto-thread-state API, if available */
 #ifdef WITH_THREAD
+    if (PyEval_ThreadsInitialized())
+        PyEval_ReInitThreads();
     _PyGILState_Init(interp, tstate);
 #endif /* WITH_THREAD */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9828>
_______________________________________

From report at bugs.python.org  Sun Sep 12 13:37:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 11:37:53 +0000
Subject: [issue9783] _elementtree.c warnings under 64-bit Windows
In-Reply-To: <1283777393.95.0.65520363014.issue9783@psf.upfronthosting.co.za>
Message-ID: <1284291473.33.0.0194591891748.issue9783@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Instead of

  PyLong_FromLong((Py_uintptr_t) self);

use

   PyLong_FromVoidPtr(self);

For the others, I suggest making length and allocated Py_ssize_t; this is likely a pervasive change. Of course, very few people will currently run into XML documents where some element has more than 2**31 children... You would need several TiB of main memory to represent it using ElementTree.

Fredrik, please indicate whether it is ok to make this kind of change, or whether it would need your explicit approval.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9783>
_______________________________________

From report at bugs.python.org  Sun Sep 12 13:48:02 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Sep 2010 11:48:02 +0000
Subject: [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284292082.71.0.88418111397.issue9827@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@Chris: I just thought that as the list was so long, alphabetic might be easier for people when they remember the attribute name but don't remember exactly what it is.

@Eric: Fair comment, I usually do but sometimes I forget. I have now also updated release31-maint, see r84732.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9827>
_______________________________________

From report at bugs.python.org  Sun Sep 12 13:49:17 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Sep 2010 11:49:17 +0000
Subject: [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284292157.79.0.976117201505.issue9827@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
Removed message: http://bugs.python.org/msg116176

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9827>
_______________________________________

From report at bugs.python.org  Sun Sep 12 13:51:42 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Sep 2010 11:51:42 +0000
Subject: [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284292302.33.0.517000844748.issue9827@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@Chris: I just thought that as the list was so long, alphabetic might be easier for people when they remember the attribute name but don't remember exactly what it is.

@Eric: Fair comment, I usually do but sometimes I forget. I have now also updated release31-maint, see r84733.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9827>
_______________________________________

From report at bugs.python.org  Sun Sep 12 13:57:44 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 11:57:44 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1284292664.16.0.799733584706.issue8372@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I see. Looking at net/unix/af_unix.c:unix_mkname of Linux 2.6, there is a comment that says

   Check unix socket name: [...]
     - if started by not zero, should be NULL terminated (FS object)

However, the code then just does

/*
 * This may look like an off by one error but it is a bit more
 * subtle. 108 is the longest valid AF_UNIX path for a binding.
 * sun_path[108] doesnt as such exist.  However in kernel space
 * we are guaranteed that it is a valid memory location in our
 * kernel address buffer.
 */
((char *)sunaddr)[len] = 0;
len = strlen(sunaddr->sun_path)+1+sizeof(short);
return len;

So it doesn't actually check that it's null-terminated, but always sets the null termination in kernel based on the address length. Interesting.

With all the effort that went into the patch, I recommend to get it right: if there is space for the \0, include it. If the string size is exactly 108, and it's linux, write it unterminated. Else fail.

As for testing: we should then definitely have a test that, if you can create an 108 byte unix socket that its socket name is what we said it should be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Sep 12 14:30:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 12:30:59 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1284294659.82.0.736029382522.issue9786@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The ifdef should go; pthreads always support TLS (since XPG5, 1997).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Sun Sep 12 14:33:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 12 Sep 2010 12:33:22 +0000
Subject: [issue1576120] Support spawnvp[e] + use native execvp[e] on win32
Message-ID: <1284294802.81.0.943660945322.issue1576120@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Brian/Tim any comments on this, the patch contains C code that I'm not qualified to comment on.

----------
nosy: +BreamoreBoy, brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1576120>
_______________________________________

From report at bugs.python.org  Sun Sep 12 14:38:44 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 12:38:44 +0000
Subject: [issue9787] Release the TLS lock during allocations
In-Reply-To: <1283839386.17.0.522591872287.issue9787@psf.upfronthosting.co.za>
Message-ID: <1284295124.53.0.600862270466.issue9787@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What is appMalloc, and what does it have to do with some Python lock?

You seem to suggest that some malloc implementations make use of Python interpreter internals. I would call that a bug in the malloc implementation (it violates standard layering assumptions), and so I'm -1 on inclusion of this patch.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9787>
_______________________________________

From report at bugs.python.org  Sun Sep 12 14:39:52 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 12 Sep 2010 12:39:52 +0000
Subject: [issue1595365] Urllib2 user-agent header added by an opener is
	"frozen"
Message-ID: <1284295192.93.0.983782844105.issue1595365@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

What is the status of this issue?

----------
nosy: +BreamoreBoy
title: User-agent header added by an opener is "frozen" -> Urllib2 user-agent header added by an opener is "frozen"
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1595365>
_______________________________________

From report at bugs.python.org  Sun Sep 12 14:44:29 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Sun, 12 Sep 2010 12:44:29 +0000
Subject: [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1284295469.83.0.35749936124.issue9802@psf.upfronthosting.co.za>


Matthew Woodcraft <matthew at woodcraft.me.uk> added the comment:

> (1) Shouldn't 'reverse=True' be omitted in the second doc
> addition?

Yes, of course, sorry.

> (2) I'd also suggest adding a brief comment about what this
> means for distinct, but equal, objects; otherwise it's not
> really obvious what the point of the doc addition is.

> (3) As a matter of clarity, perhaps replace "this is" with
> "max(iterable, key=key) is", and similarly for min.

I've attached a new patch incorporating these suggestions.

----------
Added file: http://bugs.python.org/file18858/functions.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9802>
_______________________________________

From report at bugs.python.org  Sun Sep 12 14:44:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 12:44:41 +0000
Subject: [issue9837] ZipFileExt.read() reads more data than requested
In-Reply-To: <1284283695.55.0.592905912112.issue9837@psf.upfronthosting.co.za>
Message-ID: <1284295481.0.0.8573295038.issue9837@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed. In most cases, though, read1(n) will return exactly n bytes and the loop will therefore end immediately with the right buf size. Do you have a simple test case?

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9837>
_______________________________________

From report at bugs.python.org  Sun Sep 12 14:46:32 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 12 Sep 2010 12:46:32 +0000
Subject: [issue1599254] mailbox: other programs' messages can vanish without
	trace
Message-ID: <1284295592.06.0.216337525063.issue1599254@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Does any core committer fancy reviewing the 18 attached patches? :)

----------
nosy: +BreamoreBoy
versions: +Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1599254>
_______________________________________

From report at bugs.python.org  Sun Sep 12 14:52:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 12:52:39 +0000
Subject: [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1284295959.07.0.532242446739.issue9802@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As an aside, I still like Jeffrey Yasskin's suggestion on the
> python-dev mailing list that the sensible definition for max would
> maintain the invariant that max(iterable) be equivalent to
> sorted(iterable)[-1]

What's interesting is the practical consequence that:

x, y = min(x, y), max(x, y)

cannot give you twice the same object.

Of course, there are subtle implications of how it will be implemented (especially with objects which have a partial order relationship to each other). Since max() is supposed to work on any iterator, we probably don't want to build an intermediate sequence and fetch elements in reverse order; instead perhaps use (not Py_LT) instead of Py_GT.

----------
nosy: +pitrou
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9802>
_______________________________________

From report at bugs.python.org  Sun Sep 12 15:01:04 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 12 Sep 2010 13:01:04 +0000
Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to
	urllib
In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za>
Message-ID: <1284296464.04.0.173370481814.issue4733@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Senthil: could you review the attached patch please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4733>
_______________________________________

From report at bugs.python.org  Sun Sep 12 15:23:47 2010
From: report at bugs.python.org (Pauli Virtanen)
Date: Sun, 12 Sep 2010 13:23:47 +0000
Subject: [issue9838] Inadequate C-API to Python 3 I/O objects
In-Reply-To: <1284297827.04.0.573858766917.issue9838@psf.upfronthosting.co.za>
Message-ID: <1284297827.04.0.573858766917.issue9838@psf.upfronthosting.co.za>


New submission from Pauli Virtanen <pav at iki.fi>:

The C-API exposed by the `io` module on Python 3.1/3.2 is very limited, and makes interfacing with Python file objects in extension modules difficult.

In more detail:

1) Because the Python layer has buffering etc., the file handle returned by `PyObject_AsFileDescriptor` is not usable as-is. It requires flush and seek before use, every time there is a chance that the file object has been accessed on the Python side. 

2) There are no C-API functions such as the minimal set of `PyFile_Write(buf, length)`, `PyFile_Read(buf, length)`, `PyFile_Seek(pos, whence)`, `PyFile_Tell()`.

Instead, every call must go through PyObject_CallMethod, and the file objects only handle `PyBytes` and `PyByteArray` which are cumbersome and inefficient to use in extension modules.

----------
components: Extension Modules
messages: 116188
nosy: pv
priority: normal
severity: normal
status: open
title: Inadequate C-API to Python 3 I/O objects
type: feature request
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9838>
_______________________________________

From report at bugs.python.org  Sun Sep 12 15:23:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 13:23:50 +0000
Subject: [issue9839] Test issue
In-Reply-To: <1284297830.23.0.244332630291.issue9839@psf.upfronthosting.co.za>
Message-ID: <1284297830.23.0.244332630291.issue9839@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

Will this have two patch keywords?

----------
files: rss.xml.diff
keywords: patch
messages: 116189
nosy: loewis
priority: normal
severity: normal
status: open
title: Test issue
Added file: http://bugs.python.org/file18859/rss.xml.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9839>
_______________________________________

From report at bugs.python.org  Sun Sep 12 15:24:25 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 13:24:25 +0000
Subject: [issue9839] Test issue
In-Reply-To: <1284297830.23.0.244332630291.issue9839@psf.upfronthosting.co.za>
Message-ID: <1284297865.21.0.331080537352.issue9839@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

No.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9839>
_______________________________________

From report at bugs.python.org  Sun Sep 12 15:37:40 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 13:37:40 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1284298660.22.0.520207341187.issue9784@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's probably best to rewrite these functions in the way the SDK Example section works (i.e. CreateFile/ReadFile) instead of _open/_read (*). As Amaury says, the warnings are harmless: the file numbers will always be in range, as _open created them that way (in fact, they will most likely be below 20 or so).

(*) They must have changed the SDK docs over time; IIRC, I already copied the current text (using _open) from the SDK docs back then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Sun Sep 12 15:47:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 13:47:26 +0000
Subject: [issue9838] Inadequate C-API to Python 3 I/O objects
In-Reply-To: <1284297827.04.0.573858766917.issue9838@psf.upfronthosting.co.za>
Message-ID: <1284299246.57.0.843557049419.issue9838@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Instead, every call must go through PyObject_CallMethod, and the file
> objects only handle `PyBytes` and `PyByteArray` which are cumbersome
> and inefficient to use in extension modules.

Because of the generic nature of the 3.x I/O stack, even shortcuts such as the proposed PyFile_Write will still have to use PyObject_CallMethod(obj, "write", ...) under the hood.

As for the types handled by file objects, you should be able to use a PyMemoryViewObject, which allows you to create a memory buffer without copying it (if that's what you're after).
You can also pass your own objects provided they support the new buffer API: http://docs.python.org/dev/c-api/buffer.html#bufferobjects
(I agree this documentation is not very well written, though)

So, bottom line, we could create a set of PyFile_* wrappers (or, rather, PyStream_*), but they wouldn't be much more efficient that what you can write by hand. Do you still think it's worth it? If so, I think you should float the idea on python-dev (the mailing-list).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9838>
_______________________________________

From report at bugs.python.org  Sun Sep 12 15:49:40 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 13:49:40 +0000
Subject: [issue3402] test_nis is hanging on Solaris
In-Reply-To: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za>
Message-ID: <1284299380.2.0.120121146319.issue3402@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It should not hang anymore, since r84172/r84198. The issue was a GIL-based deadlock: the GIL was acquired and then not released in a callback function, so the next callback caused a deadlock.

The actual cause was a non-ASCII character in the NIS database which caused Unicode creation to fail in the callback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3402>
_______________________________________

From report at bugs.python.org  Sun Sep 12 15:50:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 13:50:54 +0000
Subject: [issue9828] Repeated Py_Initialize and Py_Finalize usage brings fatal
	error?
In-Reply-To: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>
Message-ID: <1284299454.69.0.552652212907.issue9828@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It should be noted that repeatedly calling Py_Initialize / Py_Finalize leaks a lot (even without the "import _ctypes"):

--- 0 ---
[34543 refs]
--- 1 ---
[37540 refs]
--- 2 ---
[40504 refs]
--- 3 ---
[43468 refs]
--- 4 ---
[46432 refs]
--- 5 ---
[49396 refs]
--- 6 ---
[52360 refs]
--- 7 ---
[55324 refs]
--- 8 ---
[58288 refs]
--- 9 ---
[61252 refs]
--- 10 ---
[64216 refs]

And it also translates into memory consumption...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9828>
_______________________________________

From report at bugs.python.org  Sun Sep 12 15:55:31 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 12 Sep 2010 13:55:31 +0000
Subject: [issue3402] test_nis is hanging on Solaris
In-Reply-To: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za>
Message-ID: <1284299731.0.0.984557882294.issue3402@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thank you, Martin. Reenabled the test in r84735.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3402>
_______________________________________

From report at bugs.python.org  Sun Sep 12 16:02:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 14:02:33 +0000
Subject: [issue9793] Typo fix in What's New for 3.2: dynmaic -> dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1284300153.07.0.722655752077.issue9793@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Dag: thanks again for the patch. You did everything correctly; Eric's remarks were just in case you plan to submit contributions in an ongoing manner.

Raymond: that it makes users go through the hoops of getting a tracker account, doing a checkout and creating a patch is an indication that spell-editing should *not* be postponed until much later. Some people are very sensitive to typos (I know I am, for German), so we will continue to get reports about that whenever we release stuff with typos. If you can, it would be good if you could do a spell-check before every alpha/beta release (if you can't, we just have to wait for the users to tell us).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9793>
_______________________________________

From report at bugs.python.org  Sun Sep 12 16:03:35 2010
From: report at bugs.python.org (Black Dew)
Date: Sun, 12 Sep 2010 14:03:35 +0000
Subject: [issue9837] ZipFileExt.read() reads more data than requested
In-Reply-To: <1284283695.55.0.592905912112.issue9837@psf.upfronthosting.co.za>
Message-ID: <1284300215.66.0.0513376204994.issue9837@psf.upfronthosting.co.za>


Black Dew <blackdew at gmail.com> added the comment:

If i follow the logic in read1() correctly it will do that only for files with very low compression ratios (the original sample where i noticed that problem was actually a chunk of encrypted data inside the zip).

>From the comments referring to "with at most one read() system call" I would also assume it's OS-specific.

Anyway, I've attached a small file that reproduces this behavior on my system (win xp 32bit). When i run it i get "AssertionError: Read returned 4097 bytes (4096 requested)"

----------
Added file: http://bugs.python.org/file18860/a.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9837>
_______________________________________

From report at bugs.python.org  Sun Sep 12 16:12:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 14:12:08 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1284300728.52.0.323278816173.issue9042@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9042>
_______________________________________

From report at bugs.python.org  Sun Sep 12 16:17:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 14:17:05 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1284301025.35.0.555550283487.issue9799@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I know this is closed, but traditionally, we have put stuff like this into README (not sure whether S?bastien read the README :-). So if anybody feel like adding some text, go ahead.

In return, feel also free to take out some text that talks about very old problems.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Sun Sep 12 16:18:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 14:18:50 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1284301130.5.0.54164739371.issue9042@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Unfortunately, 2.6 and 3.1 are stable releases, they only get security > and documentation fixes. 2.7 is nearly in the same state

Well, that's false. 2.7 and 3.1 both receive bug fixes (and this looks like a bug to me :-)).

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9042>
_______________________________________

From report at bugs.python.org  Sun Sep 12 16:49:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 14:49:15 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1284302955.26.0.981165521606.issue9799@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, there's a Misc/AIX-NOTES file which needs updating. S?bastien, do you want to do that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Sun Sep 12 16:53:44 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 14:53:44 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284303224.07.0.53393456851.issue9807@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If the feature to be provided is "multiple Python installations with the same prefix", then I suggest to generalize this beyond the debug build. One approach would be:

1. add a --bin-suffix configure option (Debian: set this to _d when creating the debug build)
2. expose this as sys.bin_suffix
3. use this in many more places than this patch does, e.g. for python3-config (python3_d-config?), python3.pc, idle3, pydoc3, 2to3, and anything else that either is a binary or refers to one.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Sun Sep 12 16:58:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 14:58:47 +0000
Subject: [issue9837] ZipFileExt.read() reads more data than requested
In-Reply-To: <1284283695.55.0.592905912112.issue9837@psf.upfronthosting.co.za>
Message-ID: <1284303527.76.0.0729338238064.issue9837@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, thank you. I've fixed the issue and added a test in r84737 (3.x) and r84739 (2.7).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9837>
_______________________________________

From report at bugs.python.org  Sun Sep 12 16:59:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 14:59:28 +0000
Subject: [issue9759] GzipFile object should raise ValueError on .read() after
	.close()
In-Reply-To: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>
Message-ID: <1284303568.26.0.740191089916.issue9759@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9759>
_______________________________________

From report at bugs.python.org  Sun Sep 12 17:03:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 15:03:22 +0000
Subject: [issue9809] Wrong Registery Entries on win64
In-Reply-To: <1284009593.81.0.159283716249.issue9809@psf.upfronthosting.co.za>
Message-ID: <1284303802.5.0.884800378986.issue9809@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As Brian explains: if you want the Wow6432 entries, install the 32-bit Python - which will install just fine on your 64-bit system, and is, in many cases, the better choice.

----------
nosy: +loewis
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9809>
_______________________________________

From report at bugs.python.org  Sun Sep 12 17:20:36 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 12 Sep 2010 15:20:36 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284304836.09.0.000277857304202.issue8746@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Nick: "lchflags". lchflags is only available in 10.5 or higher, unlike chflags which has been around for much longer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sun Sep 12 17:43:19 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 12 Sep 2010 15:43:19 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1284306199.36.0.682352108112.issue9806@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

--extension-suffix ?
doesn't use the `so', which you don't see on MacOs, HpUX and Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Sun Sep 12 17:51:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 15:51:41 +0000
Subject: [issue9817] expat copyright/license file is missing
In-Reply-To: <1284110111.54.0.68745930028.issue9817@psf.upfronthosting.co.za>
Message-ID: <1284306701.37.0.614926005038.issue9817@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9817>
_______________________________________

From report at bugs.python.org  Sun Sep 12 17:58:47 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 12 Sep 2010 15:58:47 +0000
Subject: [issue9817] expat copyright/license file is missing
In-Reply-To: <1284110111.54.0.68745930028.issue9817@psf.upfronthosting.co.za>
Message-ID: <1284307127.46.0.0224340301327.issue9817@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

the .rst file is missing the zlib and libffi licenses too. will add them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9817>
_______________________________________

From report at bugs.python.org  Sun Sep 12 18:00:27 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 12 Sep 2010 16:00:27 +0000
Subject: [issue9828] Repeated Py_Initialize and Py_Finalize usage brings fatal
	error?
In-Reply-To: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>
Message-ID: <1284307227.91.0.675789653764.issue9828@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> Is 3.1 also affected?
Sorry, 3.1 is not affected.

> Can you try the following patch:
Your patch works. :-)

E:\python-dev\py3k\PC\VC6>ctypes_crash.exe
--- 0 ---
[36242 refs]
--- 1 ---
[39140 refs]
--- 2 ---
[41538 refs]
--- 3 ---
[43930 refs]
--- 4 ---
[46322 refs]
--- 5 ---
[48714 refs]
--- 6 ---
[51106 refs]
--- 7 ---
[53498 refs]
--- 8 ---
[55890 refs]
--- 9 ---
[58282 refs]

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9828>
_______________________________________

From report at bugs.python.org  Sun Sep 12 18:02:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 16:02:12 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an error for
	unencodable filenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284307332.63.0.229157586961.issue9820@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What do you gain with this patch? (i.e. what is its advantage?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Sun Sep 12 18:18:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Sep 2010 16:18:49 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an error for
	unencodable filenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284308329.34.0.00144822719653.issue9820@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> What do you gain with this patch? (i.e. what is its advantage?)

You know directly that os.listdir(bytes) is unable to encode the filename, instead of manipulate an invalid filename (b'?') and get the error later (when you use the filename: open, copy, delete, ... the file).

It's the same idea than str+bytes raises an error on Python3: get the error earlier instead of store invalid data and get the error to late.

Anywy, on Windows, it's not a good idea to manipulate bytes filenames. So it's also a way to encourage people to migrate their applications to unicode on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Sun Sep 12 18:20:39 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 12 Sep 2010 16:20:39 +0000
Subject: [issue6869] Embedded python crashed on 4th run, if "ctypes" is used
In-Reply-To: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za>
Message-ID: <1284308439.53.0.265870631219.issue6869@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I found another refcount bug in Python3.x.
Fixed in r84741(py3k), r84742(release31-maint).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6869>
_______________________________________

From report at bugs.python.org  Sun Sep 12 18:21:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 16:21:17 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284126399.18.0.460221190984.issue9822@psf.upfronthosting.co.za>
Message-ID: <4C8CFDF9.4050401@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I did not realize the build instructions recommended using the
> buildbot tool.  It is clearly past time I got around to doing windows
> build myself.

I'd rather prefer a different setup, also: it would
be better if the batch files to get the sources lived in PC (or perhaps
PCbuild), with Tools/buildbot just referring to them.

> Please regenerate the diffs from the top level of the checkout, and
> we'll see if one of the windows devs feels like checking it in.

If the buildbots continue to work, it's fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Sun Sep 12 18:25:48 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 12 Sep 2010 16:25:48 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1284308748.23.0.803672886708.issue8445@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Also reproduced on Snow Leopard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Sep 12 18:31:36 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 16:31:36 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
In-Reply-To: <1284163839.47.0.976327216356.issue767645@psf.upfronthosting.co.za>
Message-ID: <4C8D0063.7070907@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> About Windows: supports_unicode_filenames is False if
> sys.getwindowsversion().platform < 2: win32s (0) or Windows 9x/ME
> (1). I don't know win32s, but I know that Windows 9x/ME is not more
> supported.

Win32s is long gone. It was an emulation layer to support Win32 on
Windows 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Sun Sep 12 18:36:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 16:36:12 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
In-Reply-To: <1284165433.49.0.234813791168.issue767645@psf.upfronthosting.co.za>
Message-ID: <4C8D0177.7080803@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I think that supports_unicode_filenames is still useful to check if
> the filesystem API uses bytes (Linux, FreeBSD, Solaris, ...) or
> characters (Mac OS X, Windows). Mac OS X is a special case because
> the C API uses char* (byte string), but the filesystem encoding is
> fixed to utf-8 and it doesn't accept invalid utf-8 filenames. So I
> would like to say that supports_unicode_filenames should be True on
> Mac OS X (which was the initial request).

Sounds reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Sun Sep 12 18:48:46 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 16:48:46 +0000
Subject: [issue9818] build files to build Lib/distutils/command/wininst-9.0*
	are missing
In-Reply-To: <1284111065.95.0.0437799903447.issue9818@psf.upfronthosting.co.za>
Message-ID: <1284310126.1.0.963869736381.issue9818@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Use PCbuild/bdist_wininst.vcproj.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9818>
_______________________________________

From report at bugs.python.org  Sun Sep 12 18:51:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 16:51:18 +0000
Subject: [issue9828] Repeated Py_Initialize and Py_Finalize usage brings fatal
	error?
In-Reply-To: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>
Message-ID: <1284310278.23.0.740859088774.issue9828@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok. How about this patch now?
(I'm trying to solve this in a clean way :))

----------
keywords: +patch
Added file: http://bugs.python.org/file18861/gildestroy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9828>
_______________________________________

From report at bugs.python.org  Sun Sep 12 18:53:00 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 12 Sep 2010 16:53:00 +0000
Subject: [issue9817] expat copyright/license file is missing
In-Reply-To: <1284110111.54.0.68745930028.issue9817@psf.upfronthosting.co.za>
Message-ID: <1284310380.34.0.0336571861619.issue9817@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

fixed in r84743, r84745 and r84746

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9817>
_______________________________________

From report at bugs.python.org  Sun Sep 12 19:03:16 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 12 Sep 2010 17:03:16 +0000
Subject: [issue9818] build files to build Lib/distutils/command/wininst-9.0*
	are missing
In-Reply-To: <1284111065.95.0.0437799903447.issue9818@psf.upfronthosting.co.za>
Message-ID: <1284310996.27.0.129019472955.issue9818@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

my bad

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9818>
_______________________________________

From report at bugs.python.org  Sun Sep 12 19:12:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 17:12:20 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an error
	for	unencodable filenames
In-Reply-To: <1284308329.34.0.00144822719653.issue9820@psf.upfronthosting.co.za>
Message-ID: <4C8D09F0.7020901@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> You know directly that os.listdir(bytes) is unable to encode the
> filename, instead of manipulate an invalid filename (b'?') and get
> the error later (when you use the filename: open, copy, delete, ...
> the file).

Ok. Then I'm -1 on the patch: you can't know whether the application
actually wants to open the file. Perhaps it only wants to display the
file names, or perhaps it only wants to open some of the files, or
only traverse into subdirectories.

For backwards compatibility, I recommend to leave things as they are.
FindFirst/NextFileA will also do some other interesting conversions,
such as the best-fit conversion (which the "mbcs" code doesn't do
(anymore?)).

Windows has explicit A and W versions, and Python has explicit A
and W types, so it's IMO best to pair them in the natural way
(even if that means code duplication).

> Anywy, on Windows, it's not a good idea to manipulate bytes
> filenames. So it's also a way to encourage people to migrate their
> applications to unicode on Windows.

Only if people run into the issue (which few people will). People
which *do* run into the issue will likely get an error either
way, which will teach them their lesson :-)

----------
title: Windows : os.listdir(b'.') doesn't raise an error for unencodable filenames -> Windows : os.listdir(b'.') doesn't raise an error for	unencodable filenames

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Sun Sep 12 19:14:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 12 Sep 2010 17:14:34 +0000
Subject: [issue9806] no need to try loading posix extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1284311674.93.0.204906189962.issue9806@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Windows isn't relevant here, but for the others, extension-suffix sounds much better.  Added in r84747.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Sun Sep 12 19:20:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 17:20:59 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1284312059.72.0.598594897156.issue8445@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Sep 12 19:42:17 2010
From: report at bugs.python.org (Russell Keith-Magee)
Date: Sun, 12 Sep 2010 17:42:17 +0000
Subject: [issue1521051] Extra configurability for doctest TestCases
Message-ID: <1284313337.72.0.315282185951.issue1521051@psf.upfronthosting.co.za>


Russell Keith-Magee <freakboy3742 at gmail.com> added the comment:

It's still a problem AFAICT. Level of interest is a different matter.

Django has needed this since 2006, so we've always shipped a locally modified copy of the doctest module. 

That said, Django is in the process of moving away from using and recommending doctests, so there's a good chance that we'll be deprecating our local copy in the near future. 

There's still value in the idea -- it provides configuration points that are consistent and reasonable -- but Django's need for this set of changes is waning.

----------
nosy: +freakboy3742

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521051>
_______________________________________

From report at bugs.python.org  Sun Sep 12 20:42:26 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 12 Sep 2010 18:42:26 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284316946.42.0.315589033725.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Another flag? Hmm.

How about this instead: if a scoped flag appears at the end of a regex (and would therefore normally have no effect) then it's treated as though it's at the start of the regex. Thus:

    foo(?i)

is treated like:

    (?i)foo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Sep 12 20:43:44 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 12 Sep 2010 18:43:44 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1284317024.33.0.0339527795183.issue2889@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

PDCurses is not updated, because it is considered stable and mature library that has been tested on Windows platform by many roguelikes. I doubt that ncurses hackers care about Windows compatibility more than just to make it run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Sun Sep 12 20:49:38 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 12 Sep 2010 18:49:38 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1284317378.12.0.57246342785.issue9788@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I agree with Antoine's LIFO comment.  Also, FWIW, the C standard library behaves in a LIFO manner as well (C99 spec - 7.20.4.3 clause 3):

"First, all functions registered by the atexit function are called, in the reverse order of their registration,253) except that a function is called after any previously registered functions that had already been called at the time it was registered. If, during the call to any such function, a call to the longjmp function is made that would terminate the call to the registered function, the behavior is undefined."

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Sun Sep 12 21:48:25 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 12 Sep 2010 19:48:25 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1284292664.16.0.799733584706.issue8372@psf.upfronthosting.co.za>
Message-ID: <20100912194819.GA3701@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

> With all the effort that went into the patch, I recommend to get it right: if there is space for the \0, include it. If the string size is exactly 108, and it's linux, write it unterminated. Else fail.
> 
> As for testing: we should then definitely have a test that, if you can create an 108 byte unix socket that its socket name is what we said it should be.

The attached patches do those things, if I understand you
correctly (the test patches add such a test for Linux, and
linux-pass-unterminated uses memset() to zero out the area
between the end of the actual path and the end of the sun_path
array).

If you're talking about including the null in the address passed
to the system call, that does no harm on Linux, but I think the
more common practice is not to include it.  The FreeBSD SUN_LEN
macro, for instance, is provided to calculate the address length
and does not include the null.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Sep 12 22:15:22 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Sun, 12 Sep 2010 20:15:22 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284322522.57.0.256547566438.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Not that my opinion matters, but for what is it worth, I find it rather unusual to have to use special flags to get "normal" (for some definition of normal) behaviour, while retaining the defaults buggy in some way (like ZEROWIDTH). I would think, the backwards compatibility would not be needed under these circumstances - in such probably marginal cases (or is setting global flags at the end or otherwhere than on beginning oof the pattern that frequent?). It seems, that with many new features and enhancements for previously "impossible" patterns, chances are, that the code using regular expressions in a more advanced way might benefit from reviewing the patterns (where also the flags for "historical" behaviour could be adjusted if really needed).

Anyway, thanks for further improvements! (although it broke my custom function previously misusing the internal data of the regex module for getting the unicode script property (currently unavailable via unicodedata) :-).

Best regards,
   vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Sep 12 22:35:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Sep 2010 20:35:30 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an
	errorfor	unencodablefilenames
In-Reply-To: <4C8D09F0.7020901@v.loewis.de>
Message-ID: <201009122235.13850.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> FindFirst/NextFileA will also do some other interesting conversions,
> such as the best-fit conversion (which the "mbcs" code doesn't do
> (anymore?)).

About mbcs, mbcs codec of Python 3.1 is like .encode('mbcs', 'replace') and 
.decode('mbcs', 'ignore') of Python 3.2 (see issue #850997). By default 
(strict error handler), it now raises errors on undecodable byte sequence and 
unencodable character, whereas Python 3.1 just ignores the error handler.

PyUnicode_EncodeFSDefault / PyUnicode_DecodeFSDefault uses the strict error 
handler.

I just added a note about mbcs in Doc/whatsnew/3.2.rst: r84750.

----------
title: Windows : os.listdir(b'.') doesn't raise an error for	unencodable filenames -> Windows : os.listdir(b'.') doesn't raise an errorfor	unencodablefilenames

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Sun Sep 12 22:47:47 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 12 Sep 2010 20:47:47 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284324467.15.0.97016727689.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The tests for re include these regexes:

    a.b(?s)
    a.*(?s)b

I understand what Georg said previously about some people preferring to put them at the end, but I personally wouldn't do that because some regex implementations support scoped inline flags, although others, like re, don't.

I think that second regex is a bit perverse, though! :-)

On the other matter, I could make the Unicode script and block available through a couple of functions if you need them, eg:

    # Using Python 3 here
    >>> regex.script("A")
    'Latin'
    >>> regex.block("A")
    'BasicLatin'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Sep 12 23:14:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Sep 2010 21:14:56 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an
	errorfor	unencodablefilenames
In-Reply-To: <4C8D09F0.7020901@v.loewis.de>
Message-ID: <201009122314.46191.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It remembers me the discussion of the issue #3187. About unencodable filenames, 
Guido proposed to ignore them or to use errors="replace", and wrote "Failing 
the entire os.listdir() call is not acceptable". (... long discussion ...) And 
finally, os.listdir() ignored undecodable filenames on UNIX/BSD.

Then you introduced the genious PEP 383 (utf8b then renamed surrogateescape) 
and os.listdir() now raises an error if the PyUnicode_FromEncodedObject(v, 
Py_FileSystemDefaultEncoding, "surrogateescape") fails... which doesn't occur 
because of undecodable byte sequence, but for other reasons like a memory 
error.

About Windows, os.listdir(str) never fails, but my question is about 
os.listdir(bytes). Should os.listdir(bytes) returns invalid filenames (encoded 
with "mbcs+replace", filenames not usable to open, rename or delete the file) or 
just ignore them?

> Ok. Then I'm -1 on the patch: you can't know whether the application
> actually wants to open the file. Perhaps it only wants to display the
> file names, or perhaps it only wants to open some of the files, or
> only traverse into subdirectories.
>
> For backwards compatibility, I recommend to leave things as they are.
> FindFirst/NextFileA will also do some other interesting conversions,
> such as the best-fit conversion (which the "mbcs" code doesn't do
> (anymore?)).

"it only wants to open some of the files" is the typical reason for which I 
hate Python2 and its implicit conversion between bytes and characters: it 
works in most cases, but it fails "sometimes". The problem is to define (and 
explain) "sometimes".

The typical use case of listing a directory is a file chooser. On Windows using 
the bytes API, it works in most cases, but it fails if the user picks the 
"wrong" file (name with "?"). That's the problem I would like to address.

--

Ignore unencodable filenames solution is compatible with the "traverse into 
subdirectories" case. And it does also keep backward compatibility (except 
that unencodable files are hidden, which is a least problem I think).

--

I proposed to raise an error on unencodable filename. I changed my mind after 
reading your answer and the discussion on #3187. My patch breaks compatibility 
and users don't bother to unencodable filenames. Eg. glob("*.mp3") should not 
fail if the directory contains a temporary unencodable filename ("xxx.tmp").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Sun Sep 12 23:16:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 12 Sep 2010 21:16:19 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284326179.82.0.28697223713.issue2636@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Matthew, I understand why you want to have these flags scoped, and if you designed a regex dialect from scratch, that would be the way to go.  However, if we want to integrate this in Python 3.2 or 3.3, this is an absolute killer if it's not backwards compatible.

I can live with behavior changes that really are bug fixes, and of course with new features that were invalid syntax before, but this is changing an aspect that was designed that way (as the test case shows), and that really is not going to happen without an explicit new flag. Special-casing the "flags at the end" case is too magical to be of any help.

It will be hard enough to get your code into Python -- it is a huge new codebase for an absolutely essential module.  I'm nevertheless optimistic that it is going to happen at some point or other.  Of course, you would have to commit to maintaining it within Python for the forseeable future.

The "script" and "block" functions really belong into unicodedata; you'll have to coordinate that with Marc-Andre.

@Vlastimil: backwards compatibility is needed very much here.  Nobody wants to review all their regexes when switching from Python 3.1 to Python 3.2.  Many people will not care about the improved engine, they just expect their regexes to work as before, and that is a perfectly fine attitude.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Sep 12 23:20:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Sep 2010 21:20:11 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an
	errorfor	unencodablefilenames
In-Reply-To: <4C8D09F0.7020901@v.loewis.de>
Message-ID: <201009122320.01853.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> FindFirst/NextFileA will also do some other interesting conversions,
> such as the best-fit conversion (which the "mbcs" code doesn't do
> (anymore?)).

If we choose to keep this behaviour, I will have to revert my commit on mbcs 
codec to be consistent with os.listdir(). Or at least patch 
PyUnicode_EncodeFSDefault and os.fsencode() (use replace error handler) and 
PyUnicode_DecodeFSDefault and os.fsdecode() (use igrore error handler).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Sun Sep 12 23:30:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 21:30:20 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an	errorfor
	unencodablefilenames
In-Reply-To: <201009122314.46191.victor.stinner@haypocalc.com>
Message-ID: <4C8D4668.2060009@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> About Windows, os.listdir(str) never fails, but my question is about 
> os.listdir(bytes). Should os.listdir(bytes) returns invalid filenames (encoded 
> with "mbcs+replace", filenames not usable to open, rename or delete the file) or 
> just ignore them?

I see nothing wrong with returning incorrect file names.

> "it only wants to open some of the files" is the typical reason for which I 
> hate Python2 and its implicit conversion between bytes and characters: it 
> works in most cases, but it fails "sometimes". The problem is to define (and 
> explain) "sometimes".

Notice that this doesn't change with the patch. It will *still* work
sometimes, and fail sometimes. In fact, for most users and most
applications, it will never fail - *even with your patch applied*.

> Ignore unencodable filenames solution is compatible with the "traverse into 
> subdirectories" case. And it does also keep backward compatibility (except 
> that unencodable files are hidden, which is a least problem I think).

I fail to see why removing incorrect file names from the result list is
any better than keeping them. The result list will be incorrect either way.

In one case (files skipped), the user will not see the file in the
selection dialog, even though he knows its there and explorer shows it
just fine. So he thinks there must be a bug.

In the other case, it displays a non-sensical file name. Again, the user
thinks there is a bug - plus if you click on the file, you get some
error message (hopefully, the application will catch the exception -
the directory may also have changed in-between, so a missing file
error must be recovered from).

So it's a user-visible bug in either case, but if the incorrect file
name is included, it's slightly more obvious that something is wrong.

----------
title: Windows : os.listdir(b'.') doesn't raise an errorfor	unencodablefilenames -> Windows : os.listdir(b'.') doesn't raise an	errorfor unencodablefilenames

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Sun Sep 12 23:30:51 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 12 Sep 2010 21:30:51 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <20100912194819.GA3701@dbwatson.ukfsn.org>
Message-ID: <20100912213045.GA4984@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

I meant to say that FreeBSD provides the SUN_LEN macro, but it
turns out that Linux does as well, and its version behaves the
same as FreeBSD's.  The FreeBSD man pages state that the
terminating null is not part of the address:

http://www.freebsd.org/cgi/man.cgi?query=unix&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html

The examples in Stevens/Rago's "Advanced Programming in the Unix
Environment" also pass address lengths to bind(), etc. that do
not include the null.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Sep 12 23:45:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 21:45:02 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an	errorfor
	unencodablefilenames
In-Reply-To: <201009122320.01853.victor.stinner@haypocalc.com>
Message-ID: <4C8D49DA.7040101@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> If we choose to keep this behaviour, I will have to revert my commit on mbcs 
> codec to be consistent with os.listdir(). Or at least patch 
> PyUnicode_EncodeFSDefault and os.fsencode() (use replace error handler) and 
> PyUnicode_DecodeFSDefault and os.fsdecode() (use igrore error handler).

I think trying to emulate, in Python, what the *A functions do is
futile. IIUC, disables WC_NO_BEST_FIT_CHARS, and may do other stuff
which apparently is undocumented.

However, I fail to see the relationship to this issue. Having the MBCS
codec support strict mode is a good thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Sun Sep 12 23:46:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 21:46:32 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated
	AF_UNIX	addresses
In-Reply-To: <20100912213045.GA4984@dbwatson.ukfsn.org>
Message-ID: <4C8D4A36.7070103@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The examples in Stevens/Rago's "Advanced Programming in the Unix
> Environment" also pass address lengths to bind(), etc. that do
> not include the null.

I didn't (mean to) suggest that the null must be included in the
length - only that it must be included in the path.

----------
title: socket: Buffer overrun while reading unterminated AF_UNIX addresses -> socket: Buffer overrun while reading unterminated AF_UNIX	addresses

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Sep 12 23:58:33 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 12 Sep 2010 21:58:33 +0000
Subject: [issue9210] remove --with-wctype-functions configure option
In-Reply-To: <1278666917.19.0.275398438928.issue9210@psf.upfronthosting.co.za>
Message-ID: <1284328713.4.0.139597308403.issue9210@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> amaury.forgeotdarc
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9210>
_______________________________________

From report at bugs.python.org  Mon Sep 13 00:00:30 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 12 Sep 2010 22:00:30 +0000
Subject: [issue1076515] shutil.move clobbers read-only files.
Message-ID: <1284328830.86.0.266144216013.issue1076515@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I haven't had time to investigate but it shouldn't be closed just yet. Someone will get to it.

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1076515>
_______________________________________

From report at bugs.python.org  Mon Sep 13 00:01:06 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Sun, 12 Sep 2010 22:01:06 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284328866.49.0.712173063766.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Thank you both for the explanations; I somehow suspected, there would be some strong reasoning for the conservative approach with regard to the backward compatibility.
Thanks for the block() and script() offer, Matthew, but I believe, this might clutter the interface of the module, while it belongs somwhere else.
(Personally, I just solved this need by directly grabbing 
http://www.unicode.org/Public/UNIDATA/Scripts.txt using regex :-)

It might be part of the problem for unicodedata, that this is another data file than UnicodeData.txt (which is the only one used, currently, IIRC).

On the other hand it might be worthwile to synchronise this features with such updates in unicodedata (block, script, unicode range; maybe the full names of the character properties might be added too).
As unicode 6.0 is about to come with the end of September, this might also reduce the efforts of upgrading it for regex.

Do you think, it would be appropriate/realistic to create a feature request in bug tracker on enhancing unicodedata?
(Unfortunately, I must confess, I am unable to contribute code in this area, without the C knowledge I always failed to find any useful data in optimised sources of unicodedata; hence I rather directly scanned the online datafiles.) 

vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Sep 13 00:02:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 12 Sep 2010 22:02:27 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1284328947.16.0.311279665471.issue2889@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Mon Sep 13 00:13:21 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Sep 2010 22:13:21 +0000
Subject: [issue9840] Recursive Repr
In-Reply-To: <1284329600.42.0.558454209322.issue9840@psf.upfronthosting.co.za>
Message-ID: <1284329600.42.0.558454209322.issue9840@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Add a recursive_repr() decorator to provide a solution to the problem of creating a container __repr__ method that doesn't fail for recursive calls.

----------
files: recursive_repr.patch
keywords: patch
messages: 116239
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Recursive Repr
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18862/recursive_repr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9840>
_______________________________________

From report at bugs.python.org  Mon Sep 13 00:19:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 22:19:03 +0000
Subject: [issue9838] Inadequate C-API to Python 3 I/O objects
In-Reply-To: <1284297827.04.0.573858766917.issue9838@psf.upfronthosting.co.za>
Message-ID: <1284329943.89.0.597848375114.issue9838@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9838>
_______________________________________

From report at bugs.python.org  Mon Sep 13 00:43:37 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 12 Sep 2010 22:43:37 +0000
Subject: [issue9210] remove --with-wctype-functions configure option
In-Reply-To: <1278666917.19.0.275398438928.issue9210@psf.upfronthosting.co.za>
Message-ID: <1284331417.3.0.441640705916.issue9210@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Applied in r84752.

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9210>
_______________________________________

From report at bugs.python.org  Mon Sep 13 00:44:05 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 12 Sep 2010 22:44:05 +0000
Subject: [issue9828] Repeated Py_Initialize and Py_Finalize usage brings fatal
	error?
In-Reply-To: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>
Message-ID: <1284331445.84.0.900187560543.issue9828@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

gildestroy.patch also works.

E:\PYTHON~1\py3k\PC\VC6>ctypes_crash.exe
--- 0 ---
[36303 refs]
--- 1 ---
[39184 refs]
--- 2 ---
[41582 refs]
--- 3 ---
[43974 refs]
--- 4 ---
[46366 refs]
--- 5 ---
[48758 refs]
--- 6 ---
[51150 refs]
--- 7 ---
[53542 refs]
--- 8 ---
[55934 refs]
--- 9 ---
[58326 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9828>
_______________________________________

From report at bugs.python.org  Mon Sep 13 00:57:18 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 12 Sep 2010 22:57:18 +0000
Subject: [issue9313] distutils error on MSVC older than 8
In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za>
Message-ID: <1284332238.19.0.139989644484.issue9313@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Fixed in r84753(py3k).

----------
assignee: tarek -> 
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9313>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:02:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:02:16 +0000
Subject: [issue8985] String format() has problems parsing numeric indexes
In-Reply-To: <1276373641.02.0.137473124387.issue8985@psf.upfronthosting.co.za>
Message-ID: <1284332536.22.0.23908912623.issue8985@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Just for the record, I said something inexact in my previous message in this thread.  New features go to the dev branch (py3k, future 3.2), bug and doc fixes go into py3k and the stable branches (2.7 and 3.1 now), and the previous stable releases (2.5 and 2.6) only get security fixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8985>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:02:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:02:56 +0000
Subject: [issue7951] Should str.format allow negative indexes when used for
	__getitem__ access?
In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za>
Message-ID: <1284332576.48.0.948830734509.issue7951@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the detailed argument, Raymond.  I?m +1 on turning this into a doc bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:06:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:06:49 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remove dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1284332809.09.0.720439835292.issue9815@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the tests should go into 2.7 and 3.1 even if they don?t have the bug.  Adding Antoine to nosy, since he?s listed for gc in Misc/maintainers.rst.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:09:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:09:28 +0000
Subject: [issue9831] test_distutils fails on MacOSX 10.6
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1284332968.18.0.807731600244.issue9831@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I noticed this bug in the tests of distutils2 and added it to my todo list some time ago.  Tests looking at pycs should take PYTHONDONTWRITEBYTECODE into account and be skipped instead of failing.  I?ll fix it.

----------
assignee: tarek -> eric.araujo
components: +Distutils2
resolution: invalid -> accepted
status: closed -> open
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:11:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:11:13 +0000
Subject: [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284333073.44.0.465616836982.issue9827@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks!

----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9827>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:11:38 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 12 Sep 2010 23:11:38 +0000
Subject: [issue9831] test_distutils fails on MacOSX 10.6
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1284333098.53.0.774255998447.issue9831@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy:  -michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:14:56 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 12 Sep 2010 23:14:56 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284333296.92.0.547732823719.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

OK, so would it be OK if there was, say, a NEW (N) flag which made the inline flags (?flags) scoped and allowed splitting on zero-width matches?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:16:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 12 Sep 2010 23:16:20 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284333380.19.0.781033267812.issue2636@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:21:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:21:04 +0000
Subject: [issue9313] distutils error on MSVC older than 8
In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za>
Message-ID: <1284333663.85.0.202610392053.issue9313@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Wouldn?t it be more accurate to skip the test instead of returning None (falsely indicating success)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9313>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:21:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:21:52 +0000
Subject: [issue9313] distutils error on MSVC older than 8
In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za>
Message-ID: <1284333712.89.0.532147984238.issue9313@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(Adding distutils2 component so that forward-porting the patch is not forgotten.)

----------
assignee:  -> tarek
components: +Distutils2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9313>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:22:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:22:14 +0000
Subject: [issue9313] distutils error on MSVC older than 8
In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za>
Message-ID: <1284333734.76.0.325564507872.issue9313@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9313>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:26:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:26:28 +0000
Subject: [issue9841] sysconfig and distutils.sysconfig differ in subtle ways
In-Reply-To: <1284333988.17.0.109581594915.issue9841@psf.upfronthosting.co.za>
Message-ID: <1284333988.17.0.109581594915.issue9841@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

With the recent distutils revert, code that was removed from distutils.sysconfig is now back.  This causes an unfortunate code duplication that raises maintenance cost (see msg116087 for an example).

Even if distutils is feature-frozen, I think that it should be changed to use the sysconfig module again.  Think about it that way: The new feature is sysconfig itself, this does not break the distutils freeze since compatibility would be retained.

----------
assignee: tarek
components: Distutils, Library (Lib)
messages: 116251
nosy: eric.araujo, tarek
priority: normal
severity: normal
status: open
title: sysconfig and distutils.sysconfig differ in subtle ways
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9841>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:34:28 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Sun, 12 Sep 2010 23:34:28 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284334468.68.0.357269745287.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Just another rather marginal findings; differences between regex and re:

>>> regex.findall(r"[\B]", "aBc")
['B']
>>> re.findall(r"[\B]", "aBc")
[]

(Python 2.7 ... on win32; regex - issue2636-20100912.zip)
I believe, regex is more correct here, as uppercase \B doesn't have a special meaning within a set (unlike backspace \b), hence it should be treated as B, but I wanted to mention it as a difference, just in case it would matter.

I also noticed another case, where regex is more permissive:

>>> regex.findall(r"[\d-h]", "ab12c-h")
['1', '2', '-', 'h']
>>> re.findall(r"[\d-h]", "ab12c-h")
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "re.pyc", line 177, in findall
  File "re.pyc", line 245, in _compile
error: bad character range
>>> 

howewer, there might be an issue in negated sets, where the negation seem to apply for the first shorthand literal only; the rest is taken positively

>>> regex.findall(r"[^\d-h]", "a^b12c-h")
['-', 'h']

cf. also a simplified pattern, where re seems to work correctly:

>>> regex.findall(r"[^\dh]", "a^b12c-h")
['h']
>>> re.findall(r"[^\dh]", "a^b12c-h")
['a', '^', 'b', 'c', '-']
>>> 

or maybe regardless the order - in presence of shorthand literals and normal characters in negated sets, these normal characters are matched positively

>>> regex.findall(r"[^h\s\db]", "a^b 12c-h")
['b', 'h']
>>> re.findall(r"[^h\s\db]", "a^b 12c-h")
['a', '^', 'c', '-']
>>> 

also related to character sets but possibly different - maybe adding a (reduntant) character also belonging to the shorthand in a negated set seem to somehow confuse the parser:

regex.findall(r"[^b\w]", "a b")
[]
re.findall(r"[^b\w]", "a b")
[' ']

regex.findall(r"[^b\S]", "a b")
[]
re.findall(r"[^b\S]", "a b")
[' ']

>>> regex.findall(r"[^8\d]", "a 1b2")
[]
>>> re.findall(r"[^8\d]", "a 1b2")
['a', ' ', 'b']
>>> 

I didn't find any relevant tracker issues, sorry if I missed some...
I initially wanted to provide test code additions, but as I am not sure about the intended output in all cases, I am leaving it in this form;

vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:36:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:36:17 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1284334577.81.0.534242713256.issue6087@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you propose a patch?  Also, can you say if the bug exists with the new sysconfig.get_path in 2.7 and 3.2?  (I can?t test right now, I ./configure with a --prefix, which logically gets used in the paths).

----------
components: +Distutils2
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:53:16 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Sep 2010 23:53:16 +0000
Subject: [issue7951] Should str.format allow negative indexes when used for
	__getitem__ access?
In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za>
Message-ID: <1284335596.04.0.662967799546.issue7951@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
components: +Documentation -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:54:28 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 12 Sep 2010 23:54:28 +0000
Subject: [issue9313] distutils error on MSVC older than 8
In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za>
Message-ID: <1284335668.27.0.858017151969.issue9313@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

How about attached patch? I confirmed this both on MSVC8 and MSVC6.

----------
assignee:  -> tarek
Added file: http://bugs.python.org/file18863/py3k_skip_in_distutils_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9313>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:55:05 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 12 Sep 2010 23:55:05 +0000
Subject: [issue9313] distutils error on MSVC older than 8
In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za>
Message-ID: <1284335705.58.0.528610708574.issue9313@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
assignee: tarek -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9313>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:56:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:56:09 +0000
Subject: [issue9181] Solaris extension building does not work with 64 bit
	python
In-Reply-To: <1278429433.49.0.398235894568.issue9181@psf.upfronthosting.co.za>
Message-ID: <1284335769.83.0.262043924048.issue9181@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the report.  Do you want to work on a patch?  The usual process is that someone makes a patch for the active version (branch named py3k, the future 3.2), then the committer backports to stable versions (3.1 and 2.7) and forward-ports to distutils2.  See also guidelines at http://www.python.org/dev/patches/

----------
nosy: +eric.araujo
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9181>
_______________________________________

From report at bugs.python.org  Mon Sep 13 02:05:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 00:05:24 +0000
Subject: [issue9842] Document ... used in recursive repr of containers
In-Reply-To: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>
Message-ID: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Built-in containers like dict use an ellipsis to represent a recursive item.  In the symbols index, ?...? only links to the secondary prompt; I think it should also link to a paragraph explaining the display of recursive containers.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 116256
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Document ... used in recursive repr of containers
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9842>
_______________________________________

From report at bugs.python.org  Mon Sep 13 02:13:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 00:13:09 +0000
Subject: [issue9840] Recursive Repr
In-Reply-To: <1284329600.42.0.558454209322.issue9840@psf.upfronthosting.co.za>
Message-ID: <1284336789.64.0.524320834744.issue9840@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Good idea.  I wonder if the genericity (being able to specify the placeholder) is needed; the ellipsis is used by built-in containers (not documented AFAICT, see #9842) and seems a good choice for most (all?) of the cases.  What bothers me is that this simple, common case can?t just use @recursive_repr (without parens) which seems to me more natural.

One markup glitch: :meth:`repr__` lacks two underscores.

(Unimportant side question:  Since collections defines __all__, why are imported names renamed with a trailing underscore?)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9840>
_______________________________________

From report at bugs.python.org  Mon Sep 13 02:19:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 00:19:56 +0000
Subject: [issue901727] extra_path kwarg to setup() undocumented
Message-ID: <1284337196.1.0.770240616927.issue901727@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This strict freeze policy has been decided by Tarek.  The less work there is on distutils? side, the less synchronization we?ll have to do in distutils2.  We do fix doc bugs, we can also fix markup or add links, but that?s it.  Improving docs is for distutils2.

Note that at first I wanted to improve distutils docs even though the code was frozen, but I now agree with Tarek that it would take up a lot of time that is better spent in distutils2.  (Regarding the options parameter, a Montreal-Python contributor added a test for it and a TODO note about lack of documentation.  See, things get better one step at a time :)

I hope this answers your question without sounding too dictatorial.  I understand your viewpoint but ultimately agree with the freeze.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue901727>
_______________________________________

From report at bugs.python.org  Mon Sep 13 02:26:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 00:26:17 +0000
Subject: [issue9313] distutils error on MSVC older than 8
In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za>
Message-ID: <1284337577.16.0.788678639599.issue9313@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks excellent, just import the function at the module scope instead of function scope (I?ve heard about import deadlock issues, and performance is not an issue in tests, so there is no reason to import in the function).

Please backport to 3.1 and 2.7 if the bug applies to them.

----------
assignee:  -> ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9313>
_______________________________________

From report at bugs.python.org  Mon Sep 13 02:49:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 00:49:14 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1284338954.09.0.311486790529.issue9561@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Toshio, I made you nosy for a question about RPM .spec files]

>> - PKG-INFO (METADATA in distutil2), that already uses a trick to support
>> Unicode, but your change would replace it in a better way;
> Which "trick"?

Some values are explicitly allowed to use Unicode and are encoded to UTF-8
when queried.

>> - MANIFEST, which with your fix would gain the ability to handle non-ASCII
>> paths, which is a feature or a bugfix depending on your point of view;
> Wait. Non encodable bytes is a separated issue. I would like to work on the
> first problem: distutils in Python3 uses open() without encoding argument and
> so the encoding depends on the user's locale. Said differently: if you produce
> a file with distutils on a computer, you cannot be sure that the file can be
> read with the same version of Python on other computer (if the locale encoding
> is different). Eg. Windows uses mbcs encoding whereas utf-8 is the preferred
> encoding on Linux.
>
> What is the encoding of the MANIFEST file?

Python?s default encoding, unfortunately.  Try listing ?napol?on? in a MANIFEST
file and you?ll get a UnicodeEncodeError because the file wants ASCII.

>> - .def files, used by the compilers for the C linking step; I don?t know if
>> it?s appropriate to allow UTF-8 there.
>
> I don't know these files.

So we?ll have to get advice from someone well-versed in C linking.

>> - RPM spec files, which use ASCII or UTF-8 according to
>> http://en.opensuse.org/openSUSE:Specfile_guidelines#Specfile_Encoding but
>> it?s not confirmed in
>> http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html (linked
>> from the LSB site), so there?s no guarantee this works for all RPM
>> platforms. This sort of platform-specific thing is the reason why RPM
>> support has been removed in distutils2.
> UTF-8 is a superset of ASCII. If you use utf-8 but only write ascii
> characters, your output file will be written to utf-8... but it will be also
> encoded to ascii. It's magical :-)

I know that, but it does not answer the question:  Is it okay for these files
to use UTF-8?

>> - record and .pth files created by the install command.
> .pth contain directory names which can be non-ASCII.

Agreed.

>> I agree that there is something to be fixed, but I don?t know if they can
>> be fixed in distutils. Unicode in PKG-INFO is unrelated to files, whereas
>> there are files or directories in MANIFEST, spec, record and .pth.
> You can use non-ASCII characters for other topics than filenames. Eg. in a
> description of a package :-)

See above: The description of a distribution is in UTF-8.  Note that I don?t
really understand my comment anymore; I now think that this should be fixed
in distutils with the least intrusive change possible.

>> If this is going to be fixed, write_file should not use UTF-8 unconditionally
>> but grow a keyword argument IMO, so that use cases requiring ASCII
>> continue to work.
> As written before, UTF-8 is a superset of ASCII. If you read a file using utf-8
> encoding, you will be able to read ascii files. But if you use utf-8 and write
> non-ascii characters, old version of distutils using ascii or other encoding
> will not be able to read these files.

That?s what I meant: Don?t make write_file always use UTF-8 since some use cases are restricted to ASCII.

> About the keyword solution: yes, it would be a smooth way to fix this issue.

Let?s do it.  (Make sys.getdefaultencoding() its default value for compat.)

>> When you say ?patch *all* functions reading files?, I guess you mean all
>> functions that read distutils files, i.e. MANIFEST and PKG-INFO.
> I don't know distutils to answer to my own question.

You patch writing files, I?ll handle reading files :)

----------
nosy: +a.badger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Mon Sep 13 02:51:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 00:51:40 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1284339100.64.0.0546594035135.issue9561@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Note that any change requires a test.

----------
assignee: tarek -> eric.araujo
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Mon Sep 13 02:55:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Sep 2010 00:55:43 +0000
Subject: [issue9842] Document ... used in recursive repr of containers
In-Reply-To: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>
Message-ID: <1284339343.24.0.957047542067.issue9842@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

... is also the Ellipsis object, and it is probably even more important that the index cross reference that usage :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9842>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:01:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 01:01:21 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1284339681.39.0.264518464642.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Victor: I would like #9841 to be solved first so that we?re sure what file(s) need to be patched (and where to add a test for parsing).

Baptiste: Can you try to reproduce your bug with 2.7 and 3.1?

Tarek: I can take this over if you want.

----------
components: +Distutils2
dependencies: +sysconfig and distutils.sysconfig differ in subtle ways

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:07:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 01:07:47 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1284340067.04.0.306613586865.issue4359@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
superseder:  -> deriving configuration information for different builds	with the same prefix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4359>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:15:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 01:15:36 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284340536.8.0.712700541397.issue9807@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agree with Barry: sysconfig is the new hotness for configuration info.

On #4359, I said that future improvements in sysconfig (http://bitbucket.org/tarek/distutils2/src/tip/docs/design/wiki.rst) will address part of the issue: It will use a configparser file to store installation directories.  There is nothing in the document about other build-time variables at the moment, but I?m +1 on any system that would remove the brittle Makefile parsing in sysconfig.  The sysconfig.cfg does not look like the best place to put this info, since it?s not editable configuration but more state.  +0 on generating a _sysconfig.c module.

I?ll have to read again the original patch and Martin?s proposal to understand the case of debug in the wider configure information picture.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:17:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 01:17:25 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284340645.81.0.0447625885687.issue9807@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A clarification: The sysconfig.cfg does not look like the best place to put this info, since [this info] is not editable configuration but more state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:19:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Sep 2010 01:19:36 +0000
Subject: [issue2118] smtplib.SMTP() raises socket.error rather than
	SMTPConnectError
In-Reply-To: <1203027793.14.0.279031432545.issue2118@psf.upfronthosting.co.za>
Message-ID: <1284340776.2.0.010191976901.issue2118@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I discussed this issue with Antoine Pitrou on #python-dev, and his opinion is that SMTPSocketConnectError doesn't add enough value to be worthwhile.  So he is in favor of making this a doc fix.

However, the suggestion also came up to have SMTPException subclass from IOError instead of Exception, since every place where an SMTPException is raised IO is involved.  This change would mean that code that didn't care what kind of IO error causes the connection to fail could trap just IOError, and code that did care could trap SMTPConnectError and IOError separately.

It is possible this would have backward compatibility issues, so the base class change is probably suitable only for 3.2, but a doc change clarifying that non-SMTP errors can be raised by connect should be backported.

----------
nosy: +giampaolo.rodola, pitrou
resolution: accepted -> 
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2118>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:22:05 2010
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 13 Sep 2010 01:22:05 +0000
Subject: [issue9843] imp documentation redundancy with acquire_lock and
	release_lock
In-Reply-To: <1284340925.23.0.318731794312.issue9843@psf.upfronthosting.co.za>
Message-ID: <1284340925.23.0.318731794312.issue9843@psf.upfronthosting.co.za>


New submission from Demur Rumed <junkmute at hotmail.com>:

http://docs.python.org/dev/library/imp.html

acquire_lock and release_lock are listed twice. The first iteration of acquire_lock repeats "On platforms without threads, this function does nothing." twice and advises release, while the latter does not

----------
assignee: docs at python
components: Documentation
messages: 116267
nosy: docs at python, serprex
priority: normal
severity: normal
status: open
title: imp documentation redundancy with acquire_lock and release_lock

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9843>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:22:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 01:22:27 +0000
Subject: [issue9716] The inittab modules cannot be packages
In-Reply-To: <1283192897.9.0.714463074092.issue9716@psf.upfronthosting.co.za>
Message-ID: <1284340947.53.0.755234855425.issue9716@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +brett.cannon, ncoghlan
type: feature request -> behavior
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9716>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:26:59 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 13 Sep 2010 01:26:59 +0000
Subject: [issue9843] imp documentation redundancy with acquire_lock and
	release_lock
In-Reply-To: <1284340925.23.0.318731794312.issue9843@psf.upfronthosting.co.za>
Message-ID: <1284341219.69.0.147508574024.issue9843@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r84754

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9843>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:31:41 2010
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 13 Sep 2010 01:31:41 +0000
Subject: [issue9843] imp documentation redundancy with acquire_lock and
	release_lock
In-Reply-To: <1284340925.23.0.318731794312.issue9843@psf.upfronthosting.co.za>
Message-ID: <1284341501.74.0.17824702833.issue9843@psf.upfronthosting.co.za>


Demur Rumed <junkmute at hotmail.com> added the comment:

That doesn't appear to remove the repetition of their listing. Something I failed to mention: The duplication occurs after imp.reload

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9843>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:32:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 01:32:02 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1284341522.14.0.181033952556.issue8796@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/issue8796>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:44:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 01:44:55 +0000
Subject: [issue9743] __call__.__call__ chain cause crash when long enough
In-Reply-To: <1283438194.03.0.720338364102.issue9743@psf.upfronthosting.co.za>
Message-ID: <1284342295.39.0.691060052463.issue9743@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?Recursively getting __call__ method from existing __call__?
I wonder what is the use case for this.

----------
nosy: +eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9743>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:54:22 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 13 Sep 2010 01:54:22 +0000
Subject: [issue7994] object.__format__ should reject format strings
In-Reply-To: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>
Message-ID: <1284342862.79.0.890629056099.issue7994@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This should be merged before 3.2 beta.

----------
nosy: +flox
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7994>
_______________________________________

From report at bugs.python.org  Mon Sep 13 04:07:51 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 13 Sep 2010 02:07:51 +0000
Subject: [issue9716] The inittab modules cannot be packages
In-Reply-To: <1283192897.9.0.714463074092.issue9716@psf.upfronthosting.co.za>
Message-ID: <1284343671.57.0.675149349094.issue9716@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.2, Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9716>
_______________________________________

From report at bugs.python.org  Mon Sep 13 05:15:47 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 13 Sep 2010 03:15:47 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1284347747.11.0.637765628667.issue9786@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I left the ifdef in for a quick and easy way to disable this code for those interested, but I'm happy to remove it if it makes for greater synergy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Mon Sep 13 05:24:29 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 13 Sep 2010 03:24:29 +0000
Subject: [issue9787] Release the TLS lock during allocations
In-Reply-To: <1283839386.17.0.522591872287.issue9787@psf.upfronthosting.co.za>
Message-ID: <1284348269.36.0.854585108754.issue9787@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

You may find this hard to believe, but we do in fact embed python into other applications.  In this case, it is UnrealEngine, to drive a complex, console based game.  Yes, embedding python is much harder than it need be and I'll submit some patches to make that easier someday, but that's not the point of this.

appMalloc, is in this case, the canonical memory allocator in UnrealEngine.  But it could be any other memory allocator so that is beside the point.

The problem at hand, however, is this memory allocator _may_ have to inquire about the state of Python.  It would do this, for example, to gather statistics about Python's memory use.  This is critically important when developing console based applications, where every Kilobyte counts.  Embedding python sometimes requires the replacement of  the standard libc malloc with something else.

What appMalloc is doing, in this case, is for every allocation, to get the python TLS pointer.  There is nothing wrong with this, this is a GIL free operation, and it will return either NULL or the current TLS.  And it works, except, when appMalloc (through python's malloc) is being invoked from the TLS entry creation mechanism itself.  Then it deadlocks.

Now, regardless of the above, surely it is an improvement in general if we make tighter use of the TLS lock.  It's not a good idea to hold this lock across malloc calls if we can avoid it.  The patch is harmless, might even be an improvement, so why object to it?  It removes yet another "gotcha" that embedders, or those replacing malloc, (or instrumenting python's malloc use) have to face.

Cheers,

K

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9787>
_______________________________________

From report at bugs.python.org  Mon Sep 13 05:26:14 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 13 Sep 2010 03:26:14 +0000
Subject: [issue9787] Release the TLS lock during allocations
In-Reply-To: <1283839386.17.0.522591872287.issue9787@psf.upfronthosting.co.za>
Message-ID: <1284348374.84.0.613374769897.issue9787@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I forgot to add:  The API that our (instrumented) malloc implementation is calling is:
PyGILState_GetThisThreadState();

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9787>
_______________________________________

From report at bugs.python.org  Mon Sep 13 05:30:15 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 13 Sep 2010 03:30:15 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1284348615.8.0.321236753306.issue9786@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Added a new patch with #ifdef remvoved, for greater harmony.

----------
Added file: http://bugs.python.org/file18864/pthread_tls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Mon Sep 13 06:24:48 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 13 Sep 2010 04:24:48 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284351888.74.0.921369104966.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100913.zip is a new version of the regex module.

I've removed the ZEROWIDTH flag and added the NEW flag, which turns on the new behaviour such as splitting on zero-width matches and positional flags. If the NEW flag isn't turned on then the inline flags are global, like in the re module.

You were right about those bugs in the regex module, Vlastimil. :-(

I've left the permissiveness of the sets in, at least for the moment, or until someone complains about it!

Incidentally:

>>> re.findall(r"[\B]", "aBc")
[]
>>> re.findall(r"[\c]", "aBc")
['c']

so it is a bug in the re module (it's putting a non-word-boundary in a set).

----------
Added file: http://bugs.python.org/file18865/issue2636-20100913.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Sep 13 07:43:59 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 13 Sep 2010 05:43:59 +0000
Subject: [issue9313] distutils error on MSVC older than 8
In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za>
Message-ID: <1284356639.63.0.191397969619.issue9313@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> I?ve heard about import deadlock issues, and performance is not an
> issue in tests, so there is no reason to import in the function

distutils.msvc9compiler imports winreg internally,
and it only exists on windows, so importing distutils.msvc9.....
compiler may raise ImportError on Linux. So I imported only when
sys.platform == "win32".

Committed in r84760(py3k). And will be merged into other branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9313>
_______________________________________

From report at bugs.python.org  Mon Sep 13 08:06:31 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 13 Sep 2010 06:06:31 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1284357991.65.0.26535019439.issue6087@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Attached is a patch for distutils/sysconfig.py.

----------
keywords: +patch
Added file: http://bugs.python.org/file18866/distutils_sysconfig.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Mon Sep 13 08:07:34 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 13 Sep 2010 06:07:34 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1284358054.91.0.410035961491.issue6087@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Attached is a patch for sysconfig.py.

----------
Added file: http://bugs.python.org/file18867/sysconfig.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Mon Sep 13 08:13:49 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 13 Sep 2010 06:13:49 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1284358429.37.0.425825512046.issue6087@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

N.B. without the sysconfig.py patch, sysconfig.get_path() fails, but differently.

With the patch, sysconfig.get_path('stdlib') and sysconfig.get_path('include') give the expected values, but _CONFIG_VARS['srcdir'] still seems wrong:

vinay at eta-jaunty:/tmp$ python3.2
Python 3.2a2+ (py3k:84759, Sep 13 2010, 05:14:55) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig._CONFIG_VARS['srcdir']
'/tmp'
>>> 

Someone please take a look!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Mon Sep 13 08:19:28 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 13 Sep 2010 06:19:28 +0000
Subject: [issue9844] calling nonexisting function under __INSURE__
In-Reply-To: <1284358768.31.0.932745075936.issue9844@psf.upfronthosting.co.za>
Message-ID: <1284358768.31.0.932745075936.issue9844@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The Py_Main function has a section under #ifdef __INSURE__ at the end, where it does:

    _Py_ReleaseInternedStrings();
    _Py_ReleaseInternedUnicodeStrings();

The first function doesn't exist in Python 3K, so there will be a compile error with __INSURE__ defined.

----------
components: Interpreter Core
messages: 116281
nosy: eli.bendersky
priority: normal
severity: normal
status: open
title: calling nonexisting function under __INSURE__
type: compile error
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9844>
_______________________________________

From report at bugs.python.org  Mon Sep 13 08:29:30 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Sep 2010 06:29:30 +0000
Subject: [issue9787] Release the TLS lock during allocations
In-Reply-To: <1284348269.36.0.854585108754.issue9787@psf.upfronthosting.co.za>
Message-ID: <4C8DC4C5.1070009@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> You may find this hard to believe, but we do in fact embed python
> into other applications.

This is actually very easy to believe.

> appMalloc, is in this case, the canonical memory allocator in
> UnrealEngine.  But it could be any other memory allocator so that is
> beside the point.

This seems to be the core of the issue. Any other memory allocator
would *not* inquire about the state of Python. Any other memory
allocator would not even be aware that it is used by Python.

> What appMalloc is doing, in this case, is for every allocation, to
> get the python TLS pointer.  There is nothing wrong with this

I find this wrong. It violates the software layering. The memory
management layer is not supposed to access upper layers (such as
the interpreter state, or the application state).

> Now, regardless of the above, surely it is an improvement in general
> if we make tighter use of the TLS lock.  It's not a good idea to hold
> this lock across malloc calls if we can avoid it.  The patch is
> harmless, might even be an improvement, so why object to it?

The code change itself is harmless, yes. The comment is not. It imposes
a requirement on Python (namely, that the malloc implementation may
be free to make calls to Python) which is harmful. The malloc
implementation just has no business looking at the thread state.

So I remain -1 on this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9787>
_______________________________________

From report at bugs.python.org  Mon Sep 13 08:46:30 2010
From: report at bugs.python.org (Alex)
Date: Mon, 13 Sep 2010 06:46:30 +0000
Subject: [issue9743] __call__.__call__ chain cause crash when long enough
In-Reply-To: <1283438194.03.0.720338364102.issue9743@psf.upfronthosting.co.za>
Message-ID: <1284360390.08.0.11984126041.issue9743@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

I doubt there is a good usecase for it, nevertheless we should attempt to fix it, as segfaults are no good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9743>
_______________________________________

From report at bugs.python.org  Mon Sep 13 08:47:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Sep 2010 06:47:29 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1284360449.24.0.597303908848.issue9786@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It seems we need to clarify the return value of PyThread_create_key. The patch returns 0 in case of failure, which is clearly wrong as 0 is also a valid key.

I think it's safe to return -1: TlsAlloc returns TLS_OUT_OF_INDEXES, which is 0xFFFFFFFF, i.e. -1 on a 32-bit system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Mon Sep 13 09:17:23 2010
From: report at bugs.python.org (Kay Hayen)
Date: Mon, 13 Sep 2010 07:17:23 +0000
Subject: [issue9716] The inittab modules cannot be packages
In-Reply-To: <1283192897.9.0.714463074092.issue9716@psf.upfronthosting.co.za>
Message-ID: <1284362243.13.0.914164673163.issue9716@psf.upfronthosting.co.za>


Kay Hayen <kayhayen at gmx.de> added the comment:

Why did you remove Python2.7 from the versions list? Isn't this supposed to track the affected versions? (This is not the first time I encountered that.)

I understand that you may not fix all bugs in 2.x, but is it already unsupported in the sense that its bugs are not tracked, then remove it from the tracker. In the alternative, please add 2.7 (and 2.6) back.

Thanks,
Kay

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9716>
_______________________________________

From report at bugs.python.org  Mon Sep 13 09:46:54 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 13 Sep 2010 07:46:54 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1284364014.22.0.756032309372.issue8796@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

We can reconsider this at some later time, when Python 2.x is not really used much anymore.

----------
resolution:  -> postponed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Mon Sep 13 09:53:06 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 13 Sep 2010 07:53:06 +0000
Subject: [issue9787] Release the TLS lock during allocations
In-Reply-To: <1283839386.17.0.522591872287.issue9787@psf.upfronthosting.co.za>
Message-ID: <1284364386.76.0.358092140132.issue9787@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

>The malloc
>implementation just has no business looking at the thread state.

Of course it does, if it you want to have any hope of instrumenting your python memory usage with detailed python runtime information.

Your statement islike saying: "A profiler has no business looking at the  thread callstack."

Note that we are not making any new requirements on python here.  Merely facilitating the process, for those implementations that _wish_ to do so (at their own risk.)

So, although you have nothing against the patch as such, you are against it on the principle that I am using it to facilitate something that you disapprove of.  I find that a quite unreasonable position.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9787>
_______________________________________

From report at bugs.python.org  Mon Sep 13 10:00:31 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 13 Sep 2010 08:00:31 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1284364831.25.0.191709368293.issue9786@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I've changed the function as you suggest, although there are in fact no failure detection semantics defined for PyThread_create_key().  See e.g. thread.c:294

/* Return a new key.  This must be called before any other functions in
 * this family, and callers must arrange to serialize calls to this
 * function.  No violations are detected.
 */
int
PyThread_create_key(void)

----------
Added file: http://bugs.python.org/file18868/pthread_tls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Mon Sep 13 10:21:01 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Sep 2010 08:21:01 +0000
Subject: [issue9787] Release the TLS lock during allocations
In-Reply-To: <1284364386.76.0.358092140132.issue9787@psf.upfronthosting.co.za>
Message-ID: <4C8DDEEA.2080701@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Note that we are not making any new requirements on python here.

But you are. So far, there was no guarantee whatsoever about the state
of Python when malloc is called. You are now introducing a requirement
that Python must be in a certain state to make it correct to call
malloc. IOW, this innocent change actually introduces a new feature.

> So, although you have nothing against the patch as such

I think it's harmless - I don't think it is a good patch.
It shouldn't matter whether or not it is applied (i.e. there is no
change to Python that I can see).

> you are against it on the principle that I am using it to 
> facilitate something that you disapprove of.
> I find that a quite unreasonable position.

No. It's not the usage that I disapprove but, but the new requirement
on Python. If you were able to do your profiling in a manner compatible
with (the current) Python, it would be certainly fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9787>
_______________________________________

From report at bugs.python.org  Mon Sep 13 10:24:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 13 Sep 2010 08:24:15 +0000
Subject: [issue7994] object.__format__ should reject format strings
In-Reply-To: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>
Message-ID: <1284366255.99.0.27667213483.issue7994@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

now the PendingDeprecationWarnings are checked in the test suite, with r84772 (for 2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7994>
_______________________________________

From report at bugs.python.org  Mon Sep 13 10:33:31 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 13 Sep 2010 08:33:31 +0000
Subject: [issue9799] Compilation error for branch py3k on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1284366811.31.0.567637548025.issue9799@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Yes, no problem; I will update the Misc/AIX-NOTES file with all the information I have been collecting recently on Python with AIX.

I will do that when I will have solved some remaining issues I have on AIX, and also when I will have checked with AIX 5.3 as well (I am currently focused on 6.1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From report at bugs.python.org  Mon Sep 13 10:35:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Sep 2010 08:35:32 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1284364831.25.0.191709368293.issue9786@psf.upfronthosting.co.za>
Message-ID: <4C8DE250.3060501@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 13.09.2010 10:00, schrieb Kristj?n Valur J?nsson:
> 
> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:
> 
> I've changed the function as you suggest, although there are in fact no failure detection semantics defined for PyThread_create_key().  

Right. That's why I'm thinking that we should introduce some. TLS
creation *can* fail, and it is unfortunate that the original
introduction of this API forgot to consider that. Your patch did
(de facto) introduce an error return code (originally 0, now -1).
So it would be good if this was documented, and the NT version adjusted.

In principle, this is really difficult to get right. AFAICT,
pthread_key_t doesn't even have to be an integral type, and even
if it is, it may well become -1. However, we can probably worry
about this when a system comes along where this implementation
breaks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Mon Sep 13 11:08:55 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 13 Sep 2010 09:08:55 +0000
Subject: [issue9779] argparse.ArgumentParser not support unicode in print help
In-Reply-To: <1283672170.42.0.322683308746.issue9779@psf.upfronthosting.co.za>
Message-ID: <1284368935.97.0.873461119411.issue9779@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Are you sure this is an argparse issue, and not a terminal issue? Here's what I see:

>>> parser = argparse.ArgumentParser(description=u'Rus ???')
>>> print(parser.description)
Rus ???
>>> sys.stderr.write(parser.description)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 4-6: ordinal not in range(128)
>>> parser.format_help()
u'usage: [-h]\n\nRus \u0420\u0443\u0441\n\noptional arguments:\n  -h, --help  show this help message and exit\n'
>>> sys.stderr.write(parser.format_help())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 17-19: ordinal not in range(128)

To me, it looks like sys.stderr doesn't like the unicode, even though at the interactive prompt I can print things okay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9779>
_______________________________________

From report at bugs.python.org  Mon Sep 13 13:18:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Sep 2010 11:18:30 +0000
Subject: [issue9716] The inittab modules cannot be packages
In-Reply-To: <1283192897.9.0.714463074092.issue9716@psf.upfronthosting.co.za>
Message-ID: <1284376710.07.0.860507819375.issue9716@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We use versions to track which versions we are going to fix, not which versions are affected (which is why we don't list any versions pre-2.5...2.5 and 2.6 occasionally get security fixes, but no earlier versions even get those).

Now, why Brett removed 2.7 is more of a mystery...

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9716>
_______________________________________

From report at bugs.python.org  Mon Sep 13 13:50:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Sep 2010 11:50:47 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an	errorfor
	unencodablefilenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284378647.15.0.27430372978.issue9820@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I fail to see why removing incorrect file names from the result
> list is any better than keeping them. The result list will 
> be incorrect either way.

It depends if you focus on displaying the content of the directory, or on processing files and directories. If you focus on display, yes, missing files an be seen as a bug. But if you walk into directories (use cases: os.walk(), replace a text pattern in all files (~os.glob), ...), and the function raises an error (because a directory or a file name is invalid) is worse. I mean the user have to rename all unencodable names, or the devfeloper have to patch its application to catch IOError and ignore the specific IOError(22).

If listdir() ignores unencodable names, os.walk() doesn't fail, but it misses some subdirectories and files.

--

Another (worse?) idea: deny bytes path for os.listdir(), but I suppose that we will not like the idea ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Mon Sep 13 14:09:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Sep 2010 12:09:44 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an	errorfor
	unencodablefilenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284379784.92.0.239937735597.issue9820@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think trying to emulate, in Python, what the *A functions 
> do is futile.

My problem is that some functions will use mbcs in strict mode (functions using PyUnicode_EncodeFSDefault): raise UnicodeEncodeError, and other will use mbcs in replace mode (functions using Windows functions in ANSI mode): raise IOError (or other error depending on the function). It's inconsistent. We should try to keep the same behaviour for all functions.

Examples of functions using (indirectly) PyUnicode_EncodeFSDefault to encode unicode filenames: bz2.BZ2File() and _ssl.SSLContext.load_cert_chain().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Mon Sep 13 14:17:15 2010
From: report at bugs.python.org (Baptiste Carvello)
Date: Mon, 13 Sep 2010 12:17:15 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1284339681.39.0.264518464642.issue6011@psf.upfronthosting.co.za>
Message-ID: <4C8E1641.9040808@free.fr>


Baptiste Carvello <baptiste13z at free.fr> added the comment:

Eric: the bug does not exist with 2.7, as the Makefile is read as bytes. 
It exists with 3.1.2.

By the way, when I say the bug is solved on 3.2, I only mean the narrow 
problem of using a
non-ascii prefix that *is* decodable with the current locale. I do not 
mean the more general
problem that arises, for example, when building with the 'C' locale, as 
is discussed in issue9561.
With a 'C' locale, the build fails also with 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Mon Sep 13 14:27:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Sep 2010 12:27:52 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an	errorfor
	unencodablefilenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284380872.09.0.044725857807.issue9820@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

After the decision to ignore undecodable file names in os.listdir but before PEP 383 there was a long discussion on python-dev (in which I was a participant) about how horrible just ignoring the undecodable filenames was.  This applies *especially* to the os.walk case, where some files would be mysteriously skipped and it wouldn't be obvious why.
Or even obvious that they'd been skipped, in some cases.  The biggest issue was that the developer would likely never see the problem since the bulk of developers don't encounter encoding issues, so it would be the poor end user who would be confronted with the mystery, with no clues as to the cause or solution.

The conclusion of that particular thread was that Guido approved adding warning messages for filenames that were undecodable, but otherwise leaving os.listdir unchanged.  Fortunately Martin came up with PEP 383, which solved the underlying problem in a better way.

So, I don't think that skipping the undecodable names is good, unless you generate a warning.  In that thread I started out advocating raising an error, but in this case as Martin points out that would be a backward compatibility issue.  Returning the munged filenames and having the error show up when the broken filename is used seems OK to me, even if imperfect.  When the user sees the problem, they report it to the developer as a bug, who hopefully changes his code to use strings.

Adding warning messages would probably be useless at best and annoying at worst on Windows.  Maybe we could add a pseudo deprecation warning (ie: aimed at developers, silent by default) that says "don't use listdir with bytes on windows"?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Mon Sep 13 14:36:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Sep 2010 12:36:09 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an	errorfor
	unencodablefilenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284381369.84.0.864414988017.issue9820@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

But in the case of BZ2File and ssl.SSLContext.load_cert_chain(), isn't it the case that they are trying to open the files?  So producing an early error about the decoding problem makes sense.  Are there any functions other than listdir where the decoded filenames are not necessarily immediately used to manipulate the files?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Mon Sep 13 15:07:16 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 13 Sep 2010 13:07:16 +0000
Subject: [issue9845] Allow changing the method in urllib.request.Request
In-Reply-To: <1284383235.98.0.831352562835.issue9845@psf.upfronthosting.co.za>
Message-ID: <1284383235.98.0.831352562835.issue9845@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Right now you have to override Request or patch its get_method() method to be able to send HTTP requests where the method is not GET or POST.

This is making some assumptions on what the users wants to do with the request. The way get_method guesses the method is good enough in most cases, but I think it would be good to let advanced developers provide their own method when they build a request.  This would avoid unnecessary boiler-plate code to be able to customize the method.

----------
assignee: orsenthil
components: Library (Lib)
files: request_custom_method.patch
keywords: patch
messages: 116301
nosy: orsenthil, tarek
priority: normal
severity: normal
status: open
title: Allow changing the method in urllib.request.Request
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file18869/request_custom_method.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9845>
_______________________________________

From report at bugs.python.org  Mon Sep 13 15:09:26 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 13 Sep 2010 13:09:26 +0000
Subject: [issue9845] Allow changing the method in urllib.request.Request
In-Reply-To: <1284383235.98.0.831352562835.issue9845@psf.upfronthosting.co.za>
Message-ID: <1284383366.54.0.368946809933.issue9845@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

sorry - Removed the assignment (the name is not followed by *)

----------
assignee: orsenthil -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9845>
_______________________________________

From report at bugs.python.org  Mon Sep 13 15:34:02 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 13 Sep 2010 13:34:02 +0000
Subject: [issue9716] The inittab modules cannot be packages
In-Reply-To: <1283192897.9.0.714463074092.issue9716@psf.upfronthosting.co.za>
Message-ID: <1284384842.04.0.236131239454.issue9716@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I assume Brett marked this 3.x only because we currently don't support builtin packages at all, so making this work crosses way over into feature request territory. That makes it unsuitable for a branch in maintenance mode (i.e. 2.7).

Added the relevant dependency regarding support for builtin packages and removed 3.2 as a target version (as per Brett's comment on the other issue - the necessary spec work hasn't even been started, so there's no way this is a chance for 3.2).

----------
dependencies: +Allow built-in packages and submodules as well as top-level modules
type: behavior -> feature request
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9716>
_______________________________________

From report at bugs.python.org  Mon Sep 13 15:46:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Sep 2010 13:46:07 +0000
Subject: [issue1475397] time.asctime_tz, time.strftime %z %C
Message-ID: <1284385567.3.0.122820128641.issue1475397@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Would issue9527 address your request?  Note that datetime.strftime already supports %z:

>>> from datetime import *
>>> datetime.now(timezone.utc).strftime('%c %z')
'Mon Sep 13 13:43:19 2010 +0000'

(I assume you meant to write %c, not %C.)

----------
assignee:  -> belopolsky
dependencies: +Add aware local time support to datetime module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475397>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:01:00 2010
From: report at bugs.python.org (Jon Anglin)
Date: Mon, 13 Sep 2010 14:01:00 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1284386460.8.0.23232725452.issue9784@psf.upfronthosting.co.za>


Changes by Jon Anglin <janglin at fortresgrand.com>:


----------
nosy: +janglin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:01:37 2010
From: report at bugs.python.org (Jon Anglin)
Date: Mon, 13 Sep 2010 14:01:37 +0000
Subject: [issue9783] _elementtree.c warnings under 64-bit Windows
In-Reply-To: <1283777393.95.0.65520363014.issue9783@psf.upfronthosting.co.za>
Message-ID: <1284386497.03.0.113809737653.issue9783@psf.upfronthosting.co.za>


Changes by Jon Anglin <janglin at fortresgrand.com>:


----------
nosy: +janglin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9783>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:01:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Sep 2010 14:01:40 +0000
Subject: [issue1076515] shutil.move clobbers read-only files.
Message-ID: <1284386500.49.0.15949359924.issue1076515@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree that this follows Unix behaviour: a read-only file is a file whose contents cannot be modified, but you can replace it with another totally different file. You can also delete it, by the way (*).

Also, even if this weren't the desired behaviour, changing it would break compatibility for existing scripts.

(*)

>>> open('b', 'w').write('b')
1
>>> os.chmod('b', 000)
>>> os.remove('b')
>>> open('b', 'r')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'b'

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1076515>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:02:08 2010
From: report at bugs.python.org (Jon Anglin)
Date: Mon, 13 Sep 2010 14:02:08 +0000
Subject: [issue9782] _multiprocessing.c warnings under 64-bit Windows
In-Reply-To: <1283776985.14.0.464453735202.issue9782@psf.upfronthosting.co.za>
Message-ID: <1284386528.55.0.0460425968919.issue9782@psf.upfronthosting.co.za>


Changes by Jon Anglin <janglin at fortresgrand.com>:


----------
nosy: +janglin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9782>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:02:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Sep 2010 14:02:20 +0000
Subject: [issue1076515] shutil.move clobbers read-only files.
Message-ID: <1284386540.35.0.612253280095.issue1076515@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: unit test needed -> 
type: behavior -> feature request
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1076515>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:05:13 2010
From: report at bugs.python.org (jan matejek)
Date: Mon, 13 Sep 2010 14:05:13 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1284386713.25.0.618808128131.issue6706@psf.upfronthosting.co.za>


Changes by jan matejek <jmatejek at suse.cz>:


----------
nosy: +matejcik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:05:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Sep 2010 14:05:20 +0000
Subject: [issue9181] Solaris extension building does not work with 64 bit
	python
In-Reply-To: <1278429433.49.0.398235894568.issue9181@psf.upfronthosting.co.za>
Message-ID: <1284386720.7.0.133881354293.issue9181@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you try using CC="cc -m64" OPT="-O3" instead?
(replace "cc" with the proper compiler name, of course)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9181>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:11:29 2010
From: report at bugs.python.org (Jon Anglin)
Date: Mon, 13 Sep 2010 14:11:29 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1284387089.65.0.31523242332.issue9566@psf.upfronthosting.co.za>


Changes by Jon Anglin <janglin at fortresgrand.com>:


----------
nosy: +janglin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:12:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Sep 2010 14:12:13 +0000
Subject: [issue9323] trace.py bug with the main file being traced
In-Reply-To: <1279722632.82.0.584454979643.issue9323@psf.upfronthosting.co.za>
Message-ID: <1284387133.56.0.955460739.issue9323@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

>  The full path *could* be easily passed, but I think we should
> address this problem from regrtest.py's side.

I disagree.  There may be other scripts that rely on __main__.__file__ being an absolute path and we cannot require everyone to change their assumptions to make their scripts traceable.

It looks like absolute path assumption was added by Florent in r78723 (r78719 in trunk).  Florent, I would like to hear from you before deciding how to proceed.  See also issue #7712.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9323>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:12:19 2010
From: report at bugs.python.org (Jon Anglin)
Date: Mon, 13 Sep 2010 14:12:19 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za>
Message-ID: <1284387139.66.0.754645673395.issue9614@psf.upfronthosting.co.za>


Changes by Jon Anglin <janglin at fortresgrand.com>:


----------
nosy: +janglin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:17:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Sep 2010 14:17:28 +0000
Subject: [issue9828] Repeated Py_Initialize and Py_Finalize usage brings fatal
	error?
In-Reply-To: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>
Message-ID: <1284387448.09.0.104463519394.issue9828@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fix committed in r84774. Thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9828>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:27:03 2010
From: report at bugs.python.org (Chris Gerhard)
Date: Mon, 13 Sep 2010 14:27:03 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1284388023.62.0.200494259563.issue4761@psf.upfronthosting.co.za>


Changes by Chris Gerhard <chris.gerhard at oracle.com>:


----------
nosy: +Chris.Gerhard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:30:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Sep 2010 14:30:40 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <4C8DE250.3060501@v.loewis.de>
Message-ID: <1284388233.3225.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Right. That's why I'm thinking that we should introduce some. TLS
> creation *can* fail, and it is unfortunate that the original
> introduction of this API forgot to consider that. Your patch did
> (de facto) introduce an error return code (originally 0, now -1).

Perhaps we can simply call Py_FatalError() instead? There's not much we
can do when such a failure occurs anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:47:05 2010
From: report at bugs.python.org (Charles Solar)
Date: Mon, 13 Sep 2010 14:47:05 +0000
Subject: [issue9181] Solaris extension building does not work with 64 bit
	python
In-Reply-To: <1278429433.49.0.398235894568.issue9181@psf.upfronthosting.co.za>
Message-ID: <1284389225.44.0.841207140442.issue9181@psf.upfronthosting.co.za>


Charles Solar <charlessolar at gmail.com> added the comment:

I just recompiled using your suggested flags and it is now properly linking my extensions.  I guess using CFLAGS and LDFLAGS was causing the problem.
Is specifying CC the recommended way to build 64 bit python?  If so when I guess this issue is not really an issue at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9181>
_______________________________________

From report at bugs.python.org  Mon Sep 13 16:57:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Sep 2010 14:57:11 +0000
Subject: [issue9181] Solaris extension building does not work with 64 bit
	python
In-Reply-To: <1278429433.49.0.398235894568.issue9181@psf.upfronthosting.co.za>
Message-ID: <1284389831.05.0.674799012725.issue9181@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is specifying CC the recommended way to build 64 bit python?

Currently, yes. LDFLAGS is supposed to work, but it doesn't (open bug: #9437).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9181>
_______________________________________

From report at bugs.python.org  Mon Sep 13 17:16:01 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 13 Sep 2010 15:16:01 +0000
Subject: [issue1538778] pyo's are not overwritten by different optimization
	levels
Message-ID: <1284390961.77.0.176193651256.issue1538778@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

How is this different than overwriting pyc files, except that there's probably less of a use case for pycs?  IOW, if we were to do something about this, it should probably be an option to ignore any existing pyc (or pyo if -O is used) files and write new ones.  It *could* be a command line switch, but honestly I think "find ... -exec rm {}" is just as good.

I'd probably prefer adding a switch to Lib/py_compile's main to remove pyo/pyc's first or some such, but I'd still be -0 on supporting this directly in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1538778>
_______________________________________

From report at bugs.python.org  Mon Sep 13 17:21:59 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 13 Sep 2010 15:21:59 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284391319.29.0.790745317766.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

My (I think fairly straightforward) idea is to just compile the useful values in Makefile and config.h into _sysconfig.c and arrange for sysconfig to import that and check it first (fallback to parsing mf and conf.h).

I'll see if I can whip up a patch for that for review and feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Mon Sep 13 17:33:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Sep 2010 15:33:06 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284391986.25.0.675058560292.issue9807@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is there any point in creating another extension module?
We already have Modules/getpath.c which receives various configuration values at compile-time, themselves exposed as sys.prefix and friends. The simpler the better, IMO.

sysconfig can choose to expose those sys values in a funkier format if it wishes to do so.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Mon Sep 13 17:33:19 2010
From: report at bugs.python.org (sorin)
Date: Mon, 13 Sep 2010 15:33:19 +0000
Subject: [issue7280] PCBuild instruction says to use nasmw.exe but it no
	longer exist
In-Reply-To: <1257625133.53.0.426769488546.issue7280@psf.upfronthosting.co.za>
Message-ID: <1284391999.3.0.00830333755432.issue7280@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

Please reopen the bug, current documentation change is not a proper solution and also it does not work (see below).

Python's openssl repository contain pregenerated mak files (/ms/*.mak), when it should not. 

If you check openssl repository you will see that these are set to be ignored. See http://cvs.openssl.org/fileview?f=openssl/ms/.cvsignore&v=1.2.4.1

OpenSSL build script are able to detect properly nasm (or nasmw) but if you put the resulted mak files on the SVN it will break the build on other systems (like ones not having `nasmw` binary).

There are several solutions for this problem:
* (fast) modify mak files to replace nasmw with nasm - this may break the build on same machines that are not using a current version of nasm, or where people renamed the file instead of making a copy or a symlink.
* (better but harder) remove the /ms/*.mak files from the repository and assure that the build system is calling the original openssl build scripts (the ones that are able to properly generate the mak files).

Initially I considered that this is bug in OpenSSL, but this is not the case: http://rt.openssl.org/index.html?q=2338

----------
nosy: +sorin
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7280>
_______________________________________

From report at bugs.python.org  Mon Sep 13 17:35:12 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 13 Sep 2010 15:35:12 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1284392112.56.0.815651674404.issue1294232@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What also worries me is the difference between the "class" statement and the type() function.

class M_A(type):
    def __new__(mcls, name, bases, ns):
       print('M_A.__new__', mcls, name, bases)
       return super().__new__(mcls, name, bases, ns)

class M_B(M_A):
    def __new__(mcls, name, bases, ns):
       print('M_B.__new__', mcls, name, bases)
       return super().__new__(mcls, name, bases, ns)

class A(metaclass=M_A): pass
class B(metaclass=M_B): pass

class C(A, B): pass
D = type('D', (A, B), {})

The construction of C and D won't print the same messages.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Mon Sep 13 17:37:07 2010
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 13 Sep 2010 15:37:07 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1284392227.01.0.266221361888.issue9561@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

>>> - RPM spec files, which use ASCII or UTF-8 according to
>>> http://en.opensuse.org/openSUSE:Specfile_guidelines#Specfile_Encoding but
>>> it?s not confirmed in
>>> http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html (linked
>>> from the LSB site)
>> UTF-8 is a superset of ASCII. If you use utf-8 but only write ascii
>> characters, your output file will be written to utf-8... but it will be also
>> encoded to ascii. It's magical :-)
>
> I know that, but it does not answer the question:  Is it okay for these files
> to use UTF-8?

rpm spec files are encoding agnostic similar to POSIX filesystems.  This causes no end of troubles for people writing python code that deals with python of course, as they cannot rely on the bytes that they are dealing with from one package to another to have the same encoding (Remember that things like dependency solvers have to compare the information from multiple packages to make their decisions).

Individual distributions will have different policies about encoding and the use of unicode in spec files to try and mitigate the problems.  For instance, Fedora specifies utf-8 in the spec files and additionally specifies that package names must be ascii.  (So if there's a package name: python-caf?, we would likely transcribe it as python-cafe when we made a package for it).

utf-8 is a good default for locales on POSIX systems so it's a good default for encoding spec files but I know there's some people out there who make their own packages that aren't utf-8.  I haven't checked but I also wouldn't be surprised if some Asian countries (where the bytes-per-character with utf-8 is high) have local distributions that use non-utf-8 encoding as well.  Whether either of these use cases needs to be catered to in distutils (when the support is going away in distutils2) I'll leave to someone else to decide.  My personal gut instinct is no but I'm not one of the people using a non-utf-8 locale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Mon Sep 13 17:44:37 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 13 Sep 2010 15:44:37 +0000
Subject: [issue9841] sysconfig and distutils.sysconfig differ in subtle ways
In-Reply-To: <1284333988.17.0.109581594915.issue9841@psf.upfronthosting.co.za>
Message-ID: <1284392677.59.0.0709828489308.issue9841@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

That's what I wanted to do first but it turned out to be a bad idea.

This duplication is unfortunate but the freeze is also to prevent third party code that patches distutils to break.

For instance, there's a lot of code out there that just patches distutils.sysconfig paths... So changing it would break them.

----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9841>
_______________________________________

From report at bugs.python.org  Mon Sep 13 17:45:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Sep 2010 15:45:08 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284392708.55.0.0310431892343.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Hmm, it looks like patches 5 and 6 lost the fix for the class name issue. I'll check if I can merge in patch 4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Mon Sep 13 17:52:30 2010
From: report at bugs.python.org (sorin)
Date: Mon, 13 Sep 2010 15:52:30 +0000
Subject: [issue9699] invalid call of Windows API _popen() generating The
	input	line is too long error message
In-Reply-To: <1282909340.45.0.225876683414.issue9699@psf.upfronthosting.co.za>
Message-ID: <1284393150.59.0.709844689449.issue9699@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

I made a small but important update to quote_command(), now it does quote the command line only under Windows because doing this under other platforms may break the command line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9699>
_______________________________________

From report at bugs.python.org  Mon Sep 13 18:05:58 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 13 Sep 2010 16:05:58 +0000
Subject: [issue9323] trace.py bug with the main file being traced
In-Reply-To: <1279722632.82.0.584454979643.issue9323@psf.upfronthosting.co.za>
Message-ID: <1284393958.99.0.903066757644.issue9323@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I've made the wrong assumption that test.regrtest.__file__ is always absolute.

Here is a patch which should fix it.

----------
nosy: +ezio.melotti
Added file: http://bugs.python.org/file18870/issue9323_regrtest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9323>
_______________________________________

From report at bugs.python.org  Mon Sep 13 18:17:21 2010
From: report at bugs.python.org (John Admanski)
Date: Mon, 13 Sep 2010 16:17:21 +0000
Subject: [issue9846] ZipExtFile provides no mechanism for closing the
	underlying file object
In-Reply-To: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>
Message-ID: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>


New submission from John Admanski <jadmanski at gmail.com>:

When creating a ZipExtFile through ZipFile.open, the if the original ZipFile object was created with a filename then a new file object will be opened and given to the ZipExtFile to use for its file operations. There is no explicit mechanism that will allow you to release this file.

ZipExtFile does have an (undocumented?) close method, but this won't actually close the file object that underlies it; probably because it has no way of knowing if it actually owns the file object or if it just has a reference to a file object that belongs to the ZipFile.

You can work around this by destroying references to the ZipExtFile and letting the file's __del__ handle the close for you but this relies on implementation details of ZipExtFile.

Found in Python 3.1 but a look at svn.python.org suggests that this problem is still there in 2.7 and 3.2; however, I haven't actually tried it with them.

----------
components: Library (Lib)
messages: 116322
nosy: john.admanski
priority: normal
severity: normal
status: open
title: ZipExtFile provides no mechanism for closing the underlying file object
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9846>
_______________________________________

From report at bugs.python.org  Mon Sep 13 18:20:13 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 13 Sep 2010 16:20:13 +0000
Subject: [issue9716] The inittab modules cannot be packages
In-Reply-To: <1283192897.9.0.714463074092.issue9716@psf.upfronthosting.co.za>
Message-ID: <1284394813.89.0.0730583556008.issue9716@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Both David and Nick are correct as to why I did what I did.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9716>
_______________________________________

From report at bugs.python.org  Mon Sep 13 18:21:43 2010
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 13 Sep 2010 16:21:43 +0000
Subject: [issue1538778] pyo's are not overwritten by different optimization
	levels
Message-ID: <1284394903.63.0.402957992099.issue1538778@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

Here's a usage where this matters.  It's a simplification of the bug report that I got that prompted me to open this.  Let's say I have the following code:

/usr/lib/python2.7/site-packages/foo.py::

    def help():
        """I'm a little docstring, short and sweet"""
        print help.__doc__

/usr/bin/bar.py::
    #!/usr/bin/python -tt
    import sys
    import foo

    if "--help" in sys.argv:
        foo.help()
    else:
        print "if you type --help, it's me you'll meet"

The system administrator on this box comes along and runs::

    $ PYTHONOPTIMIZE=2 bar.py
    if you type --help, it's me you'll meet

No problems apparent there but then, the user comes along later and runs::
    $ PYTHONOPTIMIZE=1 ./bar.py --help
    None

At this point the end user opens a bug against my software telling me that --help is broken which confuses everyone.

Not sure the best way to fix this -- ideas that pop into my head:

These solutions don't lead to a bug report as python does the right thing on its own:

* python reads and write separate pyo files for the different optimization levels (foo.pyo1 foo.pyo2)
* python autodetects whether the cached .pyo was written for the current optimization level and disregards its existence if there's a mismatch (leading to rewriting if the user has permissions, otherwise, recompilation but no writing to disk).

The following solution leads to a bug report but can be diagnosed with just the bug reporter.  Note that PYTHONOPTIMIZE= /usr/bin/bar.py is almost as good in this situation:

* python has a commandline switch to disregard current .pyo files.

These solutions lead to a bug report but can be diagnosed with the cooperation of the system administrator in addition to the bug reporter:

* Command line switch that overwrites the .pyo files
* rm -rf *.pyo

----------
nosy: +a.badger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1538778>
_______________________________________

From report at bugs.python.org  Mon Sep 13 18:23:02 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 13 Sep 2010 16:23:02 +0000
Subject: [issue1538778] pyo's are not overwritten by different optimization
	levels
Message-ID: <1284394982.34.0.947265607538.issue1538778@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

compileall module supports -f (force) option, so you can use:
python3.2 -O -m compileall -f ${files}

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1538778>
_______________________________________

From report at bugs.python.org  Mon Sep 13 18:42:50 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 13 Sep 2010 16:42:50 +0000
Subject: [issue1538778] pyo's are not overwritten by different optimization
	levels
Message-ID: <1284396170.39.0.839013808005.issue1538778@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Uh, duh.  Thanks for reminding me about that Arfrever! :)  That should be everything Toshio needs I think.  Plus this request is 4 years old.

Closing as won't fix.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1538778>
_______________________________________

From report at bugs.python.org  Mon Sep 13 18:46:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Sep 2010 16:46:25 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284396385.93.0.209441837136.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed with minor changes in r84777.

Eli, please keep lines under 80 characters.

Leaving the issue open pending py3k port.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Mon Sep 13 18:59:12 2010
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 13 Sep 2010 16:59:12 +0000
Subject: [issue1538778] pyo's are not overwritten by different optimization
	levels
Message-ID: <1284397152.01.0.574391613425.issue1538778@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

It doesn't fix the problem as it falls into the third class of solutions (one that requires cooperation by the system administrator to diagnose and fix).

OTOH, at this point in time I'm putting all of my packages in system packages where the .pyos are pregenerated correctly so I personally won't be getting new bug reports on this problem so I personally don't need to see this fixed anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1538778>
_______________________________________

From report at bugs.python.org  Mon Sep 13 19:02:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Sep 2010 17:02:20 +0000
Subject: [issue9846] ZipExtFile provides no mechanism for closing the
	underlying file object
In-Reply-To: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>
Message-ID: <1284397340.92.0.625667353428.issue9846@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed. However, the ZipFile itself knows whether to close the file (self._filePassed). By adding a constructor argument to ZipExtFile and a __del__ method, it would solve the issue.

----------
nosy: +pitrou
stage:  -> needs patch
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9846>
_______________________________________

From report at bugs.python.org  Mon Sep 13 19:03:25 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 13 Sep 2010 17:03:25 +0000
Subject: [issue1397474] timeit execution enviroment
Message-ID: <1284397405.85.0.215437049635.issue1397474@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/issue1397474>
_______________________________________

From report at bugs.python.org  Mon Sep 13 19:23:51 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 13 Sep 2010 17:23:51 +0000
Subject: [issue1397474] timeit execution enviroment
Message-ID: <1284398631.92.0.455482343294.issue1397474@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Terry,

I'm attaching a patch for 2.7, however it's more proof-of-concept than final, because I have a few comments. The patch generally implements your documentation suggestion without the `import *` warning and without adding the final example. The latter for a couple of reasons:

1) My tests show that passing the callable instead of the string 'test()' actually takes longer to run.

2) When the callable is passed, the setup of importing 'test' from '__main__' is necessary, because the timed code doesn't have to lookup the 'test' symbol. If you want to leave that example in, the setup string can be ditched.

Let me know your thoughts and I will update the patch.

----------
Added file: http://bugs.python.org/file18871/issue1397474.py27.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1397474>
_______________________________________

From report at bugs.python.org  Mon Sep 13 19:31:15 2010
From: report at bugs.python.org (James Hutchison)
Date: Mon, 13 Sep 2010 17:31:15 +0000
Subject: [issue9847] Binary strings never compare equal to raw/normal strings
In-Reply-To: <1284399075.73.0.514162795967.issue9847@psf.upfronthosting.co.za>
Message-ID: <1284399075.73.0.514162795967.issue9847@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

Tested on Python 3.1.2 Windows XP 32-bit

Binary strings (such as what is returned by filereader.readline()) are never equal to raw or normal strings, even when both strings are empty

if(b"" == ""):
    print("Strings are equal");
    else:
        if(b"" == r""):
            print("raw and binary equal, normal isn't");
        else:
            print("they aren't equal");

output: they aren't equal

----------
components: Interpreter Core
messages: 116331
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: Binary strings never compare equal to raw/normal strings
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9847>
_______________________________________

From report at bugs.python.org  Mon Sep 13 19:34:54 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 13 Sep 2010 17:34:54 +0000
Subject: [issue9844] calling nonexisting function under __INSURE__
In-Reply-To: <1284358768.31.0.932745075936.issue9844@psf.upfronthosting.co.za>
Message-ID: <1284399294.82.0.096442568244.issue9844@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Barry, I've taken the liberty to add you to the nosy list because I found in the logs you've originally added this code (in 2001!!)

I hope it's OK with you :-)

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9844>
_______________________________________

From report at bugs.python.org  Mon Sep 13 19:40:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 13 Sep 2010 17:40:37 +0000
Subject: [issue9323] trace.py bug with the main file being traced
In-Reply-To: <1279722632.82.0.584454979643.issue9323@psf.upfronthosting.co.za>
Message-ID: <1284399637.23.0.389374460528.issue9323@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

regrtest fixed with r84776 (3.x) and r84779 (2.7)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9323>
_______________________________________

From report at bugs.python.org  Mon Sep 13 19:41:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Sep 2010 17:41:52 +0000
Subject: [issue9323] trace.py bug with the main file being traced
In-Reply-To: <1279722632.82.0.584454979643.issue9323@psf.upfronthosting.co.za>
Message-ID: <1284399712.22.0.6334633462.issue9323@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Thanks, Florent.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9323>
_______________________________________

From report at bugs.python.org  Mon Sep 13 19:48:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 13 Sep 2010 17:48:15 +0000
Subject: [issue9847] Binary strings never compare equal to raw/normal strings
In-Reply-To: <1284399075.73.0.514162795967.issue9847@psf.upfronthosting.co.za>
Message-ID: <1284400095.11.0.178853807163.issue9847@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This is by design in Python 3

http://docs.python.org/py3k/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit

----------
nosy: +flox
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9847>
_______________________________________

From report at bugs.python.org  Mon Sep 13 20:00:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Sep 2010 18:00:20 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284400820.83.0.846942419259.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Eli, while porting your tests to py3k, I had to change expected output for list comprehension testing.  This is not really surprising because 3.x comprehensions differ from 2.x (they don't leak the loop variable anymore).

The difference between versions is most pronounced if a comprehension is spread in several lines:


l = [i for
     i in
     range(10)]

The coverage of the above code in 2.x is

    1: l = [i for
            i in
   11:      range(10)]

but in 3.x, I get

   12: l = [i for
   10:      i in
    1:      range(10)]

Not surprisingly, 3.x coverage output for generators is the same as for comprehensions:

   12: l = list(i for
   10:          i in
    1:          range(10))

but in 2.x,

   12: l = list(i for
                i in
    1:          range(10))

In any case, I think the counts from the second and third line (10 and 1) are probably correct in 3.x, but I cannot explain 12 in the first line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Mon Sep 13 20:12:22 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 13 Sep 2010 18:12:22 +0000
Subject: [issue1538778] pyo's are not overwritten by different optimization
	levels
Message-ID: <1284401542.71.0.921706732546.issue1538778@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks Toshio, I get it now.  I think pre-generating the proper pyo's is probably the best solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1538778>
_______________________________________

From report at bugs.python.org  Mon Sep 13 20:41:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Sep 2010 18:41:55 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284403315.22.0.641715687206.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in:

py3k: r84780
release31-maint: r84783
release27-maint: r84777

Need a separate issue for the problem highlighted in msg116336.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Mon Sep 13 20:48:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Sep 2010 18:48:30 +0000
Subject: [issue665761] reduce() masks exception
Message-ID: <1284403710.43.0.452966128017.issue665761@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Since noone have spoken in favor of 2.7 backport, I am closing this issue as committed to py3k.

----------
keywords:  -needs review
resolution:  -> accepted
stage: patch review -> committed/rejected
status: pending -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue665761>
_______________________________________

From report at bugs.python.org  Mon Sep 13 21:11:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Sep 2010 19:11:28 +0000
Subject: [issue9820] Windows : os.listdir(b'.') doesn't raise an	errorfor
	unencodablefilenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284405088.95.0.286117129874.issue9820@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

- ignore unencodable filenames is not a good idea
- raise an error on unencodable filenames breaks backward compatibility
- I don't think that emit a warning will change anything

Even if I don't like mbcs+replace (current behaviour of os.listdir(bytes)), I now agree that it is the less worst solution. I close this issue as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Mon Sep 13 21:13:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 13 Sep 2010 19:13:02 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284405182.88.0.237546774162.issue9315@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

You probably missed Lib/test/tracedmodules/ in r84780 ;)

----------
keywords: +buildbot
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Mon Sep 13 21:27:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Sep 2010 19:27:26 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1284406046.67.0.642161343145.issue9360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch, but it's a work in progress.

Since we are breaking compatibility anyway, I think a larger cleanup is deserved. For example:
- remove old exception aliases
- make return types consistent (for example, newgroups() should returned structured data as list() does)
- use datetime.datetime objects instead of consuming and producing dates and times as 6-character strings

Additional useful features could be added:

- automatic querying of CAPABILITIES on connection
- a higher-level over() method able to parse the response as a list of header dicts (using LIST OVERVIEW.FMT), with appropriately decoded values (thanks email.header.decode_header())
- ...

Also, we should add an internal mock NNTP server to easily test features. Relying on gmane is nice for simple basic tests, but not much more.

Does it sound reasonable?

----------
stage: patch review -> 
Added file: http://bugs.python.org/file18872/nntplib_cleanup2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Mon Sep 13 21:31:48 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 13 Sep 2010 19:31:48 +0000
Subject: [issue9848] setup.py contains needless references to built-in
	_weakref module
In-Reply-To: <1284406307.9.0.78586268452.issue9848@psf.upfronthosting.co.za>
Message-ID: <1284406307.9.0.78586268452.issue9848@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

_weakref module is a built-in module in Python 3 since r58602, but references to _weakref module in setup.py haven't been removed. They can be removed in py3k and 3.1 branches.

setup.py in 2.7 branch (since r84233) contains unused, commented out reference to _weakref module, which also can be removed.

----------
components: Build
messages: 116343
nosy: Arfrever, georg.brandl
priority: normal
severity: normal
status: open
title: setup.py contains needless references to built-in _weakref module
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9848>
_______________________________________

From report at bugs.python.org  Mon Sep 13 21:32:25 2010
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 13 Sep 2010 19:32:25 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1284406345.01.0.530243408552.issue6706@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santa.ant at me.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Mon Sep 13 21:38:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Sep 2010 19:38:00 +0000
Subject: [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1284406680.29.0.770071846012.issue9802@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Of course, there are subtle implications of how it will be implemented

Indeed.  Ideally, as you mention, the implementation would only use __lt__ (as with sort and bisect).  I think that constraint only leaves one reasonable choice: namely, max and min for multiple args would be functionally equivalent to max_list and min_list below:

def min2(x, y):
    return y if y < x else x

def max2(x, y):
    return x if y < x else y

def min_list(xs):
    return reduce(min2, xs)

def max_list(xs):
    return reduce(max2, xs)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9802>
_______________________________________

From report at bugs.python.org  Mon Sep 13 21:42:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Sep 2010 19:42:39 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284406959.49.0.96612204451.issue767645@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file18841/test_pep277.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Mon Sep 13 22:04:49 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Sep 2010 20:04:49 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1284388233.3225.0.camel@localhost.localdomain>
Message-ID: <4C8E83DD.9040809@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Perhaps we can simply call Py_FatalError() instead? There's not much we
> can do when such a failure occurs anyway.

Sounds fine as well. Python's own usage definitely shouldn't fail. If
extension modules use this in an aggressive manner, they may actually
exhaust TLS keys (at least on Windows, where old versions had only
64 slots). Having the interpreter fail then sounds reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Mon Sep 13 22:07:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Sep 2010 20:07:29 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1284391319.29.0.790745317766.issue9807@psf.upfronthosting.co.za>
Message-ID: <4C8E847F.10509@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> My (I think fairly straightforward) idea is to just compile the
> useful values in Makefile and config.h into _sysconfig.c and arrange
> for sysconfig to import that and check it first (fallback to parsing
> mf and conf.h).

You seem to suggest that by doing so, one can actually dispose of
pyconfig.h afterwards, as all information is in the module.

This is definitely not the case: pyconfig.h continues to be required,
as an include that is literally used when compiling extension modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Mon Sep 13 22:27:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Sep 2010 20:27:02 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284409622.4.0.513456022481.issue767645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r84784 sets os.path.supports_unicode_filenames to True on Mac OS X (macpath module).

About test_supports_unicode_filenames.patch. test_unicode_listdir() is wrong: os.listdir(str) always return str (see r84701). "verify that the new file's name is equal to the name we tried" check of test_unicode_filename() is also wrong: newfile.name is always equal to fname, it doesn't depend on support_unicode_filenames. Since the test is wrong, I don't want to commit it. test_pep277 is enough to test the creation of files with unicode names.

I don't see anything else to do now, so I close this issue. Reopen it if I forgot something, or open a new issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Mon Sep 13 22:32:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Sep 2010 20:32:38 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284409958.92.0.728010079791.issue767645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I backported r84701 and r84784 to Python 2.7 (r84787).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Mon Sep 13 22:39:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Sep 2010 20:39:23 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1284410363.94.0.715061205059.issue9360@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Assuming we can break backward compatibility, it sounds fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Mon Sep 13 22:39:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Sep 2010 20:39:35 +0000
Subject: [issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284410375.78.0.996587934003.issue9819@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Mon Sep 13 22:47:13 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 13 Sep 2010 20:47:13 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1284410833.97.0.709042585793.issue9360@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/issue9360>
_______________________________________

From report at bugs.python.org  Mon Sep 13 22:51:54 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 13 Sep 2010 20:51:54 +0000
Subject: [issue7994] object.__format__ should reject format strings
In-Reply-To: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>
Message-ID: <1284411114.7.0.760792757712.issue7994@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Manually merged to py3k in r84790. I'll leave this open until I create the 3.3 issue to change it to a DeprecationWarning.

----------
keywords:  -needs review
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7994>
_______________________________________

From report at bugs.python.org  Mon Sep 13 22:56:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Sep 2010 20:56:40 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1284405182.88.0.237546774162.issue9315@psf.upfronthosting.co.za>
Message-ID: <05AA147A-D434-4436-A009-F3FE798BA227@gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

You must be right. I thought I did all the svn adds, but may have missed something. I'll take care of this tonight, but I am off the grid for the next 3-4 hours. 

On Sep 13, 2010, at 3:13 PM, Florent Xicluna <report at bugs.python.org> wrote:

> 
> Florent Xicluna <florent.xicluna at gmail.com> added the comment:
> 
> You probably missed Lib/test/tracedmodules/ in r84780 ;)
> 
> ----------
> keywords: +buildbot
> nosy: +flox
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue9315>
> _______________________________________

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Mon Sep 13 23:18:26 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 13 Sep 2010 21:18:26 +0000
Subject: [issue9213] range purports to implement the Sequence ABC,
	but is missing index and count methods
In-Reply-To: <1278702375.23.0.863463663463.issue9213@psf.upfronthosting.co.za>
Message-ID: <1284412706.52.0.169104767707.issue9213@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Committed as r84791.

Question: should this bugfix be backported to Python 3.1 and to xrange objects in Python 2.7?  Since it's a bugfix that adds new methods, it's a gray-area.  (same question applies to the closely related Issue #9212)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9213>
_______________________________________

From report at bugs.python.org  Mon Sep 13 23:37:18 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 13 Sep 2010 21:37:18 +0000
Subject: [issue9840] Recursive Repr
In-Reply-To: <1284329600.42.0.558454209322.issue9840@psf.upfronthosting.co.za>
Message-ID: <1284413838.94.0.794621041574.issue9840@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Committed in r84792.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9840>
_______________________________________

From report at bugs.python.org  Tue Sep 14 00:07:23 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Sep 2010 22:07:23 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284415643.76.0.871788838521.issue767645@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

There seems to be some confusion about the macpath.py module.  I'm not sure why it even exists in Python 3.  Note it has to do with obsolete Classic MacOS-style paths (colon-separated paths) which are available on Mac OS X only through deprecated Carbon interfaces.  I'm not even sure that those style paths do support unicode.  More importantly, the underlying Carbon interfaces that macpath.py uses were removed for Python 3.  AFAIK, virtually nothing on OS X uses these style paths anymore and, with the removal of all the old Mac Carbon support in Python 3, I don't think there is any Python module that can use these paths other than macpath.  I think this module should be marked for deprecation and removed.  There is no reason to modify it nor add a NEWS note, even for 2.7.

----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Tue Sep 14 01:25:12 2010
From: report at bugs.python.org (Jason Baker)
Date: Mon, 13 Sep 2010 23:25:12 +0000
Subject: [issue9849] Argparse needs better error handling for nargs
In-Reply-To: <1284420312.86.0.187137843637.issue9849@psf.upfronthosting.co.za>
Message-ID: <1284420312.86.0.187137843637.issue9849@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

This is referring to argparse 1.1 installed under Python 2.6.  When I was passing in an nargs flag, I figured that since '+' and '*' are valid options, I should pass in strings.  So when I tried passing in the string '1' instead of the integer 1, I got the following error:


>>> import argparse

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', nargs='1')
_StoreAction(option_strings=[], dest='foo', nargs='1', const=None, default=None, type=None, choices=None, help=None, metavar=None)

>>> parser.parse_args()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1698, in parse_args
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1730, in parse_known_args
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1935, in _parse_known_args
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1884, in consume_positionals
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 2028, in _match_arguments_partial
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 2169, in _get_nargs_pattern
TypeError: can't multiply sequence by non-int of type 'str'

Fortunately, I had just added the nargs and knew to correct that.  However, if I were to do something like read that value in from a config file and forget to coerce the value from a string to an int, I could see how this could be a giant pain to track down.

----------
components: Library (Lib)
messages: 116355
nosy: Jason.Baker
priority: normal
severity: normal
status: open
title: Argparse needs better error handling for nargs
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9849>
_______________________________________

From report at bugs.python.org  Tue Sep 14 02:03:04 2010
From: report at bugs.python.org (John Admanski)
Date: Tue, 14 Sep 2010 00:03:04 +0000
Subject: [issue9846] ZipExtFile provides no mechanism for closing the
	underlying file object
In-Reply-To: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>
Message-ID: <1284422584.65.0.993115995492.issue9846@psf.upfronthosting.co.za>


John Admanski <jadmanski at gmail.com> added the comment:

I'm not sure that's much of an improvement on the existing behavior, though; as I mentioned you can already work around it by killing all the references to the ZipExtFile and the underlying file object will get automatically closed if the ZipExtFile is the only object using it, so adding an explicit __del__ that does the same thing isn't much of an improvement.

Since ZipExtFile is supposed to be a file-like object (albeit a read-only one) it would make sense to be able to release the underlying resources the same way you normally do with a file...by closing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9846>
_______________________________________

From report at bugs.python.org  Tue Sep 14 02:29:11 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Sep 2010 00:29:11 +0000
Subject: [issue9849] Argparse needs better error handling for nargs
In-Reply-To: <1284420312.86.0.187137843637.issue9849@psf.upfronthosting.co.za>
Message-ID: <1284424151.68.0.973534763097.issue9849@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Note, argparse is not part of the Python standard library in 2.6 but the 2.7 and 3.2 versions exhibit the same behavior.

----------
assignee:  -> bethard
nosy: +bethard, ned.deily
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9849>
_______________________________________

From report at bugs.python.org  Tue Sep 14 03:12:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Sep 2010 01:12:26 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284426746.06.0.159821434626.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> You probably missed Lib/test/tracedmodules/

fixed in r84794.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Tue Sep 14 03:26:26 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 14 Sep 2010 01:26:26 +0000
Subject: [issue9810] bzip2 build sometimes fails (VS8.0)
In-Reply-To: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>
Message-ID: <1284427586.26.0.596444415109.issue9810@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I propose following solution.

* svn copy http://svn.python.org/projects/external/bzip2-1.0.5
  http://svn.python.org/projects/external/bzip2-1.0.5.0

* fix makefile in 
  http://svn.python.org/projects/external/bzip2-1.0.5

* svn copy http://svn.python.org/projects/external/bzip2-1.0.5
  http://svn.python.org/projects/external/bzip2-1.0.5.1

Or, use "nmake /nologo /f makefile.msc" instead of
        "nmake /nologo /f makefile.msc lib".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9810>
_______________________________________

From report at bugs.python.org  Tue Sep 14 04:00:34 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 14 Sep 2010 02:00:34 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remove dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1284429634.91.0.894479945493.issue9815@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I tried test_tar_pipe_open_read_error_v2.py on py3k,
I saw 3 uncollectable objects are reported. But they
are *collected* by gc.collect() without
gc.set_debug(gc.DEBUG_LEAK). (I'm not familiar to gc,
so maybe this is normal)

I didn't see uncollectable objects in release27-maint
and release31-maint.

And I replaced py3k's Lib/unittest with release31-maint's
one, the error was gone. Maybe problem is in Lib/unittest.
Actually, if I run the code in test_null_tarfile without
unittest, everything runs fine.

E:\python-dev>py3k test_tar_pipe_open_read_error_v2.py
.
----------------------------------------------------------------------
Ran 1 test in 0.050s

OK
===========================
gc: collectable <cell 00C4F968>
gc: collectable <tuple 00BF1968>
gc: collectable <function 00C53C98>
gc: collectable <tuple 00BF5C78>
gc: collectable <function 00C53CF8>
gc: collectable <tuple 00BF99A0>
gc: collectable <function 00C53D58>
gc: collectable <tuple 00C2D8C0>
gc: collectable <function 00C53DB8>
gc: collectable <tuple 00C37348>
gc: collectable <function 00C53E18>
gc: collectable <tuple 00C37460>
gc: collectable <function 00C53E78>
gc: collectable <tuple 00C37540>
gc: collectable <function 00C53ED8>
gc: collectable <function 00C53F38>
gc: collectable <type 00C73CE0>
gc: collectable <dict 00C4DD58>
gc: collectable <getset_descriptor 00C52AB8>
gc: collectable <getset_descriptor 00C52AF8>
gc: collectable <tuple 00AF7778>
gc: collectable <frame 00C28D70>
gc: collectable <method 00AE6278>
gc: collectable <frame 00C299A8>
gc: collectable <tuple 00BD4498>
gc: collectable <frame 00C29B50>
gc: collectable <frame 00C29CF8>
gc: collectable <frame 00C753A0>
gc: collectable <frame 00C75F40>
gc: collectable <tuple 00C375E8>
gc: collectable <frame 00C760E8>
gc: collectable <method 00C52B38>
gc: collectable <frame 00C766C8>
gc: collectable <_io.FileIO 00C52D38>
gc: collectable <_io.BufferedWriter 00BF0758>
gc: collectable <frame 00C78F80>
gc: collectable <tuple 00AEB9F8>
gc: collectable <_AssertRaisesContext 00C4FAF0>
gc: collectable <dict 00C554D0>
gc: collectable <frame 00C79328>
gc: collectable <TarFile 00C4FB98>
gc: collectable <frame 00C89390>
gc: collectable <dict 00C55770>
gc: collectable <list 00AEF978>
gc: collectable <frame 00C89780>
gc: collectable <frame 00C8A040>
gc: collectable <frame 00C89CC0>
gc: collectable <frame 00C89E70>
gc: collectable <traceback 00C56038>
gc: collectable <tuple 00C4F850>
gc: collectable <IOError 00C508F8>
gc: collectable <tuple 00C4FC08>
gc: collectable <ReadError 00C4CC50>
gc: collectable <method 00AE6338>
gc: collectable <tuple 00BF5150>
gc: collectable <tuple_iterator 00C4FA80>
gc: collectable <map 00C4FAB8>
gc: collectable <list 00AFAD38>
gc: uncollectable <_Stream 00C4FB28>
gc: uncollectable <dict 00C55620>
gc: uncollectable <_LowLevelFile 00C4FB60>
===========================
Traceback (most recent call last):
  File "test_tar_pipe_open_read_error_v2.py", line 25, in test_main
    unittest.main()
  File "e:\python-dev\py3k\lib\unittest\main.py", line 95, in __init__
    self.runTests()
  File "e:\python-dev\py3k\lib\unittest\main.py", line 231, in runTests
    sys.exit(not self.result.wasSuccessful())
SystemExit: False

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test_tar_pipe_open_read_error_v2.py", line 33, in <module>
    test_main()
  File "test_tar_pipe_open_read_error_v2.py", line 30, in test_main
    shutil.rmtree(TEMPDIR)
  File "e:\python-dev\py3k\lib\shutil.py", line 283, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "e:\python-dev\py3k\lib\shutil.py", line 281, in rmtree
    os.remove(fullname)
WindowsError: [Error 32] ???????????????????????????
??????: 'c:\\docume~1\\ocean\\locals~1\\temp\\__foobarbaz__\\tmp.tar'
gc: 61 uncollectable objects at shutdown:
[54634 refs]

----------
versions: +Python 3.1
Added file: http://bugs.python.org/file18873/test_tar_pipe_open_read_error_v2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Tue Sep 14 04:02:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Sep 2010 02:02:01 +0000
Subject: [issue9846] ZipExtFile provides no mechanism for closing the
	underlying file object
In-Reply-To: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>
Message-ID: <1284429721.76.0.799234836473.issue9846@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Antoine, any reason not to put the close in the ZipFileExt close method instead of a __del__ method?  (And document it, of course).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9846>
_______________________________________

From report at bugs.python.org  Tue Sep 14 05:34:17 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Tue, 14 Sep 2010 03:34:17 +0000
Subject: [issue9759] GzipFile object should raise ValueError on .read() after
	.close()
In-Reply-To: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>
Message-ID: <1284435257.28.0.226368788445.issue9759@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

Here is a patch for the py3k branch which adds a check for whether the GzipFile is closed on each call to GzipFile.read(). If the file is closed already, the method raises a ValueError if it is (with the message text copied from the corresponding fileobject's error message). I added an assertion to the test_read() method in Lib/test/test_gzip.py.

The changes will be exactly the same for the 2.7 branch.

----------
keywords: +patch
nosy: +jfinkels
Added file: http://bugs.python.org/file18874/issue9759.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9759>
_______________________________________

From report at bugs.python.org  Tue Sep 14 05:46:20 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Tue, 14 Sep 2010 03:46:20 +0000
Subject: [issue9759] GzipFile object should raise ValueError on .read() after
	.close()
In-Reply-To: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>
Message-ID: <1284435980.29.0.836546402028.issue9759@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

Here's the 2.7 branch patch.

----------
Added file: http://bugs.python.org/file18875/issue9759.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9759>
_______________________________________

From report at bugs.python.org  Tue Sep 14 06:35:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 14 Sep 2010 04:35:06 +0000
Subject: [issue9810] bzip2 build sometimes fails (VS8.0)
In-Reply-To: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>
Message-ID: <1284438906.67.0.31774607295.issue9810@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Another solution would be not to make clean, but del *.obj.

However, I would prefer if we stopped using makefile.msc altogether,
and explicitly included the source files of bzip2 into bz2.vcproj, similar to the way _bsddb is built (in 2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9810>
_______________________________________

From report at bugs.python.org  Tue Sep 14 07:14:13 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Sep 2010 05:14:13 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
	removed
In-Reply-To: <1284441253.52.0.765024184015.issue9850@psf.upfronthosting.co.za>
Message-ID: <1284441253.52.0.765024184015.issue9850@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

The macpath module in the standard library purports to supply "the Mac OS 9 (and earlier) implementation of the os.path module.  It can be used to manipulate old-style Macintosh pathnames on Mac OS X (or any other platform).  The following functions are available in this module: normcase(), normpath(), isabs(), join(), split(), isdir(), isfile(), walk(), exists(). For other functions available in os.path dummy counterparts are available."

Old-style Mac pathnames are not further documented - in fact, the above quote is the entire external documentation for the module - but they are ones using colon separators, like ("MacHD:Users:nad:macpath_test:file"). These style path names were initially supported on Mac OS X by compatibility APIs for programs ported from classic Mac OS but those interfaces have long been deprecated in OS X and in most cases are not available in 64-bit execution mode.

Even if one did have a need to use the obsolete old-style paths, the macpath module is currently practically unusable for anything other than simple character manipulations of the path.  Nearly all of the functions that actually call OS routines are broken in one or more ways.

Those that do make file system calls are calling APIs that are expecting normal posix-style ('/' separated paths) incorrectly with old-style (":) paths (ispath, isdir, lexists, etc) which means they only give correct results in the trivial case of unqualified file or directory names, i.e. those in the working directory.

The islink() function confusingly is testing whether a path points to a Finder Alias file (not a symlink).  Unfortunately, the Carbon API used for that test does not exist in a 64-bit version and all of the Python Carbon modules were removed in Python 3.

$ arch -i386 python2.7 -c 'import macpath; print(macpath.islink("alias_to_file"))'
1
$ arch -x86_64 python2.7 -c 'import macpath; print(macpath.islink("alias_to_file"))'
False
$ python3.2 -c 'import macpath; print(macpath.islink("alias_to_file"))'
False

The underlying import errors are being masked by "try"'s:

$ arch -i386 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
$ arch -x86_64 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'ResolveAliasFile'
$ python3.1 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named Carbon.File

The realpath function is also broken in 2.7, calling Carbon.File.FSResolveAliasFile with a ":" separated path when it expects a "/" path, and is totally broken in 3.x (no Carbon modules).


While ospath *could* be repaired by proper documentation, fixing the mishmash of path types internally, and supplying C wrappers and/or alternative 64-bit APIs, it does not seem worth the effort as these style paths are seldom encountered in modern code.  Considering how broken the module currently is and given that it probably was simply overlooked in the Python 2 to 3 transition, I think a case could be made for immediate removal prior to Python 3.2 release and even for a 3.1.x maintenance release.  Short of that, it should be cleared documented as deprecated in 3.2, 3.1, and 2.7 along with warnings about broken functionality along with added DeprecationWarnings to the module.

I can write up patches to do that depending on what the consensus is.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 116365
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: obsolete macpath module dangerously broken and should be removed
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Tue Sep 14 07:18:22 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Sep 2010 05:18:22 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284441502.44.0.659417054867.issue767645@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(I've opened Issue9850 to document the brokenness of macpath and suggest its deprecation and removal.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Tue Sep 14 07:21:49 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Sep 2010 05:21:49 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
	removed
In-Reply-To: <1284441253.52.0.765024184015.issue9850@psf.upfronthosting.co.za>
Message-ID: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The macpath module in the standard library purports to supply "the Mac OS 9 (and earlier) implementation of the os.path module.  It can be used to manipulate old-style Macintosh pathnames on Mac OS X (or any other platform).  The following functions are available in this module: normcase(), normpath(), isabs(), join(), split(), isdir(), isfile(), walk(), exists(). For other functions available in os.path dummy counterparts are available."

Old-style Mac pathnames are not further documented - in fact, the above quote is the entire external documentation for the module - but they are ones using colon separators, like ("MacHD:Users:nad:macpath_test:file"). These style path names were initially supported on Mac OS X by compatibility APIs for programs ported from classic Mac OS but those interfaces have long been deprecated in OS X and in most cases are not available in 64-bit execution mode.

Even if one did have a need to use the obsolete old-style paths, the macpath module is currently practically unusable for anything other than simple character manipulations of the path.  Nearly all of the functions that actually call OS routines are broken in one or more ways.

Those that do make file system calls are calling APIs that are expecting normal posix-style ('/' separated paths) incorrectly with old-style (":) paths (ispath, isdir, lexists, etc) which means they only give correct results in the trivial case of unqualified file or directory names, i.e. those in the working directory.

The islink() function confusingly is testing whether a path points to a Finder Alias file (not a symlink).  Unfortunately, the Carbon API used for that test does not exist in a 64-bit version and all of the Python Carbon modules were removed in Python 3.

$ arch -i386 python2.7 -c 'import macpath; print(macpath.islink("alias_to_file"))'
1
$ arch -x86_64 python2.7 -c 'import macpath; print(macpath.islink("alias_to_file"))'
False
$ python3.2 -c 'import macpath; print(macpath.islink("alias_to_file"))'
False

The underlying import errors are being masked by "try"'s:

$ arch -i386 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
$ arch -x86_64 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'ResolveAliasFile'
$ python3.2 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named Carbon.File

The realpath function is also broken in 2.7, calling Carbon.File.FSResolveAliasFile with a ":" separated path when it expects a "/" path, and is totally broken in 3.x (no Carbon modules).


While macpath *could* be repaired by proper documentation, fixing the mishmash of path types internally, and supplying C wrappers and/or alternative 64-bit APIs, it does not seem worth the effort as these style paths are seldom encountered in modern code.  Considering how broken the module currently is and given that it probably was simply overlooked in the Python 2 to 3 transition, I think a case could be made for immediate removal prior to Python 3.2 release and even for a 3.1.x maintenance release.  Short of that, it should be cleared documented as deprecated in 3.2, 3.1, and 2.7 along with warnings about broken functionality along with added DeprecationWarnings to the module.

I can write up patches to do that depending on what the consensus is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Tue Sep 14 07:21:56 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Sep 2010 05:21:56 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
	removed
In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>
Message-ID: <1284441716.81.0.423705643446.issue9850@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg116365

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Tue Sep 14 08:00:23 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 14 Sep 2010 06:00:23 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remove dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1284444023.75.0.265915241632.issue9815@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

The error went away when I commented out following line.

Lib/unittest/case.py(133)
        self.exception = exc_value.with_traceback(None)

I found this by brute force.... I noticed that
test_tar_pipe_open_read_error_v2.py starts to fail from r75241.
It stores exc_value into _AssertRaisesContext#exception.

And when the exception was re-raised like this, (_Stream#_read)

            try:
                buf = self.cmp.decompress(buf)
            except IOError:
                raise ReadError("invalid compressed data")

IOError will be set to ReadError's *__cause__* attribute.
ReadError's traceback is cleared in unittest, but IOError's
traceback is not. It contains reference to frame which contains
_AssertRaisesContext object. And ReadError will be set to
_AssertRaisesContext's *exception* attribute, cyclic reference
is made. It cannot be freed without GC.

# gc.get_referents() was really helpful.

I'll attach the test script "test_assert_raises.py" to reproduce
the error. The result should be like this.

E:\python-dev>py3k test_assert_raises.py
--------------------------
[('foo 2',), None, RuntimeError('foo 1',)]
RuntimeError('foo 1',)
[('foo 1',), <traceback object at 0x00BD2738>]
<traceback object at 0x00BD2738>
--------------------------
.
----------------------------------------------------------------------
Ran 1 test in 0.090s

OK
===========================
gc: collectable <cell 00BD0B28>
gc: collectable <tuple 00BD0B60>
gc: collectable <function 00BCFE78>
gc: collectable <tuple 00BD0AF0>
gc: collectable <function 00BCFED8>
gc: collectable <tuple 00BD0BD0>
gc: collectable <function 00BCFF38>
gc: collectable <tuple 00BD0C08>
gc: collectable <function 00BCFF98>
gc: collectable <tuple 00BD0C40>
gc: collectable <function 00BD4038>
gc: collectable <tuple 00BD0C78>
gc: collectable <function 00BD4098>
gc: collectable <tuple 00BD0CB0>
gc: collectable <function 00BD40F8>
gc: collectable <function 00BD4158>
gc: collectable <type 00C07550>
gc: collectable <dict 00B1FAB8>
gc: collectable <getset_descriptor 00BD2678>
gc: collectable <getset_descriptor 00BD26B8>
gc: collectable <tuple 00AC53F8>
gc: collectable <frame 00C08858>
gc: collectable <method 00AC43F8>
gc: collectable <frame 00C09628>
gc: collectable <tuple 00BD0038>
gc: collectable <frame 00C097D0>
gc: collectable <frame 00C09978>
gc: collectable <frame 00C0C1B8>
gc: collectable <frame 00C0CEF0>
gc: collectable <tuple 00BD0E38>
gc: collectable <frame 00C0D098>
gc: collectable <method 00AC43B8>
gc: collectable <frame 00C0D810>
gc: collectable <_AssertRaisesContext 00BD0F18>
gc: collectable <frame 00C0DF18>
gc: collectable <tuple 00BD0EA8>
gc: collectable <RuntimeError 00B9FC50>
gc: collectable <traceback 00BD2738>
gc: collectable <tuple 00BD0F50>
gc: collectable <ValueError 00B9FC98>
gc: collectable <dict 00B22818>
gc: collectable <method 00AC4338>
gc: collectable <tuple 00BD0B98>
gc: collectable <tuple_iterator 00BD0E70>
gc: collectable <map 00BD0EE0>
gc: collectable <list 00B21938>
===========================
gc: 46 uncollectable objects at shutdown:
[45415 refs]

----------
Added file: http://bugs.python.org/file18876/test_assert_raises.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Tue Sep 14 08:06:52 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 14 Sep 2010 06:06:52 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remove dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1284444412.23.0.41765351459.issue9815@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is the patch to fix this issue. (Please forget first patch)

E:\python-dev>py3k -m test.regrtest test_tarfile
[1/1] test_tarfile
1 test OK.
[85902 refs]

E:\python-dev>py3k test_assert_raises.py
--------------------------
[('foo 2',), None, RuntimeError('foo 1',)]
RuntimeError('foo 1',)
[('foo 1',), None]
None
--------------------------
.
----------------------------------------------------------------------
Ran 1 test in 0.050s

OK
===========================
gc: collectable <cell 00C824D0>
gc: collectable <tuple 00C82508>
gc: collectable <function 00C80E18>
gc: collectable <tuple 00C82498>
gc: collectable <function 00C80E78>
gc: collectable <tuple 00C82578>
gc: collectable <function 00C80ED8>
gc: collectable <tuple 00C825B0>
gc: collectable <function 00C80F38>
gc: collectable <tuple 00C825E8>
gc: collectable <function 00C80F98>
gc: collectable <tuple 00C82620>
gc: collectable <function 00C85038>
gc: collectable <tuple 00C82658>
gc: collectable <function 00C85098>
gc: collectable <function 00C850F8>
gc: collectable <type 00B78010>
gc: collectable <dict 00B31578>
gc: collectable <getset_descriptor 00C7CD78>
gc: collectable <getset_descriptor 00C7CDB8>
gc: collectable <tuple 00AC53F8>
===========================
gc: collectable <TextTestResult 00C827A8>
gc: collectable <_WritelnDecorator 00C82690>
gc: collectable <dict 00B316C8>
gc: collectable <dict 00B31818>
gc: collectable <list 00B1D3B8>
gc: collectable <list 00C7CC78>
gc: collectable <list 00B2B878>
gc: collectable <list 00C7CCF8>
gc: collectable <list 00B1D2B8>
gc: collectable <TestCase 00C82770>
gc: collectable <dict 00B314D0>
gc: collectable <dict 00B31770>
gc: collectable <list 00B1CF38>
gc: collectable <method 00AC4438>
gc: collectable <method 00AC45F8>
gc: collectable <method 00AC4638>
gc: collectable <method 00AC42F8>
gc: collectable <method 00AC45B8>
gc: collectable <method 00AC4538>
gc: 40 uncollectable objects at shutdown:
[45216 refs]

----------
versions:  -Python 3.1
Added file: http://bugs.python.org/file18877/py3k_fix__AssertRaisesContext.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Tue Sep 14 08:28:10 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Tue, 14 Sep 2010 06:28:10 +0000
Subject: [issue9729] Unconnected SSLSocket.{send,
	recv} raises TypeError: 'member_descriptor' object is not callable
In-Reply-To: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>
Message-ID: <1284445690.3.0.71258950108.issue9729@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

Here's a conservative fix for Python 2.7.  It replaces the attempts to call baseclass.method with direct calls to the decorated object (i.e. replace socket.meth(self, ...) with self._sock.meth(...)).

It also corrects a bunch of incorrect arguments being passed to _sock... it's pretty clear this code was not tested.  I've added a test that exercises each SSLSocket method that corresponds to a socket._delegate_method.

A nicer solution is to simply make socket.socket actually be a simple subclass of _socket.socket rather than the weird decorator it is now.  This has already happened on the py3k branch, which is why it doesn't have this bug.

----------
keywords: +patch
Added file: http://bugs.python.org/file18878/issue9729.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9729>
_______________________________________

From report at bugs.python.org  Tue Sep 14 08:29:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 14 Sep 2010 06:29:27 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284445767.53.0.533423427722.issue9315@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Note that if you add new directories under /Lib, you need to make the build system aware of them in several places (I don't remember all of them right now, one is in the Makefile).  Otherwise they don't get shipped and/or installed, and tests fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Tue Sep 14 08:30:09 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 14 Sep 2010 06:30:09 +0000
Subject: [issue9213] range purports to implement the Sequence ABC,
	but is missing index and count methods
In-Reply-To: <1278702375.23.0.863463663463.issue9213@psf.upfronthosting.co.za>
Message-ID: <1284445809.67.0.183030609447.issue9213@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I am -1 on adding new methods to builtins in bugfix releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9213>
_______________________________________

From report at bugs.python.org  Tue Sep 14 08:53:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Sep 2010 06:53:11 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1284445767.53.0.533423427722.issue9315@psf.upfronthosting.co.za>
Message-ID: <AANLkTikRNNMcL=7TtFwtjf4FCJVaC65Eg-Ku=CYgP4Li@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Tue, Sep 14, 2010 at 2:29 AM, Georg Brandl <report at bugs.python.org> wrote:
..
> Note that if you add new directories under /Lib, you need to make the build system aware of them in several
> places (I don't remember all of them right now, one is in the Makefile). ?Otherwise they don't get shipped
> and/or installed, and tests fail.

It looks like the right place is the LIBSUBDIRS variable in Makefile.
I guess I need to edit Makefile.pre.in to change it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Tue Sep 14 09:32:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 14 Sep 2010 07:32:36 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284449556.07.0.0711847805833.issue9315@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yep.  But there are other files to edit for the Windows distribution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Tue Sep 14 10:28:42 2010
From: report at bugs.python.org (hume)
Date: Tue, 14 Sep 2010 08:28:42 +0000
Subject: [issue9851] multiprocessing socket timeout will break client
In-Reply-To: <1284452922.14.0.631964759206.issue9851@psf.upfronthosting.co.za>
Message-ID: <1284452922.14.0.631964759206.issue9851@psf.upfronthosting.co.za>


New submission from hume <humeafo at gmail.com>:

when use multiprocessing managers, while use socket to communicate between server process and client process, if I used the global socket timeout feature(no matter how large the value is) the client will always say

  File "c:\python27\lib\multiprocessing\connection.py", line 149, in Client
    answer_challenge(c, authkey)
  File "c:\python27\lib\multiprocessing\connection.py", line 383, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
IOError: [Errno 10035] 

this is not reasonable, because this behaviour will make subprocess unable to use socket's timeout features globally.

Another question is line 138 in managers.py:
        # do authentication later
        self.listener = Listener(address=address, backlog=5)
        self.address = self.listener.address

backlog=5 will accept only 5 cocurrent connections, this is stupid, you'd better make this a argument that can be specified by user

----------
components: Library (Lib)
messages: 116375
nosy: hume
priority: normal
severity: normal
status: open
title: multiprocessing socket timeout will break client
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9851>
_______________________________________

From report at bugs.python.org  Tue Sep 14 10:30:30 2010
From: report at bugs.python.org (hume)
Date: Tue, 14 Sep 2010 08:30:30 +0000
Subject: [issue9851] multiprocessing socket timeout will break client
In-Reply-To: <1284452922.14.0.631964759206.issue9851@psf.upfronthosting.co.za>
Message-ID: <1284453030.73.0.632985462188.issue9851@psf.upfronthosting.co.za>


hume <humeafo at gmail.com> added the comment:

the above test is on windows

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9851>
_______________________________________

From report at bugs.python.org  Tue Sep 14 10:45:09 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 14 Sep 2010 08:45:09 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284453909.82.0.740662735032.issue9315@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It looks like lots of 3.1 buildbots are unhappy with r84783.
But the test passes on my local 3.1 checkout.


======================================================================
FAIL: test_trace_list_comprehension (test.test_trace.TestLineCounts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/test/test_trace.py", line 172, in test_trace_list_comprehension
    self.assertEqual(self.tracer.results().counts, expected)
AssertionError: 
  {('/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/test/test_trace.py', 71): 10,
   ('/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/test/test_trace.py', 74): 1,
-  ('/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/test/test_trace.py', 75): 13,
?                                                                                  ^

+  ('/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/test/test_trace.py', 75): 12,
?                                                                                  ^

   ('/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/test/test_trace.py', 76): 1}

----------------------------------------------------------------------
Ran 13 tests in 3.541s

http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%203.1/builds/1036

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Tue Sep 14 11:39:53 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 14 Sep 2010 09:39:53 +0000
Subject: [issue1633863] AIX: configure ignores $CC
Message-ID: <1284457193.81.0.686274642076.issue1633863@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

cc_r does not seems to be able to compile py3k, so it seems to be a bad idea to force it by default.

	cc_r -qlanglvl=extc89  -DNDEBUG -O -O2 -O2  -I. -IInclude -I./Include -I/home/cis/buildbot/support-buildbot/include -I/home/cis/buildbot/support-buildbot/include/ncurses -I/home/cis/buildbot/support-buildbot/include -I/home/cis/buildbot/support-buildbot/include/ncurses  -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o Modules/posixmodule.o
"./Modules/posixmodule.c", line 2580.26: 1506-046 (S) Syntax error.
"./Modules/posixmodule.c", line 2580.29: 1506-045 (S) Undeclared identifier Default.
make: 1254-004 The error code from the last command is 1.

The patch provided (configure.diff) is trivial and it only impacts AIX.
Could someone please apply it?

----------
type:  -> compile error
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633863>
_______________________________________

From report at bugs.python.org  Tue Sep 14 11:49:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 09:49:11 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remove dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1284457751.09.0.666780694038.issue9815@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You shouldn't use DEBUG_LEAK except for debugging purposes :)

As the doc mentions: ?To debug a leaking program call gc.set_debug(gc.DEBUG_LEAK). Notice that this includes gc.DEBUG_SAVEALL, causing garbage-collected objects to be saved in gc.garbage for inspection.?

It's true that the message at shutdown should be eliminated in this case, though.
Anyway, I've committed a fix in r84798.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Tue Sep 14 12:12:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 10:12:36 +0000
Subject: [issue1633863] AIX: configure ignores $CC
Message-ID: <1284459156.75.0.453774182963.issue1633863@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> cc_r does not seems to be able to compile py3k, so it seems to be a bad 
> idea to force it by default.

Python should be able to compile with any C89-compliant compiler, so it seems a good idea to open a bug for compile errors instead.
In this case, the fix is trivial, though, so I'm simply committing it (replace a C++-style comment ("// ...") with a normal "/* ... */")). Can you try again with r84799?

That said, it seems xlc (or xlc_r) enables additional C extensions compared to cc, so perhaps it's beneficial to use it anyway?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633863>
_______________________________________

From report at bugs.python.org  Tue Sep 14 12:28:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 10:28:48 +0000
Subject: [issue9729] Unconnected SSLSocket.{send,
	recv} raises TypeError: 'member_descriptor' object is not callable
In-Reply-To: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>
Message-ID: <1284460128.5.0.969199482203.issue9729@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nice, thank you. I will look at the patch and commit it if everything's fine.

> A nicer solution is to simply make socket.socket actually be a simple
> subclass of _socket.socket rather than the weird decorator it is now. 
> This has already happened on the py3k branch, which is why it doesn't
> have this bug.

Yes, but such a rearchitecting to the socket module is out of question for 2.x, which is in bugfix mode.

----------
assignee:  -> pitrou
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9729>
_______________________________________

From report at bugs.python.org  Tue Sep 14 13:10:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 11:10:12 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1284462612.91.0.163894347934.issue1926@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies: +nntplib cleanup

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Tue Sep 14 13:16:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 11:16:59 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1284463019.44.0.542841322834.issue1926@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It should be noted that there are two possibilities for encrypted NNTP:
- NNTPS, that is NNTP-over-SSL on port 563, as proposed here
- plain NNTP with the STARTTLS capability as described in RFC 4642

For the record, gmane provides the former (on snews.gmane.org:563) but not the latter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Tue Sep 14 13:18:41 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 14 Sep 2010 11:18:41 +0000
Subject: [issue9835] ZipFile unix external attributes incorrect for entry
	written with writestr
In-Reply-To: <1284207120.65.0.876260441068.issue9835@psf.upfronthosting.co.za>
Message-ID: <1284463121.22.0.275411537954.issue9835@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This has already been corrected by issue3394, and is at least present in python 2.6.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed
superseder:  -> zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9835>
_______________________________________

From report at bugs.python.org  Tue Sep 14 13:26:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 14 Sep 2010 11:26:25 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1284463585.32.0.184806750585.issue6839@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I agree with the change, but the code should be factorized in a function (normalize_filename for example)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6839>
_______________________________________

From report at bugs.python.org  Tue Sep 14 13:35:16 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 14 Sep 2010 11:35:16 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1284464116.87.0.334684675748.issue6839@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'd prefer if the code no longer checked if the filename in the directory matches the name in the per-file header.

The reason of that is that the two don't have to match: it is relatively cheap to rename a file in the zipfile by rewriting the directory while rewriting the entire zipfile can be pretty expensive when zipfiles get large.

It's probably worthwhile to test what other zipfile tools do in the respect (e.g., create a zipfile where the filename in the header doesn't match the name in the directory and extract that zip using a number of popular tools).


(I have a slightly odd perspective on this because I regularly deal with zipfiles containing over 100K files and over 10GByte of data).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6839>
_______________________________________

From report at bugs.python.org  Tue Sep 14 13:47:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Sep 2010 11:47:39 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284464859.16.0.515240292392.issue767645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> There seems to be some confusion about the macpath.py module. (...)

Oops. I thought that Mac OS X uses macpath, but in fact it is posixpath. Can you try my new patch posixpath_darwin.patch? I reopen the issue because I patched the wrong module. I suppose that Python 2.7 has the same issue: posixpath should be patched, not macpath.

My patch leaves macpath with supports_unicode_filenames=True. If I understood correctly: macpath should be removed (#9850).

----------
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file18879/posixpath_darwin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Tue Sep 14 13:53:49 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 14 Sep 2010 11:53:49 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
	removed
In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>
Message-ID: <1284465229.39.0.935913259893.issue9850@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm -0 on removing the module wholesale because parts of OSX still use MacOS9 style paths (in particular some Carbon APIs and AppleScript).

I'm +1 on removing all functions that aren't path manipulation code, that is 'macpath.join' would stay while 'macpath.islink' would go, and fixing the documentation.

And to be complete: I'm -1 on fixing macpath.islink and other functions that access a life filesystem because the macpath module is only meant to be used for that on MacOS9 and that platform is no longer supported.  Path manipulation code is still useful.

BTW. The module cannot be removed from 2.7 and 3.1 due to API stability requirements.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Tue Sep 14 13:56:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Sep 2010 11:56:21 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
	removed
In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>
Message-ID: <1284465381.64.0.527258533121.issue9850@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The solution may be different depending on Python version. I propose to keep macpath in Python 2.7, just because it's too late to change such thing in Python2. But we may mark macpath as deprecated, eg. "macpath will be removed in Python 3.2" (see above). I suppose that the same treatement can be used on Python 3.1 (maybe with a different warning type/message).

But for Python 3.2, I suggest to drop macpath. Said differently: drop Mac OS 9 support. If you really need Mac OS 9 support, continue to use Python 2.7. If I understood correctly, macpath is not used for os.path in Python 3.2, and it is broken (at least on 64 bits build).

But well, I am not a Mac programmer, so I don't know if Mac OS 9 is still commonly installed or not.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Tue Sep 14 14:00:40 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 14 Sep 2010 12:00:40 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
	removed
In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>
Message-ID: <1284465640.14.0.0327111189162.issue9850@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

MacOS9 is already unsupported, except for macpath all traces of OS9 support are gone with the possible exception of distutils (I removed traces of OS9 support code in 3.2 and those got restored when Tarek replaced distutils by the version from the 3.1 branch, I don't remember if I redid my OS9-removal work).

As I wrote earlier the path manipulation code (macpath.join, macpath.split etc.) are still useful because OS9-style paths are still used in some parts of OSX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Tue Sep 14 14:03:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Sep 2010 12:03:01 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1284465781.34.0.139733824908.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

For non-ascii directory name but ascii locale (eg. C locale), we have 3 choices:
 a- read Makefile as a binary file
 b- use the PEP 383
 c- refuse to compile

(a) doesn't seem easy because it looks like distutils use the unicode type for all paths. (b) supposes to patch distutils to ensure that reading (and writing?) Makefile uses errors='surrogateescape'.

About (c), it can be a temporary solution. But I also think that non-ascii directory name and ascii locale encoding is a rare use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Tue Sep 14 14:04:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Sep 2010 12:04:42 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1284465882.1.0.871599586782.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Warning: "use the PEP 383" may impact other distutils component because the path may be written into to other files, which mean that we have to use errors='surrogateescape' for these files too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Tue Sep 14 14:05:48 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 14 Sep 2010 12:05:48 +0000
Subject: [issue9852] test_ctypes fail with clang
In-Reply-To: <1284465948.07.0.835658917717.issue9852@psf.upfronthosting.co.za>
Message-ID: <1284465948.07.0.835658917717.issue9852@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

This is probably a clang bug but this is the only test failing with clang:


======================================================================
FAIL: test_byte (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_cfuncs.py", line 20, in test_byte
    self.assertEqual(self._dll.tf_b(-126), -42)
AssertionError: 43 != -42

======================================================================
FAIL: test_byte_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_cfuncs.py", line 26, in test_byte_plus
    self.assertEqual(self._dll.tf_bb(0, -126), -42)
AssertionError: 43 != -42

======================================================================
FAIL: test_short (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_cfuncs.py", line 44, in test_short
    self.assertEqual(self._dll.tf_h(-32766), -10922)
AssertionError: 10923 != -10922

======================================================================
FAIL: test_short_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_cfuncs.py", line 50, in test_short_plus
    self.assertEqual(self._dll.tf_bh(0, -32766), -10922)
AssertionError: 10923 != -10922

======================================================================
FAIL: test_doubleresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_functions.py", line 143, in test_doubleresult
    self.assertEqual(result, -21)
AssertionError: 65771.0 != -21

======================================================================
FAIL: test_floatresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_functions.py", line 131, in test_floatresult
    self.assertEqual(result, -21)
AssertionError: 65771.0 != -21

======================================================================
FAIL: test_intresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_functions.py", line 105, in test_intresult
    self.assertEqual(result, -21)
AssertionError: 65771 != -21

======================================================================
FAIL: test_longdoubleresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_functions.py", line 155, in test_longdoubleresult
    self.assertEqual(result, -21)
AssertionError: 65771.0 != -21

----------
assignee: theller
components: ctypes
messages: 116392
nosy: cartman, theller
priority: normal
severity: normal
status: open
title: test_ctypes fail with clang
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9852>
_______________________________________

From report at bugs.python.org  Tue Sep 14 14:14:33 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 14 Sep 2010 12:14:33 +0000
Subject: [issue1633863] AIX: configure ignores $CC
Message-ID: <1284466473.45.0.136022706067.issue1633863@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

cc(_r) and xlc(_r) refer to the same binary of the same compiler, but they change the default configuration of that compiler.

The documentation indicates:

 DESCRIPTION
         The invocation commands compile C and C++ source files.
         The commands and their recommended usages are described
         below.

         Invocations                   Usage (supported standards)
         _________________________________________________________

         xlc, xlc_r, xlc_r4,           Compile C source files.
         xlc_r7, xlc128, xlc128_r,     (ANSI C89, ISO C99,
         xlc128_r4, xlc128_r7          IBM language extensions)

         xlc++, xlc++_r, xlc++_r4,     Compile C++ source files.
         xlc++_r7, xlc++128,
         xlc++128_r, xlc++128_r4,
         xlc++128_r7, xlC, xlC_r,
         xlC_r4, xlC_r7, xlC128,
         xlC128_r, xlC128_r4,
         xlC128_r7

         cc, cc_r, cc_r4, cc_r7,       Compile legacy code that
         cc128, cc128_r, cc128_r4,     does not conform to Standard
         cc128_r7                      C. (pre-ANSI C)

         c89, c89_r, c89_r4,           Compile C source files with
         c89_r7, c89_128, c89_128_r,   strict conformance to the
         c89_128_r4, c89_128_r7        C89 standard. (ANSI C89)

         c99, c99_r, c99_r4,           Compile C source files with
         c99_r7, c99_128, c99_128_r,   strict conformance to the
         c99_128_r4, c99_128_r7        C99 standard. (ISO 99)

         xlc++core, xlc++core_r,       Compile C++ source files
         xlc++core_r7, xlc++core128,   but the compiler will
         xlc++core128_r,               link only to the core of
         xlc++core128_r7, xlCcore,     the runtime library.
         xlCcore_r, xlCcore_r7,
         xlC128core, xlC128core_r,
         xlC128core_r7

         gxlc                          Accepts GNU C options, maps
                                       them to their equivalent XL
                                       C option, then invokes xlc.

         gxlc++, gxlC                  Accepts GNU C/C++ options, maps
                                       them to their equivalent XL
                                       C++ option,then invokes xlc++.

         The main difference between these commands is that they
         use different default options (which are set in the
         configuration file /etc/vac.cfg.XX, where XX represents
         the AIX version).
         See the Compiler Reference for more information on these
         invocation commands.

         All invocations with a suffix of _r allow for thread-safe
         compilation. Use these commands to create threaded
         applications or to link programs that use multi-threading.

So xlc_r seems like the right one as the default to compile Python I would say.

I will check your last commit soon (I have buildbot nearly running on AIX, that is how I observed this problem actually).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633863>
_______________________________________

From report at bugs.python.org  Tue Sep 14 14:35:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 12:35:54 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1284467754.71.0.575674210794.issue6164@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Tue Sep 14 14:36:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 12:36:16 +0000
Subject: [issue6006] ffi.c compile failures on AIX 5.3 with xlc
In-Reply-To: <1242148314.87.0.355689567924.issue6006@psf.upfronthosting.co.za>
Message-ID: <1284467776.5.0.609665168997.issue6006@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6006>
_______________________________________

From report at bugs.python.org  Tue Sep 14 14:43:19 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Tue, 14 Sep 2010 12:43:19 +0000
Subject: [issue9729] Unconnected SSLSocket.{send,
	recv} raises TypeError: 'member_descriptor' object is not callable
In-Reply-To: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>
Message-ID: <1284468199.24.0.409708363669.issue9729@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

> Yes, but such a rearchitecting to the socket module is out of question 
> for 2.x, which is in bugfix mode.

Yes of course, which is why I made the conservative fix instead :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9729>
_______________________________________

From report at bugs.python.org  Tue Sep 14 14:45:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 12:45:17 +0000
Subject: [issue9846] ZipExtFile provides no mechanism for closing the
	underlying file object
In-Reply-To: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>
Message-ID: <1284468317.49.0.929311247144.issue9846@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, any reason not to put the close in the ZipFileExt close method 
> instead of a __del__ method?  (And document it, of course).

You are right, a close() method would be enough.
Furthermore, ZipExtFile already supports the context manager protocol (implicitly calling BufferedIOBase.close()), so you will simply be able to write:

with myzipfile.open("README", "r") as f:
    # ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9846>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:06:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 13:06:53 +0000
Subject: [issue9729] Unconnected SSLSocket.{send,
	recv} raises TypeError: 'member_descriptor' object is not callable
In-Reply-To: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>
Message-ID: <1284469613.21.0.5345573739.issue9729@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The recvfrom() signature is wrong (it doesn't take an address argument). Here is an updated patch.

----------
Added file: http://bugs.python.org/file18880/issue9729-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9729>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:07:11 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 14 Sep 2010 13:07:11 +0000
Subject: [issue7657] test_ctypes failure on AIX 5.3
In-Reply-To: <1262934153.84.0.332661974456.issue7657@psf.upfronthosting.co.za>
Message-ID: <1284469631.97.0.0482146057986.issue7657@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7657>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:07:19 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 14 Sep 2010 13:07:19 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1284469639.1.0.110332401212.issue678250@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:07:27 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 14 Sep 2010 13:07:27 +0000
Subject: [issue730467] Not detecting AIX_GENUINE_CPLUSPLUS
Message-ID: <1284469647.43.0.121833557853.issue730467@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue730467>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:07:31 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 14 Sep 2010 13:07:31 +0000
Subject: [issue713169] test_pty fails on HP-UX and AIX when run after
	test_openpty
Message-ID: <1284469651.71.0.348899682586.issue713169@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue713169>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:07:35 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 14 Sep 2010 13:07:35 +0000
Subject: [issue678264] test_resource fails when file size is limited
Message-ID: <1284469655.92.0.831779984366.issue678264@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678264>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:07:45 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 14 Sep 2010 13:07:45 +0000
Subject: [issue8882] socketmodule.c`getsockaddrarg() should not check
	the	length of sun_path
In-Reply-To: <1275528470.51.0.813873994417.issue8882@psf.upfronthosting.co.za>
Message-ID: <1284469665.7.0.226661739196.issue8882@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8882>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:08:25 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 14 Sep 2010 13:08:25 +0000
Subject: [issue5718] Problem compiling ffi part of build on AIX 5.3.
In-Reply-To: <1239117342.9.0.186105014374.issue5718@psf.upfronthosting.co.za>
Message-ID: <1284469705.63.0.0635185361834.issue5718@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5718>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:08:37 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 14 Sep 2010 13:08:37 +0000
Subject: [issue1745108] 2.5.1 curses panel segfault in new_panel on aix 5.3
Message-ID: <1284469717.84.0.904811623407.issue1745108@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745108>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:09:10 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 14 Sep 2010 13:09:10 +0000
Subject: [issue1563807] _ctypes built with GCC on AIX 5.3 fails with ld ffi
	error
Message-ID: <1284469750.18.0.300389177599.issue1563807@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563807>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:09:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 13:09:43 +0000
Subject: [issue9853] Wrong signature for SSLSocket.recvfrom
In-Reply-To: <1284469783.13.0.12192351164.issue9853@psf.upfronthosting.co.za>
Message-ID: <1284469783.13.0.12192351164.issue9853@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

SSLSocket.recvfrom includes an `addr` argument in its signature, but socket.recvfrom doesn't take such an argument. It should be removed.
(obviously, this method is neither tested nor used in the real-world...)

In 2.7, this is taken care of by the patch in issue9729.

----------
messages: 116397
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Wrong signature for SSLSocket.recvfrom
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9853>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:36:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 13:36:16 +0000
Subject: [issue9729] Unconnected SSLSocket.{send,
	recv} raises TypeError: 'member_descriptor' object is not callable
In-Reply-To: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>
Message-ID: <1284471376.66.0.213717890729.issue9729@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

sendto() has a similar problem. socket.sendto() takes (data, flags=0, addr), but SSLSocket.sendto() incorrectly forwards the arguments. Updated patch attached.

----------
Added file: http://bugs.python.org/file18881/issue9729-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9729>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:39:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 13:39:15 +0000
Subject: [issue9853] Wrong signature for SSLSocket.recvfrom and
	SSLSocket.sendto
In-Reply-To: <1284469783.13.0.12192351164.issue9853@psf.upfronthosting.co.za>
Message-ID: <1284471555.24.0.237605284454.issue9853@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Similar problem for sendto() (again, see issue9729).
socket.sendto() has an interesting signature (the middle `flags` argument is optional, not the following `addr`...).

----------
title: Wrong signature for SSLSocket.recvfrom -> Wrong signature for SSLSocket.recvfrom and SSLSocket.sendto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9853>
_______________________________________

From report at bugs.python.org  Tue Sep 14 16:08:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 14:08:37 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1284473317.3.0.87705354046.issue9360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a further, still work-in-progress, patch. I'm posting it here so that interested people can give advice.

----------
Added file: http://bugs.python.org/file18882/nntplib_cleanup3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Tue Sep 14 16:25:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Sep 2010 14:25:34 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284474334.73.0.47834215473.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Updated Makefile in r84803 - r84805.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Tue Sep 14 16:32:09 2010
From: report at bugs.python.org (Andy Buckley)
Date: Tue, 14 Sep 2010 14:32:09 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1284474729.63.0.86612927413.issue2292@psf.upfronthosting.co.za>


Changes by Andy Buckley <andy at insectnation.org>:


----------
nosy: +andybuckley

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Tue Sep 14 16:37:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 14:37:55 +0000
Subject: [issue9729] Unconnected SSLSocket.{send,
	recv} raises TypeError: 'member_descriptor' object is not callable
In-Reply-To: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>
Message-ID: <1284475075.3.0.0234765987262.issue9729@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r84806.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9729>
_______________________________________

From report at bugs.python.org  Tue Sep 14 16:47:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 14:47:45 +0000
Subject: [issue9853] Wrong signature for SSLSocket.recvfrom and
	SSLSocket.sendto
In-Reply-To: <1284469783.13.0.12192351164.issue9853@psf.upfronthosting.co.za>
Message-ID: <1284475665.21.0.763096234453.issue9853@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r84807 (3.x) and r84809 (3.1).

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9853>
_______________________________________

From report at bugs.python.org  Tue Sep 14 17:33:51 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Sep 2010 15:33:51 +0000
Subject: [issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284478431.43.0.573478359905.issue9728@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Where does/did the FAQ live in the version control tree?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9728>
_______________________________________

From report at bugs.python.org  Tue Sep 14 17:34:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 15:34:15 +0000
Subject: [issue1552] fromfd() and socketpair() should return wrapped sockets
In-Reply-To: <1196739495.6.0.25894007336.issue1552@psf.upfronthosting.co.za>
Message-ID: <1284478455.91.0.746259000904.issue1552@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1552>
_______________________________________

From report at bugs.python.org  Tue Sep 14 17:47:43 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Sep 2010 15:47:43 +0000
Subject: [issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284479263.71.0.267790156676.issue9728@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

It looks like the FAQ used be generated using Tools/faqwiz/faqwiz.py (which no longer exists).  According to that file:

-----------------------------------------------------------------------
This is a CGI program that maintains a user-editable FAQ.  It uses RCS
to keep track of changes to individual FAQ entries.  It is fully
configurable; everything you might want to change when using this
program to maintain some other FAQ than the Python FAQ is contained in
the configuration module, faqconf.py.
-----------------------------------------------------------------------

In other words, while the FAQ was under version control, it wasn't the regular repository.

I'll ask on python-dev is anyone has a copy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9728>
_______________________________________

From report at bugs.python.org  Tue Sep 14 17:49:15 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Sep 2010 15:49:15 +0000
Subject: [issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284479355.75.0.827651027353.issue9728@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Nevermind... archive.org has it. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9728>
_______________________________________

From report at bugs.python.org  Tue Sep 14 18:11:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Sep 2010 16:11:09 +0000
Subject: [issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284480669.44.0.584703081936.issue9728@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Fixed in r84810, r84811, and 84812.

For anyone curious, the old FAQ entry is here:
http://web.archive.org/web/20010203161100/http://www.python.org/doc/FAQ.html#3.24

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9728>
_______________________________________

From report at bugs.python.org  Tue Sep 14 18:20:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 16:20:12 +0000
Subject: [issue9854] SocketIO should return None on EWOULDBLOCK
In-Reply-To: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>
Message-ID: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

SocketIO claims to implement RawIOBase, but it lets blocking IO errors pass through on non-blocking sockets:

>>> s = socket.create_connection(("python.org", 80)); s.settimeout(0.0)
>>> f = s.makefile("rb", buffering=0)
>>> f.readinto(bytearray(10))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/nntp-9360/Lib/socket.py", line 228, in readinto
    return self._sock.recv_into(b)
socket.error: [Errno 11] Resource temporarily unavailable

Instead, readinto() should detect the blocking condition (EAGAIN / EWOULDBLOCK) and return None (same for write(), I imagine).

There also seems to be a problem in the default read() implementation in RawIOBase, which doesn't accept a possible None result from readinto():

>>> f.readinto = lambda x: None
>>> f.read(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object cannot be interpreted as an integer

(the RawIOBase docs themselves don't mention that readinto() can return None, but it's the only logical possibility: catching EWOULDBLOCK in read() but not in readinto() wouldn't make sense)

----------
components: IO, Library (Lib)
messages: 116408
nosy: amaury.forgeotdarc, benjamin.peterson, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: SocketIO should return None on EWOULDBLOCK
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9854>
_______________________________________

From report at bugs.python.org  Tue Sep 14 18:50:23 2010
From: report at bugs.python.org (Tom)
Date: Tue, 14 Sep 2010 16:50:23 +0000
Subject: [issue9855] Complex number slicing neither works nor causes an error
	on immediate use
In-Reply-To: <1284483023.7.0.0398180886345.issue9855@psf.upfronthosting.co.za>
Message-ID: <1284483023.7.0.0398180886345.issue9855@psf.upfronthosting.co.za>


New submission from Tom <tom at littlemonster.co.uk>:

I hope the title of this makes sense. I've been out of things for a long time.

Going through the Python tutorial (http://docs.python.org/tutorial/introduction.html) I departed from the script to try something. It gave neither of the results I had thought it might.

    >>> (0+1j)*(0+1j).imag
    1j
    >>> (0+1j)*(0+1j).real
    0j
    >>> a=(0+1j)*(0+1j)
    >>> a.imag
    0.0
    >>> a.real
    -1.0
    >>> 

This being my first crack at this language, I may have missed something that is obvious to the more experienced.

In my naivety, I thought that slicing the result of a calculation should work - why not? It should have the same structure as that pointed to by a variable.

So I'll leave this for either somebody with the patience to put me straight or somebody to fix.

Cheers!

----------
messages: 116409
nosy: LittleMonster
priority: normal
severity: normal
status: open
title: Complex number slicing neither works nor causes an error on immediate use
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9855>
_______________________________________

From report at bugs.python.org  Tue Sep 14 18:54:07 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Sep 2010 16:54:07 +0000
Subject: [issue9213] range purports to implement the Sequence ABC,
	but is missing index and count methods
In-Reply-To: <1278702375.23.0.863463663463.issue9213@psf.upfronthosting.co.za>
Message-ID: <1284483247.32.0.455416183262.issue9213@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Sounds reasonable to me.  I'll close this and the related 9212 (both fixes are already committed to the py3k branch).

----------
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9213>
_______________________________________

From report at bugs.python.org  Tue Sep 14 18:54:23 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Sep 2010 16:54:23 +0000
Subject: [issue9212] dict_keys purports to implement the Set ABC,
	but is missing the isdisjoint method
In-Reply-To: <1278702217.69.0.69895367614.issue9212@psf.upfronthosting.co.za>
Message-ID: <1284483263.91.0.483952667009.issue9212@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9212>
_______________________________________

From report at bugs.python.org  Tue Sep 14 18:58:08 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 14 Sep 2010 16:58:08 +0000
Subject: [issue9855] Complex number slicing neither works nor causes an error
	on immediate use
In-Reply-To: <1284483023.7.0.0398180886345.issue9855@psf.upfronthosting.co.za>
Message-ID: <1284483488.19.0.742006644099.issue9855@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The precedence doesn't work the way you think it does. Your example with the intermediate variable is the same as:

>>> ((0+1j)*(0+1j)).imag
0.0
>>> ((0+1j)*(0+1j)).real
-1.0

Note the extra level of parens so that .imag and .real are applied to the result of the multiplication.

----------
nosy: +eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9855>
_______________________________________

From report at bugs.python.org  Tue Sep 14 19:02:36 2010
From: report at bugs.python.org (Tom)
Date: Tue, 14 Sep 2010 17:02:36 +0000
Subject: [issue9855] Complex number slicing neither works nor causes an error
	on immediate use
In-Reply-To: <1284483023.7.0.0398180886345.issue9855@psf.upfronthosting.co.za>
Message-ID: <1284483756.42.0.943403676209.issue9855@psf.upfronthosting.co.za>


Tom <tom at littlemonster.co.uk> added the comment:

Thanks!

I'm not surprised that it was something stupidofme like that.

Sorry to have troubled you.

:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9855>
_______________________________________

From report at bugs.python.org  Tue Sep 14 19:26:58 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 14 Sep 2010 17:26:58 +0000
Subject: [issue9856] Change object.__format__(s) where s is non-empty to a
	DeprecationWarning
In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za>
Message-ID: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

In 3.3 the existing PendingDeprecationWarning needs to become a DeprecationWarning. In 3.4 it will become an error.

I'll change 3.3 after 3.2 is released.

See issue 7994 for the original PendingDeprecationWarning discussion.

----------
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 116413
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Change object.__format__(s) where s is non-empty to a DeprecationWarning
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9856>
_______________________________________

From report at bugs.python.org  Tue Sep 14 19:39:17 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 14 Sep 2010 17:39:17 +0000
Subject: [issue7994] object.__format__ should reject format strings
In-Reply-To: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>
Message-ID: <1284485957.5.0.592575430523.issue7994@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

See issue 9856 for changing this to a DeprecationWarning in 3.3.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7994>
_______________________________________

From report at bugs.python.org  Tue Sep 14 20:00:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 18:00:30 +0000
Subject: [issue1552] fromfd() and socketpair() should return wrapped sockets
In-Reply-To: <1196739495.6.0.25894007336.issue1552@psf.upfronthosting.co.za>
Message-ID: <1284487230.45.0.116445519859.issue1552@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

socketpair() was fixed in 3.x in r84813.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1552>
_______________________________________

From report at bugs.python.org  Tue Sep 14 20:05:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Sep 2010 18:05:07 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1284487507.87.0.46127408256.issue2292@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does

 yield *it

mean

 yield iter(tuple(it))

or

 for i in it:
     yield i
?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Tue Sep 14 20:54:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 18:54:01 +0000
Subject: [issue9854] SocketIO should return None on EWOULDBLOCK
In-Reply-To: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>
Message-ID: <1284490441.83.0.224458491818.issue9854@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem with RawIOBase.read is fixed in r84814.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9854>
_______________________________________

From report at bugs.python.org  Tue Sep 14 21:42:12 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 14 Sep 2010 19:42:12 +0000
Subject: [issue9848] setup.py contains needless references to built-in
	_weakref module
In-Reply-To: <1284406307.9.0.78586268452.issue9848@psf.upfronthosting.co.za>
Message-ID: <1284493332.39.0.522184984175.issue9848@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixed in r84819 for 3.2. No point in backporting since it doesn't hurt anything.

Thanks for the report!

----------
assignee:  -> brett.cannon
nosy: +brett.cannon
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9848>
_______________________________________

From report at bugs.python.org  Tue Sep 14 23:20:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Sep 2010 21:20:04 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1284499204.59.0.381772905805.issue6164@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Oops, this didn?t make it into 3.1.2.  Tarek, want me to commit it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Tue Sep 14 23:22:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Sep 2010 21:22:06 +0000
Subject: [issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284499326.49.0.780839544357.issue9728@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the investigation!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9728>
_______________________________________

From report at bugs.python.org  Tue Sep 14 23:29:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 21:29:01 +0000
Subject: [issue9854] SocketIO should return None on EWOULDBLOCK
In-Reply-To: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>
Message-ID: <1284499741.75.0.758346634964.issue9854@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.
The tests are only run for unbuffered objects (buffering=0), since the behaviour of buffered objects is driven by BufferedReader and friends, not by the wrapped SocketIO.

----------
keywords: +patch
nosy: +giampaolo.rodola
Added file: http://bugs.python.org/file18883/sockio_nonblock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9854>
_______________________________________

From report at bugs.python.org  Tue Sep 14 23:39:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 21:39:52 +0000
Subject: [issue9854] SocketIO should return None on EWOULDBLOCK
In-Reply-To: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>
Message-ID: <1284500392.92.0.862367240675.issue9854@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file18883/sockio_nonblock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9854>
_______________________________________

From report at bugs.python.org  Tue Sep 14 23:40:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 21:40:07 +0000
Subject: [issue9854] SocketIO should return None on EWOULDBLOCK
In-Reply-To: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>
Message-ID: <1284500407.54.0.910992097643.issue9854@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file18884/sockio_nonblock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9854>
_______________________________________

From report at bugs.python.org  Tue Sep 14 23:45:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 21:45:19 +0000
Subject: [issue9857] SkipTest in tearDown is reported an as an error
In-Reply-To: <1284500719.22.0.435536478708.issue9857@psf.upfronthosting.co.za>
Message-ID: <1284500719.22.0.435536478708.issue9857@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Raising SkipTest when in a tearDown method is reported as an error, rather than a skipped test.
Now doing this sounds like a weird use case, but it would be actually useful when you have a worker thread, and the tearDown method collects the exception raised in that thread and raises it again. For the worker thread to be able to use skipTest(), a SkipTest exception raised in tearDown should be properly reported as a skip.

----------
assignee: michael.foord
components: Library (Lib)
messages: 116422
nosy: michael.foord, pitrou
priority: normal
severity: normal
status: open
title: SkipTest in tearDown is reported an as an error
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9857>
_______________________________________

From report at bugs.python.org  Tue Sep 14 23:51:05 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 14 Sep 2010 21:51:05 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284501065.65.0.91881476232.issue9315@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The issue on 3.1 happens when Python is configured --with-computed-gotos.
(this is the case on all 3.1 buildbots)

But this issue does not happen on 3.x branch. On this branch computed-gotos is the default, but the switch --without-computed-gotos does not make a difference.

Antoine suggests to relax the test and only check if the count is within a range (12, 13).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Wed Sep 15 01:07:30 2010
From: report at bugs.python.org (Chris Withers)
Date: Tue, 14 Sep 2010 23:07:30 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1284505650.92.0.167419225833.issue6884@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

This is a regex bug, and it just bit me again :-(

Because of this bug, you cannot currently build a bdist_egg (and therefore cannot install with easy_install) http://pypi.python.org/pypi/buildout-versions on windows.

The only choice I have is to rename the 'buildout_versions' package inside the distribution to something that doesn't start with 'build'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Wed Sep 15 01:14:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Sep 2010 23:14:48 +0000
Subject: [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1284506088.36.0.767725993251.issue9802@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Documented the current behavior in r84822.

Mark, if you're free on IRC at some point, I would like to discuss further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9802>
_______________________________________

From report at bugs.python.org  Wed Sep 15 01:19:19 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 14 Sep 2010 23:19:19 +0000
Subject: [issue9854] SocketIO should return None on EWOULDBLOCK
In-Reply-To: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>
Message-ID: <1284506359.34.0.715812188339.issue9854@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I've never used socket.socket.makefile so I'm not sure, but its documentation says:

> The socket must be in blocking mode (it can not have a timeout).

If the statement is there because EAGAIN/EWOULDBLOCK were originally raised then it should be removed, otherwise I question whether makefile() is actually supposed to support non-blocking sockets in the first place.
IMO, I think it's a matter of figuring out whether makefile() should provide a socket-like behavior or a file like-behavior first.
In the first case I would expect all errors be raised as if I'm dealing with a common socket, otherwise they should be silenced/handled internally or makefile() just fail immediately as there's not such thing as "non-blocking files".

> Instead, readinto() should detect the blocking condition (EAGAIN / EWOULDBLOCK) and 
> return None (same for write(), I imagine).

io.RawIOBase.readinto doc says: 

> Read up to len(b) bytes into bytearray b and return the number of bytes read.

...so returning 0 instead of None looks more natural to me.
Same for write, also because:

>>> open('xxx', 'w').write('')
0

I've also noticed that socket.SocketIO.readinto has a while loop which continues in case of EINTR and that's something which should be removed in case makefile() actually intends to support non-blocking sockets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9854>
_______________________________________

From report at bugs.python.org  Wed Sep 15 01:51:49 2010
From: report at bugs.python.org (Bill Hayes)
Date: Tue, 14 Sep 2010 23:51:49 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1284508309.67.0.628324069922.issue7936@psf.upfronthosting.co.za>


Bill Hayes <bhayes84 at yahoo.com> added the comment:

I found this page while encountering the same problem (only one argument, the scriptname, being passed in from the command line), and wanted to post the following workaround.  I'm running Vista and using Python 2.6.
In summary I had to have 'python' at the beginning of the command line.
I found:
this did not work:  c:\>django-admin startproject mysite
this DID work:      c:\>python django-admin startproject mysite

Before finding this fix:
I had tried the 'ftype Python.File' and 'assoc .py' commands mentioned in other posts above and gotten the equivalent of 'not found'.
I actually found the correct info in the registry under HKEY_CURRENT_USER, but 'ftype' and 'assoc' don't appear to read from there.
I modified the registry under HKEY_LOCAL_MACHINE, and then I was getting the responses that were claimed to be needed in msg99369 above, but this did NOT fix the problem.
It was after the above that I found the solution - use 'python' at the beginning of the command line and all args are passed in.
(I did not go back and remove the registry edits that I made to prove conclusively that they are not part of the solution, but I doubt that they are.)

----------
nosy: +bill_sanjose

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Wed Sep 15 01:58:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 23:58:51 +0000
Subject: [issue9854] SocketIO should return None on EWOULDBLOCK
In-Reply-To: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>
Message-ID: <1284508731.53.0.639708526087.issue9854@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mardi 14 septembre 2010 ? 23:19 +0000, Giampaolo Rodola' a ?crit :
> I've never used socket.socket.makefile so I'm not sure, but its
> documentation says:
> 
> > The socket must be in blocking mode (it can not have a timeout).
> 
> If the statement is there because EAGAIN/EWOULDBLOCK were originally 
> raised then it should be removed, otherwise I question whether
> makefile() is actually supposed to support non-blocking sockets in 
> the first place.

If it wasn't supposed to, we can add that support.
The statement comes from the 2.x doc; 2.x didn't have a notion of non-blocking file-like objects at all, so it makes sense.

> IMO, I think it's a matter of figuring out whether makefile() should 
> provide a socket-like behavior or a file like-behavior first.

Well, since it claims to implement RawIOBase, it should provide a RawIOBase-like behaviour :)
(and, in any case, the only use of makefile() is to return something file-like. If you want socket-like behaviour, just use the socket)

Returning None is what raw I/O objects are supposed to do when they fail reading or writing even a single byte. It is designed and documented as such.

(the readinto() doc you mentioned lacked that precision, but I've just fixed it)

The reason None is returned (rather than 0 or b'') is so that the caller can recognize the situation and take appropriate measures.
For example, if read() returns None, it means some bytes *may* be following but we'll have to wait (select/poll/...) first; if read() returns 0, conversely, it means we've reached EOF (or, on a socket, that the peer has shutdown its side of the connection). These are two very different situations.

["file-like behaviour"]
> otherwise they should be
> silenced/handled internally or makefile() just fail immediately as
> there's not such thing as "non-blocking files".

Non-blocking files exist:

>>> import fcntl, os, io
>>> r, w = os.pipe()
>>> fcntl.fcntl(r, fcntl.F_SETFL, os.O_NONBLOCK)
0
>>> os.read(r, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 11] Resource temporarily unavailable

(It seems that on regular files O_NONBLOCK may not have an effect; not under Linux anyway)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9854>
_______________________________________

From report at bugs.python.org  Wed Sep 15 02:54:51 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Sep 2010 00:54:51 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284512091.3.0.208801022.issue767645@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

No problems noted with a quick test of posixpath_darwin.patch on 10.6 so looks good.  It will get regression tested on more configurations sometime later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Wed Sep 15 03:29:01 2010
From: report at bugs.python.org (Carlos Henrique Romano)
Date: Wed, 15 Sep 2010 01:29:01 +0000
Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode"
	parameter
In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za>
Message-ID: <1284514141.49.0.854764012831.issue2236@psf.upfronthosting.co.za>


Carlos Henrique Romano <chromano at gmail.com> added the comment:

Patch updated, now it includes test.

----------
nosy: +chromano
Added file: http://bugs.python.org/file18885/python-distutils_mkpath_filemode-v1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
_______________________________________

From report at bugs.python.org  Wed Sep 15 03:55:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Sep 2010 01:55:05 +0000
Subject: [issue9851] multiprocessing socket timeout will break client
In-Reply-To: <1284452922.14.0.631964759206.issue9851@psf.upfronthosting.co.za>
Message-ID: <1284515705.65.0.164616638779.issue9851@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +asksol, jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9851>
_______________________________________

From report at bugs.python.org  Wed Sep 15 04:21:54 2010
From: report at bugs.python.org (Jon Anglin)
Date: Wed, 15 Sep 2010 02:21:54 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1284517314.23.0.480683469785.issue9808@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

I went ahead and moved the test skip decorator to the class level as suggested by Brian Curtin, see issue9808-new.diff.

----------
Added file: http://bugs.python.org/file18886/issue9808-new.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Wed Sep 15 05:03:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 15 Sep 2010 03:03:39 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1284519819.57.0.86263932343.issue9808@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Wed Sep 15 05:15:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 03:15:34 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284520534.34.0.897574882921.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Antoine suggests to relax the test and only check
> if the count is within a range (12, 13).

This feels like implementation driven testing.  I would prefer to disable the offending test pending further investigation into the core cause. 

It is not clear to me that these differences between 2.x and 3.x are not bugs.  It seems to me that the 2.x/3.x difference discussed in msg116336 above is simply manifestation of --with-computed-gotos becoming default in 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Wed Sep 15 05:31:14 2010
From: report at bugs.python.org (Carlos Henrique Romano)
Date: Wed, 15 Sep 2010 03:31:14 +0000
Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode"
	parameter
In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za>
Message-ID: <1284521474.82.0.913999445792.issue2236@psf.upfronthosting.co.za>


Changes by Carlos Henrique Romano <chromano at gmail.com>:


Removed file: http://bugs.python.org/file18885/python-distutils_mkpath_filemode-v1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
_______________________________________

From report at bugs.python.org  Wed Sep 15 05:31:56 2010
From: report at bugs.python.org (Carlos Henrique Romano)
Date: Wed, 15 Sep 2010 03:31:56 +0000
Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode"
	parameter
In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za>
Message-ID: <1284521516.1.0.746724282075.issue2236@psf.upfronthosting.co.za>


Carlos Henrique Romano <chromano at gmail.com> added the comment:

Improving tests

----------
Added file: http://bugs.python.org/file18887/python-distutils_mkpath_filemode-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
_______________________________________

From report at bugs.python.org  Wed Sep 15 06:10:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 04:10:53 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284523853.91.0.14382023788.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like 3.1 with computed gotos produces the yet another different tracing of list comprehensions:


    2: l = [i for
   10:      i in
    1:      range(10)]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Wed Sep 15 08:59:07 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 15 Sep 2010 06:59:07 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1284533947.1.0.394282910859.issue9808@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's the first time I see the _countof() macro. There is no other usage of it in python codebase. Could you change it for something more easy for non-Windows readers?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Wed Sep 15 10:23:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 08:23:25 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1284523853.91.0.14382023788.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284538999.3190.23.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It looks like 3.1 with computed gotos produces the yet another different tracing of list comprehensions:
> 
> 
>     2: l = [i for
>    10:      i in
>     1:      range(10)]

Well, this kind of thing is going to depend on the exact bytecode, the
way the evaluation loop is written, etc. That's why I would suggest
checking that the number of traced iterations is between, e.g. 10 (since
it's the number of loop iterations) and 15 (to account for any
additional "iterations" due to various inner jumps in the bytecode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Wed Sep 15 10:27:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 08:27:10 +0000
Subject: [issue9759] GzipFile object should raise ValueError on .read() after
	.close()
In-Reply-To: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>
Message-ID: <1284539230.14.0.884215348173.issue9759@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You should make sure that all operations (except close() itself) raise ValueError. Currently:

>>> f = gzip.open("test.gz", "rb")
>>> f.close()
>>> f.read()
b''
>>> f.seek(0)
0

Also, you don't have to post a patch for 2.7. We'll do the porting ourselves.
Thanks for contributing!

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9759>
_______________________________________

From report at bugs.python.org  Wed Sep 15 10:32:15 2010
From: report at bugs.python.org (teresap989)
Date: Wed, 15 Sep 2010 08:32:15 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284539535.48.0.383304224713.issue9315@psf.upfronthosting.co.za>


teresap989 <teresap989 at yahoo.com> added the comment:

I was about to commit issue9315.3.patch, which is a lightly modified version of issue9315.2.patch, but it turned out that test_trace cannot be run by regrtest.py:

$ ./python.exe Lib/test/regrtest.py test_trace
test_trace
test test_trace failed -- multiple errors occurred; run in verbose mode for details
1 test failed:
    test_trace



__________________
[url=http://moviesonlineworld.com]watch free movies online[/url]

----------
nosy: +teresap989

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Wed Sep 15 10:34:35 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 15 Sep 2010 08:34:35 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1284538999.3190.23.camel@localhost.localdomain>
Message-ID: <AANLkTikJsywBkTczn=LqWJtpgwB0dg8JywrJ-Puj6Obm@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

Is it really *interesting* to trace separate parts of list comprehensions
like this? What would one want to do that? The only idea I have in mind of
perhaps for comprehensions containing 'if's, to know how many times the
comprehension was actually executed.

In any case, this indeed depends quite a lot on the internal representation
of comprehensions.

----------
Added file: http://bugs.python.org/file18888/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________
-------------- next part --------------
<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
&gt; It looks like 3.1 with computed gotos produces the yet another different tracing of list comprehensions:<br>
&gt;<br>
&gt;<br>
&gt; ?? ?? 2: l = [i for<br>
&gt; ?? ??10: ?? ?? ??i in<br>
&gt; ?? ?? 1: ?? ?? ??range(10)]<br>
<br>
</div>Well, this kind of thing is going to depend on the exact bytecode, the<br>
way the evaluation loop is written, etc. That&#39;s why I would suggest<br>
checking that the number of traced iterations is between, e.g. 10 (since<br>
it&#39;s the number of loop iterations) and 15 (to account for any<br>
additional &quot;iterations&quot; due to various inner jumps in the bytecode.<br>
<div><div></div><br></div></blockquote></div><br>Is it really *interesting* to trace separate parts of list comprehensions like this? What would one want to do that? The only idea I have in mind of perhaps for comprehensions containing &#39;if&#39;s, to know how many times the comprehension was actually executed.<br>

<br>In any case, this indeed depends quite a lot on the internal representation of comprehensions.<br></div>

From report at bugs.python.org  Wed Sep 15 10:40:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 08:40:57 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284540057.43.0.768540622267.issue9315@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
Removed message: http://bugs.python.org/msg116438

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Wed Sep 15 10:53:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 08:53:13 +0000
Subject: [issue9858] RawIOBase doesn't define readinto
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

RawIOBase is defined as having the readinto() method but it doesn't. It should at least have a failing one (raising io.UnsupportedOperation like the BufferedIOBase.{read,readinto} methods do).

This is, of course, mainly for auto-documenting purposes (with help() and friends).

----------
components: IO
keywords: easy
messages: 116440
nosy: pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: RawIOBase doesn't define readinto
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 10:54:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 08:54:28 +0000
Subject: [issue9858] RawIOBase doesn't define readinto
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1284540868.89.0.840475170898.issue9858@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 11:52:31 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 15 Sep 2010 09:52:31 +0000
Subject: [issue9857] SkipTest in tearDown is reported an as an error
In-Reply-To: <1284500719.22.0.435536478708.issue9857@psf.upfronthosting.co.za>
Message-ID: <1284544351.44.0.210057402801.issue9857@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Interesting use case.

If the test has not yet failed this is fine. The problem is that if an exception has *already* been raised then it will already have been added to the result - so by then skipping is meaningless (or contradictory - the test can fail *and* skip).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9857>
_______________________________________

From report at bugs.python.org  Wed Sep 15 14:28:25 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 15 Sep 2010 12:28:25 +0000
Subject: [issue9858] RawIOBase doesn't define readinto
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1284553705.59.0.071772942158.issue9858@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

+1 for a failing one. (Does the base implementation not raise?)

Is it even possible to implement a real one without buffering?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 14:39:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 12:39:59 +0000
Subject: [issue9858] RawIOBase doesn't define readinto
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1284554399.8.0.808961178011.issue9858@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> +1 for a failing one. (Does the base implementation not raise?)

The base implementation doesn't exist :)

> Is it even possible to implement a real one without buffering?

FileIO does. It's the same as read(), except that you read into an existing buffer rather than allocating a new bytes object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 15:36:55 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Sep 2010 13:36:55 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1284557815.0.0.128748480031.issue9858@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Attached is a script to find all of the mismatches between the C and Python implementations.  There are several.  Below is the output:

RawIOBase C is missing: ['readinto', 'write']
StringIO C is missing: ['name']
StringIO python is missing: ['__getstate__', '__setstate__']
BufferedRandom python is missing: ['raw']
BlockingIOError python is missing: ['characters_written']
TextIOWrapper python is missing: ['buffer']
BufferedReader python is missing: ['raw']
BufferedWriter python is missing: ['raw']
BytesIO python is missing: ['__setstate__']

Since the Python version was the original reference implementation, adding the attributes missing from the C side seems to be a straightforward decision (and it should simply match whatever the Python version does).  It looks like a number of new attributes have creeped into the C side, which will require more thoughtful decision making.

We should probably double-check that each of these is documented, while we're at it.

----------
priority: low -> normal
resolution:  -> accepted
title: RawIOBase doesn't define readinto -> Python and C implementations of io are out of sync
Added file: http://bugs.python.org/file18889/missing_methods.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 15:46:44 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Sep 2010 13:46:44 +0000
Subject: [issue9859] Add tests to verify API match of modules with 2
	implementations
In-Reply-To: <1284558397.04.0.990092096712.issue9859@psf.upfronthosting.co.za>
Message-ID: <1284558397.04.0.990092096712.issue9859@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Recently it came to light that the classes in C and Python implementations of the io module have slightly different attributes (issue9858).  I propose the addition of a helper function in Lib/test/support.py to verify that the classes in two different implementations define the same attributes.  Then, we can add tests to use that function to verify that C and Python implementations define the same API (for the io module, but also for other modules where we have two implementations).  The script I added to issue9858 could serve as a starting point for such a function.

Since CPython's standard library is the de facto reference implementation, it's important that it define one API and not two slightly different ones. :-)

----------
components: Tests
messages: 116445
nosy: stutzbach
priority: low
severity: normal
stage: needs patch
status: open
title: Add tests to verify API match of modules with 2 implementations
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9859>
_______________________________________

From report at bugs.python.org  Wed Sep 15 15:47:20 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Sep 2010 13:47:20 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1284558440.31.0.519073929951.issue9858@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

FWIW, I just opened Issue9859: Add tests to verify API match of modules with 2 implementations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 15:54:13 2010
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 15 Sep 2010 13:54:13 +0000
Subject: [issue9851] multiprocessing socket timeout will break client
In-Reply-To: <1284452922.14.0.631964759206.issue9851@psf.upfronthosting.co.za>
Message-ID: <1284558853.51.0.960226777799.issue9851@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Calling it stupid doesn't incentivize me to help you, or fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9851>
_______________________________________

From report at bugs.python.org  Wed Sep 15 15:54:46 2010
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Wed, 15 Sep 2010 13:54:46 +0000
Subject: [issue9857] SkipTest in tearDown is reported an as an error
In-Reply-To: <1284500719.22.0.435536478708.issue9857@psf.upfronthosting.co.za>
Message-ID: <1284558886.46.0.543807982237.issue9857@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda <draghuram at gmail.com>:


----------
nosy: +draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9857>
_______________________________________

From report at bugs.python.org  Wed Sep 15 16:08:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 14:08:16 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

When testing config options, it is often useful to build python in a directory different from the root of the source tree.  This is supported by autoconf based builds as follows: you cd to the desired directory run configure with an explicit path. For example:

$ cd ../altdir
$ ../python-source/configure
$ make

However, this fails for python 3.1 and 3.2 with the following error:


i686-apple-darwin10-gcc-4.2.1: Parser/tokenizer_pgen.o: No such file or directory
i686-apple-darwin10-gcc-4.2.1: Parser/printgrammar.o: No such file or directory
i686-apple-darwin10-gcc-4.2.1: Parser/pgenmain.o: No such file or directory
make: *** [Parser/pgen] Error 1

----------
assignee: belopolsky
components: Interpreter Core
messages: 116448
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Building python outside of source directory fails
type: compile error
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Wed Sep 15 16:18:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Sep 2010 14:18:20 +0000
Subject: [issue678264] test_resource fails when file size is limited
Message-ID: <1284560300.36.0.147271607336.issue678264@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The test does not fail if FSIZE is not max on linux/py3k, but max is still represented as -1 on linux.  So the reported bug is no longer valid, but Martin's concern has not been addressed.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678264>
_______________________________________

From report at bugs.python.org  Wed Sep 15 16:19:52 2010
From: report at bugs.python.org (paul clinch)
Date: Wed, 15 Sep 2010 14:19:52 +0000
Subject: [issue9861] subprocess module changed exposed attributes
In-Reply-To: <1284560392.0.0.232628441453.issue9861@psf.upfronthosting.co.za>
Message-ID: <1284560392.0.0.232628441453.issue9861@psf.upfronthosting.co.za>


New submission from paul clinch <pclinch at internet-glue.co.uk>:

Some attributes, e.g. STARTF_USESHOWWINDOW have moved to _subrocess.STARTF_USESHOWWINDOW. This breaks old code.

----------
components: Library (Lib)
messages: 116450
nosy: pclinch
priority: normal
severity: normal
status: open
title: subprocess module changed exposed attributes
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9861>
_______________________________________

From report at bugs.python.org  Wed Sep 15 16:45:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 14:45:51 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1284561951.29.0.579971841188.issue9860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I think the problem is with the following explicit rules in Makefile:


Parser/tokenizer_pgen.o:        $(srcdir)/Parser/tokenizer.c

Parser/pgenmain.o:      $(srcdir)/Include/parsetok.h

It looks like these rules are not VPATH friendly.  Per Antoine's suggestions, adding build experts to the nosy list.

----------
nosy: +dmalcolm, doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Wed Sep 15 16:56:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Sep 2010 14:56:13 +0000
Subject: [issue9859] Add tests to verify API match of modules with 2
	implementations
In-Reply-To: <1284558397.04.0.990092096712.issue9859@psf.upfronthosting.co.za>
Message-ID: <1284562573.09.0.317152613842.issue9859@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Shouldn't the test suite catch such discrepancies by testing all of the API?  So your script catching something would be the equivalent of "oops, we forgot a test" (or "oops, this name shouldn't be public").  Which is not a bad thing to have as part of the test suite.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9859>
_______________________________________

From report at bugs.python.org  Wed Sep 15 17:03:23 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Sep 2010 15:03:23 +0000
Subject: [issue9859] Add tests to verify API match of modules with 2
	implementations
In-Reply-To: <1284558397.04.0.990092096712.issue9859@psf.upfronthosting.co.za>
Message-ID: <1284563003.36.0.753450246614.issue9859@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Yes, exactly. :-)

(see also Issue9731, which has a similar flavor)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9859>
_______________________________________

From report at bugs.python.org  Wed Sep 15 17:06:03 2010
From: report at bugs.python.org (Stonewall Ballard)
Date: Wed, 15 Sep 2010 15:06:03 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now
	"10.3"	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1284563163.47.0.334205777671.issue9516@psf.upfronthosting.co.za>


Stonewall Ballard <stoneyb at gmail.com> added the comment:

I just ran into this with Python 2.7, installed using port. I'm using python to process a text file in an Xcode 3.2 Script build step, and it's throwing the error because my Xcode target has a base sdk of 10.5.

----------
nosy: +stoneyb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Wed Sep 15 17:06:11 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 15 Sep 2010 15:06:11 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <1284557815.0.0.128748480031.issue9858@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=RLjkt6f-_rQujXzBsZBsd10Ksnd-7y-DzjMth@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/9/15 Daniel Stutzbach <report at bugs.python.org>:
>
> Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:
>
> Attached is a script to find all of the mismatches between the C and Python implementations. ?There are several. ?Below is the output:
>
> BufferedRandom python is missing: ['raw']
> TextIOWrapper python is missing: ['buffer']
> BufferedReader python is missing: ['raw']
> BufferedWriter python is missing: ['raw']

These attributes exist; they're just not properties.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 17:18:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 15:18:26 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1284563906.26.0.519473742466.issue9860@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It works here (Linux). Did you try make distclean first? Also, try to remove the various files created by configure.

(what is VPATH?)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Wed Sep 15 17:24:33 2010
From: report at bugs.python.org (Chris Withers)
Date: Wed, 15 Sep 2010 15:24:33 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1284564273.89.0.931048117648.issue6884@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

So, the workaround I gave doesn't work, because this stupid regex still knocks out all the egg-info. The only solution is to use that accidentally employed by http://svn.plone.org/svn/collective/buildout/buildout.dumppickedversions/trunk/ and put any files starting with 'build' and that need to be used on Windows in a sub-folder.

Here's a debug sdist build dump from buildout.dumppickedversions:

Running setup script 'setup.py'.
Distribution.parse_config_files():
options (after parsing config files):
no commands known yet
options (after parsing command line):
option dict for 'aliases' command:
  {}
option dict for 'sdist' command:
  {}
running sdist
Distribution.get_command_obj(): creating 'sdist' command object
running egg_info
Distribution.get_command_obj(): creating 'egg_info' command object
writing requirements to src\buildout.dumppickedversions.egg-info\requires.txt
writing src\buildout.dumppickedversions.egg-info\PKG-INFO
writing namespace_packages to src\buildout.dumppickedversions.egg-info\namespace_packages.txt
writing top-level names to src\buildout.dumppickedversions.egg-info\top_level.txt
writing dependency_links to src\buildout.dumppickedversions.egg-info\dependency_links.txt
writing entry points to src\buildout.dumppickedversions.egg-info\entry_points.txt
Distribution.get_command_obj(): creating 'build_py' command object
Distribution.get_command_obj(): creating 'build' command object
include_pattern: applying regex r'^src\\buildout\.dumppickedversions\.egg\-info\.*[^/]*\Z(?ms)'
 adding src\buildout.dumppickedversions.egg-info\dependency_links.txt
 adding src\buildout.dumppickedversions.egg-info\entry_points.txt
 adding src\buildout.dumppickedversions.egg-info\namespace_packages.txt
 adding src\buildout.dumppickedversions.egg-info\not-zip-safe
 adding src\buildout.dumppickedversions.egg-info\PKG-INFO
 adding src\buildout.dumppickedversions.egg-info\requires.txt
 adding src\buildout.dumppickedversions.egg-info\SOURCES.txt
 adding src\buildout.dumppickedversions.egg-info\top_level.txt
exclude_pattern: applying regex r'^build\.*'
 removing buildout.cfg
exclude_pattern: applying regex r'^buildout\.dumppickedversions\-0\.5\.*'
...

Now contrast with buildout_versions:

Running setup script 'setup.py'.
Distribution.parse_config_files():
options (after parsing config files):
no commands known yet
options (after parsing command line):
option dict for 'aliases' command:
  {}
option dict for 'sdist' command:
  {}
running sdist
Distribution.get_command_obj(): creating 'sdist' command object
running egg_info
Distribution.get_command_obj(): creating 'egg_info' command object
writing requirements to buildout_versions.egg-info\requires.txt
writing buildout_versions.egg-info\PKG-INFO
writing top-level names to buildout_versions.egg-info\top_level.txt
writing dependency_links to buildout_versions.egg-info\dependency_links.txt
writing entry points to buildout_versions.egg-info\entry_points.txt
Distribution.get_command_obj(): creating 'build_py' command object
Distribution.get_command_obj(): creating 'build' command object
include_pattern: applying regex r'^buildout\_versions\.egg\-info\.*[^/]*\Z(?ms)'
 adding buildout_versions.egg-info\dependency_links.txt
 adding buildout_versions.egg-info\entry_points.txt
 adding buildout_versions.egg-info\not-zip-safe
 adding buildout_versions.egg-info\PKG-INFO
 adding buildout_versions.egg-info\requires.txt
 adding buildout_versions.egg-info\SOURCES.txt
 adding buildout_versions.egg-info\top_level.txt
exclude_pattern: applying regex r'^build\.*'
 removing buildout_versions.egg-info\top_level.txt
 removing buildout_versions.egg-info\SOURCES.txt
 removing buildout_versions.egg-info\requires.txt
 removing buildout_versions.egg-info\PKG-INFO
 removing buildout_versions.egg-info\not-zip-safe
 removing buildout_versions.egg-info\entry_points.txt
 removing buildout_versions.egg-info\dependency_links.txt
 removing buildout.cfg
 removing buildout_versions.egg-info\SOURCES.txt
exclude_pattern: applying regex r'^buildout\-versions\-1\.4\.*'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Wed Sep 15 17:24:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 15:24:45 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1284564285.98.0.93072402726.issue9860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It turns out that make only gets confused when target files (Parser/pgenmain.o etc.) exist in the source directory.  Thus an obvious workaround is to build all versions in alternative directories or delete object files from source tree before alternative builds.

This is still fragile and does not explain why for some targets, VPATH candidates are ignored and for some are not.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Wed Sep 15 17:30:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 15:30:48 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1284564648.23.0.148132414605.issue9860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> (what is VPATH?)

VPATH is a search path that make uses to find targets and prerequisites.  configure sets it to its own location when invoked from a directory other than cwd.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Wed Sep 15 17:44:18 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Sep 2010 15:44:18 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1284565458.87.0.459252003273.issue9858@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> These attributes exist; they're just not properties.

Yes, I see.  They're added to the instance in the constructor, so they don't exist as attributes of the class.  Also in that category:

BlockingIOError python is missing: ['characters_written']

That leaves:

RawIOBase C is missing: ['readinto', 'write']
StringIO C is missing: ['name']
StringIO python is missing: ['__getstate__', '__setstate__']
BytesIO python is missing: ['__setstate__']

The Python version of StringIO throws an AttributeException on the .name attribute.  It's a property inherited from the TextIOWrapper.  Effectively, TextIOWrapper provides the .name attribute if the object that it's wrapping provides the .name attribute.  This behavior is undocumented.

Is that reasonable behavior?  Or should TextIOWrapper define .name always and return some suitable value if the wrapped object doesn't define .name? (e.g., None)

In any case, it needs documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 17:50:06 2010
From: report at bugs.python.org (Chris Withers)
Date: Wed, 15 Sep 2010 15:50:06 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1284565806.98.0.290574222451.issue6884@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Okay, so here's the patch:

Change line 352 on distutils/filelist.py from:

pattern_re = "^" + os.path.join(prefix_re, ".*" + pattern_re)

To:

pattern_re = "^"+prefix_re+re.escape(os.sep)+".*"+pattern_re

os.path.join is is not always the saviour ;-)

----------
keywords: +needs review -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Wed Sep 15 17:51:10 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 15 Sep 2010 15:51:10 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <1284565458.87.0.459252003273.issue9858@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=R9B5B6XcRWkEFGMa4w4WjxPFnncxh6GyRfonE@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/9/15 Daniel Stutzbach <report at bugs.python.org>:
>
> Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:
>
>> These attributes exist; they're just not properties.
>
> Yes, I see.  They're added to the instance in the constructor, so they don't exist as attributes of the class.  Also in that category:
>
> BlockingIOError python is missing: ['characters_written']
>
> That leaves:
>
> RawIOBase C is missing: ['readinto', 'write']
> StringIO C is missing: ['name']
> StringIO python is missing: ['__getstate__', '__setstate__']
> BytesIO python is missing: ['__setstate__']

I'm not sure if this pickling stuff matters as long as they both pickle.

>
> The Python version of StringIO throws an AttributeException on the .name attribute.  It's a property inherited from the TextIOWrapper.  Effectively, TextIOWrapper provides the .name attribute if the object that it's wrapping provides the .name attribute.  This behavior is undocumented.
>
> Is that reasonable behavior?  Or should TextIOWrapper define .name always and return some suitable value if the wrapped object doesn't define .name? (e.g., None)

Yes, all the code expects an AttributeError on name is it's not
present. For example, FileIO only sets its name attribute if it is
passed a filename and not an fd.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 18:01:37 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Sep 2010 16:01:37 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <AANLkTi=R9B5B6XcRWkEFGMa4w4WjxPFnncxh6GyRfonE@mail.gmail.com>
Message-ID: <AANLkTimuxYtg2K2utX5_mKMKkq+egV-2C_WtTbW2m9am@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Wed, Sep 15, 2010 at 10:51 AM, Benjamin Peterson
<report at bugs.python.org>wrote:

> I'm not sure if this pickling stuff matters as long as they both pickle.
>

I'm not sure either.  Do other Python implementations try to maintain a
compatible pickle format with CPython?  If so, I think CPython's C and
Python versions should also pickle to the same format.

> Yes, all the code expects an AttributeError on name is it's not
> present. For example, FileIO only sets its name attribute if it is
> passed a filename and not an fd.
>

Actually, FileIO sets the name attribute to the file descriptor if it isn't
passed a name:

1

----------
Added file: http://bugs.python.org/file18890/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________
-------------- next part --------------
<div class="gmail_quote">On Wed, Sep 15, 2010 at 10:51 AM, Benjamin Peterson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

I&#39;m not sure if this pickling stuff matters as long as they both pickle.<br></blockquote><div><br>I&#39;m not sure either.?? Do other Python implementations try to maintain a compatible pickle format with CPython??? If so, I think CPython&#39;s C and Python versions should also pickle to the same format.<br>
??</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Yes, all the code expects an AttributeError on name is it&#39;s not<br>
present. For example, FileIO only sets its name attribute if it is<br>
passed a filename and not an fd.<br></blockquote><div><br>Actually, FileIO sets the name attribute to the file descriptor if it isn&#39;t passed a name:<br><br>&gt;&gt;&gt; f = io.FileIO(1)<br>&gt;&gt;&gt; <a href="http://f.name">f.name</a><br>
1<br></div></div>

From report at bugs.python.org  Wed Sep 15 18:10:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Sep 2010 16:10:09 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1284567009.75.0.8156664949.issue9858@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file18890/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 18:10:34 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Sep 2010 16:10:34 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1284567034.35.0.703577008977.issue9858@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Roundup does not play well with Gmail when Gmail is in Rich Format mode ;-)

That example should have read:

>>> f = io.FileIO(1)
>>> f.name
1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 18:13:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 16:13:16 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284567196.57.0.629099141992.issue9315@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file18888/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Wed Sep 15 18:26:12 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 15 Sep 2010 16:26:12 +0000
Subject: [issue1633863] AIX: configure ignores $CC
Message-ID: <1284567972.56.0.138821013649.issue1633863@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Antoine, I tested your commit with cc_r and it compiles fine (I have buildbot running now, just need to find a way to make the results publicly browsable).

I still think xlc_r would be a better choice as a default: at the moment ctypes will not compile on AIX, but cc_r will fail as soon as when it compiles _ctypes.c, while xlc_r will compile this file fine but fail later on libffi/src/powerpc/ffi.c

cc_r -qlanglvl=extc89 -DNDEBUG -O -O2 -O2 -Ibuild/temp.aix-6.1-3.2/libffi/include -Ibuild/temp.aix-6.1-3.2/libffi -I/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/libffi/src -I. -I./Include -I/home/cis/buildbot/support-buildbot/include -I/home/cis/buildbot/support-buildbot/include/ncurses -I/usr/local/include -IInclude -I/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build -c /san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c -o build/temp.aix-6.1-3.2/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.o
"build/temp.aix-6.1-3.2/libffi/include/ffi.h", line 133.27: 1506-207 (W) Integer constant 9223372036854775807 out of range.
"build/temp.aix-6.1-3.2/libffi/include/ffi.h", line 134.3: 1506-205 (S) #error "no 64-bit data type supported"
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 3222.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 3766.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 5386.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 5387.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 5388.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 5389.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 5391.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633863>
_______________________________________

From report at bugs.python.org  Wed Sep 15 18:29:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 16:29:14 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284568154.34.0.202173077241.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Is it really *interesting* to trace separate parts of list
> comprehensions like this?

It may or may not be useful for tracing code in the wild, but it helps to isolate the causes of count mismatches.

I am attaching a file, x.py, that shows differing behavior for 3.1 and 3.2 and with and without computed gotos in each version.

The traced code is


2 def f():
3     return [i
4             for i
5             in range(10)]

and the script prints the disassembly of f including the listcomp object.

The results are (s/g - with/without computed gotos):

3.1s: {('x.py', 3): 2, ('x.py', 5): 1}
3.1g: {('x.py', 4): 10, ('x.py', 3): 2, ('x.py', 5): 1}
3.2s: {('x.py', 3): 12, ('x.py', 5): 1}
3.2g: {('x.py', 4): 10, ('x.py', 3): 12, ('x.py', 5): 1}

Note that the bytecode is the same in all cases:

  3           0 LOAD_CONST               1 (<code object <listcomp> at 0x1005250b8, file "x.py", line 3>) 
              3 MAKE_FUNCTION            0 

  5           6 LOAD_GLOBAL              0 (range) 
              9 LOAD_CONST               2 (10) 
             12 CALL_FUNCTION            1 
             15 GET_ITER             
             16 CALL_FUNCTION            1 
             19 RETURN_VALUE         
listcomp:
  3           0 BUILD_LIST               0 
              3 LOAD_FAST                0 (.0) 
        >>    6 FOR_ITER                12 (to 21) 

  4           9 STORE_FAST               1 (i) 
             12 LOAD_FAST                1 (i) 
             15 LIST_APPEND              2 
             18 JUMP_ABSOLUTE            6 
        >>   21 RETURN_VALUE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Wed Sep 15 18:30:34 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 15 Sep 2010 16:30:34 +0000
Subject: [issue9862] test_subprocess hangs on AIX
In-Reply-To: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>
Message-ID: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

On AIX, the test test_communicate_pipe_buf in test_subprocess will hang forever (in py3k and py27):

test_communicate_pipe_buf (__main__.ProcessTestCase) ... 


  File "Lib/test/test_subprocess.py", line 386, in test_communicate_pipe_buf
    (stdout, stderr) = p.communicate(string_to_write)
  File "/san_cis/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/Python-2.7-svn/Lib/subprocess.py", line 740, in communicate
    return self._communicate(input)
  File "/san_cis/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/Python-2.7-svn/Lib/subprocess.py", line 1257, in _communicate
    stdout, stderr = self._communicate_with_poll(input)
  File "/san_cis/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/Python-2.7-svn/Lib/subprocess.py", line 1320, in _communicate_with_poll
    input_offset += os.write(fd, chunk)
KeyboardInterrupt

The comment in this test indicates:
  # communicate() with writes larger than pipe_buf
  # This test will probably deadlock rather than fail, if
  # communicate() does not work properly.

So I guess it means communicate() does not work properly on AIX.

----------
components: Library (Lib)
messages: 116467
nosy: sable
priority: normal
severity: normal
status: open
title: test_subprocess hangs on AIX
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9862>
_______________________________________

From report at bugs.python.org  Wed Sep 15 18:31:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 16:31:14 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284568274.45.0.607286167606.issue9315@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file18891/x.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Wed Sep 15 18:47:53 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 15 Sep 2010 16:47:53 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <1284567034.35.0.703577008977.issue9858@psf.upfronthosting.co.za>
Message-ID: <AANLkTikkmbBVW5H9zPmn76OzKCRa2qdBjbt2XqktOLJf@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/9/15 Daniel Stutzbach <report at bugs.python.org>:
>
> Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:
>
> Roundup does not play well with Gmail when Gmail is in Rich Format mode ;-)
>
> That example should have read:
>
>>>> f = io.FileIO(1)
>>>> f.name
> 1

Hmm, none the less other code expects it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 19:30:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 17:30:57 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284571857.88.0.484713749188.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching another test file, y.py, which shows that the cause of discrepancy is outside of the trace module. The traced function is the same as in x.py only with 5 iterations instead of 10 for brevity, but instead of using trace module, I am registering a custom trace function like this:

lines =	[]
def tracefunc(frame, what, arg):
    if what == 'line':
	lines.append(frame.f_lineno)
    return tracefunc
sys.settrace(tracefunc)

3.1s: [3, 5, 3]
3.1g: [3, 5, 3, 4, 4, 4, 4, 4]
3.2s: [3, 5, 3, 3, 3, 3, 3, 3]
3.2g: [3, 5, 3, 4, 3, 4, 3, 4, 3, 4, 3, 4, 3]

Interestingly, this shows that effect of computed gotos is the same in 3.1 and 3.2 - adding a line event from "for i" line.

This situation illustrates the reason why I wanted to use synthetic events to test the trace module rather than events generated by settrace  machinery.  Apparently these differences have nothing to do with trace.py and everything with ceval.c.  If it is important to maintain stability of trace events between python versions, tests (with appropriate sensitivity) should be added to test_sys_setrace.

On the other hand, there are a lot of things that can go wrong in trace.py - extracting code information from frame, divining the method and class names etc.  Ideally, this logic should be tested without reliance on details of event generation.

----------
Added file: http://bugs.python.org/file18892/y.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Wed Sep 15 19:35:44 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Wed, 15 Sep 2010 17:35:44 +0000
Subject: [issue9759] GzipFile object should raise ValueError on .read() after
	.close()
In-Reply-To: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>
Message-ID: <1284572144.33.0.417056839807.issue9759@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

Here's the updated patch, which checks whether the file is closed on each call to read(), write(), and flush(), along with a test.

----------
Added file: http://bugs.python.org/file18893/issue9759.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9759>
_______________________________________

From report at bugs.python.org  Wed Sep 15 20:20:54 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 15 Sep 2010 18:20:54 +0000
Subject: [issue9854] SocketIO should return None on EWOULDBLOCK
In-Reply-To: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>
Message-ID: <1284574854.32.0.403686635118.issue9854@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Non-blocking files exist

Of course, I should have been more clear.
What I meant is that there's no such thing as explicit and "native" as setblocking() for plain files.

> Returning None is what raw I/O objects are supposed to do when they 
> fail reading or writing even a single byte. It is designed and 
> documented as such.

>From http://docs.python.org/dev/library/io.html#module-io about io.BufferedIOBase.readinto()

> A BlockingIOError is raised if the underlying raw stream is in non 
> blocking-mode, and has no data available at the moment.

This is valid for BufferedReader, BufferWriter and BufferIOBase classes in various methods while io.RawIOBase.write() and io.RawIOBase.read() return None instead. Shouldn't they raise BlockingIOError as well? Why do they return None?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9854>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:00:15 2010
From: report at bugs.python.org (Corey Bertram)
Date: Wed, 15 Sep 2010 19:00:15 +0000
Subject: [issue9863] threading, signals,
	atexit: different execution with different versions
Message-ID: <1284577215.42.0.967366454397.issue9863@psf.upfronthosting.co.za>


Changes by Corey Bertram <corey at qr7.com>:


----------
nosy: cbertram
priority: normal
severity: normal
status: open
title: threading, signals, atexit: different execution with different versions
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9863>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:02:22 2010
From: report at bugs.python.org (Corey Bertram)
Date: Wed, 15 Sep 2010 19:02:22 +0000
Subject: [issue9863] threading, signals,
	atexit: different execution with different versions
In-Reply-To: <1284577342.31.0.557156421767.issue9863@psf.upfronthosting.co.za>
Message-ID: <1284577342.31.0.557156421767.issue9863@psf.upfronthosting.co.za>


New submission from Corey Bertram <corey at qr7.com>:

my code works on python 2.6.2 and fails to work on python 2.6.5. What's going on here?

import atexit, sys, signal, time, threading

terminate = False
threads = []

def test_loop():
    while True:
        if terminate:
            print('stopping thread')
            break
        else:
            print('looping')
            time.sleep(1)

@atexit.register
def shutdown():
    global terminate
    print('shutdown detected')
    terminate = True
    for thread in threads:
        thread.join()

def close_handler(signum, frame):
    print('caught signal')
    sys.exit(0)

def run():
    global threads
    thread = threading.Thread(target=test_loop)
    thread.start()
    threads.append(thread)

    while True:
        time.sleep(2)
        print('main')

signal.signal(signal.SIGINT, close_handler)

if __name__ == "__main__":
    run()


python 2.6.2:
$ python halp.py 
looping
looping
looping
main
looping
main
looping
looping
looping
main
looping
^Ccaught signal
shutdown detected
stopping thread

python 2.6.5:
$ python halp.py 
looping
looping
looping
main
looping
looping
main
looping
looping
main
^Ccaught signal
looping
looping
looping
looping
...
looping
looping
Killed <- kill -9 process at this point

The main thread on 2.6.5 appears to never execute the atexit functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9863>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:05:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 19:05:24 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

They both return raw tuples, which are not very intuitive to interpret:

>>> email.utils.parsedate_tz("Wed, 15 Sep 2010 09:53:50 -0700 (PDT)")
(2010, 9, 15, 9, 53, 50, 0, 1, -1, -25200)

It would be much better if they returned some kind of namedtuple, which would preserve backwards compatibility but with much better readability and usability.

Note that parsedate() could also return the existing time.struct_time type (which is compatible with a 9-tuple):
http://docs.python.org/library/time.html#time.struct_time

----------
components: Library (Lib)
messages: 116473
nosy: barry, pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email.utils.{parsedate,parsedate_tz} should have better return types
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:06:07 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 15 Sep 2010 19:06:07 +0000
Subject: [issue9861] subprocess module changed exposed attributes
In-Reply-To: <1284560392.0.0.232628441453.issue9861@psf.upfronthosting.co.za>
Message-ID: <1284577567.25.0.702430671681.issue9861@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/issue9861>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:09:38 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 15 Sep 2010 19:09:38 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1284577778.79.0.138860877391.issue9864@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:09:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 19:09:58 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1284577798.74.0.358263364864.issue9864@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, while as mentioned in the docs ?indexes 6, 7, and 8 of the result tuple are not usable?, perhaps it would be time to fix it? (at least for 6 and 7, aka. wday and yday)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:26:08 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 15 Sep 2010 19:26:08 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1284578768.77.0.0809953694907.issue4761@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:29:16 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 15 Sep 2010 19:29:16 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284578956.1.0.465572998402.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

@Martin: yep, I know we still need to install pyconfig.h and Makefile, but we shouldn't need to parse them to get programmatic access to the data they contain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:30:01 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 15 Sep 2010 19:30:01 +0000
Subject: [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1284579001.12.0.104356193263.issue9746@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9746>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:31:41 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 15 Sep 2010 19:31:41 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1284579101.45.0.930114006504.issue9756@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9756>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:36:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 19:36:02 +0000
Subject: [issue9854] SocketIO should return None on EWOULDBLOCK
In-Reply-To: <1284574854.32.0.403686635118.issue9854@psf.upfronthosting.co.za>
Message-ID: <1284579358.3190.70.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Of course, I should have been more clear.
> What I meant is that there's no such thing as explicit and "native" as
> setblocking() for plain files.

Indeed. It would probably be a nice addition, assuming it is portable
enough.

> > A BlockingIOError is raised if the underlying raw stream is in non 
> > blocking-mode, and has no data available at the moment.
> 
> This is valid for BufferedReader, BufferWriter and BufferIOBase
> classes in various methods while io.RawIOBase.write() and
> io.RawIOBase.read() return None instead. Shouldn't they raise
> BlockingIOError as well? Why do they return None?

Well, that's how it was decided when the new IO lib was designed.
See http://www.python.org/dev/peps/pep-3116/#non-blocking-i-o
(but this says that write() should return 0, while the FileIO
implementation returns None; I'd say that for consistency with read()
and readinto() returning None is the right thing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9854>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:45:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 19:45:07 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284579907.2.0.574767481256.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Raymond asked on IRC why this work is being back-ported.  The answer is that it is being forward-ported rather than back-ported.  The trace module had no unittests in either 2.x or 3.x and was very buggy in 3.x.  Presumably, 2.x version saw more use and was likely to be more correct than 3.x, so we decided to start with adding unit tests to 2.7 and then port the tests to 3.x while fixing the bugs.  See msg111134.

This does not necessarily mean that we need to include 3.1. It may be appropriate to limit what is going to 3.1 to tests that support bug fixes.

If nobody raises an objection, I am going to close this issue by removing list comprehension test from 3.1 and will open a separate "interpreter core" issue for line tracing inconsistencies.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Wed Sep 15 22:03:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Sep 2010 20:03:02 +0000
Subject: [issue678264] test_resource fails when file size is limited
Message-ID: <1284580982.98.0.416446600835.issue678264@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As a point of information, on my gentoo linux system without largefile support in the kernel, any value 4294967295 or above results in getrlimit reporting -1.  Any smaller value is set and reported as itself.  (If a sufficiently large value is passed in to setrlimit, an OverflowError results.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678264>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:02:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Sep 2010 21:02:45 +0000
Subject: [issue9863] threading, signals,
	atexit: different execution with different versions
In-Reply-To: <1284577342.31.0.557156421767.issue9863@psf.upfronthosting.co.za>
Message-ID: <1284584565.29.0.48612666497.issue9863@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can confirm this, and that it works on python2.5 (I don't have a 2.6.2 around to test).  It also has the looping behavior on 2.7 and 3.2.

Given the timing, I wonder if this is the result of the fix to issue 1722344.

(Note, I removed 2.6 because it doesn't receive bug fixes any more, only security fixes.)

----------
nosy: +pitrou, r.david.murray
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9863>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:12:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 21:12:39 +0000
Subject: [issue9865] OrderedDict doesn't implement __sizeof__
In-Reply-To: <1284585159.01.0.70557172329.issue9865@psf.upfronthosting.co.za>
Message-ID: <1284585159.01.0.70557172329.issue9865@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Ordered dicts pretend to have the memory consumption as dicts:

>>> import sys, collections
>>> sys.getsizeof({})
280
>>> sys.getsizeof(collections.OrderedDict())
280

----------
components: Library (Lib)
messages: 116481
nosy: pitrou, rhettinger
priority: low
severity: normal
status: open
title: OrderedDict doesn't implement __sizeof__
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9865>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:17:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 21:17:57 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1284585477.3.0.86784843522.issue9360@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file18894/nntplib_cleanup4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:23:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 21:23:01 +0000
Subject: [issue9866] Inconsistencies in tracing list comprehensions
In-Reply-To: <1284585781.8.0.0490639400631.issue9866@psf.upfronthosting.co.za>
Message-ID: <1284585781.8.0.0490639400631.issue9866@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached test script, tracetest.py, prints disassembly followed by a trace of the following function:


1  def f():
2      return [i
3              for i
4              in range(2)]


With default configuration, the output is


  2           0 LOAD_CONST               1 (<code object <listcomp> at 0x100484e00, file "tracetest.py", line 2>) 
              3 MAKE_FUNCTION            0 

  4           6 LOAD_GLOBAL              0 (range) 
              9 LOAD_CONST               2 (2) 
             12 CALL_FUNCTION            1 
             15 GET_ITER             
             16 CALL_FUNCTION            1 
             19 RETURN_VALUE         
listcomp:
  2           0 BUILD_LIST               0 
              3 LOAD_FAST                0 (.0) 
        >>    6 FOR_ITER                12 (to 21) 

  3           9 STORE_FAST               1 (i) 
             12 LOAD_FAST                1 (i) 
             15 LIST_APPEND              2 
             18 JUMP_ABSOLUTE            6 
        >>   21 RETURN_VALUE         
['2 0 LOAD_CONST', '4 6 LOAD_GLOBAL', '2 0 BUILD_LIST', '3 9 STORE_FAST', '2 6 FOR_ITER', '3 9 STORE_FAST', '2 6 FOR_ITER']

but with configuration using --without-computed-gotos option, the disassembly is the same, but the trace is different:


['2 0 LOAD_CONST', '4 6 LOAD_GLOBAL', '2 0 BUILD_LIST', '2 6 FOR_ITER', '2 6 FOR_ITER']

This behavior changed between 3.1 and 3.2 (likely in r74132), but it is inconsistent in both versions.  Since r74132 changes were not backported to 3.1, I am classifying this as 3.2 only even though the problem is present in 3.1 as well.

See also issues #6042 and #9315.

----------
components: Interpreter Core
files: tracetest.py
messages: 116482
nosy: alexandre.vassalotti, amaury.forgeotdarc, belopolsky, collinwinter, eli.bendersky, ezio.melotti, flox, georg.brandl, jyasskin, pitrou, rhettinger, teresap989, terry.reedy
priority: normal
severity: normal
status: open
title: Inconsistencies in tracing list comprehensions
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18895/tracetest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9866>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:28:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Sep 2010 21:28:47 +0000
Subject: [issue1633863] AIX: configure ignores $CC
Message-ID: <1284586127.79.0.767793857364.issue1633863@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

S?bastien, you could email Martin (tracker id loewis) about adding your buildbot to our unstable fleet (or even to stable if it is stable; that is, the tests normally pass and don't randomly fail).  As long as you are around to help fix bugs it would be great to have an aix buildbot in our buildbot fleet.

(NB: see also http://wiki.python.org/moin/BuildBot, which unfortunately is a bit out of date...)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633863>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:29:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 21:29:00 +0000
Subject: [issue9865] OrderedDict doesn't implement __sizeof__
In-Reply-To: <1284585159.01.0.70557172329.issue9865@psf.upfronthosting.co.za>
Message-ID: <1284586140.43.0.0365119828064.issue9865@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I wonder if type metaclass can be taught to handle this in general for subclasses implemented in python.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9865>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:30:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 21:30:40 +0000
Subject: [issue9865] OrderedDict doesn't implement __sizeof__
In-Reply-To: <1284585159.01.0.70557172329.issue9865@psf.upfronthosting.co.za>
Message-ID: <1284586240.21.0.714842153499.issue9865@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

How do you want to "handle this in general"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9865>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:33:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 21:33:59 +0000
Subject: [issue9866] Inconsistencies in tracing list comprehensions
In-Reply-To: <1284585781.8.0.0490639400631.issue9866@psf.upfronthosting.co.za>
Message-ID: <1284586439.08.0.986395223701.issue9866@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As I said in #9315, I think this kind of thing (bytecode traces) is an implementation detail; the changes in results shouldn't be regarded as breaking compatibility.
The only problem I could see would be if a whole line of code would be "forgotten".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9866>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:37:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 21:37:18 +0000
Subject: [issue9865] OrderedDict doesn't implement __sizeof__
In-Reply-To: <1284585159.01.0.70557172329.issue9865@psf.upfronthosting.co.za>
Message-ID: <1284586638.14.0.366528605834.issue9865@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> How do you want to "handle this in general"?

Possibly by adding up __sizeof__'s of base and __dict__ in a generated function?  With a special handling of slots ...

May prove to be too complicated to be worth the effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9865>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:39:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 21:39:50 +0000
Subject: [issue9865] OrderedDict doesn't implement __sizeof__
In-Reply-To: <1284586638.14.0.366528605834.issue9865@psf.upfronthosting.co.za>
Message-ID: <1284586785.3190.76.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > How do you want to "handle this in general"?
> 
> Possibly by adding up __sizeof__'s of base and __dict__ in a generated
> function?  With a special handling of slots ...

I agree that in the general case this would be better, but for
OrderedDict it would still fail to give the right value (OrderedDict
also needs to take into account its internal node objects).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9865>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:41:09 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 15 Sep 2010 21:41:09 +0000
Subject: [issue8077] urlparse
In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za>
Message-ID: <1284586869.93.0.793827878058.issue8077@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: cgi handling of POSTed files is broken -> urlparse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8077>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:41:44 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Sep 2010 21:41:44 +0000
Subject: [issue9863] threading, signals,
	atexit: different execution with different versions
In-Reply-To: <1284577342.31.0.557156421767.issue9863@psf.upfronthosting.co.za>
Message-ID: <1284586904.37.0.878704847303.issue9863@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I can verify that the test case terminates with 2.6.2 and 2.5.1 but does not for 2.6.6, 2.7, and 3.2.

This is indeed almost certainly due to Issue1722344. r75749 moved wait_for_thread_shutdown into Py_Finalize just before the atexit functions are called.  The previous behavior was considered a bug (see discussion at Msg66054 so, by that standard, the test program here is incorrect and the fact that it worked prior to 2.6.2 was an accident.   The test can be fixed trivially of course by setting terminate in close_handler instead of the atexit handler.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9863>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:45:50 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 15 Sep 2010 21:45:50 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1284587150.85.0.264975247563.issue9860@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Please could you remove object files from source tree then try again.

This is invalid issue.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:46:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 21:46:33 +0000
Subject: [issue9866] Inconsistencies in tracing list comprehensions
In-Reply-To: <1284586439.08.0.986395223701.issue9866@psf.upfronthosting.co.za>
Message-ID: <AANLkTinGq0qKH6hVjpgWDet2bahQDH1yOye3LJQLcNmC@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Sep 15, 2010 at 5:33 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
> As I said in #9315, I think this kind of thing (bytecode traces) is an implementation detail; the changes
> in results shouldn't be regarded as breaking compatibility.

In r74132, an attempt was made to rationalize and document line
tracing.  While it is an implementation detail, I don't think people
expect it to be platform dependent in CPython implementation.  "With
computed gotos" was supposed to be a pure optimization.  I find it
very surprising that it changes tracing behavior.

> The only problem I could see would be if a whole line of code would be "forgotten".

This is exactly what my example demonstrates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9866>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:52:49 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Sep 2010 21:52:49 +0000
Subject: [issue9865] OrderedDict doesn't implement __sizeof__
In-Reply-To: <1284585159.01.0.70557172329.issue9865@psf.upfronthosting.co.za>
Message-ID: <1284587569.36.0.234045116839.issue9865@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I have a hard time caring about this.  The main value of sys.getsizeof()
is to enable developers to determine the internal sizes of basic objects on a given build.  IIRC, there was no intention for this to become a requirement for pure python classes.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9865>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:56:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 21:56:13 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284587150.85.0.264975247563.issue9860@psf.upfronthosting.co.za>
Message-ID: <AANLkTikEufiJRK4igva++g7H9cgt-=M8wnK5+GPyAmHq@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Sep 15, 2010 at 5:45 PM, Roumen Petrov <report at bugs.python.org> wrote:
..
> Please could you remove object files from source tree then try again.
>
It looks like you missed my penultimate comment.

> This is invalid issue.

At the very least, Building Python [1] section can be expanded to
cover building outside of the source tree.  Some developers are not
even aware that this is supported.

[1] http://docs.python.org/using/unix.html#building-python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:59:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Sep 2010 21:59:04 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1284587944.25.0.168922446644.issue6884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My feeling was that there was a logic bug in filelist (something explicitly added should not be filtered out by a default exclude pattern), so I?m glad to learn it?s just a regex bug.  I?ll add a test for the add/filter logic just in case.  Thanks a lot for the diagnosis and patch, I will probably commit it on Monday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:59:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Sep 2010 21:59:58 +0000
Subject: [issue6884] Impossible to include file in sdist that starts with
	'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1284587998.09.0.0552928531791.issue6884@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +patch -needs review
resolution:  -> accepted
stage: needs patch -> patch review
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Thu Sep 16 00:26:37 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Sep 2010 22:26:37 +0000
Subject: [issue9863] threading, signals,
	atexit: different execution with different versions
In-Reply-To: <1284577342.31.0.557156421767.issue9863@psf.upfronthosting.co.za>
Message-ID: <1284589597.94.0.115029177543.issue9863@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

A better fix for the program is to mark the test_loop thread as a daemon thread.  As the threading module documentation says, by default threads started from the main thread are non-daemon threads and the "entire Python program exits when no alive non-daemon threads are left."  The test case terminates properly by adding a thread.daemon = True after the threading.Thread call in run().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9863>
_______________________________________

From report at bugs.python.org  Thu Sep 16 01:06:54 2010
From: report at bugs.python.org (Corey Bertram)
Date: Wed, 15 Sep 2010 23:06:54 +0000
Subject: [issue9863] threading, signals,
	atexit: different execution with different versions
In-Reply-To: <1284577342.31.0.557156421767.issue9863@psf.upfronthosting.co.za>
Message-ID: <1284592014.9.0.573482107533.issue9863@psf.upfronthosting.co.za>


Corey Bertram <corey at qr7.com> added the comment:

let me preface this: I'm no expert on how this should be done ect...

The goal here was to specifically not set daemon on the test_loop thread. In an actual app test_loop would perhaps need to shutdown cleanly (save state or what have you). That said, your previous suggestion of moving the setting of terminate to the close handler (or maybe just call shutdown) works, but defeats the whole purpose of using atexit at all.

My understanding is that the main thread has ended execution due to the signal. If the signal handler called shutdown, when the test_loop thread exits, all of the atexit registered functions would execute (in this example it would mean calling the shutdown function twice). It just seems ugly now no matter what.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9863>
_______________________________________

From report at bugs.python.org  Thu Sep 16 01:19:46 2010
From: report at bugs.python.org (Corey Bertram)
Date: Wed, 15 Sep 2010 23:19:46 +0000
Subject: [issue9863] threading, signals,
	atexit: different execution with different versions
In-Reply-To: <1284577342.31.0.557156421767.issue9863@psf.upfronthosting.co.za>
Message-ID: <1284592786.5.0.948453788506.issue9863@psf.upfronthosting.co.za>


Corey Bertram <corey at qr7.com> added the comment:

On second thought, i'll just move forward with this new expected behavior. I understand the design decision and why it was made here in regards to waiting for threads to shutdown before atexit kicks in. My intended use for atexit just no longer works in this particular case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9863>
_______________________________________

From report at bugs.python.org  Thu Sep 16 01:42:31 2010
From: report at bugs.python.org (Ben Smith)
Date: Wed, 15 Sep 2010 23:42:31 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284594151.45.0.738555153356.issue9090@psf.upfronthosting.co.za>


Ben Smith <benjamin.coder.smith at gmail.com> added the comment:

I also see this issue on occasion on windows XP SP 3, using python 2.6.5 to fetch large files via http.

The error is infrequent, but it is happening in my situation without a VM.

----------
nosy: +Ben.Smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Thu Sep 16 01:46:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 23:46:45 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284594405.02.0.79110747493.issue9090@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +exarkun, giampaolo.rodola
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Thu Sep 16 02:02:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Sep 2010 00:02:10 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284595330.47.0.562052968711.issue9090@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It appears that there is a known issue with Windows sockets where this 
> type of problem may occur with non-blocking sockets. It is described in 
> the msdn documentation for WSAAsyncSelect()
> (http://msdn.microsoft.com/en-us/library/ms741540%28VS.85%29.aspx).

That documentation doesn't seem to describe the same kind of situation; it is about delayed notification through Windows messages (if you read the sequence they given in example, it's quite logical why it can fail).

Have you tried instrumenting sock_recv_guts() and dumping the actual return values and errnos (from both internal_select() and recv())?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Thu Sep 16 02:36:24 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 16 Sep 2010 00:36:24 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284597384.98.0.317881416858.issue9315@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with finishing this and opening a separate issue with respect to list comp behavior. The latter seems peripheral to the purpose of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Thu Sep 16 02:39:53 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 16 Sep 2010 00:39:53 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1284597593.52.0.119762148008.issue9858@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> Hmm, none the less other code expects it.

Does that imply that there's some code that will break on FileIO objects that are created using a file descriptor instead of a filename?  If so, where?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Thu Sep 16 02:53:31 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Sep 2010 00:53:31 +0000
Subject: [issue9865] OrderedDict doesn't implement __sizeof__
In-Reply-To: <1284585159.01.0.70557172329.issue9865@psf.upfronthosting.co.za>
Message-ID: <1284598411.59.0.810577432722.issue9865@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
keywords: +patch
stage:  -> patch review
type: behavior -> feature request
Added file: http://bugs.python.org/file18896/od_size.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9865>
_______________________________________

From report at bugs.python.org  Thu Sep 16 02:53:38 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 16 Sep 2010 00:53:38 +0000
Subject: [issue9858] Python and C implementations of io are out of sync
In-Reply-To: <1284597593.52.0.119762148008.issue9858@psf.upfronthosting.co.za>
Message-ID: <AANLkTinMkXrdGJ601GnfFy=rcmV9izmaqNUhirLi3Z5Q@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/9/15 Daniel Stutzbach <report at bugs.python.org>:
>
> Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:
>
>> Hmm, none the less other code expects it.
>
> Does that imply that there's some code that will break on FileIO objects that are created using a file descriptor instead of a filename? ?If so, where?

No, just that all code that access name expects an AttributeError,
indicating that when there is no "name" an error should result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Thu Sep 16 03:53:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Sep 2010 01:53:24 +0000
Subject: [issue9863] threading, signals,
	atexit: different execution with different versions
In-Reply-To: <1284577342.31.0.557156421767.issue9863@psf.upfronthosting.co.za>
Message-ID: <1284602004.07.0.940338356294.issue9863@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm closing this as invalid, but I note that this kind of behavior change is not something we would normally have done in a point release if we had realized the consequences.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9863>
_______________________________________

From report at bugs.python.org  Thu Sep 16 04:02:58 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 16 Sep 2010 02:02:58 +0000
Subject: [issue9867] Interrupted system calls are not retried on OS X
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

Currently Python does not check fread and other IO calls for EINTR.  This usually is not an issue, but on OS X a continued program will be sent an SIGCONT signal which causes fread to be interrupted.

Testcase:

mitsuhiko at nausicaa:~$ python2.7
Python 2.7 (r27:82508, Jul  3 2010, 21:12:11) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from signal import SIGCONT, signal
>>> def show_signal(*args):
...  print 'Got SIGCONT'
...  
>>> signal(SIGCONT, show_signal)
0
>>> import sys
>>> sys.stdin.read()
^Z
[1]+  Stopped                 python2.7
mitsuhiko at nausicaa:~$ fg
python2.7
Got SIGCONT
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 4] Interrupted system call
>>> 

Expected behavior: on fg it should continue to read.  The solution would be to loop all calls to fread and friends until errno is no longer EINTR.  Now the question is how to best do that.  I can't think of a portable way to define a macro that continues to run an expression until errno is EINTR, maybe someone else has an idea.

Otherwise it would be possible to just put the loops by hand around each fread/fgetc etc. call, but that would make the code quite a bit more ugly.

Technically I suppose the problem applies to all platforms, on OS X it's just easier to trigger.

----------
messages: 116504
nosy: aronacher
priority: normal
severity: normal
status: open
title: Interrupted system calls are not retried on OS X
type: behavior
versions: Python 2.5, 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/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 04:42:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Sep 2010 02:42:41 +0000
Subject: [issue8077] cgi handling of POSTed files is broken
In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za>
Message-ID: <1284604961.69.0.933221179243.issue8077@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray
title: urlparse -> cgi handling of POSTed files is broken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8077>
_______________________________________

From report at bugs.python.org  Thu Sep 16 05:09:58 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Sep 2010 03:09:58 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284606598.47.0.462491706864.issue9867@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The test fails exactly the same way using a python 2.6.6 on a current Debian (testing) Linux 2.6.32 so I think it better to remove the OS X from the title.  Also the versions field refers to where a potential fix might be applied; that rules out 2.5 and 2.6 since it is not a security problem.

I was also curious if calling signal.siginterrupt for SIGCONT had any effect on this.  Neither False nor True on either OS X or linux seemed to change the behavior.

----------
nosy: +ned.deily
title: Interrupted system calls are not retried on OS X -> Interrupted system calls are not retried
versions:  -Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 05:21:09 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Sep 2010 03:21:09 +0000
Subject: [issue9868] test_locale leaves locale changed
In-Reply-To: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>
Message-ID: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I noticed test_locale leaves locale changed.

# test_boo is simple test just to print windows error.

E:\python-dev\py3k\Lib\test>py3k -m test.regrtest test_locale test_boo
[1/2] test_locale
[2/2] test_boo
test test_boo failed -- Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\regrtest.py", line 941, in runtest_inner
    indirect_test()
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 14, in test_main
    support.run_unittest(TestCase)
  File "e:\python-dev\py3k\lib\test\support.py", line 1128, in run_unittest
    _run_suite(suite)
  File "e:\python-dev\py3k\lib\test\support.py", line 1111, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'
test.support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'

During handling of the above exception, another exception occurred:

test test_boo failed -- Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'
test.support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'

During handling of the above exception, another exception occurred:

Exception IOError: 'raw write() returned invalid length 253 (should have been be
tween 0 and 252)' in <_io.TextIOWrapper name='<stdout>' encoding='cp932'> ignore
d
test.support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'

During handling of the above exception, another exception occurred:

Exception IOError: 'raw write() returned invalid length 253 (should have been be
tween 0 and 252)' in <_io.TextIOWrapper name='<stdout>' encoding='cp932'> ignore
d
[79459 refs]

/////////////////////////////////////////////////
// test_boo.py

from test import support
import unittest
import os

TMPDIR = os.path.join(os.path.dirname(os.path.abspath(__file__)), "__notexist__")

class TestCase(unittest.TestCase):
    def test(self):
        os.rmdir(TMPDIR)

def test_main():
    support.run_unittest(TestCase)

if __name__ == '__main__':
    test_main()

----------
components: Tests
messages: 116506
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_locale leaves locale changed
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9868>
_______________________________________

From report at bugs.python.org  Thu Sep 16 06:11:40 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Sep 2010 04:11:40 +0000
Subject: [issue9868] test_locale leaves locale changed
In-Reply-To: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>
Message-ID: <1284610300.8.0.648288785811.issue9868@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This happens because in Lib/test/test_locale.py,
TestEnUSCollation#setUp raises exception after
BaseLocalizedTest.setUp(self) changed locale.
tearDown never be called when setUp failedsetUp failed.

It's easy to fix this as is, but I think more general
solution would be better.

How about the mechanism like this? It calls setUp() and
tearDown() in according to MRO, if setUp() fails somewhere
in the chain, calls tearDown() for the class whose setUp()
is successfully called. (Be care, you shouldn't call
parent's setUp() or tearDown() directly)

////////////////////
// mockup

import unittest

class TestCase2(unittest.TestCase):
    def setUp(self):
        klasses = []
        try:
            for klass in reversed(self.__class__.__mro__):
                func = getattr(klass, "setUp2", None)
                if func is not None:
                    func(self)
                    klasses.append(klass)
        except:
            for klass in reversed(klasses):
                func = getattr(klass, "tearDown2", None)
                if func is not None:
                    func(self)
            raise
    def tearDown(self):
        for klass in self.__class__.__mro__:
            func = getattr(klass, "tearDown2", None)
            if func is not None:
                func(self)

class A(TestCase2):
    def setUp2(self):
        print("A#setUp2")
    def tearDown2(self):
        print("A#tearDown2")

class B(A):
    def setUp2(self):
        print("B#setUp2")
        raise RuntimeError("B#setUp2 failed")
    def tearDown2(self):
        print("B#tearDown2")
    def test(self):
        pass

if __name__ == '__main__':
    unittest.main()

////////////////////////////////
// result

A#setUp2
B#setUp2
A#tearDown2
(snip)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9868>
_______________________________________

From report at bugs.python.org  Thu Sep 16 06:15:54 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Sep 2010 04:15:54 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remove dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1284610554.78.0.130113184088.issue9815@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is the simple test case to demonstrate this issue.

----------
Added file: http://bugs.python.org/file18897/test_traceback_freed.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Thu Sep 16 06:19:00 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Sep 2010 04:19:00 +0000
Subject: [issue9810] bzip2 build sometimes fails (VS8.0)
In-Reply-To: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>
Message-ID: <1284610740.36.0.416746057063.issue9810@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you for the reply. I agree with you. I'll try to
create latter option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9810>
_______________________________________

From report at bugs.python.org  Thu Sep 16 06:21:40 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Sep 2010 04:21:40 +0000
Subject: [issue9810] bzip2 build sometimes fails (VS8.0)
In-Reply-To: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>
Message-ID: <1284610900.91.0.675829519307.issue9810@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

- create latter option
+ create the patch by latter option

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9810>
_______________________________________

From report at bugs.python.org  Thu Sep 16 08:08:55 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Sep 2010 06:08:55 +0000
Subject: [issue9810] bzip2 build sometimes fails (VS8.0)
In-Reply-To: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>
Message-ID: <1284617335.87.0.636789889879.issue9810@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Probably this patch works.

P.S.
These lines in PCBuild/vs9to8.py seem to be not needed. I could
build python even without it, (I only tried py3k)

  # Bah. VS8.0 does not expand macros in file names.
  # Replace them here.
  lines = lines.replace('$(sqlite3Dir)', '..\\..\\..\\sqlite-3.6.21')

I'm not sure, maybe VS8 SP1's bug? I tried on this.

  Microsoft Visual Studio 2005
  Version 8.0.50727.42  (RTM.050727-4200)

----------
keywords: +patch
Added file: http://bugs.python.org/file18898/py3k_bz2_vcproj.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9810>
_______________________________________

From report at bugs.python.org  Thu Sep 16 08:59:02 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Thu, 16 Sep 2010 06:59:02 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1284620342.58.0.542981849704.issue8746@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

*NOUNLINK was not implemented by OSX, so there's actually a bug with the compile tests if you take that into consideration. And again, only FreeBSD defines *NOUNLINK. The other BSDs, not so much.

As far as the reason why I implemented the flags, the documentation that I was looking at didn't implement those flags. I looked at the latest documentation and it appears to be correct though. I will implement tests for *UNLINK and *HIDDEN (FWIW the tests I wrote are ok for cross-compilation because they just test for the existence of the values -- they don't test to ensure that the functionality is correct, like some of the logic in configure was recently `fixed' to do).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Thu Sep 16 08:59:59 2010
From: report at bugs.python.org (hume)
Date: Thu, 16 Sep 2010 06:59:59 +0000
Subject: [issue9851] multiprocessing socket timeout will break client
In-Reply-To: <1284452922.14.0.631964759206.issue9851@psf.upfronthosting.co.za>
Message-ID: <1284620399.21.0.850197541046.issue9851@psf.upfronthosting.co.za>


hume <humeafo at gmail.com> added the comment:

Oh, it's obvious that you've found a stupid bug in my description, if that frustrate you, I'd like to say sorry. 

So I would restate: "this is not so user friendly, would you be kindly enough to fix it?"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9851>
_______________________________________

From report at bugs.python.org  Thu Sep 16 09:51:51 2010
From: report at bugs.python.org (Carl Witty)
Date: Thu, 16 Sep 2010 07:51:51 +0000
Subject: [issue9869] long_subtype_new segfault in pure-Python code
In-Reply-To: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>
Message-ID: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>


New submission from Carl Witty <Carl.Witty at gmail.com>:

PyNumber_Long() (and hence long_new()) are willing to return ints, rather than longs.  However, when long_subtype_new() calls long_new(), it casts the result to PyLongObject* without a check.  (Well, there is an assertion, so if assertions are enabled you'd get an assertion failure instead of a potential segmentation fault.)

The attached program segfaults for me; returning smaller numbers than 1000000 sometimes gives bad answers instead of crashing.

----------
components: Interpreter Core
files: python_long_bug.py
messages: 116514
nosy: cwitty
priority: normal
severity: normal
status: open
title: long_subtype_new segfault in pure-Python code
type: crash
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file18899/python_long_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9869>
_______________________________________

From report at bugs.python.org  Thu Sep 16 10:11:26 2010
From: report at bugs.python.org (Sergey)
Date: Thu, 16 Sep 2010 08:11:26 +0000
Subject: [issue9870] compile and nested scopes
In-Reply-To: <1284624686.57.0.761868003126.issue9870@psf.upfronthosting.co.za>
Message-ID: <1284624686.57.0.761868003126.issue9870@psf.upfronthosting.co.za>


New submission from Sergey <sergey_magaf at mail.ru>:

See attached tmp1.py
It is very simple but it doesn't work
It raises NameError
NameError: global name 'arg' is not defined

----------
components: None
files: tmp1.py
messages: 116515
nosy: webcubator
priority: normal
severity: normal
status: open
title: compile and nested scopes
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18900/tmp1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9870>
_______________________________________

From report at bugs.python.org  Thu Sep 16 10:55:25 2010
From: report at bugs.python.org (Popa Claudiu)
Date: Thu, 16 Sep 2010 08:55:25 +0000
Subject: [issue9871] IDLE dies when using some regex
In-Reply-To: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>
Message-ID: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

Hello.

While trying to find a way for extracting strange characters in an ascii file, I stumbled upon some strange behaviour of IDLE, which exits without warning after running the following regex:

re.findall(b"\x.{2}", b"sdds\xd8")

In Python 2.6, this won't happen. This is my version of Python 3.1:
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35).

----------
components: IDLE
messages: 116516
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: IDLE dies when using some regex
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9871>
_______________________________________

From report at bugs.python.org  Thu Sep 16 11:13:49 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Sep 2010 09:13:49 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
	removed
In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>
Message-ID: <1284628429.94.0.287950973864.issue9850@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Patches in progress.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Thu Sep 16 11:46:52 2010
From: report at bugs.python.org (Marco Mariani)
Date: Thu, 16 Sep 2010 09:46:52 +0000
Subject: [issue8639] Allow callable objects in inspect.getargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1284630412.5.0.16531399015.issue8639@psf.upfronthosting.co.za>


Marco Mariani <birbag at gmail.com> added the comment:

I second this, I depend on this monkeypatch for my turbogears projects, where I use callable objects as error handlers:

    def getargspec(func):
        if getattr(func, '__call__') and not isfunction(func) and not ismethod(func):
            func = func.__call__
        if ismethod(func):
            func = func.im_func
        if not isfunction(func):
            raise TypeError('arg is not a Python function')
        args, varargs, varkw = getargs(func.func_code)
        return args, varargs, varkw, func.func_defaults

but I suppose 2.7 is locked to this change so I propose it for 3.x

----------
nosy: +marco.mariani
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8639>
_______________________________________

From report at bugs.python.org  Thu Sep 16 12:25:11 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 16 Sep 2010 10:25:11 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284632711.13.0.173774954518.issue9867@psf.upfronthosting.co.za>


Changes by Armin Ronacher <armin.ronacher at active-4.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 13:13:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Sep 2010 11:13:14 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1284578956.1.0.465572998402.issue9807@psf.upfronthosting.co.za>
Message-ID: <4C91FBC6.1050103@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> @Martin: yep, I know we still need to install pyconfig.h and
> Makefile, but we shouldn't need to parse them to get programmatic
> access to the data they contain.

Hmm. What do you gain by not parsing them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep 16 13:13:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 16 Sep 2010 11:13:40 +0000
Subject: [issue9869] long_subtype_new segfault in pure-Python code
In-Reply-To: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>
Message-ID: <1284635620.69.0.77822952387.issue9869@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9869>
_______________________________________

From report at bugs.python.org  Thu Sep 16 13:24:10 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Sep 2010 11:24:10 +0000
Subject: [issue678264] test_resource fails when file size is limited
In-Reply-To: <1284580982.98.0.416446600835.issue678264@psf.upfronthosting.co.za>
Message-ID: <4C91FE57.9080102@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> As a point of information, on my gentoo linux system without
> largefile support in the kernel, any value 4294967295 or above
> results in getrlimit reporting -1.  Any smaller value is set and
> reported as itself.  (If a sufficiently large value is passed in to
> setrlimit, an OverflowError results.)

I think we really should create new issues for any remaining problems.

AFAICT, the remaining problems are:
- resource.RLIM_INFINITY is -1 on Linux, when it is meant to be
   a really large value
- (as you reported) getrlimit returns -1 to indicate RLIM_INFINITY.

I think the core of the problem is that the resource module considers
rlim_t to be a signed type (or at least representable in "long long").
Using FromUnsignedLongLong in the appropriate place might solve the
issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678264>
_______________________________________

From report at bugs.python.org  Thu Sep 16 13:28:49 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Sep 2010 11:28:49 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284636529.6.0.839773536558.issue9867@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I fail to see why this is a bug. If the system call is interrupted, why should Python not report that?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 13:35:44 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 16 Sep 2010 11:35:44 +0000
Subject: [issue9662] ctypes not building under OS X because of
	ffi_closure_free not being defined early enough
In-Reply-To: <1282509924.5.0.810083084534.issue9662@psf.upfronthosting.co.za>
Message-ID: <1284636944.32.0.429534481821.issue9662@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

(Finally...) Checked in for 2.7 in r84846

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9662>
_______________________________________

From report at bugs.python.org  Thu Sep 16 13:36:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Sep 2010 11:36:04 +0000
Subject: [issue9810] bzip2 build sometimes fails (VS8.0)
In-Reply-To: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>
Message-ID: <1284636964.22.0.742123173252.issue9810@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I can't test the patch right now, but it looks good to me.

Please check it into py3k to see how the buildbots do. If it seems to work correctly (both for x86 and AMD64), feel free to backport it to 2.7 and 3.1.

As for vs9to8: I can't comment; I don't use older VS versions anymore.
In any case, this looks like an unrelated issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9810>
_______________________________________

From report at bugs.python.org  Thu Sep 16 13:47:40 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 16 Sep 2010 11:47:40 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284637660.64.0.468391575207.issue9867@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

One could argue of course that every user of Python should handle EINTR, but that's something I think should be solved in the IO library because very few people know that one is supposed to restart syscalls on EINTR on POSIX systems.

Ruby for instance handles EINTR properly:

mitsuhiko at nausicaa:~$ ruby -e 'puts $stdin.read.inspect'
^Z
[1]+  Stopped
mitsuhiko at nausicaa:~$ fg
ruby -e 'puts $stdin.read.inspect'
test
"test\n"



So does perl:

mitsuhiko at nausicaa:~$ perl -e 'chomp($x = <STDIN>); print $x'
^Z
[1]+  Stopped
mitsuhiko at nausicaa:~$ fg
perl -e 'chomp($x = <STDIN>); print $x'
test
test

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 13:49:30 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 16 Sep 2010 11:49:30 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284637770.9.0.360354237359.issue9867@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Interestingly even PHP handles that properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 13:58:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Sep 2010 11:58:11 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <4C91FBC6.1050103@v.loewis.de>
Message-ID: <1284638282.3397.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 16 septembre 2010 ? 11:13 +0000, Martin v. L?wis a ?crit :
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> > @Martin: yep, I know we still need to install pyconfig.h and
> > Makefile, but we shouldn't need to parse them to get programmatic
> > access to the data they contain.
> 
> Hmm. What do you gain by not parsing them?

Not having some complicate and brittle code to parse Makefiles would
certainly be a win, IMO.
(the canonical pyconfig.h is arguably much simpler)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep 16 13:58:54 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 16 Sep 2010 11:58:54 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1284638334.0.0.975330662174.issue8445@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Unassigning because the issue affects more than just OSX and I'm not a Tkinter expert.

----------
assignee: ronaldoussoren -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Thu Sep 16 13:59:56 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 16 Sep 2010 11:59:56 +0000
Subject: [issue9701] Update ZSH profile on Mac OS installation
In-Reply-To: <1282914673.78.0.162248680277.issue9701@psf.upfronthosting.co.za>
Message-ID: <1284638396.28.0.906567290465.issue9701@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Thanks for the patch. I will apply this before the next release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9701>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:03:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Sep 2010 12:03:39 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284637660.64.0.468391575207.issue9867@psf.upfronthosting.co.za>
Message-ID: <4C920796.30409@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> One could argue of course that every user of Python should handle
> EINTR, but that's something I think should be solved in the IO
> library because very few people know that one is supposed to restart
> syscalls on EINTR on POSIX systems.
>
> Ruby for instance handles EINTR properly:

Hmm. So under what conditions should it continue, and under what 
conditions should it raise an exception (when errno is EINTR)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:06:01 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 16 Sep 2010 12:06:01 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284638761.25.0.0187783684302.issue9867@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

> Hmm. So under what conditions should it continue, and under what 
> conditions should it raise an exception (when errno is EINTR)?

EINTR indicates a temporary failure.  In that case it should always retry.

A common macro for handling that might look like this:

#define RETRY_ON_EINTR(x) ({ \
  typeof(x) rv; \
  do { rv = x; } while (rv < 0 && errno == EINTR); \
  rv;\
})

But from what I understand, braces in parentheses are a GCC extension.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:07:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Sep 2010 12:07:12 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1284638282.3397.0.camel@localhost.localdomain>
Message-ID: <4C92086A.7030302@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Not having some complicate and brittle code to parse Makefiles would
> certainly be a win, IMO.

Not sure how the patch would look like, but I would expect that any
patch to build a module to include Makefile settings makes it *less*
robust: every time you add or remove a Makefile variable, you have to
remember to adjust the module as well. Currently, you can access 
arbitrary Makefile variables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:13:10 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 16 Sep 2010 12:13:10 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284638761.25.0.0187783684302.issue9867@psf.upfronthosting.co.za>
Message-ID: <4C9209D3.7050903@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 16.09.10 14:06, schrieb Armin Ronacher:
>
> Armin Ronacher<armin.ronacher at active-4.com>  added the comment:
>
>> Hmm. So under what conditions should it continue, and under what
>> conditions should it raise an exception (when errno is EINTR)?
>
> EINTR indicates a temporary failure.  In that case it should always retry.

But Ruby doesn't. If you send SIGINT, it will print

-e:1:in `read': Interrupt
	from -e:1

If you send SIGHUP, it will print

Hangup

So it is surely more complex than "always retry".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:15:08 2010
From: report at bugs.python.org (Michael Fladischer)
Date: Thu, 16 Sep 2010 12:15:08 +0000
Subject: [issue9162] License for multiprocessing files
In-Reply-To: <1278311687.0.0.315948028382.issue9162@psf.upfronthosting.co.za>
Message-ID: <1284639308.51.0.783580048957.issue9162@psf.upfronthosting.co.za>


Michael Fladischer <michael at fladi.at> added the comment:

Is there any timeline on when this will be fixed? It's currently blocking work on a python-related package for Debian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9162>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:18:59 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 16 Sep 2010 12:18:59 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284639539.66.0.971883787114.issue9867@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Wouldn't retrying on EINTR cause havoc when you try to interrupt a process?

That is: what would happen with the proposed patch when a python script does a read that takes a very long time and the user tries to interrupt the script (by using Ctrl+C to send a SIGTERM)?

If I my understanding of is correct the patch will ensure that the process does not get interupted because the default SIGTERM handler just sets a flag that's periodicly checked in the python interpreter loop.  With the proposed patch python would not get around to checking that flag until the I/O operation is finished.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:28:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Sep 2010 12:28:10 +0000
Subject: [issue9865] OrderedDict doesn't implement __sizeof__
In-Reply-To: <1284585159.01.0.70557172329.issue9865@psf.upfronthosting.co.za>
Message-ID: <1284640090.94.0.961383788631.issue9865@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9865>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:28:13 2010
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 16 Sep 2010 12:28:13 +0000
Subject: [issue9872] `a.b.my_function is not b.my_function` when `a` and `b`
	are both on `sys.path`
In-Reply-To: <1284640093.44.0.797706221833.issue9872@psf.upfronthosting.co.za>
Message-ID: <1284640093.44.0.797706221833.issue9872@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

Let's say you have this structure:

a\
  __init__.py
  b\
    __init__.py

In `b.__init__` a function called `my_function` is defined.

And assume that `a` and `b` are both on `sys.path`. Then this situation happens:

    >>> import a.b
    >>> import b
    >>> a.b.my_function is b.my_function
    False
    >>> a.b.my_function
    <function my_function at 0x00BC70C0>
    >>> b.my_function
    <function my_function at 0x00BC7108>
    >>> a.b.my_function.__module__
    'a.b'
    >>> b.my_function.__module__
    'b'

It seems that `a.b.my_function` and `b.my_function` are different objects.

----------
messages: 116536
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `a.b.my_function is not b.my_function` when `a` and `b` are both on `sys.path`
type: behavior
versions: Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9872>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:29:53 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 16 Sep 2010 12:29:53 +0000
Subject: [issue9872] `a.b.my_function is not b.my_function` when `a` and `b`
	are both on `sys.path`
In-Reply-To: <1284640093.44.0.797706221833.issue9872@psf.upfronthosting.co.za>
Message-ID: <1284640193.62.0.0882236010052.issue9872@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

And indeed that's expected. Don't do that.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9872>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:34:05 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 16 Sep 2010 12:34:05 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284640445.49.0.754017666834.issue9867@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

The following minimal C code shows how EINTR can be handled:

#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <signal.h>

#define BUFFER_SIZE 1024


int
main()
{
    char buffer[BUFFER_SIZE];
    printf("PID = %d\n", getpid());
    while (1) {
        int rv = fgetc(stdin);
        if (rv < 0) {
            if (feof(stdin))
                break;
            if (errno == EINTR)
                continue;
            printf("Call failed with %d\n", errno);
            return 1;
        }
        else
            fputc(rv, stdout);
    }
    return 0;
}



Test application:

mitsuhiko at nausicaa:/tmp$ ./a.out 
PID = 22806
Terminated
mitsuhiko at nausicaa:/tmp$ ./a.out 
PID = 22809

mitsuhiko at nausicaa:/tmp$ ./a.out 
PID = 22812
^Z
[2]+  Stopped                 ./a.out
mitsuhiko at nausicaa:/tmp$ fg
./a.out
test
test
foo
foo

First signal sent was TERM, second was INT.  Last case was sending to background, receiving the ignored SIGCONT signal, fgetc returning -1 and fgetc being called again because of errno being EINTR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:36:50 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 16 Sep 2010 12:36:50 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284640610.68.0.456949284144.issue9867@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

> Wouldn't retrying on EINTR cause havoc when you try to interrupt a process?

All your C applications are doing it, why should Python cause havok there?  Check the POSIX specification on that if you don't trust me.

> That is: what would happen with the proposed patch when a python script
> does a read that takes a very long time and the user tries to interrupt 
> the script (by using Ctrl+C to send a SIGTERM)?
EINTR is only returned if nothing was read so far and the call was interrupted in case of fread.

Here a quick explanation from the GNU's libc manual:
http://www.gnu.org/s/libc/manual/html_node/Interrupted-Primitives.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:38:43 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 16 Sep 2010 12:38:43 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284640723.99.0.661462476435.issue9867@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

There is a funny story related to that though :)

"BSD avoids EINTR entirely and provides a more convenient approach:
 to restart the interrupted primitive, instead of making it fail."

BSD does, but the Mach/XNU kernel combo on OS X is not.  Which is why all the shipped BSD tools have that bug, but if you run their GNU equivalents on OS X everything work as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:55:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Sep 2010 12:55:25 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284641725.84.0.788497356399.issue9867@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some parts of the stdlib already retry manually (such as SocketIO, subprocess, multiprocessing, socket.sendall), so it doesn't sound unreasonable for the IO lib to retry too.

There are/were other people complaining in similar cases: #7978, #1628205.

----------
nosy: +benjamin.peterson, exarkun, pitrou, stutzbach
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:21:01 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Thu, 16 Sep 2010 13:21:01 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284643261.12.0.689187267265.issue9867@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:22:06 2010
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 16 Sep 2010 13:22:06 +0000
Subject: [issue9162] License for multiprocessing files
In-Reply-To: <1284639308.51.0.783580048957.issue9162@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=2AdmpTWpp62cgOpL+TWQ2YFZYocA4MR0Dy74n@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Thu, Sep 16, 2010 at 8:15 AM, Michael Fladischer
<report at bugs.python.org> wrote:
>
> Michael Fladischer <michael at fladi.at> added the comment:
>
> Is there any timeline on when this will be fixed? It's currently blocking work on a python-related package for Debian.
>

I'll ping the PSF board for the legal recommendations again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9162>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:25:14 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Sep 2010 13:25:14 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As per python-dev discussion in June, many Py3k APIs currently gratuitously prevent the use of bytes and bytearray objects as arguments due to their use of string literals internally.

Examples:
urllib.parse.urlparse
urllib.parse.urlunparse
urllib.parse.urljoin
urllib.parse.urlsplit
(and plenty of other examples in urllib.parse)

While a strict reading of the relevant RFCs suggests that strings are the more appropriate type for these APIs, as a practical matter, protocol developers want to be able to operate on ASCII supersets as raw bytes.

The proposal is to modify the implementation of these functions such that string literals are used only with string arguments, and bytes literals otherwise. If a function accepts multiple values and a mixture of strings and bytes is passed in then the operation will still fail (as it should).

----------
assignee: ncoghlan
components: Library (Lib)
messages: 116543
nosy: ncoghlan
priority: high
severity: normal
stage: needs patch
status: open
title: Allow bytes in some APIs that use string literals internally
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:27:58 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 16 Sep 2010 13:27:58 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284640610.68.0.456949284144.issue9867@psf.upfronthosting.co.za>
Message-ID: <C1B8367C-D4D8-4F2E-A233-8252D374D407@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 16 Sep, 2010, at 14:36, Armin Ronacher wrote:

> 
> Armin Ronacher <armin.ronacher at active-4.com> added the comment:
> 
>> Wouldn't retrying on EINTR cause havoc when you try to interrupt a process?
> 
> All your C applications are doing it, why should Python cause havok there?  Check the POSIX specification on that if you don't trust me.
> 
>> That is: what would happen with the proposed patch when a python script
>> does a read that takes a very long time and the user tries to interrupt 
>> the script (by using Ctrl+C to send a SIGTERM)?
> EINTR is only returned if nothing was read so far and the call was interrupted in case of fread.
> 
> Here a quick explanation from the GNU's libc manual:
> http://www.gnu.org/s/libc/manual/html_node/Interrupted-Primitives.html

You conveniently didn't quote the part of my message where I explained why I think there may be a problem.

CPython's signal handlers just set a global flag to indicate that a signal occurred and run the actual signal handler later on from the main interpreter loop, see signal_handler in Modules/signal.c and intcatcher in Parser/intrcheck.c.  

The latter contains the default handler for SIGINT and that already contains code that deals with SIGINT not having any effect (when you sent SIGINT twice in a row without CPython running pending calls the interpreter gets aborted). 

Because Python's signal handlers only set a flag and do the actual action later on blindly rerunning system calls when errno == EINTR may result in programs that don't seem to react to signals at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:29:17 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 16 Sep 2010 13:29:17 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284640723.99.0.661462476435.issue9867@psf.upfronthosting.co.za>
Message-ID: <A4316CDD-917A-401A-87E1-5813BDD50ED4@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 16 Sep, 2010, at 14:38, Armin Ronacher wrote:

> 
> Armin Ronacher <armin.ronacher at active-4.com> added the comment:
> 
> There is a funny story related to that though :)
> 
> "BSD avoids EINTR entirely and provides a more convenient approach:
> to restart the interrupted primitive, instead of making it fail."
> 
> BSD does, but the Mach/XNU kernel combo on OS X is not.  Which is why all the shipped BSD tools have that bug, but if you run their GNU equivalents on OS X everything work as expected.

setting the SA_RESTART in the call to sigaction should work (on OSX HAVE_SIGACTION is defined), unless the manpage is lying.

Ronald

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:33:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Sep 2010 13:33:25 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <C1B8367C-D4D8-4F2E-A233-8252D374D407@mac.com>
Message-ID: <1284643999.3397.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Because Python's signal handlers only set a flag and do the actual
> action later on blindly rerunning system calls when errno == EINTR may
> result in programs that don't seem to react to signals at all.

You just need to call PyErr_CheckSignals() and check its result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:36:03 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 16 Sep 2010 13:36:03 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284644163.96.0.562275197739.issue9867@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

> setting the SA_RESTART in the call to sigaction should work (on OSX HAVE_SIGACTION is defined), unless the manpage is lying.

It should work, haven't tried.  From what I understand on a BSD system, retrying is the default.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:40:24 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 16 Sep 2010 13:40:24 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284644424.5.0.0359780094256.issue9867@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

> You conveniently didn't quote the part of my message where I explained 
> why I think there may be a problem.
I understand that, but there are already cases in Python where EINTR is handled properly.  In fact, quoting socketmodule.c:

    if (res == EINTR && PyErr_CheckSignals())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:42:05 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 16 Sep 2010 13:42:05 +0000
Subject: [issue9867] Interrupted system calls are not retried
In-Reply-To: <1284644424.5.0.0359780094256.issue9867@psf.upfronthosting.co.za>
Message-ID: <96648CB3-9E86-43C9-9232-52138E19F73C@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 16 Sep, 2010, at 15:40, Armin Ronacher wrote:

> 
> Armin Ronacher <armin.ronacher at active-4.com> added the comment:
> 
>> You conveniently didn't quote the part of my message where I explained 
>> why I think there may be a problem.
> I understand that, but there are already cases in Python where EINTR is handled properly.  In fact, quoting socketmodule.c:
> 
>    if (res == EINTR && PyErr_CheckSignals())

This looks fine.

Ronald

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:53:18 2010
From: report at bugs.python.org (Raphael Mankin)
Date: Thu, 16 Sep 2010 13:53:18 +0000
Subject: [issue9874] Message.attach() loses empty attachments
In-Reply-To: <1284645198.43.0.725761534678.issue9874@psf.upfronthosting.co.za>
Message-ID: <1284645198.43.0.725761534678.issue9874@psf.upfronthosting.co.za>


New submission from Raphael Mankin <raph at mankin.org.uk>:

When attaching a sequence of parts to a MIMEMultipart message, empty attachments are silently discarded.

----------
components: Library (Lib)
messages: 116550
nosy: raph at mankin.org.uk
priority: normal
severity: normal
status: open
title: Message.attach() loses empty attachments
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9874>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:58:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Sep 2010 13:58:28 +0000
Subject: [issue9874] Message.attach() loses empty attachments
In-Reply-To: <1284645198.43.0.725761534678.issue9874@psf.upfronthosting.co.za>
Message-ID: <1284645508.83.0.213505957617.issue9874@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Can you provide a simple example program that demonstrates the problem?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9874>
_______________________________________

From report at bugs.python.org  Thu Sep 16 16:01:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Sep 2010 14:01:58 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1284645718.84.0.974638080942.issue9873@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 16 16:08:18 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 16 Sep 2010 14:08:18 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1284646098.93.0.0712813715887.issue9873@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 16 16:19:52 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 16 Sep 2010 14:19:52 +0000
Subject: [issue9875] Garbage output when running setup.py on Windows
In-Reply-To: <1284646791.69.0.38074502633.issue9875@psf.upfronthosting.co.za>
Message-ID: <1284646791.69.0.38074502633.issue9875@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

The output of setup.py is polluted with this log message:

  Importing new compiler from distutils.msvc9compiler

on Windows.  For example, using pyOpenSSL's setup.py, running "setup.py --version" produces this output:

  Importing new compiler from distutils.msvc9compiler
  0.10

But the version number of pyOpenSSL is "0.10", not "Importing new compiler from distutils.msvc9compiler\n0.10".

The --quiet flag does not solve this problem, apparently because this log message is done at the top-level of msvccompiler.py, perhaps before --quiet is interpreted.

This interferes with my build automation which depends on "setup.py --version" producing the version number of the project in order to properly compute certain filenames.

----------
assignee: tarek
components: Distutils
messages: 116552
nosy: eric.araujo, exarkun, tarek
priority: normal
severity: normal
status: open
title: Garbage output when running setup.py on Windows
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9875>
_______________________________________

From report at bugs.python.org  Thu Sep 16 16:29:15 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 16 Sep 2010 14:29:15 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284647355.25.0.569932005678.issue9090@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Actually, it's possible that select(2) incorrectly reports sockets as ready for reading : for example if the socket receives data, but then discards it because of an invalid checksum (and I guess you're more likely to get this type of problem on a VM or while copying large files).

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Thu Sep 16 16:36:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Sep 2010 14:36:53 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284647813.84.0.638291358387.issue9090@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So it means we should indeed retry on a socket with timeout... But we must take care not to exceed the original timeout, so we must measure the time taken by each select() call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Thu Sep 16 16:37:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Sep 2010 14:37:00 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284647820.7.0.869917173407.issue9807@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've only been on the periphery of the distutils/makefile discussion, but I thought the goal was to *autogenerate* a module containing the relevant information at python build time, instead of (as now) parsing the makefile at run time.  Whether or not this autogeneration involves or does not involve parsing the makefile at python build time is an orthogonal issue.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep 16 16:44:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 16 Sep 2010 14:44:56 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284648296.1.0.435155461009.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

See issue #9866 for follow ups on list comprehensions' tracing.

----------
nosy:  -Alexander.Belopolsky
status: open -> closed
superseder:  -> Inconsistencies in tracing list comprehensions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Thu Sep 16 16:46:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 16 Sep 2010 14:46:07 +0000
Subject: [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1284648367.58.0.921154015858.issue9315@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

List comprehension test is removed from 3.1 in r84848.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________

From report at bugs.python.org  Thu Sep 16 17:06:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 16 Sep 2010 15:06:45 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1284649605.21.0.918075902239.issue9264@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> So I'm open to ideas and am willing to submit improved patches for 3.2

I offered some ideas in my last message.  In addition, I would like to see profile and trace documentation to converge to similar structure and use similar terminology.  In particular, I don't like "Run *cmd* under control of the Trace object" because Trace is not a debugger and does not "control" the execution.  I think the explanation at http://docs.python.org/dev/py3k/library/profile.html#cProfile.run is better.  On the other hand, I like "Programming Interface" as the title of the API section better than "Reference Manual" in profile docs.  I hope we can change both trace and profile sections and retain the best choices.

----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Thu Sep 16 17:14:31 2010
From: report at bugs.python.org (Raphael Mankin)
Date: Thu, 16 Sep 2010 15:14:31 +0000
Subject: [issue9874] Message.attach() loses empty attachments
In-Reply-To: <1284645508.83.0.213505957617.issue9874@psf.upfronthosting.co.za>
Message-ID: <e0692dfbb29295e933a0bc1554be9775.squirrel@mail.mankin.org.uk>


Raphael Mankin <raph at mankin.org.uk> added the comment:

'Simple' is the problem. I will come back to you on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9874>
_______________________________________

From report at bugs.python.org  Thu Sep 16 17:17:33 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 15:17:33 +0000
Subject: [issue416670] MatchObjects not deepcopy()able
Message-ID: <1284650253.52.0.750585975387.issue416670@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg113202.

----------
nosy: +BreamoreBoy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue416670>
_______________________________________

From report at bugs.python.org  Thu Sep 16 17:26:58 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 15:26:58 +0000
Subject: [issue460474] codecs.StreamWriter: reset() on close()
Message-ID: <1284650818.38.0.00685324927653.issue460474@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg114140.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue460474>
_______________________________________

From report at bugs.python.org  Thu Sep 16 17:33:45 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 16 Sep 2010 15:33:45 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now
	"10.3"	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1284651225.56.0.944116697993.issue9516@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've attached a patch for 3.2 that should fix the issue. 

The patch adds a couple of testcases (1 for sysconfig and 1 for distutils.command.build_ext), adjust a couple more and implements the following functional changes:

1) sysconfig._init_posix no longer does anything with 
   MACOSX_DEPLOYMENT_TARGET in the environment

2) sysconfig.get_platform always uses MACOSX_DEPLOYMENT_TARGET from 
   the Makefile and ignores the setting from the environment
   (in hindsight looking at the environment was wrong, particularly 
   because that also affects the name of bdist_* files and that can
   confuse tools like distutils)

3) distutils.util.get_platform was changed in the same way and for
   the same reason.

4) distutils.sysconfig._init_posix does still look at 
   MACOSX_DEPLOYMENT_TARGET but changes the environment by updating
   os.environ instead of calling os.putenv. The latter is very 
   confusing when you're debugging environment issues.

I'm not 100% sure about the (lack of) change to distutils.sysconfig._init_posix. It might be better to just always use the deployment target that was specified during the build of python itself.

There is a use-case for overriding the deployment target though: locally build an extension that you use on your machine and that uses compiler/library features that require a newer deployment target than the one used to build python itself.

----------
keywords: +patch
Added file: http://bugs.python.org/file18901/issue9516.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Thu Sep 16 17:46:13 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 15:46:13 +0000
Subject: [issue923697] SAX2 'property_encoding' feature not supported
Message-ID: <1284651973.46.0.892251667423.issue923697@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

The URL referenced in msg54124 gives a 404.  It is also used as the property_encoding in the sax handler module.  Could this be fixed in 3.2 or can this issue be closed?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue923697>
_______________________________________

From report at bugs.python.org  Thu Sep 16 17:49:15 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 15:49:15 +0000
Subject: [issue1648923] HP-UX: -lcurses missing for readline.so
Message-ID: <1284652155.58.0.731221727198.issue1648923@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I can't believe that a build issue raised almost 4 years ago against 2.5 is still an issue today.

----------
nosy: +BreamoreBoy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1648923>
_______________________________________

From report at bugs.python.org  Thu Sep 16 17:58:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Sep 2010 15:58:08 +0000
Subject: [issue416670] MatchObjects not deepcopy()able
Message-ID: <1284652688.63.0.933951076823.issue416670@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue416670>
_______________________________________

From report at bugs.python.org  Thu Sep 16 17:59:35 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 15:59:35 +0000
Subject: [issue1178] IDLE - add "paste code" functionality
In-Reply-To: <1190153010.77.0.038299898053.issue1178@psf.upfronthosting.co.za>
Message-ID: <1284652775.21.0.963966752532.issue1178@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

This has already been implemented.

----------
nosy: +BreamoreBoy
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1178>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:06:10 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 16:06:10 +0000
Subject: [issue3020] doctest should have lib2to3 integration
In-Reply-To: <1212331047.91.0.677781535819.issue3020@psf.upfronthosting.co.za>
Message-ID: <1284653170.7.0.625695050953.issue3020@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this still valid, can it be closed as out of date or what?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3020>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:08:16 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 16:08:16 +0000
Subject: [issue3030] compiler warning on HP-UX
In-Reply-To: <1212472557.24.0.226147292753.issue3030@psf.upfronthosting.co.za>
Message-ID: <1284653296.54.0.00347569805206.issue3030@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I can't believe that a build issue relating to 2.6 is still valid over two years later.

----------
nosy: +BreamoreBoy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3030>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:12:48 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 16:12:48 +0000
Subject: [issue4837] Omits MACHINE and DEBUG when building tix8.4.3
In-Reply-To: <1231099614.05.0.848880488218.issue4837@psf.upfronthosting.co.za>
Message-ID: <1284653568.7.0.89156717166.issue4837@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is the attached patch still valid?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4837>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:13:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Sep 2010 16:13:05 +0000
Subject: [issue9874] Message.attach() loses empty attachments
In-Reply-To: <1284645198.43.0.725761534678.issue9874@psf.upfronthosting.co.za>
Message-ID: <1284653585.97.0.210571656886.issue9874@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Got your off-ticket email.  I was hoping for something that *just* demonstrated the problem (just enough code to show the issue).  It may be a bit before I can find the time to reduce your code to such a test case.

----------
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9874>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:17:21 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 16:17:21 +0000
Subject: [issue5033] setup.py crashes if sqlite version contains 'beta'
In-Reply-To: <1232641406.0.0.500689225697.issue5033@psf.upfronthosting.co.za>
Message-ID: <1284653841.71.0.371134906694.issue5033@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

A one line fix is given in msg80370, can this be applied,should the issue be closed or what?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5033>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:18:40 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 16:18:40 +0000
Subject: [issue5309] setup.py doesn't parallelize extension module compilation
In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za>
Message-ID: <1284653920.29.0.0181129987456.issue5309@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
components: +Distutils2 -Distutils
nosy: +eric.araujo
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5309>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:22:26 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 16:22:26 +0000
Subject: [issue5629] PEP 0 date and revision not being set
In-Reply-To: <1238519928.09.0.287279544516.issue5629@psf.upfronthosting.co.za>
Message-ID: <1284654146.36.0.6500306168.issue5629@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I assume that people are still interested in this?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5629>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:27:55 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 16:27:55 +0000
Subject: [issue5667] Interpreter fails to initialize on build dir when IO
	encoding is one of CJK
In-Reply-To: <1238664339.95.0.0471411238024.issue5667@psf.upfronthosting.co.za>
Message-ID: <1284654475.18.0.583103219511.issue5667@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Hum, a low priority interpreter core crash, would anyone like to comment?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5667>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:37:18 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 16:37:18 +0000
Subject: [issue6893] defaultdict example in py3 doc should mention the new
	Counter class
In-Reply-To: <1252724623.36.0.815888015467.issue6893@psf.upfronthosting.co.za>
Message-ID: <1284655038.52.0.80668180142.issue6893@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
assignee: georg.brandl -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6893>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:38:06 2010
From: report at bugs.python.org (Alexander Solovyov)
Date: Thu, 16 Sep 2010 16:38:06 +0000
Subject: [issue9876] ConfigParser can't interpolate values from other sections
In-Reply-To: <1284655085.98.0.131711113127.issue9876@psf.upfronthosting.co.za>
Message-ID: <1284655085.98.0.131711113127.issue9876@psf.upfronthosting.co.za>


New submission from Alexander Solovyov <piranha at piranha.org.ua>:

Often it is useful to access some variable in other section for interpolation needs: for example, parent directory declared in common section could be used in configuration of certain components. Included patch can fix that (using syntax 'section.variable'), is there any chances that it could be applied? :)


--- ConfigParser.old.py	2010-09-16 19:20:27.000000000 +0300
+++ ConfigParser.py	2010-09-16 19:22:33.000000000 +0300
@@ -585,7 +585,7 @@
             if "%(" in value:
                 value = self._KEYCRE.sub(self._interpolation_replace, value)
                 try:
-                    value = value % vars
+                    value = value % _Context(self, section)
                 except KeyError, e:
                     raise InterpolationMissingOptionError(
                         option, section, rawval, e.args[0])
@@ -667,3 +667,15 @@
             raise ValueError("invalid interpolation syntax in %r at "
                              "position %d" % (value, m.start()))
         ConfigParser.set(self, section, option, value)
+
+
+class _Context(object):
+    def __init__(self, config, section):
+        self.config = config
+        self.section = section
+
+    def __getitem__(self, key):
+        if '.' in key:
+            return self.config.get(*key.split('.'))
+        else:
+            return self.config.get(self.section, key)

----------
components: Library (Lib)
messages: 116573
nosy: asolovyov
priority: normal
severity: normal
status: open
title: ConfigParser can't interpolate values from other sections
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9876>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:38:42 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 16:38:42 +0000
Subject: [issue7059] 'checking getaddrinfo bug' doesn't output the result
	during ./configure
In-Reply-To: <1254703921.37.0.174838855875.issue7059@psf.upfronthosting.co.za>
Message-ID: <1284655122.21.0.610834890227.issue7059@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this still a problem on Linux?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7059>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:59:03 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 16:59:03 +0000
Subject: [issue8554] suspicious comment in msilib.py/__init__.py
In-Reply-To: <1272418292.04.0.0208509109493.issue8554@psf.upfronthosting.co.za>
Message-ID: <1284656343.17.0.548931532808.issue8554@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

The line in question has been like that since r42847 i.e. when the file came into existence.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8554>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:04:46 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 17:04:46 +0000
Subject: [issue8921] 2.7rc1: test_ttk failures on OSX 10.4
In-Reply-To: <1275847373.81.0.425210704121.issue8921@psf.upfronthosting.co.za>
Message-ID: <1284656686.25.0.00540437584665.issue8921@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Were these test failures fixed prior to the full release of 2.7 in which case this can be closed?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8921>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:20:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Sep 2010 17:20:08 +0000
Subject: [issue1648923] HP-UX: -lcurses missing for readline.so
Message-ID: <1284657608.41.0.0473156745002.issue1648923@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It could still exist since we don't seem to have many people building python on hpux.  That said, unless the op confirms the problem still exists in 2.7 or later this can stay closed.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1648923>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:25:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Sep 2010 17:25:36 +0000
Subject: [issue460474] codecs.StreamWriter: reset() on close()
Message-ID: <1284657936.28.0.676024675827.issue460474@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: closed -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue460474>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:31:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 16 Sep 2010 17:31:27 +0000
Subject: [issue9870] compile and nested scopes
In-Reply-To: <1284624686.57.0.761868003126.issue9870@psf.upfronthosting.co.za>
Message-ID: <1284658287.41.0.915885087711.issue9870@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If you want to execute code as in the global namespace, don't supply a separate "locals" dict to eval/exec.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9870>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:33:45 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Sep 2010 17:33:45 +0000
Subject: [issue4837] Omits MACHINE and DEBUG when building tix8.4.3
In-Reply-To: <1231099614.05.0.848880488218.issue4837@psf.upfronthosting.co.za>
Message-ID: <1284658425.17.0.975383157639.issue4837@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I think so, because TIX version built with python is not changed.

Anuway, I'm using PC/VC6/build_tkinter.py to build TCL/TK and TIX,
so I myself do not need this patch so much.

Please feel free to close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4837>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:34:24 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 17:34:24 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284658464.34.0.0684765960383.issue9807@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
title: deriving configuration information for different builds	with the same prefix -> deriving configuration information for different builds with the same prefix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:34:56 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Sep 2010 17:34:56 +0000
Subject: [issue4837] Omits MACHINE and DEBUG when building tix8.4.3
In-Reply-To: <1231099614.05.0.848880488218.issue4837@psf.upfronthosting.co.za>
Message-ID: <1284658496.37.0.215565046697.issue4837@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Of cource, I'm happy if anyone needs this patch. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4837>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:37:45 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 17:37:45 +0000
Subject: [issue1633953] re.compile("(.*$){1,4}", re.MULTILINE) fails
Message-ID: <1284658665.06.0.816764835569.issue1633953@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can this be closed as a duplicate of #2537?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633953>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:49:04 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Thu, 16 Sep 2010 17:49:04 +0000
Subject: [issue1187] pipe fd handling issues in subprocess.py on POSIX
In-Reply-To: <1190400129.03.0.21752289973.issue1187@psf.upfronthosting.co.za>
Message-ID: <1284659344.89.0.303920267036.issue1187@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

Here's a patch which adds the test from 1187-dustin.patch for the py3k branch. The test passes without any additional changes to the py3k code.

----------
nosy: +jfinkels
Added file: http://bugs.python.org/file18902/issue1187.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1187>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:51:05 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 17:51:05 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

sysconfig.get_config_h_filename() returns the path of pyconfig.h.  The Makefile is also used to return values from sysconfig but it's path is hidden in a non-public method, for no good reason that I can think of.  Therefore, sysconfig._get_makefile_filename() should be renamed to sysconfig.get_makefile_filename().

----------
assignee: barry
components: Library (Lib)
keywords: easy
messages: 116583
nosy: barry
priority: normal
severity: normal
status: open
title: Expose sysconfig._get_makefile_filename() in public API
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:57:25 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Sep 2010 17:57:25 +0000
Subject: [issue9810] bzip2 build sometimes fails (VS8.0)
In-Reply-To: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>
Message-ID: <1284659845.03.0.987225856348.issue9810@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Committed in r84851(py3k). Let's see buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9810>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:01:58 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 18:01:58 +0000
Subject: [issue1634774] locale 1251 does not convert to upper case properly
Message-ID: <1284660118.68.0.67463697005.issue1634774@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I've tried to see if this is still an issue but frankly can't make head nor tail out of it :(  Any locale gurus up for this?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1634774>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:03:22 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 18:03:22 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284660202.72.0.286619708338.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I was thinking along the lines that RDM outlined, IOW that _sysconfig.c or equivalent would be autogenerated at build time.  But I think there are really two issues here:

1) Avoiding parsing of pyconfig.h and Makefile to get variable values for the sysconfig module.  This is fairly easy, but also the less important one I think.  If we still want to do this, let's move it to a separate bug.

2) Allowing for pyconfig.h and Makefile for different build options to coexist.  You need this so that extensions will be built against the correct build parameters.  This is much more important and I think the issue that Doko really wants to solve.  The _d hack now used is only a partial solution because it doesn't take into account other build options.

One possibility would be to use $SO, $SOABI, or just the flags in the latter (if you don't want the 'cpython-32' redundancy in the name) in the filename to pyconfig.h and Makefile.  e.g.

>>> import sysconfig
>>> sysconfig.get_config_h_filename()
'/usr/local/include/python3.2/config-32m/pyconfig.h'
>>> sysconfig.get_makefile_filename() # see bug 9877
'/usr/local/lib/python3.2/config-32m/Makefile'

The related issue is the naming of the binaries to include the build flag.   Right now on Ubuntu we have python3-dbg for example.  Maybe instead we want python3-<SOABI-FLAGS> e.g. python3-m, python3-dm etc.  We can of course always use symlinks to get the old, or default names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:08:02 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Sep 2010 18:08:02 +0000
Subject: [issue9868] test_locale leaves locale changed
In-Reply-To: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>
Message-ID: <1284660482.11.0.334028765429.issue9868@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This patch is *as is* patch.

Index: Lib/test/test_locale.py
===================================================================
--- Lib/test/test_locale.py	(revision 84824)
+++ Lib/test/test_locale.py	(working copy)
@@ -352,13 +352,13 @@
     locale_type = locale.LC_ALL
 
     def setUp(self):
-        BaseLocalizedTest.setUp(self)
         enc = codecs.lookup(locale.getpreferredencoding(False) or 'ascii').name
         if enc not in ('utf-8', 'iso8859-1', 'cp1252'):
             raise unittest.SkipTest('encoding not suitable')
         if enc != 'iso8859-1' and (sys.platform == 'darwin' or
                                    sys.platform.startswith('freebsd')):
             raise unittest.SkipTest('wcscoll/wcsxfrm have known bugs')
+        BaseLocalizedTest.setUp(self)
 
     def test_strcoll_with_diacritic(self):
         self.assertLess(locale.strcoll('??', 'b'), 0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9868>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:08:46 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 18:08:46 +0000
Subject: [issue9878] Avoid parsing pyconfig.h and Makefile by autogenerating
	extension module
In-Reply-To: <1284660526.13.0.672517649262.issue9878@psf.upfronthosting.co.za>
Message-ID: <1284660526.13.0.672517649262.issue9878@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

This is splitting one concern from bug 9807 - specifically to avoid parsing pyconfig.h and Makefile in the sysconfig module by autogenerating an extension module (e.g. _sysconfig.c) at build time and using that to get the variables from those two files.

----------
assignee: barry
components: Library (Lib)
messages: 116588
nosy: barry
priority: normal
severity: normal
status: open
title: Avoid parsing pyconfig.h and Makefile by autogenerating extension module
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9878>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:09:51 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 18:09:51 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284660591.71.0.456086646477.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

See issue 9878 for the "don't parse" bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:09:57 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 18:09:57 +0000
Subject: [issue4837] Omits MACHINE and DEBUG when building tix8.4.3
In-Reply-To: <1231099614.05.0.848880488218.issue4837@psf.upfronthosting.co.za>
Message-ID: <1284660597.92.0.479381743305.issue4837@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4837>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:10:15 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 18:10:15 +0000
Subject: [issue9878] Avoid parsing pyconfig.h and Makefile by autogenerating
	extension module
In-Reply-To: <1284660526.13.0.672517649262.issue9878@psf.upfronthosting.co.za>
Message-ID: <1284660615.46.0.793260715131.issue9878@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

See issue 9807

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9878>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:10:44 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 16 Sep 2010 18:10:44 +0000
Subject: [issue9869] long_subtype_new segfault in pure-Python code
In-Reply-To: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>
Message-ID: <1284660644.07.0.390104932932.issue9869@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9869>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:15:05 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 16 Sep 2010 18:15:05 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284660905.83.0.62282828535.issue9877@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

-1 The Makefile is very implementation specific to CPython.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:18:27 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 18:18:27 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284660905.83.0.62282828535.issue9877@psf.upfronthosting.co.za>
Message-ID: <20100916141815.3b32ef5a@mission>


Barry A. Warsaw <barry at python.org> added the comment:

On Sep 16, 2010, at 06:15 PM, Benjamin Peterson wrote:

>-1 The Makefile is very implementation specific to CPython.

and pyconfig.h isn't?

-Barry

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:46:08 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Sep 2010 18:46:08 +0000
Subject: [issue8921] 2.7rc1: test_ttk failures on OSX 10.4
In-Reply-To: <1275847373.81.0.425210704121.issue8921@psf.upfronthosting.co.za>
Message-ID: <1284662768.08.0.334904000549.issue8921@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Duplicate of unresolved Issue8445

----------
assignee: ronaldoussoren -> 
nosy: +ned.deily
resolution:  -> duplicate
status: open -> closed
superseder:  -> buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8921>
_______________________________________

From report at bugs.python.org  Thu Sep 16 21:05:12 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 16 Sep 2010 19:05:12 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284663912.01.0.422948042831.issue9877@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes, it's unfortunate that that is exposed. Hopefully, sysconfig will evolve some way to find information independent of implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Thu Sep 16 21:05:40 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 19:05:40 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284663940.49.0.393646320248.issue9877@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file18903/9877.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Thu Sep 16 21:10:32 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 19:10:32 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284664232.35.0.421042759509.issue9877@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I don't agree that it's a bad thing that sysconfig exposes implementation specific information - it seems kind of the point of it.

"The sysconfig module provides access to Python?s configuration information like the list of installation paths and the configuration variables relevant for the current platform."

Of course things like sysconfig.get_config_h_filename() should raise an exception or return None on implementations that don't have a pyconfig.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Thu Sep 16 21:10:55 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 19:10:55 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284664255.02.0.454905544101.issue9877@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Patch attached.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Thu Sep 16 21:25:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Sep 2010 19:25:53 +0000
Subject: [issue6893] defaultdict example in py3 doc should mention the new
	Counter class
In-Reply-To: <1252724623.36.0.815888015467.issue6893@psf.upfronthosting.co.za>
Message-ID: <1284665153.98.0.123214413504.issue6893@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This example needs to stay.  It was one of the principal motiviating use cases for defaultdict and it is a good, simple, understandable example of how to use it.

Also, I don't want to cross-link these two tools because they a subtly different (the default dict approach inserts a zero for missing elements while the Counter approach returns zero but does not insert it).

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6893>
_______________________________________

From report at bugs.python.org  Thu Sep 16 21:34:13 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 19:34:13 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284665653.17.0.170252374796.issue9877@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


Added file: http://bugs.python.org/file18904/docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Thu Sep 16 21:34:59 2010
From: report at bugs.python.org (Jason Grout)
Date: Thu, 16 Sep 2010 19:34:59 +0000
Subject: [issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for
	C++"
In-Reply-To: <1239729771.84.0.97828652099.issue5755@psf.upfronthosting.co.za>
Message-ID: <1284665699.15.0.825054604523.issue5755@psf.upfronthosting.co.za>


Jason Grout <jason.grout at drake.edu> added the comment:

Any progress on this?  I see this warning a *lot* when compiling lots of packages for Sage (matplotlib included).

----------
nosy: +Jason.Grout

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5755>
_______________________________________

From report at bugs.python.org  Thu Sep 16 21:36:03 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 16 Sep 2010 19:36:03 +0000
Subject: [issue5629] PEP 0 date and revision not being set
In-Reply-To: <1238519928.09.0.287279544516.issue5629@psf.upfronthosting.co.za>
Message-ID: <1284665763.18.0.535050176965.issue5629@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Yes, it's just a question of how to interpret it. If we bother keeping the info in there, should it be for all updates to PEPs, or just when a PEP is added?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5629>
_______________________________________

From report at bugs.python.org  Thu Sep 16 21:57:18 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 19:57:18 +0000
Subject: [issue1648890] HP-UX: ld -Wl,+b...
Message-ID: <1284667038.12.0.159903385921.issue1648890@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
versions: +Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1648890>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:01:21 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 20:01:21 +0000
Subject: [issue1648957] HP-UX:
	_ctypes/libffi/src/ia64/ffi/__attribute__/native cc
Message-ID: <1284667281.65.0.377385008633.issue1648957@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this still a problem with later versions of Python and/or the quoted OSes?

----------
nosy: +BreamoreBoy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1648957>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:09:51 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 20:09:51 +0000
Subject: [issue1651427] readline needs termcap on my FC6
Message-ID: <1284667791.98.0.142917119391.issue1651427@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I can't believe that this is still an issue over 3 1/2 years on.

----------
nosy: +BreamoreBoy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1651427>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:10:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 20:10:54 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1284667854.04.0.649022458359.issue9873@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/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:19:20 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 20:19:20 +0000
Subject: [issue1653416] OS X print >> f, "Hello" produces no error: normal?
Message-ID: <1284668360.43.0.533794175152.issue1653416@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I've assumed this is still a problem on OS X.

----------
nosy: +BreamoreBoy
title: print >> f, "Hello" produces no error: normal? -> OS X print >> f, "Hello" produces no error: normal?
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1653416>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:24:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 20:24:35 +0000
Subject: [issue5309] setup.py doesn't parallelize extension module compilation
In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za>
Message-ID: <1284668675.74.0.770407477704.issue5309@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do you want to work on a patch?

----------
stage:  -> needs patch
versions: +Python 2.5, Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5309>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:27:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 20:27:16 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284668836.67.0.717287318969.issue9877@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I don't agree that it's a bad thing that sysconfig exposes
> implementation specific information - it seems kind of the point of it.

Well, it exposes configuration information, for example paths (which should exist in all VMs), but things like the existence of a .h file seem implementation details that should not be public IMO.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:27:29 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 20:27:29 +0000
Subject: [issue1653457] Python misbehaves when installed in / (patch attached)
Message-ID: <1284668849.14.0.198610466595.issue1653457@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can someone with a Linux box try the latest patch please.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1653457>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:28:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 20:28:04 +0000
Subject: [issue9878] Avoid parsing pyconfig.h and Makefile by autogenerating
	extension module
In-Reply-To: <1284660526.13.0.672517649262.issue9878@psf.upfronthosting.co.za>
Message-ID: <1284668884.8.0.639508493585.issue9878@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9878>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:30:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 20:30:41 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1284669041.16.0.0363499347234.issue9807@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Antoine:
> Is there any point in creating another extension module?
> We already have Modules/getpath.c which receives various configuration
> values at compile-time, themselves exposed as sys.prefix and friends.

I have no opinion on generating a new module vs. adding info to getpath.c, but I wouldn?t like to further bloat the sys module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:31:15 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Thu, 16 Sep 2010 20:31:15 +0000
Subject: [issue9683] Dead code in py3k inspect module
In-Reply-To: <1282763623.07.0.68649497821.issue9683@psf.upfronthosting.co.za>
Message-ID: <1284669075.6.0.464273388628.issue9683@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

The documentation about `getargvalues()` and the docstrings of `getargspec()` and friends still mention nested lists for args. Should I update the patch or should I create a new issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9683>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:31:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 20:31:22 +0000
Subject: [issue3020] doctest should have lib2to3 integration
In-Reply-To: <1212331047.91.0.677781535819.issue3020@psf.upfronthosting.co.za>
Message-ID: <1284669082.43.0.889567270244.issue3020@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Still valid IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3020>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:32:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 20:32:48 +0000
Subject: [issue3020] doctest should have lib2to3 integration
In-Reply-To: <1212331047.91.0.677781535819.issue3020@psf.upfronthosting.co.za>
Message-ID: <1284669168.37.0.113208803434.issue3020@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +benjamin.peterson, tim_one
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3020>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:34:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 20:34:30 +0000
Subject: [issue9876] ConfigParser can't interpolate values from other sections
In-Reply-To: <1284655085.98.0.131711113127.issue9876@psf.upfronthosting.co.za>
Message-ID: <1284669270.13.0.0141019852397.issue9876@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Stable versions don?t get new features, only bug fixes.

----------
nosy: +eric.araujo, fdrake, lukasz.langa
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9876>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:40:56 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 20:40:56 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284668836.67.0.717287318969.issue9877@psf.upfronthosting.co.za>
Message-ID: <20100916164048.547267f5@mission>


Barry A. Warsaw <barry at python.org> added the comment:

On Sep 16, 2010, at 08:27 PM, ?ric Araujo wrote:

>?ric Araujo <merwok at netwok.org> added the comment:
>
>> I don't agree that it's a bad thing that sysconfig exposes
>> implementation specific information - it seems kind of the point of
>> it.
>
>Well, it exposes configuration information, for example paths (which
>should exist in all VMs), but things like the existence of a .h file
>seem implementation details that should not be public IMO.

If that's the case, then where should this information be exposed?  I think it
needs to be exposed *somewhere*.  You don't want people just guessing or
reinventing all the file system search code that's already in sysconfig.

I'm also not convinced that the paths and schemes are implementation
agnostic.  For example, you'd have to add schemes for each of the other
implementations (and their variants, e.g. Jython installed on POSIX vs. Jython
installed on Windows).  And clearly, some of the scheme paths described in the
module are pretty specific to autoconf's model of the world.  (Does IronPython
really have platinclude?)

Now, I definitely have my own beefs about sysconfig's API, but it is what it
is, so unless there's a clear alternative, I think sysconfig should expose
information that will be useful for programmatically determining configuration
details of the Python you're running.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:44:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 20:44:38 +0000
Subject: [issue9874] Message.attach() loses empty attachments
In-Reply-To: <1284645198.43.0.725761534678.issue9874@psf.upfronthosting.co.za>
Message-ID: <1284669878.71.0.275192029919.issue9874@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9874>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:47:36 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 20:47:36 +0000
Subject: [issue1659705] Python extension problems after re-install
Message-ID: <1284670056.44.0.266617505143.issue1659705@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I've been chopping and changing versions recently and haven't had any problems.  @Brian/Tim any comments?

----------
nosy: +BreamoreBoy, brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1659705>
_______________________________________

From report at bugs.python.org  Thu Sep 16 22:59:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 20:59:22 +0000
Subject: [issue1660009] continuing problem with httplib multiple set-cookie
	headers
Message-ID: <1284670762.46.0.253286521625.issue1660009@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
assignee: georg.brandl -> docs at python
nosy: +docs at python
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1660009>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:04:04 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 21:04:04 +0000
Subject: [issue1661754] ftplib passive ftp problem on multihomed clients
Message-ID: <1284671044.86.0.128777463551.issue1661754@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1661754>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:14:53 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Sep 2010 21:14:53 +0000
Subject: [issue1653416] OS X print >> f, "Hello" produces no error: normal?
Message-ID: <1284671693.3.0.146583186186.issue1653416@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

At least for the original test case, the Python 3 equivalent does fail on OS X:

$ python3.1
Python 3.1.2 (r312:79360M, Mar 24 2010, 01:33:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('/dev/null')
>>> print('Hello',file=f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: not writable
>>> 

Perhaps this can be closed as "wont fix" for Python 2 and, if necessary, open a separate issue for checking fprintf and fwrite return values?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1653416>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:20:16 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 21:20:16 +0000
Subject: [issue1665333] Documentation missing for OptionGroup class in optparse
Message-ID: <1284672016.76.0.984916337831.issue1665333@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Should this be left with AMK or should it be reassigned to docs at python?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1665333>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:21:49 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 16 Sep 2010 21:21:49 +0000
Subject: [issue5629] PEP 0 date and revision not being set
In-Reply-To: <1284665763.18.0.535050176965.issue5629@psf.upfronthosting.co.za>
Message-ID: <AANLkTind1jXUw83ghjc3UQdkO=Er97WzPUFsS=dcOKK5@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/9/16 Brett Cannon <report at bugs.python.org>:
>
> Brett Cannon <brett at python.org> added the comment:
>
> Yes, it's just a question of how to interpret it. If we bother keeping the info in there, should it be for all updates to PEPs, or just when a PEP is added?

I think you could just as well insert the date that it's generated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5629>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:28:41 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 21:28:41 +0000
Subject: [issue1669349] make install fails if no previous Python installation
Message-ID: <1284672521.25.0.0456848011627.issue1669349@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can someone with install and/or build experience please confirm or deny that this is a problem with supported versions of Python.

----------
nosy: +BreamoreBoy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669349>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:31:33 2010
From: report at bugs.python.org (elf)
Date: Thu, 16 Sep 2010 21:31:33 +0000
Subject: [issue1659705] Python extension problems after re-install
Message-ID: <1284672693.43.0.000303039565283.issue1659705@psf.upfronthosting.co.za>


elf <elfin24fw at users.sourceforge.net> added the comment:

Yeah this was fixed a long time ago thanks :)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1659705>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:32:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 21:32:29 +0000
Subject: [issue1665333] Documentation missing for OptionGroup class in optparse
Message-ID: <1284672749.69.0.237163656219.issue1665333@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adding docs@ to nosy. amk: Please reassign to docs@ if you don?t intend to work on this.

----------
nosy: +docs at python, eric.araujo
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1665333>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:34:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 21:34:10 +0000
Subject: [issue5629] PEP 0 date and revision not being set
In-Reply-To: <1238519928.09.0.287279544516.issue5629@psf.upfronthosting.co.za>
Message-ID: <1284672850.15.0.333842748651.issue5629@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/issue5629>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:35:48 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 21:35:48 +0000
Subject: [issue1671676] test_mailbox is hanging while doing gmake test on
	HP-UX v3
Message-ID: <1284672948.58.0.109717247803.issue1671676@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can someone with an HP-UX box please see if this is still a problem with currently supported versions of Python.

----------
nosy: +BreamoreBoy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1671676>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:49:39 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 21:49:39 +0000
Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support
Message-ID: <1284673779.11.0.42570632854.issue1675455@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

@Senthil should this be assigned to your good self?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675455>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:56:12 2010
From: report at bugs.python.org (Tom Browder)
Date: Thu, 16 Sep 2010 21:56:12 +0000
Subject: [issue9879] Tracker Won't Accept New Bugs
In-Reply-To: <1284674171.88.0.225242150175.issue9879@psf.upfronthosting.co.za>
Message-ID: <1284674171.88.0.225242150175.issue9879@psf.upfronthosting.co.za>


New submission from Tom Browder <tom.browder at gmail.com>:

When I attempt to enter a new bug I get:

An error has occurred

A problem was encountered processing your request. The tracker
maintainers have been notified of the problem.

----------
components: Demos and Tools
messages: 116620
nosy: Tom.Browder
priority: normal
severity: normal
status: open
title: Tracker Won't Accept New Bugs
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9879>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:01:16 2010
From: report at bugs.python.org (Tom Browder)
Date: Thu, 16 Sep 2010 22:01:16 +0000
Subject: [issue9879] Tracker Won't Accept New Bugs
In-Reply-To: <1284674171.88.0.225242150175.issue9879@psf.upfronthosting.co.za>
Message-ID: <1284674476.64.0.703019151311.issue9879@psf.upfronthosting.co.za>


Tom Browder <tom.browder at gmail.com> added the comment:

Since this worked, I tried again to enter the bug with a new process.  I have tried changing several selections but I still get the error--very strange!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9879>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:01:38 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 22:01:38 +0000
Subject: [issue1675951] [gzip] Performance for small reads and fix seek problem
Message-ID: <1284674498.69.0.4801339144.issue1675951@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

As there has been a lot of support for the attached patch what is needed to take this forward?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:02:12 2010
From: report at bugs.python.org (Tom Browder)
Date: Thu, 16 Sep 2010 22:02:12 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>


New submission from Tom Browder <tom.browder at gmail.com>:

I am trying to rebuild the 2.7 maintenance branch and get this error
on Ubuntu 10.04.1 LTS:

XXX lineno: 743, opcode: 0
Traceback (most recent call last):
 File "/usr/local/src/python-2.7-maint-svn/Lib/site.py", line 62, in <module>
  import os
 File "/usr/local/src/python-2.7-maint-svn/Lib/os.py", line 743, in <module>
  def urandom(n):
SystemError: unknown opcode

I installed it successfully once so I may be getting conflicts, but I can't figure out why.  There were some similar bugs reported in previous versions but I didn't see a clear solution.

I have done "make distclean" and "./configure".  I have unset my
PYTHONPATH and LD_LIBRARY_PATH, but python2.7 is my default python from a previous good build and installation.

----------
components: Build
messages: 116623
nosy: Tom.Browder
priority: normal
severity: normal
status: open
title: Python 2.7 Won't Build: SystemError: unknown opcode
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:03:54 2010
From: report at bugs.python.org (Tom Browder)
Date: Thu, 16 Sep 2010 22:03:54 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284674634.36.0.224266212606.issue9880@psf.upfronthosting.co.za>


Changes by Tom Browder <tom.browder at gmail.com>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:04:12 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 22:04:12 +0000
Subject: [issue1676820] Add a PeriodicTimer to threading
Message-ID: <1284674652.66.0.154720063978.issue1676820@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Could someone with commit privileges please take a look at the patch, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1676820>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:04:51 2010
From: report at bugs.python.org (Tom Browder)
Date: Thu, 16 Sep 2010 22:04:51 +0000
Subject: [issue9879] Tracker Won't Accept New Bugs
In-Reply-To: <1284674171.88.0.225242150175.issue9879@psf.upfronthosting.co.za>
Message-ID: <1284674691.4.0.157988214889.issue9879@psf.upfronthosting.co.za>


Tom Browder <tom.browder at gmail.com> added the comment:

It looks like the problem was because I was trying to add a complete e-mail address to the "nosy" list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9879>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:06:30 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 22:06:30 +0000
Subject: [issue1677694] test_timeout refactoring
Message-ID: <1284674790.72.0.581529673265.issue1677694@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Could someone with commit privileges please take this forward?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1677694>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:06:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 22:06:31 +0000
Subject: [issue1676820] Add a PeriodicTimer to threading
Message-ID: <1284674791.43.0.734144373477.issue1676820@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1676820>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:08:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Sep 2010 22:08:10 +0000
Subject: [issue1675951] [gzip] Performance for small reads and fix seek problem
Message-ID: <1284674890.07.0.492441199511.issue1675951@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As there has been a lot of support for the attached patch what is
> needed to take this forward?

Read my 2010-06-17 message above. Someone needs to update the patch for 3.2, and preferable show that it still brings an improvement (small micro-benchmarks are enough).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:19:42 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 22:19:42 +0000
Subject: [issue1678077] improve telnetlib.Telnet so option negotiation becomes
	easie
Message-ID: <1284675582.12.0.462614272181.issue1678077@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
components: +Library (Lib) -None
stage:  -> unit test needed
type:  -> feature request
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1678077>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:22:38 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 16 Sep 2010 22:22:38 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284675758.02.0.0347470614385.issue9880@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Maybe a corrupted .pyc file? Can you please attach the file
/usr/local/src/python-2.7-maint-svn/Lib/os.pyc

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:22:59 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 16 Sep 2010 22:22:59 +0000
Subject: [issue9881] PySSL_SSLRead loops until data is available,
	even in non-blocking mode
In-Reply-To: <1284675779.48.0.545213768425.issue9881@psf.upfronthosting.co.za>
Message-ID: <1284675779.48.0.545213768425.issue9881@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

Here's a transcript which demonstrates the blocking behavior:

>>> import socket
>>> import time
>>> import ssl
>>> s = ssl.wrap_socket(socket.socket())
>>> s.connect(('localhost', 8443))
>>> s.send('GET /async.rpy HTTP/1.1\r\n\r\n')
27
>>> s.setblocking(False)
>>> a = time.time(); s.recv(1024); b = time.time()
'HTTP/1.1 200 OK\r\nTransfer-Encoding: chunked\r\nDate: Thu, 02 Sep 2010 11:51:03 GMT\r\nContent-Type: text/html\r\nServer: TwistedWeb/10.1.0+r29954\r\n\r\n4c\r\n<html><body>Sorry to keep you waiting.</body></html>\r\n0\r\n\r\n'
>>> print b - a
4.13403391838
>>>

(This can be reproduced using any web server which is a bit slow in responding; it's very obvious here because I used a server that intentionally waits several seconds before generating a response).

----------
components: Library (Lib)
messages: 116629
nosy: exarkun
priority: normal
severity: normal
status: open
title: PySSL_SSLRead loops until data is available, even in non-blocking mode
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/issue9881>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:25:57 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 16 Sep 2010 22:25:57 +0000
Subject: [issue9881] PySSL_SSLread loops until data is available,
	even in non-blocking mode
In-Reply-To: <1284675779.48.0.545213768425.issue9881@psf.upfronthosting.co.za>
Message-ID: <1284675957.0.0.335266461153.issue9881@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <invalid at example.invalid>:


----------
title: PySSL_SSLRead loops until data is available, even in non-blocking mode -> PySSL_SSLread loops until data is available, even in non-blocking mode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9881>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:32:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Sep 2010 22:32:30 +0000
Subject: [issue9881] PySSL_SSLread loops until data is available,
	even in non-blocking mode
In-Reply-To: <1284675779.48.0.545213768425.issue9881@psf.upfronthosting.co.za>
Message-ID: <1284676350.68.0.36549802243.issue9881@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It was corrected between 2.6.5 and 2.6.6 (see r79291 and also potentially r80453).

Here, on the 2.6 maintenance branch:

>>> import socket, time, ssl
>>> s = ssl.wrap_socket(socket.socket())
>>> s.connect(('linuxfr.org', 443))
>>> s.setblocking(False)
>>> s.recv(1024)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/27/Lib/ssl.py", line 219, in recv
    return self.read(buflen)
  File "/home/antoine/cpython/27/Lib/ssl.py", line 138, in read
    return self._sslobj.read(len)
ssl.SSLError: [Errno 2] _ssl.c:1348: The operation did not complete (read)

Can you check with 2.6.6 or the release26-maint SVN head?

----------
nosy: +pitrou
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9881>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:46:25 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 16 Sep 2010 22:46:25 +0000
Subject: [issue9881] PySSL_SSLread loops until data is available,
	even in non-blocking mode
In-Reply-To: <1284675779.48.0.545213768425.issue9881@psf.upfronthosting.co.za>
Message-ID: <1284677185.35.0.537912664532.issue9881@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

Hm.  I must have been testing with old versions, since I can't reproduce this now.  Sorry for the noise.

----------
resolution: out of date -> duplicate
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9881>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:51:45 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 22:51:45 +0000
Subject: [issue1681974] mkdtemp fails on Windows if username has non-ASCII
	character
Message-ID: <1284677505.92.0.826247610263.issue1681974@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I can't reproduce this problem on Windows Vista with any of the current maintainance branches of Python using the interactive prompt from the command line.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1681974>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:56:36 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 16 Sep 2010 22:56:36 +0000
Subject: [issue9875] Garbage output when running setup.py on Windows
In-Reply-To: <1284646791.69.0.38074502633.issue9875@psf.upfronthosting.co.za>
Message-ID: <1284677796.86.0.235214579172.issue9875@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

This seems to have been caused by an ill-placed distutils.log.set_verbosity(3) call.  With that removed, this output isn't generated by default.  So perhaps this is invalid, feel free to close it as so if you agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9875>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:57:06 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Sep 2010 22:57:06 +0000
Subject: [issue9879] Tracker Won't Accept New Bugs
In-Reply-To: <1284674171.88.0.225242150175.issue9879@psf.upfronthosting.co.za>
Message-ID: <1284677826.08.0.188659436428.issue9879@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Glad you were able to get past the problem.  Looks like there already is an open issue about this on the Meta-tracker (for bug reports about the bug tracker itself):

http://psf.upfronthosting.co.za/roundup/meta/issue336

----------
nosy: +ned.deily
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9879>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:58:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Sep 2010 22:58:27 +0000
Subject: [issue1676820] Add a PeriodicTimer to threading
Message-ID: <1284677907.8.0.328450614666.issue1676820@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't really agree with "negative periods behave like if the period was 0". Negative periods don't mean anything and should just raise ValueError.
(as for 0, well, we can allow it anyway, although it means the timer just degenerates into an busy loop)

The doc will have to be converted to the new Sphinx format, as well.

----------
nosy: +jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1676820>
_______________________________________

From report at bugs.python.org  Fri Sep 17 01:01:31 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 23:01:31 +0000
Subject: [issue706406] fix bug #685846: raw_input defers signals
Message-ID: <1284678091.1.0.469563239039.issue706406@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can someone please comment on msg114316 as I'm out of my depth here, thanks.

----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706406>
_______________________________________

From report at bugs.python.org  Fri Sep 17 01:01:40 2010
From: report at bugs.python.org (Tom Browder)
Date: Thu, 16 Sep 2010 23:01:40 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284678100.94.0.751182102954.issue9880@psf.upfronthosting.co.za>


Tom Browder <tom.browder at gmail.com> added the comment:

File attached as requested.

----------
Added file: http://bugs.python.org/file18905/os.pyc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 01:11:36 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 23:11:36 +0000
Subject: [issue3180] Interrupts are lost during readline PyOS_InputHook
	processing
In-Reply-To: <1214238743.53.0.342771827236.issue3180@psf.upfronthosting.co.za>
Message-ID: <1284678696.97.0.436582551986.issue3180@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I'm unsure as to whether this is a feature request or a behaviour problem, anyone?  Regardless could a core dev take a look at the patch which involves changes to the API for PyOS_InputHook, see msg68638.

----------
nosy: +BreamoreBoy
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3180>
_______________________________________

From report at bugs.python.org  Fri Sep 17 01:12:26 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 23:12:26 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284678746.96.0.275380623157.issue9880@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Note that I tried to reproduce this on my 10.04.1 system, with various states of Python 2.7 installed, etc. and was unable to reproduce it.  It's certainly odd that you're getting the SystemError on that line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 01:42:15 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 16 Sep 2010 23:42:15 +0000
Subject: [issue1676820] Add a PeriodicTimer to threading
Message-ID: <1284680535.83.0.13218038411.issue1676820@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Java's Timer class tends to be discouraged these days in favor of ScheduledExecutorService.scheduleAtFixedRate and .scheduleWithFixedDelay (http://download.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledExecutorService.html). Could you say why you modeled this interface off of java.util.Timer instead of ScheduledExecutor? See http://www.python.org/dev/peps/pep-3148/ for the basis of executors in Python.

I'm skeptical of having a PeriodicTimer that embeds a fixed-delay timing. Both fixed-rate and fixed-delay are useful for different things, and given the ambiguity we probably shouldn't give in to the temptation to guess. 

I'm skeptical of having a new thread per periodic task. It's a little more work to multiplex tasks onto shared threads, and maybe that work isn't worth it for now, but I think the interface should allow future implementations to multiplex their tasks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1676820>
_______________________________________

From report at bugs.python.org  Fri Sep 17 01:48:17 2010
From: report at bugs.python.org (ipatrol)
Date: Thu, 16 Sep 2010 23:48:17 +0000
Subject: [issue9740] Support for HTTP 1.1 persistent connections throughout
	the standard library
In-Reply-To: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za>
Message-ID: <1284680897.4.0.823164589913.issue9740@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

Possibly, but I don't really have expertise in the underbelly of the HTTP system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9740>
_______________________________________

From report at bugs.python.org  Fri Sep 17 01:52:36 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 16 Sep 2010 23:52:36 +0000
Subject: [issue5629] PEP 0 date and revision not being set
In-Reply-To: <1238519928.09.0.287279544516.issue5629@psf.upfronthosting.co.za>
Message-ID: <1284681156.33.0.327936970145.issue5629@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Done in r84855.

----------
assignee:  -> brett.cannon
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5629>
_______________________________________

From report at bugs.python.org  Fri Sep 17 02:21:57 2010
From: report at bugs.python.org (ipatrol)
Date: Fri, 17 Sep 2010 00:21:57 +0000
Subject: [issue9882] abspath from directory
In-Reply-To: <1284682917.39.0.650396347526.issue9882@psf.upfronthosting.co.za>
Message-ID: <1284682917.39.0.650396347526.issue9882@psf.upfronthosting.co.za>


New submission from ipatrol <ipatrol6010 at yahoo.com>:

Just an easy patch.

os.path.abspath is defined as os.path.normpath(os.path.join(os.getcwd(),path), but os.path.relpath also adds a start option. This creates an asymmetry where getting the absolute path from a relative path and a directory has no single operation whereas the inverse does. So finding the absolute path of 'foo' in the directory '/bar/buzz/bang/quok' requires several nested functions or else a quick dash in with os.chdir. Hence redefining os.path.abspath as os.path.normpath(os.path.join(start or os.getcwd(),path).

----------
components: Library (Lib)
messages: 116643
nosy: ipatrol
priority: normal
severity: normal
status: open
title: abspath from directory
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9882>
_______________________________________

From report at bugs.python.org  Fri Sep 17 05:30:46 2010
From: report at bugs.python.org (Aubrey Barnard)
Date: Fri, 17 Sep 2010 03:30:46 +0000
Subject: [issue9883] minidom: AttributeError: DocumentFragment instance has no
	attribute 'writexml'
In-Reply-To: <1284694245.92.0.410723728376.issue9883@psf.upfronthosting.co.za>
Message-ID: <1284694245.92.0.410723728376.issue9883@psf.upfronthosting.co.za>


New submission from Aubrey Barnard <aubrey.f.barnard at gmail.com>:

Summary:
Writing a document fragment doesn't work because the 'writexml' method is not implemented.

Problem:
I would like to be able to write out document fragments as XML text, but this functionality is not implemented. Here are the reasons why I think this functionality should be implemented.

1. DOM Level 1 describes a document fragment as a lightweight document. I can write a document as XML text so why not a document fragment?

2. This would be very easy to implement, basically just the child processing loop from Element.writexml:
for node in self.childNodes:
    node.writexml(writer,indent+addindent,addindent,newl)

3. Document fragments are often returned as intermediate results in XML building. The best way I can think of to unit test these results is by writing the document fragment as XML text and comparing to an existing string. (Comparing two document fragments is not guaranteed to work.)

4. Implementing an XML editor on top of minidom would require this functionality, e.g. display a piece of cut XML.

I realize that writing document fragments as XML text is not a common or "core" operation, but it makes sense in the above four cases and perhaps other cases as well. Therefore, to me, implementing this functionality is less a question of "Why?" and more a question of "Why not?"

I will be glad to add any other information as requested.

----------
components: XML
messages: 116644
nosy: Aubrey.Barnard
priority: normal
severity: normal
status: open
title: minidom: AttributeError: DocumentFragment instance has no attribute 'writexml'
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9883>
_______________________________________

From report at bugs.python.org  Fri Sep 17 08:15:33 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 17 Sep 2010 06:15:33 +0000
Subject: [issue1653416] OS X print >> f, "Hello" produces no error: normal?
Message-ID: <1284704133.11.0.37603166527.issue1653416@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is not an issue for 3.x because the io library doesn't use stdio.

I'd say this is unlikely to get fixed in 2.7 as every call to stdio functions needs to be checked and updated.

----------
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1653416>
_______________________________________

From report at bugs.python.org  Fri Sep 17 08:27:38 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 17 Sep 2010 06:27:38 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1284704858.84.0.824855189954.issue9786@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, here is a patch.  key creation returns -1 on error, and the caller can detect this and raise a fatal error.

----------
Added file: http://bugs.python.org/file18906/pthread_tls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Fri Sep 17 08:54:15 2010
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Fri, 17 Sep 2010 06:54:15 +0000
Subject: [issue1653416] OS X print >> f,
	"Hello" produces no error on read-only f: normal?
Message-ID: <1284706455.34.0.585746133241.issue1653416@psf.upfronthosting.co.za>


Changes by Eric O. LEBIGOT <eric.lebigot at normalesup.org>:


----------
title: OS X print >> f, "Hello" produces no error: normal? -> OS X print >> f, "Hello" produces no error on read-only f: normal?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1653416>
_______________________________________

From report at bugs.python.org  Fri Sep 17 09:09:08 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 07:09:08 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284707348.48.0.457930038606.issue9880@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

For some reason your file os.pyc is corrupted:
I loaded it with a working python2.7:

import marshal, dis
pyc = open('bados.pyc', 'rb').read()
code = marshal.loads(pyc[8:])
dis.dis(code)

And it appears that all the "jump" instructions are wrong: the address is either 0, or something around 65536.

Which compiler do you use? I remember subtle bugs caused by some version of gcc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 10:52:39 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 17 Sep 2010 08:52:39 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1284713559.17.0.905438796902.issue5113@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Actually, looking at the man page, this seems to be normal:

---
In order to change the owner or group, you must own the file and have the CHOWN privilege (see setprivgrp(1M)). [...] Note that a given user's or group's ability to use this command can be restricted by setprivgrp (see setprivgrp(1M)).
---

So depending on the setting of setprivgrp, chown'ing a file to root may be allowed or not.
It might be a good idea to skip this test on HP-UX. Solaris apparently behaves in the same way.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Fri Sep 17 11:12:22 2010
From: report at bugs.python.org (Owen)
Date: Fri, 17 Sep 2010 09:12:22 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>


New submission from Owen <j2.nete at gmail.com>:

OS: Windows 2003STD x64 en

I have try to call python method from c++ dll by "WINFUNCTYPE".
But the 4th parameter is always None or 0 if the type is int or void* (float is works fine).

Following is the part of source code:
==code==========================================
import sys
from ctypes import *

windll.LoadLibrary("testPy2.dll")
#########################################

def test3(param1,param2,param3,param4,param5,param6,param7,param8,param9,param10):
  print("================")
  print(param1)
  print(param2)
  print(param3)
  # the 4th param4 is always 0.
  print(param4)
  print(param5)
  print(param6)
  print(param7)
  print(param8)
  print(param9)
  print(param10)
  print("================")
  return 20
  
C_METHOD_TYPE4 = WINFUNCTYPE(c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32)

windll.testPy2.fntestPy7(9,C_METHOD_TYPE4(test3))
==code==========================================

To my knowledge, both visual c++ and gcc use registers for the first few parameters, and then after that use the stack.  Maybe this is the reason.

I have attached some simple codes for reproduce this issue.
issues
  - testPy2      <- source code of the dll
  - test.py      <- python file to reproduce the issue
  - testPy2.dll  <- the dll to reproduce the issue

----------
components: Windows
files: issues.zip
messages: 116649
nosy: J2.NETe
priority: normal
severity: normal
status: open
title: The 4th parameter of method always None or 0 on x64 Windows.
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18907/issues.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Fri Sep 17 11:13:24 2010
From: report at bugs.python.org (Owen)
Date: Fri, 17 Sep 2010 09:13:24 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1284714804.64.0.886195434914.issue9884@psf.upfronthosting.co.za>


Changes by Owen <j2.nete at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Fri Sep 17 12:29:35 2010
From: report at bugs.python.org (Tom Browder)
Date: Fri, 17 Sep 2010 10:29:35 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284719375.9.0.714489941694.issue9880@psf.upfronthosting.co.za>


Tom Browder <tom.browder at gmail.com> added the comment:

I'm using gcc-4.5.1.  I'll try an older version: gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 12:44:51 2010
From: report at bugs.python.org (Tom Browder)
Date: Fri, 17 Sep 2010 10:44:51 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284720291.18.0.222413960944.issue9880@psf.upfronthosting.co.za>


Tom Browder <tom.browder at gmail.com> added the comment:

The build succeeded with the older version of gcc.  I either have a mis-compiled gcc-4.5.1 (but the same version on another host worked okay) or gcc has a very subtle bug.  I think this issue can be considered closed; however, it may be worth a note in a FAQ or build instructions.  Good catch Amaury!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 12:51:36 2010
From: report at bugs.python.org (Tom Browder)
Date: Fri, 17 Sep 2010 10:51:36 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284720696.63.0.812413478553.issue9880@psf.upfronthosting.co.za>


Tom Browder <tom.browder at gmail.com> added the comment:

Correction on the bad gcc compiler: the actual version was a non-released version off the gcc-4.6 branch:  gcc version 4.6.0 20100908 (experimental) (GCC).  I'm filing a bug with gcc.  Sorry for the wasted time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 13:07:39 2010
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 17 Sep 2010 11:07:39 +0000
Subject: [issue9872] `a.b.my_function is not b.my_function` when `a` and `b`
	are both on `sys.path`
In-Reply-To: <1284640093.44.0.797706221833.issue9872@psf.upfronthosting.co.za>
Message-ID: <1284721659.85.0.399147966659.issue9872@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Benjamin,

This behavior is involved in a problem I have with Django. When using Django, you have apps that live inside a project:

my_project\
  __init__.py
  my_app\
    __init__.py
    views.py

So if you have a view function in `views.py`, it will have two separate identities, and that causes problems.

Do you have an idea what I can do about it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9872>
_______________________________________

From report at bugs.python.org  Fri Sep 17 13:08:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 11:08:25 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284721705.75.0.737259212194.issue9880@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You're welcome.
Please join a link to the gcc bug when you have one.

----------
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 13:14:15 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 11:14:15 +0000
Subject: [issue9872] `a.b.my_function is not b.my_function` when `a` and `b`
	are both on `sys.path`
In-Reply-To: <1284640093.44.0.797706221833.issue9872@psf.upfronthosting.co.za>
Message-ID: <1284722055.86.0.336169364421.issue9872@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I suggest to report this to the Django team.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9872>
_______________________________________

From report at bugs.python.org  Fri Sep 17 13:36:19 2010
From: report at bugs.python.org (paontis)
Date: Fri, 17 Sep 2010 11:36:19 +0000
Subject: [issue9885] Function Round does not work properly in some conditions
In-Reply-To: <1284723379.23.0.462202029266.issue9885@psf.upfronthosting.co.za>
Message-ID: <1284723379.23.0.462202029266.issue9885@psf.upfronthosting.co.za>


New submission from paontis <paoregs at gmail.com>:

For example round(10.3333, 1) returns 10.300000000000001 and round(1.3333, 2)returns 1.3300000000000001

I exect they return 10.3 and 1.33 rispectively

NOTE: other combinations work fine eg. round(10.3333, 2) or round(1.3333, 3)

See IDLE commands in the attached file round.txt

Used Python 2.6.6 for Windows

----------
files: round.txt
messages: 116656
nosy: paontis
priority: normal
severity: normal
status: open
title: Function Round does not work properly in some conditions
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file18908/round.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9885>
_______________________________________

From report at bugs.python.org  Fri Sep 17 13:37:43 2010
From: report at bugs.python.org (Tom Browder)
Date: Fri, 17 Sep 2010 11:37:43 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284723463.35.0.718305591576.issue9880@psf.upfronthosting.co.za>


Tom Browder <tom.browder at gmail.com> added the comment:

Here is a link to the thread I started on the gcc-help mailing list concerning the issue: 

  http://gcc.gnu.org/ml/gcc-help/2010-09/msg00170.html

If I don't get a successful build with the current gcc trunk, I imagine this thread will transfer to the gcc (dev) list--I'll try to keep the links up.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 14:13:26 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Sep 2010 12:13:26 +0000
Subject: [issue9886] Make operator.itemgetter/attrgetter/methodcaller easier
	to discover
In-Reply-To: <1284725606.32.0.188356028787.issue9886@psf.upfronthosting.co.za>
Message-ID: <1284725606.32.0.188356028787.issue9886@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The observation has been made that there are some idioms related to key functions passed to various methods and functions that aren't particularly easy to discover.

One suggestion is to create a "key function" glossary entry that provides examples of standard library operations that exist primarily for use as key functions (i.e. the three functions mentioned in the issue title), as well as mentioning some of the APIs that accept key functions (e.g. sorted, list.sort, min, max). The documentation of these various could then cross link to the "key function" glossary entry to make this idioms more discoverable without needing to repeat ourselves in the documentation of every method that accepts a key function.

As per discussion on python-ideas, including the glossary entry suggestion from Terry Reedy:
http://mail.python.org/pipermail/python-ideas/2010-September/008093.html

----------
assignee: docs at python
components: Documentation
messages: 116658
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Make operator.itemgetter/attrgetter/methodcaller easier to discover
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9886>
_______________________________________

From report at bugs.python.org  Fri Sep 17 14:39:25 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 17 Sep 2010 12:39:25 +0000
Subject: [issue9886] Make operator.itemgetter/attrgetter/methodcaller easier
	to discover
In-Reply-To: <1284725606.32.0.188356028787.issue9886@psf.upfronthosting.co.za>
Message-ID: <1284727165.97.0.157227057133.issue9886@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9886>
_______________________________________

From report at bugs.python.org  Fri Sep 17 14:51:56 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 12:51:56 +0000
Subject: [issue1690840] xmlrpclib methods submit call on __str__, __repr__
Message-ID: <1284727916.22.0.376577462975.issue1690840@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

This has been fixed in py3k but not 2.7.  Is it worth backporting the change?

----------
nosy: +BreamoreBoy
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1690840>
_______________________________________

From report at bugs.python.org  Fri Sep 17 14:58:19 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 12:58:19 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1284728299.21.0.70111973996.issue1692335@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Fri Sep 17 15:07:29 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 13:07:29 +0000
Subject: [issue1693546] email.Message set_param rfc2231 encoding incorrect
Message-ID: <1284728849.72.0.708057747009.issue1693546@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693546>
_______________________________________

From report at bugs.python.org  Fri Sep 17 15:19:53 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 17 Sep 2010 13:19:53 +0000
Subject: [issue9887] distutil's build_scripts doesn't read utf-8 in all locales
In-Reply-To: <1284729593.16.0.252664137674.issue9887@psf.upfronthosting.co.za>
Message-ID: <1284729593.16.0.252664137674.issue9887@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

"LANG=C python3 setup.py build_scripts" chokes on UTF-8 encoded scripts. The problem is that "copy_scripts" uses "open" without specifying an encoding. This issue may be related to #9561.

----------
assignee: tarek
components: Distutils
messages: 116660
nosy: eric.araujo, hagen, tarek
priority: normal
severity: normal
status: open
title: distutil's build_scripts doesn't read utf-8 in all locales
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9887>
_______________________________________

From report at bugs.python.org  Fri Sep 17 15:29:46 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 13:29:46 +0000
Subject: [issue1699594] shlex fails to parse strings correctly
Message-ID: <1284730186.0.0.917282711738.issue1699594@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

@Georg: seems like your r55549 and r55550 fixed this, am I correct?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699594>
_______________________________________

From report at bugs.python.org  Fri Sep 17 15:38:57 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 13:38:57 +0000
Subject: [issue1703592] have a way to ignore nonexisting locales in
	locale.setlocale
Message-ID: <1284730737.82.0.811431373168.issue1703592@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this still an issue on Debian and Ubuntu?

----------
nosy: +BreamoreBoy, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1703592>
_______________________________________

From report at bugs.python.org  Fri Sep 17 15:43:14 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Sep 2010 13:43:14 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1284730994.47.0.214708209747.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

>From the python-dev thread (http://mail.python.org/pipermail/python-dev/2010-September/103780.html):
==============
So the domain of any polymorphic text manipulation functions we define would be:
 - Unicode strings
 - byte sequences where the encoding is either:
   - a single byte ASCII superset (e.g. iso-8859-*, cp1252, koi8*, mac*)
   - an ASCII compatible multibyte encoding (e.g. UTF-8, EUC-JP)

Passing in byte sequences that are encoded using an ASCII incompatible
multibyte encoding (e.g. CP932, UTF-7, UTF-16, UTF-32, shift-JIS,
big5, iso-2022-*, EUC-CN/KR/TW) or a single byte encoding that is not
an ASCII superset (e.g. EBCDIC) will have undefined results.
==================

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Fri Sep 17 15:49:34 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 13:49:34 +0000
Subject: [issue1704474] optparse tests fail under Jython
Message-ID: <1284731374.07.0.122388251581.issue1704474@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

How do we find out which versions of optparse and test_optparse jython is currently using?

----------
nosy: +BreamoreBoy
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1704474>
_______________________________________

From report at bugs.python.org  Fri Sep 17 15:58:23 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 13:58:23 +0000
Subject: [issue1705393] Select() failure (race condition)
Message-ID: <1284731903.44.0.312657277687.issue1705393@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I've changed things in reply to msg85311, feel free to alter things again if you disagree.

----------
assignee:  -> docs at python
components: +Documentation -Extension Modules, Library (Lib)
nosy: +BreamoreBoy, docs at python
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705393>
_______________________________________

From report at bugs.python.org  Fri Sep 17 16:11:27 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 14:11:27 +0000
Subject: [issue1705520] pyunit should allow __unittest in locals to trim
	stackframes
Message-ID: <1284732687.43.0.210213816004.issue1705520@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

is this still relevant?

----------
nosy: +BreamoreBoy
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705520>
_______________________________________

From report at bugs.python.org  Fri Sep 17 16:14:08 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 17 Sep 2010 14:14:08 +0000
Subject: [issue1705520] pyunit should allow __unittest in locals to trim
	stackframes
Message-ID: <1284732848.11.0.485826207285.issue1705520@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

It is relevant and would be *possible* to implement. I'm not 100% convinced it is a good *enough* idea to make it worth adding though. I'd like to leave the issue open for the moment in case other people want to comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705520>
_______________________________________

From report at bugs.python.org  Fri Sep 17 16:14:43 2010
From: report at bugs.python.org (Colin Watson)
Date: Fri, 17 Sep 2010 14:14:43 +0000
Subject: [issue1703592] have a way to ignore nonexisting locales in
	locale.setlocale
Message-ID: <1284732883.21.0.404644655341.issue1703592@psf.upfronthosting.co.za>


Colin Watson <cjwatson at users.sourceforge.net> added the comment:

Yes, the same symptoms are still present.

I'd argue that it generally isn't an error in practice for applications, and thus the net effect of this exception is negative; it's extraordinarily rare for a crash to be preferable to running without localisation.  Adding a new function would help because I think it would be easier to persuade people to call a new function that just does what they want ("turn on localisation if possible") than to catch an exception (at which point they have to think "hm, could that exception be for some other reason than you-just-don't-have-that-locale", etc.).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1703592>
_______________________________________

From report at bugs.python.org  Fri Sep 17 16:28:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Sep 2010 14:28:00 +0000
Subject: [issue9885] Function Round does not work properly in some conditions
In-Reply-To: <1284723379.23.0.462202029266.issue9885@psf.upfronthosting.co.za>
Message-ID: <1284733680.56.0.00451300067875.issue9885@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please read

    http://docs.python.org/tutorial/floatingpoint.html

Although your case isn't directly covered there, the root cause is the same.  Floating point can't exactly represent 10.3.

Note that in Python2.7 and 3.x, the repr will be shortened to 10.3, so if you'd tried this there you would never have noticed the underlying issue.

If you need exact decimal arithmetic, use the Decimal module.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9885>
_______________________________________

From report at bugs.python.org  Fri Sep 17 16:35:57 2010
From: report at bugs.python.org (paontis)
Date: Fri, 17 Sep 2010 14:35:57 +0000
Subject: [issue9885] Function Round does not work properly in some conditions
In-Reply-To: <1284723379.23.0.462202029266.issue9885@psf.upfronthosting.co.za>
Message-ID: <1284734157.6.0.675786809168.issue9885@psf.upfronthosting.co.za>


paontis <paontis at gmail.com> added the comment:

ok thx very much for the explaination

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9885>
_______________________________________

From report at bugs.python.org  Fri Sep 17 16:43:46 2010
From: report at bugs.python.org (Swapnil Talekar)
Date: Fri, 17 Sep 2010 14:43:46 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284734626.27.0.316654335805.issue6627@psf.upfronthosting.co.za>


Swapnil Talekar <swapnil.st at gmail.com> added the comment:

As far as I know, the thread creation done in the file is not correct. While creating threads in C extension, there are certain rules to follow. Firstly, Python should be made thread-aware if it is not already i.e. call PyEval_InitThreads in the C callback function. After its creation, the thread should bootstrap to be able to execute Python code. It should create a new PyThreadState for itself by calling PyThreadState_New. For this, the thread should be passed the InterpreterState* through the entry function. Before executing any Python code, the thread should make sure that the current ThreadState * is corresponding to it by calling PyEval_RestoreThread.
Refer http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock

----------
nosy: +swapnil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Fri Sep 17 17:06:35 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 17 Sep 2010 15:06:35 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284735995.8.0.0825738666163.issue9877@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Fri Sep 17 17:08:16 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Sep 2010 15:08:16 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284736096.65.0.879743692532.issue6627@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Swapnil's analysis looks correct to me - there are certain rules you have to follow before calling back into the Python interpreter core. If you don't follow them, the behaviour you will get is completely undefined.

If the problem still occurs even when the C thread is correctly initialised for calling into the Python C API then this issue can be reopened.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Fri Sep 17 17:28:48 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 15:28:48 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284737328.05.0.64793036339.issue6627@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

One more thing:
in the sample code, the thread initializes no PyThreadState. So the ctypes callback creates a temporary PyThreadState just for the duration of the call.

This explains the difference between threading.local and _threading_local:

- threading.local() uses the PyThreadState to store its data: You get a new value on each call.
- _threading_local.local() uses a global dictionary indexed by the thread id: the same value is retained across call.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Fri Sep 17 17:40:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Sep 2010 15:40:24 +0000
Subject: [issue9882] abspath from directory
In-Reply-To: <1284682917.39.0.650396347526.issue9882@psf.upfronthosting.co.za>
Message-ID: <1284738024.82.0.745642213147.issue9882@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9882>
_______________________________________

From report at bugs.python.org  Fri Sep 17 17:43:18 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 15:43:18 +0000
Subject: [issue1706323] Updated ASTVisitor Classes
Message-ID: <1284738198.67.0.0639994208692.issue1706323@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this still relevant given the addition of the ast module in r64064?

----------
nosy: +BreamoreBoy
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706323>
_______________________________________

From report at bugs.python.org  Fri Sep 17 17:49:01 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 15:49:01 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284738541.03.0.65379568518.issue1708652@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Fri Sep 17 18:05:31 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 16:05:31 +0000
Subject: [issue1709112] test_1686475 of test_os & pagefile.sys
Message-ID: <1284739531.33.0.929043507216.issue1709112@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

@Brian/Tim the attached patches have not been applied, what do you make of this one?

----------
components: +Extension Modules -Windows
nosy: +BreamoreBoy, brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1709112>
_______________________________________

From report at bugs.python.org  Fri Sep 17 18:08:12 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 17 Sep 2010 16:08:12 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284739692.83.0.38392238528.issue1708652@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Does this request still stand? If so then I'll add it to the new regex module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Fri Sep 17 18:19:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 16:19:22 +0000
Subject: [issue1710703] zipfile.ZipFile behavior inconsistent.
Message-ID: <1284740362.41.0.45910177482.issue1710703@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I don't think the latest patch has been committed, could someone wave their magic wand please :)

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1710703>
_______________________________________

From report at bugs.python.org  Fri Sep 17 18:42:49 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 17 Sep 2010 16:42:49 +0000
Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode"
	parameter
In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za>
Message-ID: <1284741769.58.0.275642371394.issue2236@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed for py3k in r84861, release31-maint in r84863 and release27-maint in r84862.

Thanks for patch, Carlos Henrique Romano.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
_______________________________________

From report at bugs.python.org  Fri Sep 17 18:50:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 16:50:22 +0000
Subject: [issue1724822] provide a shlex.split alternative for Windows shell
	syntax
Message-ID: <1284742222.85.0.728842729818.issue1724822@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Already fixed by r55549 and r55550.

----------
nosy: +BreamoreBoy
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1724822>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:03:41 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 17:03:41 +0000
Subject: [issue1727418] xmlrpclib waits indefinately
Message-ID: <1284743021.98.0.115439482323.issue1727418@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can this be closed due to work on #6267?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1727418>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:05:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Sep 2010 17:05:07 +0000
Subject: [issue1724822] provide a shlex.split alternative for Windows shell
	syntax
Message-ID: <1284743107.91.0.769159170404.issue1724822@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, this feature request has not been satisfied.  Georg fixed some subsidiary issues, but they did not in fact address the feature request for an shlex.split equivalent for Windows.

Since no one has expressed interest in working on this, even though model code has been offered, I'm changing the resolution to languishing rather than reopening it.  Perhaps someone with an itch to scratch will decide to pick it up eventually.

----------
assignee: georg.brandl -> 
nosy: +r.david.murray
resolution: fixed -> 
status: closed -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1724822>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:05:56 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 17:05:56 +0000
Subject: [issue1729930] 2.5.1 latest svn fails test_curses and test_timeout
Message-ID: <1284743156.13.0.406760170107.issue1729930@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I can't believe that this is still relevant.

----------
nosy: +BreamoreBoy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1729930>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:11:20 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 17:11:20 +0000
Subject: [issue1730136] tkFont.__eq__ gives type error
Message-ID: <1284743480.23.0.125738163551.issue1730136@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I think this one line patch still needs applying.

----------
nosy: +BreamoreBoy
type:  -> behavior
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1730136>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:17:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Sep 2010 17:17:51 +0000
Subject: [issue1729930] 2.5.1 latest svn fails test_curses and test_timeout
Message-ID: <1284743871.22.0.919091565958.issue1729930@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The bug probably does still exist (see issue 7038 for a recent similar report).  However, without a repeatable test case we can't fix it, so leaving this closed is fine.  If the OP can still reproduce it we can try working on it again.

----------
nosy: +r.david.murray
resolution: out of date -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1729930>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:18:19 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 17:18:19 +0000
Subject: [issue1730372] Mesa with NPTL makes Python extensions crash with
	std::cerr
Message-ID: <1284743899.95.0.689566203001.issue1730372@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Could a Linux guru try to reproduce this with the latest trunk, thanks.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1730372>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:25:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 17:25:22 +0000
Subject: [issue1732367] Document the constants in the socket module
Message-ID: <1284744322.86.0.929366367298.issue1732367@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

msg67121 states proposed changes were lost :(

----------
nosy: +BreamoreBoy
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1732367>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:27:20 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 17 Sep 2010 17:27:20 +0000
Subject: [issue1724822] provide a shlex.split alternative for Windows shell
	syntax
Message-ID: <1284744440.54.0.1000646857.issue1724822@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Raymond Chen's blog today discusses CommandLineToArgvW, which is apparently an API that can parse command lines. It's not clear to me if this is actually called by the MSFT CRT:
http://blogs.msdn.com/b/oldnewthing/archive/2010/09/17/10063629.aspx

Here's the documentation for it:
http://msdn.microsoft.com/en-us/library/bb776391%28VS.85%29.aspx

I don't know if we could call this directly (or via ctypes), or if we could emulate it based on the documentation, which doesn't seem very complete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1724822>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:27:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Sep 2010 17:27:26 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284744446.62.0.904181913305.issue1708652@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I would say you should make the call on whether or not it is worth adding.  IIUC it would mean there was more than one way to do something (\Z vs 'exact'), so I personally am -0 on the feature request.  But I'm not a frequent regex user, so I don't think my opinion should count for much.

----------
assignee: niemeyer -> 
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:33:20 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 17:33:20 +0000
Subject: [issue1735509] Newer reply format for imap commands in imaplib.py
Message-ID: <1284744800.0.0.0556576728181.issue1735509@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is there any interest in the change proposed here?  If not I'll close in a few weeks time.  Note the patch does not include doc or unit test changes.

----------
nosy: +BreamoreBoy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1735509>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:33:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Sep 2010 17:33:50 +0000
Subject: [issue1732367] Document the constants in the socket module
Message-ID: <1284744830.82.0.202248612215.issue1732367@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Resolution "won't fix" is inappropriate.  We'd love to fix it, but someone has to volunteer to (re)write the doc update...

----------
nosy: +r.david.murray
resolution: wont fix -> 
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1732367>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:35:52 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 17:35:52 +0000
Subject: [issue1736792] dict reentrant/threading request
Message-ID: <1284744952.71.0.907918677746.issue1736792@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this something that should be taken up on python-dev?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1736792>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:36:18 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 17 Sep 2010 17:36:18 +0000
Subject: [issue1735509] Newer reply format for imap commands in imaplib.py
Message-ID: <1284744978.06.0.682973898673.issue1735509@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm not sure what "fetch command does not contain literal" means. If the OP can clarify, I'd be interested in this issue.

----------
nosy: +eric.smith
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1735509>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:38:54 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 17 Sep 2010 17:38:54 +0000
Subject: [issue1724822] provide a shlex.split alternative for Windows shell
	syntax
Message-ID: <1284745134.02.0.737679718775.issue1724822@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Now that I think about this some more, we wouldn't want to call this API. I'd rather this hypothetical function be available on non-Windows platforms, so we'd have to implement the semantics of CommandLineToArgvW or whichever CRT we decide to match.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1724822>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:46:28 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 17:46:28 +0000
Subject: [issue1739789] Accelerate attr dict lookups
Message-ID: <1284745588.87.0.760737345715.issue1739789@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is there any interest in this or can it be closed as implied in msg52790?

----------
nosy: +BreamoreBoy, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739789>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:49:15 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 17:49:15 +0000
Subject: [issue1742205] ZipFile.writestr writes incorrect extended local
	headers
Message-ID: <1284745755.91.0.907524265123.issue1742205@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +alanmcintyre
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1742205>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:54:43 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 17:54:43 +0000
Subject: [issue1744456] Patch for feat. 1713877 Expose callbackAPI in readline
	module
Message-ID: <1284746083.45.0.13783817361.issue1744456@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is there anyone who'd like to see this functionality exposed who could review this C code patch?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1744456>
_______________________________________

From report at bugs.python.org  Fri Sep 17 19:59:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 17:59:22 +0000
Subject: [issue1744752] Newline skipped in "for line in file" for huge file
Message-ID: <1284746362.06.0.383649158124.issue1744752@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

@Brian/Tim any thoughts on this?

----------
nosy: +BreamoreBoy, brian.curtin, tim.golden
title: Newline skipped in "for line in file" -> Newline skipped in "for line in file" for huge file
versions: +Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1744752>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:02:50 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 18:02:50 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1284746570.49.0.351539914768.issue1745035@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Given the title, type and severity shouldn't someone take a look at this?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:15:23 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 18:15:23 +0000
Subject: [issue1745761] Bad attributes/data handling in SGMLib
Message-ID: <1284747323.71.0.835317499771.issue1745761@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can we close this as sgmllib only supported htmllib which has been superseded by HTMLParser?

----------
nosy: +BreamoreBoy
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745761>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:18:02 2010
From: report at bugs.python.org (Brian Bernstein)
Date: Fri, 17 Sep 2010 18:18:02 +0000
Subject: [issue9888] int overflow in datetime causes seg fault from
	datetime.ctime()
In-Reply-To: <1284747482.26.0.727712350645.issue9888@psf.upfronthosting.co.za>
Message-ID: <1284747482.26.0.727712350645.issue9888@psf.upfronthosting.co.za>


New submission from Brian Bernstein <bernie9998 at gmail.com>:

When creating an int overflow via a subtraction operation with a datetime object and a timedelta object, the resulting datetime object can cause a segmentation fault when the ctime method is called.

Segmentation Fault occurred on python 2.6.5 on 64 bit ubuntu lucid.

Code as follows:

from datetime import datetime, timedelta
(datetime.now() - timedelta(734395)).ctime()

----------
components: None
files: segfault.py
messages: 116700
nosy: bernie9998
priority: normal
severity: normal
status: open
title: int overflow in datetime causes seg fault from datetime.ctime()
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file18909/segfault.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9888>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:19:14 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 18:19:14 +0000
Subject: [issue1749512] imaplib cannot handle mailboxes with ACL: lrs
Message-ID: <1284747554.88.0.0614047082225.issue1749512@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

@Florian this won't go anywhere unles the patch includes doc and unit test changes.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1749512>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:20:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Sep 2010 18:20:12 +0000
Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode"
	parameter
In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za>
Message-ID: <1284747612.64.0.0362194838623.issue2236@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This update appears to be turning the windows buildbots red.  See for example http://www.python.org/dev/buildbot/all/builders/x86 XP-4 3.1/builds/1230/steps/test/logs/stdio.

----------
nosy: +r.david.murray
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:23:15 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 18:23:15 +0000
Subject: [issue1751519] curses - new window methods: addchstr and addchnstr
Message-ID: <1284747795.87.0.46170178677.issue1751519@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Doc additions haven't been included with the patches.

----------
nosy: +BreamoreBoy
stage:  -> patch review
type:  -> feature request
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1751519>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:25:30 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 18:25:30 +0000
Subject: [issue1752919] Exception in HTMLParser for special JavaScript code
Message-ID: <1284747930.79.0.413674203267.issue1752919@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can't see much sense in keeping a duplicate open.

----------
nosy: +BreamoreBoy
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1752919>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:26:02 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Sep 2010 18:26:02 +0000
Subject: [issue9886] Make operator.itemgetter/attrgetter/methodcaller easier
	to discover
In-Reply-To: <1284725606.32.0.188356028787.issue9886@psf.upfronthosting.co.za>
Message-ID: <1284747962.6.0.363550056622.issue9886@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9886>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:27:12 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 18:27:12 +0000
Subject: [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1284748032.29.0.461452492383.issue1753718@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
assignee: barry -> docs at python
nosy: +docs at python
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1753718>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:31:20 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 18:31:20 +0000
Subject: [issue1757057] IDLE + BeautifulSoup = Error
Message-ID: <1284748280.91.0.798082015594.issue1757057@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can we close this given "This is caused by a bug in BeautifulSoup which was fixed in version 3.0.5." from msg84412?

----------
nosy: +BreamoreBoy
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757057>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:44:29 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Sep 2010 18:44:29 +0000
Subject: [issue1739789] Accelerate attr dict lookups
Message-ID: <1284749069.1.0.350927132136.issue1739789@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This was an interesting idea.  Essentially, it created cell-style objects for entries in a global dict so that functions using load_global could access and update the values directly.

All dicts paid a price for this, but only module dicts would benefit.  A more refined approach would be to create a custom dict type just for module globals.

Mark, you're right.  The patch appears to have been abandoned and not generated interest.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739789>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:46:30 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Sep 2010 18:46:30 +0000
Subject: [issue1744456] Patch for feat. 1713877 Expose callbackAPI in readline
	module
Message-ID: <1284749190.94.0.148401442943.issue1744456@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This appears to be a duplicate of Issue1175004; both supply patches to implement readline callbacks.  Suggest that anyone moving forward with this review both patches.

----------
nosy: +ned.deily
resolution:  -> duplicate
superseder:  -> Export more libreadline API functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1744456>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:48:03 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Sep 2010 18:48:03 +0000
Subject: [issue1175004] Export more libreadline API functions
Message-ID: <1284749283.75.0.336224184643.issue1175004@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Issue1744456 contains a different patch to implement readline callbacks.  Suggest that anyone moving forward with this review both patches.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1175004>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:50:55 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Sep 2010 18:50:55 +0000
Subject: [issue1744752] Newline skipped in "for line in file" for huge file
Message-ID: <1284749455.13.0.374183277633.issue1744752@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

We need a reproducible test before being able to go forward with this.  At the very least, that would help isolate whether this is a build specific C library issue.

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1744752>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:58:22 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 17 Sep 2010 18:58:22 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284749902.85.0.0912884895974.issue6627@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

@Swapnil: the rules you quote are correct for the C extension, but do not apply when using ctypes, because ctypes is doing the required initializations automatically.

However, if Amaury is correct, ctypes performs the initializations in a way that break the threading.local functionality. 

I think the best way to address this bug would therefore be to add a warning to the ctypes documentation that C created threads will not support threading.local().

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:58:31 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 17 Sep 2010 18:58:31 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284749911.0.0.0835706193904.issue6627@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


----------
resolution: invalid -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Fri Sep 17 21:00:12 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 17 Sep 2010 19:00:12 +0000
Subject: [issue9441] increase logging handlers test coverage
In-Reply-To: <1280597180.41.0.450800729974.issue9441@psf.upfronthosting.co.za>
Message-ID: <1284750012.5.0.102153040363.issue9441@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Okay, the tests now pass and I've committed the path to py3k (r84864). Thanks, Tom and Alexander.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9441>
_______________________________________

From report at bugs.python.org  Fri Sep 17 21:05:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Sep 2010 19:05:19 +0000
Subject: [issue9888] int overflow in datetime causes seg fault from
	datetime.ctime()
In-Reply-To: <1284747482.26.0.727712350645.issue9888@psf.upfronthosting.co.za>
Message-ID: <1284750319.1.0.101468978946.issue9888@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9888>
_______________________________________

From report at bugs.python.org  Fri Sep 17 21:09:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Sep 2010 19:09:07 +0000
Subject: [issue9888] int overflow in datetime causes seg fault from
	datetime.ctime()
In-Reply-To: <1284747482.26.0.727712350645.issue9888@psf.upfronthosting.co.za>
Message-ID: <1284750547.37.0.55678155586.issue9888@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This does not reproduce for me on python2.6.5 gentoo linux; however, gentoo linux does have some additional post 2.6.5 patches applied.
It also does not reproduce on 2.7.

----------
nosy: +barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9888>
_______________________________________

From report at bugs.python.org  Fri Sep 17 21:28:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Sep 2010 19:28:17 +0000
Subject: [issue9441] increase logging handlers test coverage
In-Reply-To: <1280597180.41.0.450800729974.issue9441@psf.upfronthosting.co.za>
Message-ID: <1284751697.15.0.673553858532.issue9441@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It looks like we are getting buildbot failures as a result of this checkin:

  http://www.python.org/dev/buildbot/all/builders/i386 Ubuntu 3.x/builds/2216/steps/test/logs/stdio

----------
nosy: +r.david.murray
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9441>
_______________________________________

From report at bugs.python.org  Fri Sep 17 21:32:11 2010
From: report at bugs.python.org (Michael Kleehammer)
Date: Fri, 17 Sep 2010 19:32:11 +0000
Subject: [issue9889] PyUnicode_FormatV and Py_UNICODE*?
In-Reply-To: <1284751931.03.0.894481141092.issue9889@psf.upfronthosting.co.za>
Message-ID: <1284751931.03.0.894481141092.issue9889@psf.upfronthosting.co.za>


New submission from Michael Kleehammer <michael at kleehammer.com>:

Using Py_UNICODE* in Python 3 C extensions is significantly more cumbersome than using char* was in Python 2.x.  One addition that could help would be a Py_UNICODE* format type for PyUnicode_FormatV.

Many printf libraries us %S for wchar_t which would have been nicely analogous, but that is already taken for str(obj).

----------
components: Extension Modules, Interpreter Core
messages: 116714
nosy: mkleehammer
priority: normal
severity: normal
status: open
title: PyUnicode_FormatV and Py_UNICODE*?
type: feature request
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9889>
_______________________________________

From report at bugs.python.org  Fri Sep 17 21:32:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Sep 2010 19:32:21 +0000
Subject: [issue9888] int overflow in datetime causes seg fault from
	datetime.ctime()
In-Reply-To: <1284747482.26.0.727712350645.issue9888@psf.upfronthosting.co.za>
Message-ID: <1284751941.94.0.986036889549.issue9888@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9888>
_______________________________________

From report at bugs.python.org  Fri Sep 17 21:32:30 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Sep 2010 19:32:30 +0000
Subject: [issue1757057] Unexpected "maximum recursion depth exceeded" in IDLE
	shell with objects that cannot be pickled
Message-ID: <1284751950.77.0.410568161874.issue1757057@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

While BeautifulSoup may have been fixed, the issue here still points to an underlying problem in IDLE being vulnerable to pickling errors.  The given test case still fails in 2.7 (I didn't try to construct a test for Python 3).

----------
nosy: +kbk, ned.deily
resolution: invalid -> 
status: pending -> open
title: IDLE + BeautifulSoup = Error -> Unexpected "maximum recursion depth exceeded" in IDLE shell with objects that cannot be pickled
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757057>
_______________________________________

From report at bugs.python.org  Fri Sep 17 22:10:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Sep 2010 20:10:35 +0000
Subject: [issue9889] PyUnicode_FormatV and Py_UNICODE*?
In-Reply-To: <1284751931.03.0.894481141092.issue9889@psf.upfronthosting.co.za>
Message-ID: <1284754235.98.0.121953938773.issue9889@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9889>
_______________________________________

From report at bugs.python.org  Fri Sep 17 22:11:24 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 20:11:24 +0000
Subject: [issue1744752] Newline skipped in "for line in file" for huge file
Message-ID: <1284754284.21.0.0958011972447.issue1744752@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think there's actually a bug in the MSVCRT read() function, which was not too hard to spot (see explanation below).  In short, a CRLF file opened in text mode may skip a newline after 4GB.

I'm re-closing the issue as "won't fix". There's really nothing we can do about it.  But note that Python 3.x is not affected (raw files are always opened in binary mode and CRLF translation is done by Python); with 2.7, you may use io.open().

Other issues: issue1142, issue1672853, issue1451466 also report the same end-of-line issue on Windows (I just searched for "windows gb" in the tracker...) I'll close them as well.

Now, the explanation of the bug; it's not easy to reproduce because it depends both on the internal FILE buffer size and the number of chars passed to fread().
In the Microsoft CRT source code, in open.c, there is a block starting with this encouraging comment "This is the hard part.  We found a CR at end of buffer.  We must peek ahead to see if next char is an LF."
Oddly, there is an almost exact copy of this function in Perl source code:
http://perl5.git.perl.org/perl.git/blob/4342f4d6df6a7dfa22a470aa21e54a5622c009f3:/win32/win32.c#l3668
The problem is in the call to SetFilePointer(), used to step back one position after the lookahead; it will fail because it is unable to return the current position in a 32bit DWORD. [The fix is easy; do you see it?]
At this point, the function thinks that the next read() will return the LF, but it won't because the file pointer was not moved back.

----------
nosy: +amaury.forgeotdarc
resolution: invalid -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1744752>
_______________________________________

From report at bugs.python.org  Fri Sep 17 22:20:22 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 20:20:22 +0000
Subject: [issue1142] code sample showing errors reading large files with py
	2.5/3.0
In-Reply-To: <1189439562.54.0.204300359031.issue1142@psf.upfronthosting.co.za>
Message-ID: <1284754822.06.0.624472901641.issue1142@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

issue1744752 describes why it's probably a bug in the C library.
possible workarounds are to open the files in universal mode, to use io.open(), or to switch to python 3!

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> closed
superseder:  -> Newline skipped in "for line in file" for huge file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1142>
_______________________________________

From report at bugs.python.org  Fri Sep 17 22:21:28 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 20:21:28 +0000
Subject: [issue1672853] Error reading files larger than 4GB
Message-ID: <1284754888.79.0.406194819964.issue1672853@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

issue1744752 describes why it's probably a bug in the C library.
possible workarounds are to open the files in universal mode, to use io.open(), or to switch to python 3!

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> closed
superseder:  -> Newline skipped in "for line in file" for huge file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672853>
_______________________________________

From report at bugs.python.org  Fri Sep 17 22:22:27 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 20:22:27 +0000
Subject: [issue1451466] reading very large files
Message-ID: <1284754947.28.0.977257567099.issue1451466@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

issue1744752 describes why it's probably a bug in the C library.
possible workarounds are to open the files in universal mode, to use io.open(), or to switch to python 3!

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> closed
superseder:  -> Newline skipped in "for line in file" for huge file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1451466>
_______________________________________

From report at bugs.python.org  Fri Sep 17 22:49:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 20:49:25 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284756565.71.0.0674315477993.issue6627@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> ctypes performs the initializations in a way that break the
> threading.local functionality. 

Not quite. ctypes (or more exactly: the PyGILState_Ensure() and PyGILState_Release() functions, which are the standard API to do this) is in a situation where it must call Python code from a thread which has no PyThreadState.  So it creates a thread state, runs the code, and destroys the thread state; is this wrong?

If you want to keep Python state during your C thread, there are 4 lines to add to your function:

void *async_cb(void *dummy)
{
    PyGILState_STATE gstate = PyGILState_Ensure();
    Py_BEGIN_ALLOW_THREADS
    (*callback_fn)();
    (*callback_fn)();
    Py_END_ALLOW_THREADS
    PyGILState_Release(gstate);
    pthread_exit(NULL);
}

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Fri Sep 17 23:10:21 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 17 Sep 2010 21:10:21 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284757821.67.0.444558864846.issue6627@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

No, I am not saying that the behaviour of ctypes is wrong. It just happens to have some effects on threading.local that I think should be documented. That's why I reassigned this as a documentation bug. 

Please reconsider closing this bug. I'm also happy to change the type to "Feature request".


As an aside: I think in most cases one uses ctypes to call functions that are already compiled, so changing the source is not an option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Fri Sep 17 23:16:10 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 17 Sep 2010 21:16:10 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284758170.03.0.525759141973.issue6627@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

To be a bit more constructive, why not add something like this in paragraph to http://docs.python.org/library/ctypes.html#callback-functions:

"Note that if the callback function is called in a new thread that has been created outside of Python's control (i.e., by the foreign code that calls the callback), ctypes creates a new dummy Python thread on every invocation. That means that values stored with `threading.local` will *not* survive across different callbacks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Fri Sep 17 23:31:57 2010
From: report at bugs.python.org (Brian Bernstein)
Date: Fri, 17 Sep 2010 21:31:57 +0000
Subject: [issue9888] int overflow in datetime causes seg fault from
	datetime.ctime()
In-Reply-To: <1284747482.26.0.727712350645.issue9888@psf.upfronthosting.co.za>
Message-ID: <1284759117.95.0.331779490259.issue9888@psf.upfronthosting.co.za>


Brian Bernstein <bernie9998 at gmail.com> added the comment:

After further investigation, it appears the cause is the ability to overflow the datetime object by almost a year.  I've modified the test to demonstrate this relative to the current date:

from datetime import date, datetime, timedelta
(datetime.now()-timedelta((date.today()-date(1,1,1)).days+364)).ctime()

It seems the date can be overflowed by up to a year without throwing an Exception.  The result of which is a seg fault when calling the bound ctime method.

Note that anything above 364 results in OverFlowError.  Below 18 still overflows, but does not seg fault, instead resulting in a weird result,e.g.:
'Tue (null) 240 17:25:37 0001'

I'll update the script to demonstrate the edge cases where this occurs.

----------
Added file: http://bugs.python.org/file18910/segfault.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9888>
_______________________________________

From report at bugs.python.org  Fri Sep 17 23:48:41 2010
From: report at bugs.python.org (Tom Lynn)
Date: Fri, 17 Sep 2010 21:48:41 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284760121.12.0.271565371837.issue1708652@psf.upfronthosting.co.za>


Tom Lynn <tlynn at users.sourceforge.net> added the comment:

I don't know whether it should stand, I'm somewhere around 0 on it myself. So I guess that means it shouldn't, since it's easier to add features than remove them. The problem is that once you're aware of the need for it you need it less.

In case other people are +1, I'll note that "exact" isn't a very nice name either, not being a verb. "exact_match" is a bit long but probably better (and better than "match_exact").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Sat Sep 18 00:13:22 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 22:13:22 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284761602.77.0.326757434443.issue6627@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is not specific to ctypes.
Please read http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock
specially the paragraph that says "...when threads are created from C...".
Is it explicit enough? How would you change it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Sat Sep 18 00:29:17 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 17 Sep 2010 22:29:17 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284762557.34.0.565606147859.issue6627@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

One point of ctypes is to save the user the trouble of having to create a full blown C extension, so I don't think it's reasonable to expect a ctypes user to have read the full C API documentation as well. Only a very small subset of the page that you gave is actually relevant for use with ctypes. Why not put this information where a ctypes user can find it easily?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Sat Sep 18 00:34:39 2010
From: report at bugs.python.org (lorph)
Date: Fri, 17 Sep 2010 22:34:39 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284762879.25.0.12705394816.issue8998@psf.upfronthosting.co.za>


lorph <lorph1 at gmail.com> added the comment:

May I recommend using libtomcrypt instead of openssl because of the advertising problem outlined here?

http://bugs.python.org/issue9119

In my opinion, libtomcrypt is easier to use and cleaner. It compiles on Windows without requiring Perl, and is free of the advertising clause in OpenSSL since it is public domain.

http://libtom.org/?page=features&newsitems=5&whatfile=crypt

----------
nosy: +lorph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 00:36:34 2010
From: report at bugs.python.org (Adam Olsen)
Date: Fri, 17 Sep 2010 22:36:34 +0000
Subject: [issue1736792] dict reentrant/threading request
Message-ID: <1284762994.99.0.653388697142.issue1736792@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

I don't believe there's anything to debate on this, so all it really needs is a patch, followed by getting someone to review and commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1736792>
_______________________________________

From report at bugs.python.org  Sat Sep 18 00:37:37 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 22:37:37 +0000
Subject: [issue1706323] Updated ASTVisitor Classes
Message-ID: <1284763057.12.0.421009847118.issue1706323@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Indeed, this module has little value now that ast.py is in stdlib.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706323>
_______________________________________

From report at bugs.python.org  Sat Sep 18 00:49:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Sep 2010 22:49:54 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284762879.25.0.12705394816.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284763787.27980.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> May I recommend using libtomcrypt instead of openssl because of the
> advertising problem outlined here?

Changing libraries because of an "advertising problem" doesn't sound
reasonable. The latter is much more easily solved than the former.

Besides, libtomcrypt doesn't seem to provide SSL or TLS support (at
least the Web page you linked to doesn't say so), so OpenSSL would still
be needed for the ssl module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:07:47 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 17 Sep 2010 23:07:47 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284764867.8.0.7270865895.issue8998@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

How about nss?  As a bonus, this would also avoid making more work for Fedora (<http://fedoraproject.org/wiki/FedoraCryptoConsolidation>).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:11:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Sep 2010 23:11:33 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284764867.8.0.7270865895.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284765088.27980.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> How about nss?  As a bonus, this would also avoid making more work for
> Fedora (<http://fedoraproject.org/wiki/FedoraCryptoConsolidation>).

Well, similar question: what will it bring and who will do the work? :)
(Fedora perhaps?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:14:49 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 17 Sep 2010 23:14:49 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284765088.27980.5.camel@localhost.localdomain>
Message-ID: <1284765278.22563.23.camel@radiator.bos.redhat.com>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

On Fri, 2010-09-17 at 23:11 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> > How about nss?  As a bonus, this would also avoid making more work for
> > Fedora (<http://fedoraproject.org/wiki/FedoraCryptoConsolidation>).
> 
> Well, similar question: what will it bring and who will do the work? :)
> (Fedora perhaps?)

Possibly me - if you'll take my patches :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:15:44 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 17 Sep 2010 23:15:44 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284765344.06.0.177940193309.issue8998@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

What it will bring: APIs which aren't absolutely insane; full SSL support; RSA, DSA, ECDSA, Diffie-Hellman, EC Diffie-Hellman, AES, Triple DES, DES, RC2, RC4, SHA-1, SHA-256, SHA-384, SHA-512, MD2, MD5, HMAC: Common cryptographic algorithms used in public-key and symmetric-key cryptography; simplified FIPS 140 validation; better licensing (MPL).

I'm interested in stuff based on nss, but I definitely won't promise to do the work.  Fortunately dmalcolm seems to be on top of that. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:20:33 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 17 Sep 2010 23:20:33 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284765633.85.0.647776571434.issue8998@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I should note that I can't touch anything to do with Elliptic Curve crypto.  I don't know if I can comment on the reasons for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:24:18 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 17 Sep 2010 23:24:18 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284765858.87.0.322163312127.issue8998@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

> I should note that I can't touch anything to do with Elliptic Curve crypto.  I don't know if I can comment on the reasons for that.

Hopefully anything ECC related can be done separately.  There's certainly no ECC APIs in Python now, so there would be no loss of functionality if any new crypto-related APIs didn't include ECC.  Later if someone is sufficiently interesting, they could add it to the base library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:26:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Sep 2010 23:26:37 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284765278.22563.23.camel@radiator.bos.redhat.com>
Message-ID: <1284765993.27980.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 17 septembre 2010 ? 23:14 +0000, Dave Malcolm a ?crit :
> Dave Malcolm <dmalcolm at redhat.com> added the comment:
> 
> On Fri, 2010-09-17 at 23:11 +0000, Antoine Pitrou wrote:
> > Antoine Pitrou <pitrou at free.fr> added the comment:
> > 
> > > How about nss?  As a bonus, this would also avoid making more work for
> > > Fedora (<http://fedoraproject.org/wiki/FedoraCryptoConsolidation>).
> > 
> > Well, similar question: what will it bring and who will do the work? :)
> > (Fedora perhaps?)
> 
> Possibly me - if you'll take my patches :)

Converting/rewriting _ssl.c while remaining compatible is certainly the
most interesting part, so I suggest you start with that if you are
motivated :)
You should also explain the rationale on the mailing-list, so that
interested people have a chance to offer advice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:27:54 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 23:27:54 +0000
Subject: [issue1730136] tkFont.__eq__ gives type error
Message-ID: <1284766074.73.0.840741229721.issue1730136@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r84865.

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1730136>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:29:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Sep 2010 23:29:57 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284766197.46.0.85904689057.issue8998@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:33:23 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 17 Sep 2010 23:33:23 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284766403.75.0.751614315215.issue8998@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

FWIW, one of my RH colleagues (John Dennis) has written a set of Python bindings for NSS:
  http://fedoraproject.org/wiki/Features/PythonNSS

(Though that seems to me to be a slightly different thing to a general-purpose crypto lib that happens to be written using NSS as an implementation detail)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:37:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Sep 2010 23:37:41 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1284766661.2.0.277817698604.issue767645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> No problems noted with a quick test of posixpath_darwin.patch 
> on 10.6 so looks good.

Ok thanks. Fix commited to 3.2 (r84866) and 2.7 (r84868). I kept my patch on macpath (supports_unicode_filenames=True) because it is still valid (even if it is not used). Or is it wrong that Mac OS 9 speaks unicode?

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:39:27 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 17 Sep 2010 23:39:27 +0000
Subject: [issue9441] increase logging handlers test coverage
In-Reply-To: <1280597180.41.0.450800729974.issue9441@psf.upfronthosting.co.za>
Message-ID: <1284766767.11.0.499907601884.issue9441@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Okay, I've temporarily commented out TimedRotatingFileHandlerTest tests, while I investigate further. Let's see how the buildbots cope now.

----------
resolution: fixed -> accepted
stage: committed/rejected -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9441>
_______________________________________

From report at bugs.python.org  Sat Sep 18 01:41:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Sep 2010 23:41:04 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1284766864.06.0.0532699489767.issue8589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't see any test_warnings anymore on http://code.google.com/p/bbreport/wiki/PythonBuildbotReport. Close this issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Sat Sep 18 02:55:46 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 18 Sep 2010 00:55:46 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284771346.49.0.906424573776.issue8998@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

libtomcrypt is a _great_ library.  That is what hashlib uses for the hash algorithms when OpenSSL is not available.

But the _primary_ reason for using OpenSSL is that it is the defacto open source location for the best architecture specific implementations of any hash and crypto algorithm.  OpenSSL outperforms libtomcrypt by a significant factor (easily 2x) in most cases.

The NSS everywhere effort mentioned in the fedora link sounds interesting.  I support having the ability to link against that instead of OpenSSL or copies of libtomcrypt but I am generally in favor of absolute performance per byte of all algorithms concerned being available.  (ie: don't force hashlib to stop using openssl, just provide an alternative).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 03:21:18 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 18 Sep 2010 01:21:18 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1284772878.46.0.538879641155.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I hope attached patch will fix this. I used shutil.copy2
to retain modified time. (Actually, I tested on VS8.0 with
equivalent change, I didn't test this file directly)

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file18911/py3k_supress_rebuild_of_openssl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Sat Sep 18 03:25:26 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 18 Sep 2010 01:25:26 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1284773126.85.0.889724157661.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is the result of second run.

------ ?????: ??????: _ssl, ??: Debug Win32 ------
?????????????????...
Can not find a suitable PERL:
 NO perl interpreters were found on this machine at all!
 Please install ActivePerl and ensure it appears on your path
No Perl installation was found. Existing Makefiles are used.
Found a working perl at 'None'
Found an SSL directory at '..\..\..\openssl-1.0.0a'
Executing ssl makefiles: nmake /nologo -f "ms\nt.mak"
Building OpenSSL
[40162 refs]
??????????...
_ssl.c
..\..\Modules\_ssl.c(583) : warning C4090: '=' : ??? 'const' ??????
..\..\Modules\_ssl.c(930) : warning C4090: '=' : ??? 'const' ??????
????????...
   ????? E:\python-dev\py3k\PC\VS8.0\\_ssl_d.lib ??????? E:\python-dev\py3k\PC\VS8.0\\_ssl_d.exp ????
?????? "file://E:\python-dev\py3k\PC\VS8.0\Win32-temp-Debug\_ssl\BuildLog.htm" ?????????
_ssl - ??? 0??? 2
========== ???: 1 ?????0 ???7 ???0 ???? ==========

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Sat Sep 18 03:54:37 2010
From: report at bugs.python.org (Dylon)
Date: Sat, 18 Sep 2010 01:54:37 +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: <1284774877.07.0.1280459876.issue9890@psf.upfronthosting.co.za>


New submission from Dylon <hydro56 at gmail.com>:

I attempt to run the program (IDLE) after a fresh install of Python x86 on windows 7 32-bit and it gives me this error:
"Runtime Error!

Program: C:\Program Files\Python\pythonw.exe


This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information."

----------
components: IDLE, Windows
messages: 116746
nosy: Hydro56
priority: normal
severity: normal
status: open
title: Visual C++ Runtime Library Error is there a fix?
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9890>
_______________________________________

From report at bugs.python.org  Sat Sep 18 04:20:38 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 18 Sep 2010 02:20:38 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284776438.15.0.270829513259.issue6627@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The suggestion in http://bugs.python.org/issue6627#msg116722 is a good one.

This a case where the user may legitimately not realise that threading.local is stored in the *temporary* state created by ctypes rather than in something more persistent inside the interpreter.

Since the ctypes state is per callback, it won't persist across calls, even when they're made from the same thread.

Suggested wording:
"""Note that if the callback function is called in a new thread that has been created outside of Python's control (i.e., by the foreign code that calls the callback), ctypes creates a new dummy Python thread on every invocation, including recreation of the thread local storage area. While this is correct for most purposes, it does mean that values stored with `threading.local` will *not* survive across different callbacks, even when those calls are made from the same C thread."""

----------
keywords: +easy
resolution: works for me -> 
stage: committed/rejected -> needs patch
status: closed -> open
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Sat Sep 18 04:25:38 2010
From: report at bugs.python.org (Jon Anglin)
Date: Sat, 18 Sep 2010 02:25:38 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1284776738.91.0.797978201487.issue9808@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

The _countof(_x_) macro expands to something like this:

    sizeof(_x_)/sizeof(_x_[0])

This was an attempt by Microsoft to mitigate some buffer overrun issues.  I have gotten in the habit of using it as it is less verbose.  I have uploaded a new issue9808.diff file that removes the _countof macro. I will leave it up to those with commit privileges which version gets checked in. Personally I like it because it clarifies the programmers intent. Why not introduce it to the Python code base?

----------
Added file: http://bugs.python.org/file18912/issue9808.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Sat Sep 18 04:56:00 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 18 Sep 2010 02:56:00 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1284778560.77.0.98041710536.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100918.zip is a new version of the regex module.

I've added 'pos' and 'endpos' arguments to regex.sub and regex.subn and refactored a little.

I can't think of any other features that need to be added or see any more speed improvements.

Have I missed anything important? :-)

----------
Added file: http://bugs.python.org/file18913/issue2636-20100918.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Sep 18 05:00:10 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 18 Sep 2010 03:00:10 +0000
Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode"
	parameter
In-Reply-To: <1284747612.64.0.0362194838623.issue2236@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=0wUM8_cbe6CNfs58_AZ4ZPeLBkdWNjiGQwB4E@mail.gmail.com>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I have skipped the mode tests on windows platforms, as they are not
really applicable.
Lets see the buildbots status and close the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
_______________________________________

From report at bugs.python.org  Sat Sep 18 05:14:54 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Sep 2010 03:14:54 +0000
Subject: [issue9842] Document ... used in recursive repr of containers
In-Reply-To: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>
Message-ID: <1284779694.9.0.482382113399.issue9842@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/issue9842>
_______________________________________

From report at bugs.python.org  Sat Sep 18 05:23:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Sep 2010 03:23:03 +0000
Subject: [issue9856] Change object.__format__(s) where s is non-empty to a
	DeprecationWarning
In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za>
Message-ID: <1284780183.54.0.791315946091.issue9856@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Perhaps this could be expanded to "Deprecation warnings in 3.3" with release-blocker priority to list all 3.2 PendingDWs. Once changes are made, it could be retitled "Removals in 3.4", with a new "Deprecation warnings in 3.4" added.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9856>
_______________________________________

From report at bugs.python.org  Sat Sep 18 05:32:09 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Sep 2010 03:32:09 +0000
Subject: [issue9859] Add tests to verify API match of modules with 2
	implementations
In-Reply-To: <1284558397.04.0.990092096712.issue9859@psf.upfronthosting.co.za>
Message-ID: <1284780729.05.0.0799965339751.issue9859@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

+1
I presume you can use the experience with #9858 to either refine the program to have fewer false positives or refine the program doc to explain the possibility where such are unavoidable. (And as a lint-like metatest, I think false positives are better than false negatives.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9859>
_______________________________________

From report at bugs.python.org  Sat Sep 18 05:40:57 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Sep 2010 03:40:57 +0000
Subject: [issue9871] IDLE dies when using some regex
In-Reply-To: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>
Message-ID: <1284781257.62.0.575921657851.issue9871@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Verified as IDLE specific on WinXP, 3.1.2

With interpreter, I get
>>> import re; re.findall(b"\x.{2}", b"sdds\xd8")
ValueError: invalid \x escape

In an IDLE Shell window, the window immediately disappears when I hit return and the taskbar button disappears about a third of a second later.

----------
nosy: +terry.reedy
stage:  -> unit test needed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9871>
_______________________________________

From report at bugs.python.org  Sat Sep 18 05:43:46 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Sep 2010 03:43:46 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1284781426.11.0.333882446998.issue9884@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Sat Sep 18 06:13:28 2010
From: report at bugs.python.org (Joseph Walton)
Date: Sat, 18 Sep 2010 04:13:28 +0000
Subject: [issue923697] SAX2 'property_encoding' feature not supported
Message-ID: <1284783208.37.0.25572524732.issue923697@psf.upfronthosting.co.za>


Joseph Walton <josephw at users.sourceforge.net> added the comment:

The behaviour is unchanged in Python 3.1 and the sample program still fails.

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue923697>
_______________________________________

From report at bugs.python.org  Sat Sep 18 08:34:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Sep 2010 06:34:48 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284791688.5.0.162772368805.issue1708652@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm not sure it really is so useful that it warrants a new regex method.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Sat Sep 18 09:56:10 2010
From: report at bugs.python.org (geremy condra)
Date: Sat, 18 Sep 2010 07:56:10 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284771346.49.0.906424573776.issue8998@psf.upfronthosting.co.za>
Message-ID: <AANLkTikSQYHzOzdu1JbC=nsxLsn=Dy6DwWKYd=6i=juk@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Fri, Sep 17, 2010 at 8:55 PM, Gregory P. Smith
<report at bugs.python.org> wrote:
>
> Gregory P. Smith <greg at krypto.org> added the comment:
>
> libtomcrypt is a _great_ library. ?That is what hashlib uses for the hash algorithms when OpenSSL is not available.
>
> But the _primary_ reason for using OpenSSL is that it is the defacto open source location for the best architecture specific implementations of any hash and crypto algorithm. ?OpenSSL outperforms libtomcrypt by a significant factor (easily 2x) in most cases.
>
> The NSS everywhere effort mentioned in the fedora link sounds interesting. ?I support having the ability to link against that instead of OpenSSL or copies of libtomcrypt but I am generally in favor of absolute performance per byte of all algorithms concerned being available. ?(ie: don't force hashlib to stop using openssl, just provide an alternative).

I'm open to working with other libraries, but realistically there
isn't a huge point in supporting every crypto library out there, and
it would be a bad idea all around to try. My suggestion would be that
we stick with OpenSSL until a replacement for _ssl.c exists; after
that we can revisit that decision and see where we stand.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Sep 18 11:11:22 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sat, 18 Sep 2010 09:11:22 +0000
Subject: [issue9891] Minor doc typo at datamodel.rst: "list" -> "alist"
In-Reply-To: <1284801081.96.0.0540649030597.issue9891@psf.upfronthosting.co.za>
Message-ID: <1284801081.96.0.0540649030597.issue9891@psf.upfronthosting.co.za>


New submission from Rodrigo Bernardo Pimentel <rbp at isnomore.net>:

The "Built-in methods" item of the "The standard type hierarchy" section of Doc/reference/datamodels.rst uses a list instance called "alist" as an example, and it says "__self__ is set to the object denoted by *list*." It should read "the object denoted by *alist*"

This affects all releases, so I've marked them all. But I suppose we don't care about 2.5 anymore. All the others are listed on docs.python.org (or are "trunk"), and I think should be fixed.

It's a trivial fix, and a single patch works 2.x and another for 3.x.

----------
assignee: docs at python
components: Documentation
files: alist_doc-2.x.patch
keywords: patch
messages: 116757
nosy: docs at python, rbp
priority: normal
severity: normal
status: open
title: Minor doc typo at datamodel.rst: "list" -> "alist"
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18914/alist_doc-2.x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9891>
_______________________________________

From report at bugs.python.org  Sat Sep 18 11:11:46 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sat, 18 Sep 2010 09:11:46 +0000
Subject: [issue9891] Minor doc typo at datamodel.rst: "list" -> "alist"
In-Reply-To: <1284801081.96.0.0540649030597.issue9891@psf.upfronthosting.co.za>
Message-ID: <1284801106.87.0.610160548914.issue9891@psf.upfronthosting.co.za>


Changes by Rodrigo Bernardo Pimentel <rbp at isnomore.net>:


Added file: http://bugs.python.org/file18915/alist_doc-3.x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9891>
_______________________________________

From report at bugs.python.org  Sat Sep 18 11:40:05 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 18 Sep 2010 09:40:05 +0000
Subject: [issue9189] Improve CFLAGS handling
In-Reply-To: <1278517873.84.0.191654592449.issue9189@psf.upfronthosting.co.za>
Message-ID: <1284802805.8.0.490010787182.issue9189@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

-1 for the changes. Please restore to previous state.
The patch break all uses of well documented  build variables.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9189>
_______________________________________

From report at bugs.python.org  Sat Sep 18 11:48:36 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Sat, 18 Sep 2010 09:48:36 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1284803316.37.0.779369929166.issue1625@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Sat Sep 18 12:14:55 2010
From: report at bugs.python.org (Florian Festi)
Date: Sat, 18 Sep 2010 10:14:55 +0000
Subject: [issue1675951] [gzip] Performance for small reads and fix seek problem
Message-ID: <1284804895.22.0.159199370234.issue1675951@psf.upfronthosting.co.za>


Florian Festi <florianfesti at users.sourceforge.net> added the comment:

I updated the performace script to Py3. You still need to change the import gzipnew line to actually load the modified module. Right now it just compares the stdlib gzip module to itself.

----------
Added file: http://bugs.python.org/file18916/test_gzip2-py3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Sat Sep 18 12:20:08 2010
From: report at bugs.python.org (Florian Festi)
Date: Sat, 18 Sep 2010 10:20:08 +0000
Subject: [issue1675951] [gzip] Performance for small reads and fix seek problem
Message-ID: <1284805208.59.0.0966073810805.issue1675951@psf.upfronthosting.co.za>


Florian Festi <florianfesti at users.sourceforge.net> added the comment:

Attached result of a run with stdlib gzip module only. Results indicate that performance still is as bad as on Python 2. The Python 3 gzip module also still makes use of tell() ans seek(). So both argument for including this patch are still valid.

Porting the patch will include some real work to get the bytes vs string split right.

----------
Added file: http://bugs.python.org/file18917/result-py3.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Sat Sep 18 12:48:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 18 Sep 2010 10:48:36 +0000
Subject: [issue9869] long_subtype_new segfault in pure-Python code
In-Reply-To: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>
Message-ID: <1284806916.59.0.040210151734.issue9869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Problem confirmed here; thanks for the report.

I think it's also a bug that after:

class A(object):
    def __long__(self):
        return 42

long(A()) returns an object of type 'int' rather than an object of type 'long'.  It's inconsistent with what happens with __trunc__, too:

>>> class A(object):
...     def __trunc__(self): return 42
... 
[37198 refs]
>>> long(A())
42L
[37201 refs]

What's a little bit odd is that there's a test for the __long__-returning-int behaviour in test_class that asserts the return type should be int.

Here's a patch that fixes the return type of long (and PyNumber_Long) to be long in these cases.

----------
keywords: +patch
Added file: http://bugs.python.org/file18918/issue9869.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9869>
_______________________________________

From report at bugs.python.org  Sat Sep 18 12:52:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 18 Sep 2010 10:52:17 +0000
Subject: [issue9869] long_subtype_new segfault in pure-Python code
In-Reply-To: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>
Message-ID: <1284807137.85.0.661111571809.issue9869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Removing 2.6 from the versions, since this isn't a security problem (as far as I know).

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9869>
_______________________________________

From report at bugs.python.org  Sat Sep 18 13:35:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 11:35:26 +0000
Subject: [issue1675951] Performance for small reads and fix seek problem
In-Reply-To: <1284805208.59.0.0966073810805.issue1675951@psf.upfronthosting.co.za>
Message-ID: <1284809720.3220.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Attached result of a run with stdlib gzip module only. Results
> indicate that performance still is as bad as on Python 2. The Python 3
> gzip module also still makes use of tell() ans seek(). So both
> argument for including this patch are still valid.

Performance is easily improved by wrapping the file object in a
io.BufferedReader or io.BufferedWriter:

Text 1 byte block test
Original gzip Write:    2.125 s Read:    0.683 s
New gzip      Write:    0.390 s Read:    0.240 s

Text 4 byte block test
Original gzip Write:    1.077 s Read:    0.351 s
New gzip      Write:    0.204 s Read:    0.132 s

Text 16 byte block test
Original gzip Write:    1.119 s Read:    0.353 s
New gzip      Write:    0.264 s Read:    0.137 s

Still, fixing the seek()/tell() issue would be nice.

----------
title: [gzip] Performance for small reads and fix seek problem -> Performance for small reads and fix seek problem

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Sat Sep 18 13:42:19 2010
From: report at bugs.python.org (Tom Lynn)
Date: Sat, 18 Sep 2010 11:42:19 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284810139.38.0.5835450273.issue1708652@psf.upfronthosting.co.za>


Tom Lynn <tlynn at users.sourceforge.net> added the comment:

I'm still unsure.  I think this confusion does cause bugs in real-world code.  Perhaps more prominence for \A and \Z in the docs?  There's already a section comparing regexps starting '^' with match under "Matching vs Searching".

The problem is basically that ^ and $ have weird semantics but are better recognised than \A and \Z.  Looking over the docs again I see that the docs for $ are still misleading, in a way that's related to this issue:

    foo matches both 'foo' and 'foobar', while the regular
    expression foo$ matches only 'foo'.

"foo$ matches only 'foo' (out of 'foo' and 'foobar')" is the correct interpretation of that, but it's easy to read it as "foo$ means exact_match('foo')", which is the misconception I was hoping to put to rest with this (foo$ also matches the 'foo' part of 'foo\nbar', even with flags=0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Sat Sep 18 13:57:28 2010
From: report at bugs.python.org (Tom Lynn)
Date: Sat, 18 Sep 2010 11:57:28 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284811048.19.0.0839128566658.issue1708652@psf.upfronthosting.co.za>


Tom Lynn <tlynn at users.sourceforge.net> added the comment:

Actually, looking at the second part of the docs for $ (on "foo.$") makes me think the main motivating case here may be a bug in re.match::

    >>> re.match('foo$', 'foo\n\n')
    >>> re.match('foo$', 'foo\n')
    <_sre.SRE_Match object at 0x00A98678>

Shortening an input string shouldn't ever cause it to match, should it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Sat Sep 18 14:03:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 12:03:09 +0000
Subject: [issue9869] long_subtype_new segfault in pure-Python code
In-Reply-To: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>
Message-ID: <1284811389.97.0.33703641199.issue9869@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What's a little bit odd is that there's a test for the __long__-
> returning-int behaviour in test_class that asserts the return type
> should be int.

If there is a test then the behaviour is probably deliberate, and changing it would break compatibility.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9869>
_______________________________________

From report at bugs.python.org  Sat Sep 18 14:11:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 12:11:54 +0000
Subject: [issue9888] int overflow in datetime causes seg fault from
	datetime.ctime()
In-Reply-To: <1284747482.26.0.727712350645.issue9888@psf.upfronthosting.co.za>
Message-ID: <1284811914.48.0.838648728329.issue9888@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently it has been fixed somewhere between 2.6.5 and 2.6.6. I get a segmentation fault in 2.6.5, but an OverflowError in all of {2.6.6, 2.7, 3.1, 3.2}.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9888>
_______________________________________

From report at bugs.python.org  Sat Sep 18 14:23:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 12:23:36 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284812616.15.0.681363404292.issue9877@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Barry's request looks reasonable. Any build information will have platform specificities to it.

On the other hand, this begs the question of why you want to access the Python makefile at all. Is there any information in there that isn't currently exposed? I think it would be nice if people could completely forget about the existence of that file, and instead have nice programmatic APIs to query properties they are interested in.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Sat Sep 18 14:44:37 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 18 Sep 2010 12:44:37 +0000
Subject: [issue9869] long_subtype_new segfault in pure-Python code
In-Reply-To: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>
Message-ID: <1284813877.92.0.130512704987.issue9869@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

There are plenty of tests that check implementation specific internal behaviors. I don't think the presence of test alone would mean that it can't be changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9869>
_______________________________________

From report at bugs.python.org  Sat Sep 18 14:48:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 12:48:19 +0000
Subject: [issue9869] long_subtype_new segfault in pure-Python code
In-Reply-To: <1284813877.92.0.130512704987.issue9869@psf.upfronthosting.co.za>
Message-ID: <1284814091.3220.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> There are plenty of tests that check implementation specific internal
> behaviors. I don't think the presence of test alone would mean that it
> can't be changed.

Right. In practice, returning a long instead of an int can produce bugs,
mainly because some C functions will only accept ints and refuse longs.

(which is the C functions' fault, but unless you want to find and fix
all of them (including perhaps in 3rd-party libraries), I think it's
better not to change the current behaviour)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9869>
_______________________________________

From report at bugs.python.org  Sat Sep 18 14:51:36 2010
From: report at bugs.python.org (Tom Lynn)
Date: Sat, 18 Sep 2010 12:51:36 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284814296.88.0.874928779874.issue1708652@psf.upfronthosting.co.za>


Tom Lynn <tlynn at users.sourceforge.net> added the comment:

Oh dear, I'm wrong on two fronts (I wish Roundup had post editing).

a) foo$ doesn't match the 'foo' part of 'foo\nbar' as I stated above, but does match the 'foo' part of 'foo\n'.
b) Obviously shortening an input string can cause it to match.  It's still weird though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Sat Sep 18 14:57:38 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 12:57:38 +0000
Subject: [issue1777398] IDLE Freezes After Running Scripts
Message-ID: <1284814658.2.0.238063921008.issue1777398@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777398>
_______________________________________

From report at bugs.python.org  Sat Sep 18 14:58:11 2010
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Sat, 18 Sep 2010 12:58:11 +0000
Subject: [issue9892] Event spends less time in wait() than requested
In-Reply-To: <1284814691.18.0.9754077779.issue9892@psf.upfronthosting.co.za>
Message-ID: <1284814691.18.0.9754077779.issue9892@psf.upfronthosting.co.za>


New submission from Dmitry Dvoinikov <dmitry at targeted.org>:

If you request Event.wait(x), the call consistently returns in less than x seconds.

Sample:
---------------------------------------------------------
from threading import Event
from time import time

e = Event()

before = time()
e.wait(0.1)
after = time()

print(after - before)

# under Python 3.1 prints 0.109999...
# under Python 3.2 prints 0.092999...
---------------------------------------------------------

----------
components: Library (Lib)
messages: 116772
nosy: ddvoinikov
priority: normal
severity: normal
status: open
title: Event spends less time in wait() than requested
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9892>
_______________________________________

From report at bugs.python.org  Sat Sep 18 15:11:01 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 13:11:01 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1284815461.68.0.0739276312219.issue1028@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Could someone with commit privileges please review the patch with a view to committing, thanks.

----------
nosy: +BreamoreBoy, terry.reedy
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Sat Sep 18 15:13:46 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 13:13:46 +0000
Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as
	Python comments
In-Reply-To: <1188181252.17.0.123349198402.issue1034@psf.upfronthosting.co.za>
Message-ID: <1284815626.83.0.238329391054.issue1034@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Removed 2.7 as too late, can we get this into 3.2?

----------
nosy: +BreamoreBoy
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1034>
_______________________________________

From report at bugs.python.org  Sat Sep 18 15:19:47 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 13:19:47 +0000
Subject: [issue1079] decode_header does not follow RFC 2047
In-Reply-To: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za>
Message-ID: <1284815987.78.0.6952328678.issue1079@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
stage: needs patch -> patch review
versions: +Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1079>
_______________________________________

From report at bugs.python.org  Sat Sep 18 15:25:02 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 13:25:02 +0000
Subject: [issue1128] msilib.Directory.make_short only handles file names with
	a single dot in them
In-Reply-To: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za>
Message-ID: <1284816302.92.0.120487940178.issue1128@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

@Brian/Tim do have have any input on this?  Also note that a similar patch exists on issue7639.

----------
nosy: +BreamoreBoy, brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1128>
_______________________________________

From report at bugs.python.org  Sat Sep 18 15:35:39 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 13:35:39 +0000
Subject: [issue1159] os.getenv() not updated after external module uses C
	putenv()
In-Reply-To: <1189668127.19.0.0258251668017.issue1159@psf.upfronthosting.co.za>
Message-ID: <1284816939.78.0.55923507737.issue1159@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can someone please comment on whether or not this issue is still valid.

----------
nosy: +BreamoreBoy
resolution: postponed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1159>
_______________________________________

From report at bugs.python.org  Sat Sep 18 15:46:51 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 13:46:51 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <1284817611.45.0.687118195429.issue1195@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

There's a one line patch in msg59242, could someone please take a look.  Apparantly py3k is not affected by this issue although I haven't tried it myself.

----------
nosy: +BreamoreBoy
stage: unit test needed -> patch review
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Sat Sep 18 15:50:36 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 13:50:36 +0000
Subject: [issue1215] Python hang when catching a segfault
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1284817836.91.0.791814404183.issue1215@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

There are several suggestions inline as how how the docs should be changed.

----------
assignee:  -> docs at python
nosy: +BreamoreBoy, docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1215>
_______________________________________

From report at bugs.python.org  Sat Sep 18 15:56:57 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 13:56:57 +0000
Subject: [issue1250] Building external modules using Sun Studio 12
In-Reply-To: <1191964251.86.0.558465608726.issue1250@psf.upfronthosting.co.za>
Message-ID: <1284818217.38.0.329493830893.issue1250@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is anyone out there using Sun Studio who can comment on this?  If there are no responses within a couple of weeks I'll close.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1250>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:05:08 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 14:05:08 +0000
Subject: [issue1257] atexit errors should result in nonzero exit code
In-Reply-To: <1192046186.55.0.804669715206.issue1257@psf.upfronthosting.co.za>
Message-ID: <1284818708.1.0.398038263954.issue1257@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can someone please review the attached patch with a view to committing, it contains doc and unit test changes.

----------
nosy: +BreamoreBoy
stage:  -> patch review
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1257>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:08:12 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 14:08:12 +0000
Subject: [issue1274] doctest fails to run file based tests with 8bit paths
In-Reply-To: <1192213919.32.0.843568182453.issue1274@psf.upfronthosting.co.za>
Message-ID: <1284818892.9.0.471629247544.issue1274@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


Removed file: http://bugs.python.org/file8527/bug_3740_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1274>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:10:55 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 14:10:55 +0000
Subject: [issue1274] doctest fails to run file based tests with 8bit paths
In-Reply-To: <1192213919.32.0.843568182453.issue1274@psf.upfronthosting.co.za>
Message-ID: <1284819055.66.0.375189971343.issue1274@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

The patch simply changes test_doctest, is it acceptable or not?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1274>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:15:09 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 14:15:09 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1284819309.4.0.722294700667.issue1322@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:20:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 14:20:56 +0000
Subject: [issue9892] Event spends less time in wait() than requested
In-Reply-To: <1284814691.18.0.9754077779.issue9892@psf.upfronthosting.co.za>
Message-ID: <1284819656.08.0.662073581621.issue9892@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It consistently doesn't here:
0.10013985633850098
0.1001589298248291
(etc.)

What system are you using? There are two factors:
- accuracy of the timeout in the wait() function
- accuracy of the results returned by time()

Apart from a possible bug in Python, both of these factors depend on the operating system.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9892>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:22:37 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 14:22:37 +0000
Subject: [issue1348] httplib closes socket, then tries to read from it
In-Reply-To: <1193532553.16.0.237482805264.issue1348@psf.upfronthosting.co.za>
Message-ID: <1284819757.57.0.313716336981.issue1348@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg114602 so I'll close in a couple of weeks unless anyone objects.

----------
nosy: +BreamoreBoy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1348>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:27:18 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 14:27:18 +0000
Subject: [issue1350] IDLE - CallTips enhancement - show full doc-string in new
	window
In-Reply-To: <1193540394.75.0.209428889105.issue1350@psf.upfronthosting.co.za>
Message-ID: <1284820038.22.0.0167067978573.issue1350@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

>From msg84550 "The added functionality is useful, but this patch is not the way to go".  Can this be closed as rejected, would the OP like to supply an updated patch, or what?

----------
nosy: +BreamoreBoy, terry.reedy
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1350>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:34:03 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 14:34:03 +0000
Subject: [issue1423] wave sunau aifc 16bit errors
In-Reply-To: <1194812128.3.0.121145701122.issue1423@psf.upfronthosting.co.za>
Message-ID: <1284820443.61.0.904556249245.issue1423@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this still valid?

----------
nosy: +BreamoreBoy -gvanrossum
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1423>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:37:11 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 14:37:11 +0000
Subject: [issue1429] FD leak in SocketServer
In-Reply-To: <1194870454.07.0.621713310435.issue1429@psf.upfronthosting.co.za>
Message-ID: <1284820631.93.0.797846867643.issue1429@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

This will go nowhere unless a patch is provided that contains code, doc and unit test changes.

----------
nosy: +BreamoreBoy
stage:  -> unit test needed
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1429>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:39:43 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 14:39:43 +0000
Subject: [issue1441] Cycles through ob_type aren't freed
In-Reply-To: <1195009292.31.0.0975446267952.issue1441@psf.upfronthosting.co.za>
Message-ID: <1284820783.85.0.578611822466.issue1441@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this still valid?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:51:51 2010
From: report at bugs.python.org (Jeff McNeil)
Date: Sat, 18 Sep 2010 14:51:51 +0000
Subject: [issue1429] FD leak in SocketServer
In-Reply-To: <1194870454.07.0.621713310435.issue1429@psf.upfronthosting.co.za>
Message-ID: <1284821511.43.0.0951483683947.issue1429@psf.upfronthosting.co.za>


Jeff McNeil <jeff at jmcneil.net> added the comment:

I'll see if I can get it to reproduce and put a patch together.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1429>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:53:33 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 14:53:33 +0000
Subject: [issue1452] subprocess's popen.stdout.seek(0) doesn't raise an error
In-Reply-To: <1195225008.73.0.984849336269.issue1452@psf.upfronthosting.co.za>
Message-ID: <1284821613.57.0.0524287642775.issue1452@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

@Brian/Tim what would you expect to happen here?

----------
nosy: +BreamoreBoy, brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1452>
_______________________________________

From report at bugs.python.org  Sat Sep 18 16:55:52 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 14:55:52 +0000
Subject: [issue1458] installer crashes on attempted cancellation
In-Reply-To: <1195424067.48.0.215930942967.issue1458@psf.upfronthosting.co.za>
Message-ID: <1284821752.84.0.184685684296.issue1458@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg85633.

----------
nosy: +BreamoreBoy
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1458>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:06:37 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:06:37 +0000
Subject: [issue1483] xml.sax.saxutils.prepare_input_source ignores character
	stream in InputSource
In-Reply-To: <1195653795.8.0.542576278207.issue1483@psf.upfronthosting.co.za>
Message-ID: <1284822397.08.0.76005648511.issue1483@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

There's a one line patch in msg57749 and some unit tests are attached so would a committer take a look please.  Also note that #2174 and #2175 are related.

----------
nosy: +BreamoreBoy
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1483>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:10:38 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:10:38 +0000
Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100
In-Reply-To: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za>
Message-ID: <1284822638.37.0.317422714571.issue1491@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


Removed file: http://bugs.python.org/file10269/BaseHTTPServer_continue.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:10:59 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:10:59 +0000
Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100
In-Reply-To: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za>
Message-ID: <1284822659.2.0.181819343329.issue1491@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


Removed file: http://bugs.python.org/file10278/BaseHTTPRequestHandlerTestCase.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:11:11 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:11:11 +0000
Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100
In-Reply-To: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za>
Message-ID: <1284822671.71.0.202254516128.issue1491@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


Removed file: http://bugs.python.org/file10684/BaseHTTPServer_continue_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:11:25 2010
From: report at bugs.python.org (jeroen)
Date: Sat, 18 Sep 2010 15:11:25 +0000
Subject: [issue1423] wave sunau aifc 16bit errors
In-Reply-To: <1284820443.61.0.904556249245.issue1423@psf.upfronthosting.co.za>
Message-ID: <AANLkTinW3=Yk8i9o0Nv3q_yvgsCyMJRcTpt4-cbaDr3D@mail.gmail.com>


jeroen <jjkeizer at gmail.com> added the comment:

as far as I know. But i have not use or tested it since a long time

On Sat, Sep 18, 2010 at 4:34 PM, Mark Lawrence <report at bugs.python.org>wrote:

>
> Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:
>
> Is this still valid?
>
> ----------
> nosy: +BreamoreBoy -gvanrossum
> versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1423>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file18919/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1423>
_______________________________________
-------------- next part --------------
as far as I know. But i have not use or tested it since a long time<br><br><div class="gmail_quote">On Sat, Sep 18, 2010 at 4:34 PM, Mark Lawrence <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
Mark Lawrence &lt;<a href="mailto:breamoreboy at yahoo.co.uk">breamoreboy at yahoo.co.uk</a>&gt; added the comment:<br>
<br>
Is this still valid?<br>
<br>
----------<br>
nosy: +BreamoreBoy -gvanrossum<br>
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0<br>
<br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
<div class="im">&lt;<a href="http://bugs.python.org/issue1423" target="_blank">http://bugs.python.org/issue1423</a>&gt;<br>
</div>_______________________________________<br>
</blockquote></div><br>

From report at bugs.python.org  Sat Sep 18 17:13:24 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:13:24 +0000
Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100
In-Reply-To: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za>
Message-ID: <1284822804.15.0.975843497744.issue1491@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:15:31 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:15:31 +0000
Subject: [issue1504] Add 2to3 fixer for (un)bound methods
In-Reply-To: <1196162321.58.0.597340041678.issue1504@psf.upfronthosting.co.za>
Message-ID: <1284822931.72.0.470669057752.issue1504@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg71746.

----------
nosy: +BreamoreBoy
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1504>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:15:53 2010
From: report at bugs.python.org (Adam Olsen)
Date: Sat, 18 Sep 2010 15:15:53 +0000
Subject: [issue1441] Cycles through ob_type aren't freed
In-Reply-To: <1195009292.31.0.0975446267952.issue1441@psf.upfronthosting.co.za>
Message-ID: <1284822953.31.0.0412424371024.issue1441@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

As far as I know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:21:01 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:21:01 +0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1284823261.35.0.596694126044.issue1518@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Closing as recommended in msg101239.

----------
nosy: +BreamoreBoy
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:22:20 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:22:20 +0000
Subject: [issue1532] Refleak run of test_tcl fails
In-Reply-To: <1196464643.1.0.5780121191.issue1532@psf.upfronthosting.co.za>
Message-ID: <1284823340.13.0.55351094073.issue1532@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I don't believe that this can still be an issue.

----------
nosy: +BreamoreBoy
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1532>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:24:53 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:24:53 +0000
Subject: [issue1540] Refleak tests: test_doctest and test_gc are failing
In-Reply-To: <1196606516.14.0.848950318684.issue1540@psf.upfronthosting.co.za>
Message-ID: <1284823493.47.0.338616241024.issue1540@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can we have an update on this please as it seems important.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:29:42 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:29:42 +0000
Subject: [issue1554] socketmodule cleanups: allow the use of keywords in
	socket functions
In-Reply-To: <1196784173.07.0.425557098914.issue1554@psf.upfronthosting.co.za>
Message-ID: <1284823782.33.0.0582039657443.issue1554@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Could someone please review the latest patch, I'd like to see the OP's work rewarded with the patch getting into 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1554>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:31:55 2010
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Sat, 18 Sep 2010 15:31:55 +0000
Subject: [issue9892] Event spends less time in wait() than requested
In-Reply-To: <1284814691.18.0.9754077779.issue9892@psf.upfronthosting.co.za>
Message-ID: <1284823915.02.0.150115993057.issue9892@psf.upfronthosting.co.za>


Dmitry Dvoinikov <dmitry at targeted.org> added the comment:

You are right, sorry. It's Windows XP Prof, Python 3.2a2.

The differences in OS may be the cause, but the problem doesn't appear in 3.1 on the same machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9892>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:32:16 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:32:16 +0000
Subject: [issue1574] Touchpad 2 Finger scroll does not work in IDLE on Mac
	(But scroll wheel of external mouse does)
In-Reply-To: <1205799861.09.0.525919108741.issue1574@psf.upfronthosting.co.za>
Message-ID: <1284823936.17.0.704020975391.issue1574@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +taleinat, terry.reedy
stage: unit test needed -> needs patch
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1574>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:33:58 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:33:58 +0000
Subject: [issue1584] Mac OS X: building with X11 Tkinter
In-Reply-To: <1197345898.75.0.132866639605.issue1584@psf.upfronthosting.co.za>
Message-ID: <1284824038.26.0.405825357048.issue1584@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

This will go nowhere unless someone supplies a patch.

----------
nosy: +BreamoreBoy
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1584>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:39:36 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:39:36 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1284824376.66.0.807453174672.issue1602@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

@Brian/Tim what's your take on this?

----------
nosy: +BreamoreBoy, brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:44:52 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:44:52 +0000
Subject: [issue1605] Semi autogenerated _types module
In-Reply-To: <1197510011.31.0.0381617184937.issue1605@psf.upfronthosting.co.za>
Message-ID: <1284824692.89.0.306188033955.issue1605@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this ever likely to go anywhere?  My understanding is that this would be difficult to do (or have I simply misread something?).  If I'm correct, wouldn't it be better to use our limited resources elsewhere?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1605>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:47:00 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 18 Sep 2010 15:47:00 +0000
Subject: [issue1441] Cycles through ob_type aren't freed
In-Reply-To: <1195009292.31.0.0975446267952.issue1441@psf.upfronthosting.co.za>
Message-ID: <1284824820.18.0.685814501769.issue1441@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> __dict__ = self in subclass of dict causes a memory leak?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:50:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 15:50:59 +0000
Subject: [issue9892] Event spends less time in wait() than requested
In-Reply-To: <1284823915.02.0.150115993057.issue9892@psf.upfronthosting.co.za>
Message-ID: <1284825054.3220.23.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> You are right, sorry. It's Windows XP Prof, Python 3.2a2.
> 
> The differences in OS may be the cause, but the problem doesn't appear
> in 3.1 on the same machine.

The implementation changed between 3.1 and 3.2. On 3.1, wait() with
timeout ran a polling loop until either the event was set or the delay
was expired (and it used time() itself, which kind of guarantees that
your case would always produce the expected result).

On 3.2, wait() with timeout simply calls the adequate OS function
(sem_timedwait under POSIX, WaitForSingleObject under Windows). It is
actually more precise, because the polling loop and its sleep() calls
are eliminated.

Also, I just traced the WaitForSingleObject call under a Windows VM, and
it gets called with the correct timeout value (100 ms).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9892>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:53:49 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 15:53:49 +0000
Subject: [issue1615] descriptor protocol bug
In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>
Message-ID: <1284825229.95.0.356161906785.issue1615@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

This is still an issue with the latest trunk.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615>
_______________________________________

From report at bugs.python.org  Sat Sep 18 17:57:03 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 18 Sep 2010 15:57:03 +0000
Subject: [issue1615] descriptor protocol bug
In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>
Message-ID: <1284825423.81.0.355419388529.issue1615@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I consider this to be a feature. Properties can raise AttributeError to defer to __getattr__.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615>
_______________________________________

From report at bugs.python.org  Sat Sep 18 18:01:05 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 16:01:05 +0000
Subject: [issue7225] fwrite() compiler warnings
In-Reply-To: <1256692580.97.0.277746602553.issue7225@psf.upfronthosting.co.za>
Message-ID: <1284825665.05.0.274933512681.issue7225@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

See also #1616 and #1621.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7225>
_______________________________________

From report at bugs.python.org  Sat Sep 18 18:06:26 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 16:06:26 +0000
Subject: [issue1616] compiler warnings
In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za>
Message-ID: <1284825986.25.0.810735533996.issue1616@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

How many warnings are we now getting on the buildbots?

----------
nosy: +BreamoreBoy
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616>
_______________________________________

From report at bugs.python.org  Sat Sep 18 18:10:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 16:10:38 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1284826238.17.0.620306132319.issue9552@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch works here (VS 2008).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Sat Sep 18 18:18:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 16:18:10 +0000
Subject: [issue1605] Semi autogenerated _types module
In-Reply-To: <1197510011.31.0.0381617184937.issue1605@psf.upfronthosting.co.za>
Message-ID: <1284826690.07.0.196238113599.issue1605@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the core issue is a disagreement on the way to go.

I would agree with Benjamin's and Christian's proposal, given that it's quite practical to implement. Guido's proposal means we would have to add new modules just so that the relevant C types can be exposed "at the right place".

The types module is generally used for low-level trickery (since most useful types are accessible from the builtin namespace), and IMO it makes sense to have a dedicated module for that.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1605>
_______________________________________

From report at bugs.python.org  Sat Sep 18 18:20:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 16:20:57 +0000
Subject: [issue9892] Event spends less time in wait() than requested
In-Reply-To: <1284814691.18.0.9754077779.issue9892@psf.upfronthosting.co.za>
Message-ID: <1284826857.52.0.564512727849.issue9892@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm closing because there doesn't seem to be a genuine bug in Python. But thanks for reporting anyway! The threading facilities in 3.2 need real-world testing.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9892>
_______________________________________

From report at bugs.python.org  Sat Sep 18 18:33:42 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 18 Sep 2010 16:33:42 +0000
Subject: [issue1605] Semi autogenerated _types module
In-Reply-To: <1197510011.31.0.0381617184937.issue1605@psf.upfronthosting.co.za>
Message-ID: <1284827622.04.0.212071787653.issue1605@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm still against collecting all types in one module. Closing.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1605>
_______________________________________

From report at bugs.python.org  Sat Sep 18 18:34:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 16:34:46 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

While trying out vim, I noticed that the files in Misc/Vim are very poor compared to what is otherwise provided by the vim community:
- highlighting including 3.x syntax: http://www.vim.org/scripts/script.php?script_id=974
- PEP 8 indentation: http://www.vim.org/scripts/script.php?script_id=974

Also, the vimrc uses "au BufRead,BufNewFile *.py" style selection, while the recommended modern style seems to use a ".vim/ftplugin" filetype-specific file instead.

Does it still make sense to maintain these files separately?

----------
components: Demos and Tools
messages: 116812
nosy: brett.cannon, pitrou
priority: low
severity: normal
status: open
title: Usefulness of the Misc/Vim/ files?
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Sat Sep 18 18:44:32 2010
From: report at bugs.python.org (Pino Toscano)
Date: Sat, 18 Sep 2010 16:44:32 +0000
Subject: [issue9894] wrong errno check
In-Reply-To: <1284828272.46.0.993131390334.issue9894@psf.upfronthosting.co.za>
Message-ID: <1284828272.46.0.993131390334.issue9894@psf.upfronthosting.co.za>


New submission from Pino Toscano <toscano.pino at tiscali.it>:

In Lib/test/test_subprocess.py there's a check of an errno value done against a number, instead of using the proper E* constants, which is not portable (POSIX does not specify any actual value of the E* constants).
This makes the test test_leaking_fds_on_error fail on OSes where the errno ENOENT has a value different than two (like on GNU/Hurd, for example).

The attached patch was done in the py3k branch, but the issue appears in any other branch (including trunk). Could you please fix the issue also in the active Python branches?

----------
components: Tests
files: errno_py3k.diff
keywords: patch
messages: 116813
nosy: pino
priority: normal
severity: normal
status: open
title: wrong errno check
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18920/errno_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9894>
_______________________________________

From report at bugs.python.org  Sat Sep 18 19:09:46 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 18 Sep 2010 17:09:46 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284829786.61.0.792561133944.issue9090@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Unfortunately, select doesn't necessarily update the timeout variable with the remaining time, so we can't rely on this. This would mean having the select enclosed within gettimeofday and friends, which seems a bit overkill...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Sat Sep 18 19:11:15 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 18 Sep 2010 17:11:15 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284829875.01.0.126491342579.issue9090@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

> Unfortunately, select doesn't necessarily update the timeout variable with the remaining time, so we can't rely on this. This would mean having the select enclosed within gettimeofday and friends, which seems a bit overkill...

How is it "overkill" to be correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Sat Sep 18 19:39:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 17:39:26 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1284829786.61.0.792561133944.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284831561.3220.28.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Unfortunately, select doesn't necessarily update the timeout variable
> with the remaining time, so we can't rely on this. This would mean
> having the select enclosed within gettimeofday and friends, which
> seems a bit overkill...

Well, given the general cost of Python function calls and bytecode
interpretation, it would probably not be much of a runtime overhead. So
it's mainly some additional, not very exciting code to write :-)

(luckily, in 3.2 we have a cross-platform gettimeofday() abstraction in
pytime.h which will ease things quite a bit)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Sat Sep 18 20:01:51 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 18 Sep 2010 18:01:51 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284832911.52.0.145853620109.issue9090@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Yes, I was concerned with the runtime overhead (especially under VMs, where clocks are emulated) and strace output ;-)
As for the dull code writting, I could give it a shot unless someone else wants to go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Sat Sep 18 20:03:58 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 18 Sep 2010 18:03:58 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1284833038.96.0.413905850155.issue2643@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Any thoughts on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
_______________________________________

From report at bugs.python.org  Sat Sep 18 20:17:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 18:17:21 +0000
Subject: [issue9894] wrong errno check
In-Reply-To: <1284828272.46.0.993131390334.issue9894@psf.upfronthosting.co.za>
Message-ID: <1284833841.6.0.241416838843.issue9894@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r84878 (3.2), r84879 (2.7) and r84880 (3.1). Thank you!

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9894>
_______________________________________

From report at bugs.python.org  Sat Sep 18 20:19:32 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 18 Sep 2010 18:19:32 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284833972.67.0.0305482954553.issue9090@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

@ehohenstein: sorry, I hadn't seen you'd already submitted a patch, so you may as well update it to take into account what was said above. Also, please note that this issue is not specific to windows, so it would be nice to fix it for Unices too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Sat Sep 18 20:24:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 18:24:56 +0000
Subject: [issue9895] Speed up test_subprocess
In-Reply-To: <1284834296.27.0.356977051477.issue9895@psf.upfronthosting.co.za>
Message-ID: <1284834296.27.0.356977051477.issue9895@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_subprocess is currently very slow and the main culprit is test_no_leaking (here, it takes 80s out of the 100s needed for the whole run). This tests spawns as many subprocesses as would be needed to reach the max file descriptor limit. Spawning a subprocess is a heavy operation and consequently the test is very long.

This patch adopts another approach: it opens many file descriptors (using os.open()) until the max fd limit is reached, closes some of them (10 is enough) and then launches a bunch of subprocesses in a loop to check that they succeed. Consequently, the test is very fast (even on a Windows VM in debug mode).

----------
components: Tests
files: noleaking.patch
keywords: patch
messages: 116821
nosy: brian.curtin, gregory.p.smith, pitrou, tim.golden
priority: normal
severity: normal
stage: patch review
status: open
title: Speed up test_subprocess
type: performance
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18921/noleaking.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9895>
_______________________________________

From report at bugs.python.org  Sat Sep 18 20:30:34 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 18:30:34 +0000
Subject: [issue1686] string.Template.safe_substitute fail when overriding
	pattern attribute
In-Reply-To: <1198301656.07.0.935231571982.issue1686@psf.upfronthosting.co.za>
Message-ID: <1284834634.84.0.896009758362.issue1686@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Well what is the decision?  FWIW I sway towards the +0 from msg112156 rather than the -0 from msg63791, but then what do I know?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1686>
_______________________________________

From report at bugs.python.org  Sat Sep 18 20:36:35 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 18:36:35 +0000
Subject: [issue1708] improvements for linecache
In-Reply-To: <1199024318.28.0.602984080184.issue1708@psf.upfronthosting.co.za>
Message-ID: <1284834995.18.0.394131433161.issue1708@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

@umaxx are you interested in taking this forward?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708>
_______________________________________

From report at bugs.python.org  Sat Sep 18 20:38:01 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 18:38:01 +0000
Subject: [issue1722] Undocumented urllib functions
In-Reply-To: <1199298780.6.0.893928826633.issue1722@psf.upfronthosting.co.za>
Message-ID: <1284835081.06.0.857929336418.issue1722@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
assignee: georg.brandl -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722>
_______________________________________

From report at bugs.python.org  Sat Sep 18 20:39:27 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 18 Sep 2010 18:39:27 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The attached patch adds the start, stop and step members to range objects, corresponding the contructor arguments. The patch also include tests and documentation changes.

----------
components: Interpreter Core
files: range_attrs.diff
keywords: patch
messages: 116824
nosy: durban
priority: normal
severity: normal
status: open
title: Introspectable range objects
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18922/range_attrs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Sat Sep 18 21:16:19 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 18 Sep 2010 19:16:19 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1284837379.27.0.292367636426.issue9893@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So the irony of saying that the files are poor is that I took that code from the highlight file from Vim itself and simply automated the creation of the files.

As for the more proper way of selecting when to apply the highlights, I would not be surprised that I am wrong.

The entire point of the Misc/Vim directory was so that we had files which were as up-to-date as svn is. I personally got tired of not having new keywords be recognized. I'm no Vim expert -- just a happy user -- so I'm sure there could be better out there. If we drop the files we will just have to go back to manually editing files to support new syntax until the community picks it up. But maybe devolving responsibility like that is not a bad thing.

And your link for the Python 3 syntax is incorrect; it's the same as the PEP 8 indentation file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Sat Sep 18 23:06:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 21:06:40 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1284844000.46.0.06347724494.issue9896@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/issue9896>
_______________________________________

From report at bugs.python.org  Sat Sep 18 23:12:46 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 18 Sep 2010 21:12:46 +0000
Subject: [issue9895] Speed up test_subprocess
In-Reply-To: <1284834296.27.0.356977051477.issue9895@psf.upfronthosting.co.za>
Message-ID: <AANLkTim=1zz9ABcOLxuM4RMz2cs8n5LjibV0VHUQ0+Jh@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Overall I like the approach.

A few questions / clarifications:

 is errno.EMFILE portable?  will that errno test work on both posix and
windows?

 should the is_resource_enabled('subprocess') stuff be preserved (why was it
there to begin with? because the old test took so long?)

----------
Added file: http://bugs.python.org/file18923/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9895>
_______________________________________
-------------- next part --------------
Overall I like the approach.<div><br>A few questions / clarifications:</div><div><br></div><div>??is errno.EMFILE portable? ??will that errno test work on both posix and windows?</div><div><br></div><div>??should the is_resource_enabled(&#39;subprocess&#39;) stuff be preserved (why was it there to begin with? because the old test took so long?)</div>

<div><br></div><meta charset="utf-8">

From report at bugs.python.org  Sat Sep 18 23:27:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 21:27:38 +0000
Subject: [issue9895] Speed up test_subprocess
In-Reply-To: <AANLkTim=1zz9ABcOLxuM4RMz2cs8n5LjibV0VHUQ0+Jh@mail.gmail.com>
Message-ID: <1284845251.3220.29.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> A few questions / clarifications:
> 
>  is errno.EMFILE portable?  will that errno test work on both posix and
> windows?

It does (tested under Linux and a Win64 VM).

>  should the is_resource_enabled('subprocess') stuff be preserved (why was it
> there to begin with? because the old test took so long?)

I guess the latter: the test was so long, especially on slow machines,
that it was only enabled selectively.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9895>
_______________________________________

From report at bugs.python.org  Sat Sep 18 23:30:13 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 18 Sep 2010 21:30:13 +0000
Subject: [issue9895] Speed up test_subprocess
In-Reply-To: <1284845251.3220.29.camel@localhost.localdomain>
Message-ID: <AANLkTinmAGXT9jvTyPFtOt9n+b9z9cgRrnbdcyOxuFQf@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

looks good to me.  commit it. :)

----------
Added file: http://bugs.python.org/file18924/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9895>
_______________________________________
-------------- next part --------------
looks good to me. ??commit it. :)<br><br><div class="gmail_quote"><br></div>

From report at bugs.python.org  Sat Sep 18 23:35:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 18 Sep 2010 21:35:11 +0000
Subject: [issue9895] Speed up test_subprocess
In-Reply-To: <1284834296.27.0.356977051477.issue9895@psf.upfronthosting.co.za>
Message-ID: <1284845711.16.0.91265382607.issue9895@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file18923/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9895>
_______________________________________

From report at bugs.python.org  Sat Sep 18 23:35:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 18 Sep 2010 21:35:21 +0000
Subject: [issue9895] Speed up test_subprocess
In-Reply-To: <1284834296.27.0.356977051477.issue9895@psf.upfronthosting.co.za>
Message-ID: <1284845721.53.0.525332828058.issue9895@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file18924/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9895>
_______________________________________

From report at bugs.python.org  Sat Sep 18 23:37:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 18 Sep 2010 21:37:07 +0000
Subject: [issue9895] Speed up test_subprocess
In-Reply-To: <1284834296.27.0.356977051477.issue9895@psf.upfronthosting.co.za>
Message-ID: <1284845827.41.0.905987620123.issue9895@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

+1 fo faster regrtest

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9895>
_______________________________________

From report at bugs.python.org  Sun Sep 19 00:06:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 22:06:18 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284847578.82.0.597723963929.issue9090@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a proof of concept patch for Python 3.2. It only wraps recv() and recv_into(). recvfrom() and recvfrom_into() should receive the same treatment, at least.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file18925/selectretry.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Sun Sep 19 00:06:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 22:06:44 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284847604.06.0.725480237575.issue9090@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Sun Sep 19 00:13:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 22:13:04 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284847984.63.0.986403373029.issue9090@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file18925/selectretry.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Sun Sep 19 00:13:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 22:13:23 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1284848003.91.0.217593148066.issue9090@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file18926/selectretry.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Sun Sep 19 00:37:35 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Sep 2010 22:37:35 +0000
Subject: [issue1686] string.Template.safe_substitute fail when overriding
	pattern attribute
In-Reply-To: <1198301656.07.0.935231571982.issue1686@psf.upfronthosting.co.za>
Message-ID: <1284849455.09.0.957786484111.issue1686@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg63791

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1686>
_______________________________________

From report at bugs.python.org  Sun Sep 19 00:39:10 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Sep 2010 22:39:10 +0000
Subject: [issue1686] string.Template.safe_substitute fail when overriding
	pattern attribute
In-Reply-To: <1198301656.07.0.935231571982.issue1686@psf.upfronthosting.co.za>
Message-ID: <1284849550.82.0.196992729048.issue1686@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This looks fine.

----------
assignee: barry -> 
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1686>
_______________________________________

From report at bugs.python.org  Sun Sep 19 00:44:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 22:44:58 +0000
Subject: [issue9895] Speed up test_subprocess
In-Reply-To: <1284834296.27.0.356977051477.issue9895@psf.upfronthosting.co.za>
Message-ID: <1284849898.75.0.0219267071844.issue9895@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Done, thank you.
(r84883, r84884, r84885)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9895>
_______________________________________

From report at bugs.python.org  Sun Sep 19 00:45:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Sep 2010 22:45:45 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284849945.0.0.384561116282.issue1708652@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Can we close this one?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Sun Sep 19 00:54:18 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 18 Sep 2010 22:54:18 +0000
Subject: [issue9810] bzip2 build sometimes fails (VS8.0)
In-Reply-To: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>
Message-ID: <1284850458.35.0.211577707374.issue9810@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Backported in r84881(release27-maint), r84886(release31-maint).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9810>
_______________________________________

From report at bugs.python.org  Sun Sep 19 00:54:22 2010
From: report at bugs.python.org (lorph)
Date: Sat, 18 Sep 2010 22:54:22 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284850462.96.0.244805154384.issue8998@psf.upfronthosting.co.za>


lorph <lorph1 at gmail.com> added the comment:

> OpenSSL outperforms libtomcrypt by a significant factor (easily 2x) in most cases.

Gregory, do you have any evidence to substantiate this claim? Not that it isn't plausible, but I couldn't find any benchmarks, and here the author of libtomcrypt finds it to be 40% faster than OpenSSL concerning RSA operations.

http://www.adras.com/TomsFastMath-faster.t71-93.html

>  but I am generally in favor of absolute performance per byte of all algorithms concerned being available

Performance isn't all that matters, or else Python would have used GMP, as Guido discussed here:

http://mail.python.org/pipermail/python-3000/2007-September/010329.html

It is also not a convincing argument that new python libraries should use OpenSSL if possible just because that is what _ssl uses. Compiling Python with OpenSSL support has been optional because it puts additional restrictions on the PSF license. Spreading this restriction to the future crypto module (when we have a choice not to) doesn't make sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 01:02:16 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Sep 2010 23:02:16 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1284850936.29.0.428541293194.issue9896@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I don't see anything wrong with this idea, but I don't really see a need for it either.  AFAICT, this has never been requested in the 20 years that range() has been in Python.  This is probably YAGNI.  It may also be in violation of the language moratorium (it's one more thing that other implementations would have to mirror).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Sun Sep 19 01:03:55 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 18 Sep 2010 23:03:55 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284851035.62.0.177372483458.issue1708652@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

'$' matches at the end of the string or at a newline at the end of a string (if multiline mode isn't turned on). '\Z' matches only at the end of the string.

If not even the OP is convinced of the need, then I have no objection to closing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Sun Sep 19 01:05:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 23:05:19 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284850462.96.0.244805154384.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284851113.3220.34.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It is also not a convincing argument that new python libraries should
> use OpenSSL if possible just because that is what _ssl uses. Compiling
> Python with OpenSSL support has been optional because it puts
> additional restrictions on the PSF license. Spreading this restriction
> to the future crypto module (when we have a choice not to) doesn't
> make sense.

It certainly makes more sense than making Python depend on *several*
crypto libraries.
As for the licensing restriction, it doesn't seem to disturb many Python
users. It's the first time I see someone complaining about it.

This isn't meant to discourage any such efforts (I don't care about
which crypto library we use), but any proposal of using another crypto
library than OpenSSL should IMO include a migration proposal for the
_ssl module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 01:15:40 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Sep 2010 23:15:40 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1284851740.92.0.464797955035.issue9896@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

One other thought.  If there is a perceived need, I would rather an alternate approach that unifies a language a bit by letting range() expose its arguments as a slice and modify its input to accept a slice.

>>> range(0, 20, 2).slice
slice(0, 20, 20)
>>> range(_)
range(0, 20, 2)

>>> s = range(0, 20, 2).slice
>>> s.start
0
>>> s.stop
20
>>> s.step
2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Sun Sep 19 01:22:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 23:22:03 +0000
Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode"
	parameter
In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za>
Message-ID: <1284852123.85.0.742871676454.issue2236@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

All buildbots are red.

----------
assignee: tarek -> orsenthil
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
_______________________________________

From report at bugs.python.org  Sun Sep 19 01:34:27 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Sep 2010 23:34:27 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284852867.72.0.422128523944.issue1708652@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Sun Sep 19 01:35:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 18 Sep 2010 23:35:20 +0000
Subject: [issue1686] string.Template.safe_substitute fail when overriding
	pattern attribute
In-Reply-To: <1198301656.07.0.935231571982.issue1686@psf.upfronthosting.co.za>
Message-ID: <1284852920.94.0.619004114855.issue1686@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Committed with r84888.

----------
assignee:  -> flox
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1686>
_______________________________________

From report at bugs.python.org  Sun Sep 19 02:09:00 2010
From: report at bugs.python.org (lorph)
Date: Sun, 19 Sep 2010 00:09:00 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284854940.27.0.852246255397.issue8998@psf.upfronthosting.co.za>


lorph <lorph1 at gmail.com> added the comment:

> It certainly makes more sense than making Python depend on *several* crypto libraries.

Since libtomcrypt is public domain, you could incorporate the source into the tree without making it a binary dependency. The same cannot be said for OpenSSL. I certainly wouldn't mind having 1 dependency on NSS, but having 2 modules depend on OpenSSL is a step in the wrong direction.

> As for the licensing restriction, it doesn't seem to disturb many Python users. It's the first time I see someone complaining about it.

It took several years until someone like Marc-Andre Lemburg to find that the Python website might be violating that license. Perhaps the reason is because no one bothers to read licenses carefully. People are probably violating the license without knowing it.

If you take a look at the clause "All advertising materials mentioning features or use of this software must display the following acknowledgment", you will find at least 2 problems. 

One is that if you mention something like "base64" in whatever could be deemed "advertising", you will be subject to this clause because base64 is a feature of OpenSSL, even if you don't use their implementation. Another problem is the difference between the clause "features or use of this software", which is semantically different from "features of this software or use of this software".

Is it worth the risk to depend on Eric Young's proclivity to sue now that he works for RSA and produces competing software called BSAFE? Maybe it is for you, but certainly not for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 02:13:02 2010
From: report at bugs.python.org (Tom Lynn)
Date: Sun, 19 Sep 2010 00:13:02 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1284855182.02.0.86487141542.issue1708652@psf.upfronthosting.co.za>


Tom Lynn <tlynn at users.sourceforge.net> added the comment:

(Sorry to comment on a closed issue, it was closed as I was writing this.)  It's not that I'm not convinced of the need, just not of the solution.  I still think that there are problems here:

a) forgetting any \Z or $ terminator to .match() is easy,
b) $ is easily misunderstood (and not just by me) and I suspect commonly dangerously misused in validation routines as a result,
c) '(?:%s)\Z' % regexp is noisy, combines two less-understood features, and makes simple regexps hard to read,
d) '(?:%s)\Z' % regexp.pattern requires recompilation of the regexp.

I think another method is probably the best solution to these, but it may have too much cost (though I'm not sure what that cost would be).

Largely orthogonally, I'd like to see \Z encouraged over $ in the docs, and preferably a version of this table (probably under Matching vs Searching), corrected if I'm wrong of course:

NON-MULTILINE:
    '^' is equivalent to '\A'
    '$' is equivalent to '(?:\Z|(?=\n\Z))'

MULTILINE:
    '^' is equivalent to '(?:\A|(?<=\n))'
    '$' is equivalent to '(?:\Z|(?=\n))'

But the docs already try to express the above table (or its correction) in English, so you may feel it wouldn't add anything, in which case I'd still like to see any corrections for my own edification if possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Sun Sep 19 02:37:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Sep 2010 00:37:08 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284854940.27.0.852246255397.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284856617.3220.49.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Since libtomcrypt is public domain, you could incorporate the source
> into the tree without making it a binary dependency.

And then we have to maintain our copy ourselves. I'm not sure why you
think this is better than depending on a system-wide install, because
it's certainly worse.

(we do have private copies of a couple of libraries: zlib, expat,
libffi. The first two are probably for historical reasons (the
system-wide versions are used by default), while the third is because
it's patched)

> I certainly wouldn't mind having 1 dependency on NSS, but having 2
> modules depend on OpenSSL is a step in the wrong direction.

Perhaps you wouldn't mind, but others would (especially packagers;
including ourselves since we build binary packages for Windows and Mac
OS X).

> It took several years until someone like Marc-Andre Lemburg to find
> that the Python website might be violating that license. Perhaps the
> reason is because no one bothers to read licenses carefully. People
> are probably violating the license without knowing it.

The solution to stop violating it is trivial, though: just add the
required mention(s).
Compare that to rewriting a lot of code and making sure it doesn't
change behaviour compared to previous Python versions.

> One is that if you mention something like "base64" in whatever could
> be deemed "advertising", you will be subject to this clause because
> base64 is a feature of OpenSSL, even if you don't use their
> implementation.

Unless "base64" is an OpenSSL trademark, this is FUD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 03:00:37 2010
From: report at bugs.python.org (lorph)
Date: Sun, 19 Sep 2010 01:00:37 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284858037.04.0.0899641274705.issue8998@psf.upfronthosting.co.za>


lorph <lorph1 at gmail.com> added the comment:

> The solution to stop violating it is trivial, though: just add the
required mention(s).

That only solves the problem for Python.org. It does not solve the problem for everyone else that has to write "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) This product includes cryptographic software written by Eric Young (eay at cryptsoft.com)" in advertisement that mentions features.

> Unless "base64" is an OpenSSL trademark, this is FUD.

The license clearly states: "All advertising materials mentioning features or use of this software". Do you somehow disagree that base64 is a feature of the OpenSSL library?

http://www.openssl.org/docs/crypto/BIO_f_base64.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 03:08:51 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 19 Sep 2010 01:08:51 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1284858531.56.0.529448325787.issue9896@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

What is the use case for this?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Sun Sep 19 03:16:11 2010
From: report at bugs.python.org (Damjan Georgievski)
Date: Sun, 19 Sep 2010 01:16:11 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284858971.49.0.968585700671.issue8998@psf.upfronthosting.co.za>


Changes by Damjan Georgievski <gdamjan at users.sourceforge.net>:


----------
nosy:  -gdamjan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 03:35:34 2010
From: report at bugs.python.org (Owen)
Date: Sun, 19 Sep 2010 01:35:34 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1284860134.51.0.362688769763.issue9884@psf.upfronthosting.co.za>


Owen <j2.nete at gmail.com> added the comment:

Please reproduce this issue by 64bit Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Sun Sep 19 03:56:20 2010
From: report at bugs.python.org (Carlos Henrique Romano)
Date: Sun, 19 Sep 2010 01:56:20 +0000
Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode"
	parameter
In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za>
Message-ID: <1284861380.43.0.179232944559.issue2236@psf.upfronthosting.co.za>


Carlos Henrique Romano <chromano at gmail.com> added the comment:

Updating test in order to consider umask, this is supposed to fix buildbot issues.

----------
Added file: http://bugs.python.org/file18927/python-distutils_mkpath_filemode-test-update.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
_______________________________________

From report at bugs.python.org  Sun Sep 19 06:21:43 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 19 Sep 2010 04:21:43 +0000
Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode"
	parameter
In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za>
Message-ID: <1284870103.83.0.598701583225.issue2236@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Buildbots are green now after fixing the mode issue in the tests in r84889,r84890,r84891

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
_______________________________________

From report at bugs.python.org  Sun Sep 19 08:11:45 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 19 Sep 2010 06:11:45 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284850462.96.0.244805154384.issue8998@psf.upfronthosting.co.za>
Message-ID: <AANLkTin06TWom3MtZujv4WGiouYB62v55hBFLnLRZXAu@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

This bug has turned into a bikeshed.

Lets stop that please.

I _DON'T_ care about performance when it comes to someone submitting an
actual working implementation of a crypto library for inclusion with the
standard library.  The first priority needs to be a useful stable API.

After that is settled, implementations backed by whatever libraries can be
written by anyone who wants to contribute them.  Lets not stop that from
happening by arguing about who's library is a prettier color.  The first one
may well be implemented in Python itself as a for all I care.

-gps

(comments below are to answer questions but really are not relevant to the
bug)

On Sat, Sep 18, 2010 at 3:54 PM, lorph <report at bugs.python.org> wrote:

>
> lorph <lorph1 at gmail.com> added the comment:
>
> > OpenSSL outperforms libtomcrypt by a significant factor (easily 2x) in
> most cases.
>
> Gregory, do you have any evidence to substantiate this claim? Not that it
> isn't plausible, but I couldn't find any benchmarks, and here the author of
> libtomcrypt finds it to be 40% faster than OpenSSL concerning RSA
> operations.
>

I should not have said "most" cases but there are many cases where it does.
 Run your own microbenchmarks on various hardware if you're curious
("openssl speed algorithmname" on the command line is an existing openssl
benchmark).  The important thing to realize is that libtomcrypt is
intentionally written in very portable C.  That is great but it leaves a lot
on the table.  Optimizations for various platforms to take advantage of
enhanced instruction sets such as SSE2 and explicit hardware crypto
acceleration instructions such as
http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-aes-instructions-set/are
not likely to be part of libtomcrypt, nor should they ever be part of
code included with and distributed as part of Python.  That should come from
a dynamic library that is part of the OS.  That may be NSS, that may be
OpenSSL, that may be any number of other things.  Its beyond the scope of
this bug.

I'm sorry for bringing the performance angle up even if it motivate me to
make hashlib happen.

An example benchmark of hashlib using libtomcrypt sha1 vs openssl sha1 is
here http://bugs.python.org/issue1121611#msg47779 if you're curious but
please make any responses to that outside of this bug.

-gps

----------
Added file: http://bugs.python.org/file18928/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________
-------------- next part --------------
<meta charset="utf-8"><div>This bug has turned into a bikeshed.</div><div><br></div><div>Lets stop that please.</div><div><br></div><div>I _DON&#39;T_ care about performance when it comes to someone submitting an actual working implementation of a crypto library for inclusion with the standard library. ??The first priority needs to be a useful stable API.</div>

<div><br></div><div>After that is settled, implementations backed by whatever libraries can be written by anyone who wants to contribute them. ??Lets not stop that from happening by arguing about who&#39;s library is a prettier color. ??The first one may well be implemented in Python itself as a for all I care.</div>

<div><br></div><div>-gps</div><div><br></div><div>(comments below are to answer questions but really are not relevant to the bug)</div><br><div class="gmail_quote">On Sat, Sep 18, 2010 at 3:54 PM, lorph <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
lorph &lt;<a href="mailto:lorph1 at gmail.com">lorph1 at gmail.com</a>&gt; added the comment:<br>
<div class="im"><br>
&gt; OpenSSL outperforms libtomcrypt by a significant factor (easily 2x) in most cases.<br>
<br>
</div>Gregory, do you have any evidence to substantiate this claim? Not that it isn&#39;t plausible, but I couldn&#39;t find any benchmarks, and here the author of libtomcrypt finds it to be 40% faster than OpenSSL concerning RSA operations.<br>

</blockquote><div><br></div><div>I should not have said &quot;most&quot; cases but there are many cases where it does. ??Run your own microbenchmarks on various hardware if you&#39;re curious (&quot;openssl speed algorithmname&quot; on the command line is an existing openssl benchmark). ??The important thing to realize is that libtomcrypt is intentionally written in very portable C. ??That is great but it leaves a lot on the table. ??Optimizations for various platforms to take advantage of enhanced instruction sets such as SSE2 and explicit hardware crypto acceleration instructions such as??<a href="http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-aes-instructions-set/">http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-aes-instructions-set/</a> are not likely to be part of libtomcrypt, nor should they ever be part of code included with and distributed as part of Python. ??That should come from a dynamic library that is part of the OS. ??That may be NSS, that may be OpenSSL, that may be any number of other things. ??Its beyond the scope of this bug.</div>

<div><br></div><div>I&#39;m sorry for bringing the performance angle up even if it motivate me to make hashlib happen.</div><div><br></div><div>An example benchmark of hashlib using libtomcrypt sha1 vs openssl sha1 is here??<a href="http://bugs.python.org/issue1121611#msg47779">http://bugs.python.org/issue1121611#msg47779</a> if you&#39;re curious but please make any responses to that outside of this bug.</div>

<div><br></div><div>-gps</div></div>

From report at bugs.python.org  Sun Sep 19 10:27:16 2010
From: report at bugs.python.org (Owen)
Date: Sun, 19 Sep 2010 08:27:16 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1284884836.67.0.339605247259.issue9884@psf.upfronthosting.co.za>


Owen <j2.nete at gmail.com> added the comment:

Note:
This issue also occurs on other 64 bit windows OS(i.e. windows xp 64bit)

Load "testPy2.dll" needs vc++ runtime library (http://download.microsoft.com/download/2/d/6/2d61c766-107b-409d-8fba-c39e61ca08e8/vcredist_x64.exe)

Update "testPy2.dll", use this to reproduce the issue.
python code:
import sys
from ctypes import *

windll.LoadLibrary("testPy2.dll")
#########################################

def test3(param1,param2,param3,param4,param5,param6,param7,param8,param9,param10):
  print("================")
  print(param1)
  print(param2)
  print(param3)
  print(param4)
  print(param5)
  print(param6)
  print(param7)
  print(param8)
  print(param9)
  print(param10)
  print("================")
  return 20
  
C_METHOD_TYPE4 = WINFUNCTYPE(c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32)

windll.testPy2.fntestPy7(9,C_METHOD_TYPE4(test3))

#########################################

def test4(param1,param2,param3,param4,param5,param6,param7,param8,param9,param10):
  print("================")
  print(param1)
  print(param2)
  print(param3)
  print(param4)
  print(param5)
  print(param6)
  print(param7)
  print(param8)
  print(param9)
  print(param10)
  print("================")
  return 20
  
C_METHOD_TYPE5 = WINFUNCTYPE(c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32)

windll.testPy2.fntestPy8(10,C_METHOD_TYPE5(test4))

#########################################

def test5(param1,param2,param3,param4,param5,param6,param7,param8,param9,param10):
  print("================")
  print(param1)
  print(param2)
  print(param3)
  print(param4)
  print(param5)
  print(param6)
  print(param7)
  print(param8)
  print(param9)
  print(param10)
  print("================")
  return 20
  
C_METHOD_TYPE6 = WINFUNCTYPE(c_int32, c_float, c_float, c_float, c_float, c_float, c_float, c_float, c_float, c_float, c_float)

windll.testPy2.fntestPy9(11,C_METHOD_TYPE6(test5))

----------
Added file: http://bugs.python.org/file18929/testPy2.dll

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Sun Sep 19 11:24:52 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 19 Sep 2010 09:24:52 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1284888292.79.0.186317226345.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks. I've committed in r84902(py3k).

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Sun Sep 19 11:44:44 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 19 Sep 2010 09:44:44 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1284889484.6.0.937963457518.issue9896@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> What is the use case for this?

The basic idea was, that in Python almost everything is introspectable, so why range objects aren't.  It was pretty straightforward to implement it, so I've done it (actually when I was working on rangeobject.c, I was surprised to see that these members aren't available from python code).
But if this isn't needed, I'm absolutely ok with that.  I think this would be a nice to have feature, but of course not necessary.  Also, if it violates the moratorium (I don't know), then of course this sould be at least postponed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Sun Sep 19 12:06:31 2010
From: report at bugs.python.org (hume)
Date: Sun, 19 Sep 2010 10:06:31 +0000
Subject: [issue9897] multiprocessing problems
In-Reply-To: <1284890791.64.0.603170640253.issue9897@psf.upfronthosting.co.za>
Message-ID: <1284890791.64.0.603170640253.issue9897@psf.upfronthosting.co.za>


New submission from hume <humeafo at gmail.com>:

when use multiprocessing managers, while use socket to communicate between server process and client process, if I used the global socket timeout feature(no matter how large the value is) the client will always say

  File "c:\python27\lib\multiprocessing\connection.py", line 149, in Client
    answer_challenge(c, authkey)
  File "c:\python27\lib\multiprocessing\connection.py", line 383, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
IOError: [Errno 10035] 

this is not reasonable, because this behaviour will make subprocess unable to use socket's timeout features globally.

Another question is line 138 in managers.py:
        # do authentication later
        self.listener = Listener(address=address, backlog=5)
        self.address = self.listener.address

backlog=5 will accept only 5 cocurrent connections, this is not so user friendly, you'd better make this a argument that can be specified by user

----------
components: Library (Lib)
messages: 116854
nosy: hume
priority: normal
severity: normal
status: open
title: multiprocessing problems
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9897>
_______________________________________

From report at bugs.python.org  Sun Sep 19 12:31:44 2010
From: report at bugs.python.org (Aaron Sterling)
Date: Sun, 19 Sep 2010 10:31:44 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1284892304.91.0.961602389134.issue2090@psf.upfronthosting.co.za>


Aaron Sterling <aaronasterling at gmail.com> added the comment:

FWIW, I also get this behavior on 2.6.5 and there are claims that it occurs on 2.6.4 and 3.1.1. see http://stackoverflow.com/questions/3745221/import-calls-init-py-twice/3745273#3745273

----------
nosy: +Aaron.Sterling
versions: +Python 2.6 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Sun Sep 19 12:32:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Sep 2010 10:32:22 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284892342.9.0.335760485269.issue8998@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> The license clearly states: "All advertising materials mentioning
> features or use of this software". Do you somehow disagree that base64
> is a feature of the OpenSSL library?
>
> http://www.openssl.org/docs/crypto/BIO_f_base64.html

That's funny. Do you think that if OpenSSL provided its own implementation of strlen(), every text that mentions strlen() needs to acknowledge OpenSSL? Do you realize how ridiculous that is?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 12:33:54 2010
From: report at bugs.python.org (Aaron Sterling)
Date: Sun, 19 Sep 2010 10:33:54 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1284892434.86.0.706544102156.issue2090@psf.upfronthosting.co.za>


Changes by Aaron Sterling <aaronasterling at gmail.com>:


----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Sun Sep 19 12:43:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 19 Sep 2010 10:43:22 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1284893002.74.0.927067293312.issue1738@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Patch worked fine with 2.7.  I reworked it for SVN trunk but got this failure.

FAILED (failures=1)
Traceback (most recent call last):
  File "test_filecmp.py", line 179, in <module>
    test_main()
  File "test_filecmp.py", line 176, in test_main
    support.run_unittest(FileCompareTestCase, DirCompareTestCase)
  File "c:\py3k\lib\test\support.py", line 1128, in run_unittest
    _run_suite(suite)
  File "c:\py3k\lib\test\support.py", line 1111, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "test_filecmp.py", line 158, in test_dircmp_fnmatch
    self.assertEqual(d.left_list, ['file'])
AssertionError: Lists differ: ['dir-ignore', 'file', 'file.t... != ['file']

First differing element 0:
dir-ignore
file

First list contains 2 additional elements.
First extra element 1:
file

- ['dir-ignore', 'file', 'file.tmp']
+ ['file']

I've attached a py3k patch as a different pair of eyes is more likely to spot a problem.

----------
nosy: +BreamoreBoy
Added file: http://bugs.python.org/file18930/issue1738py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738>
_______________________________________

From report at bugs.python.org  Sun Sep 19 12:49:47 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 19 Sep 2010 10:49:47 +0000
Subject: [issue1744] readline module - set/get quote delimiters
In-Reply-To: <1199632447.57.0.76416797802.issue1744@psf.upfronthosting.co.za>
Message-ID: <1284893387.87.0.0421960075009.issue1744@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can a committer review this please.  Can't test it myself as I don't have a *NIX box, sorry.

----------
nosy: +BreamoreBoy
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1744>
_______________________________________

From report at bugs.python.org  Sun Sep 19 12:52:15 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 19 Sep 2010 10:52:15 +0000
Subject: [issue1763] Winpath module - easy access to Windows directories like
	My Documents
In-Reply-To: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za>
Message-ID: <1284893535.29.0.0397541753376.issue1763@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg110596.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1763>
_______________________________________

From report at bugs.python.org  Sun Sep 19 12:52:32 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 19 Sep 2010 10:52:32 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284850462.96.0.244805154384.issue8998@psf.upfronthosting.co.za>
Message-ID: <4C95EB6C.5050104@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Just another data point for the discussion:

The PSF is currently funding the effort to port pyOpenSSL to
Python 3.x and the port is nearly finished.

It may be worthwhile investigating adding the EVP interface
from evpy (with the ctypes bindings converted to real C wrappers)
to pyOpenSSL and then adding the pyOpenSSL package to the stdlib.

Note that going for other crypto libs than OpenSSL is currently
not an option, since those are not widely available on the OSes and
we cannot easily add crypto code itself to Python's stdlib due to the
issues with crypto import/export/use restrictions which would
limit the use of Python in various countries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 13:00:18 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 19 Sep 2010 11:00:18 +0000
Subject: [issue1778] SyntaxError.offset sometimes wrong
In-Reply-To: <1199920786.95.0.62807405199.issue1778@psf.upfronthosting.co.za>
Message-ID: <1284894018.17.0.711538252041.issue1778@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

This will go nowhere until someone supplies a patch.  I'm assuming unit tests can be built using the attached test file.

----------
nosy: +BreamoreBoy
stage: unit test needed -> needs patch
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1778>
_______________________________________

From report at bugs.python.org  Sun Sep 19 13:05:34 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 19 Sep 2010 11:05:34 +0000
Subject: [issue1783] nonexistent data items declared as exports in sysmodule.h
In-Reply-To: <1199980462.14.0.466582779842.issue1783@psf.upfronthosting.co.za>
Message-ID: <1284894334.26.0.589795429462.issue1783@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

The 1st declaration still exists, the 2nd has been removed.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1783>
_______________________________________

From report at bugs.python.org  Sun Sep 19 13:15:29 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 19 Sep 2010 11:15:29 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <1284894929.45.0.950041975998.issue1785@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I can't apply the patch to any current SVN version.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Sun Sep 19 13:23:28 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 19 Sep 2010 11:23:28 +0000
Subject: [issue1794] Hot keys must work in any keyboard layout
In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za>
Message-ID: <1284895408.07.0.514211960074.issue1794@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

>From msg86386 "Nevertheless, after reading your comments I came to the conclusion that doing what you want is very unlikely to happen." so closing.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1794>
_______________________________________

From report at bugs.python.org  Sun Sep 19 13:24:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 19 Sep 2010 11:24:22 +0000
Subject: [issue1800] ctypes callback fails when called in Python with array
	argument
In-Reply-To: <1200093299.88.0.890377527012.issue1800@psf.upfronthosting.co.za>
Message-ID: <1284895462.88.0.797803046308.issue1800@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Anybody?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1800>
_______________________________________

From report at bugs.python.org  Sun Sep 19 14:07:53 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 19 Sep 2010 12:07:53 +0000
Subject: [issue1827] svnversion_init() doesn't support svn urls in
	sandbox/trunk
In-Reply-To: <1200345592.67.0.60555355752.issue1827@psf.upfronthosting.co.za>
Message-ID: <1284898073.28.0.850630115592.issue1827@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this ever likely to happen given the switch to Mercurial, or is that a different scenario to this?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1827>
_______________________________________

From report at bugs.python.org  Sun Sep 19 14:11:43 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 19 Sep 2010 12:11:43 +0000
Subject: [issue1838] Ctypes C-level infinite recursion
In-Reply-To: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za>
Message-ID: <1284898303.6.0.401830380555.issue1838@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I'm not convinced that this needs doing, so I'll close in a couple of weeks unless anyone objects.

----------
nosy: +BreamoreBoy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1838>
_______________________________________

From report at bugs.python.org  Sun Sep 19 14:29:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Sep 2010 12:29:18 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1284899358.89.0.0898718553033.issue9786@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Sun Sep 19 15:01:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Sep 2010 13:01:49 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284901309.96.0.480648689154.issue8998@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It may be worthwhile investigating adding the EVP interface
> from evpy (with the ctypes bindings converted to real C wrappers)
> to pyOpenSSL and then adding the pyOpenSSL package to the stdlib.

pyOpenSSL being LGPL'ed, I'm not sure this is possible.
On the other hand, gradually adding some of pyOpenSSL's most useful functionalities to the ssl module would be worthwhile, and I know Jean-Paul would be interested in this.
This has already begun in 3.2, but I've been alone in doing it and it would be nice if other people contributed:
http://docs.python.org/dev/library/ssl.html#ssl-contexts

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 16:17:58 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 19 Sep 2010 14:17:58 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284901309.96.0.480648689154.issue8998@psf.upfronthosting.co.za>
Message-ID: <4C961B92.9060406@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> It may be worthwhile investigating adding the EVP interface
>> from evpy (with the ctypes bindings converted to real C wrappers)
>> to pyOpenSSL and then adding the pyOpenSSL package to the stdlib.
> 
> pyOpenSSL being LGPL'ed, I'm not sure this is possible.

Changing the license should be possible, since we know the
copyright owners and both are PSF members (AB Strakt and Jean-Paul).

> On the other hand, gradually adding some of pyOpenSSL's most useful functionalities to the ssl module would be worthwhile, and I know Jean-Paul would be interested in this.
> This has already begun in 3.2, but I've been alone in doing it and it would be nice if other people contributed:
> http://docs.python.org/dev/library/ssl.html#ssl-contexts

I don't think we should redo this effort in the context
of the ssl module.

pyOpenSSL is stable, in production use and
has a decent API. The ssl module is good enough for HTTPS client
use. pyOpenSSL provides a robust server side implementation with
all the required certificate and context handling needed for this.

We could tell people to use the ssl module for clients and
pyOpenSSL for the server side and perhaps integrate the OpenSSL
package into the ssl namespace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 16:25:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Sep 2010 14:25:33 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <4C961B92.9060406@egenix.com>
Message-ID: <1284906329.3205.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> pyOpenSSL is stable, in production use and
> has a decent API. The ssl module is good enough for HTTPS client
> use. pyOpenSSL provides a robust server side implementation with
> all the required certificate and context handling needed for this.
> 
> We could tell people to use the ssl module for clients and
> pyOpenSSL for the server side and perhaps integrate the OpenSSL
> package into the ssl namespace.

In this case, this should be decided early, so that I know if I should
continue caring about the ssl module or not. I'm not interested in
maintaining potentially obsolete code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 16:46:19 2010
From: report at bugs.python.org (Tom Browder)
Date: Sun, 19 Sep 2010 14:46:19 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284907579.16.0.344990464533.issue9880@psf.upfronthosting.co.za>


Tom Browder <tom.browder at gmail.com> added the comment:

I'm getting no interest from the gcc group at the moment.  I would like to help track down the bug and will nose around the Python source to zero in on where the problem is for detailed debugging.  Can anyone point me to the key files that concern the byte compiler?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Sun Sep 19 16:46:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Sep 2010 14:46:35 +0000
Subject: [issue9897] multiprocessing problems
In-Reply-To: <1284890791.64.0.603170640253.issue9897@psf.upfronthosting.co.za>
Message-ID: <1284907595.08.0.0887622927868.issue9897@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9897>
_______________________________________

From report at bugs.python.org  Sun Sep 19 16:52:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Sep 2010 14:52:50 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284907970.82.0.032611234497.issue9880@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can look at Python/compile.c (the ast-to-bytecode compiler), Python/peephole.c (the bytecode optimizer), Python/marshal.c (the on-disk bytecode serializer/unserialize).

First step could be to actually disable the optimizer (see PyCode_Optimize in peephole.c).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Sun Sep 19 17:03:28 2010
From: report at bugs.python.org (Alex)
Date: Sun, 19 Sep 2010 15:03:28 +0000
Subject: [issue1838] Ctypes C-level infinite recursion
In-Reply-To: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za>
Message-ID: <1284908608.09.0.346654479831.issue1838@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

I concur with Daniel, this strikes me as a legitimate bug.  Crashing is obviously possibly by calling into arbitrary C code, but in this case control never leaves the runtime.

----------
nosy: +alex
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1838>
_______________________________________

From report at bugs.python.org  Sun Sep 19 18:08:29 2010
From: report at bugs.python.org (Lenard Lindstrom)
Date: Sun, 19 Sep 2010 16:08:29 +0000
Subject: [issue1800] ctypes callback fails when called in Python with array
	argument
In-Reply-To: <1200093299.88.0.890377527012.issue1800@psf.upfronthosting.co.za>
Message-ID: <1284912509.74.0.444031904802.issue1800@psf.upfronthosting.co.za>


Lenard Lindstrom <len-l at telus.net> added the comment:

I will check it out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1800>
_______________________________________

From report at bugs.python.org  Sun Sep 19 18:33:46 2010
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 19 Sep 2010 16:33:46 +0000
Subject: [issue9851] multiprocessing socket timeout will break client
In-Reply-To: <1284452922.14.0.631964759206.issue9851@psf.upfronthosting.co.za>
Message-ID: <1284914026.8.0.79120051908.issue9851@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Duplicate; 9897

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9851>
_______________________________________

From report at bugs.python.org  Sun Sep 19 18:34:18 2010
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 19 Sep 2010 16:34:18 +0000
Subject: [issue9897] multiprocessing problems
In-Reply-To: <1284890791.64.0.603170640253.issue9897@psf.upfronthosting.co.za>
Message-ID: <1284914058.91.0.721040103732.issue9897@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

hume; filing this again doesn't help. I closed issue 9851 as a duplicate of this for you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9897>
_______________________________________

From report at bugs.python.org  Sun Sep 19 19:16:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Sep 2010 17:16:17 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1284916577.77.0.819817886862.issue9360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is the current state of the cleanup work. Coding is roughly finished; most methods are unit-tested. The documentation remains to be done. Review welcome.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file18931/nntplib_cleanup5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Sun Sep 19 19:29:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 19 Sep 2010 17:29:56 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284858037.04.0.0899641274705.issue8998@psf.upfronthosting.co.za>
Message-ID: <4C96488E.6050700@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> Unless "base64" is an OpenSSL trademark, this is FUD.
> 
> The license clearly states: "All advertising materials mentioning
> features or use of this software". Do you somehow disagree that
> base64 is a feature of the OpenSSL library?

What specific "advertising material" mentions "base64" but fails to
mention "OpenSSL"? In any case, this is off-topic for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 19:39:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Sep 2010 17:39:49 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1284917989.59.0.975237465391.issue8998@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file18928/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Sep 19 20:55:43 2010
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 19 Sep 2010 18:55:43 +0000
Subject: [issue9898] cProfile.runctx doesn't allow sort argument
In-Reply-To: <1284922541.3.0.303854957861.issue9898@psf.upfronthosting.co.za>
Message-ID: <1284922541.3.0.303854957861.issue9898@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

The `cProfile.runctx` function currently doesn't allow using the `sort` argument. For some reason the `sort` argument is allowed in `run` but not in `runctx`. Attached is a patch that allows using `sort` in `runctx`.

----------
components: Library (Lib)
files: cProfile.patch
keywords: patch
messages: 116880
nosy: cool-RR
priority: normal
severity: normal
status: open
title: cProfile.runctx doesn't allow sort argument
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18932/cProfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9898>
_______________________________________

From report at bugs.python.org  Sun Sep 19 21:17:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Sep 2010 19:17:24 +0000
Subject: [issue9119] Python download page needs to mention crypto code
	in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1284923844.73.0.926049588689.issue9119@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes, everything under docs.python.org is generated from files from the Doc directory of a CPython checkout.  s/.html/.rst/ and you have your filename.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9119>
_______________________________________

From report at bugs.python.org  Sun Sep 19 22:11:36 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 19 Sep 2010 20:11:36 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1284927096.59.0.847714262107.issue2090@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I replied to the Stack Overflow question. I should also mention that importlib is on PyPI and compatible back to PYthon 2.3.

I still plan to get to this some day, but I don't view this as a critical fix, just a nice thing to do for folks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Sun Sep 19 22:43:00 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 19 Sep 2010 20:43:00 +0000
Subject: [issue9899] [REGRESSION] test_tk broken on MacOSX 10.6
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

py3k branch, revision 84907

======================================================================
ERROR: test_font_eq (tkinter.test.test_tkinter.test_font.FontTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/tkinter/test/test_tkinter/test_font.py", line 10, in test_font_eq
    font1 = font.nametofont("system")
  File "/Users/cartman/Sources/py3k/Lib/tkinter/font.py", line 22, in nametofont
    return Font(name=name, exists=True)
  File "/Users/cartman/Sources/py3k/Lib/tkinter/font.py", line 83, in __init__
    "named font %s does not already exist" % (self.name,))
_tkinter.TclError: named font system does not already exist

----------
components: Tests
messages: 116883
nosy: cartman
priority: normal
severity: normal
status: open
title: [REGRESSION] test_tk broken on MacOSX 10.6
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9899>
_______________________________________

From report at bugs.python.org  Sun Sep 19 22:54:17 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 19 Sep 2010 20:54:17 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1284929657.45.0.0473281470654.issue9360@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

To make the distinction easier to remember, would it help if the methods that are currently set to return bytes instead accepted the typical encoding+errors parameters, with parallel *b APIs to get at the raw bytes?

My concern with the current API is that there isn't a clear indicator during normal programming as to which APIs return strings and which return the raw bytes and hence require further decoding.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Sun Sep 19 23:06:11 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 19 Sep 2010 21:06:11 +0000
Subject: [issue4844] ZipFile doesn't range check in _EndRecData()
In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za>
Message-ID: <1284930371.07.0.533345290326.issue4844@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Following EAFP principle, it would be better - cleaner and more efficient - to put the stuct.unpack inside a try/except clause than checking the lengths beforehand.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4844>
_______________________________________

From report at bugs.python.org  Sun Sep 19 23:09:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Sep 2010 21:09:38 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1284929657.45.0.0473281470654.issue9360@psf.upfronthosting.co.za>
Message-ID: <1284930573.3205.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> To make the distinction easier to remember, would it help if the
> methods that are currently set to return bytes instead accepted the
> typical encoding+errors parameters, with parallel *b APIs to get at
> the raw bytes?

Not really, no. For raw messages, which encoding+errors must be used
depends on the returned contents, it's not something the client can know
up front; moreover, different parts of the returned bytes may need
decoding using different encodings (for example if there are several
MIME parts to the message). People should use the email package to parse
the raw messages, as I assume they already do in 2.x.

Apart from raw message bodies, NNTP data has well-defined encodings and
that's why I can take and return unicode (although as stated, I also use
surrogateescape to be fault-tolerant in the face of broken servers).

> My concern with the current API is that there isn't a clear indicator
> during normal programming as to which APIs return strings and which
> return the raw bytes and hence require further decoding.

That's a documentation issue. I haven't touched the docs yet :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Sun Sep 19 23:39:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 19 Sep 2010 21:39:20 +0000
Subject: [issue9252] PyImport_Import calls __import__ with dummy fromlist
In-Reply-To: <1279055953.69.0.493320308989.issue9252@psf.upfronthosting.co.za>
Message-ID: <1284932360.06.0.46184497347.issue9252@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixed in r84908.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9252>
_______________________________________

From report at bugs.python.org  Sun Sep 19 23:43:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Sep 2010 21:43:25 +0000
Subject: [issue9119] Python download page needs to mention crypto code
	in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1284932605.76.0.322342736786.issue9119@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not quite everything (index.html and download.html are special, in that they're not generated from reST), but otherwise that is correct.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9119>
_______________________________________

From report at bugs.python.org  Sun Sep 19 23:59:25 2010
From: report at bugs.python.org (Alan McIntyre)
Date: Sun, 19 Sep 2010 21:59:25 +0000
Subject: [issue4844] ZipFile doesn't range check in _EndRecData()
In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za>
Message-ID: <1284933565.64.0.590135351668.issue4844@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

I had to look up the abbreviation (Easier to Ask Forgiveness than Permission), but that does sound like a good idea.  Thanks for mentioning it. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4844>
_______________________________________

From report at bugs.python.org  Mon Sep 20 00:31:42 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 19 Sep 2010 22:31:42 +0000
Subject: [issue1838] Ctypes C-level infinite recursion
In-Reply-To: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za>
Message-ID: <1284935502.36.0.010684109151.issue1838@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

So has anyone got an idea on how to fix this without solving the halting problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1838>
_______________________________________

From report at bugs.python.org  Mon Sep 20 01:04:15 2010
From: report at bugs.python.org (Rob Watson)
Date: Sun, 19 Sep 2010 23:04:15 +0000
Subject: [issue9900] Threading Bug or misuse of the api ?
In-Reply-To: <1284937455.45.0.396725320878.issue9900@psf.upfronthosting.co.za>
Message-ID: <1284937455.45.0.396725320878.issue9900@psf.upfronthosting.co.za>


New submission from Rob Watson <rmawatson at gmail.com>:

Is the below a bug or a misuse of the api ? This was compiled with visual studio 2008 and python26 64bit

void testfunction()
{
	for (int x = 1;x <= 100000;x++)
	{
		
		PyGILState_STATE gstate = PyGILState_Ensure();
		PyRun_SimpleString("2 + 1");
		PyGILState_Release(gstate);
	}	
}


int main()
{
	
	Py_Initialize();
	PyEval_InitThreads();
	PyEval_ReleaseLock();	
	
	boost::thread(boost::bind(testfunction));
	
        // if this Sleep(100) is commented out, I will get "Python Fatal Error : This thread state must be current when releasing"
	Sleep(100);
	testfunction();
	Sleep(1000000);
}

----------
components: None
messages: 116891
nosy: Rob.Watson
priority: normal
severity: normal
status: open
title: Threading Bug or misuse of the api ?
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9900>
_______________________________________

From report at bugs.python.org  Mon Sep 20 01:14:32 2010
From: report at bugs.python.org (Rob Watson)
Date: Sun, 19 Sep 2010 23:14:32 +0000
Subject: [issue9900] Threading Bug or misuse of the api ?
In-Reply-To: <1284937455.45.0.396725320878.issue9900@psf.upfronthosting.co.za>
Message-ID: <1284938072.49.0.583102494494.issue9900@psf.upfronthosting.co.za>


Changes by Rob Watson <rmawatson at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9900>
_______________________________________

From report at bugs.python.org  Mon Sep 20 01:22:36 2010
From: report at bugs.python.org (Rob Watson)
Date: Sun, 19 Sep 2010 23:22:36 +0000
Subject: [issue9900] Threading Bug or misuse of the api ?
In-Reply-To: <1284937455.45.0.396725320878.issue9900@psf.upfronthosting.co.za>
Message-ID: <1284938556.77.0.387903217276.issue9900@psf.upfronthosting.co.za>


Changes by Rob Watson <rmawatson at gmail.com>:


----------
resolution: invalid -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9900>
_______________________________________

From report at bugs.python.org  Mon Sep 20 01:22:50 2010
From: report at bugs.python.org (Rob Watson)
Date: Sun, 19 Sep 2010 23:22:50 +0000
Subject: [issue9900] Threading Bug or misuse of the api ?
In-Reply-To: <1284937455.45.0.396725320878.issue9900@psf.upfronthosting.co.za>
Message-ID: <1284938570.06.0.183195781094.issue9900@psf.upfronthosting.co.za>


Changes by Rob Watson <rmawatson at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9900>
_______________________________________

From report at bugs.python.org  Mon Sep 20 01:25:55 2010
From: report at bugs.python.org (Rob Watson)
Date: Sun, 19 Sep 2010 23:25:55 +0000
Subject: [issue9900] Threading Bug or misuse of the api ?
In-Reply-To: <1284937455.45.0.396725320878.issue9900@psf.upfronthosting.co.za>
Message-ID: <1284938755.45.0.682222696374.issue9900@psf.upfronthosting.co.za>


Changes by Rob Watson <rmawatson at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9900>
_______________________________________

From report at bugs.python.org  Mon Sep 20 01:53:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 19 Sep 2010 23:53:41 +0000
Subject: [issue9900] Threading Bug or misuse of the api ?
In-Reply-To: <1284937455.45.0.396725320878.issue9900@psf.upfronthosting.co.za>
Message-ID: <1284940421.71.0.362330122529.issue9900@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please include a message when closing an issue to indicate why it's closed.

AFAICT, this is indeed incorrect usage of the API: you should have used PyEval_SaveThread instead of PyEval_ReleaseLock.

----------
nosy: +loewis
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9900>
_______________________________________

From report at bugs.python.org  Mon Sep 20 01:57:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Sep 2010 23:57:42 +0000
Subject: [issue9901] GIL destruction can fail
In-Reply-To: <1284940662.22.0.656569610088.issue9901@psf.upfronthosting.co.za>
Message-ID: <1284940662.22.0.656569610088.issue9901@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_finalize_with_trace (in test_threading) sometimes fails because of failing to destroy the GIL (in _PyEval_FiniThreads()). This can be reproduced quite reliably by launching several copies in parallel:

$ ./python -m test.regrtest -j10 -F test_threading
[...]
test test_threading failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_threading.py", line 334, in test_finalize_with_trace
    "Unexpected error: " + ascii(stderr))
AssertionError: Unexpected error: b'Fatal Python error: pthread_mutex_destroy(gil_mutex) failed\n'


What happens is that pthread_mutex_destroy() fails with EBUSY. According to the POSIX man page:

?[EBUSY]
    The implementation has detected an attempt to destroy the object referenced by mutex while it is locked or referenced (for example, while being used in a pthread_cond_timedwait() or pthread_cond_wait()) by another thread.?


After a bit of tracing, it becomes clear that Py_Finalize() calls _PyEval_FiniThreads() while another thread is taking the GIL (take_gil()). Unfortunately, this is not a situation we can avoid, since we rely on process exit to kill lingering threads: arbitrary CPython code may still be running in parallel while we are finalizing interpreter structures.

Therefore, it is likely that _PyEval_FiniThreads() should avoid destroying the mutex at all. Indeed, if we destroy the mutex, it is possible that a lingering thread tries to retake the GIL after waking up from a system call (Py_END_ALLOW_THREADS), and fails because of another fatal error ("Fatal Python error: pthread_mutex_lock(gil_mutex) failed").

----------
components: Interpreter Core
messages: 116893
nosy: amaury.forgeotdarc, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: GIL destruction can fail
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9901>
_______________________________________

From report at bugs.python.org  Mon Sep 20 01:58:02 2010
From: report at bugs.python.org (Rob Watson)
Date: Sun, 19 Sep 2010 23:58:02 +0000
Subject: [issue9900] Threading Bug or misuse of the api ?
In-Reply-To: <1284937455.45.0.396725320878.issue9900@psf.upfronthosting.co.za>
Message-ID: <1284940682.06.0.323861100185.issue9900@psf.upfronthosting.co.za>


Rob Watson <rmawatson at gmail.com> added the comment:

it seemed changing PyEval_ReleaseLock() to PyThreadState_DeleteCurrent() has fixed my problem. Thanks

----------
resolution: invalid -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9900>
_______________________________________

From report at bugs.python.org  Mon Sep 20 01:59:01 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 19 Sep 2010 23:59:01 +0000
Subject: [issue9900] Threading Bug or misuse of the api ?
In-Reply-To: <1284937455.45.0.396725320878.issue9900@psf.upfronthosting.co.za>
Message-ID: <1284940741.96.0.0286161274589.issue9900@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9900>
_______________________________________

From report at bugs.python.org  Mon Sep 20 02:02:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 00:02:18 +0000
Subject: [issue9902] test_undecodable_env failure
In-Reply-To: <1284940938.56.0.417110685036.issue9902@psf.upfronthosting.co.za>
Message-ID: <1284940938.56.0.417110685036.issue9902@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Under the "x86 debian parallel 3.x" buildbot, there's the following failure:

======================================================================
FAIL: test_undecodable_env (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/test/test_subprocess.py", line 898, in test_undecodable_env
    self.assertEquals(stdout.decode('ascii'), ascii(value))
AssertionError: "'abc\\xff'" != "'abc\\udcff'"
- 'abc\xff'
?      ^
+ 'abc\udcff'
?      ^^^


======================================================================
FAIL: test_undecodable_env (test.test_subprocess.ProcessTestCasePOSIXPurePython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/test/test_subprocess.py", line 898, in test_undecodable_env
    self.assertEquals(stdout.decode('ascii'), ascii(value))
AssertionError: "'abc\\xff'" != "'abc\\udcff'"
- 'abc\xff'
?      ^
+ 'abc\udcff'
?      ^^^

----------
assignee: haypo
components: Tests
messages: 116895
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_undecodable_env failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9902>
_______________________________________

From report at bugs.python.org  Mon Sep 20 02:06:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 00:06:48 +0000
Subject: [issue9902] test_undecodable_env failure
In-Reply-To: <1284940938.56.0.417110685036.issue9902@psf.upfronthosting.co.za>
Message-ID: <1284941208.68.0.888012882685.issue9902@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It can be reproduced quite easily with the right locale:

$ LANG=fr_FR.iso8859-1 ./python -m test.regrtest -v test_subprocess

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9902>
_______________________________________

From report at bugs.python.org  Mon Sep 20 02:12:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 00:12:31 +0000
Subject: [issue9902] test_undecodable_env failure
In-Reply-To: <1284940938.56.0.417110685036.issue9902@psf.upfronthosting.co.za>
Message-ID: <1284941551.34.0.338322492111.issue9902@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fix attempted in r84912.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9902>
_______________________________________

From report at bugs.python.org  Mon Sep 20 02:14:41 2010
From: report at bugs.python.org (Alex)
Date: Mon, 20 Sep 2010 00:14:41 +0000
Subject: [issue1838] Ctypes C-level infinite recursion
In-Reply-To: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za>
Message-ID: <1284941681.71.0.677481502406.issue1838@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

No need to solve the halting problem, just to detect a cycle in data.  I've got a patch, however it requires objects to be hashable.  Another case for identity dict I suppose :)  Not sure if that's a reasonable requirement, in any event, proof of concept patch, against trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file18933/python_recursive_as_parameter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1838>
_______________________________________

From report at bugs.python.org  Mon Sep 20 02:27:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 00:27:51 +0000
Subject: [issue8432] buildbot: test_send_signal of test_subprocess failure
In-Reply-To: <1271522195.0.0.944847217112.issue8432@psf.upfronthosting.co.za>
Message-ID: <1284942471.51.0.52312748327.issue8432@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The test fails mostly on very slow machines (not only BSD ones, but also the Debian sparc buildbot).
Therefore, I've attempted a fix in r84910 by relaxing timings, and simply skipping the test if it seems we couldn't send the signal in time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8432>
_______________________________________

From report at bugs.python.org  Mon Sep 20 02:28:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 00:28:40 +0000
Subject: [issue9902] test_undecodable_env failure
In-Reply-To: <1284940938.56.0.417110685036.issue9902@psf.upfronthosting.co.za>
Message-ID: <1284942520.43.0.181227958474.issue9902@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9902>
_______________________________________

From report at bugs.python.org  Mon Sep 20 02:40:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 00:40:16 +0000
Subject: [issue8432] buildbot: test_send_signal of test_subprocess failure
In-Reply-To: <1271522195.0.0.944847217112.issue8432@psf.upfronthosting.co.za>
Message-ID: <1284943216.19.0.176428908517.issue8432@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The fix succeeded on the "sparc Debian 3.x" buildbot while test_subprocess had been failing consistently before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8432>
_______________________________________

From report at bugs.python.org  Mon Sep 20 02:48:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 00:48:43 +0000
Subject: [issue9903] test_concurrent_futures writes on stderr
In-Reply-To: <1284943723.6.0.157191690698.issue9903@psf.upfronthosting.co.za>
Message-ID: <1284943723.6.0.157191690698.issue9903@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_concurrent_futures writes the following on stderr:

exception calling callback for <Future at 0x6a72508 state=finished returned int>
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/concurrent/futures/_base.py", line 267, in _invoke_callbacks
    callback(self)
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/test/test_concurrent_futures.py", line 626, in raising_fn
    raise Exception('doh!')
Exception: doh!


test_concurrent_futures should capture stderr instead, and also probably check its value (to be sure that the exception does get logged out properly).

----------
assignee: bquinlan
components: Tests
messages: 116902
nosy: bquinlan, pitrou
priority: normal
severity: normal
status: open
title: test_concurrent_futures writes on stderr
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9903>
_______________________________________

From report at bugs.python.org  Mon Sep 20 04:04:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Sep 2010 02:04:46 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1284948286.97.0.989901474065.issue9360@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I tested this against my existing py3k nttp client code.

Why is it a good thing to make file a keyword only parameter? But given that it is, line 720 needs to use it as such, which omission means your missing at least one test :)

On line 193 you index fmt, and *then* you check the length.  When the number of tokens is too long, an IndexError is raised.  (Note that the offending overview line comes from the gmane group comp.lang.python.mime.devel, and the offense is an extra '' field on one of the records.  No idea why it got added to that one record.  Looks like it is message 701, artid <4111BBA9.3040302 at harvee.org>)

Could the 'date' field in the xover headers also be a DateTime rather than a string?  And :bytes and :lines be ints?  Or is that being to DWIMish?  If the date field isn't returned as a datetime, though, should there be a helper method for converting it, or should we just assume that email.utils mktime_tz and parsedate_tz?

Am I correct that the purpose of _NNTPBase is to make testing easier?

There seem to be only three lines of code in common between the file and the non-file case in _getlongresp.  I think it would be clearer to make them two different routines, or at least move the three common lines to the top and then do an if test on file is None (that is, put the simpler, non-file case first).

My little nttp client script doesn't really test very much of the nttplib interface, nor is it very complex.  The change to xover considerably simplified that part of my script, so I very much like that change.  I was also able to drop my implementation of decode_header.  So overall this patch is significant improvement, IMO.

I haven't given the code as thorough a review as might be optimal, but I certainly think you are headed in the right direction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Mon Sep 20 04:08:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Sep 2010 02:08:54 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1284948534.88.0.67734873574.issue9360@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Gah.  I reviewed patch4, didn't noticed today's update :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Mon Sep 20 04:12:20 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 20 Sep 2010 02:12:20 +0000
Subject: [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1284948740.17.0.304691256169.issue9786@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Committed as revision 84914

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Mon Sep 20 04:25:43 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Sep 2010 02:25:43 +0000
Subject: [issue9899] tkinter test_font fails on OS X with Aqua Tk
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1284949543.82.0.527110581786.issue9899@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

r84865 for Issue1730136 introduced a new tkinter test, test_font.  As it stands, the test fails on OS X 10.6 when Python is built with Aqua Tk, at least with either the Apple-supplied 8.5 or the ActiveState 8.5 (I haven't tried with any of the Aqua 8.4 version).  The main problem is that font "system" is not a font name returned by the interface used by tkinter/font.py:

$ /usr/bin/wish8.5
% font names
systemPushButtonFont systemMenuItemFont systemApplicationFont systemSystemFont systemMenuItemMarkFont TkMenuFont TkDefaultFont systemSmallEmphasizedSystemFont systemDetailEmphasizedSystemFont systemMiniSystemFont TkHeadingFont TkTooltipFont systemUtilityWindowTitleFont systemViewsFont systemSmallSystemFont systemMenuTitleFont systemEmphasizedSystemFont TkTextFont systemDetailSystemFont TkCaptionFont systemLabelFont systemAlertHeaderFont systemMenuItemCmdKeyFont TkSmallCaptionFont TkFixedFont systemWindowTitleFont systemToolbarFont TkIconFont
% font actual system
-family {Lucida Grande} -size 13 -weight normal -slant roman -underline 0 -overstrike 0

Based on the man page here (http://www.tcl.tk/man/tcl8.5/TkCmd/font.htm#M31) it appears any of the "standard" font names would be a better choice, like TkDefaultFont.

Also, test_font should include the standard tkinter.test setUp and setDown functions so that the test can be run by itself.

The attached patch should fix both issues.

----------
components: +Tkinter
keywords: +patch
nosy: +amaury.forgeotdarc, gpolo, ned.deily
stage:  -> patch review
title: [REGRESSION] test_tk broken on MacOSX 10.6 -> tkinter test_font fails on OS X with Aqua Tk
Added file: http://bugs.python.org/file18934/issue9899-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9899>
_______________________________________

From report at bugs.python.org  Mon Sep 20 05:19:03 2010
From: report at bugs.python.org (hume)
Date: Mon, 20 Sep 2010 03:19:03 +0000
Subject: [issue9897] multiprocessing problems
In-Reply-To: <1284890791.64.0.603170640253.issue9897@psf.upfronthosting.co.za>
Message-ID: <1284952743.95.0.0894362888358.issue9897@psf.upfronthosting.co.za>


hume <humeafo at gmail.com> added the comment:

ok, I refill this to fix the un-plesant words problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9897>
_______________________________________

From report at bugs.python.org  Mon Sep 20 06:39:12 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 20 Sep 2010 04:39:12 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1284957552.06.0.487846040573.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I'll revert my commits because I noticed after perl source
like openssl-1.0.0a/crypto/x86cpuid.pl was modified,
unnecessary rebuild happened again.

Appropriate fix will be "only copies *.asm if there are not
in tmp32/" as comments in PCBuild/build_ssl.py saids.(Probably
this copying is not needed only when Perl is available,
I suppose)

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Mon Sep 20 06:42:24 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 20 Sep 2010 04:42:24 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1284957744.39.0.243479808238.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

- only when
+ when

P.S.
I cannot figure out how to solve this error.
http://www.python.org/dev//buildbot/builders/x86%20Windows7%203.x/builds/1593/steps/compile/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Mon Sep 20 06:57:05 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 20 Sep 2010 04:57:05 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1284958625.17.0.197478757866.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This is the patch I'm thinking of. I confirmed this works
on VS8.0. (After replaced "..\\.." with "..\\..\\..")

E:\PYTHON~1\py3k\PC\VS8.0>python_d.exe build_ssl.py Release Win32 -a
Found a working perl at 'C:\Perl\bin\perl.exe'
Found an SSL directory at '..\..\..\openssl-1.0.0a'
Executing ssl makefiles: nmake /nologo -f "ms\nt.mak"
Building OpenSSL
        copy ".\crypto\buildinf.h" "tmp32\buildinf.h"
        Copied one file.
        copy ".\crypto\opensslconf.h" "inc32\openssl\opensslconf.h"
        Copied one file.
[45178 refs]

By this change, two header files are still copied. I feel
it's strange header files are modified but none of sources
are not re-built.

----------
Added file: http://bugs.python.org/file18935/py3k_openssl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Mon Sep 20 08:29:06 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 20 Sep 2010 06:29:06 +0000
Subject: [issue9904] Cosmetic issues that might be worthy a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The following minor issues may affect the readability of the code implementing symbol tables in Include/symtable.h and Python/symtable.c

    * The comment for st_global in symtable.h says: "borrowed ref to st_top->st_symbols. typo? (st_top->ste_symbols)
    * ste_varnames: the name and the comment after it are misleading, since it actually collects only the function's parameters and not all variables.
    * the st_nblocks and st_future fields of symtable aren't used anywhere - py3k compiles fine when they're removed.
    * in analyze_block a comment says "Recursively call analyze_block()" - untrue, probably meant analyze_child_block. While technically analyze_child_block calls analyze_block, the comment as-is appears misleading.
    * symtable_add_def is also called with the USE flag, not only definitions, hence its name doesn't reflect its purpose accurately
    * There are some indentation artifacts that obscure readability. For example the case Raise_kind of symtable_visit_stmt, where two nested blocks start and end in the same column obscuring the fact they're nested. This could be a result of an automatic tab to space conversion in the past.

----------
components: Interpreter Core
messages: 116911
nosy: eli.bendersky, ncoghlan
priority: normal
severity: normal
status: open
title: Cosmetic issues  that might be worthy a fix in symtable.h/c
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Mon Sep 20 08:29:33 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 20 Sep 2010 06:29:33 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1284964173.89.0.945459614586.issue9904@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
title: Cosmetic issues  that might be worthy a fix in symtable.h/c -> Cosmetic issues that may warrant a fix in symtable.h/c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Mon Sep 20 08:35:15 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 20 Sep 2010 06:35:15 +0000
Subject: [issue9898] cProfile.runctx doesn't allow sort argument
In-Reply-To: <1284922541.3.0.303854957861.issue9898@psf.upfronthosting.co.za>
Message-ID: <1284964515.74.0.150094437454.issue9898@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This has already been done as part of issue9428 in r83524.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9898>
_______________________________________

From report at bugs.python.org  Mon Sep 20 08:40:53 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 20 Sep 2010 06:40:53 +0000
Subject: [issue9901] GIL destruction can fail
In-Reply-To: <1284940662.22.0.656569610088.issue9901@psf.upfronthosting.co.za>
Message-ID: <1284964853.56.0.671549730233.issue9901@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

looks similar to issue1856

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9901>
_______________________________________

From report at bugs.python.org  Mon Sep 20 08:48:45 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 20 Sep 2010 06:48:45 +0000
Subject: [issue1838] Ctypes C-level infinite recursion
In-Reply-To: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za>
Message-ID: <1284965325.59.0.651699405397.issue1838@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This function is called quite often. Building a set each time will be expensive.
What about a simpler recursion check with Py_EnterRecursiveCall()?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1838>
_______________________________________

From report at bugs.python.org  Mon Sep 20 09:42:02 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 07:42:02 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1284968522.64.0.967607086531.issue1859@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Anyone interested in picking this up?  I've tried and fell flat on my face :(

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Mon Sep 20 09:45:08 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 07:45:08 +0000
Subject: [issue1865] Bytes alias for 2.6
In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za>
Message-ID: <1284968708.19.0.989258506563.issue1865@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
assignee: georg.brandl -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1865>
_______________________________________

From report at bugs.python.org  Mon Sep 20 09:50:05 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 07:50:05 +0000
Subject: [issue1866] const arg for PyInt_FromString
In-Reply-To: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za>
Message-ID: <1284969005.97.0.552007309152.issue1866@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Any opinions as to whether the patch should be reworked for 3.2 or not?

----------
nosy: +BreamoreBoy
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1866>
_______________________________________

From report at bugs.python.org  Mon Sep 20 09:52:11 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 07:52:11 +0000
Subject: [issue1874] email parser does not register a defect for invalid
	Content-Transfer-Encoding on multipart messages
In-Reply-To: <1200767841.97.0.882225337338.issue1874@psf.upfronthosting.co.za>
Message-ID: <1284969131.51.0.98864587352.issue1874@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +r.david.murray
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1874>
_______________________________________

From report at bugs.python.org  Mon Sep 20 09:55:40 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 07:55:40 +0000
Subject: [issue1875] "if 0: return" not raising SyntaxError
In-Reply-To: <1200768950.55.0.245752373825.issue1875@psf.upfronthosting.co.za>
Message-ID: <1284969340.74.0.629150857219.issue1875@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

msg81023 indicates that more work is needed on this.

----------
nosy: +BreamoreBoy
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1875>
_______________________________________

From report at bugs.python.org  Mon Sep 20 10:58:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 08:58:10 +0000
Subject: [issue8432] buildbot: test_send_signal of test_subprocess failure
In-Reply-To: <1271522195.0.0.944847217112.issue8432@psf.upfronthosting.co.za>
Message-ID: <1284973090.37.0.6405727593.issue8432@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

test_subprocess now succeeds on all 3.x buildbots. Will backport and then close.

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8432>
_______________________________________

From report at bugs.python.org  Mon Sep 20 11:09:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 09:09:32 +0000
Subject: [issue1730136] tkFont.__eq__ gives type error
Message-ID: <1284973772.24.0.801100364218.issue1730136@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The new test case fails on (FreeBSD, OS X) buildbots:

======================================================================
ERROR: test_font_eq (tkinter.test.test_tkinter.test_font.FontTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/test_tkinter/test_font.py", line 10, in test_font_eq
    font1 = font.nametofont("system")
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/font.py", line 22, in nametofont
    return Font(name=name, exists=True)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/font.py", line 83, in __init__
    "named font %s does not already exist" % (self.name,))
_tkinter.TclError: named font system does not already exist

----------------------------------------------------------------------

----------
assignee: loewis -> amaury.forgeotdarc
nosy: +pitrou
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1730136>
_______________________________________

From report at bugs.python.org  Mon Sep 20 11:10:19 2010
From: report at bugs.python.org (Pablo Bitton)
Date: Mon, 20 Sep 2010 09:10:19 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1284973819.96.0.256806199561.issue5673@psf.upfronthosting.co.za>


Pablo Bitton <pablo.bitton at gmail.com> added the comment:

Has anybody had a chance to look into the problem I encountered yet?

Do you need more information?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Mon Sep 20 11:14:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 09:14:39 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1284974079.88.0.840382998205.issue8845@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine also suggested it might be the particular version of sqlite in 
> use on the buildbot, but I don't currently know what version that is.  
> Bill, can you clue me in?

You could simply print out sqlite3.sqlite_version at the beginning of test_sqlite when it is run in verbose mode, as is done in test_ssl.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Mon Sep 20 11:47:15 2010
From: report at bugs.python.org (C. E. Ball)
Date: Mon, 20 Sep 2010 09:47:15 +0000
Subject: [issue1584] Mac OS X: building with X11 Tkinter
In-Reply-To: <1197345898.75.0.132866639605.issue1584@psf.upfronthosting.co.za>
Message-ID: <1284976035.55.0.982342367031.issue1584@psf.upfronthosting.co.za>


C. E. Ball <ceball at users.sf.net> added the comment:

Sorry, I don't have a Mac, and I don't have access to one that I could use to make a patch. 

At the time, I was trying to support OS X users of a piece of Python/Tkinter software. Please do not keep this issue open on my account.

Thanks,
Chris

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1584>
_______________________________________

From report at bugs.python.org  Mon Sep 20 12:19:11 2010
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 20 Sep 2010 10:19:11 +0000
Subject: [issue9898] cProfile.runctx doesn't allow sort argument
In-Reply-To: <1284922541.3.0.303854957861.issue9898@psf.upfronthosting.co.za>
Message-ID: <1284977951.88.0.231421731383.issue9898@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Is this going into 3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9898>
_______________________________________

From report at bugs.python.org  Mon Sep 20 13:16:42 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 20 Sep 2010 11:16:42 +0000
Subject: [issue1866] const arg for PyInt_FromString
In-Reply-To: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za>
Message-ID: <1284981402.94.0.283884189406.issue1866@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm rejecting this due to the effect it has on the output parameters.

The patch ends up have to stick (char *) casts in several places because a pointer into the string provided via the char * input parameter is returned by each affected API to the calling function via a char **output parameter.

We can't change the signature of the output parameters since that would break existing code. That then means we also can't change the signature of the input parameters, since we can't guarantee that the recipient of the output parameter won't later use it to change things.

The calling code knows whether or not it is going to modify the pointer it receives back, and hence whether or not it is safe to cast away the const-ness of the passed in pointer.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1866>
_______________________________________

From report at bugs.python.org  Mon Sep 20 13:22:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 11:22:25 +0000
Subject: [issue8432] buildbot: test_send_signal of test_subprocess failure
In-Reply-To: <1271522195.0.0.944847217112.issue8432@psf.upfronthosting.co.za>
Message-ID: <1284981745.02.0.607132308497.issue8432@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8432>
_______________________________________

From report at bugs.python.org  Mon Sep 20 13:33:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 11:33:00 +0000
Subject: [issue9901] GIL destruction can fail
In-Reply-To: <1284940662.22.0.656569610088.issue9901@psf.upfronthosting.co.za>
Message-ID: <1284982380.2.0.777285148882.issue9901@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It is similar, but the issue is slightly different. Fixing issue1856 with the proposed resolution (the "stay_forever" flag) won't solve this, because the GIL mutex will still refuse to be destroyed if other threads reference it at the same time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9901>
_______________________________________

From report at bugs.python.org  Mon Sep 20 13:42:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 11:42:08 +0000
Subject: [issue9901] GIL destruction can fail
In-Reply-To: <1284940662.22.0.656569610088.issue9901@psf.upfronthosting.co.za>
Message-ID: <1284982928.81.0.161970660626.issue9901@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Moving the _PyEval_FiniThreads() call to Py_Initialize() solves the issue:

diff -r 9e49082da463 Python/pythonrun.c
--- a/Python/pythonrun.c        Mon Sep 20 12:46:56 2010 +0200
+++ b/Python/pythonrun.c        Mon Sep 20 13:41:47 2010 +0200
@@ -217,8 +217,15 @@ Py_InitializeEx(int install_sigs)
         Py_FatalError("Py_Initialize: can't make first thread");
     (void) PyThreadState_Swap(tstate);
 
-    /* auto-thread-state API, if available */
 #ifdef WITH_THREAD
+    /* We can't call _PyEval_FiniThreads() in Py_Finalize because
+       destroying the GIL might fail when it is being referenced from
+       another running thread (see issue #9901).
+       Instead we destroy the previously created GIL here, which ensures
+       that we can call Py_Initialize / Py_Finalize multiple times. */
+    _PyEval_FiniThreads();
+
+    /* Auto-thread-state API */
     _PyGILState_Init(interp, tstate);
 #endif /* WITH_THREAD */
 
@@ -514,10 +521,6 @@ Py_Finalize(void)
 
     PyGrammar_RemoveAccelerators(&_PyParser_Grammar);
 
-#ifdef WITH_THREAD
-    _PyEval_FiniThreads();
-#endif
-
 #ifdef Py_TRACE_REFS
     /* Display addresses (& refcnts) of all objects still alive.
      * An address can be used to find the repr of the object, printed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9901>
_______________________________________

From report at bugs.python.org  Mon Sep 20 13:42:34 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 20 Sep 2010 11:42:34 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1284982954.1.0.0765247551806.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The design approach (at least for urllib.parse) is to add separate *b APIs that operate on bytes rather than implicitly allowing bytes in the ordinary versions of the function.

Allowing programmers to manipulate correctly encoded (and hence ASCII compatible) bytes to avoid decode/encode overhead when manipulating URLs is fine (and the whole point of adding the new functions). Allowing them to *not know* whether they have encoded data or text suitable for display to the user isn't necessary (and is easy to add later if we decide we want it, while taking it away is far more difficult).

More detail at http://mail.python.org/pipermail/python-dev/2010-September/103828.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Mon Sep 20 13:55:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 11:55:37 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1284983737.63.0.647368375545.issue1856@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

See #9901 for a variation on the same global issue (running threads can access interpreter structures - the GIL - while the main thread is trying to destroy them).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1856>
_______________________________________

From report at bugs.python.org  Mon Sep 20 14:10:06 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 20 Sep 2010 12:10:06 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284812616.15.0.681363404292.issue9877@psf.upfronthosting.co.za>
Message-ID: <20100920080953.55bfa8fe@mission>


Barry A. Warsaw <barry at python.org> added the comment:

On Sep 18, 2010, at 12:23 PM, Antoine Pitrou wrote:

>Antoine Pitrou <pitrou at free.fr> added the comment:
>
>Barry's request looks reasonable. Any build information will have
>platform specificities to it.

Thanks.  I'll take that as approval to land it. :)

>On the other hand, this begs the question of why you want to access
>the Python makefile at all. Is there any information in there that
>isn't currently exposed? I think it would be nice if people could
>completely forget about the existence of that file, and instead have
>nice programmatic APIs to query properties they are interested in.

In principle I agree that the parsing of pyconfig.h and Makefile are
implementation details that shouldn't matter.  I'm working on the bug to
pre-parse these at build time and generate a _sysconfig module that sysconfig
would import.  However, for introspection purposes, since pyconfig.h's
location is exposed, I wanted symmetry for Makefile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Mon Sep 20 14:21:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 12:21:16 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <20100920080953.55bfa8fe@mission>
Message-ID: <1284985270.3176.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> >On the other hand, this begs the question of why you want to access
> >the Python makefile at all. Is there any information in there that
> >isn't currently exposed? I think it would be nice if people could
> >completely forget about the existence of that file, and instead have
> >nice programmatic APIs to query properties they are interested in.
> 
> In principle I agree that the parsing of pyconfig.h and Makefile are
> implementation details that shouldn't matter.  I'm working on the bug to
> pre-parse these at build time and generate a _sysconfig module that sysconfig
> would import.

I don't think you can pre-parse these at build time, since a Python
executable doesn't exist. You must adopt the reverse approach: pass all
necessary variables on the command-line (e.g. through -DCFLAGS switches)
when compiling the _sysconfig module, from the Makefile.

(I'm assuming that _sysconfig will have to be built-in rather than
dynamically loadable, since it exposes information which is critical for
building dynamic modules :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Mon Sep 20 15:30:24 2010
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 20 Sep 2010 13:30:24 +0000
Subject: [issue1730136] tkFont.__eq__ gives type error
Message-ID: <1284989424.56.0.567149963352.issue1730136@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Closing this again in favor of issue9899.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1730136>
_______________________________________

From report at bugs.python.org  Mon Sep 20 15:35:58 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 20 Sep 2010 13:35:58 +0000
Subject: [issue9862] test_subprocess hangs on AIX
In-Reply-To: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>
Message-ID: <1284989758.59.0.0887401948306.issue9862@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

The problem does not happen with Python 2.6.
The difference is that:

* in Python 2.6,  the subprocess module would try to write at most 512 bytes
cf L1221 in subprocess.py
chunk = input[input_offset : input_offset + 512]

* in Python 2.7 and py3k, the subprocess module will try to write at most _PIPE_BUF bytes
cf L1319 in subprocess.py
chunk = input[input_offset : input_offset + _PIPE_BUF]

When forcing PIPE_BUF to 512 in selectmodule.c, the test will pass.
PIPE_BUF seems to be broken on AIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9862>
_______________________________________

From report at bugs.python.org  Mon Sep 20 15:37:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 13:37:02 +0000
Subject: [issue9899] tkinter test_font fails on OS X with Aqua Tk
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1284989822.36.0.921514844976.issue9899@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch works here (Mandriva Linux).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9899>
_______________________________________

From report at bugs.python.org  Mon Sep 20 15:37:53 2010
From: report at bugs.python.org (Alex)
Date: Mon, 20 Sep 2010 13:37:53 +0000
Subject: [issue1838] Ctypes C-level infinite recursion
In-Reply-To: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za>
Message-ID: <1284989873.51.0.621135584126.issue1838@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Good idea Amaury, seems to work just fine.

----------
Added file: http://bugs.python.org/file18936/python_recursive_as_parameter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1838>
_______________________________________

From report at bugs.python.org  Mon Sep 20 15:45:17 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 13:45:17 +0000
Subject: [issue1887] distutils doesn't support out-of-source builds
In-Reply-To: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za>
Message-ID: <1284990317.59.0.730438785119.issue1887@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

There's been no reply to msg109822, so should this be closed with the Superseder field updated or what?

----------
nosy: +BreamoreBoy, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1887>
_______________________________________

From report at bugs.python.org  Mon Sep 20 15:53:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 13:53:22 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1284990802.13.0.0394822578043.issue1927@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Any *NIX gurus who can sort this one?

----------
nosy: +BreamoreBoy
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1927>
_______________________________________

From report at bugs.python.org  Mon Sep 20 15:58:12 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 13:58:12 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1284991092.47.0.258432215037.issue1943@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

No reply to msg110599, I'll close this in a couple of weeks unless anyone objects.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Mon Sep 20 15:59:36 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 13:59:36 +0000
Subject: [issue1944] Documentation for PyUnicode_AsString (et al.) missing.
In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za>
Message-ID: <1284991176.46.0.172424667429.issue1944@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
assignee: georg.brandl -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1944>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:03:41 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 14:03:41 +0000
Subject: [issue1953] Compact int and float freelists
In-Reply-To: <1201491269.72.0.799398122167.issue1953@psf.upfronthosting.co.za>
Message-ID: <1284991421.72.0.706962331896.issue1953@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I've set the stage to patch review becasue I think this reflects the accepted resolution.  I don't understand why this hasn't been committed, anyone?

----------
nosy: +BreamoreBoy
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1953>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:08:13 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 14:08:13 +0000
Subject: [issue1962] ctypes feature request: Automatic type conversion of
	input arguments to C functions
In-Reply-To: <1201597182.13.0.442457985171.issue1962@psf.upfronthosting.co.za>
Message-ID: <1284991693.0.0.707499683068.issue1962@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this ever likely to happen, given that there's been 2.75 years since the request without a response?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1962>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:12:27 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 14:12:27 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1284991947.84.0.835642125115.issue1975@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this still an issue?  If yes can a *NIX type person action it.  If no can we close it?

----------
nosy: +BreamoreBoy -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:15:02 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 14:15:02 +0000
Subject: [issue1977] Python reinitialization test
In-Reply-To: <1201720244.02.0.0976736262476.issue1977@psf.upfronthosting.co.za>
Message-ID: <1284992102.48.0.919351818377.issue1977@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Quote msg83564 "This is still a good idea.", in which case shouldn't someone push this forward, failing that close as out of date?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1977>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:18:09 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 14:18:09 +0000
Subject: [issue2005] posixmodule expects sizeof(pid_t/gid_t/uid_t) <=
	sizeof(long)
In-Reply-To: <1202068724.99.0.704404319493.issue2005@psf.upfronthosting.co.za>
Message-ID: <1284992289.05.0.858446716035.issue2005@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I'm assuming that this has never been implemented, am I correct?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2005>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:23:15 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 14:23:15 +0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1284992595.95.0.323404694248.issue2016@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can someone please backport this to 2.7 so we can get this closed, thanks.

----------
nosy: +BreamoreBoy
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:27:15 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 14:27:15 +0000
Subject: [issue2027] Module containing C implementations of common text
	algorithms
In-Reply-To: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>
Message-ID: <1284992835.21.0.22298350563.issue2027@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I'll close this as suggested in msg106281 in a couple of weeks unless someone objects.

----------
nosy: +BreamoreBoy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2027>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:33:49 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 20 Sep 2010 14:33:49 +0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1284993229.81.0.950857533041.issue2016@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The fix was applied to trunk before the creation of the 2.7 branch.
There is nothing to backport

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:34:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 20 Sep 2010 14:34:11 +0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1284992595.95.0.323404694248.issue2016@psf.upfronthosting.co.za>
Message-ID: <AANLkTinRUuJJCtuL=nfo3SmB9fvsm85Hdr=pNaf2T6wH@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Sep 20, 2010 at 10:23 AM, Mark Lawrence <report at bugs.python.org> wrote:
>
> Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:
>
> Can someone please backport this to 2.7 so we can get this closed, thanks.
>

AFAICT, r73564 preceded 2.7 branch cut, so the fix is already in 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:42:18 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 14:42:18 +0000
Subject: [issue2039] Pymalloc patch for int and float objects
In-Reply-To: <1202404760.1.0.562652734774.issue2039@psf.upfronthosting.co.za>
Message-ID: <1284993738.37.0.271830102691.issue2039@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

If my reading of this is correct there is little or nothing to be gained by applying any patch, hence can this be closed?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2039>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:59:05 2010
From: report at bugs.python.org (Reid Kleckner)
Date: Mon, 20 Sep 2010 14:59:05 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1284994745.8.0.26110819191.issue5673@psf.upfronthosting.co.za>


Reid Kleckner <rnk at mit.edu> added the comment:

No, sorry, I just haven't gotten around to reproducing it on Linux.

And I've even needed this functionality in the mean time, and we worked around it with the standard alarm trick!  =/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Mon Sep 20 16:59:11 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 14:59:11 +0000
Subject: [issue2052] Allow changing difflib._file_template character encoding.
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1284994751.88.0.939222020965.issue2052@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

difflib._file_template is still hard-coded in py3k SVN.  I'm unsure as to whether this is a feature request, a behaviour issue or not an issue at all, can someone please advise, thanks.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
_______________________________________

From report at bugs.python.org  Mon Sep 20 17:05:33 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 20 Sep 2010 15:05:33 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1284991092.47.0.258432215037.issue1943@psf.upfronthosting.co.za>
Message-ID: <AANLkTinMa4=ESXBBL7ffYS6sE-90EBzU-s6vVpF5HOZa@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/9/20 Mark Lawrence <report at bugs.python.org>:
>
> Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:
>
> No reply to msg110599, I'll close this in a couple of weeks unless anyone objects.

Please don't. This is still a valid issue.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Mon Sep 20 17:06:05 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 20 Sep 2010 15:06:05 +0000
Subject: [issue1865] Bytes alias for 2.6
In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za>
Message-ID: <1284995165.11.0.622980661891.issue1865@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1865>
_______________________________________

From report at bugs.python.org  Mon Sep 20 17:30:18 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 20 Sep 2010 15:30:18 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284996618.07.0.250597130429.issue9877@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r84925

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Mon Sep 20 18:21:29 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 20 Sep 2010 16:21:29 +0000
Subject: [issue9862] test_subprocess hangs on AIX
In-Reply-To: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>
Message-ID: <1284999689.43.0.912730250482.issue9862@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

PIPE_BUF in unistd.h is defined to 32768.

The test works with PIPE_BUF changed up to 6144 but won't work with 7168.

We could probably use 4096 as a safe value for faster result if needed.
I just do not define the value and leave the default of 512 be used.

Here is my patch which has been verified to work OK and should be applied to py3k and py27.

----------
keywords: +patch
Added file: http://bugs.python.org/file18937/patch_broken_pipe_buf.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9862>
_______________________________________

From report at bugs.python.org  Mon Sep 20 18:24:49 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 20 Sep 2010 16:24:49 +0000
Subject: [issue9862] PIPE_BUF is invalid on AIX
In-Reply-To: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>
Message-ID: <1284999889.76.0.072521175013.issue9862@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
title: test_subprocess hangs on AIX -> PIPE_BUF is invalid on AIX

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9862>
_______________________________________

From report at bugs.python.org  Mon Sep 20 18:29:03 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 16:29:03 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1285000143.52.0.468035569372.issue2057@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this really needed?  TortoiseSVN is a cracking bit of kit, and I'm hoping that in the future TortoiseHG is as good if not better.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
_______________________________________

From report at bugs.python.org  Mon Sep 20 18:37:36 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 16:37:36 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1285000656.95.0.431956834171.issue2091@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

The patch is now way out of date to the extent that I can't find the code in fileobject.c, perhaps I'm just blind  Can someone please provide a new patch, thanks.

----------
nosy: +BreamoreBoy
versions: +Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2091>
_______________________________________

From report at bugs.python.org  Mon Sep 20 18:39:49 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 16:39:49 +0000
Subject: [issue2123] ctypes pointer not always keeping target alive
In-Reply-To: <1203085504.98.0.560350426708.issue2123@psf.upfronthosting.co.za>
Message-ID: <1285000789.12.0.83682888106.issue2123@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
versions: +Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2123>
_______________________________________

From report at bugs.python.org  Mon Sep 20 19:33:03 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 20 Sep 2010 17:33:03 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1285003983.88.0.202663089565.issue2091@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Of course, the implementation is now in the io module:
Modules/_io/_iomodule.c *and* Lib/_pyio.py

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2091>
_______________________________________

From report at bugs.python.org  Mon Sep 20 19:41:32 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 20 Sep 2010 17:41:32 +0000
Subject: [issue9898] cProfile.runctx doesn't allow sort argument
In-Reply-To: <1284922541.3.0.303854957861.issue9898@psf.upfronthosting.co.za>
Message-ID: <1285004492.57.0.448584267096.issue9898@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

yes, as you can see in the diffs, it's already in 3.2alpha2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9898>
_______________________________________

From report at bugs.python.org  Mon Sep 20 19:59:36 2010
From: report at bugs.python.org (Thomas Claveirole)
Date: Mon, 20 Sep 2010 17:59:36 +0000
Subject: [issue9905] subprocess.Popen fails with stdout=PIPE,
	stderr=PIPE if standard descriptors (0, 1, 2) are closed.
In-Reply-To: <1285005576.46.0.387895977213.issue9905@psf.upfronthosting.co.za>
Message-ID: <1285005576.46.0.387895977213.issue9905@psf.upfronthosting.co.za>


New submission from Thomas Claveirole <thomas.claveirole at gmail.com>:

Hello,

Here is a code that exhibits an invalid behavior (Python 2.6.6):
---8<---
import subprocess, os

os.close(0) # Works correctly if any of these two are commented out.
os.close(2)

print subprocess.Popen('echo foo>&2', shell=True,
                       stdout=subprocess.PIPE,
                       stderr=subprocess.PIPE).communicate()
--->8---

When run, the output is:
('', '')

While it should be:
('', 'foo\n')

When analyzing the code with strace the problem gets clearer:
$ strace -f -e pipe,fork,dup2,close ./Popen-bug.py
[...]
5085  pipe([0, 2])                      = 0  # Creates the pipes.
5085  pipe([3, 4])                      = 0
5085  pipe([5, 6])                      = 0
[...] # In this skipped part Popen() closes useless pipe endpoints.
5086  dup2(2, 1)                        = 1 # stdout setup.
5086  dup2(4, 2)                        = 2 # stderr setup.
5086  close(2)                          = 0
[...]

The last "close(2)" is the error: apparently Popen() tries to close the remaining pipe endpoints (as should theoretically be done) but fails to see that the endpoint created by pipe([0, 2]) has already been closed during the previous dup2(4, 2) and that the file descriptor 2 is now the standard error.  Therefore, Popen incorrectly closes the standard error.

To fix that, Popen should check, before closing the remaining pipe endpoints, that these endpoints are not the one that just get closed by the two previous dup2s.

Best regards,

----------
components: Library (Lib)
messages: 116957
nosy: Thomas.Claveirole
priority: normal
severity: normal
status: open
title: subprocess.Popen fails with stdout=PIPE, stderr=PIPE if standard descriptors (0, 1, 2) are closed.
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9905>
_______________________________________

From report at bugs.python.org  Mon Sep 20 20:07:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 18:07:16 +0000
Subject: [issue1977] Python reinitialization test
In-Reply-To: <1201720244.02.0.0976736262476.issue1977@psf.upfronthosting.co.za>
Message-ID: <1285006036.25.0.546711647386.issue1977@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Quote msg83564 "This is still a good idea.", in which case shouldn't
> someone push this forward, failing that close as out of date?

Just because someone doesn't "push this forward" doesn't mean it's out of date.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1977>
_______________________________________

From report at bugs.python.org  Mon Sep 20 20:20:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 18:20:35 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1284948286.97.0.989901474065.issue9360@psf.upfronthosting.co.za>
Message-ID: <1285006829.3228.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Gah.  I reviewed patch4, didn't noticed today's update :(

Oops, I'm sorry for that. It turns out most of your comments are useful anyway.

> Why is it a good thing to make file a keyword only parameter?

I was thinking that if we want to add other function parameters, it will
be possible to do so while keeping the (mnemonically useful) convention
that the file parameter is last.

You are right that testing that parameter is still on the TODO list...

> On line 193 you index fmt, and *then* you check the length.  When the
> number of tokens is too long, an IndexError is raised.

Yes, this is fixed in patch5 :)

> Could the 'date' field in the xover headers also be a DateTime rather
> than a string?  And :bytes and :lines be ints?  Or is that being to
> DWIMish?

We could indeed parse the xover/over fields, but the issue is that there
can be extra fields which therefore won't get parsed (or not all of them
if we decide to recognize some e.g. "Xref").

Also, people could want to get at the non-parsed representation
(especially for the date field), which means we would need two APIs with
two different levels of abstraction.

> If the date field isn't returned as a datetime, though, should there
> be a helper method for converting it, or should we just assume that
> email.utils mktime_tz and parsedate_tz?

parsedate or parsedate_tz is the right thing to use indeed (dates follow
the same format as in e-mails). As for the from and subject fields, the
provided decode_header() is very recommended (as the __main__ block
shows).

> Am I correct that the purpose of _NNTPBase is to make testing easier?

Yes.

> There seem to be only three lines of code in common between the file
> and the non-file case in _getlongresp.  I think it would be clearer to
> make them two different routines, or at least move the three common
> lines to the top and then do an if test on file is None (that is, put
> the simpler, non-file case first).

I'll take a look.

> My little nttp client script doesn't really test very much of the
> nttplib interface, nor is it very complex.  The change to xover
> considerably simplified that part of my script, so I very much like
> that change.  I was also able to drop my implementation of
> decode_header.  So overall this patch is significant improvement, IMO.

Thank you :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Mon Sep 20 20:33:21 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 20 Sep 2010 18:33:21 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1285007601.37.0.579241522143.issue2057@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Unified diffs is the preferred type on this tracker as http://www.python.org/dev/patches/ describes. I also sure that they constitute more than 90% of patches attached here. If you have access to tracker attachments - you can test this.

Unfortunately, diff.py generates context diffs by default, and I do not have plans to add this format into my patch.py tool, so it won't be a correct counterpart to include in Scripts/

By ' diff/patch lib is not.' I meant that 'diff/patch _lib_ is not ready'. You can use patch.py as a tool, but don't rely that API is stable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
_______________________________________

From report at bugs.python.org  Mon Sep 20 20:49:36 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Sep 2010 18:49:36 +0000
Subject: [issue1887] distutils doesn't support out-of-source builds
In-Reply-To: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za>
Message-ID: <1285008576.55.0.130659086045.issue1887@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I suspect so, but I leave it to Eric to decide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1887>
_______________________________________

From report at bugs.python.org  Mon Sep 20 20:49:50 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Sep 2010 18:49:50 +0000
Subject: [issue1887] distutils doesn't support out-of-source builds
In-Reply-To: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za>
Message-ID: <1285008590.86.0.543742316646.issue1887@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/issue1887>
_______________________________________

From report at bugs.python.org  Mon Sep 20 20:55:25 2010
From: report at bugs.python.org (Lenard Lindstrom)
Date: Mon, 20 Sep 2010 18:55:25 +0000
Subject: [issue1800] ctypes callback fails when called in Python with array
	argument
In-Reply-To: <1200093299.88.0.890377527012.issue1800@psf.upfronthosting.co.za>
Message-ID: <1285008925.68.0.554329545312.issue1800@psf.upfronthosting.co.za>


Lenard Lindstrom <len-l at telus.net> added the comment:

I have checked over the proposed patch and made a small change that more elegantly obtains PyCArrayType. Decaying arrays into pointers is not an ideal solution. Ctypes arrays have bounds checking (pointers do not) adding an extra margin of safety when a C function prototype has sized arrays in the declaration. But this is a rare case. So the proposed patch is good enough. The alternative is to reject arrays as arguments altogether, with CFUNCTYPE raising an exception if one is found.

The problem lies with line 1241 in _ctypes.c and line 221 in callbacks.c (r84925 or py3k). In the first case, the value of CDataObject.b_ptr is assigned to PyCArgObject.value.p. In the second case PyCArgObject.value.p (*pArgs) is recovered to *CDataObject.b_ptr. I see no way to fix this without changes to several functions and files.

----------
Added file: http://bugs.python.org/file18938/issue1800.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1800>
_______________________________________

From report at bugs.python.org  Mon Sep 20 21:21:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Sep 2010 19:21:03 +0000
Subject: [issue1865] Document bytes alias for 2.7
In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za>
Message-ID: <1285010463.26.0.528472167012.issue1865@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Changing title to match current issue status.

DOC PATCH

Grammar section: As near as I can tell, the alternatives for 

stringprefix    ::=  "r" | "u" | "ur" | "R" | "U" | "UR" | "Ur" | "uR"

should simply be augmented with

                     | "b" | "B" | "br" | "Br" | "bR" | "BR"

(on a separate line, indented as indicated).

Text section: At the end of the second paragraph, *replace*

"The two prefix characters may be combined; in this case, 'u' must appear before 'r'."

with

"A prefix of 'b' or 'B' is ignored in Python2; it indicates that the literal should become a bytes object in Python 3. A 'u' or 'b' prefix may be followed (but not preceded) by an 'r' prefix."

----------
components:  -Interpreter Core
resolution: fixed -> 
title: Bytes alias for 2.6 -> Document bytes alias for 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1865>
_______________________________________

From report at bugs.python.org  Mon Sep 20 21:31:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 19:31:12 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1285011072.48.0.881469556455.issue1625@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an update of the patch against current py3k. I've added a copyright mention at the top of Modules/bz2module.c which I hope manages to capture the essence of msg93721. Martin, what do you think?

----------
nosy: +loewis
stage:  -> patch review
versions:  -Python 2.7
Added file: http://bugs.python.org/file18939/bz2ms.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Mon Sep 20 21:55:07 2010
From: report at bugs.python.org (Michael Gilbert)
Date: Mon, 20 Sep 2010 19:55:07 +0000
Subject: [issue9401] automatically try forward operations when reverse
	operations are NotImplemented
In-Reply-To: <1280339816.95.0.28348031653.issue9401@psf.upfronthosting.co.za>
Message-ID: <1285012507.24.0.222981149433.issue9401@psf.upfronthosting.co.za>


Michael Gilbert <michael.s.gilbert at gmail.com> added the comment:

i think that, for example, the default __rsub__ implementation could be:

  return self + -other

which should just do the right thing assuming the addition and negation functions already do the right thing for the class type.

anyway, any implementation should leave the option to override the default __r*__ methods, which would keep the implementation backwards compatible as well.

can i keep this open as a feature request?

thanks,
mike

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9401>
_______________________________________

From report at bugs.python.org  Mon Sep 20 22:05:01 2010
From: report at bugs.python.org (Michael Gilbert)
Date: Mon, 20 Sep 2010 20:05:01 +0000
Subject: [issue9906] including elementary mathematical functions in default
	types
In-Reply-To: <1285013101.44.0.231152316832.issue9906@psf.upfronthosting.co.za>
Message-ID: <1285013101.44.0.231152316832.issue9906@psf.upfronthosting.co.za>


New submission from Michael Gilbert <michael.s.gilbert at gmail.com>:

hi,

it would be really nice if elementary mathematical operations such as sin/cosine (via __sin__ and __cos__) were available as base parts of the python data model [0].  this would make it easier to write new math classes, and it would eliminate the ugliness of things like self.exp().

this would also eliminate the need for separate math and cmath libraries since those could be builtin to the default float and complex types.  of course if those libs were removed, that would cause a lot of backward compatibility breakage.

it would also help new users who just want to do math and don't know that they need to import separate classes just for elementary math functionality.

anyway, just a thought.

[0] http://docs.python.org/reference/datamodel.html

----------
components: Interpreter Core
messages: 116966
nosy: Michael.Gilbert
priority: normal
severity: normal
status: open
title: including elementary mathematical functions in default types
versions: Python 2.5, 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/issue9906>
_______________________________________

From report at bugs.python.org  Mon Sep 20 22:06:44 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 20 Sep 2010 20:06:44 +0000
Subject: [issue1531775] HTTPSConnection request hangs
Message-ID: <1285013204.13.0.779202384177.issue1531775@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Skimming through the code, the only place where we can reasonably block is inside HTTPConnection._send_output(), when the data is actually sent to the socket.
What probably happens is the following:
- connect() call succeeded, we have an established TCP connection
- before request() is called - or in the middle of the sending - the host at the other host goes down in brutal way, so that we don't receive a FIN/RST: the TCP stack has no clue that the remote host went down
- we keep sending data through the socket, until the socket write buffer fills up, and then, since httplib uses blocking sockets by default, we block on the send() call

Now, depending on the TCP stack setting, after a given number of retries the stack will decide the other host went down, and return an error. But this can take a long time (under Linux, it's set by net.ipv4.tcp_retries2 sysctl by default to 30 minutes).
The only thing that surprises me here is that when the host is back online, we should get a RST, but it depends on the OS, the timeouts, maybe there's a statefull firewall, etc.

So I'd say it's not a httplib issue here, it's just a standard behaviour of a TCP connection when an host goes down.

Note that the solution is simply to use non-blocking socket, and it's already implemented. Heck, it's even documented actually:

class httplib.HTTPConnection(host[, port[, strict[, timeout[, source_address]]]])
If the optional timeout parameter is given, blocking operations (like connection attempts) will timeout after that many seconds (if it is not given, the global default timeout setting is used).

So for me it's not an issue, but given the lack of infos, maybe I got it completely wrong ;-)

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1531775>
_______________________________________

From report at bugs.python.org  Mon Sep 20 22:14:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 20:14:09 +0000
Subject: [issue9901] GIL destruction can fail
In-Reply-To: <1284940662.22.0.656569610088.issue9901@psf.upfronthosting.co.za>
Message-ID: <1285013649.18.0.811337375248.issue9901@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r84927.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9901>
_______________________________________

From report at bugs.python.org  Mon Sep 20 22:26:32 2010
From: report at bugs.python.org (intgr)
Date: Mon, 20 Sep 2010 20:26:32 +0000
Subject: [issue675698] New block cipher API
Message-ID: <1285014392.14.0.665465802294.issue675698@psf.upfronthosting.co.za>


Changes by intgr <marti at juffo.org>:


----------
nosy: +intgr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue675698>
_______________________________________

From report at bugs.python.org  Mon Sep 20 22:33:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 20:33:31 +0000
Subject: [issue9650] format codes in time.strptime docstrings
In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za>
Message-ID: <1285014811.48.0.201087772222.issue9650@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9650>
_______________________________________

From report at bugs.python.org  Mon Sep 20 22:36:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 20:36:45 +0000
Subject: [issue9845] Allow changing the method in urllib.request.Request
In-Reply-To: <1284383235.98.0.831352562835.issue9845@psf.upfronthosting.co.za>
Message-ID: <1285015005.28.0.380007960763.issue9845@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 on the idea and code patch.  Needs test and doc update.

----------
nosy: +eric.araujo
stage:  -> patch review
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9845>
_______________________________________

From report at bugs.python.org  Mon Sep 20 22:58:01 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Sep 2010 20:58:01 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1285016281.01.0.155492319441.issue2057@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Given that difflib produces unified diffs (among 3 others) and that diff.py is a thin command-line wrapper that provides access to all 4 formats (with no default), I consider those two files 'ready'. So I presume you are referring to your patch.py, which is still labelled experimental.

Difflib works by analyzing sequences a and b with SequenceMatcher to produce a sequence of edits that would produce b from a. It then formats the edits into 1 of 4 formats.

Ideally, a patchlib would have a core SequenceEditor that would apply a sequence of edits (in the same format as SequenceMatcher's outputs) to sequence a to output sequence b. That much seems relatively easy. To be complete, it should also have at least 3 if not 4 parse functions that would produce edit sequences. A corresponding patch.py would then be a thin command-line wrapper over patchlib.

Your comments and a perusal of your code indicates that it has a unified diff parser, a sequence matcher, and command-line wrapper. I guess the immediate question is whether this would be enough for a start.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
_______________________________________

From report at bugs.python.org  Mon Sep 20 22:58:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 20:58:05 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1284958625.17.0.197478757866.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285016281.3228.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This is the patch I'm thinking of. I confirmed this works
> on VS8.0. (After replaced "..\\.." with "..\\..\\..")

Works here too (VS 2008)!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:02:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 21:02:45 +0000
Subject: [issue9272] CGIHTTPServer poisons os.environ
In-Reply-To: <1279270191.51.0.568678636745.issue9272@psf.upfronthosting.co.za>
Message-ID: <1285016565.14.0.709215818835.issue9272@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: unit test needed -> patch review
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9272>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:09:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 21:09:14 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1285016954.53.0.480341061428.issue9860@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does this apply to 2.7 too?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:12:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 21:12:28 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
	removed
In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>
Message-ID: <1285017148.27.0.262414889748.issue9850@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree with Ronald?s proposal.

(Re ?I don't remember if I redid my OS9-removal work?: Looks like you didn?t.)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:13:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 21:13:20 +0000
Subject: [issue9847] Binary strings never compare equal to raw/normal strings
In-Reply-To: <1284399075.73.0.514162795967.issue9847@psf.upfronthosting.co.za>
Message-ID: <1285017200.54.0.095572936142.issue9847@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: works for me -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9847>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:17:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 21:17:59 +0000
Subject: [issue7162] 2to3 does not convert __builtins__.file
In-Reply-To: <1255814979.41.0.0993610579435.issue7162@psf.upfronthosting.co.za>
Message-ID: <1285017479.76.0.591955850856.issue7162@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7162>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:19:47 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 20 Sep 2010 21:19:47 +0000
Subject: [issue9272] CGIHTTPServer poisons os.environ
In-Reply-To: <1279270191.51.0.568678636745.issue9272@psf.upfronthosting.co.za>
Message-ID: <1285017587.36.0.800147997435.issue9272@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

So..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9272>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:23:48 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 21:23:48 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1285017828.59.0.648532563266.issue2175@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

As nobody appears to be interested I'll close this in a couple of weeks unless someone objects.

----------
nosy: +BreamoreBoy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:24:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 21:24:25 +0000
Subject: [issue9621] Graphviz output for 2to3 fixer patterns
In-Reply-To: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za>
Message-ID: <1285017865.63.0.474265372319.issue9621@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you port your diff to 3.2?  It?s where new features land.

I think the implicit relative import (?import gvgraph? with the Tools/scripts dir is not on sys.path) won?t work.

----------
nosy: +benjamin.peterson, eric.araujo
stage:  -> patch review
type:  -> feature request
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9621>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:26:25 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 21:26:25 +0000
Subject: [issue2180] tokenize: mishandles line joining
In-Reply-To: <1203904758.19.0.84784431119.issue2180@psf.upfronthosting.co.za>
Message-ID: <1285017985.11.0.438097840432.issue2180@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Nobody appears to be interested so I'll close this in a couple of weeks unless someone objects, unless a patch is provided.

----------
nosy: +BreamoreBoy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2180>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:27:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 21:27:04 +0000
Subject: [issue9597] mac: Install 2to3 in /usr/local/bin
In-Reply-To: <1281738541.55.0.960534882511.issue9597@psf.upfronthosting.co.za>
Message-ID: <1285018024.82.0.302064705495.issue9597@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Which makefile target are you referring to?  I see 2to3 listed alongside idle and other programs in some targets.  Also, doesn?t this apply to 3.1?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9597>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:27:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 21:27:18 +0000
Subject: [issue9597] mac: Install 2to3 in /usr/local/bin
In-Reply-To: <1281738541.55.0.960534882511.issue9597@psf.upfronthosting.co.za>
Message-ID: <1285018038.64.0.11213473698.issue9597@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Installation -2to3 (2.x to 3.0 conversion tool), Build, Macintosh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9597>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:27:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 21:27:38 +0000
Subject: [issue9597] mac: Install 2to3 in /usr/local/bin
In-Reply-To: <1281738541.55.0.960534882511.issue9597@psf.upfronthosting.co.za>
Message-ID: <1285018058.07.0.134206903843.issue9597@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Macintosh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9597>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:29:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 21:29:03 +0000
Subject: [issue9583] PYTHONOPTIMIZE = 0 is not honored
In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za>
Message-ID: <1285018143.34.0.00187844752314.issue9583@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9583>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:29:51 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 21:29:51 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1285018191.08.0.667197127819.issue2193@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this a bug or isn't it, so should it be behaviour or feature request or what?

----------
nosy: +BreamoreBoy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:33:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 21:33:29 +0000
Subject: [issue9571] argparse: Allow the use of -- to break out of nargs and
	into subparser
In-Reply-To: <1281554487.14.0.725527410465.issue9571@psf.upfronthosting.co.za>
Message-ID: <1285018409.09.0.00554442647598.issue9571@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/issue9571>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:33:33 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 21:33:33 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1285018413.04.0.64335651119.issue2200@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I think distutils changes should be aimed at several versions, please correct them if I'm wrong.

----------
nosy: +BreamoreBoy, eric.araujo
versions: +Python 2.5, Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:36:47 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Sep 2010 21:36:47 +0000
Subject: [issue9907] interactive mode TAB does not insert on OS X built with
	editline instead of GNU readline
In-Reply-To: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>
Message-ID: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

When building Python on OS X, there is now support for linking Python with the readline compatibility interface of the OS X supplied BSD editline library rather than using the GNU readline library.  Because of deficiencies in the version in earlier OS X releases, this support is only enabled for builds with a deployment target of 10.5 or higher.  With the python 2.7 release, for the first time a python.org installer for OS X is available that uses this capability: the 10.5 and higher 32-bit/64-bit version. The 10.3 and higher 32-bit-only installer uses GNU readline as do previous installers.  There is a behavior regression in the editline-linked versions: when started in interactive mode, the TAB key does not insert, rather it inserts a "./" file spec in the command buffer and a second TAB causes a completion search of files in the current directory.

With readline and typing <TAB> <CR>:

  $ unset PYTHONSTARTUP 
  $ python2.7
  Python 2.7 (r27:82508, Jul  3 2010, 20:17:05) 
  [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>>     
  ... 
  $ 

With editline and <TAB> <CR>:

  $ unset PYTHONSTARTUP 
  $ python2.7
  Python 2.7 (r27:82508, Jul  3 2010, 21:12:11) 
  [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> ./
    File "<stdin>", line 1
      ./
      ^
  SyntaxError: invalid syntax
  >>> ^D

Two workarounds for python2.7 until the problem is addressed in a future installer:

   (1) either install the 10.3 and up python 2.7

or (2) add or edit a python startup file for python2.7:

       $ cat > $HOME/.pystartup
       import readline
       if 'libedit' in readline.__doc__:
           readline.parse_and_bind("bind ^I ed-insert")
       ^D
       $ export PYTHONSTARTUP=$HOME/.pystartup


Since whitespace is significant in Python, Modules/readline.c initialization attempts to override TAB behavior by forcing TAB to "insert" by default (unless overridden by later readline module calls).  Somehow that is failing when going through editline's readline compatibility layer.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 116981
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: interactive mode TAB does not insert on OS X built with editline instead of GNU readline
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9907>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:40:28 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 20 Sep 2010 21:40:28 +0000
Subject: [issue1953] Compact int and float freelists
In-Reply-To: <1201491269.72.0.799398122167.issue1953@psf.upfronthosting.co.za>
Message-ID: <1285018828.59.0.854696566916.issue1953@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The remarks above haven't been addressed. The feature is OK, but the patch is not yet perfect.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1953>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:43:54 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 21:43:54 +0000
Subject: [issue2213] build_tkinter.py does not handle paths with spaces
In-Reply-To: <1204331742.92.0.0412981555519.issue2213@psf.upfronthosting.co.za>
Message-ID: <1285019034.73.0.316827024248.issue2213@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Is this still valid?

----------
nosy: +BreamoreBoy, gpolo, taleinat, terry.reedy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2213>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:46:28 2010
From: report at bugs.python.org (Yitz Gale)
Date: Mon, 20 Sep 2010 21:46:28 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1285019188.07.0.210451811527.issue2175@psf.upfronthosting.co.za>


Yitz Gale <gale at sefer.org> added the comment:

Perhaps more people would be interested if
you raise the priority. This bug can cause
serious data corruption, or even crashes.
It should also be tagged as "easy".

An alternative would be to remove the expat
sax parser from the libraries, since we don't
support it. But that seems a little extreme.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:51:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Sep 2010 21:51:53 +0000
Subject: [issue2180] tokenize: mishandles line joining
In-Reply-To: <1203904758.19.0.84784431119.issue2180@psf.upfronthosting.co.za>
Message-ID: <1285019513.36.0.233942228388.issue2180@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Mark, please stop closing these based on age.
The needs to be a determination whether this
is a valid bug.  If so, then a patch is needed.
If not, it can be closed.

----------
assignee: jhylton -> 
nosy: +rhettinger
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2180>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:58:45 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Sep 2010 21:58:45 +0000
Subject: [issue9907] interactive mode TAB does not insert on OS X built with
	editline instead of GNU readline
In-Reply-To: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>
Message-ID: <1285019925.37.0.806749121489.issue9907@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

[Thanks to Nik Krumm for reporting the problem on python-list/comp.lang.python]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9907>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:02:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:02:13 +0000
Subject: [issue4151] Separate build dir broken
In-Reply-To: <1224522256.17.0.820973690454.issue4151@psf.upfronthosting.co.za>
Message-ID: <1285020133.1.0.925130178827.issue4151@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For the record, I?m not clear about what is fixed or not in each branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4151>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:06:07 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 20 Sep 2010 22:06:07 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1285016281.01.0.155492319441.issue2057@psf.upfronthosting.co.za>
Message-ID: <AANLkTikY4Lvg1K+0CLCRu7L_EBiOK-hBXzLvbQYb3Ueo@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Mon, Sep 20, 2010 at 11:58 PM, Terry J. Reedy <report at bugs.python.org> wrote:
> Given that difflib produces unified diffs (among 3 others) and that diff.py is a thin command-line wrapper that provides access to all 4 formats (with no default), I consider those two files 'ready'.

Context diff is default format for diff.py utility. I tried my best to
change this, but failed, and that's very disappointing in Python
community. You may take a look how much time was wasted on a decision
for a file that is neither part of standard library nor really used by
anyone participated except me. http://bugs.python.org/issue8355

> So I presume you are referring to your patch.py, which is still labelled experimental.
>
> Difflib works by analyzing sequences a and b with SequenceMatcher to produce a sequence of edits that would produce b from a. It then formats the edits into 1 of 4 formats.
>
> Ideally, a patchlib would have a core SequenceEditor that would apply a sequence of edits (in the same format as SequenceMatcher's outputs) to sequence a to output sequence b. That much seems relatively easy. To be complete, it should also have at least 3 if not 4 parse functions that would produce edit sequences. A corresponding patch.py would then be a thin command-line wrapper over patchlib.

Difflib doesn't produce correct output for unified format, and
patch.py is not able to parse it correctly - see issue2142, issue7585
(for Python 2.6). patch.py doesn't operate with sequences of edits -
it has line by line parser (rather than symbol by symbol), which
produces list of filenames with info about changed lines in hunk
objects (containing line numbers). There is no SequenceEditor
sequences.

> Your comments and a perusal of your code indicates that it has a unified diff parser, a sequence matcher, and command-line wrapper. I guess the immediate question is whether this would be enough for a start.

Unified diff parser is valid only for Subversion style patches.
Patches produced by difflib are not valid as stated above. Mercurial
and git style patches are about to be added later with an ability to
create and copy/move files.

Sequence matcher is line comparison tool with some intelligence to
free developer from CRLF difference sufferings. It is good for "apply
patch" use case, but I do not know how about low-level SequenceEditor
API. Usually patch utilities contains more additional logic to apply
patches with some offset.

http://code.google.com/p/google-diff-match-patch/ will be a better
point for low level difflib API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:08:15 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 20 Sep 2010 22:08:15 +0000
Subject: [issue2027] Module containing C implementations of common text
	algorithms
In-Reply-To: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>
Message-ID: <1285020495.95.0.828434596096.issue2027@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2027>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:09:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:09:27 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1285020567.32.0.591260090549.issue9877@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry for being out of touch.  I?m fine with the new feature here and now; we still have the deprecation process if we want to make both get_config_h_filename and get_makefile_filename private later (as implementation details), or we could have them return None for other VMs.  We?ll see when we split the stdlib into its own repo or when we get feedback from other VMs.

----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:11:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:11:13 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1285020673.56.0.432177943359.issue2090@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:16:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:16:08 +0000
Subject: [issue9906] including elementary mathematical functions in default
	types
In-Reply-To: <1285013101.44.0.231152316832.issue9906@psf.upfronthosting.co.za>
Message-ID: <1285020968.06.0.879330133.issue9906@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.smith, lemburg, mark.dickinson, rhettinger, stutzbach
type:  -> feature request
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9906>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:19:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:19:49 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1285021189.54.0.654072850613.issue9893@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Those files are useful for me, even if I had to tweak them slightly.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:20:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:20:18 +0000
Subject: [issue9891] Minor doc typo at datamodel.rst: "list" -> "alist"
In-Reply-To: <1284801081.96.0.0540649030597.issue9891@psf.upfronthosting.co.za>
Message-ID: <1285021218.7.0.535601729061.issue9891@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9891>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:21:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:21:44 +0000
Subject: [issue9887] distutil's build_scripts doesn't read utf-8 in all locales
In-Reply-To: <1284729593.16.0.252664137674.issue9887@psf.upfronthosting.co.za>
Message-ID: <1285021304.42.0.73423081688.issue9887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does POSIX mandate an encoding when using the C locale?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9887>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:23:39 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 20 Sep 2010 22:23:39 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1285021419.38.0.584682306959.issue4709@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/issue4709>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:25:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:25:37 +0000
Subject: [issue9882] abspath from directory
In-Reply-To: <1284682917.39.0.650396347526.issue9882@psf.upfronthosting.co.za>
Message-ID: <1285021537.18.0.0446896894557.issue9882@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Would you bring this up on python-ideas?  I am neither +1 nor -1 on your idea, but I know that symmetry/consistency is not always a winning rationale.  Not every possibly useful one-liner should be a standard function.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9882>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:32:55 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Sep 2010 22:32:55 +0000
Subject: [issue9865] OrderedDict doesn't implement __sizeof__
In-Reply-To: <1284585159.01.0.70557172329.issue9865@psf.upfronthosting.co.za>
Message-ID: <1285021975.59.0.210536463711.issue9865@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r84852

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9865>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:44:24 2010
From: report at bugs.python.org (lorph)
Date: Mon, 20 Sep 2010 22:44:24 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1285022664.84.0.530775970673.issue8998@psf.upfronthosting.co.za>


lorph <lorph1 at gmail.com> added the comment:

> Do you think that if OpenSSL provided its own implementation of strlen(), every text that mentions strlen() needs to acknowledge OpenSSL? Do you realize how ridiculous that is?

If that text is deemed to be advertising by Eric Young and a court of law, then absolutely yes. The license is short, clear, and does not make any exceptions for features that you might deem to be commonplace.

http://www.openssl.org/source/license.html

I also agree that this is ridiculous, but believing something is ridiculous does not make it any less real as Barnes and Nobles learned the hard way by using Amazon's one-click patent.

> The important thing to realize is that libtomcrypt is
intentionally written in very portable C.  That is great but it leaves a lot on the table. Optimizations for various platforms to take advantage of enhanced instruction sets such as SSE2 and explicit hardware crypto acceleration instructions such as [...] are not likely to be part of libtomcrypt, 

A quick glance at libtomcrypt tells me otherwise. It is portable C, but it still has inline assembler. It has optimizations using SSE2, x86, x86_64, and PPC32. Even though it might not have that new Intel AES instruction yet, this is the same argument people had for using GMP for python's integers.

If there is a problem with multiple libraries, I'd like to reiterate my support for migrating to NSS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:46:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 22:46:41 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1285022664.84.0.530775970673.issue8998@psf.upfronthosting.co.za>
Message-ID: <1285022793.3228.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If there is a problem with multiple libraries, I'd like to reiterate
> my support for migrating to NSS.

Will your support go so far as to investigate feasibility and provide a
patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:51:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:51:03 +0000
Subject: [issue9868] test_locale leaves locale changed
In-Reply-To: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>
Message-ID: <1285023063.29.0.777518684037.issue9868@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +giampaolo.rodola, lemburg, michael.foord, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9868>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:53:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 22:53:51 +0000
Subject: [issue9901] GIL destruction can fail
In-Reply-To: <1284940662.22.0.656569610088.issue9901@psf.upfronthosting.co.za>
Message-ID: <1285023231.82.0.386723120148.issue9901@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9901>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:55:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:55:55 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285023355.51.0.726506497024.issue9864@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/issue9864>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:59:21 2010
From: report at bugs.python.org (Buck Golemon)
Date: Mon, 20 Sep 2010 22:59:21 +0000
Subject: [issue9583] PYTHONOPTIMIZE = 0 is not honored
In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za>
Message-ID: <1285023561.54.0.872846818201.issue9583@psf.upfronthosting.co.za>


Buck Golemon <buck.golemon at amd.com> added the comment:

Minimal demo:

$ setenv PYTHONOPTIMIZE 0
$ python3.1 -OO -c "print(__debug__)"
False


I've used this code to get the desired functionality:

if [[ $TESTING == 1 || ${PYTHONOPTIMIZE-2} =~ '^(0*|)$' ]]; then
    #someone is requesting no optimization
    export -n PYTHONOPTIMIZE
    opt=''
elif [[ $PYTHONOPTIMIZE ]]; then
    #someone is setting their own optimization
    opt=''
else
    #optimization by default
    opt='-O'
fi

exec $INSTALL_BASE/bin/python2.6 $opt "$@"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9583>
_______________________________________

From report at bugs.python.org  Tue Sep 21 00:59:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:59:29 +0000
Subject: [issue9533] metaclass can't derive from ABC
In-Reply-To: <1281090819.15.0.255356922996.issue9533@psf.upfronthosting.co.za>
Message-ID: <1285023569.67.0.489918840846.issue9533@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/issue9533>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:00:04 2010
From: report at bugs.python.org (geremy condra)
Date: Mon, 20 Sep 2010 23:00:04 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1285022664.84.0.530775970673.issue8998@psf.upfronthosting.co.za>
Message-ID: <AANLkTinU1btaTDx-NY2o=gNbX75D0ru0UrN0QMxjD7P-@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Mon, Sep 20, 2010 at 3:44 PM, lorph <report at bugs.python.org> wrote:
>
> lorph <lorph1 at gmail.com> added the comment:
>
>> Do you think that if OpenSSL provided its own implementation of strlen(), every text that mentions strlen() needs to acknowledge OpenSSL? Do you realize how ridiculous that is?
>
> If that text is deemed to be advertising by Eric Young and a court of law, then absolutely yes. The license is short, clear, and does not make any exceptions for features that you might deem to be commonplace.
>
> http://www.openssl.org/source/license.html
>
> I also agree that this is ridiculous, but believing something is ridiculous does not make it any less real as Barnes and Nobles learned the hard way by using Amazon's one-click patent.

I get called paranoid a lot, but I don't find this terribly
convincing. Having said that, I'm happy to have your help in making
sure that the interface we create is agnostic with respect to openssl,
libtomcrypt, NSS, etc. That would mean that if Eric Young did decide
to try and force his hand we would be able to switch away the very
next day with no muss and no fuss. Are you willing to provide that
help?

>> The important thing to realize is that libtomcrypt is
> intentionally written in very portable C. ?That is great but it leaves a lot on the table. Optimizations for various platforms to take advantage of enhanced instruction sets such as SSE2 and explicit hardware crypto acceleration instructions such as [...] are not likely to be part of libtomcrypt,
>
> A quick glance at libtomcrypt tells me otherwise. It is portable C, but it still has inline assembler. It has optimizations using SSE2, x86, x86_64, and PPC32. Even though it might not have that new Intel AES instruction yet, this is the same argument people had for using GMP for python's integers.

I'm not worried about speed. In fact, if fast means "vulnerable to
side-channel cryptanalysis" I'm firmly opposed to it, and I don't know
if that's the case here. OpenSSL has at least been subject to
significant attention in that regard.

> If there is a problem with multiple libraries, I'd like to reiterate my support for migrating to NSS.

I'm happy to do this work if you (or someone else) will step forward
and help me identify and fix compatibility concerns. Otherwise, this
is just a waste of time all around.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:02:59 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Sep 2010 23:02:59 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1285023779.99.0.382566319379.issue8743@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

After discussion on IRC, have decided to make the Set ABC more closely match setobject.c:

1) loosen setobject.c binary operations to accept any Set rather than any set/frozenset (see attached patch).

2) tighten Set.__or__, etc to only accept Set rather than any Iterable

3) add Set.update(), Set.difference(), etc so that iterable inputs can be handled without a first casting an iterable input to be a Set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:03:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 23:03:31 +0000
Subject: [issue1887] distutils doesn't support out-of-source builds
In-Reply-To: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za>
Message-ID: <1285023811.8.0.981314821734.issue1887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

#4151 and friends were about building Python, this is about building Python projects with distutils.  As a feature request, I?m reassigning to distutils2.

Monty: Would you like to update your patch?  distutils is frozen except for bug fixes, we work on the next gen in parallel.  See distutils2.notmyidea.org for developer resources and link to our repository.

----------
components: +Distutils2 -Build, Distutils
versions: +Python 2.5, Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1887>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:11:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Sep 2010 23:11:01 +0000
Subject: [issue6305] islice doesn't accept large stop values
In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za>
Message-ID: <1285024261.54.0.668877475743.issue6305@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Unassigning.  If someone is interested creating a patch, I think it is a reasonable request.

----------
assignee: rhettinger -> 
priority: low -> normal
stage:  -> needs patch
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6305>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:11:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 23:11:35 +0000
Subject: [issue1887] distutils doesn't support out-of-source builds
In-Reply-To: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za>
Message-ID: <1285024295.45.0.534170457506.issue1887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let me add that distutils very much wants you to run the setup script from its parent directory, contrary to autotools which can run from another directory, so it could be that other parts than build* commands are affected.

That said, specifying the target build dir is supported; in other words, don?t run ?../setup.py build --src-dir=..? but try ?./setup.py build --build-dir some/where?.

I still have to do a bit of research about make distclean.  Some options like build_ext.inplace are not affected by build-dir, so distclean is not as easy as ?rm -rf $build_dir?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1887>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:14:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 23:14:49 +0000
Subject: [issue9875] Garbage output when running setup.py on Windows
In-Reply-To: <1284646791.69.0.38074502633.issue9875@psf.upfronthosting.co.za>
Message-ID: <1285024489.95.0.124451197176.issue9875@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is indeed invalid.

In distutils2, we?re removing the custom log module in favor of standard logging, and I?ve added a note on my todo list to check that verbosity option passed to setup scripts do impact module-level logging calls.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9875>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:31:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 23:31:35 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1285025495.0.0.188036294852.issue2200@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

distutils bugs follow standard Python rules: They are fixed in stable and development branches, now 2.7, 3.1 and py3k.  If there is a security hazard, the fix would go into 2.6 and possibly 2.5 too.

distutils2 has to work with 2.4-2.7 and (soon) 3.1-3.2, so Tarek told me to set all available versions for those bugs (2.5-py3k), even if I think ?3rd party? is more appropriate and useful (since a distutils2 bug would not for example block a CPython 3.2 release).

When a bug applies to distutils and distutils2, I prefer to set only versions relevant for distutils.  distutils2 has only one branch which is tested with all supported Python version, and I actually consider distutils2 a version of distutils: It makes more sense to me to think ?this bug exists in CPython 3.1, 3.2 and distutils2?.

----------
components: +Distutils2
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:34:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 23:34:19 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1285025659.66.0.111830067542.issue2200@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Could someone provide use cases for this change?  What programs which were not .exe did you need to run though distutils?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:34:23 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Sep 2010 23:34:23 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1285025663.74.0.967144400372.issue8743@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg116998

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:37:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Sep 2010 23:37:01 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1285025821.01.0.487286834363.issue8743@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

After discussion on IRC, have decided to make the Set ABC more closely match setobject.c by loosening setobject.c binary operations to accept any Iterable rather than any just a set/frozenset.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:39:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Sep 2010 23:39:48 +0000
Subject: [issue9583] PYTHONOPTIMIZE = 0 is not honored
In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za>
Message-ID: <1285025988.87.0.705250326201.issue9583@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am following the suggestion in the last sentence of the original post and turning this into a doc issue. I believe it is standard that command-line switches override environmental variables when there is a conflict, but 'Using Python', section 1.2. 'Environment variables' could gain a sentence that says so, or whatever the case is. If I am correct, "These environment variables influence Python?s behavior." could be followed by "They are processed *before* the command-line switches other than -E."

As I read the doc, PYTHONOPTIMIZE = 0, does not seem to mean to the interpreter what you expect it to. "PYTHONOPTIMIZE  If this is set to a non-empty string it is equivalent to specifying the -O option. If set to an integer, it is equivalent to specifying -O multiple times." (which is to say, equivalent to -OO.) But the doc could be misleading. You can check the source if you wish.

In general there are lots of switches to alter defaults and turn things on but none to restore defaults and turn things off. The one exception is "-E  Ignore all PYTHON* environment variables, e.g. PYTHONPATH and PYTHONHOME, that might be set." The obvious intent is to start fresh and only specify what one wants. I do not think one idiosyncratic wrapper is sufficient reason to add one or more other off switches. There are already about 20 options. If you do not want something turned on, do not turn it on.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9583>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:40:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Sep 2010 23:40:38 +0000
Subject: [issue9583] Document startup option/environment interaction
In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za>
Message-ID: <1285026038.73.0.906608553121.issue9583@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
title: PYTHONOPTIMIZE = 0 is not honored -> Document startup option/environment interaction
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9583>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:48:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Sep 2010 23:48:25 +0000
Subject: [issue2213] build_tkinter.py does not handle paths with spaces
In-Reply-To: <1204331742.92.0.0412981555519.issue2213@psf.upfronthosting.co.za>
Message-ID: <1285026505.18.0.335656986518.issue2213@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/issue2213>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:49:13 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 20 Sep 2010 23:49:13 +0000
Subject: [issue9597] mac: Install 2to3 in /usr/local/bin
In-Reply-To: <1281738541.55.0.960534882511.issue9597@psf.upfronthosting.co.za>
Message-ID: <1285026553.0.0.307769145324.issue9597@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Ah, please close this then. I am not sure what I was thinking when reporting this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9597>
_______________________________________

From report at bugs.python.org  Tue Sep 21 01:51:37 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Mon, 20 Sep 2010 23:51:37 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1285026697.37.0.770895579108.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I like the idea of the general "new" flag introducing the reasonable, backwards incompatible behaviour; one doesn't have to remember a list of non-standard flags to get this features.

While I recognise, that the module probably can't work correctly with wide unicode characters on a narrow python build (py 2.7, win XP in this case), i noticed a difference to re in this regard (it might be based on the absence of the wide unicode literal in the latter).

re.findall(u"\\U00010337", u"a\U00010337bc")
[]
re.findall(u"(?i)\\U00010337", u"a\U00010337bc")
[]
regex.findall(u"\\U00010337", u"a\U00010337bc")
[]
regex.findall(u"(?i)\\U00010337", u"a\U00010337bc")
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "C:\Python27\lib\regex.py", line 203, in findall
    return _compile(pattern, flags).findall(string, pos, endpos,
  File "C:\Python27\lib\regex.py", line 310, in _compile
    parsed = parsed.optimise(info)
  File "C:\Python27\lib\_regex_core.py", line 1735, in optimise
    if self.is_case_sensitive(info):
  File "C:\Python27\lib\_regex_core.py", line 1727, in is_case_sensitive
    return char_type(self.value).lower() != char_type(self.value).upper()
ValueError: unichr() arg not in range(0x10000) (narrow Python build)

I.e. re fails to match this pattern (as it actually looks for "U00010337" ), regex doesn't recognise the wide unicode as surrogate pair either, but it also raises an error from narrow unichr. Not sure, whether/how it should be fixed, but the difference based on the i-flag seems unusual.

Of course it would be nice, if surrogate pairs were interpreted, but I can imagine, that it would open a whole can of worms, as this is not thoroughly supported in the builtin unicode either (len, indices, slicing).

I am trying to make wide unicode characters somehow usable in my app, mainly with hacks like extended unichr
("\U"+hex(67)[2:].zfill(8)).decode("unicode-escape") 
or likewise for ord
surrog_ord = (ord(first) - 0xD800) * 0x400 + (ord(second) - 0xDC00) + 0x10000

Actually, using regex, one can work around some of these limitations of len, index or slice using a list form of the string containing surrogates

regex.findall(ur"(?s)(?:\p{inHighSurrogates}\p{inLowSurrogates})|.", u"ab???cd")
[u'a', u'b', u'\U00010337', u'\U00010338', u'\U00010339', u'c', u'd']

but apparently things like wide unicode literals or character sets (even extending of the shorthands like \w etc.) are much more complicated.

regards,
   vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Sep 21 02:04:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 00:04:16 +0000
Subject: [issue9908] os.stat() fails on bytes paths under Windows 7
In-Reply-To: <1285027456.78.0.828515138477.issue9908@psf.upfronthosting.co.za>
Message-ID: <1285027456.78.0.828515138477.issue9908@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Under Windows 7, there is another path in posixmodule.c for stat() (because of the link dereferencing feature, it seems). This path fails for the bytes version. It turns out that GetFinalPathNameByHandleA returns a value which is one byte too small (while GetFinalPathNameByHandleW returns the expected value). The MSDN doc (*) seems to mention it although with a strange wording:

    ?Windows Server 2008 and Windows Vista:  For the ANSI version of this function, GetFinalPathNameByHandleA, the return value includes the size of the terminating null character.?

(*) http://msdn.microsoft.com/en-us/library/aa364962%28VS.85%29.aspx

The net result is that, when we give 'buf_size+1' to the second GetFinalPathNameByHandleA() call after 'buf_size' was returned by the first call, the buffer is still not big enough and it doesn't get filled. The subsequent call to win32_lstat() is done with a bogus path and fails with "[Error 2]: the system cannot find the file specified".

Here is a patch fixing this and also harmonizing win32_stat() and win32_stat_w(). I've added a test, although additional tests for bytes symlinks would probably be deserved. Please review.

PS: the context is:
http://mail.python.org/pipermail/python-dev/2010-September/103860.html

----------
components: Library (Lib), Windows
files: win7statbytes.patch
keywords: patch
messages: 117009
nosy: brian.curtin, db3l, pitrou, tim.golden
priority: high
severity: normal
status: open
title: os.stat() fails on bytes paths under Windows 7
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18940/win7statbytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9908>
_______________________________________

From report at bugs.python.org  Tue Sep 21 02:07:23 2010
From: report at bugs.python.org (Buck Golemon)
Date: Tue, 21 Sep 2010 00:07:23 +0000
Subject: [issue9583] Document startup option/environment interaction
In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za>
Message-ID: <1285027643.61.0.115557453846.issue9583@psf.upfronthosting.co.za>


Buck Golemon <buck.golemon at amd.com> added the comment:

If I understand this code, it means that PYTHONOPTIMIZE set to 1 or 2 works as expected, but set to 0, gives a flag value of 1.

static int
add_flag(int flag, const char *envs)
{
        int env = atoi(envs);
        if (flag < env)
                flag = env;
        if (flag < 1)
                flag = 1;
        return flag;
}


Read literally, the man page indicates that any integer value will give a flag value of 2. 

I agree my shell script is probably unusual, but I believe setting this environment value to zero and expecting the feature to be off (given no contradicting options) is reasonable.

I petition to remove the second if statement above (environment value of "0" yields no flag).

I'd also love to provide a numeric argument to -O, to dynamically set this value more readily, but that is lower importance.

I can implement these and run the unit tests if required.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9583>
_______________________________________

From report at bugs.python.org  Tue Sep 21 02:11:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Sep 2010 00:11:38 +0000
Subject: [issue9597] mac: Install 2to3 in /usr/local/bin
In-Reply-To: <1281738541.55.0.960534882511.issue9597@psf.upfronthosting.co.za>
Message-ID: <1285027898.59.0.35534819451.issue9597@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I haven?t checked that *every* target containing pydoc contained 2to3 too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9597>
_______________________________________

From report at bugs.python.org  Tue Sep 21 02:31:28 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 21 Sep 2010 00:31:28 +0000
Subject: [issue9908] os.stat() fails on bytes paths under Windows 7
In-Reply-To: <1285027456.78.0.828515138477.issue9908@psf.upfronthosting.co.za>
Message-ID: <1285029088.02.0.178599493784.issue9908@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith, jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9908>
_______________________________________

From report at bugs.python.org  Tue Sep 21 02:40:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Sep 2010 00:40:34 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1285029634.18.0.50404782318.issue9877@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Will backport to distutils2 shortly and close again.

----------
assignee: barry -> eric.araujo
status: closed -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Tue Sep 21 03:42:56 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 21 Sep 2010 01:42:56 +0000
Subject: [issue1327971] HTTPResponse instance has no attribute 'fileno'
Message-ID: <1285033376.12.0.489110514361.issue1327971@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fix committed in revision 84932.  A property based fileno was not required, because it is hardly set, it is always often a read-only attribute. Also, py3k behavior is same as the current fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1327971>
_______________________________________

From report at bugs.python.org  Tue Sep 21 03:45:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Sep 2010 01:45:05 +0000
Subject: [issue9583] Document startup option/environment interaction
In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za>
Message-ID: <1285033505.37.0.105345068012.issue9583@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I understood the documentation snippet Terry quoted as saying exactly what you say the code does.  The doc could be clearer by replacing "multiple times" with "that number of times".  Not that more than two has any meaning currently...

Changing the behavior of PYTHONOPTIMIZE as you suggest would be a backward compatibility change that would probably require a deprecation cycle.  (And the message would have to not really be a DeprecationWarning, since DeprecationWarnings are now silent by default but this is a user-triggered event, not a developer-triggered event and so should be user visible.)

Unsetting an environment variable to remove its effect is a fairly common idiom.  So I don't think it is worth the effort of making the change you suggest, even though I agree it would be more intuitive if PYTHONOPTIMIZE=0 meant what you thought it meant.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9583>
_______________________________________

From report at bugs.python.org  Tue Sep 21 03:50:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Sep 2010 01:50:03 +0000
Subject: [issue9583] Document startup option/environment interaction
In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za>
Message-ID: <1285033803.88.0.722082865474.issue9583@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I do not deny that the behavior described in the doc is a bit strange (keying off of type, ignoring value) is a bit bizarre and contrary to reasonable expectation based on other programs. But to alter behavior before 3.2 or later would require a clearly demonstrated discrepancy between doc and behavior, which I do not see. For startup behavior, some discussion on pydev or python-ideas lists would probably be needed.

If the C code you posted is a quote from the Python source, please give the file path, preferably for current trunk version (the py3k branch). The second 'if' looks a bit strange at first glance, but I will not judge without seeing more.

> I believe setting this environment value to zero and expecting the feature to be off (given no contradicting options) is reasonable.

Optimization is off by default. So there is no need to have a environment value that means to keep it off.  Just do not set it. Or unset it if needed.

That said, the code you showed suggests that the option/environment interaction is more complicated than I thought, at least for this pair.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9583>
_______________________________________

From report at bugs.python.org  Tue Sep 21 04:01:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Sep 2010 02:01:47 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1285034507.5.0.0232764635259.issue9360@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK.  It doesn't seem all that likely that we'll be adding parameters, but you never know.  So I'm OK with file becoming keyword only.

As for the overview headers...if they aren't decoded through decode_header already, why are they unicode?  If they haven't been decoded, I'd expect them to be bytes.  Or does the standard really say that these headers, extracted from the bytes message data, will be valid utf-8?  (I realize that as things stand now with email5 you'll in fact *have* to decode them in order to process them with decode_header, but that doesn't change the fact that if they are unicode I would expect that they'd be *fully* decoded.)

But I take your point about the datatypes otherwise.  Also, when we get to email6 all headers should be turned into Header objects, and there will be a way to get a datetime out of a Date Header object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Tue Sep 21 04:06:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Sep 2010 02:06:02 +0000
Subject: [issue9908] os.stat() fails on bytes paths under Windows 7
In-Reply-To: <1285027456.78.0.828515138477.issue9908@psf.upfronthosting.co.za>
Message-ID: <1285034762.34.0.0228481323454.issue9908@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The bug appears to really be limited to Vista?/W7. On WinXP,
>>> os.path.exists('c:/programs/python31')
True
>>> os.path.exists(b'c:/programs/python31')
True
Has the patch been tested on WinXP to be sure it does not introduce a bug for this?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9908>
_______________________________________

From report at bugs.python.org  Tue Sep 21 04:11:15 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 21 Sep 2010 02:11:15 +0000
Subject: [issue1327971] HTTPResponse instance has no attribute 'fileno'
Message-ID: <1285035075.21.0.495850472278.issue1327971@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Documented it in r84933, r84934 and r84935

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1327971>
_______________________________________

From report at bugs.python.org  Tue Sep 21 04:11:37 2010
From: report at bugs.python.org (Buck Golemon)
Date: Tue, 21 Sep 2010 02:11:37 +0000
Subject: [issue9583] Document startup option/environment interaction
In-Reply-To: <1285033505.37.0.105345068012.issue9583@psf.upfronthosting.co.za>
Message-ID: <7691DC9FC60C9E4F88A0BBCA628F55FF043E8DE5F2@sausexmbp02.amd.com>


Buck Golemon <buck.golemon at amd.com> added the comment:

"that number of times" isn't exactly accurate either, since "0" is effectively interpreted as "1".

This change would only adversely affect people who use no -O option, set PYTHONOPTIMIZE to '0', and need optimization.
I feel like that falls into the realm of version differences, but that's your decision.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9583>
_______________________________________

From report at bugs.python.org  Tue Sep 21 04:20:28 2010
From: report at bugs.python.org (Buck Golemon)
Date: Tue, 21 Sep 2010 02:20:28 +0000
Subject: [issue9583] Document startup option/environment interaction
In-Reply-To: <1285033803.88.0.722082865474.issue9583@psf.upfronthosting.co.za>
Message-ID: <7691DC9FC60C9E4F88A0BBCA628F55FF043E8DE602@sausexmbp02.amd.com>


Buck Golemon <buck.golemon at amd.com> added the comment:

The file is here:
   http://svn.python.org/view/python/trunk/Python/pythonrun.c?view=markup

The second if statement is doing exactly what I find troubling: set the flag even if the incoming value is 0.
I guess this is to handle the empty string case, such as:

setenv PYTHONDEBUG
./myscript.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9583>
_______________________________________

From report at bugs.python.org  Tue Sep 21 05:03:24 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 21 Sep 2010 03:03:24 +0000
Subject: [issue1778] SyntaxError.offset sometimes wrong
In-Reply-To: <1199920786.95.0.62807405199.issue1778@psf.upfronthosting.co.za>
Message-ID: <1285038204.96.0.769921530744.issue1778@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

None offsets gone in r84931.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1778>
_______________________________________

From report at bugs.python.org  Tue Sep 21 05:21:45 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 21 Sep 2010 03:21:45 +0000
Subject: [issue9899] tkinter test_font fails on OS X with Aqua Tk
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1285039305.38.0.620336825591.issue9899@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Somebody want to commit it?

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9899>
_______________________________________

From report at bugs.python.org  Tue Sep 21 05:27:43 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Tue, 21 Sep 2010 03:27:43 +0000
Subject: [issue9909] request for calendar.dayofyear() function
In-Reply-To: <1285039663.27.0.59327234025.issue9909@psf.upfronthosting.co.za>
Message-ID: <1285039663.27.0.59327234025.issue9909@psf.upfronthosting.co.za>


New submission from Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com>:

This is a function which computes the integer between 1 and 366 representing the day of the year, given a year, month, and day.

The implementation I have provided computes the difference between the ordinal numbers of the given day and January first of that month.

This will be useful in resolving issue9864, in which parsing of date strings has an unimplemented "day of year" feature.

----------
components: Library (Lib)
files: dayofyear.patch
keywords: patch
messages: 117024
nosy: jfinkels
priority: normal
severity: normal
status: open
title: request for calendar.dayofyear() function
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file18941/dayofyear.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9909>
_______________________________________

From report at bugs.python.org  Tue Sep 21 05:32:06 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 21 Sep 2010 03:32:06 +0000
Subject: [issue9597] mac: Install 2to3 in /usr/local/bin
In-Reply-To: <1281738541.55.0.960534882511.issue9597@psf.upfronthosting.co.za>
Message-ID: <1285039926.67.0.0155157671792.issue9597@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

All of the current installers create 2to3 or versioned 2to3 links only (for Python 3).  The most recent change was for 2.7 in Issue9392. Please reopen if you find one that's missed.

----------
nosy: +ned.deily
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9597>
_______________________________________

From report at bugs.python.org  Tue Sep 21 05:42:03 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Tue, 21 Sep 2010 03:42:03 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285040523.89.0.938112813912.issue9864@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

If the changes I propose in issue9909 are implemented (briefly: a calendar.dayofyear() function), the following patch (with documentation and tests) should fill in the missing fields in the returned tuple.

Note that the email._parseaddr module now depends on the calendar module.

----------
keywords: +patch
nosy: +jfinkels
Added file: http://bugs.python.org/file18942/issue9864.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Tue Sep 21 05:44:07 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Tue, 21 Sep 2010 03:44:07 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285040647.37.0.100335429952.issue9864@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

I was not clear: the patch I provided REQUIRES the function I provided in issue9909. But I don't know how to change the "Dependencies" field in Roundup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Tue Sep 21 05:49:30 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 21 Sep 2010 03:49:30 +0000
Subject: [issue2027] Module containing C implementations of common text
	algorithms
In-Reply-To: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>
Message-ID: <1285040970.03.0.00996907060315.issue2027@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I've started on a module called 'texttools'. So far it has Levenshtein and Porter (both coded in C).

If there's interest I'll put it on PyPI.

Suggestions for other additions?

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2027>
_______________________________________

From report at bugs.python.org  Tue Sep 21 06:39:03 2010
From: report at bugs.python.org (Swapnil Talekar)
Date: Tue, 21 Sep 2010 04:39:03 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1285043943.16.0.816529286647.issue6627@psf.upfronthosting.co.za>


Swapnil Talekar <swapnil.st at gmail.com> added the comment:

Nick, the last statement,
"While this is correct for most purposes, it does mean that..."
can be simplified to, 
"It means...". 
I had to read it several times before I realized, there is no "not" after "does" :) 
BTW, since this particular arrangement of having a temporary thread state during the callback is particularly useful for ctypes (I cannot imagine any other usecase) and also it sort-of breaks things, a potential feature request could be to have consistent thread state during the lifetime of a C thread. I don't have much idea how to do that or whether it is even possible? Would anyone like to give a thought?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Tue Sep 21 08:32:34 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 21 Sep 2010 06:32:34 +0000
Subject: [issue9910] Add Py_SetPath API for embeddint python
In-Reply-To: <1285050754.57.0.81319423251.issue9910@psf.upfronthosting.co.za>
Message-ID: <1285050754.57.0.81319423251.issue9910@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

When calling Py_Initialize() from an embedding application, there is currently no way for the application to override Python's initial settin g of sys.path.  An elaborate mechanism in getpathp.c kicks in, guessing the path based on several criteria.

Ideally, this mechanism, which is valid only for python.exe and its semantics, should be opt in.  It forces embedders that have their own libraries to go through complicated hoops (with environment variables and what not) to direct their embedded interpreter at the right place for modules, and to make sure that it is not confused by any other python distribution present on the system.

This submission adds a Py_SetPath() function to the API.  This has been successfully used by CCP in EVE Online and other products to completely override python's path guessing mechanics.  If called with a semicolon separated path prior to Py_Initialize, it will be used as the fodder for the initial sys.path.

----------
components: Interpreter Core
files: py_setpath.patch
keywords: easy, needs review, patch
messages: 117030
nosy: krisvale
priority: normal
severity: normal
status: open
title: Add Py_SetPath API for embeddint python
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18943/py_setpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9910>
_______________________________________

From report at bugs.python.org  Tue Sep 21 08:33:15 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 21 Sep 2010 06:33:15 +0000
Subject: [issue9862] PIPE_BUF is invalid on AIX
In-Reply-To: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>
Message-ID: <1285050795.08.0.785608538555.issue9862@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Removing select.PIPE_BUF does not seem a good idea to me because this breaks compatibility.  I suggest to simply set it to 512 on AIX.

(An ideal solution would be to really determine the actual buffer size in ./configure; this is probably overkill)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9862>
_______________________________________

From report at bugs.python.org  Tue Sep 21 08:51:22 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Tue, 21 Sep 2010 06:51:22 +0000
Subject: [issue9887] distutil's build_scripts doesn't read utf-8 in all locales
In-Reply-To: <1284729593.16.0.252664137674.issue9887@psf.upfronthosting.co.za>
Message-ID: <1285051882.19.0.593530567688.issue9887@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Why does this matter? PEP 3120 specifies UTF-8 as the default source encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9887>
_______________________________________

From report at bugs.python.org  Tue Sep 21 08:56:42 2010
From: report at bugs.python.org (Lev Shamardin)
Date: Tue, 21 Sep 2010 06:56:42 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1285052202.94.0.0661447696976.issue2200@psf.upfronthosting.co.za>


Lev Shamardin <shamardin at gmail.com> added the comment:

My use case was compiling PyQt4 resources and Qt Designer .ui files from setup script using pyrcc4 and pyuic4 commands. On windows pyrcc4 is actually a pyrcc4.bat file (at least it was at the time of the original bug submission - haven't checked current status), and find_exe could not find it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
_______________________________________

From report at bugs.python.org  Tue Sep 21 09:04:03 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Sep 2010 07:04:03 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1285052643.47.0.823000952315.issue8998@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> If that text is deemed to be advertising by Eric Young and a court of law

The license of a software product cannot affect software that is not even aware of that said product.  (A patent, or a trademark can.)  It governs the use of that product, not of others.  "Features of this library" means really features of *that* library, as specifically implemented in that library.

If a license for one specific software product could affect all other software with such a primitive clause, I don't want to think how Richard Stallman would have worded the GPL :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 10:32:59 2010
From: report at bugs.python.org (lorph)
Date: Tue, 21 Sep 2010 08:32:59 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1285057979.11.0.006992026353.issue8998@psf.upfronthosting.co.za>


lorph <lorph1 at gmail.com> added the comment:

> The license of a software product cannot affect software that is not even aware of that said product.

I never claimed that the clause triggered for all software in existence. We are talking about OpenSSL being bundled with Python where Python is very much aware of OpenSSL. Provided the following 3 circumstances are met, the advertisement clause applies:

1. You are distributing Python with OpenSSL
2. You are "advertising".
3. Your advertising mentions features.

By mentioning features of Python, or even a feature of OpenSSL you don't even use (base64), by the wording of the license you are obligated to also advertise OpenSSL and Eric Young. This obviously has a chilling effect on the distribution and advertising of Python apps. Think about the 100 char blurb on every small web banner.

> In fact, if fast means "vulnerable to side-channel cryptanalysis" I'm firmly opposed to it, and I don't know if that's the case here. OpenSSL has at least been subject to significant attention in that regard.

LTC does address side-channel attacks, but this is a moot point since by using a high level language like Python, you are vulnerable to memory scanning since you cannot normally zero out Python strings (something you may wish to consider in the crypto API).

I'd also add that the "rounds" option should be left in for compatibility reasons. For easy usage, a default such as CBC could be specified. Otherwise, I don't think there is anything wrong with the API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 10:45:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 08:45:25 +0000
Subject: [issue9908] os.stat() fails on bytes paths under Windows 7
In-Reply-To: <1285034762.34.0.0228481323454.issue9908@psf.upfronthosting.co.za>
Message-ID: <1285058720.3202.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Has the patch been tested on WinXP to be sure it does not introduce a
> bug for this?

No. Can you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9908>
_______________________________________

From report at bugs.python.org  Tue Sep 21 10:56:10 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 21 Sep 2010 08:56:10 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1285059370.66.0.34497119277.issue2200@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I believe I had problems with SCons and other .py scripts that are installed as executable .bat files on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
_______________________________________

From report at bugs.python.org  Tue Sep 21 10:56:54 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 21 Sep 2010 08:56:54 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1285059414.95.0.182398201827.issue2200@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Another use case for .bat files is adddin extra params for executable files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
_______________________________________

From report at bugs.python.org  Tue Sep 21 11:00:37 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Sep 2010 09:00:37 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1285057979.11.0.006992026353.issue8998@psf.upfronthosting.co.za>
Message-ID: <4C987432.50308@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I never claimed that the clause triggered for all software in
> existence. We are talking about OpenSSL being bundled with Python
> where Python is very much aware of OpenSSL. Provided the following 3
> circumstances are met, the advertisement clause applies:

Can we please stop getting license interpretations from laymen on
a bug tracker? If somebody is really concerned that the PSF might
violate some license, the PSF lawyer should be asked to evaluate
the situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 11:05:59 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 21 Sep 2010 09:05:59 +0000
Subject: [issue9862] PIPE_BUF is invalid on AIX
In-Reply-To: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>
Message-ID: <1285059959.55.0.19690015242.issue9862@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

OK for me.
Here is a new patch that defines PIPE_BUF to 512 instead of removing select.PIPE_BUF.

----------
Added file: http://bugs.python.org/file18944/patch_broken_pipe_buf_updated.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9862>
_______________________________________

From report at bugs.python.org  Tue Sep 21 11:18:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 09:18:42 +0000
Subject: [issue9910] Add Py_SetPath API for embeddint python
In-Reply-To: <1285050754.57.0.81319423251.issue9910@psf.upfronthosting.co.za>
Message-ID: <1285060722.69.0.999127111367.issue9910@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You must also update Modules/getpath.c.
You should also add documentation.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9910>
_______________________________________

From report at bugs.python.org  Tue Sep 21 11:19:56 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 21 Sep 2010 09:19:56 +0000
Subject: [issue9907] interactive mode TAB does not insert on OS X built with
	editline instead of GNU readline
In-Reply-To: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>
Message-ID: <1285060796.87.0.205657842054.issue9907@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The problem is due to a difference in the behavior of the rl_initialize function between the editline readline emulation and the real GNU libreadline.  Modules/readline.c setup_readline calls several rl functions to create various default bindings, including overriding TAB to "insert" rather than to "trigger completion", then calls rl_initialize allowing the users defaults from .inputrc to override.  It seems the emulated rl_initialize causes all the modified bindings to be discarded, causing TAB to revert to its default "trigger file completion".  The solution in the attached patches is to conditionally call rl_initialize at the beginning of setup_readline, rather than at the end, if the editline emulation is in use.  Patches supplied for py3k and 27 (but not 31 since the feature was never backported there even though it was to 26).  I did not supply any additional tests since I can't think of a straightforward way to simulate the condition in the test framework; suggestions welcome.

----------
keywords: +patch
nosy: +zvezdan
stage:  -> patch review
versions:  -Python 3.1
Added file: http://bugs.python.org/file18945/issue9907-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9907>
_______________________________________

From report at bugs.python.org  Tue Sep 21 11:20:38 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 21 Sep 2010 09:20:38 +0000
Subject: [issue9907] interactive mode TAB does not insert on OS X built with
	editline instead of GNU readline
In-Reply-To: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>
Message-ID: <1285060838.85.0.267712761108.issue9907@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file18946/issue9907-27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9907>
_______________________________________

From report at bugs.python.org  Tue Sep 21 12:32:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Sep 2010 10:32:34 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1285065154.18.0.466332944703.issue2200@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the use cases.  I agree this is a bug, not a feature, so unless Tarek disagrees I will commit the last patch.

I'm not sure this requires tests.

----------
assignee: tarek -> eric.araujo
resolution:  -> accepted
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
_______________________________________

From report at bugs.python.org  Tue Sep 21 12:33:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 21 Sep 2010 10:33:35 +0000
Subject: [issue9887] distutil's build_scripts doesn't read utf-8 in all locales
In-Reply-To: <1284729593.16.0.252664137674.issue9887@psf.upfronthosting.co.za>
Message-ID: <1285065215.74.0.362316327894.issue9887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay.  Then this bug is part of #9561.

----------
components: +Distutils2
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> distutils: set encoding to utf-8 for input and output files
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9887>
_______________________________________

From report at bugs.python.org  Tue Sep 21 13:04:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 21 Sep 2010 11:04:56 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1284906329.3205.0.camel@localhost.localdomain>
Message-ID: <4C989153.2010200@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> pyOpenSSL is stable, in production use and
>> has a decent API. The ssl module is good enough for HTTPS client
>> use. pyOpenSSL provides a robust server side implementation with
>> all the required certificate and context handling needed for this.
>>
>> We could tell people to use the ssl module for clients and
>> pyOpenSSL for the server side and perhaps integrate the OpenSSL
>> package into the ssl namespace.
> 
> In this case, this should be decided early, so that I know if I should
> continue caring about the ssl module or not. I'm not interested in
> maintaining potentially obsolete code.

I'll ask Jean-Paul and AB Strakt if they are up to contributing
the pyOpenSSL code to the Python stdlib based on a contributor
agreement. This would enable us to relicense the code undert
the PSF license even if the original code's license is not
changed.

Once that's a done deal, we can then consider moving in the above
direction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 13:08:24 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Tue, 21 Sep 2010 11:08:24 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1285067304.3.0.777732113698.issue9561@psf.upfronthosting.co.za>


Changes by Hagen F?rstenau <hfuerstenau at gmx.net>:


----------
nosy: +hagen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Tue Sep 21 13:41:35 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 21 Sep 2010 11:41:35 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1285069295.64.0.118863478716.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I use Python 3, where len("\U00010337") == 2 on a narrow build.

Yes, wide Unicode on a narrow build is a problem:

>>> regex.findall("\\U00010337", "a\U00010337bc")
[]
>>> regex.findall("(?i)\\U00010337", "a\U00010337bc")
[]

I'm not sure how (or whether!) to handle surrogate pairs. It _would_ make things more complicated.

I suppose the moral is that if you want to use wide Unicode then you really should use a wide build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Sep 21 13:45:20 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 21 Sep 2010 11:45:20 +0000
Subject: [issue9119] Python download page needs to mention crypto code
	in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1285069520.48.0.698827094119.issue9119@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Added OpenSSL license to Python 2.7, 3.1 and 3.2 in r84938, r84939, r84940 resp.

Now we'll only need to add a mention of the fact that we ship OpenSSL in the Windows installers on the download page.

Terry, would you like to move this forward with the Python.org webmasters ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9119>
_______________________________________

From report at bugs.python.org  Tue Sep 21 15:03:23 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 21 Sep 2010 13:03:23 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1285043943.16.0.816529286647.issue6627@psf.upfronthosting.co.za>
Message-ID: <AANLkTinUvBcUhxZmy8L_HCWhogM3b3jDG87Fcp4NWWwW@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Tue, Sep 21, 2010 at 2:39 PM, Swapnil Talekar <report at bugs.python.org> wrote:
> Swapnil Talekar <swapnil.st at gmail.com> added the comment:
> Nick, the last statement,
> "While this is correct for most purposes, it does mean that..."
> can be simplified to,
> "It means...".
> I had to read it several times before I realized, there is no "not" after "does" :)

The shorter version doesn't mean the same thing though - the ctypes
arrangement *really is* correct for most purposes. The only issue is
that threading.local won't persist, since the storage is blown away as
soon as the callback returns.

> BTW, since this particular arrangement of having a temporary thread state during the callback is particularly useful for ctypes (I cannot imagine any other usecase) and also it sort-of breaks things, a potential feature request could be to have consistent thread state during the lifetime of a C thread. I don't have much idea how to do that or whether it is even possible? Would anyone like to give a thought?

There's no easy way to make the thread state persist between calls, as
ctypes needs to destroy the thread state it creates at some point to
avoid a memory leak. Since it has no way of knowing when the
underlying C thread is no longer in use, it is forced to assume that
every call is going to be the last one from that thread and kill the
thread state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Tue Sep 21 15:53:44 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 21 Sep 2010 13:53:44 +0000
Subject: [issue678264] test_resource fails when file size is limited
Message-ID: <1285077224.45.0.474885128708.issue678264@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

For info:
this test fails on AIX 6.1 with py3k with the following error:

test test_resource failed -- Traceback (most recent call last):
  File "/san_cis/home/cis/buildbot/buildbot-aix6/py3k-aix6-xlc/build/Lib/test/test_resource.py", line 28, in test_fsize_ismax
    self.assertEqual(resource.RLIM_INFINITY, max)
AssertionError: 2147483647 != 1073741312

The same test works on AIX 5.3.

Is it related or should I open a new issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678264>
_______________________________________

From report at bugs.python.org  Tue Sep 21 16:17:38 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Tue, 21 Sep 2010 14:17:38 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1285078658.52.0.589148145368.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Well, of course, the surrogates probably shouldn't be handled separately in one module independently of the rest of the standard library. (I actually don't know such narrow implementation (although it is mentioned in those unicode quidelines 
http://unicode.org/reports/tr18/#Supplementary_Characters )

The main surprise on my part was due to the compile error rather than empty match as was the case with re; 
but now I see, that it is a consequence of the newly introduced wide unicode notation, the matching behaviour changed consistently.

(for my part, the workarounds I found, seem to be sufficient in the cases I work with wide unicode; most likely I am not going to compile wide unicode build on windows myself in the near future :-)
 vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Sep 21 16:21:21 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 21 Sep 2010 14:21:21 +0000
Subject: [issue678264] test_resource fails when file size is limited
Message-ID: <1285078881.93.0.734398205605.issue678264@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I suppose the difference comes from the fact that I have:
on AIX 5.3: 
$ ulimit -f
unlimited

on AIX 6.1:
$ ulimit -f 
1048575

I think the test should be updated to not require "ulimit -f" is unlimited.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678264>
_______________________________________

From report at bugs.python.org  Tue Sep 21 16:43:01 2010
From: report at bugs.python.org (DSM)
Date: Tue, 21 Sep 2010 14:43:01 +0000
Subject: [issue9911] doc copyedits
In-Reply-To: <1285080181.79.0.899000794299.issue9911@psf.upfronthosting.co.za>
Message-ID: <1285080181.79.0.899000794299.issue9911@psf.upfronthosting.co.za>


New submission from DSM <dsm001 at users.sourceforge.net>:

Various typo fixes for the docs.  As usual, I left historical documents alone (except for 3.1 whatsnew: fixed the spelling of Jack Diederich's name).  Fixing ~30 means I probably introduced ~3 problems of my own, but that should still be a net win..

Patch against py3k r84944.

----------
assignee: docs at python
components: Documentation
files: typos.patch
keywords: patch
messages: 117052
nosy: docs at python, dsm001
priority: normal
severity: normal
status: open
title: doc copyedits
versions: Python 3.3
Added file: http://bugs.python.org/file18947/typos.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9911>
_______________________________________

From report at bugs.python.org  Tue Sep 21 16:43:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 14:43:58 +0000
Subject: [issue9906] including elementary mathematical functions in default
	types
In-Reply-To: <1285013101.44.0.231152316832.issue9906@psf.upfronthosting.co.za>
Message-ID: <1285080238.77.0.318349411745.issue9906@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

IIRC, trigonometric functions, such as sin or cos, are not considered "elementary" in the real domain.

The problem with this proposal is where to stop.  Right now the line is drawn somewhere at __abs__ and __pow__.  If you add __sin__ and __cos__, you would probably want to include __tan__ and the inverses to all three of sin, cos and tan.  What about hyperbolic functions: sinh, cosh, tanh, etc?  These are actually "elementary" in the usual sense.

-1 and the proper forum for such suggestions in python-ideas rather then the bug tracker.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9906>
_______________________________________

From report at bugs.python.org  Tue Sep 21 16:47:37 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 21 Sep 2010 14:47:37 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285080457.37.0.19793751033.issue678250@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I would like to reopen this issue as it is still occurring in py3k on AIX 5.3 and 6.1:

Re-running test test_mmap in verbose mode
test_access_parameter (test.test_mmap.MmapTests) ... ERROR
test_anonymous (test.test_mmap.MmapTests) ... ok
test_bad_file_desc (test.test_mmap.MmapTests) ... ok
test_basic (test.test_mmap.MmapTests) ... ok
test_context_manager (test.test_mmap.MmapTests) ... ok
test_context_manager_exception (test.test_mmap.MmapTests) ... ok
test_double_close (test.test_mmap.MmapTests) ... ok
test_entire_file (test.test_mmap.MmapTests) ... ok
test_error (test.test_mmap.MmapTests) ... ok
test_extended_getslice (test.test_mmap.MmapTests) ... ok
test_extended_set_del_slice (test.test_mmap.MmapTests) ... ok
test_find_end (test.test_mmap.MmapTests) ... ok
test_io_methods (test.test_mmap.MmapTests) ... ok
test_move (test.test_mmap.MmapTests) ... ok
test_offset (test.test_mmap.MmapTests) ... ok
test_prot_readonly (test.test_mmap.MmapTests) ... ok
test_rfind (test.test_mmap.MmapTests) ... ok
test_subclass (test.test_mmap.MmapTests) ... ok
test_tougher_find (test.test_mmap.MmapTests) ... ok

======================================================================
ERROR: test_access_parameter (test.test_mmap.MmapTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_u02/home/recette/buildbot/buildbot-aix5/py3k-aix5-xlc/build/Lib/test/test_mmap.py", line 219, in test_access_parameter
    m.flush()
mmap.error: [Errno 22] Invalid argument

----------------------------------------------------------------------
Ran 19 tests in 0.216s

FAILED (errors=1)


Should flush be modified to do nothing in this case or should the unit test be updated?
thanks

----------
type: crash -> behavior
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Tue Sep 21 16:48:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Sep 2010 14:48:43 +0000
Subject: [issue9911] doc copyedits
In-Reply-To: <1285080181.79.0.899000794299.issue9911@psf.upfronthosting.co.za>
Message-ID: <1285080523.45.0.567791249932.issue9911@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks! Committed as r84945.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9911>
_______________________________________

From report at bugs.python.org  Tue Sep 21 16:53:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Sep 2010 14:53:03 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285080783.4.0.995802194462.issue678250@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: out of date -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Tue Sep 21 16:55:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 14:55:26 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285080926.1.0.168185376838.issue9864@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I've added #9909 as a dependency, but IMO it is less likely to be accepted than this feature request.

On this issue, I would much rather see email package to start using datetime objects to represent time rather than named or unnamed tuples.

----------
dependencies: +request for calendar.dayofyear() function
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Tue Sep 21 16:58:42 2010
From: report at bugs.python.org (Michael Gilbert)
Date: Tue, 21 Sep 2010 14:58:42 +0000
Subject: [issue9906] including elementary mathematical functions in default
	types
In-Reply-To: <1285013101.44.0.231152316832.issue9906@psf.upfronthosting.co.za>
Message-ID: <1285081122.91.0.872660046605.issue9906@psf.upfronthosting.co.za>


Michael Gilbert <michael.s.gilbert at gmail.com> added the comment:

the  elementary functions are well-defined set, and i would include all of them.  that includes exp, sqrt, ln, trig, and hyperbolic functions.

i'll start a thread on python-ideas.  thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9906>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:02:10 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 21 Sep 2010 15:02:10 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1285081330.46.0.270186771239.issue5505@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I guess this is not duplicate.
On HEAD of py3k, #9658 seems to be fixed,
but the issue reported here can be reproduced
even now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:03:25 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 21 Sep 2010 15:03:25 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1285081405.21.0.830755362672.issue5505@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
Removed message: http://bugs.python.org/msg117058

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:04:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 15:04:43 +0000
Subject: [issue9621] Graphviz output for 2to3 fixer patterns
In-Reply-To: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za>
Message-ID: <1285081483.96.0.042066353887.issue9621@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Matt,

Can you post a sample graph in a common image format, say PNG?  I am curious to see it, but not curious enough to install graphviz.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9621>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:05:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 15:05:03 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285081503.22.0.166413256442.issue9864@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> On this issue, I would much rather see email package to start using
> datetime objects to represent time rather than named or unnamed tuples.

I agree on the principle, but I don't know if it's acceptable with regards to compatibility. It's up to David and Barry to decide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:07:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 15:07:27 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1285081647.97.0.124020390377.issue9860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Does this apply to 2.7 too?

I think it does, but it would be hard to sell any improvements in this area as a bug fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:11:07 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 21 Sep 2010 15:11:07 +0000
Subject: [issue1633863] AIX: configure ignores $CC
Message-ID: <1285081867.22.0.562317573067.issue1633863@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I am currently in the process of correcting the building of Python on AIX and stabilizing the tests in order to add my buildbot as a slave of the official buildbot master, cf post on python-dev
http://mail.python.org/pipermail/python-dev/2010-September/103774.html

Could someone please commit this (IMO straightforward) patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633863>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:16:32 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 21 Sep 2010 15:16:32 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285082192.69.0.285522194923.issue9864@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

It does make sense, and email6 is like Python 3 in the sense that backward compatibility is not a priority.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:17:12 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 21 Sep 2010 15:17:12 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285082232.2.0.948015342098.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you for the test.

Well, I noticed py3k_openssl.patch can suppress rebuild
of OpenSSL nicely, but from IDE, _ssl and _hashlib
are always rebuilt. It doesn't take so much time though.

With py3k_openssl_v2.patch, we can supress OpenSSL and
python project rebuild nicely, but we cannot rebuild
_ssl and _hashlib from IDE after OpenSSL sources are
modified. We need to call "python_d build_ssl.py ..."
manually.

I cannot find the best way for this issue. :-(

----------
Added file: http://bugs.python.org/file18948/py3k_openssl_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:19:16 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 21 Sep 2010 15:19:16 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285082356.22.0.635128975979.issue9552@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file18948/py3k_openssl_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:21:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 15:21:31 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1285082232.2.0.948015342098.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285082484.3666.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, I noticed py3k_openssl.patch can suppress rebuild
> of OpenSSL nicely, but from IDE, _ssl and _hashlib
> are always rebuilt. It doesn't take so much time though.
> 
> With py3k_openssl_v2.patch, we can supress OpenSSL and
> python project rebuild nicely, but we cannot rebuild
> _ssl and _hashlib from IDE after OpenSSL sources are
> modified. We need to call "python_d build_ssl.py ..."
> manually.

I think it's better to rebuild everytime than have to invoke a console
command manually.
Also, as you say, building _ssl and hashlib is fast. The problem with
rebuilding OpenSSL is that it's very slow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:21:51 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 21 Sep 2010 15:21:51 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285082511.13.0.895490989236.issue9552@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file18949/py3k_openssl_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:23:28 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 21 Sep 2010 15:23:28 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285082608.99.0.0328309975878.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I want to commit py3k_openssl.patch for now, because
it is much better than before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:24:36 2010
From: report at bugs.python.org (Floris Bruynooghe)
Date: Tue, 21 Sep 2010 15:24:36 +0000
Subject: [issue9912] Fail when vsvarsall.bat produces stderr
In-Reply-To: <1285082676.18.0.058541871992.issue9912@psf.upfronthosting.co.za>
Message-ID: <1285082676.18.0.058541871992.issue9912@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

It would have saved me a lot of time if msvc9compiler would fail if executing the vsvarsall.bat file produced any output.  The attached patch does this and fails when I try to compile from within a cygwin environment.  I've also tested this from the normal windows command prompt and there buiding does succeed with this patch applied.

----------
assignee: tarek
components: Distutils
files: msvc9.diff
keywords: patch
messages: 117067
nosy: eric.araujo, flub, tarek
priority: normal
severity: normal
status: open
title: Fail when vsvarsall.bat produces stderr
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18950/msvc9.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9912>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:24:39 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 21 Sep 2010 15:24:39 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285082679.13.0.255220730656.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Oops, I missed your post. Thank you, I'll commit like that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:27:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 15:27:58 +0000
Subject: [issue9866] Inconsistencies in tracing list comprehensions
In-Reply-To: <1284585781.8.0.0490639400631.issue9866@psf.upfronthosting.co.za>
Message-ID: <1285082878.34.0.486344600121.issue9866@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have found the root cause of these differences.  The trace function is not called when the opcode is successfully predicted.  When computed gotos are enabled, opcode prediction is disabled as explained in the following comment in ceval.c:

    Opcode prediction is disabled with threaded code, since the latter allows                                                                                                                         
    the CPU to record separate branch prediction information for each                                                                                                                                 
    opcode.

Note that this issue is similar to #884022 which was resolved by disabling opcode prediction in dynamic profile builds.

Given that opcode prediction if off by default, I don't see much of the reason to try to improve tracing of predicted opcodes.

----------
assignee:  -> belopolsky
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9866>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:28:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Sep 2010 15:28:06 +0000
Subject: [issue678250] test_mmap failling on AIX
In-Reply-To: <1285080457.37.0.19793751033.issue678250@psf.upfronthosting.co.za>
Message-ID: <4C98CF03.5000606@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Should flush be modified to do nothing in this case or should the unit test be updated?

Tim is suggesting that flush should indeed become a noop. Since nobody
else speaking in favor of it being an error, I guess this is the way to
go: flush, on an ACCESS_COPY file, does nothing, and the test is fine
as it stands.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:28:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 15:28:10 +0000
Subject: [issue1633863] AIX: configure ignores $CC
Message-ID: <1285082890.62.0.309994826436.issue1633863@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, committed in r84946 (3.2), r84947 (3.1) and r84948 (2.7). Thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633863>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:41:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 15:41:00 +0000
Subject: [issue2643] mmap_object_dealloc calls time-consuming msync(),
	although close doesn't
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1285083660.8.0.846828951615.issue2643@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's a pity that flush() is defined like this. Ideally, if mmap claims to mimick ordinary file objects, flush() should be a no-op() and there should be a separate sync() method.

On the other hand, your (Charles-Fran?ois's) patch is already much better than the statu quo.
If nobody objects, I think it should be committed to 3.2. Whether or not we should be backport it to the stable branches is a bit more delicate, since it /could/ break badly written applications...

On a sidenote, the mmap object has received a *lot* less attention during the years than the other IO primitives (especially file objects in 3.x). It should probably only be used for specialized cases.

----------
components: +IO, Library (Lib)
stage: patch review -> commit review
title: mmap_object_dealloc does not call FlushViewOfFile on windows -> mmap_object_dealloc calls time-consuming msync(), although close doesn't
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:43:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 15:43:19 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285083799.46.0.0195220470789.issue678250@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Interestingly, the matter was discussed on another issue, #2643. I also agree that ideally flush() should become a no-op (only in 3.2, since it would break compatibility). But then we should also expose a separate sync() method with the current behaviour.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:44:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 15:44:02 +0000
Subject: [issue2643] mmap_object_dealloc calls time-consuming msync(),
	although close doesn't
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1285083842.95.0.361521546556.issue2643@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I notice that there's support in #678250 for making flush() a no-op.
We should still fix tp_dealloc anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:53:27 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Sep 2010 15:53:27 +0000
Subject: [issue678250] test_mmap failling on AIX
In-Reply-To: <1285083799.46.0.0195220470789.issue678250@psf.upfronthosting.co.za>
Message-ID: <4C98D4F5.30008@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Interestingly, the matter was discussed on another issue, #2643. I
> also agree that ideally flush() should become a no-op (only in 3.2,
> since it would break compatibility). But then we should also expose a
> separate sync() method with the current behaviour.

I think you misunderstand. I'm not proposing that flush should become
a noop entirely - only for ACCESS_COPY mappings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:57:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 15:57:48 +0000
Subject: [issue9913] Misc/SpecialBuilds.txt  is out of date
In-Reply-To: <1285084668.56.0.665403194927.issue9913@psf.upfronthosting.co.za>
Message-ID: <1285084668.56.0.665403194927.issue9913@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

It looks like Misc/SpecialBuilds.txt has not been updated since 2.4.

This file is referenced from C-API documentation [1], but is not accessible as a hyperlink.

Some of the recommendations in this file are out of date, in particular those that recommend setting make variables where a configure switch is available.

I believe it would be best to retire Misc/SpecialBuilds.txt and move still relevant sections to proper .rst files.


[1] http://docs.python.org/dev/py3k/c-api/intro.html#debugging-builds

----------
assignee: docs at python
components: Documentation
messages: 117076
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Misc/SpecialBuilds.txt  is out of date
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9913>
_______________________________________

From report at bugs.python.org  Tue Sep 21 18:00:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Sep 2010 16:00:32 +0000
Subject: [issue2643] mmap_object_dealloc calls time-consuming msync(),
	although close doesn't
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1285084832.22.0.257925333509.issue2643@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think Antoine misinterpreted my message. I do think that flush should continue to msync, except in cases where there really is no underlying file to sync to. It may (or may not) be unfortunate that the method is called flush, but nothing is gained by renaming it.

I agree that calling msync on close/dealloc is not really necessary. The Windows version doesn't sync, either.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
_______________________________________

From report at bugs.python.org  Tue Sep 21 18:07:48 2010
From: report at bugs.python.org (geremy condra)
Date: Tue, 21 Sep 2010 16:07:48 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <4C989153.2010200@egenix.com>
Message-ID: <AANLkTimE_wxP+tjFSki3-u3gbsR2yT6F2iVoARbKpK6g@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Tue, Sep 21, 2010 at 4:04 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> Antoine Pitrou wrote:
>>
>> Antoine Pitrou <pitrou at free.fr> added the comment:
>>
>>> pyOpenSSL is stable, in production use and
>>> has a decent API. The ssl module is good enough for HTTPS client
>>> use. pyOpenSSL provides a robust server side implementation with
>>> all the required certificate and context handling needed for this.
>>>
>>> We could tell people to use the ssl module for clients and
>>> pyOpenSSL for the server side and perhaps integrate the OpenSSL
>>> package into the ssl namespace.
>>
>> In this case, this should be decided early, so that I know if I should
>> continue caring about the ssl module or not. I'm not interested in
>> maintaining potentially obsolete code.
>
> I'll ask Jean-Paul and AB Strakt if they are up to contributing
> the pyOpenSSL code to the Python stdlib based on a contributor
> agreement. This would enable us to relicense the code undert
> the PSF license even if the original code's license is not
> changed.
>
> Once that's a done deal, we can then consider moving in the above
> direction.

I'm not sure I understand the relevance of pyopenssl here- it's pretty
clearly focused on SSL/TLS rather than on crypto. Maybe someone can
clarify?

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 18:08:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 16:08:55 +0000
Subject: [issue2643] mmap_object_dealloc calls time-consuming msync(),
	although close doesn't
In-Reply-To: <1285084832.22.0.257925333509.issue2643@psf.upfronthosting.co.za>
Message-ID: <1285085331.3666.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I agree that calling msync on close/dealloc is not really necessary.
> The Windows version doesn't sync, either.

Ok, thank you. I committed the patch in r84950.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
_______________________________________

From report at bugs.python.org  Tue Sep 21 18:09:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 16:09:20 +0000
Subject: [issue2643] mmap_object_dealloc calls time-consuming msync(),
	although close doesn't
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1285085360.24.0.969267830572.issue2643@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
_______________________________________

From report at bugs.python.org  Tue Sep 21 18:26:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 16:26:38 +0000
Subject: [issue9899] tkinter test_font fails on OS X with Aqua Tk
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1285086398.6.0.72555688562.issue9899@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r84952. Thanks!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9899>
_______________________________________

From report at bugs.python.org  Tue Sep 21 18:36:48 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 21 Sep 2010 16:36:48 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285087008.6.0.205924226581.issue678250@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Would that patch be OK? It solves the test_mmap on AIX.

----------
keywords: +patch
Added file: http://bugs.python.org/file18951/patch_flush_mmap.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Tue Sep 21 18:49:32 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 21 Sep 2010 16:49:32 +0000
Subject: [issue9912] Fail when vsvarsall.bat produces stderr
In-Reply-To: <1285082676.18.0.058541871992.issue9912@psf.upfronthosting.co.za>
Message-ID: <1285087772.65.0.131163890186.issue9912@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A non-empty stderr does not mean that a command failed.
For example, the Microsoft compiler "cl.exe" prints the version string to stderr.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9912>
_______________________________________

From report at bugs.python.org  Tue Sep 21 19:12:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Sep 2010 17:12:25 +0000
Subject: [issue9908] os.stat() fails on bytes paths under Windows 7
In-Reply-To: <1285027456.78.0.828515138477.issue9908@psf.upfronthosting.co.za>
Message-ID: <1285089145.44.0.0924049215275.issue9908@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Only if given a revised 32bit binary (and revised test_os.py). I expect someone else who can will see this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9908>
_______________________________________

From report at bugs.python.org  Tue Sep 21 19:16:40 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Sep 2010 17:16:40 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285089400.8.0.359826591912.issue678250@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Looks fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Tue Sep 21 19:20:24 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Sep 2010 17:20:24 +0000
Subject: [issue9119] Python download page needs to mention crypto code
	in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1285089624.89.0.546250291776.issue9119@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I sent an email.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9119>
_______________________________________

From report at bugs.python.org  Tue Sep 21 19:33:43 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 21 Sep 2010 17:33:43 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTimE_wxP+tjFSki3-u3gbsR2yT6F2iVoARbKpK6g@mail.gmail.com>
Message-ID: <4C98EC73.4050207@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

geremy condra wrote:
> 
> geremy condra <debatem1 at gmail.com> added the comment:
> 
> On Tue, Sep 21, 2010 at 4:04 AM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
>>
>> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>>
>> Antoine Pitrou wrote:
>>>
>>> Antoine Pitrou <pitrou at free.fr> added the comment:
>>>
>>>> pyOpenSSL is stable, in production use and
>>>> has a decent API. The ssl module is good enough for HTTPS client
>>>> use. pyOpenSSL provides a robust server side implementation with
>>>> all the required certificate and context handling needed for this.
>>>>
>>>> We could tell people to use the ssl module for clients and
>>>> pyOpenSSL for the server side and perhaps integrate the OpenSSL
>>>> package into the ssl namespace.
>>>
>>> In this case, this should be decided early, so that I know if I should
>>> continue caring about the ssl module or not. I'm not interested in
>>> maintaining potentially obsolete code.
>>
>> I'll ask Jean-Paul and AB Strakt if they are up to contributing
>> the pyOpenSSL code to the Python stdlib based on a contributor
>> agreement. This would enable us to relicense the code under
>> the PSF license even if the original code's license is not
>> changed.
>>
>> Once that's a done deal, we can then consider moving in the above
>> direction.
> 
> I'm not sure I understand the relevance of pyopenssl here- it's pretty
> clearly focused on SSL/TLS rather than on crypto. Maybe someone can
> clarify?

Yes, but it provides a decent platform for adding other crypto APIs
as well and then we could have these as C APIs rather than wrappers
using ctypes.

There's already a patch available from Keyphrene adding all those bits:
http://www.keyphrene.com/products/pyOpenSSL-extended/index.php?lng=en

The patch would need to be updated for the new pyOpenSSL version,
but that's certainly within range. And we'd need to get their permission
to relicense as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 19:56:51 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 21 Sep 2010 17:56:51 +0000
Subject: [issue1962] ctypes feature request: Automatic type conversion of
	input arguments to C functions
In-Reply-To: <1201597182.13.0.442457985171.issue1962@psf.upfronthosting.co.za>
Message-ID: <1285091811.49.0.420301391412.issue1962@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't think this should happen by default.
but what the user wants is already possible, by using the from_param() method.  For example, the AutoStrParam type converts everything to a string (and a char*):

from ctypes import *

class AutoStrParam(c_char_p):
    @classmethod
    def from_param(cls, value):
        return str(value)

strlen = cdll.LoadLibrary('msvcrt').strlen
strlen.argtypes = [AutoStrParam]

print strlen(None)     # "None"          ->  4
print strlen(type)     # "<type 'type'>" -> 13

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1962>
_______________________________________

From report at bugs.python.org  Tue Sep 21 19:59:37 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 21 Sep 2010 17:59:37 +0000
Subject: [issue9908] os.stat() fails on bytes paths under Windows 7
In-Reply-To: <1285027456.78.0.828515138477.issue9908@psf.upfronthosting.co.za>
Message-ID: <1285091977.44.0.0184170722225.issue9908@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The patch looks ok to me. I tested it on Server 2003 (same as XP) and it worked fine in addition to Windows 7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9908>
_______________________________________

From report at bugs.python.org  Tue Sep 21 20:01:08 2010
From: report at bugs.python.org (geremy condra)
Date: Tue, 21 Sep 2010 18:01:08 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <4C98EC73.4050207@egenix.com>
Message-ID: <AANLkTikgWSm6iN6NoLk01J_jiFeOsV=EFh_yvcyOkLO+@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Tue, Sep 21, 2010 at 10:33 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> geremy condra wrote:
>>
>> geremy condra <debatem1 at gmail.com> added the comment:
>>
>> On Tue, Sep 21, 2010 at 4:04 AM, Marc-Andre Lemburg
>> <report at bugs.python.org> wrote:
>>>
>>> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>>>
>>> Antoine Pitrou wrote:
>>>>
>>>> Antoine Pitrou <pitrou at free.fr> added the comment:
>>>>
>>>>> pyOpenSSL is stable, in production use and
>>>>> has a decent API. The ssl module is good enough for HTTPS client
>>>>> use. pyOpenSSL provides a robust server side implementation with
>>>>> all the required certificate and context handling needed for this.
>>>>>
>>>>> We could tell people to use the ssl module for clients and
>>>>> pyOpenSSL for the server side and perhaps integrate the OpenSSL
>>>>> package into the ssl namespace.
>>>>
>>>> In this case, this should be decided early, so that I know if I should
>>>> continue caring about the ssl module or not. I'm not interested in
>>>> maintaining potentially obsolete code.
>>>
>>> I'll ask Jean-Paul and AB Strakt if they are up to contributing
>>> the pyOpenSSL code to the Python stdlib based on a contributor
>>> agreement. This would enable us to relicense the code under
>>> the PSF license even if the original code's license is not
>>> changed.
>>>
>>> Once that's a done deal, we can then consider moving in the above
>>> direction.
>>
>> I'm not sure I understand the relevance of pyopenssl here- it's pretty
>> clearly focused on SSL/TLS rather than on crypto. Maybe someone can
>> clarify?
>
> Yes, but it provides a decent platform for adding other crypto APIs
> as well and then we could have these as C APIs rather than wrappers
> using ctypes.

The intention all along has been that we use the C API, and in fact
I'm pretty far along on writing that. Assuming there won't be an issue
with porting pyopenssl to python3, this seems like a pretty good idea
to me though.

> There's already a patch available from Keyphrene adding all those bits:
> http://www.keyphrene.com/products/pyOpenSSL-extended/index.php?lng=en
>
> The patch would need to be updated for the new pyOpenSSL version,
> but that's certainly within range. And we'd need to get their permission
> to relicense as well.

Bits and pieces of this look useful but it also looks like I'd be
rewriting a lot of it to move away from the RSA_* routines, etc. I
suspect it would take more time to get it into line than to just
cherrypick out of it.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 20:17:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 18:17:45 +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: <1285093065.41.0.819526070425.issue9914@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The main() method of trace and profile modules attempt to emulate the environment in which traced code runs when invoked directly, but it fails in several respects.   The specific problem which is the subject of this issue is that while __name__ is set to '__main__' in code globals, sys.modules['__main__'] still point to the trace/profile module.

Among other problems, this conflicts, with a popular idiom used in regression test scripts:

   support.run_unittest(__name__)

For example,

$ python -m trace -c -C trace.d Lib/test/test_optparse.py 

----------------------------------------------------------------------
Ran 0 tests in 0.001s

OK

No tests are ran because run_unittests() looks for test case classes in the trace module and finds none.


This is related to #9323, so I am merging in the nosy list.  See also r83393.

----------
assignee: belopolsky
components: Library (Lib)
messages: 117090
nosy: belopolsky, eli.bendersky, ezio.melotti, flox, georg.brandl
priority: normal
severity: normal
status: open
title: trace/profile conflict with the use of sys.modules[__name__]
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9914>
_______________________________________

From report at bugs.python.org  Tue Sep 21 20:19:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 18:19:41 +0000
Subject: [issue9908] os.stat() fails on bytes paths under Windows 7
In-Reply-To: <1285027456.78.0.828515138477.issue9908@psf.upfronthosting.co.za>
Message-ID: <1285093181.86.0.266140981553.issue9908@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I committed the patch in r84956. Thank you for testing.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9908>
_______________________________________

From report at bugs.python.org  Tue Sep 21 20:29:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 21 Sep 2010 18:29:47 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTikgWSm6iN6NoLk01J_jiFeOsV=EFh_yvcyOkLO+@mail.gmail.com>
Message-ID: <4C98F998.7060208@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

geremy condra wrote:
> 
>>>> I'll ask Jean-Paul and AB Strakt if they are up to contributing
>>>> the pyOpenSSL code to the Python stdlib based on a contributor
>>>> agreement. This would enable us to relicense the code under
>>>> the PSF license even if the original code's license is not
>>>> changed.
>>>>
>>>> Once that's a done deal, we can then consider moving in the above
>>>> direction.
>>>
>>> I'm not sure I understand the relevance of pyopenssl here- it's pretty
>>> clearly focused on SSL/TLS rather than on crypto. Maybe someone can
>>> clarify?
>>
>> Yes, but it provides a decent platform for adding other crypto APIs
>> as well and then we could have these as C APIs rather than wrappers
>> using ctypes.
> 
> The intention all along has been that we use the C API, and in fact
> I'm pretty far along on writing that. Assuming there won't be an issue
> with porting pyopenssl to python3, this seems like a pretty good idea
> to me though.

Ah, sorry, I must have missed that turn in the discussion :-)

The pyOpenSSL port to Python3 is closing in on completion. Jean-Paul
is planning for an alpha release next month.

>> There's already a patch available from Keyphrene adding all those bits:
>> http://www.keyphrene.com/products/pyOpenSSL-extended/index.php?lng=en
>>
>> The patch would need to be updated for the new pyOpenSSL version,
>> but that's certainly within range. And we'd need to get their permission
>> to relicense as well.
> 
> Bits and pieces of this look useful but it also looks like I'd be
> rewriting a lot of it to move away from the RSA_* routines, etc. I
> suspect it would take more time to get it into line than to just
> cherrypick out of it.

If you are writing new code for this anyway, it may be better to
avoid the license question of the Keyphrene patch and just use
their code as reference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 20:30:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 18:30:44 +0000
Subject: [issue766910] fix one or two bugs in trace.py
Message-ID: <1285093844.29.0.908685252232.issue766910@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file8481/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________

From report at bugs.python.org  Tue Sep 21 20:35:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 18:35:10 +0000
Subject: [issue766910] fix one or two bugs in trace.py
Message-ID: <1285094110.54.0.758748416047.issue766910@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________

From report at bugs.python.org  Tue Sep 21 20:35:20 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 21 Sep 2010 18:35:20 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285094120.01.0.762737113239.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I committed py3k_openssl.patch in r84957(py3k).
I won't merge into release27-maint nor release31-maint
because they are built against openssl-0.9.x and
don't have *.asm copy code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Tue Sep 21 20:37:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 18:37:17 +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: <1285094237.31.0.0787218131238.issue9325@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +ncoghlan, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Tue Sep 21 20:54:04 2010
From: report at bugs.python.org (geremy condra)
Date: Tue, 21 Sep 2010 18:54:04 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <4C98F998.7060208@egenix.com>
Message-ID: <AANLkTimLT6XBAQ_mtLw-anGEt0pk7gVAk1a60Z2YM8eY@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Tue, Sep 21, 2010 at 11:29 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> geremy condra wrote:
>>
>>>>> I'll ask Jean-Paul and AB Strakt if they are up to contributing
>>>>> the pyOpenSSL code to the Python stdlib based on a contributor
>>>>> agreement. This would enable us to relicense the code under
>>>>> the PSF license even if the original code's license is not
>>>>> changed.
>>>>>
>>>>> Once that's a done deal, we can then consider moving in the above
>>>>> direction.
>>>>
>>>> I'm not sure I understand the relevance of pyopenssl here- it's pretty
>>>> clearly focused on SSL/TLS rather than on crypto. Maybe someone can
>>>> clarify?
>>>
>>> Yes, but it provides a decent platform for adding other crypto APIs
>>> as well and then we could have these as C APIs rather than wrappers
>>> using ctypes.
>>
>> The intention all along has been that we use the C API, and in fact
>> I'm pretty far along on writing that. Assuming there won't be an issue
>> with porting pyopenssl to python3, this seems like a pretty good idea
>> to me though.
>
> Ah, sorry, I must have missed that turn in the discussion :-)
>
> The pyOpenSSL port to Python3 is closing in on completion. Jean-Paul
> is planning for an alpha release next month.

Do you know if he's looking for help with that? There's been some talk of
a porting sprint here and I'd be happy to put that at the top of the list.

>>> There's already a patch available from Keyphrene adding all those bits:
>>> http://www.keyphrene.com/products/pyOpenSSL-extended/index.php?lng=en
>>>
>>> The patch would need to be updated for the new pyOpenSSL version,
>>> but that's certainly within range. And we'd need to get their permission
>>> to relicense as well.
>>
>> Bits and pieces of this look useful but it also looks like I'd be
>> rewriting a lot of it to move away from the RSA_* routines, etc. I
>> suspect it would take more time to get it into line than to just
>> cherrypick out of it.
>
> If you are writing new code for this anyway, it may be better to
> avoid the license question of the Keyphrene patch and just use
> their code as reference.

Yeah, I think that makes the most sense.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 21:14:59 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 21 Sep 2010 19:14:59 +0000
Subject: [issue9906] including elementary mathematical functions in default
	types
In-Reply-To: <1285013101.44.0.231152316832.issue9906@psf.upfronthosting.co.za>
Message-ID: <1285096499.96.0.974806978753.issue9906@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9906>
_______________________________________

From report at bugs.python.org  Tue Sep 21 21:15:53 2010
From: report at bugs.python.org (Matt Bond)
Date: Tue, 21 Sep 2010 19:15:53 +0000
Subject: [issue9621] Graphviz output for 2to3 fixer patterns
In-Reply-To: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za>
Message-ID: <1285096553.29.0.00232362450683.issue9621@psf.upfronthosting.co.za>


Matt Bond <gmattbond at gmail.com> added the comment:

?ric,

When I was working with 2to3 this summer I was running it via python3, so I think the patch should work - however, if I've submitted it to the wrong place or the wrong branch, where should I be looking at to ensure my code does work on 3.2 and is submitted to the right place?

In regard to the import gvgraph, I wasn't sure what to do with it - for my distribution gvgraph wasn't available as a package, and it was only one file so I just dumped it in the same directory as the script. I'm open to suggestions as to how that import should be handled better.

Alexander - I'll attach a sample image as soon as I get back to my development machine, which should be later this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9621>
_______________________________________

From report at bugs.python.org  Tue Sep 21 21:16:36 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 21 Sep 2010 19:16:36 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1285096596.38.0.772717319132.issue9860@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

FYIW, the OS X installer build script (Mac/BuildScript/build-installer.py for years has, and continues to, depend on building outside of the source directory.  When I build one, I always start with a clean source directory.  There are so many opportunities for the configure and make stages to go wrong that it seems not worth the effort to try to plug all of the holes of the type you have identified here when attempting to build with a "dirty" source directory.  I wouldn't trust using one.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Tue Sep 21 21:22:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 19:22:33 +0000
Subject: [issue9899] tkinter test_font fails on OS X with Aqua Tk
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1285096953.86.0.89257880385.issue9899@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9899>
_______________________________________

From report at bugs.python.org  Tue Sep 21 22:03:32 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 21 Sep 2010 20:03:32 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

(I've made an educated guess about who to add to the Nosy list)

The attached patch substantially speeds up sorting using the "key" parameter.  It is purely a performance patch; the language and libraries are not changed in any other way from the users point of view.  I measured a reduction in execution time of at least 15% in many cases and more than 40% for large n.

I performed measurements on an Intel 64-bit Linux system using gcc 4.3.2 and on an Intel 32-bit Windows XP system using Visual C Express Edition 2009.

Previously, "key" was implemented by a creating a sortwrapperobject, which is a PyObject storing a key and a value and using only the key for comparison.  

With the patch, sortwrapperobject is removed entirely.  Instead, the sort uses two arrays: one for keys and one for values.  Comparisons use the keys array.  Whenever a swap is performed, the swap is performed on both arrays.  If the "keys" parameter is not provided to the sort, the second swap is skipped (since the keys are also the values).

Compared to the sortwrapperobject approach, speed is improved by:
- Requiring only 1 memory allocation for an array of PyObject *'s, instead of n memory allocations for n sortwrapperobjects
- Removes the need to dereference through sortwrapperobjects, which were scattered about in memory (i.e., had poor cache locality)
- Substantially smaller memory overhead, further improving cache performance
 
When the "key" parameter is not used, the code still needs to check to see if it should be performing a second swap.  However, the additional instructions are cache and branch-prediction friendly and do not have a noticeable impact on performance.  I conducted enough experiments to establish a 95% confidence interval that excluded a slowdown of more than 1% (but did not exclude a slowdown of 0% - which is good).

A handful of results:

# No key, same speed
otto:~$ py3k-git-base/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 'f()'
1000000 loops, best of 3: 0.276 usec per loop
otto:~$ py3k-git/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 'f()' 
1000000 loops, best of 3: 0.276 usec per loop

# With a key, patched version is faster
otto:~$ py3k-git-base/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 'f(key=int)'
1000000 loops, best of 3: 1.76 usec per loop
otto:~$ py3k-git/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 'f(key=int)'
1000000 loops, best of 3: 1.5 usec per loop

# Results are more dramatic with large n
otto:~$ py3k-git-base/python -m timeit -s 'x = list(range(100000))' -s 'f = x.sort' 'f(key=int)'
10 loops, best of 3: 35.2 msec per loop
otto:~$ py3k-git/python -m timeit -s 'x = list(range(100000))' -s 'f = x.sort' 'f(key=int)'
10 loops, best of 3: 22.4 msec per loop

I have been using a script for running a large battery of experiments with different values of n and different conditions (random data, sorted data, reverse-sorted data, key, no key, etc.).  The script works, but it's clunky to use.  I'm working on cleaning that up and hope to attach it to this issue within the next few days.

----------
assignee: stutzbach
components: Library (Lib)
files: sort-key-locality.diff
keywords: patch
messages: 117097
nosy: collinwinter, rhettinger, stutzbach, tim_one
priority: normal
severity: normal
stage: patch review
status: open
title: speeding up sorting with a key
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18952/sort-key-locality.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Sep 21 22:37:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 20:37:54 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285101474.44.0.2385107985.issue9915@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks rather nice. I don't think there's any point in micro-optimizations such as stack_keys.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Sep 21 22:43:56 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 21 Sep 2010 20:43:56 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285101836.54.0.610638995071.issue9915@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Conceptually, this is a reasonable approach.  

I originally put in the sortwrapper as a straight-forward technique of tackling the 2.x API which allowed a key-function, or a cmp-function, or both, or neither.   IOW, the original motivation is now gone.  The only remaining advantage of the sortwrapper is that it is independent of the main code for the timsort, so both are more readable and maintainable in their current form.

I've only had a cursory look at the patch.  A couple of thoughts:

* The memmove, memcpy functions are tricky to time because of varying performance across various architectures and libraries.  Code like "*dest++ = *pb++;" is hard to beat, especially for short runs.

* Is the code slower for the common case where a key function is not provided?  The patch seems to add a level of indirection throughout the code (lots of "lo.values" instead of just "lo").

* A more extensive timing suite would be helpful; the ones listed in the first post are simplistic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Sep 21 23:09:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 21 Sep 2010 21:09:09 +0000
Subject: [issue9131] test_set_reprs in test_pprint is fragile
In-Reply-To: <1277927280.23.0.76585633164.issue9131@psf.upfronthosting.co.za>
Message-ID: <1285103349.84.0.262406855534.issue9131@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Committed in r84961

----------
stage: patch review -> committed/rejected
status: open -> closed
type:  -> behavior
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9131>
_______________________________________

From report at bugs.python.org  Tue Sep 21 23:17:24 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 21 Sep 2010 21:17:24 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTimLT6XBAQ_mtLw-anGEt0pk7gVAk1a60Z2YM8eY@mail.gmail.com>
Message-ID: <4C9920E1.6050709@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

geremy condra wrote:
> 
>>> The intention all along has been that we use the C API, and in fact
>>> I'm pretty far along on writing that. Assuming there won't be an issue
>>> with porting pyopenssl to python3, this seems like a pretty good idea
>>> to me though.
>>
>> Ah, sorry, I must have missed that turn in the discussion :-)
>>
>> The pyOpenSSL port to Python3 is closing in on completion. Jean-Paul
>> is planning for an alpha release next month.
> 
> Do you know if he's looking for help with that? There's been some talk of
> a porting sprint here and I'd be happy to put that at the top of the list.

I don't know. You might want to contact him directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Sep 21 23:26:21 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 21 Sep 2010 21:26:21 +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: <1285104381.54.0.821834880277.issue9325@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I've thought about this in the past, but never really pursued it due to the question of what to do with the __main__ namespace.

There are three options here:
1. Use runpy.run_module to run the module in a fresh __main__ namespace
2. Use runpy.run_module to run the module under its own name
3. Use runpy._run_module_as_main to run the module in the real __main__ namespace

Option 3 is probably a bad idea (due to the risk of clobbering globals from pdb/trace/profile/doctest/etc) but failing to do it that way creates a difference between the way the actual -m switch works and what these modules will be doing.

That said, I haven't looked closely at what these modules do for ordinary scripts, where much the same problem will already arise. If option 1 is adequate for this purpose, then it shouldn't be that hard to add - it's just that I've never done the investigation to see if it *would* be adequate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Tue Sep 21 23:31:13 2010
From: report at bugs.python.org (John J Lee)
Date: Tue, 21 Sep 2010 21:31:13 +0000
Subject: [issue1660009] continuing problem with httplib multiple set-cookie
	headers
Message-ID: <1285104673.96.0.0149300993437.issue1660009@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

What I said in 2007 re commas could be well out of date (might well have been so even then, in fact).  Somebody should check what browsers do now...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1660009>
_______________________________________

From report at bugs.python.org  Tue Sep 21 23:40:36 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 21 Sep 2010 21:40:36 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285105236.97.0.0965020674125.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Antoine said:
> I don't think there's any point in micro-optimizations such as
> stack_keys.

Good point.  I'll try taking that out and see how it impacts the timing.

Raymond said:
> The memmove, memcpy functions are tricky to time because of varying
> performance across various architectures and libraries.  Code like
> "*dest++ = *pb++;" is hard to beat, especially for short runs.

Anything that was a memmove or memcpy remains a memmove or memcpy.  Anything that was equivalent but implemented "by hand" remains that way. (Although in either case the details have been moved into a sortslice_* static inline function.) 

I have avoided changing any memcpy/memmove to "by hand" (or vise versa), because I know that it might be faster on my system but slower on someone else's.

> Is the code slower for the common case where a key function is not
> provided?  

The short answer is "no".  The long answer is that I conducted enough experiments for the 95% confidence interval of the ratio of execution times (patched/trunk) to be 0.994735131656 +/- 0.00540792612332, for the case where no key function is provided.

> The patch seems to add a level of indirection throughout the code
> (lots of "lo.values" instead of just "lo").

The compiler can exactly compute the stack offset of "lo.values", so it should require the same number and type of instructions to access as just "lo".

> A more extensive timing suite would be helpful; the ones listed in 
> the first post are simplistic.

I have one, but it's clunky and requires modifying the script to change important parameters.  I'm refactoring it to use argparse and will attach it to this issue when it's ready.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Sep 21 23:44:12 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 21 Sep 2010 21:44:12 +0000
Subject: [issue9916] errno module is missing some symbols
In-Reply-To: <1285105452.83.0.807715545592.issue9916@psf.upfronthosting.co.za>
Message-ID: <1285105452.83.0.807715545592.issue9916@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

According to this message, Python's errno module is missing some symbols:

https://lists.ubuntu.com/archives/ubuntu-devel/2010-August/031341.html

ENOMEDIUM       123     /* No medium found */
EMEDIUMTYPE     124     /* Wrong medium type */
ECANCELED       125     /* Operation Canceled */
ENOKEY          126     /* Required key not available */
EKEYEXPIRED     127     /* Key has expired */
EKEYREVOKED     128     /* Key has been revoked */
EKEYREJECTED    129     /* Key was rejected by service */
EOWNERDEAD      130     /* Owner died */
ENOTRECOVERABLE 131     /* State not recoverable */
ERFKILL         132     /* Operation not possible due to RF-kill */

While we're at it, it might be nice to add -m functionality to print out the errno, though I'm not even sure this is possible with an extension module.

----------
assignee: barry
components: Extension Modules
messages: 117105
nosy: barry
priority: normal
severity: normal
status: open
title: errno module is missing some symbols
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9916>
_______________________________________

From report at bugs.python.org  Tue Sep 21 23:57:53 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 21 Sep 2010 21:57:53 +0000
Subject: [issue678250] test_mmap failling on AIX
In-Reply-To: <4C98CF03.5000606@v.loewis.de>
Message-ID: <125156.27292.qm@web29605.mail.ird.yahoo.com>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger

________________________________
From: Martin v. L??wis <report at bugs.python.org>
To: breamoreboy at yahoo.co.uk
Sent: Tue, 21 September, 2010 16:28:06
Subject: [issue678250] test_mmap failling on AIX

Martin v. L??wis <martin at v.loewis.de> added the comment:

> Should flush be modified to do nothing in this case or should the unit test be 
>updated?

Tim is suggesting that flush should indeed become a noop. Since nobody
else speaking in favor of it being an error, I guess this is the way to
go: flush, on an ACCESS_COPY file, does nothing, and the test is fine
as it stands.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

----------
Added file: http://bugs.python.org/file18953/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________
-------------- next part --------------
<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Please ensure tha I'm taken off of the email list as I've been banned from contributing to Python by Raymond Hettinger<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Martin v. L??wis &lt;report at bugs.python.org&gt;<br><b><span style="font-weight: bold;">To:</span></b> breamoreboy at yahoo.co.uk<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, 21 September, 2010 16:28:06<br><b><span style="font-weight: bold;">Subject:</span></b> [issue678250] test_mmap failling on AIX<br></font><br><br>Martin v. L??wis &lt;<a ymailto="mailto:martin at v.loewis.de"
 href="mailto:martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br><br>&gt; Should flush be modified to do nothing in this case or should the unit test be updated?<br><br>Tim is suggesting that flush should indeed become a noop. Since nobody<br>else speaking in favor of it being an error, I guess this is the way to<br>go: flush, on an ACCESS_COPY file, does nothing, and the test is fine<br>as it stands.<br><br>----------<br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org" href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue678250" target="_blank">http://bugs.python.org/issue678250</a>&gt;<br>_______________________________________<br></div></div>
</div><br>



      </body></html>

From report at bugs.python.org  Tue Sep 21 23:58:04 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 21 Sep 2010 21:58:04 +0000
Subject: [issue678250] test_mmap failling on AIX
In-Reply-To: <1285083799.46.0.0195220470789.issue678250@psf.upfronthosting.co.za>
Message-ID: <381770.17164.qm@web29610.mail.ird.yahoo.com>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger

________________________________
From: Antoine Pitrou <report at bugs.python.org>
To: breamoreboy at yahoo.co.uk
Sent: Tue, 21 September, 2010 16:43:19
Subject: [issue678250] test_mmap failling on AIX

Antoine Pitrou <pitrou at free.fr> added the comment:

Interestingly, the matter was discussed on another issue, #2643. I also agree 
that ideally flush() should become a no-op (only in 3.2, since it would break 
compatibility). But then we should also expose a separate sync() method with the 
current behaviour.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

----------
Added file: http://bugs.python.org/file18954/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________
-------------- next part --------------
<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Please ensure tha I'm taken off of the email list as I've been banned from contributing to Python by Raymond Hettinger<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Antoine Pitrou &lt;report at bugs.python.org&gt;<br><b><span style="font-weight: bold;">To:</span></b> breamoreboy at yahoo.co.uk<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, 21 September, 2010 16:43:19<br><b><span style="font-weight: bold;">Subject:</span></b> [issue678250] test_mmap failling on AIX<br></font><br><br>Antoine Pitrou &lt;<a ymailto="mailto:pitrou at free.fr"
 href="mailto:pitrou at free.fr">pitrou at free.fr</a>&gt; added the comment:<br><br>Interestingly, the matter was discussed on another issue, #2643. I also agree that ideally flush() should become a no-op (only in 3.2, since it would break compatibility). But then we should also expose a separate sync() method with the current behaviour.<br><br>----------<br>nosy: +pitrou<br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org" href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue678250" target="_blank">http://bugs.python.org/issue678250</a>&gt;<br>_______________________________________<br></div></div>
</div><br>



      </body></html>

From report at bugs.python.org  Tue Sep 21 23:58:14 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 21 Sep 2010 21:58:14 +0000
Subject: [issue678250] test_mmap failling on AIX
In-Reply-To: <4C98D4F5.30008@v.loewis.de>
Message-ID: <930713.34585.qm@web29609.mail.ird.yahoo.com>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger

________________________________
From: Martin v. L??wis <report at bugs.python.org>
To: breamoreboy at yahoo.co.uk
Sent: Tue, 21 September, 2010 16:53:27
Subject: [issue678250] test_mmap failling on AIX

Martin v. L??wis <martin at v.loewis.de> added the comment:

> Interestingly, the matter was discussed on another issue, #2643. I
> also agree that ideally flush() should become a no-op (only in 3.2,
> since it would break compatibility). But then we should also expose a
> separate sync() method with the current behaviour.

I think you misunderstand. I'm not proposing that flush should become
a noop entirely - only for ACCESS_COPY mappings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

----------
Added file: http://bugs.python.org/file18955/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________
-------------- next part --------------
<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Please ensure tha I'm taken off of the email list as I've been banned from contributing to Python by Raymond Hettinger<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Martin v. L??wis &lt;report at bugs.python.org&gt;<br><b><span style="font-weight: bold;">To:</span></b> breamoreboy at yahoo.co.uk<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, 21 September, 2010 16:53:27<br><b><span style="font-weight: bold;">Subject:</span></b> [issue678250] test_mmap failling on AIX<br></font><br><br>Martin v. L??wis &lt;<a ymailto="mailto:martin at v.loewis.de"
 href="mailto:martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br><br>&gt; Interestingly, the matter was discussed on another issue, #2643. I<br>&gt; also agree that ideally flush() should become a no-op (only in 3.2,<br>&gt; since it would break compatibility). But then we should also expose a<br>&gt; separate sync() method with the current behaviour.<br><br>I think you misunderstand. I'm not proposing that flush should become<br>a noop entirely - only for ACCESS_COPY mappings.<br><br>----------<br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org" href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue678250" target="_blank">http://bugs.python.org/issue678250</a>&gt;<br>_______________________________________<br></div></div>
</div><br>



      </body></html>

From report at bugs.python.org  Tue Sep 21 23:58:25 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 21 Sep 2010 21:58:25 +0000
Subject: [issue678250] test_mmap failling on AIX
In-Reply-To: <1285087008.6.0.205924226581.issue678250@psf.upfronthosting.co.za>
Message-ID: <281025.41006.qm@web29609.mail.ird.yahoo.com>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger

________________________________
From: S??bastien Sabl?? <report at bugs.python.org>
To: breamoreboy at yahoo.co.uk
Sent: Tue, 21 September, 2010 17:36:48
Subject: [issue678250] test_mmap failling on AIX

S??bastien Sabl?? <sable at users.sourceforge.net> added the comment:

Would that patch be OK? It solves the test_mmap on AIX.

----------
keywords: +patch
Added file: http://bugs.python.org/file18951/patch_flush_mmap.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

----------
Added file: http://bugs.python.org/file18956/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________
-------------- next part --------------
<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Please ensure tha I'm taken off of the email list as I've been banned from contributing to Python by Raymond Hettinger<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> S??bastien Sabl?? &lt;report at bugs.python.org&gt;<br><b><span style="font-weight: bold;">To:</span></b> breamoreboy at yahoo.co.uk<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, 21 September, 2010 17:36:48<br><b><span style="font-weight: bold;">Subject:</span></b> [issue678250] test_mmap failling on AIX<br></font><br><br>S??bastien Sabl?? &lt;<a ymailto="mailto:sable at users.sourceforge.net"
 href="mailto:sable at users.sourceforge.net">sable at users.sourceforge.net</a>&gt; added the comment:<br><br>Would that patch be OK? It solves the test_mmap on AIX.<br><br>----------<br>keywords: +patch<br>Added file: <a href="http://bugs.python.org/file18951/patch_flush_mmap.diff" target="_blank">http://bugs.python.org/file18951/patch_flush_mmap.diff</a><br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org" href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue678250" target="_blank">http://bugs.python.org/issue678250</a>&gt;<br>_______________________________________<br></div></div>
</div><br>


      </body></html>

From report at bugs.python.org  Tue Sep 21 23:58:38 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 21 Sep 2010 21:58:38 +0000
Subject: [issue678250] test_mmap failling on AIX
In-Reply-To: <1285089400.8.0.359826591912.issue678250@psf.upfronthosting.co.za>
Message-ID: <427722.51396.qm@web29611.mail.ird.yahoo.com>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger

________________________________
From: Martin v. L??wis <report at bugs.python.org>
To: breamoreboy at yahoo.co.uk
Sent: Tue, 21 September, 2010 18:16:40
Subject: [issue678250] test_mmap failling on AIX

Martin v. L??wis <martin at v.loewis.de> added the comment:

Looks fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

----------
Added file: http://bugs.python.org/file18957/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________
-------------- next part --------------
<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Please ensure tha I'm taken off of the email list as I've been banned from contributing to Python by Raymond Hettinger<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Martin v. L??wis &lt;report at bugs.python.org&gt;<br><b><span style="font-weight: bold;">To:</span></b> breamoreboy at yahoo.co.uk<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, 21 September, 2010 18:16:40<br><b><span style="font-weight: bold;">Subject:</span></b> [issue678250] test_mmap failling on AIX<br></font><br><br>Martin v. L??wis &lt;<a ymailto="mailto:martin at v.loewis.de"
 href="mailto:martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br><br>Looks fine to me.<br><br>----------<br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org" href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue678250" target="_blank">http://bugs.python.org/issue678250</a>&gt;<br>_______________________________________<br></div></div>
</div><br>



      </body></html>

From report at bugs.python.org  Tue Sep 21 23:58:52 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 21 Sep 2010 21:58:52 +0000
Subject: [issue1962] ctypes feature request: Automatic type conversion of
	input arguments to C functions
In-Reply-To: <1285091811.49.0.420301391412.issue1962@psf.upfronthosting.co.za>
Message-ID: <168859.49941.qm@web29614.mail.ird.yahoo.com>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger

________________________________
From: Amaury Forgeot d'Arc <report at bugs.python.org>
To: breamoreboy at yahoo.co.uk
Sent: Tue, 21 September, 2010 18:56:51
Subject: [issue1962] ctypes feature request: Automatic type conversion of input 
arguments to C functions

Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't think this should happen by default.
but what the user wants is already possible, by using the from_param() method.  
For example, the AutoStrParam type converts everything to a string (and a 
char*):

from ctypes import *

class AutoStrParam(c_char_p):
    @classmethod
    def from_param(cls, value):
        return str(value)

strlen = cdll.LoadLibrary('msvcrt').strlen
strlen.argtypes = [AutoStrParam]

print strlen(None)     # "None"          ->  4
print strlen(type)     # "<type 'type'>" -> 13

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1962>
_______________________________________

----------
Added file: http://bugs.python.org/file18958/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1962>
_______________________________________
-------------- next part --------------
<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Please ensure tha I'm taken off of the email list as I've been banned from contributing to Python by Raymond Hettinger<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Amaury Forgeot d'Arc &lt;report at bugs.python.org&gt;<br><b><span style="font-weight: bold;">To:</span></b> breamoreboy at yahoo.co.uk<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, 21 September, 2010 18:56:51<br><b><span style="font-weight: bold;">Subject:</span></b> [issue1962] ctypes feature request: Automatic type conversion of input arguments to C functions<br></font><br><br>Amaury Forgeot d'Arc &lt;<a
 ymailto="mailto:amauryfa at gmail.com" href="mailto:amauryfa at gmail.com">amauryfa at gmail.com</a>&gt; added the comment:<br><br>I don't think this should happen by default.<br>but what the user wants is already possible, by using the from_param() method.&nbsp; For example, the AutoStrParam type converts everything to a string (and a char*):<br><br>from ctypes import *<br><br>class AutoStrParam(c_char_p):<br>&nbsp; &nbsp; @classmethod<br>&nbsp; &nbsp; def from_param(cls, value):<br>&nbsp; &nbsp; &nbsp; &nbsp; return str(value)<br><br>strlen = cdll.LoadLibrary('msvcrt').strlen<br>strlen.argtypes = [AutoStrParam]<br><br>print strlen(None)&nbsp; &nbsp;  # "None"&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -&gt;&nbsp; 4<br>print strlen(type)&nbsp; &nbsp;  # "&lt;type 'type'&gt;" -&gt; 13<br><br>----------<br>nosy: +amaury.forgeotdarc<br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org"
 href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue1962" target="_blank">http://bugs.python.org/issue1962</a>&gt;<br>_______________________________________<br></div></div>
</div><br>



      </body></html>

From report at bugs.python.org  Tue Sep 21 23:58:59 2010
From: report at bugs.python.org (Floris Bruynooghe)
Date: Tue, 21 Sep 2010 21:58:59 +0000
Subject: [issue9912] Fail when vsvarsall.bat produces stderr
In-Reply-To: <1285082676.18.0.058541871992.issue9912@psf.upfronthosting.co.za>
Message-ID: <1285106339.72.0.0616302848479.issue9912@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

I'm aware of that but my limited testing showed that in this case that doesn't happen.

However if this is considered too brittle to just plain fail as soon as there's stderr, how about using distutils' log facility to log the stderr at a reasonable level (warning?)?  That way at least you'll be able to see something useful when you get a failure at a strange looking and far less meaningful traceback a few lines lower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9912>
_______________________________________

From report at bugs.python.org  Tue Sep 21 23:59:02 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 21 Sep 2010 21:59:02 +0000
Subject: [issue766910] fix one or two bugs in trace.py
In-Reply-To: <1285093844.36.0.232271906136.issue766910@psf.upfronthosting.co.za>
Message-ID: <979993.19244.qm@web29613.mail.ird.yahoo.com>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger

________________________________
From: Alexander Belopolsky <report at bugs.python.org>
To: breamoreboy at yahoo.co.uk
Sent: Tue, 21 September, 2010 19:30:44
Subject: [issue766910] fix one or two bugs in trace.py

Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Removed file: http://bugs.python.org/file8481/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________

----------
Added file: http://bugs.python.org/file18959/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________
-------------- next part --------------
<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Please ensure tha I'm taken off of the email list as I've been banned from contributing to Python by Raymond Hettinger<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Alexander Belopolsky &lt;report at bugs.python.org&gt;<br><b><span style="font-weight: bold;">To:</span></b> breamoreboy at yahoo.co.uk<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, 21 September, 2010 19:30:44<br><b><span style="font-weight: bold;">Subject:</span></b> [issue766910] fix one or two bugs in trace.py<br></font><br><br>Changes by Alexander Belopolsky &lt;<a
 ymailto="mailto:belopolsky at users.sourceforge.net" href="mailto:belopolsky at users.sourceforge.net">belopolsky at users.sourceforge.net</a>&gt;:<br><br><br>Removed file: <a href="http://bugs.python.org/file8481/unnamed" target="_blank">http://bugs.python.org/file8481/unnamed</a><br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org" href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue766910" target="_blank">http://bugs.python.org/issue766910</a>&gt;<br>_______________________________________<br></div></div>
</div><br>



      </body></html>

From report at bugs.python.org  Tue Sep 21 23:59:18 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 21 Sep 2010 21:59:18 +0000
Subject: [issue766910] fix one or two bugs in trace.py
In-Reply-To: <1285094110.63.0.663579870504.issue766910@psf.upfronthosting.co.za>
Message-ID: <951168.19263.qm@web29613.mail.ird.yahoo.com>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Please ensure tha I'm taken off of the email list as I've been banned from 
contributing to Python by Raymond Hettinger

________________________________
From: Alexander Belopolsky <report at bugs.python.org>
To: breamoreboy at yahoo.co.uk
Sent: Tue, 21 September, 2010 19:35:10
Subject: [issue766910] fix one or two bugs in trace.py

Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:

----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________

----------
Added file: http://bugs.python.org/file18960/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________
-------------- next part --------------
<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Please ensure tha I'm taken off of the email list as I've been banned from contributing to Python by Raymond Hettinger<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Alexander Belopolsky &lt;report at bugs.python.org&gt;<br><b><span style="font-weight: bold;">To:</span></b> breamoreboy at yahoo.co.uk<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, 21 September, 2010 19:35:10<br><b><span style="font-weight: bold;">Subject:</span></b> [issue766910] fix one or two bugs in trace.py<br></font><br><br>Changes by Alexander Belopolsky &lt;<a
 ymailto="mailto:belopolsky at users.sourceforge.net" href="mailto:belopolsky at users.sourceforge.net">belopolsky at users.sourceforge.net</a>&gt;:<br><br><br>----------<br>assignee:&nbsp; -&gt; belopolsky<br>nosy: +belopolsky<br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org" href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue766910" target="_blank">http://bugs.python.org/issue766910</a>&gt;<br>_______________________________________<br></div></div>
</div><br>



      </body></html>

From report at bugs.python.org  Wed Sep 22 00:01:45 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 21 Sep 2010 22:01:45 +0000
Subject: [issue9912] Fail when vsvarsall.bat produces stderr
In-Reply-To: <1285082676.18.0.058541871992.issue9912@psf.upfronthosting.co.za>
Message-ID: <1285106505.38.0.266568897002.issue9912@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

yes, displaying the stderr content is a good idea.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9912>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:16:51 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 21 Sep 2010 22:16:51 +0000
Subject: [issue1962] ctypes feature request: Automatic type conversion of
	input arguments to C functions
In-Reply-To: <1201597182.13.0.442457985171.issue1962@psf.upfronthosting.co.za>
Message-ID: <1285107411.32.0.25703035851.issue1962@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file18958/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1962>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:16:58 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 21 Sep 2010 22:16:58 +0000
Subject: [issue1962] ctypes feature request: Automatic type conversion of
	input arguments to C functions
In-Reply-To: <1201597182.13.0.442457985171.issue1962@psf.upfronthosting.co.za>
Message-ID: <1285107418.81.0.801720569137.issue1962@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1962>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:18:18 2010
From: report at bugs.python.org (Floris Bruynooghe)
Date: Tue, 21 Sep 2010 22:18:18 +0000
Subject: [issue9912] Fail when vsvarsall.bat produces stderr
In-Reply-To: <1285082676.18.0.058541871992.issue9912@psf.upfronthosting.co.za>
Message-ID: <1285107498.85.0.726430207979.issue9912@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

msvc9_log.diff does log stderr at warning level when it occurs.

----------
Added file: http://bugs.python.org/file18961/msvc9_log.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9912>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:20:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Sep 2010 22:20:55 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285107655.44.0.384964873562.issue678250@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
Removed message: http://bugs.python.org/msg117109

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:21:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Sep 2010 22:21:06 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285107666.0.0.783244819389.issue678250@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
Removed message: http://bugs.python.org/msg117108

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:21:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Sep 2010 22:21:13 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285107673.36.0.100568069652.issue678250@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
Removed message: http://bugs.python.org/msg117107

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:21:23 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Sep 2010 22:21:23 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285107683.27.0.129649714916.issue678250@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
Removed message: http://bugs.python.org/msg117106

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:21:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 21 Sep 2010 22:21:28 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285107688.95.0.561775554662.issue678250@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
Removed message: http://bugs.python.org/msg117110

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:24:46 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 21 Sep 2010 22:24:46 +0000
Subject: [issue1962] ctypes feature request: Automatic type conversion of
	input arguments to C functions
In-Reply-To: <1201597182.13.0.442457985171.issue1962@psf.upfronthosting.co.za>
Message-ID: <1285107886.47.0.72817018622.issue1962@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
Removed message: http://bugs.python.org/msg117111

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1962>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:24:57 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 21 Sep 2010 22:24:57 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285107897.95.0.235167038747.issue9915@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:32:14 2010
From: report at bugs.python.org (John J Lee)
Date: Tue, 21 Sep 2010 22:32:14 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1285108334.11.0.475957922111.issue2193@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Looks like a bug.  Here's the trac bug that this caused -- trac fixed their bug by working around this bug in a really ugly way:

http://trac.edgewall.org/ticket/2256

It would be nice to notify the trac developers if/when this is fixed.

This bug is probably not specific to colons (e.g. commas used to be valid in HTTP cookie strings, and still are as far as I know -- somebody should test what current browsers do to make sure).  The set of characters regarded as legal is less important than the fact that parsing a Cookie header should *never* raise CookieError -- it should just ignore any invalid cookies.  Still, IIRC there isn't any need to treat any of them as invalid, since more or less anything is a valid cookie (or was in the past -- as I say, maybe browsers have cleaned up since then, but I'd be surprised).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Sep 22 00:38:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Sep 2010 22:38:09 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1285108689.68.0.615904000679.issue4661@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, I'm not entirely sure I want to post this, but....

Antoine and I were having a conversation about nntplib and email and I noted that unicode as an email transmission channel acts as if it required 7bit clean data.  That is, that there's no way to use unicode as an 8bit data transmission channel.  Antoine pointed out that there is PEP 383, and that he is using that in his nntplib update to tunnel 8bit data (if there is any) from and back to the nntp server.  I said I couldn't do that with email because I not only needed to transmit the data, I also needed to *parse* it.

Antoine pointed out that you can in fact parse a header even if it has surrogateescape code points in it.

So I started thinking about that.  In point of fact, from the point of view of an email parser, non-ASCII bytes are pretty much opaque.  They don't affect the semantics of the parsing.  Either they are invalid data (in headers), or they are opaque content data (8bit Content-Transfer-Encoding).

So...I came up with a horrible little hack, which is attached here as a patch.  This is horrible because it is a perversion of the Python3 desire to make a clean separation between bytes and strings.  The only thing it really has to recommend it is that it works: it allows email5 (the version of email currently in Python3) to read wire-format messages and parse them into valid message structures.

The patch is a proof of concept and is far from complete.  It handles only message bodies (but those are the most important) and has no doc updates and only one test.  If this approach is deemed worth considering, I will flesh out the tests and make sure the corner cases are handled correctly, and write docs with lots of notes about why this is perverse and email6 will make it all better :)

I feel bad about posting this both because it is an ugly hack and because it will likely slow down email6 development (because it will make email5 mostly work).  But making email5 mostly work in 3.2 seems like a case where practicality beats purity.

The essence of the hack is as follows: Given binary data we encode it to ASCII using the surrogateescape error handler.  Then, when a message body is retrieved we check to see if there are any surrogates in it, and if there are we encode it back to ASCII using surrogateescape, thereby recovering the original bytes.  For "Content-Transfer-Encoding: 8bit" parts we can then try to decode it using the declared charset, or ASCII with the replace error handler if the charset isn't known.  But in any case the original binary data is accessible by using 'decode=True' in the call to get_payload.  (NB for those not familiar with the API: decode=True refers to decoding the Content-Transfer-Encoding, *not* decoding to unicode...which means after CTE decoding you end up with a byte string).

For headers, which are not supposed to have 8bit data in them, the best we can do is re-decode them with ASCII/replace, but at least it will be possible to parse the messages.  (The current patch doesn't do this.)

Another thing missing from the current patch is the generator side.  But since the binary data for the message content is now available, it should be possible to have a generator that outputs binary.

Note that in this patch I've introduced new functions/methods for getting binary string data in, but for file input one needs to open the file as text using ASCII encoding and the surrogateescape error handler.

I've only done minimal testing on this (obviously), and so I may find a showstopper somewhere along the way, but so far it seems to work, and logically it seems like it should work.

I don't know if that makes me happy or sad :)

----------
keywords: +patch
versions:  -Python 3.1
Added file: http://bugs.python.org/file18962/email_parse_bytes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Wed Sep 22 01:18:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 23:18:14 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1285111094.32.0.45192540694.issue4661@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A couple of comments:
- what is `str(self.get_param('charset', 'ascii'))` supposed to achieve? does get_param() return a bytes object?
- instead of ascii+surrogateescape, you could simply use latin1

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Wed Sep 22 01:26:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Sep 2010 23:26:35 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1285111595.22.0.755877572106.issue4661@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The 'str' around get_param shouldn't be there, that was left over from an earlier version of the patch.

I use surrogateescape rather than latin1 because using surrogateescape with ascii encoding gives me a reliable way to know whether or not the original source was bytes containing non-ascii chars.  (If it was bytes containing only ascii chars, then it doesn't matter what the original source was.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Wed Sep 22 01:50:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Sep 2010 23:50:22 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1285113022.95.0.257190307877.issue4661@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Wed Sep 22 02:25:37 2010
From: report at bugs.python.org (geremy condra)
Date: Wed, 22 Sep 2010 00:25:37 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <4C9920E1.6050709@egenix.com>
Message-ID: <AANLkTin_xDRzoMsS8V+Ffswq_OKPnke8Y_XG4AXMkQFt@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

>>> The pyOpenSSL port to Python3 is closing in on completion. Jean-Paul
>>> is planning for an alpha release next month.
>>
>> Do you know if he's looking for help with that? There's been some talk of
>> a porting sprint here and I'd be happy to put that at the top of the list.
>
> I don't know. You might want to contact him directly.

Sent.

By the way, if you've used the keyphrene API and wouldn't mind sharing
how it compares with the proposed crypto API I'd appreciate it, I
don't think it came up in any of the initial conversations about this.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Wed Sep 22 03:37:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Sep 2010 01:37:24 +0000
Subject: [issue678264] test_resource fails when file size is limited
Message-ID: <1285119444.84.0.0358364056176.issue678264@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That's what the original report is about, as opposed to the linux repr issue that Martin wants to break out into a new ticket (which I will do).  Any ideas how to fix the test?  It didn't fail for me on linux, so I don't have a good test platform for trying to fix it.

I'm un-assigning Neal since the original report is no longer the cause of the test error.  (The test has obviously changed since we don't check print output any more.)

----------
assignee: nnorwitz -> 
components:  -Library (Lib)
nosy:  -BreamoreBoy
stage: unit test needed -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678264>
_______________________________________

From report at bugs.python.org  Wed Sep 22 03:42:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Sep 2010 01:42:57 +0000
Subject: [issue9917] resource max value represented as signed when should be
	unsigned
In-Reply-To: <1285119777.0.0.437398080007.issue9917@psf.upfronthosting.co.za>
Message-ID: <1285119777.0.0.437398080007.issue9917@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Breaking out the library bug discussed in issue 678264 from the test bug the issue is about.

See msg14344 and msg116479.

----------
components: Library (Lib)
messages: 117123
nosy: ajaksu2, loewis, mdr0, nnorwitz, r.david.murray, sable
priority: normal
severity: normal
stage: needs patch
status: open
title: resource max value represented as signed when should be unsigned
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9917>
_______________________________________

From report at bugs.python.org  Wed Sep 22 03:47:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Sep 2010 01:47:42 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285120062.63.0.230288369105.issue9864@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, email6 should make use of datetime objects.  For email5 Antoine's proposal is better, but the question is will it happen before 3.2 beta :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Wed Sep 22 05:24:59 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 22 Sep 2010 03:24:59 +0000
Subject: [issue1172011] BaseCookie should call value_decode from __getitem__
Message-ID: <1285125899.48.0.0813872493935.issue1172011@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Moreover, BaseCookie should be used only for subclassing. Proper way is to always use SimpleCookie, this was an Invalid bug report.

----------
stage: unit test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1172011>
_______________________________________

From report at bugs.python.org  Wed Sep 22 08:01:45 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 22 Sep 2010 06:01:45 +0000
Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100
In-Reply-To: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za>
Message-ID: <1285135305.47.0.635303247465.issue1491@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491>
_______________________________________

From report at bugs.python.org  Wed Sep 22 08:09:42 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 22 Sep 2010 06:09:42 +0000
Subject: [issue1595365] Urllib2 user-agent header added by an opener is
	"frozen"
Message-ID: <1285135782.49.0.861721412245.issue1595365@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This is still a valid bug.

----------
assignee:  -> orsenthil
resolution:  -> accepted
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1595365>
_______________________________________

From report at bugs.python.org  Wed Sep 22 09:54:02 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 22 Sep 2010 07:54:02 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTin_xDRzoMsS8V+Ffswq_OKPnke8Y_XG4AXMkQFt@mail.gmail.com>
Message-ID: <4C99B614.2050904@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

geremy condra wrote:
> 
> geremy condra <debatem1 at gmail.com> added the comment:
> 
>>>> The pyOpenSSL port to Python3 is closing in on completion. Jean-Paul
>>>> is planning for an alpha release next month.
>>>
>>> Do you know if he's looking for help with that? There's been some talk of
>>> a porting sprint here and I'd be happy to put that at the top of the list.
>>
>> I don't know. You might want to contact him directly.
> 
> Sent.
> 
> By the way, if you've used the keyphrene API and wouldn't mind sharing
> how it compares with the proposed crypto API I'd appreciate it, I
> don't think it came up in any of the initial conversations about this.

No, I haven't used the APIs. I do have some experience with mxCrypto,
though, which is a low-level wrapper for the ciphers and hashes in
OpenSSL:

    http://www.egenix.com/www2002/python/mxCrypto.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Wed Sep 22 10:20:05 2010
From: report at bugs.python.org (ingemar)
Date: Wed, 22 Sep 2010 08:20:05 +0000
Subject: [issue9918] Installation "make test", two fails if non-ascii path
In-Reply-To: <1285143605.22.0.680406805216.issue9918@psf.upfronthosting.co.za>
Message-ID: <1285143605.22.0.680406805216.issue9918@psf.upfronthosting.co.za>


New submission from ingemar <ingemar at sijohansson.com>:

I am using Kubuntu 10.4 on a no-brand box with a 64-bit CPU.
I use my own download and install of Python 3.1, SIP and PyQt.

The default download directory as set up by the Kubuntu install is /home/ingemar/H?mtningar,
where "H?mtningar" is Swedish and corresponds to "Download". 
This is where the download of Python-3.1.2.tar.bz2 gets stored by default.
And this is where I let Krusader store the Python-3.1.2 folder that it pulls out of the bz2.
So I step into that folder and run ./configure,  make,  make test,  -- whoops, two tests fail:
-----------------------------------------------------------------------------------------------------
....
test_cmd
test_cmd_line
Warning: os.environ was modified by test_cmd_line
test test_cmd_line failed -- Traceback (most recent call last):
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/test/test_cmd_line.py", line 181, in test_large_PYTHONPATH
    self.assertTrue(path1.encode('ascii') in stdout)
AssertionError: False is not True

test_cmd_line_script
test_code
....


....
test_xdrlib
test_xml_etree
test_xml_etree_c
test_xmlrpc
Traceback (most recent call last):
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/xmlrpc/server.py", line 448, in do_POST
    size_remaining = int(self.headers["content-length"])
ValueError: invalid literal for int() with base 10: 'I am broken'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/socketserver.py", line 281, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/socketserver.py", line 307, in process_request
    self.finish_request(request, client_address)
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/socketserver.py", line 320, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/socketserver.py", line 614, in __init__
    self.handle()
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/http/server.py", line 352, in handle
    self.handle_one_request()
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/http/server.py", line 346, in handle_one_request
    method()
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/xmlrpc/server.py", line 472, in do_POST
    self.send_header("X-traceback", traceback.format_exc())
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/http/server.py", line 410, in send_header
    self.wfile.write(("%s: %s\r\n" % (keyword, value)).encode('ASCII', 'strict'))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 71: ordinal not in range(128)
test test_xmlrpc failed -- Traceback (most recent call last):
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/test/test_xmlrpc.py", line 555, in test_fail_with_info
    p.pow(6,8)
xmlrpc.client.ProtocolError: <ProtocolError for 127.0.0.1:46081/RPC2: 500 Internal Server Error>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/test/test_xmlrpc.py", line 562, in test_fail_with_info
    self.assertTrue(e.headers.get("X-traceback") is not None)
AssertionError: False is not True

test_xmlrpc_net
test_xmlrpc_net skipped -- Use of the `network' resource not enabled
test_zipfile
test_zipfile64
test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run
test_zipimport
test_zipimport_support
test_zlib
312 tests OK.
2 tests failed:
    test_cmd_line test_xmlrpc
22 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_kqueue
    test_nis test_ossaudiodev test_pep277 test_smtpnet
    test_socketserver test_startfile test_timeout test_tk
    test_ttk_guionly test_urllib2net test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64
Those skips are all expected on linux2.
make: *** [test] Fel 1
...
-----------------------------------------------------------------------------------------------------







Those two test don't like the Swedish dotted character "?" in the folder name.
I renamed the folder into pure ASCII and restarted: 
./configure,  make,  make test,  sudo make install.
Everything worked as expected:
.....
314 tests OK.
22 tests skipped:
.....

----------
components: None
messages: 117128
nosy: ingemar
priority: normal
severity: normal
status: open
title: Installation "make test", two fails if non-ascii path
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9918>
_______________________________________

From report at bugs.python.org  Wed Sep 22 11:04:40 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 22 Sep 2010 09:04:40 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285146280.66.0.00800290722563.issue678250@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

After Antoine commit concerning issue2643, here is a new patch (just removing the changes in close).

Could you commit it?

----------
Added file: http://bugs.python.org/file18963/patch_mmap_flush_updated.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Wed Sep 22 11:58:46 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 22 Sep 2010 09:58:46 +0000
Subject: [issue678264] test_resource fails when file size is limited
Message-ID: <1285149526.51.0.345814893933.issue678264@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

The ideal would be to check that RLIMIT_FSIZE corresponds to the ulimit as it has been suggested by Neal Norwitz in msg14345, but since the value reported by ulimit has a different unit for each platform, that would be quite a lot of trouble.

All I can suggest is the following, which checks that both values are somewhat reasonable.

Index: Lib/test/test_resource.py
===================================================================
--- Lib/test/test_resource.py	(r?vision 84964)
+++ Lib/test/test_resource.py	(copie de travail)
@@ -20,12 +20,17 @@
         except AttributeError:
             pass
         else:
-            # RLIMIT_FSIZE should be RLIM_INFINITY, which will be a really big
-            # number on a platform with large file support.  On these platforms,
-            # we need to test that the get/setrlimit functions properly convert
-            # the number to a C long long and that the conversion doesn't raise
-            # an error.
-            self.assertEqual(resource.RLIM_INFINITY, max)
+            # RLIMIT_FSIZE should be RLIM_INFINITY if 'ulimit -f' is
+            # set to unlimited
+            # RLIM_INFINITY will be a really big number on a platform
+            # with large file support.  On these platforms, we need to
+            # test that the get/setrlimit functions properly convert
+            # the number to a C long long and that the conversion
+            # doesn't raise an error.            
+            self.assertGreater(resource.RLIM_INFINITY, 0)
+            self.assertLessEqual(cur, max)
+            self.assertGreater(max, 0)
+            self.assertLessEqual(max, resource.RLIM_INFINITY)
             resource.setrlimit(resource.RLIMIT_FSIZE, (cur, max))
 
     def test_fsize_enforced(self):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678264>
_______________________________________

From report at bugs.python.org  Wed Sep 22 12:09:30 2010
From: report at bugs.python.org (Florian Festi)
Date: Wed, 22 Sep 2010 10:09:30 +0000
Subject: [issue1675951] Performance for small reads and fix seek problem
Message-ID: <1285150170.1.0.62688743466.issue1675951@psf.upfronthosting.co.za>


Florian Festi <florianfesti at users.sourceforge.net> added the comment:

Stupid me! I ran the tests against my systems gzip version (Py 3.1). The performance issue is basically fixed by rev 77289. Performance is even a bit better that my original patch by may be 10-20%. The only test case where it performs worse is 

Random 10485760 byte block test
Original gzip Write:   20.452 s Read:    2.931 s
New gzip      Write:   20.518 s Read:    1.247 s

Don't know if it is worth bothering. May be increasing the maximum chunk size improves this - but I didn't try that out yet.

WRT to seeking:

I now have two patches that eliminate the need for seek() on normal operation (rewind obviously still needs seek()). Both are based on the PaddedFile class. The first patch just creates a PaddedFile object while switching from an old to a new member while the second just wraps the fileobj all the time. Performance test show that wrapping is cheap. The first patch is a bit ugly while the second requires a implementation of seek() and may create problems if new methods of the fileobj are used that may interfere with the PaddedFile's internals.

So I leave the choice which one is preferred to the module owner.

The patch creates another problem with is not yet fixed: The implementation of .seekable() is becoming wrong. As one can now use non seekable files the implementation should check if the file object used for reading is really seekable. As this is my first PY3k work I'd prefer if this can be solved by someone else (But that should be pretty easy).

----------
Added file: http://bugs.python.org/file18964/0001-Avoid-the-need-of-seek-ing-on-the-file-read.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Wed Sep 22 12:10:02 2010
From: report at bugs.python.org (Florian Festi)
Date: Wed, 22 Sep 2010 10:10:02 +0000
Subject: [issue1675951] Performance for small reads and fix seek problem
Message-ID: <1285150202.45.0.0155546380151.issue1675951@psf.upfronthosting.co.za>


Changes by Florian Festi <florianfesti at users.sourceforge.net>:


Added file: http://bugs.python.org/file18965/0002-Avoid-the-need-of-seek-ing-on-the-file-read-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Wed Sep 22 12:32:32 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 22 Sep 2010 10:32:32 +0000
Subject: [issue730467] Not detecting AIX_GENUINE_CPLUSPLUS
Message-ID: <1285151552.96.0.429102034007.issue730467@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I can confirm this is still a problem in py3k for AIX 5.3 and AIX 6.1.
The file "/usr/lpp/xlC/include/load.h" does not exist anymore; it is now "/usr/include/load.h".

The proposed patch would only create a problem for very old versions of AIX and xlc (which are no longer supported by IBM anyway and I doubt anybody is going to compile Python 3.x on them some day), while the current state is that it is broken for current versions ("current" being "released in the last 7 years"!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue730467>
_______________________________________

From report at bugs.python.org  Wed Sep 22 12:34:36 2010
From: report at bugs.python.org (qpatata)
Date: Wed, 22 Sep 2010 10:34:36 +0000
Subject: [issue9919] gdbinit lineno result is one line in excess
In-Reply-To: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>
Message-ID: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>


New submission from qpatata <qpatata at gmail.com>:

Thanks a lot to all python teams for your excel.lent work.

When latest version of gdbinit macros is used to debug with gdb a python 2.4 session, the result from lineno macro seems one line more than the correct one.

If we compare the gdb macro:

define lineno
    set $__continue = 1
    set $__co = f->f_code
    set $__lasti = f->f_lasti
    set $__sz = ((PyStringObject *)$__co->co_lnotab)->ob_size/2
    set $__p = (unsigned char *)((PyStringObject *)$__co->co_lnotab)->ob_sval
    set $__li = $__co->co_firstlineno
    set $__ad = 0
    while ($__sz-1 >= 0 && $__continue)
      set $__sz = $__sz - 1
      set $__ad = $__ad + *$__p
      set $__p = $__p + 1
      if ($__ad > $__lasti)
	set $__continue = 0
      end
      set $__li = $__li + *$__p
      set $__p = $__p + 1
    end
    printf "%d", $__li
end

with the related C source code in libpython.py

    def addr2line(self, addrq):
        '''
        Get the line number for a given bytecode offset

        Analogous to PyCode_Addr2Line; translated from pseudocode in
        Objects/lnotab_notes.txt
        '''
        co_lnotab = self.pyop_field('co_lnotab').proxyval(set())

        # Initialize lineno to co_firstlineno as per PyCode_Addr2Line
        # not 0, as lnotab_notes.txt has it:
        lineno = int_from_int(self.field('co_firstlineno'))

        addr = 0
        for addr_incr, line_incr in zip(co_lnotab[::2], co_lnotab[1::2]):
            addr += ord(addr_incr)
            if addr > addrq:
                return lineno
            lineno += ord(line_incr)
        return lineno

we see that if addr  is greater than addrq, the python codes returns immedialty, but the gdb macro adds a new delta of lines before exit the loop.

Kind regards.

----------
messages: 117133
nosy: qpatata
priority: normal
severity: normal
status: open
title: gdbinit lineno result is one line in excess
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9919>
_______________________________________

From report at bugs.python.org  Wed Sep 22 12:48:40 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 22 Sep 2010 10:48:40 +0000
Subject: [issue730467] Not detecting AIX_GENUINE_CPLUSPLUS
Message-ID: <1285152520.61.0.154443020518.issue730467@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

It should also be changed in Python/dynload_aix.c:

Index: Python/dynload_aix.c
===================================================================
--- Python/dynload_aix.c	(r?vision 84964)
+++ Python/dynload_aix.c	(copie de travail)
@@ -12,7 +12,7 @@
 
 
 #ifdef AIX_GENUINE_CPLUSPLUS
-#include "/usr/lpp/xlC/include/load.h"
+#include <load.h>
 #define aix_load loadAndInit
 #else
 #define aix_load load

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue730467>
_______________________________________

From report at bugs.python.org  Wed Sep 22 15:03:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Sep 2010 13:03:25 +0000
Subject: [issue9918] Installation "make test", two fails if non-ascii path
In-Reply-To: <1285143605.22.0.680406805216.issue9918@psf.upfronthosting.co.za>
Message-ID: <1285160605.0.0.695672346394.issue9918@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm amazed you only got two failures.  Victor has been doing a lot of work in 3.2 trying to make non-ascii paths work reliably.

----------
nosy: +haypo, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9918>
_______________________________________

From report at bugs.python.org  Wed Sep 22 15:06:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Sep 2010 13:06:56 +0000
Subject: [issue9918] Installation "make test", two fails if non-ascii path
In-Reply-To: <1285143605.22.0.680406805216.issue9918@psf.upfronthosting.co.za>
Message-ID: <1285160816.83.0.463835393542.issue9918@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

oh, wait, victor's work is for undecodable non-ascii characters.  I think flox did the work on decodable non-ascii characters, and that may well have gone into 3.1.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9918>
_______________________________________

From report at bugs.python.org  Wed Sep 22 15:13:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Sep 2010 13:13:42 +0000
Subject: [issue9918] Installation "make test", two fails if non-ascii path
In-Reply-To: <1285143605.22.0.680406805216.issue9918@psf.upfronthosting.co.za>
Message-ID: <1285161222.6.0.544009757141.issue9918@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

See issue7606 and issue7605: both fixed in SVN. All is needed is a new 3.1.x release :)

----------
nosy: +pitrou
resolution:  -> out of date
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9918>
_______________________________________

From report at bugs.python.org  Wed Sep 22 15:13:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Sep 2010 13:13:47 +0000
Subject: [issue9917] resource max value represented as signed when should be
	unsigned
In-Reply-To: <1285119777.0.0.437398080007.issue9917@psf.upfronthosting.co.za>
Message-ID: <1285161227.68.0.699024191501.issue9917@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

And here is Martin's summary of the issue:

I think we really should create new issues for any remaining problems.

AFAICT, the remaining problems are:
- resource.RLIM_INFINITY is -1 on Linux, when it is meant to be
   a really large value
- (as you reported) getrlimit returns -1 to indicate RLIM_INFINITY.

I think the core of the problem is that the resource module considers
rlim_t to be a signed type (or at least representable in "long long").
Using FromUnsignedLongLong in the appropriate place might solve the
issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9917>
_______________________________________

From report at bugs.python.org  Wed Sep 22 15:39:21 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 22 Sep 2010 13:39:21 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1285162761.99.0.137747450892.issue1692335@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In msg108954, I believe belopolsky is mistaken in stating that "it would be easy to simply provide custom __getinitargs__ or __reduce__ to support it". It appears __getinitargs__ does not work on Python 2.5 or Python 2.7. Exceptions of the following class still raise a TypeError on unpickling:

class D(Exception):
    """Extension with values, init called with no args."""
    def __init__(self, foo):
        self.foo = foo
        Exception.__init__(self)

    def __getinitargs__(self):
        return self.foo,

Using __reduce__ does seem to work. I suspect this is because Exceptions are extension types.

I think the fundamental problem is that pickling exceptions does not follow the principle of least surprise. In particular:

 - Other built-in objects (dicts, lists, etc) don't require special handling (replace Exception with dict in the above example and it works).
 - It's not obvious how to write an Exception subclass that takes additional arguments and make it pickleable.
 - Neither the pickle documentation nor the Exception documentation describe how pickling is implemented in Exceptions.

Eric has provided some good use cases. Furthermore, it seems counter-intuitive to me to pass a subclass' custom arguments to the parent class. Indeed, even the official tutorial defines exception classes that are unpickleable (http://docs.python.org/tutorial/errors.html#tut-userexceptions).

If the use case is obvious enough that it shows up in the hello world tutorial, I don't think there should be any argument that it's not a common use case.

At the very least, there should be a section in the pickle documentation or Exception documentation describing how one should make a pickleable subclass. What would be better is for Exceptions to behave like most other classes when being pickled.

----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Wed Sep 22 15:41:43 2010
From: report at bugs.python.org (jasper)
Date: Wed, 22 Sep 2010 13:41:43 +0000
Subject: [issue7296] OverflowError: signed integer is greater than maximum on
	mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1285162903.65.0.40655085689.issue7296@psf.upfronthosting.co.za>


jasper <jasper at humppa.nl> added the comment:

FYI, the issue has been fixed now in the mips64 port of OpenBSD by "replacing the previous/old floating point completion code with a C interface to the MI softfloat code, implementing all MIPS IV specified floating point
operations."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7296>
_______________________________________

From report at bugs.python.org  Wed Sep 22 16:13:08 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 22 Sep 2010 14:13:08 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

test_cmath will fail with the following error on AIX:

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/buildbot/buildbot-aix6/py3k-aix6-xlc/build/Lib/test/test_cmath.py", line 350, in test_specific_values
    msg=error_message)
  File "/san_cis/home/cis/buildbot/buildbot-aix6/py3k-aix6-xlc/build/Lib/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.


There is a test concerning tanh in configure, which may be related:
checking whether tanh preserves the sign of zero... yes

----------
components: Library (Lib)
messages: 117141
nosy: sable
priority: normal
severity: normal
status: open
title: test_cmath on atan fails on AIX
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Wed Sep 22 16:19:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Sep 2010 14:19:52 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1285165192.56.0.0800656895471.issue9920@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report.  This looks like it's probably a bug (not a particularly serious one, but worth reporting) on AIX.

The 'tanh' configure test diagnoses a similar wrong-sign-of-zero problem on FreeBSD;  it looks as though AIX is happy here---that is, 'yes' is the expected and desired result for that configure test.

----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Wed Sep 22 16:21:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Sep 2010 14:21:16 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1285165276.91.0.409645662185.issue9920@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

P.S.  Was the test with a debug build of Python?  If not, could you see if the test failure still occurs with a debug build (i.e., when --with-pydebug is passed as a configure argument)?  That would help eliminate compiler optimization bugs as a possible cause.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Wed Sep 22 16:30:50 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Sep 2010 14:30:50 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1285165850.35.0.562176548693.issue9920@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry---one more question:  could you tell me what the following gives on the AIX machine?

Python 2.7 (r27:82500, Aug 15 2010, 14:21:15) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from cmath import tanh
>>> tanh(complex(-0.0, 0.0))
(-0+0j)


Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Wed Sep 22 16:58:07 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 22 Sep 2010 14:58:07 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1285167487.24.0.799498618025.issue1692335@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

After some further reading, I found that PEP-352 (http://www.python.org/dev/peps/pep-0352/) explicitly states that "Including programmatic information (e.g., an error code number) should be stored as a separate attribute in a subclass [and not in the args attribute]." The parameter to Exception.__init__ should always be a single, human-readable string. The default pickler doesn't handle this officially-prescribed use-case without overriding __reduce__.

class F(Exception):
    def __init__(self, message, code):
        Exception.__init__(self, message)
        self.code = code

Of course, as belopolsky observed, __repr__ must also be overridden.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Wed Sep 22 17:22:57 2010
From: report at bugs.python.org (Radu Grigore)
Date: Wed, 22 Sep 2010 15:22:57 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>


New submission from Radu Grigore <radugrigore at gmail.com>:

The docs say that "the return value is the concatenation of path1, and optionally path2, etc., with exactly one directory separator (os.sep) inserted between components, unless path2 is empty."

But os.path.join('x','') returns 'x/' in which path1 and path2 *are* separated by exactly one os.sep, even though path2 is empty.

Either the docs or the implementation should be updated.

----------
components: Library (Lib)
messages: 117146
nosy: rgrig
priority: normal
severity: normal
status: open
title: os.path.join('x','') behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Wed Sep 22 19:14:33 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 22 Sep 2010 17:14:33 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285175673.25.0.400686320818.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Attached is my script for running a more comprehensive battery of speed tests.  The script itself requires Python 2.6 with argparse installed or Python 2.7 (which includes argparse).

For obvious reasons, please make sure that your unpatched and patched versions of python are otherwise identical (same source, same compiler, same configure and compiler settings, etc.).

The script will create subdirectories to store data, so please run it in the speed_test directory.

Example usage:

otto:~/speed_test$ ./speed_test.py ../py3k-unpatched/ ../py3k-patched/ 'sort random'


otto:~/speed_test$ ./speed_test.py --help
usage: speed_test.py [-h] [--minn MINN] [--maxn MAXN]
                     [-r, --repetitions REPETITIONS] [--graphs]
                     control experiment [tests [tests ...]]

Compare the speed of two list implementations

positional arguments:
  control               control/python
  experiment            experiment/python
  tests                 Names of tests to conduct

optional arguments:
  -h, --help            show this help message and exit
  --minn MINN           Minimum list size
  --maxn MAXN           Maximum list size
  -r, --repetitions REPETITIONS
                        Repetitions; how many times to repeat each experiment
  --graphs              Generate performance graphs as a function of n;
                        requires gnuplot

Available experiments:
sort random tuples
sort random key
sort reversed
sort random objects
sort sorted
sort sorted key
sort random
sort sorted objects
sort reversed key

----------
Added file: http://bugs.python.org/file18966/speed_test.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Wed Sep 22 20:12:55 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 22 Sep 2010 18:12:55 +0000
Subject: [issue9919] gdbinit lineno result is one line in excess
In-Reply-To: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>
Message-ID: <1285179175.44.0.590731019401.issue9919@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Can you show an example which shows an incorrect lineno?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9919>
_______________________________________

From report at bugs.python.org  Wed Sep 22 20:39:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 22 Sep 2010 18:39:42 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
In-Reply-To: <1285162761.99.0.137747450892.issue1692335@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=wq6ZTq_oesBO-R624dhr5CGiUzOcGKThVAQZ6@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Sep 22, 2010 at 9:39 AM, Jason R. Coombs <report at bugs.python.org> wrote:
> .. It appears __getinitargs__ does not work on Python 2.5 or Python 2.7.

Yes,  __getinitargs__  is only used for old style classes.  I was
wrong on that point.

> Exceptions of the following class still raise a TypeError on unpickling:
>
> class D(Exception):
> ? ?"""Extension with values, init called with no args."""
> ? ?def __init__(self, foo):
> ? ? ? ?self.foo = foo
> ? ? ? ?Exception.__init__(self)
>
> ? ?def __getinitargs__(self):
> ? ? ? ?return self.foo,
>

The problem with your D class is that it does not provide correct args
attribute which is expected from an exception class:

()

> Using __reduce__ does seem to work. I suspect this is because Exceptions are extension types.
>

There are two ways to fix this class.  Both fix the args issue as well:

1. Pass foo to Exception.__init__  like this: Exception.__init__(self,
foo) in D.__init__.

2. Explicitly initialize self.args: self.args	= foo,

> I think the fundamental problem is that pickling exceptions does not follow the principle of least surprise. In particular:
>
> ?- Other built-in objects (dicts, lists, etc) don't require special handling (replace Exception with dict in the above example and it works).

Other built-in objects don't provide an API for retrieving their init arguments.

> ?- It's not obvious how to write an Exception subclass that takes additional arguments and make it pickleable.

AFAICT, this is python subclassing 101: if base class __init__ uses
arguments, they should be passed to it by subclass' __init__.

> ?- Neither the pickle documentation nor the Exception documentation describe how pickling is implemented in Exceptions.
>

Exception documentation may be improved by adding a section on
subclassing.  Note that the args argument was not even mentioned in
2.7 documentation, so some discussion of its role may be helpful
somewhere.

> Eric has provided some good use cases. Furthermore, it seems counter-intuitive to me to pass a subclass' custom
> arguments to the parent class. Indeed, even the official tutorial defines exception classes that are unpickleable
> (http://docs.python.org/tutorial/errors.html#tut-userexceptions).
>

Well, the tutorial examples should probably be changed.  In these
examples base class __init__ is not called at all which is probably
not a good style.

> If the use case is obvious enough that it shows up in the hello world tutorial, I don't think
> there should be any argument that it's not a common use case.
>

I am not arguing against simplifying Exception subclassing.  I just
don't see an easy solution that would not promote subclasses with
unusable args attribute.  I also disagree with this issue classified
as a bug.  It may be a valid feature request, but not a bug.

In any case, no proponent of this feature has come up with a patch for
3.2 so far and in my view, this would be a prerequisite for moving
this forward.

> At the very least, there should be a section in the pickle documentation or Exception
> documentation describing how one should make a pickleable subclass. ..

I agree, but again someone has to step in to write such section.
Improving documentation may also be the only solution for the 2.x
series.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Wed Sep 22 20:41:28 2010
From: report at bugs.python.org (Ask Solem)
Date: Wed, 22 Sep 2010 18:41:28 +0000
Subject: [issue9801] Can not use append/extend to lists in a multiprocessing
	manager dict
In-Reply-To: <1283973802.38.0.869176624785.issue9801@psf.upfronthosting.co.za>
Message-ID: <1285180888.59.0.261574230995.issue9801@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Maybe surprising but not so weird if you think about what happens
behind the scenes.

When you do

    >>> x = man.list()
    >>> x.append({})

You send an empty dict to the manager to be appended to x

when do:

   >>> x[0]
   {}

you receive a local copy of the empty dict from the manager process.


So this:

    >>> x[0]["a"] = 5

will only modify the local copy.

What you would have to do is:

    >>> x.append({})
    >>> t = x[0]
    >>> t["a"] = 5
    >>> x[0] = t

This will not be atomic of course, so this may be something
to take into account.

What maybe could be supported is something like:
    >>> x[0] = manager.dict()
    >>>x[0]["foo"] = "bar"

but otherwise I wouldn't consider this a bug.

----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9801>
_______________________________________

From report at bugs.python.org  Wed Sep 22 21:19:59 2010
From: report at bugs.python.org (Ask Solem)
Date: Wed, 22 Sep 2010 19:19:59 +0000
Subject: [issue7707] multiprocess.Queue operations during import can lead to
	deadlocks
In-Reply-To: <1263573315.16.0.465636049394.issue7707@psf.upfronthosting.co.za>
Message-ID: <1285183199.97.0.0115446604069.issue7707@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

I created a small doc patch for this (attached).

----------
keywords: +needs review, patch
nosy: +asksol
versions: +Python 3.1 -Python 2.6
Added file: http://bugs.python.org/file18967/multiprocessing-issue7707.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7707>
_______________________________________

From report at bugs.python.org  Wed Sep 22 22:44:23 2010
From: report at bugs.python.org (qpatata)
Date: Wed, 22 Sep 2010 20:44:23 +0000
Subject: [issue9919] gdbinit lineno result is one line in excess
In-Reply-To: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>
Message-ID: <1285188263.18.0.983544854518.issue9919@psf.upfronthosting.co.za>


qpatata <qpatata at gmail.com> added the comment:

Hello,

Thanks for your colaboration.

Starting by the following python file, called "prueba.py":

> cat prueba.py
import time

def bar():
    time.sleep(10);
    print "hello";

def foo():
  while True:
    bar();

foo();




Open a gdb session with python2-6 as target:

> gdb /usr/bin/python2.6

and run the python program. 

gdb> run prueba.py

After a few seconds, type Ctrl-C to break the program. Usually, break will interrupt it when execution is in the "sleep" statement. A "bt" gives:

#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb7d42fdd in select () from /lib/i686/cmov/libc.so.6
#2  0x08119a3f in floatsleep (self=0x0, args=(10,)) at ../Modules/timemodule.c:918
#3  time_sleep (self=0x0, args=(10,)) at ../Modules/timemodule.c:206
#4  0x080e0721 in call_function (f=Frame 0x82e17ac, for file prueba.py, line 4, in bar (), 
    throwflag=0) at ../Python/ceval.c:3750
#5  PyEval_EvalFrameEx (f=Frame 0x82e17ac, for file prueba.py, line 4, in bar (), throwflag=0)
    at ../Python/ceval.c:2412
...

If we go until C frame #5 (up, up, ...) and execute the lineno macro:

#5  PyEval_EvalFrameEx (f=Frame 0x82e17ac, for file prueba.py, line 4, in bar (), throwflag=0)
    at ../Python/ceval.c:2412
2412    in ../Python/ceval.c

(gdb) lineno
5
(gdb) 

It is clear the mismatch between the line reported by lineno (5), the one in the source file (4) and the one displayed by gdb (4).

In addition, if we look at the version history of the "gdbinit" file, we can see how version 39276 has an implementation of lineno who matches the related C code in Python project, but next version (39492) introduces a boolean to control the end of loop. This change is, probably, the origen of the mismatch.

Thanks a lot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9919>
_______________________________________

From report at bugs.python.org  Wed Sep 22 22:47:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Sep 2010 20:47:47 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1285188467.18.0.265267728197.issue9921@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since changing the implementation would be a backward incompatible behavior change to a behavior that has existed for a long time, it's the docs that should be updated.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, r.david.murray
stage:  -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Wed Sep 22 22:58:23 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 22 Sep 2010 20:58:23 +0000
Subject: [issue9916] errno module is missing some symbols
In-Reply-To: <1285105452.83.0.807715545592.issue9916@psf.upfronthosting.co.za>
Message-ID: <1285189103.26.0.587530722527.issue9916@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r84966

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9916>
_______________________________________

From report at bugs.python.org  Wed Sep 22 23:17:20 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 22 Sep 2010 21:17:20 +0000
Subject: [issue1462440] socket and threading: udp multicast setsockopt fails
Message-ID: <1285190240.69.0.704165167085.issue1462440@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I tested it on a Windows XP box, and encountered the same problem.
The error is raised because Windows XP requires the socket to be bound before calling setsockopt(IPPROTO_IP, IP_ADD_MEMBERSHIP, mreq).
So calling bind() before setsockopt() solves this error.
But then you also need to specify for the sender the interface to use using setsockopt(IPPROTO_IP, IP_MULTICAST_IF, address)

Here's a working example:

---- sender ----
from socket import *

s = socket(AF_INET, SOCK_DGRAM)
s.setsockopt(IPPROTO_IP, IP_MULTICAST_IF, inet_aton('127.0.0.1'))
s.sendto(b'foo', ('224.0.0.1', 4242))
----------------

--- receiver ---
from socket import *

s = socket(AF_INET, SOCK_DGRAM)
s.bind(('127.0.0.1', 4242))
mreq = inet_aton('224.0.0.1') + inet_aton('127.0.0.1')
s.setsockopt(IPPROTO_IP, IP_ADD_MEMBERSHIP, mreq)
s.recv(100)
----------------

So it's not a Python bug.
Since multicast is tricky, it might be a good idea to add a short example somewhere in the documentation though.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1462440>
_______________________________________

From report at bugs.python.org  Thu Sep 23 00:06:39 2010
From: report at bugs.python.org (geremy condra)
Date: Wed, 22 Sep 2010 22:06:39 +0000
Subject: [issue9922] subprocess.getstatusoutput and bytes
In-Reply-To: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>
Message-ID: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>


New submission from geremy condra <debatem1 at gmail.com>:

It looks like subprocess.getstatusoutput on 3.2a1 tries to coerce to UTF-8, which fails when dealing with bytes. This demonstrates the behavior nearly all the time for me on Ubuntu 10.04:

>>> import subprocess
>>> subprocess.getstatusoutput('dd if=/dev/random bs=1K count=1')

Here's the tracebacks from a few runs:

>>> subprocess.getstatusoutput('dd if=/dev/random bs=1K count=1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/subprocess.py", line 585, in getstatusoutput
    text = pipe.read()
  File "/usr/local/lib/python3.2/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xcb in position 3: invalid continuation byte
>>> subprocess.getstatusoutput('dd if=/dev/random bs=1K count=1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/subprocess.py", line 585, in getstatusoutput
    text = pipe.read()
  File "/usr/local/lib/python3.2/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe4 in position 2: invalid continuation byte
>>> subprocess.getstatusoutput('dd if=/dev/random bs=1K count=1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/subprocess.py", line 585, in getstatusoutput
    text = pipe.read()
  File "/usr/local/lib/python3.2/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xac in position 0: invalid start byte
>>> subprocess.getstatusoutput('dd if=/dev/random bs=1K count=1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/subprocess.py", line 585, in getstatusoutput
    text = pipe.read()
  File "/usr/local/lib/python3.2/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xf1 in position 0: invalid continuation byte
>>> 

And here's the version info:

Python 3.2a1 (r32a1:83318, Aug 13 2010, 22:32:03) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.

----------
components: Library (Lib)
messages: 117156
nosy: debatem1
priority: normal
severity: normal
status: open
title: subprocess.getstatusoutput and bytes
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9922>
_______________________________________

From report at bugs.python.org  Thu Sep 23 00:09:02 2010
From: report at bugs.python.org (Matt Bond)
Date: Wed, 22 Sep 2010 22:09:02 +0000
Subject: [issue9621] Graphviz output for 2to3 fixer patterns
In-Reply-To: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za>
Message-ID: <1285193342.65.0.164420813945.issue9621@psf.upfronthosting.co.za>


Matt Bond <gmattbond at gmail.com> added the comment:

As requested, attached is the output for the fix_buffer fixer, as an example of the kind of output this patch can produce.

----------
Added file: http://bugs.python.org/file18968/fix_buf_pytree_1.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9621>
_______________________________________

From report at bugs.python.org  Thu Sep 23 00:11:05 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 22 Sep 2010 22:11:05 +0000
Subject: [issue9919] gdbinit lineno result is one line in excess
In-Reply-To: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>
Message-ID: <1285193465.39.0.707588770798.issue9919@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

OK, I reproduce the issue. It is now clear to me as well that r39492 was slightly wrong: the replacement of "break" should avoid to execute the end of the loop.

The following patch fixes the issue for me, can someone with better gdb knowledge check it?

Index: Misc/gdbinit
===================================================================
--- Misc/gdbinit        (revision 84966)
+++ Misc/gdbinit        (working copy)
@@ -59,9 +59,10 @@
       set $__p = $__p + 1
       if ($__ad > $__lasti)
        set $__continue = 0
+      else
+        set $__li = $__li + *$__p
+        set $__p = $__p + 1
       end
-      set $__li = $__li + *$__p
-      set $__p = $__p + 1
     end
     printf "%d", $__li
 end

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9919>
_______________________________________

From report at bugs.python.org  Thu Sep 23 01:21:02 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 22 Sep 2010 23:21:02 +0000
Subject: [issue1257] atexit errors should result in nonzero exit code
In-Reply-To: <1192046186.55.0.804669715206.issue1257@psf.upfronthosting.co.za>
Message-ID: <1285197662.32.0.821931880251.issue1257@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

exit code = 128 + # of failed atexits

I don't agree with the feature. Do we need something so complex?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1257>
_______________________________________

From report at bugs.python.org  Thu Sep 23 01:28:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Sep 2010 23:28:45 +0000
Subject: [issue9621] Graphviz output for 2to3 fixer patterns
In-Reply-To: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za>
Message-ID: <1285198125.93.0.722642300008.issue9621@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> When I was working with 2to3 this summer I was running it via python3,
> so I think the patch should work
Code in the patch uses print as a keyword (2.x), not a function (3.x).  How does that work?

> however, if I've submitted it to the wrong place or the wrong branch,
> where should I be looking at to ensure my code does work on 3.2 and
> is submitted to the right place?
This tracker is the right place for bugs relevant to any CPython version.  To ensure your code works on 3.2, just apply the diff on a 3.2 checkout.  More info on http://www.python.org/dev/ (especially http://www.python.org/dev/patches/).

> In regard to the import gvgraph, I wasn't sure what to do with it
If the implicit relative import doesn?t work, as I suspect, sys.path.append(os.path.dirname(__file__)) should be enough.

(Cheers from a fellow GSoCer, by the way :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9621>
_______________________________________

From report at bugs.python.org  Thu Sep 23 01:37:38 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 22 Sep 2010 23:37:38 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285198658.83.0.00604553508077.issue9552@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Thu Sep 23 03:04:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Sep 2010 01:04:33 +0000
Subject: [issue1491804] Simple slice support for list.sort() and .reverse()
Message-ID: <1285203873.96.0.523776364576.issue1491804@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In fact, I find the proposed syntax *less* obvious than the slice syntax, for sorted.  IOW, I'd be -1 on adding these to sorted.  The potentially useful case is between

    l[a:b] = sorted(l[a:b})

vs

    l.sort(start=a, stop=b)

where the interesting bit is that the sort takes place in place (no memory copy).

I still find the slice syntax clearer :), and it's not clear that the savings of the memory copy for a few programs that use it is worth the added complexity for all other programs.  So I concur with Raymond's rejection.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491804>
_______________________________________

From report at bugs.python.org  Thu Sep 23 03:04:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Sep 2010 01:04:50 +0000
Subject: [issue1491804] Simple slice support for list.sort() and .reverse()
Message-ID: <1285203890.25.0.817429494486.issue1491804@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491804>
_______________________________________

From report at bugs.python.org  Thu Sep 23 04:26:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Sep 2010 02:26:08 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285208768.98.0.200511043749.issue9864@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm assigning this to myself because I'm assigned on all email issues, but that shouldn't prevent someone from working on a patch implementing Antoine's suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Thu Sep 23 04:26:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Sep 2010 02:26:29 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285208789.37.0.72986259215.issue9864@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Thu Sep 23 05:03:57 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Thu, 23 Sep 2010 03:03:57 +0000
Subject: [issue9923] mailcap module may will not work on non-POSIX platforms
	if MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>


New submission from Gregory Nofi <crackityjones2004-p at yahoo.com>:

mailcap.getcaps() has a call to mailcap.listmailcapfiles(), which returns a list of all mailcap files found on the system.

listmailcapfiles() first looks for the MAILCAPS environment variable. If it exists, it converts the string value into a list by splitting it on ":". This will not work on platforms that use other path separators, like Windows (";").

Attached are patches that use os.pathsep instead.

For more information about the MAILCAPS variable, see Appendix A in RFC 1524 (http://tools.ietf.org/html/rfc1524.html).

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh, Windows
files: mailcap_trunk.py
messages: 117163
nosy: gnofi, ronaldoussoren
priority: normal
severity: normal
status: open
title: mailcap module may will not work on non-POSIX platforms if MAILCAPS env variable is set
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18969/mailcap_trunk.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Thu Sep 23 05:04:32 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Thu, 23 Sep 2010 03:04:32 +0000
Subject: [issue9923] mailcap module may will not work on non-POSIX platforms
	if MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1285211072.13.0.958100651489.issue9923@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Added file: http://bugs.python.org/file18970/mailcap_py3k.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Thu Sep 23 05:06:22 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Thu, 23 Sep 2010 03:06:22 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1285211182.01.0.92586042893.issue9923@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

Fixing typo in title

----------
title: mailcap module may will not work on non-POSIX platforms if MAILCAPS env variable is set -> mailcap module may not work on non-POSIX platforms if MAILCAPS env variable is set

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Thu Sep 23 05:45:40 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Thu, 23 Sep 2010 03:45:40 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285213540.61.0.0367900381701.issue9864@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

Where does "email6" live?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Thu Sep 23 05:54:51 2010
From: report at bugs.python.org (Alex)
Date: Thu, 23 Sep 2010 03:54:51 +0000
Subject: [issue9801] Can not use append/extend to lists in a multiprocessing
	manager dict
In-Reply-To: <1283973802.38.0.869176624785.issue9801@psf.upfronthosting.co.za>
Message-ID: <1285214091.13.0.872830555427.issue9801@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

It should be documented though.  Similar scenario in the Django docs: http://docs.djangoproject.com/en/1.2/topics/http/sessions/#when-sessions-are-saved

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9801>
_______________________________________

From report at bugs.python.org  Thu Sep 23 05:56:06 2010
From: report at bugs.python.org (mike bayer)
Date: Thu, 23 Sep 2010 03:56:06 +0000
Subject: [issue9924] sqlite3 SELECT does not BEGIN a transaction,
	but should according to spec
In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za>
Message-ID: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za>


New submission from mike bayer <mike_mp at zzzcomputing.com>:

Copying this bug from the pysqlite tracker, at http://code.google.com/p/pysqlite/issues/detail?id=21 , as the issue has been opened for two days with no reply. (side node - should sqlite3 bugs be reported here or on the pysqlite tracker ?)  The text below was originally written by Randall Nortman:

Pysqlite does not open a transaction in the database until a DML statement is encountered (INSERT, UPDATE, or DELETE).  A DQL (SELECT) statement will not cause a transaction to be opened if one is not already opened.  This is the documented behavior, but it is not what is intended by the spec (PEP 249).  The spec intends a transaction to always be open (per the spec author), and this is what happens in other DB-API drivers.  For more information, see the this DB-SIG mailing list post (by the PEP 249 author):

http://mail.python.org/pipermail/db-sig/2010-September/005645.html

For additional background, see this thread on the SQLAlchemy mailing list, which is the source of the attached test case:

http://groups.google.com/group/sqlalchemy/browse_thread/thread/2f47e28c1fcdf9e6/0ef1666759ce0724#0ef1666759ce0724

What steps will reproduce the problem?
1. See attached test case.  Run it as is, and the final conn1.commit() statement will complete successfully.
2. Uncomment the c2.execute("BEGIN") line and run again; this time conn1.commit() hangs until a timeout, then a "Database is locked" error is returned.

What is the expected output? What do you see instead?

The BEGIN should be issued implicitly, and even without doing it explicitly, the commit should block and then return the DB locked error.

What version of the product are you using? On what operating system?

Python 2.6.6 with its built-in sqlite3 module, on Debian Squeeze x86.

import sqlite3
import os

if os.path.exists("file.db"):
    os.unlink("file.db")
    
conn1 = sqlite3.connect("file.db")

c1 = conn1.cursor()

c1.execute("PRAGMA read_uncommitted=SERIALIZABLE")

c1.execute("""create table foo (id integer primary key, data varchar(30))""")
c1.execute("insert into foo(id, data) values (1, 'data1')")
c1.close()
conn1.commit()

c1 = conn1.cursor()
c1.execute("select * from foo where id=1")
row1 = c1.fetchone()
c1.close()

conn2 = sqlite3.connect("file.db")
c2 = conn2.cursor()

c2.execute("PRAGMA read_uncommitted=SERIALIZABLE")

# sqlite3 should be doing this automatically.
# when called, conn1's commit blocks
#c2.execute("BEGIN")
c2.execute("select * from foo where id=1")
row2 = c2.fetchone()
c2.close()

c1 = conn1.cursor()
c1.execute("update foo set data='data2'")

print "About to commit conn1..."
conn1.commit()

----------
components: Library (Lib)
messages: 117167
nosy: zzzeek
priority: normal
severity: normal
status: open
title: sqlite3 SELECT does not BEGIN a transaction, but should according to spec
type: behavior
versions: Python 2.5, 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/issue9924>
_______________________________________

From report at bugs.python.org  Thu Sep 23 06:02:37 2010
From: report at bugs.python.org (mike bayer)
Date: Thu, 23 Sep 2010 04:02:37 +0000
Subject: [issue9924] sqlite3 SELECT does not BEGIN a transaction,
	but should according to spec
In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za>
Message-ID: <1285214557.72.0.599610833317.issue9924@psf.upfronthosting.co.za>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

My own comment here is that I'm supposing the "late BEGIN" behavior is to cut down on SQLite's file locking.    I think a way to maintain that convenience for most cases, while allowing the stricter behavior that makes SERIALIZABLE isolation worthwhile, would be an option to sqlite3.connect() that moves the implicit BEGIN to before any DQL, not just DML, statement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9924>
_______________________________________

From report at bugs.python.org  Thu Sep 23 08:36:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 23 Sep 2010 06:36:25 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1285223785.18.0.421768759989.issue9808@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Thu Sep 23 08:45:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 23 Sep 2010 06:45:16 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1285224316.08.0.572209003368.issue2175@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'll have a look.

----------
assignee: loewis -> georg.brandl
nosy: +georg.brandl
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Thu Sep 23 08:45:52 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 23 Sep 2010 06:45:52 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1285224352.19.0.894913590957.issue2193@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'll have a look.

----------
assignee: akuchling -> georg.brandl
nosy: +georg.brandl
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Thu Sep 23 08:47:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 23 Sep 2010 06:47:58 +0000
Subject: [issue9801] Can not use append/extend to lists in a multiprocessing
	manager dict
In-Reply-To: <1283973802.38.0.869176624785.issue9801@psf.upfronthosting.co.za>
Message-ID: <1285224478.16.0.172179935545.issue9801@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Changing to doc issue.

----------
components: +Documentation -Library (Lib)
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9801>
_______________________________________

From report at bugs.python.org  Thu Sep 23 09:45:41 2010
From: report at bugs.python.org (qpatata)
Date: Thu, 23 Sep 2010 07:45:41 +0000
Subject: [issue9919] gdbinit lineno result is one line in excess
In-Reply-To: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>
Message-ID: <1285227941.8.0.466872441472.issue9919@psf.upfronthosting.co.za>


qpatata <qpatata at gmail.com> added the comment:

Well, me also I'm not expert in gdb.

Solution looks nice and previous testcase now gives the correct answer.

Thanks a lot for your help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9919>
_______________________________________

From report at bugs.python.org  Thu Sep 23 10:10:35 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 23 Sep 2010 08:10:35 +0000
Subject: [issue9924] sqlite3 SELECT does not BEGIN a transaction,
	but should according to spec
In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za>
Message-ID: <1285229435.59.0.929506555057.issue9924@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ghaering
versions:  -Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9924>
_______________________________________

From report at bugs.python.org  Thu Sep 23 11:15:48 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 23 Sep 2010 09:15:48 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1285233348.79.0.367587424561.issue9920@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Thanks for the quick reply Mark.

I tried with pydebug and got the same error.

Here is the trace for your last question:

Python 3.2a2+ (py3k:84969M, Sep 23 2010, 10:55:24) [C] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> from cmath import tanh
[52276 refs]
>>> tanh(complex(-0.0, 0.0))
(-0+0j)
[52281 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Thu Sep 23 12:05:27 2010
From: report at bugs.python.org (Stephan Bellegy)
Date: Thu, 23 Sep 2010 10:05:27 +0000
Subject: [issue1743] IDLE fails to launch
In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za>
Message-ID: <1285236327.44.0.760244127859.issue1743@psf.upfronthosting.co.za>


Stephan Bellegy <stephan.bellegy at gmail.com> added the comment:

Reproduced today with Python 2.6.6 and 2.7 on Win7 32 bits.

Deleting .idlerc directory made it.

Doesn't look like fixed guys ! ;-)

----------
nosy: +Stephan.Bellegy
versions: +Python 2.6 -Python 2.5, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1743>
_______________________________________

From report at bugs.python.org  Thu Sep 23 12:19:43 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 23 Sep 2010 10:19:43 +0000
Subject: [issue9922] subprocess.getstatusoutput can fail with utf8
	UnicodeDecodeError
In-Reply-To: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>
Message-ID: <1285237183.57.0.348540643055.issue9922@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

In Python 3, subprocess.Popen returns stdout as "bytes" rather than "string" so it seems reasonable that subprocess.getstatusoutput should do the same.

>>> subprocess.Popen(['dd if=/dev/random bs=1024 count=1'], shell=True, stdout=subprocess.PIPE).communicate()[0]
1+0 records in
1+0 records out
1024 bytes transferred in 0.000142 secs (7218432 bytes/sec)
b'\x11\xfb\xe1w ...

The problem is reproducible on 3.1 and py3k.

The attached patch for py3k (with a backport to 3.1) corrects getstatusoutput to return bytes.  It also includes a test case and updates the docs to show byte output.

----------
keywords: +patch
nosy: +astrand, ned.deily
stage:  -> patch review
title: subprocess.getstatusoutput and bytes -> subprocess.getstatusoutput can fail with utf8 UnicodeDecodeError
versions: +Python 3.1
Added file: http://bugs.python.org/file18971/issue9922-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9922>
_______________________________________

From report at bugs.python.org  Thu Sep 23 12:20:03 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 23 Sep 2010 10:20:03 +0000
Subject: [issue9922] subprocess.getstatusoutput can fail with utf8
	UnicodeDecodeError
In-Reply-To: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>
Message-ID: <1285237203.11.0.0643420999174.issue9922@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file18972/issue9922-31.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9922>
_______________________________________

From report at bugs.python.org  Thu Sep 23 12:20:33 2010
From: report at bugs.python.org (strank)
Date: Thu, 23 Sep 2010 10:20:33 +0000
Subject: [issue1175004] Export more libreadline API functions
Message-ID: <1285237233.53.0.77648082659.issue1175004@psf.upfronthosting.co.za>


Changes by strank <strank at strank.info>:


----------
nosy: +strank

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1175004>
_______________________________________

From report at bugs.python.org  Thu Sep 23 12:34:04 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Thu, 23 Sep 2010 10:34:04 +0000
Subject: [issue9582] documentation line needs rewording
In-Reply-To: <1281650622.86.0.310513887463.issue9582@psf.upfronthosting.co.za>
Message-ID: <1285238044.56.0.252381964721.issue9582@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

uploaded patch. 

patch could be applied to 2.7-maint and p3k successfuly. single word insert.

----------
nosy: +ruseel
Added file: http://bugs.python.org/file18973/issue9582.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9582>
_______________________________________

From report at bugs.python.org  Thu Sep 23 12:34:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 23 Sep 2010 10:34:34 +0000
Subject: [issue1743] IDLE fails to launch
In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za>
Message-ID: <1285238074.59.0.206039577517.issue1743@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please submit this as a new bug issue, preferably with precise instructions on how to reproduce it. Can you provide some clue how the file became hidden in the first place?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1743>
_______________________________________

From report at bugs.python.org  Thu Sep 23 12:36:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Sep 2010 10:36:23 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1285238183.07.0.773949712605.issue9920@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks;  so it's probably not an optimization bug, but rather a math library bug somewhere.

And thanks for the tanh result;  unfortunately I asked the wrong question---I meant to ask about atanh(complex(-0.0, 0.0)) :(

Analysis: atan(z) is computed internally as atanh(iz) / i.  So if the imaginary part of atan is coming out wrong, it's probably because the real part of atanh is incorrect.  So I'd expect atanh(complex(-0.0, 0.0)) to produce 0.0j (instead of the correct answer of -0.0 + 0.0j).

The real part of atanh(x + iy) is computed (for a region of the complex plane containing 0.0) using the formula:

    real_part = log1p(4.*z.real/((1-z.real)*(1-z.real) + z.imag * z.imag))/4.;

My best guess is that the log1p function is dropping the sign on a negative zero.  But in that case I'd expect test_math to fail on your system, too.

Could you try the following experiments, and let me know what you get?  (Feel free to stop as soon as your results start to differ from what's below.)

>>> import math, cmath
>>> math.log1p(-0.0)
-0.0
>>> z = complex(-0.0, 0.0)
>>> 4. * z.real
-0.0
>>> (1 - z.real) * (1 - z.real) + z.imag * z.imag
1.0
>>> 4. * z.real / ((1 - z.real) * (1 - z.real) + z.imag * z.imag)
-0.0
>>> math.log1p(4. * z.real / ((1 - z.real) * (1 - z.real) + z.imag * z.imag))
-0.0
>>> math.log1p(4. * z.real / ((1 - z.real) * (1 - z.real) + z.imag * z.imag)) / 4.
-0.0
>>> cmath.atanh(z).real
-0.0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Thu Sep 23 12:44:48 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Thu, 23 Sep 2010 10:44:48 +0000
Subject: [issue9924] sqlite3 SELECT does not BEGIN a transaction,
	but should according to spec
In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za>
Message-ID: <1285238688.95.0.574846537012.issue9924@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Yes Mike. Avoiding unnecessary locks was exactly the reason for this behaviour. I agree that for serializable transactions I'd need to make some changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9924>
_______________________________________

From report at bugs.python.org  Thu Sep 23 13:03:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Sep 2010 11:03:25 +0000
Subject: [issue9922] subprocess.getstatusoutput can fail with utf8
	UnicodeDecodeError
In-Reply-To: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>
Message-ID: <1285239805.92.0.845213508089.issue9922@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9922>
_______________________________________

From report at bugs.python.org  Thu Sep 23 13:36:01 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 23 Sep 2010 11:36:01 +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: <1285241761.69.0.313189849546.issue9890@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Can you try to open a Command Prompt and type (with the quotes):
    "C:\Program Files\Python\python.exe" "C:\Program Files\Python\Lib\idle\idle.py" 
Do you see error messages?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9890>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:15:45 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 23 Sep 2010 13:15:45 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1285247745.32.0.724516293254.issue9920@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

No problem; I tried with a different compiler this time (gcc instead of xlc) and with -O0 just to be sure it is not a compiler issue. I had the same error.

I tried your test and you are right, the problem happens with log1p dropping the sign:

>>> import math, cmath
[52601 refs]
>>> math.log1p(-0.0)
0.0

I also tried test_math but it seems to work fine:

> ./python -E ./Lib/test/test_math.py 
testAcos (__main__.MathTests) ... ok
testAcosh (__main__.MathTests) ... ok
testAsin (__main__.MathTests) ... ok
testAsinh (__main__.MathTests) ... ok
testAtan (__main__.MathTests) ... ok
testAtan2 (__main__.MathTests) ... ok
testAtanh (__main__.MathTests) ... ok
testCeil (__main__.MathTests) ... ok
testConstants (__main__.MathTests) ... ok
testCopysign (__main__.MathTests) ... ok
testCos (__main__.MathTests) ... ok
testCosh (__main__.MathTests) ... ok
testDegrees (__main__.MathTests) ... ok
testExp (__main__.MathTests) ... ok
testFabs (__main__.MathTests) ... ok
testFactorial (__main__.MathTests) ... ok
testFloor (__main__.MathTests) ... ok
testFmod (__main__.MathTests) ... ok
testFrexp (__main__.MathTests) ... ok
testFsum (__main__.MathTests) ... ok
testHypot (__main__.MathTests) ... ok
testIsfinite (__main__.MathTests) ... ok
testIsinf (__main__.MathTests) ... ok
testIsnan (__main__.MathTests) ... ok
testLdexp (__main__.MathTests) ... ok
testLog (__main__.MathTests) ... ok
testLog10 (__main__.MathTests) ... ok
testLog1p (__main__.MathTests) ... ok
testModf (__main__.MathTests) ... ok
testPow (__main__.MathTests) ... ok
testRadians (__main__.MathTests) ... ok
testSin (__main__.MathTests) ... ok
testSinh (__main__.MathTests) ... ok
testSqrt (__main__.MathTests) ... ok
testTan (__main__.MathTests) ... ok
testTanh (__main__.MathTests) ... ok
test_exceptions (__main__.MathTests) ... ok
test_mtestfile (__main__.MathTests) ... ok
test_testfile (__main__.MathTests) ... ok
test_trunc (__main__.MathTests) ... ok
./Lib/test/ieee754.txt
Doctest: ieee754.txt ... ok

----------------------------------------------------------------------
Ran 41 tests in 10.467s

OK

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:19:17 2010
From: report at bugs.python.org (Randall Nortman)
Date: Thu, 23 Sep 2010 13:19:17 +0000
Subject: [issue9924] sqlite3 SELECT does not BEGIN a transaction,
	but should according to spec
In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za>
Message-ID: <1285247957.63.0.463050374066.issue9924@psf.upfronthosting.co.za>


Changes by Randall Nortman <rnpythonbugs at wonderclown.net>:


----------
nosy: +rnortman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9924>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:34:33 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 23 Sep 2010 13:34:33 +0000
Subject: [issue9868] test_locale leaves locale changed
In-Reply-To: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>
Message-ID: <1285248873.95.0.467311991329.issue9868@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

unittest *can't* know which setUp methods have already been called if an error occurs in one of them (because they are called explicitly by the sub-classes and not by unittest itself). Given this, the specific fix suggested seems good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9868>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:46:14 2010
From: report at bugs.python.org (Stephan Bellegy)
Date: Thu, 23 Sep 2010 13:46:14 +0000
Subject: [issue9925] Idle doesn't launch
In-Reply-To: <1285249574.15.0.491090079116.issue9925@psf.upfronthosting.co.za>
Message-ID: <1285249574.15.0.491090079116.issue9925@psf.upfronthosting.co.za>


New submission from Stephan Bellegy <stephan.bellegy at gmail.com>:

Environment is Win7, 32bits. User has Admin rights.

I haven't coded in Python at the office for a while and had a little script to write. Thus, I decided to upgrade from 2.6 to 2.7 (that is : 2.6 was already there and functionnal as far as I remind it and was the first install of Python on the new PC)

2.7 installation run without problems nor warnings, as usual.
But then Idle didn't launch. No message. No Python process running in the background. So I launched it via a shell and grabbed an error message :
IOError: [Errno 13] Permission denied: 'C:\\Users\\Foobar\\.idlerc\\recent-files.lst'

Then I googled and found http://bugs.python.org/issue1743

Deleting ~\.idlerc\ did the trick and now Idle runs fine.

So the bug 1743 isn't clearly solved and this is what I suspect :
My Windows is localized in French. From the DOS Shell, the User Dir is C:\Users\FOOBAR
but Windows Explorer displays in its address bar : C:\Utilisateurs\FOOBAR
Maybe the problem comes from here ?

----------
components: IDLE, Installation
messages: 117184
nosy: Stephan.Bellegy
priority: normal
severity: normal
status: open
title: Idle doesn't launch
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9925>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:46:54 2010
From: report at bugs.python.org (Stephan Bellegy)
Date: Thu, 23 Sep 2010 13:46:54 +0000
Subject: [issue1743] IDLE fails to launch
In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za>
Message-ID: <1285249614.58.0.223909981675.issue1743@psf.upfronthosting.co.za>


Stephan Bellegy <stephan.bellegy at gmail.com> added the comment:

New bug reported here
http://bugs.python.org/issue9925

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1743>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:48:07 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 13:48:07 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285249687.57.0.751555772813.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Hello. Probably I found the better solution for this issue.

* build_ssl.py always runs before _ssl.vcproj or _hashlib.vcproj
  is built. (If entire solution is built, run only onece)

* When OpenSSL sources are modified, because build_ssl.py always runs,
  correctly OpenSSL are rebuilt.

* Module/_ssl.c or Module/_hashlib.c are rebuilt if they or
  include files refereed by them are not modified.

Can you try this? (Only Debug|Win32 and Release|Win32 are implemented)

----------
Added file: http://bugs.python.org/file18974/py3k_better_build_ssl.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:48:32 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 13:48:32 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285249712.88.0.804323134291.issue9552@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
resolution: fixed -> 
status: closed -> open
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:48:50 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 23 Sep 2010 13:48:50 +0000
Subject: [issue9582] documentation line needs rewording
In-Reply-To: <1281650622.86.0.310513887463.issue9582@psf.upfronthosting.co.za>
Message-ID: <1285249730.96.0.957104315556.issue9582@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed in r84971 and r84972. Thanks.

----------
assignee: docs at python -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9582>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:50:29 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 13:50:29 +0000
Subject: [issue5497] openssl compileerror with original source
In-Reply-To: <1237272241.76.0.44185655243.issue5497@psf.upfronthosting.co.za>
Message-ID: <1285249829.75.0.809925070961.issue5497@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

PCBuild on py3k have fix for this. We'll need to 
investigate/merge in other branches and version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5497>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:54:09 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 13:54:09 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285250049.42.0.890263115458.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

- Module/_ssl.c or Module/_hashlib.c are rebuilt
+ Module/_ssl.c or Module/_hashlib.c won't be rebuilt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:57:52 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 23 Sep 2010 13:57:52 +0000
Subject: [issue9582] documentation line needs rewording
In-Reply-To: <1281650622.86.0.310513887463.issue9582@psf.upfronthosting.co.za>
Message-ID: <1285250272.96.0.580263720937.issue9582@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9582>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:18:36 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 14:18:36 +0000
Subject: [issue9868] test_locale leaves locale changed
In-Reply-To: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>
Message-ID: <1285251516.49.0.240389947992.issue9868@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> unittest *can't* know which setUp methods have already been called if
> an error occurs in one of them (because they are called explicitly by
> the sub-classes and not by unittest itself).

Well, C++ constructor/destructor behaves like that when constructor
of subclass raised exception. Destructors of super classes are called
in reverse order. The benefit of it is implementator of subclass
don't have to care about finalization of super class. It is done
automatically. But if explicit call is essential for us, my proposal
is not needed.

> Given this, the specific fix suggested seems good.
Thanks, I'll commit this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9868>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:21:48 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 23 Sep 2010 14:21:48 +0000
Subject: [issue9868] test_locale leaves locale changed
In-Reply-To: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>
Message-ID: <1285251708.47.0.29873532131.issue9868@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Destructors are special cased in many languages and tearDown is not a destructor. More importantly though the change you suggest would be backwards incompatible.

The 'correct' way to do this in new code is to use cleanUp functions which *are* called even if an exception is raised during setUp.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9868>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:24:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Sep 2010 14:24:34 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285251874.05.0.0596641738388.issue678250@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file18953/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:24:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Sep 2010 14:24:39 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285251879.11.0.920872229166.issue678250@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file18954/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:24:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Sep 2010 14:24:42 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285251882.02.0.914644817556.issue678250@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file18955/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:24:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Sep 2010 14:24:44 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285251884.61.0.512886669532.issue678250@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file18956/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:24:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Sep 2010 14:24:47 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1285251887.67.0.866427542087.issue678250@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file18957/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:32:48 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 23 Sep 2010 14:32:48 +0000
Subject: [issue9926] Wrapped TestSuite subclass does not get __call__ executed
In-Reply-To: <1285252368.31.0.189981048833.issue9926@psf.upfronthosting.co.za>
Message-ID: <1285252368.31.0.189981048833.issue9926@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

In Python 3.2, when inheriting from TestSuite, it is no longer possible to override __call__ (e.g. to introduce a TestSuite setUp and tearDown).
The __call__ method will not be called anymore.

Instead, if the object has a _wrapped_run defined (which it will, since it inherits from TestSuite), then this is called instead. Overriding _wrapped_run is a work-around, however, this being a private method, overriding it is probably not a good idea.

----------
assignee: michael.foord
messages: 117192
nosy: loewis, michael.foord
priority: normal
severity: normal
status: open
title: Wrapped TestSuite subclass does not get __call__ executed
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9926>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:39:09 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 23 Sep 2010 14:39:09 +0000
Subject: [issue9925] Idle doesn't launch
In-Reply-To: <1285249574.15.0.491090079116.issue9925@psf.upfronthosting.co.za>
Message-ID: <1285252749.67.0.104433047025.issue9925@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Is that problem reproducible?

I.e. what did you do, in what order, and: when you do it again, will the problem occur again?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9925>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:50:28 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 14:50:28 +0000
Subject: [issue9868] test_locale leaves locale changed
In-Reply-To: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>
Message-ID: <1285253428.72.0.169448863551.issue9868@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> Destructors are special cased in many languages and tearDown is not a
> destructor.

Yes, but they are similar.

> More importantly though the change you suggest would be
> backwards incompatible.

> The 'correct' way to do this in new code is to use cleanUp functions
> which *are* called even if an exception is raised during setUp.

I must admit I'm not familiar with unittest framework. Probably
better way exists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9868>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:54:41 2010
From: report at bugs.python.org (Brian Bernstein)
Date: Thu, 23 Sep 2010 14:54:41 +0000
Subject: [issue5762] AttributeError: 'NoneType' object has no attribute
	'replace'
In-Reply-To: <1239798874.6.0.325655580097.issue5762@psf.upfronthosting.co.za>
Message-ID: <1285253681.42.0.293413757764.issue5762@psf.upfronthosting.co.za>


Brian Bernstein <bernie9998 at gmail.com> added the comment:

Experiencing this issue too.  It occurs when an xml element contains a blank xmlns attribute, e.g.:

{{{
<element xmlns=""/>
}}}

When toxml() is called on a minidom document with this attribute, the exception occurs.

I am including a simple script that causes this crash.

----------
nosy: +bernie9998
Added file: http://bugs.python.org/file18975/minidomcrash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5762>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:57:21 2010
From: report at bugs.python.org (Brian Bernstein)
Date: Thu, 23 Sep 2010 14:57:21 +0000
Subject: [issue5762] AttributeError: 'NoneType' object has no attribute
	'replace'
In-Reply-To: <1239798874.6.0.325655580097.issue5762@psf.upfronthosting.co.za>
Message-ID: <1285253841.06.0.20272817147.issue5762@psf.upfronthosting.co.za>


Changes by Brian Bernstein <bernie9998 at gmail.com>:


----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5762>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:16:40 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Thu, 23 Sep 2010 15:16:40 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285255000.46.0.0573268531204.issue6608@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

As alexandre.vassalotti pointed in msg107596, I added precondition check.

 * extracted the range check from time_strftime as "is_valid_tm".
 * time_asctime, time_strftime call "is_valid_tm"

 * testcase for both asctime and strftime (abbeyj's work)

I splited patch just for unittest files(Lib/test/test_time.py) and (Modules/timemodule.c)

----------
keywords: +patch
nosy: +ruseel
Added file: http://bugs.python.org/file18976/issue6608-timemodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:16:57 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Thu, 23 Sep 2010 15:16:57 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285255017.11.0.0870558668214.issue6608@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


Added file: http://bugs.python.org/file18977/issue6608-timemodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:17:10 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Thu, 23 Sep 2010 15:17:10 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285255030.98.0.344459713579.issue6608@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


Removed file: http://bugs.python.org/file18977/issue6608-timemodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:17:30 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Thu, 23 Sep 2010 15:17:30 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285255050.9.0.950298491142.issue6608@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


Added file: http://bugs.python.org/file18978/issue6608-testcase.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:39:08 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 15:39:08 +0000
Subject: [issue9927] Leak around GetFinalPathNameByHandle (Windows)
In-Reply-To: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>
Message-ID: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I've found there are leaks around GetFinalPathNameByHandle in
Modules/posixmodule.c. (Leaks when function fails)

I hope attached patch will fix this.

----------
components: Windows
files: py3k_fix_leak_around_GetFinalPathNameByHandle.patch
keywords: patch
messages: 117197
nosy: ocean-city
priority: normal
severity: normal
status: open
title: Leak around GetFinalPathNameByHandle (Windows)
versions: Python 3.2
Added file: http://bugs.python.org/file18979/py3k_fix_leak_around_GetFinalPathNameByHandle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9927>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:46:45 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 23 Sep 2010 15:46:45 +0000
Subject: [issue9926] Wrapped TestSuite subclass does not get __call__ executed
In-Reply-To: <1285252368.31.0.189981048833.issue9926@psf.upfronthosting.co.za>
Message-ID: <1285256805.92.0.256732788553.issue9926@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Right, _wrapped_run is private and not intended to be overridden. 

Perhaps slightly ironically (for this particular bug report) is that the change was introduced to support class and module level setUp and tearDown (similar to the use-case it now blocks).

Another workaround would be to inherit from BaseTestSuite (which would disable the class and module level fixture support).

A backwards compatible change would be to rename BaseTestSuite *back* to TestSuite and give the current TestSuite a new name. This means that the new class / module level fixtures would only be supported in code that gets suites from the TestLoader (which uses the new class) or by creating suites using the new class.

The disadvantage of this approach is that it is not uncommon for test frameworks to create suites themselves - and doing this could 'break' tests using class / module fixtures.

The reason for the change is that in order to tearDown the final class and module level fixtures we need to know when we exit the 'top level' of a run from inside a suite.

Any other suggestions or ideas?

(Another idea is to add explicit setUp and tearDown hooks to the TestSuite object. This isn't backwards compatible but meets the direct use case. Obviously backwards compatibility is greatly preferable.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9926>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:46:49 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 15:46:49 +0000
Subject: [issue9927] Leak around GetFinalPathNameByHandle (Windows)
In-Reply-To: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>
Message-ID: <1285256809.86.0.152362460607.issue9927@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

About buffer size, GetFinalPathNameByHandle may return the
length or string or the size of required buffer size (the
length of striing + 1) depending on platforms and ANSI/WIDE
version.

If function returns the length of string buffer size,
buf_size + 1 is buffer size. MSDN saids

  cchFilePath [in]

      The size of lpszFilePath, in TCHARs. This value does not include a NULL termination character.

so we must pass buf_size + 1 for GetFinalPathNameByHandle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9927>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:47:26 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 15:47:26 +0000
Subject: [issue9927] Leak around GetFinalPathNameByHandle (Windows)
In-Reply-To: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>
Message-ID: <1285256846.92.0.865787667054.issue9927@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
Removed message: http://bugs.python.org/msg117199

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9927>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:48:21 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 23 Sep 2010 15:48:21 +0000
Subject: [issue9927] Leak around GetFinalPathNameByHandle (Windows)
In-Reply-To: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>
Message-ID: <1285256901.22.0.162242650741.issue9927@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Extension Modules
nosy: +brian.curtin, jaraco
stage:  -> patch review
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9927>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:50:07 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 15:50:07 +0000
Subject: [issue9927] Leak around GetFinalPathNameByHandle (Windows)
In-Reply-To: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>
Message-ID: <1285257007.02.0.140693480588.issue9927@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I cannot test this directly. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9927>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:51:05 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 23 Sep 2010 15:51:05 +0000
Subject: [issue9926] Wrapped TestSuite subclass does not get __call__ executed
In-Reply-To: <1285252368.31.0.189981048833.issue9926@psf.upfronthosting.co.za>
Message-ID: <1285257065.1.0.741453443137.issue9926@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Hmmm... 2.7 has already been released and has the same issue, so 'drastic' changes (like renaming BaseTestSuite back to TestSuite) are probably out.

----------
components: +Library (Lib)
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9926>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:52:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 23 Sep 2010 15:52:18 +0000
Subject: [issue9919] gdbinit lineno result is one line in excess
In-Reply-To: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>
Message-ID: <1285257138.58.0.00678710274283.issue9919@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: +Demos and Tools
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9919>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:55:46 2010
From: report at bugs.python.org (James Hutchison)
Date: Thu, 23 Sep 2010 15:55:46 +0000
Subject: [issue9801] Can not use append/extend to lists in a multiprocessing
	manager dict
In-Reply-To: <1283973802.38.0.869176624785.issue9801@psf.upfronthosting.co.za>
Message-ID: <1285257346.66.0.401611660322.issue9801@psf.upfronthosting.co.za>


James Hutchison <jamesghutchison at gmail.com> added the comment:

Is there a way to get this so it behaves more intuitively? You'd think adding a managed list to a managed dictionary (or another managed list) or making a deep copy would work but it still doesn't. When you get an item from a managed data structure, it seems to be returning a data-only copy of the object instead of a handle to the manager of the object. The fact that += (extend) works but .extend() doesn't work also seems to raise a flag for me (although I do understand why this is). I don't think it should behave this way.

i.e.:
currently:
d['l'] -> return copy.deepcopy(d['l'])

should be:
d['l'] -> return managerObject(d['l'])
where managerObject is a managed object that runs on the same process as the manager it came from

Problem: Currently there is no easy way to do random access without copying out and copying back in. I'd think that would be a real efficiency problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9801>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:59:54 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 15:59:54 +0000
Subject: [issue9287] Minor fix in test_file2k.OtherFileTests.testOpenDir
In-Reply-To: <1279377543.77.0.675008772529.issue9287@psf.upfronthosting.co.za>
Message-ID: <1285257594.0.0.376531010576.issue9287@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've committed your fix in r84975. Thank you.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9287>
_______________________________________

From report at bugs.python.org  Thu Sep 23 18:08:16 2010
From: report at bugs.python.org (Stephan Bellegy)
Date: Thu, 23 Sep 2010 16:08:16 +0000
Subject: [issue9925] Idle doesn't launch
In-Reply-To: <1285249574.15.0.491090079116.issue9925@psf.upfronthosting.co.za>
Message-ID: <1285258096.38.0.326857074991.issue9925@psf.upfronthosting.co.za>


Stephan Bellegy <stephan.bellegy at gmail.com> added the comment:

it is reproductible.
At first, Python 2.6.? was installed.

i tried to install 2.7 and got the problem
uninstalled 2.7
tried 2.6.6 and got the problem

then google, delete dir and got it running

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9925>
_______________________________________

From report at bugs.python.org  Thu Sep 23 18:14:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 23 Sep 2010 16:14:36 +0000
Subject: [issue9927] Leak around GetFinalPathNameByHandle (Windows)
In-Reply-To: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>
Message-ID: <1285258476.7.0.879048091372.issue9927@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The tests pass here, but I haven't thoroughly reviewed the patch yet. After a quick glance it generally looks ok, although I wish we didn't have so much duplication.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9927>
_______________________________________

From report at bugs.python.org  Thu Sep 23 18:14:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 23 Sep 2010 16:14:39 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285258479.9.0.343415440133.issue6608@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The patch looks good to me.  Just a few nitpicks: the local convention seems to be no underscores in helper functions such as gettmarg.  I would call is_valid_tm, "checktm" instead.  Also, predicate-like naming (is_...) suggests a function without side-effects, while is_valid_tm sets an error when it gets an invalid tm.  Also, please add missing comments above gettmarg and is_valid_tm.  Finally, please start the function body with a "{" on a new line.  Thank you for your submission.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Thu Sep 23 18:24:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Sep 2010 16:24:50 +0000
Subject: [issue1675951] Performance for small reads and fix seek problem
Message-ID: <1285259090.64.0.700701519487.issue1675951@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you very much! I have kept the second approach (use PaddedFile at all times), since it is more regular and minimizes the probability for borderline cases.
As for the supposed performance slowdown, it doesn't seem significant. On large blocks of data, I expect that compression/decompression cost will be overwhelming anyway.
I've added a test case and committed the patch in r84976. Don't hesitate to contribute again.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Thu Sep 23 18:56:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Sep 2010 16:56:47 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1285261007.95.0.209682595913.issue9360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, unescaped utf-8 is explicitly allowed in headers by RFC 3977:

   The content of a header SHOULD be in UTF-8.  However, if an
   implementation receives an article from elsewhere that uses octets in
   the range 128 to 255 in some other manner, it MAY pass it to a client
   or server without modification.  Therefore, implementations MUST be
   prepared to receive such headers, and data derived from them (e.g.,
   in the responses from the OVER command, Section 8.3), and MUST NOT
   assume that they are always UTF-8.

(I guess this means NNTP is now more modern than SMTP :-)).

Actually, there's a test with an actual utf-8 header in the unit tests.
(as for ?implementations MUST be prepared to receive such headers, and data derived from them?, this is accounted for by using surrogateescape).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Thu Sep 23 19:27:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Sep 2010 17:27:44 +0000
Subject: [issue9272] CGIHTTPServer poisons os.environ
In-Reply-To: <1279270191.51.0.568678636745.issue9272@psf.upfronthosting.co.za>
Message-ID: <1285262864.3.0.316060906303.issue9272@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Anatoly, last we heard you did not wish to sign the contributor agreement and so were not submitting patches.  We are respecting your wishes by not applying this.  Have you changed your mind?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9272>
_______________________________________

From report at bugs.python.org  Thu Sep 23 19:44:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Sep 2010 17:44:20 +0000
Subject: [issue9928] weird oddity with bz2 context manager
In-Reply-To: <1285263860.75.0.0295269513822.issue9928@psf.upfronthosting.co.za>
Message-ID: <1285263860.75.0.0295269513822.issue9928@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I haven't investigated but this is weird (especially the fact that it doesn't *always* happen). There might be a problem with SETUP_WITH or perhaps the method cache:

>>> import bz2
>>> f = bz2.BZ2File('foo.bz2', 'wb')
>>> with f: pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __exit__
>>> f.__enter__().__exit__(None, None, None)
>>>

----------
components: Interpreter Core, Library (Lib)
messages: 117210
nosy: amaury.forgeotdarc, arigo, benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: weird oddity with bz2 context manager
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9928>
_______________________________________

From report at bugs.python.org  Thu Sep 23 19:56:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Sep 2010 17:56:18 +0000
Subject: [issue9928] weird oddity with bz2 context manager
In-Reply-To: <1285263860.75.0.0295269513822.issue9928@psf.upfronthosting.co.za>
Message-ID: <1285264578.38.0.857461575797.issue9928@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, it is because bz2 doesn't call PyType_Ready() but instead sets some field manually. Perhaps we could have a guard somewhere that raises a fatal error when a C extension type hasn't been properly readied?

In the meantime, this patch seems to solve the issue:

diff -r 843be379fb26 Modules/bz2module.c
--- a/Modules/bz2module.c       Thu Sep 23 18:45:17 2010 +0200
+++ b/Modules/bz2module.c       Thu Sep 23 19:55:19 2010 +0200
@@ -2155,9 +2155,12 @@ PyInit_bz2(void)
 {
     PyObject *m;
 
-    Py_TYPE(&BZ2File_Type) = &PyType_Type;
-    Py_TYPE(&BZ2Comp_Type) = &PyType_Type;
-    Py_TYPE(&BZ2Decomp_Type) = &PyType_Type;
+    if (PyType_Ready(&BZ2File_Type) < 0)
+        return NULL;
+    if (PyType_Ready(&BZ2Comp_Type) < 0)
+        return NULL;
+    if (PyType_Ready(&BZ2Decomp_Type) < 0)
+        return NULL;
 
     m = PyModule_Create(&bz2module);
     if (m == NULL)

----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9928>
_______________________________________

From report at bugs.python.org  Thu Sep 23 20:06:33 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 23 Sep 2010 18:06:33 +0000
Subject: [issue9928] weird oddity with bz2 context manager
In-Reply-To: <1285264578.38.0.857461575797.issue9928@psf.upfronthosting.co.za>
Message-ID: <AANLkTike76mp-LRCm1nCmhEaZOGtG_nUOdM9cZfpjdx3@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/9/23 Antoine Pitrou <report at bugs.python.org>:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Actually, it is because bz2 doesn't call PyType_Ready() but instead sets some field manually. Perhaps we could have a guard somewhere that raises a fatal error when a C extension type hasn't been properly readied?

The problem is that there's no one entry point for types to get into
the C-API. I suppose we could iterate through a c-module's dictionary
after it's initialized...

>
> In the meantime, this patch seems to solve the issue:

Please apply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9928>
_______________________________________

From report at bugs.python.org  Thu Sep 23 20:15:42 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 18:15:42 +0000
Subject: [issue9929] subprocess.Popen unbuffered not work (windows)
In-Reply-To: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>
Message-ID: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Following script hangs on Python3.x.

from subprocess import *
import sys

p = Popen([sys.executable, "-c", "import sys; print(sys.stdin.read(1))"], stdin=PIPE)
p.stdin.write(b'x')
p.wait()

This is because unbuffered functionality of
subprocess.Popen is disabled. Is this still needed?

I confirmed test_subprocess passes with the attached
patch.

----------
components: Windows
files: py3k_fix_unbuffered_in_subprocess.patch
keywords: patch
messages: 117213
nosy: ocean-city
priority: normal
severity: normal
status: open
title: subprocess.Popen unbuffered not work (windows)
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18980/py3k_fix_unbuffered_in_subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9929>
_______________________________________

From report at bugs.python.org  Thu Sep 23 20:23:22 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 18:23:22 +0000
Subject: [issue9929] subprocess.Popen unbuffered not work (windows)
In-Reply-To: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>
Message-ID: <1285266202.04.0.776571234765.issue9929@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Interestingly, following code also hangs. Maybe I'm
misunderstanding the meaning of *bufsize*....

from subprocess import *
import sys

p = Popen([sys.executable, "-c", "import sys; print(sys.stdin.read(1))"], stdin=PIPE)
p.stdin.write(b'xx') # size 2
p.wait()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9929>
_______________________________________

From report at bugs.python.org  Thu Sep 23 20:27:53 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 23 Sep 2010 18:27:53 +0000
Subject: [issue9272] CGIHTTPServer poisons os.environ
In-Reply-To: <1279270191.51.0.568678636745.issue9272@psf.upfronthosting.co.za>
Message-ID: <1285266473.11.0.248205650749.issue9272@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I still haven't received answers on the licensing questions in developer's mailing list. After the amount of negative feedback received I decided not to continue. But I am still interested in constructive discussion to get satisfying and full answers to the questions I've asked. You should understand that I can not sign agreements which terms are not clear to me, or if I think that other party fails to fulfill the conditions.

I see the contributor's agreement text is changed again, but there is no history of changes, and no electronic signature, and looking through the text I still can't find it to be clear.

As for this patch - I hereby release it into public domain, or if copyright law in your country doesn't allow that - I hereby grant you the right to use it on the terms of ISC license or WTFP license.

If you still can't use the patch and can't explain me why the paragraph above is not enough, it is still possible to resolve the situation if you have some contacts at Google. I can submit my patch to Google and they'll send it to you. This will work, because I've signed http://code.google.com/legal/individual-cla-v1.0.html But this won't work if they didn't sign your form, of course.


P.S. I want to see Python more open for contributions as well as you, but with more attention to details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9272>
_______________________________________

From report at bugs.python.org  Thu Sep 23 20:39:52 2010
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 23 Sep 2010 18:39:52 +0000
Subject: [issue9930] Incorrect semantics of __radd__ method for builtin types
In-Reply-To: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>
Message-ID: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>


New submission from Mark Shannon <marks at dcs.gla.ac.uk>:

Attached program fails.
See comments in file for details and possible diagnosis

----------
files: binary_op_mimic.py
messages: 117216
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Incorrect semantics of __radd__ method for builtin types
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18981/binary_op_mimic.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9930>
_______________________________________

From report at bugs.python.org  Thu Sep 23 20:46:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 23 Sep 2010 18:46:48 +0000
Subject: [issue9272] CGIHTTPServer poisons os.environ
In-Reply-To: <1279270191.51.0.568678636745.issue9272@psf.upfronthosting.co.za>
Message-ID: <1285267608.29.0.298512636531.issue9272@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

ISTM that the attached patch is trivial enough not to require any contributor agreement or copyright assignment, at least if we change "Ma Test CGI Server v1.0" to something neutral.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9272>
_______________________________________

From report at bugs.python.org  Thu Sep 23 20:56:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Sep 2010 18:56:15 +0000
Subject: [issue9930] Incorrect semantics of __radd__ method for builtin types
In-Reply-To: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>
Message-ID: <1285268175.69.0.114483039185.issue9930@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Could you post some simple examples and an explanation of what you think the problem is?  I have no clue what problem your code is trying to show just by looking at it.  (Maybe it will be clear to someone else, but still, simple examples are usually better, and easier to turn into unit tests.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9930>
_______________________________________

From report at bugs.python.org  Thu Sep 23 21:12:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 23 Sep 2010 19:12:06 +0000
Subject: [issue9930] Incorrect semantics of __radd__ method for builtin types
In-Reply-To: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>
Message-ID: <1285269126.06.0.442755481312.issue9930@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is indeed weird.  PyNumber_Add ends up calling compare_add with the float as its first argument, which is impossible to do from Python.  And the wrap_binaryfunc_r check for subtypes means that compare.__radd__ claims it doesn't support floats either.  So from Python, it's impossible to add floats and complex numbers via __special__ methods :)

Maybe Mark wants to shed some light?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9930>
_______________________________________

From report at bugs.python.org  Thu Sep 23 21:14:51 2010
From: report at bugs.python.org (Brian Brazil)
Date: Thu, 23 Sep 2010 19:14:51 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1285269291.45.0.185788006973.issue9921@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

The behaviour is a bit more nuanced:
>>> os.path.join('x', '')
'x/'
>>> os.path.join('x', '', 'y')
'x/y'
>>> os.path.join('x', '', 'y', '', '')
'x/y/'
>>> os.path.join('', 'x')
'x'

I'm unsure how to word this best, maybe "non-trailing empty paths are ignored"?

----------
nosy: +bbrazil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Thu Sep 23 21:23:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Sep 2010 19:23:03 +0000
Subject: [issue9930] Incorrect semantics of __radd__ method for builtin types
In-Reply-To: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>
Message-ID: <1285269783.74.0.176165179563.issue9930@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

If I understand correctly, the complaint is that (for example) in Python 3.x, we have:

Python 3.1.2 (r312:79147, Aug 20 2010, 20:06:00) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> float.__radd__(3.0, 1)
NotImplemented

while in Python 2.x:

Python 2.6.6 (r266:84292, Aug 28 2010, 18:05:46) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> float.__radd__(3.0, 1)
4.0

It's not clear to me whether there's any good reason for this change.



(I'm deliberately avoiding the original float + complex example, since complex is a little peculiar in 2.x for x <= 6 anyway---it's treated as an 'old-style' number (not to be confused with an old-style class)).

(Changing versions:  2.5 and 2.6 aren't getting bugfixes any more, and 2.7 appears to be behaving correctly.)

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9930>
_______________________________________

From report at bugs.python.org  Thu Sep 23 21:25:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Sep 2010 19:25:22 +0000
Subject: [issue9930] Incorrect semantics of __radd__ method for builtin types
In-Reply-To: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>
Message-ID: <1285269922.26.0.826658862822.issue9930@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9930>
_______________________________________

From report at bugs.python.org  Thu Sep 23 21:31:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Sep 2010 19:31:18 +0000
Subject: [issue9930] Incorrect semantics of __radd__ method for builtin types
In-Reply-To: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>
Message-ID: <1285270278.21.0.459065319461.issue9930@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> PyNumber_Add ends up calling compare_add with the float as its first
> argument, which is impossible to do from Python.

[Assuming you mean complex_add.]  I think this bit is expected, though.  complex_add (or float_add, or whatever) provides both the __add__ and __radd__ methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9930>
_______________________________________

From report at bugs.python.org  Thu Sep 23 21:35:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 23 Sep 2010 19:35:43 +0000
Subject: [issue9930] Incorrect semantics of __radd__ method for builtin types
In-Reply-To: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>
Message-ID: <1285270543.34.0.921081247541.issue9930@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, not sure.  I'm referring to Objects/abstract.c, binary_op1, which tries to call both slotv and slotw.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9930>
_______________________________________

From report at bugs.python.org  Thu Sep 23 21:50:05 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 19:50:05 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remove dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1285271405.29.0.499387846204.issue9815@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Thu Sep 23 21:50:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Sep 2010 19:50:26 +0000
Subject: [issue9930] Incorrect semantics of __radd__ method for builtin types
In-Reply-To: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>
Message-ID: <1285271426.43.0.562174618581.issue9930@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It looks like Mark is right:  the wrap_binaryfunc_r subtype check should just be removed.  The corresponding check in 2.x only occurs for types which don't have the Py_TPFLAGS_CHECKTYPES flag set.  As of 2.7, *all* of the numeric types have this flag set (in 2.6, the complex type doesn't).

I'm not seeing any (relevant) test failures here after removing the check.
Actually, I'm not seeing any test failures at all.  Hooray!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9930>
_______________________________________

From report at bugs.python.org  Thu Sep 23 21:53:28 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 23 Sep 2010 19:53:28 +0000
Subject: [issue9930] Incorrect semantics of __radd__ method for builtin types
In-Reply-To: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>
Message-ID: <1285271608.51.0.330466293508.issue9930@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That's encouraging.  I would suggest making this fix; the fact that Jython and IronPython also get this right is another reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9930>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:04:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 23 Sep 2010 20:04:56 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1285272296.17.0.145394570339.issue9808@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed in r84983. Thanks!

----------
components: +Extension Modules -Library (Lib)
resolution: accepted -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:16:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Sep 2010 20:16:52 +0000
Subject: [issue9930] Incorrect semantics of __radd__ method for builtin types
In-Reply-To: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>
Message-ID: <1285273012.92.0.0966346554196.issue9930@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r84984 (py3k), r84986 (release31-maint).  Thanks for the report!

----------
assignee:  -> mark.dickinson
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9930>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:18:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Sep 2010 20:18:08 +0000
Subject: [issue9928] weird oddity with bz2 context manager
In-Reply-To: <1285263860.75.0.0295269513822.issue9928@psf.upfronthosting.co.za>
Message-ID: <1285273088.9.0.868202552598.issue9928@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r84980 (3.2), r84981 (3.1) and r84982 (2.7).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9928>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:19:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Sep 2010 20:19:43 +0000
Subject: [issue9815] test_tarfile sometimes ends with error "Cannot remove dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1285273183.74.0.867858558108.issue9815@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Adding Michael for review of py3k_fix__AssertRaisesContext.patch.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:27:12 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 20:27:12 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

test_ttk_guionly hangs on x86 XP5 buldbot.
But it doesn't hang on test_tk. Former shows
widget but latter doesn't on my machine.

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/1348/steps/test/logs/stdio

----------
components: Tests, Tkinter, Windows
messages: 117230
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_ttk_guionly hangs on XP5
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:39:08 2010
From: report at bugs.python.org (Adam Nemecek)
Date: Thu, 23 Sep 2010 20:39:08 +0000
Subject: [issue9932] List of sets initialization behavior problems
In-Reply-To: <1285274348.08.0.841759888392.issue9932@psf.upfronthosting.co.za>
Message-ID: <1285274348.08.0.841759888392.issue9932@psf.upfronthosting.co.za>


New submission from Adam Nemecek <adamnemecek at gmail.com>:

I'm not sure if this is the intended behavior, but it seems unusual to me.
a = [set([]) for i in range(2)] evaluates to a list [set([]),set([])] and
b= 2*[set([])] evaluates to [set([]),set([])].
Nothing wrong here. 
Nevertheless, if I do a[0].add(1), a has the value [set([1]), set([])] but  b[0].add(1) evaluates to [set([1]), set([1])]. 
I understand that in list b, all of the sets refer to the same object in memory, nevertheless, I do not feel like this is the correct behavior.

----------
components: None
messages: 117231
nosy: adamnemecek
priority: normal
severity: normal
status: open
title: List of sets initialization behavior problems
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9932>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:39:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 23 Sep 2010 20:39:56 +0000
Subject: [issue9790] ntpath contains imports inside functions
In-Reply-To: <1283867043.1.0.607515525376.issue9790@psf.upfronthosting.co.za>
Message-ID: <1285274396.13.0.277629505361.issue9790@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed to py3k in r84988 using Nick's second suggestion.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9790>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:40:09 2010
From: report at bugs.python.org (Jon Anglin)
Date: Thu, 23 Sep 2010 20:40:09 +0000
Subject: [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1285274409.79.0.649650268515.issue9808@psf.upfronthosting.co.za>


Changes by Jon Anglin <janglin at fortresgrand.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:41:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 23 Sep 2010 20:41:13 +0000
Subject: [issue9790] ntpath contains imports inside functions
In-Reply-To: <1283867043.1.0.607515525376.issue9790@psf.upfronthosting.co.za>
Message-ID: <1285274473.96.0.991569426485.issue9790@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9790>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:56:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Sep 2010 20:56:14 +0000
Subject: [issue9401] automatically try forward operations when reverse
	operations are NotImplemented
In-Reply-To: <1280339816.95.0.28348031653.issue9401@psf.upfronthosting.co.za>
Message-ID: <1285275374.5.0.0542353079386.issue9401@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, but you could bring it up on python-ideas.  (It would have to wait until after the moratorium in any case.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9401>
_______________________________________

From report at bugs.python.org  Thu Sep 23 23:03:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Sep 2010 21:03:43 +0000
Subject: [issue9905] subprocess.Popen fails with stdout=PIPE,
	stderr=PIPE if standard descriptors (0, 1, 2) are closed.
In-Reply-To: <1285005576.46.0.387895977213.issue9905@psf.upfronthosting.co.za>
Message-ID: <1285275823.55.0.931827749755.issue9905@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9905>
_______________________________________

From report at bugs.python.org  Thu Sep 23 23:04:33 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 23 Sep 2010 21:04:33 +0000
Subject: [issue1385] hmac module violates RFC for some hash functions,
	e.g. sha512
In-Reply-To: <1194202320.65.0.260919187967.issue1385@psf.upfronthosting.co.za>
Message-ID: <1285275873.19.0.0874592408288.issue1385@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/issue1385>
_______________________________________

From report at bugs.python.org  Thu Sep 23 23:11:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Sep 2010 21:11:27 +0000
Subject: [issue2052] Allow changing difflib._file_template character encoding.
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1285276287.42.0.776241805026.issue2052@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe that charset is the standard default for html, which would make this a feature request.

----------
assignee: tim_one -> 
nosy: +r.david.murray
stage: unit test needed -> needs patch
type: behavior -> feature request
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
_______________________________________

From report at bugs.python.org  Thu Sep 23 23:12:59 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 23 Sep 2010 21:12:59 +0000
Subject: [issue9932] List of sets initialization behavior problems
In-Reply-To: <1285274348.08.0.841759888392.issue9932@psf.upfronthosting.co.za>
Message-ID: <1285276379.33.0.652444103003.issue9932@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This is well defined in Python and will not change.

----------
nosy: +eric.smith
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9932>
_______________________________________

From report at bugs.python.org  Thu Sep 23 23:27:10 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 23 Sep 2010 21:27:10 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1285277230.49.0.291105224439.issue8879@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here's a patch of the functionality. The doc change is small and easy, I'll add it shortly.

One oddity is that os.path.samefile is False for a link and its source, but True for a symlink and its source. I find that to be quite odd, but stepping through the code I don't see where this is anything we are doing. I haven't been able to figure out if this is really expected behavior from Windows. When the files are open, os.path.sameopenfile shows that the link and its source are the same, which is expected.

----------
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file18982/issue8879.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Thu Sep 23 23:55:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Sep 2010 21:55:11 +0000
Subject: [issue2005] posixmodule expects sizeof(pid_t/gid_t/uid_t) <=
	sizeof(long)
In-Reply-To: <1202068724.99.0.704404319493.issue2005@psf.upfronthosting.co.za>
Message-ID: <1285278911.04.0.422042544067.issue2005@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It appears as though this was fixed as part of issue 1983.  Antoine, can you confirm that?

----------
nosy: +pitrou, r.david.murray -BreamoreBoy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2005>
_______________________________________

From report at bugs.python.org  Fri Sep 24 00:02:26 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 22:02:26 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1285279346.29.0.763938711941.issue8879@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

With following implementation, issamefile return True
for hard link. I heard GetFinalPathNameByHandle
returns different paths for hard links.

>>> import nt, os
>>> def issamefile(path1, path2):
...     fd1 = os.open(path1, os.O_RDONLY)
...     fd2 = os.open(path2, os.O_RDONLY)
...     fi1 = nt._getfileinformation(fd1)
...     fi2 = nt._getfileinformation(fd2)
...     os.close(fd1)
...     os.close(fd2)
...     return fi1 == fi2
...
>>> issamefile("src.txt", "lnk.txt")
True

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Fri Sep 24 00:10:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Sep 2010 22:10:25 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1285279825.29.0.0857991725605.issue3873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a fixed version of Victor's bench (didn't work on 2.x).

----------
Added file: http://bugs.python.org/file18983/bench_pickle.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Fri Sep 24 00:11:51 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 23 Sep 2010 22:11:51 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1285279911.16.0.59806681306.issue6706@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

giampaolo: did you ever rewrite the patch?

For reference to other users:
http://code.google.com/p/pyftpdlib/source/browse/trunk/pyftpdlib/ftpserver.py

Note the complexity of the two handle_accept implementations in that file; both of them begin:
        try:
            sock, addr = self.accept()
        except TypeError:
            # sometimes accept() might return None (see issue 91)
            return
        except socket.error, err:
            # ECONNABORTED might be thrown on *BSD (see issue 105)
            if err[0] != errno.ECONNABORTED:
                logerror(traceback.format_exc())
            return
        else:
            # sometimes addr == None instead of (ip, port) (see issue 104)
            if addr == None:
                return

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Fri Sep 24 00:17:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Sep 2010 22:17:46 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1285280266.16.0.01951746526.issue3873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

And here is new performance patch (Victor's patch was outdated because of heavy changes incorporated from Unladen Swallow). Results of bench_pickle.py are as follows:

* Python 2.7 (cPickle):

Protocol 0
- dump: 189.8 ms
- load (seekable=False): 318.1 ms
- load (seekable=True): 321.2 ms
Protocol 1
- dump: 58.2 ms
- load (seekable=False): 89.5 ms
- load (seekable=True): 89.4 ms
Protocol 2
- dump: 58.0 ms
- load (seekable=False): 89.1 ms
- load (seekable=True): 89.1 ms

* Python 3.2 (unpatched):

Protocol 0
- dump: 144.5 ms
- load (seekable=False): 530.7 ms
- load (seekable=True): 530.5 ms
Protocol 1
- dump: 27.8 ms
- load (seekable=False): 280.4 ms
- load (seekable=True): 279.9 ms
Protocol 2
- dump: 27.8 ms
- load (seekable=False): 280.6 ms
- load (seekable=True): 281.9 ms

* Python 3.2 + patch:

Protocol 0
- dump: 146.4 ms
- load (seekable=False): 611.1 ms
- load (seekable=True): 194.2 ms
Protocol 1
- dump: 27.3 ms
- load (seekable=False): 254.7 ms
- load (seekable=True): 31.2 ms
Protocol 2
- dump: 27.3 ms
- load (seekable=False): 254.6 ms
- load (seekable=True): 31.2 ms

----------
Added file: http://bugs.python.org/file18984/unpickleprefetch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Fri Sep 24 00:20:46 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 23 Sep 2010 22:20:46 +0000
Subject: [issue9905] subprocess.Popen fails with stdout=PIPE,
	stderr=PIPE if standard descriptors (0, 1, 2) are closed.
In-Reply-To: <1285005576.46.0.387895977213.issue9905@psf.upfronthosting.co.za>
Message-ID: <1285280446.63.0.862521472392.issue9905@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

issue6610 looks very similar. issue9074 may also be related.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9905>
_______________________________________

From report at bugs.python.org  Fri Sep 24 00:31:46 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 23 Sep 2010 22:31:46 +0000
Subject: [issue9888] int overflow in datetime causes seg fault from
	datetime.ctime()
In-Reply-To: <1284747482.26.0.727712350645.issue9888@psf.upfronthosting.co.za>
Message-ID: <1285281106.99.0.876828780553.issue9888@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

yes, this was fixed by issue7150.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed
superseder:  -> datetime operations spanning MINYEAR give bad results

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9888>
_______________________________________

From report at bugs.python.org  Fri Sep 24 00:34:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Sep 2010 22:34:18 +0000
Subject: [issue2005] posixmodule expects sizeof(pid_t/gid_t/uid_t) <=
	sizeof(long)
In-Reply-To: <1202068724.99.0.704404319493.issue2005@psf.upfronthosting.co.za>
Message-ID: <1285281258.87.0.46744254711.issue2005@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The pid_t issue was fixed but not uid_t/gid_t.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2005>
_______________________________________

From report at bugs.python.org  Fri Sep 24 01:48:36 2010
From: report at bugs.python.org (Kamil Kisiel)
Date: Thu, 23 Sep 2010 23:48:36 +0000
Subject: [issue9933] os module does not have the documented EX_NOTFOUND
	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>


New submission from Kamil Kisiel <kisielk at users.sourceforge.net>:

The library documentation (http://docs.python.org/library/os.html) states:

"""
os.EX_NOTFOUND
Exit code that means something like ?an entry was not found?.

Availability: Unix.

New in version 2.3.
"""

However, on both my Linux and OS X installs of OS X this happens:

python
Python 2.6.2 (r262:71600, Oct 24 2009, 03:15:21) 
[GCC 4.4.1 [gcc-4_4-branch revision 150839]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
im>>> import os
>>> os.EX_NOTFOUND
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'EX_NOTFOUND'
>>> 


Unfortunately I don't have another Python version available to test with at the moment so I'm not sure if this affects other versions as well.

----------
components: Library (Lib)
messages: 117245
nosy: kisielk
priority: normal
severity: normal
status: open
title: os module does not have the documented EX_NOTFOUND attribute
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9933>
_______________________________________

From report at bugs.python.org  Fri Sep 24 01:49:32 2010
From: report at bugs.python.org (Kamil Kisiel)
Date: Thu, 23 Sep 2010 23:49:32 +0000
Subject: [issue9933] os module does not have the documented EX_NOTFOUND
	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285285772.33.0.415228939922.issue9933@psf.upfronthosting.co.za>


Kamil Kisiel <kisielk at users.sourceforge.net> added the comment:

That should have read "Linux and OS X installs of *Python*".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9933>
_______________________________________

From report at bugs.python.org  Fri Sep 24 01:50:18 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 23 Sep 2010 23:50:18 +0000
Subject: [issue9790] ntpath contains imports inside functions
In-Reply-To: <1283867043.1.0.607515525376.issue9790@psf.upfronthosting.co.za>
Message-ID: <1285285818.4.0.929719914859.issue9790@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Nick noticed another issue with this, and it actually won't work on pre-Vista versions since we load GetFinalPathNameByHandle at runtime, which is why we had that NotImplementedError.

Attaching a patch which should handle this. We only try the import on Windows 6.0 or above now, and otherwise (XP, other OS'es) use the fallback method.

----------
keywords: +patch
nosy: +ncoghlan
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open
Added file: http://bugs.python.org/file18985/issue9790_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9790>
_______________________________________

From report at bugs.python.org  Fri Sep 24 02:02:08 2010
From: report at bugs.python.org (Retro)
Date: Fri, 24 Sep 2010 00:02:08 +0000
Subject: [issue9934] Python Docs Typo
In-Reply-To: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>
Message-ID: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

http://docs.python.org/distutils/sourcedist.html#manifest-related-options

Please visit the above link and note the typo in:
-o is a sortcut for --manifest-only.

Should be:
-o is a shortcut for --manifest-only.

The word "sortcut" is a typo. Please fix it to "shortcut". Thanks.

----------
assignee: docs at python
components: Documentation
messages: 117248
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Python Docs Typo
versions: Python 2.5, 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/issue9934>
_______________________________________

From report at bugs.python.org  Fri Sep 24 02:07:09 2010
From: report at bugs.python.org (Dan Buch)
Date: Fri, 24 Sep 2010 00:07:09 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1285286829.7.0.959169335533.issue4661@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Fri Sep 24 02:21:44 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 24 Sep 2010 00:21:44 +0000
Subject: [issue9933] os module does not have the documented EX_NOTFOUND
	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285287704.17.0.160778532769.issue9933@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The following code exists in Modules/posixmodule.c

8167     /* These come from sysexits.h */
...
8216 #ifdef EX_NOTFOUND
8217     if (ins(d, "EX_NOTFOUND", (long)EX_NOTFOUND)) return -1;
8218 #endif /* EX_NOTFOUND */


sysexits.h on my Mac has no mention of EX_NOTFOUND. I'm guessing it was removed some time ago or maybe it never existed? I wasn't able to find anything after a quick Google search.

Was there any particular reason you need EX_NOTFOUND other than that it's documented? Just trying to trace where this thing came from and went.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9933>
_______________________________________

From report at bugs.python.org  Fri Sep 24 02:49:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Sep 2010 00:49:38 +0000
Subject: [issue9933] os module does not have the documented EX_NOTFOUND
	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285289378.94.0.163660153129.issue9933@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Perhaps this constant existed at some point on some linux systems...google found one comment about it referencing posix.2.  I also found it mentioned in a specific version of sendmail, and in bash.  When it appears it seems to most often have the value 127.

I suspect the mention of this constant should just be deleted from the docs.  Google code search finds no mention of it in any sysexits.h file anywhere it has searched, so the chances are this constant will never be defined by Python.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, r.david.murray
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9933>
_______________________________________

From report at bugs.python.org  Fri Sep 24 02:56:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Sep 2010 00:56:47 +0000
Subject: [issue9933] os module does not have the documented EX_NOTFOUND
	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285289807.21.0.174250677472.issue9933@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

s/linux/unix/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9933>
_______________________________________

From report at bugs.python.org  Fri Sep 24 02:57:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 24 Sep 2010 00:57:53 +0000
Subject: [issue9933] os module does not have the documented EX_NOTFOUND
	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285289873.4.0.833928641774.issue9933@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

+1 for removing it from the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9933>
_______________________________________

From report at bugs.python.org  Fri Sep 24 03:07:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 01:07:04 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is a bunch of assorted optimizations which make pickling of user-defined classes quite a bit faster.

Example on a minimal instance:

$ python -m timeit -s "import pickle; import collections, __main__; __main__.X=type('X', (), {}); x=X()" "pickle.dumps(x)"
-> before: 100000 loops, best of 3: 8.11 usec per loop
-> after: 100000 loops, best of 3: 2.95 usec per loop

Example on a namedtuple:

$ python -m timeit -s "import pickle; import collections, __main__; __main__.X=collections.namedtuple('X', 'a'); x=X(5)" "pickle.dumps(x)"
-> before: 100000 loops, best of 3: 9.52 usec per loop
-> after: 100000 loops, best of 3: 3.78 usec per loop

Unladen Swallow's pickling benchmark:

### pickle ###
Min: 0.792903 -> 0.704288: 1.1258x faster
Avg: 0.796241 -> 0.706073: 1.1277x faster
Significant (t=39.374217)
Stddev: 0.00410 -> 0.00307: 1.3342x smaller
Timeline: http://tinyurl.com/38elzvv

----------
components: Library (Lib)
files: pickleinst.patch
keywords: patch
messages: 117253
nosy: alexandre.vassalotti, belopolsky, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Faster pickling of instances
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18986/pickleinst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9935>
_______________________________________

From report at bugs.python.org  Fri Sep 24 03:23:59 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Fri, 24 Sep 2010 01:23:59 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285291439.41.0.593963466869.issue6608@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

Thank you for a kind guidance.

I uploaded patch with 

 - function name "checktm" 
 - add comment above gettmarg
 - move comment in "checktm" to (above function signature)
  - change comment little bit to mention issue6608
 - "{" on new line

----------
Added file: http://bugs.python.org/file18987/issue6608-timemodule-2nd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Fri Sep 24 04:00:33 2010
From: report at bugs.python.org (Jon Anglin)
Date: Fri, 24 Sep 2010 02:00:33 +0000
Subject: [issue9783] _elementtree.c warnings under 64-bit Windows
In-Reply-To: <1283777393.95.0.65520363014.issue9783@psf.upfronthosting.co.za>
Message-ID: <1285293633.89.0.14013025074.issue9783@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

issue9783.diff provides a patch that will compile clean on 32 and 64 bit Windows systems.  I tried to avoid explicit casts where I could, but it was not always possible. I have ported a lot of my company's code to 64 bit (all Windows based).  In my experience many warnings are because of programmers using the int type in places where a size_t may be more appropriate. Most of the warnings here are due to mixing int and Py_ssize_t types.

----------
keywords: +patch
Added file: http://bugs.python.org/file18988/issue9783.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9783>
_______________________________________

From report at bugs.python.org  Fri Sep 24 04:25:18 2010
From: report at bugs.python.org (Skye)
Date: Fri, 24 Sep 2010 02:25:18 +0000
Subject: [issue2209] mailbox module doesn't support compressed mbox
In-Reply-To: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za>
Message-ID: <1285295118.64.0.245169407444.issue2209@psf.upfronthosting.co.za>


Changes by Skye <skyepn at gmail.com>:


----------
nosy: +skyepn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2209>
_______________________________________

From report at bugs.python.org  Fri Sep 24 04:30:06 2010
From: report at bugs.python.org (Jon Anglin)
Date: Fri, 24 Sep 2010 02:30:06 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1285295406.23.0.14823679809.issue9784@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

issue9784.diff contains a patch that compiles clean on 32 and 64 bit Windows. This patch is exactly what Amaury Forgeot d'Arc recommended in msg115750.

----------
keywords: +patch
Added file: http://bugs.python.org/file18989/issue9784.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Fri Sep 24 04:35:03 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Sep 2010 02:35:03 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285295703.06.0.257650495691.issue6608@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/issue6608>
_______________________________________

From report at bugs.python.org  Fri Sep 24 04:55:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 02:55:55 +0000
Subject: [issue9936] trace misreports "missing" lines
In-Reply-To: <1285296955.25.0.310844622187.issue9936@psf.upfronthosting.co.za>
Message-ID: <1285296955.25.0.310844622187.issue9936@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

With the attached traceme.py, 


$ python -m trace -m -s -c  traceme.py
lines   cov%   module   (path)
    2    50%   traceme   (traceme.py)
$ cat traceme.cover 
       x = (1,
>>>>>>      2,
    1:      3)

This is wrong because all lines in traceme.py are executed.

----------
files: traceme.py
messages: 117257
nosy: belopolsky
priority: normal
severity: normal
status: open
title: trace misreports "missing" lines
Added file: http://bugs.python.org/file18990/traceme.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9936>
_______________________________________

From report at bugs.python.org  Fri Sep 24 05:00:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 03:00:04 +0000
Subject: [issue9936] trace misreports "missing" lines
In-Reply-To: <1285296955.25.0.310844622187.issue9936@psf.upfronthosting.co.za>
Message-ID: <1285297204.95.0.169053025879.issue9936@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch that fixes this issue.  Need to add a unit test.

----------
assignee:  -> belopolsky
components: +Library (Lib)
keywords: +patch
stage:  -> unit test needed
type:  -> behavior
versions: +Python 3.2
Added file: http://bugs.python.org/file18991/issue9936.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9936>
_______________________________________

From report at bugs.python.org  Fri Sep 24 05:02:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 03:02:48 +0000
Subject: [issue9936] trace misreports "missing" lines
In-Reply-To: <1285296955.25.0.310844622187.issue9936@psf.upfronthosting.co.za>
Message-ID: <1285297368.11.0.0763932124851.issue9936@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +eli.bendersky, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9936>
_______________________________________

From report at bugs.python.org  Fri Sep 24 05:07:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Sep 2010 03:07:26 +0000
Subject: [issue1794] Hot keys must work in any keyboard layout
In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za>
Message-ID: <1285297646.92.0.577756742188.issue1794@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

it does seem that the consensus is that this is not a generally desirable feature.

----------
nosy: +r.david.murray -BreamoreBoy
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1794>
_______________________________________

From report at bugs.python.org  Fri Sep 24 05:13:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Sep 2010 03:13:56 +0000
Subject: [issue1763] Winpath module - easy access to Windows directories like
	My Documents
In-Reply-To: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za>
Message-ID: <1285298036.92.0.804113755144.issue1763@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: closed -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1763>
_______________________________________

From report at bugs.python.org  Fri Sep 24 05:16:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 03:16:33 +0000
Subject: [issue9936] trace misreports "missing" lines
In-Reply-To: <1285296955.25.0.310844622187.issue9936@psf.upfronthosting.co.za>
Message-ID: <1285298193.88.0.618667885808.issue9936@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9936>
_______________________________________

From report at bugs.python.org  Fri Sep 24 06:11:09 2010
From: report at bugs.python.org (Kamil Kisiel)
Date: Fri, 24 Sep 2010 04:11:09 +0000
Subject: [issue9933] os module does not have the documented EX_NOTFOUND
	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285301469.87.0.664096459822.issue9933@psf.upfronthosting.co.za>


Kamil Kisiel <kisielk at users.sourceforge.net> added the comment:

I mostly wanted to just report the issue rather than propose a solution, so I'm in favor of whatever everyone feels is best.

As for how I came across the issue, it was mostly curiosity, I wanted to see the numerical value of all the os.EX_* constants and was printing them out on the screen when I stumbled upon this.

If there's no chance of it working, which seems to be the case, I agree it should probably be just removed from the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9933>
_______________________________________

From report at bugs.python.org  Fri Sep 24 06:52:12 2010
From: report at bugs.python.org (Andrew Ziem)
Date: Fri, 24 Sep 2010 04:52:12 +0000
Subject: [issue7519] ConfigParser can't read files with BOM markers
In-Reply-To: <1260905357.88.0.211998340765.issue7519@psf.upfronthosting.co.za>
Message-ID: <1285303932.95.0.274517084462.issue7519@psf.upfronthosting.co.za>


Changes by Andrew Ziem <ahz001 at gmail.com>:


----------
nosy: +AndrewZiem

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7519>
_______________________________________

From report at bugs.python.org  Fri Sep 24 07:05:22 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Fri, 24 Sep 2010 05:05:22 +0000
Subject: [issue459007] Document sys.path on Windows
Message-ID: <1285304722.3.0.200588940561.issue459007@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


----------
nosy: +ruseel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue459007>
_______________________________________

From report at bugs.python.org  Fri Sep 24 07:51:51 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Sep 2010 05:51:51 +0000
Subject: [issue9933] os module does not have the documented EX_NOTFOUND
	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285307511.83.0.933608611072.issue9933@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I fail to see the issue. The documentation clearly says, above the block of all the EX_* constants:

Note

Some of these may not be available on all Unix platforms, since there is some variation. These constants are defined where they are defined by the underlying platform.

That seems to explain the situation well, no?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9933>
_______________________________________

From report at bugs.python.org  Fri Sep 24 08:47:15 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 24 Sep 2010 06:47:15 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285310835.82.0.881968673816.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, previous one contained experimental code for another issue.
I've attached correct one.

----------
Added file: http://bugs.python.org/file18992/py3k_better_build_ssl.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Fri Sep 24 09:10:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 24 Sep 2010 07:10:40 +0000
Subject: [issue9933] os module does not have the documented EX_NOTFOUND
	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285312240.31.0.316257091404.issue9933@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree with Martin.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9933>
_______________________________________

From report at bugs.python.org  Fri Sep 24 11:17:19 2010
From: report at bugs.python.org (Iwasa Kazmi)
Date: Fri, 24 Sep 2010 09:17:19 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>


New submission from Iwasa Kazmi <kzmizzz at gmail.com>:

_winreg.EnumValue causes MemoryError if the name of the value contains multibyte unicode characters.

I'm using 2.6.6.
I think it is relevant to Isssue #2810.

----------
components: Windows
messages: 117264
nosy: kzmi
priority: normal
severity: normal
status: open
title: _winreg.EnumValue causes MemoryError
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Fri Sep 24 11:19:40 2010
From: report at bugs.python.org (Iwasa Kazmi)
Date: Fri, 24 Sep 2010 09:19:40 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285319980.66.0.695717002205.issue9937@psf.upfronthosting.co.za>


Iwasa Kazmi <kzmizzz at gmail.com> added the comment:

Added sample registory data file.

----------
Added file: http://bugs.python.org/file18993/fonts.reg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Fri Sep 24 11:21:08 2010
From: report at bugs.python.org (Iwasa Kazmi)
Date: Fri, 24 Sep 2010 09:21:08 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285320068.86.0.667322355776.issue9937@psf.upfronthosting.co.za>


Iwasa Kazmi <kzmizzz at gmail.com> added the comment:

Added py file to reproduce.

----------
Added file: http://bugs.python.org/file18994/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Fri Sep 24 11:22:28 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 24 Sep 2010 09:22:28 +0000
Subject: [issue9868] test_locale leaves locale changed
In-Reply-To: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>
Message-ID: <1285320148.91.0.234286687059.issue9868@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Committed in r84973(py3k) and r84990(release31-maint).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9868>
_______________________________________

From report at bugs.python.org  Fri Sep 24 11:26:11 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 24 Sep 2010 09:26:11 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285320371.37.0.584497430544.issue9552@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file18974/py3k_better_build_ssl.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Fri Sep 24 11:26:21 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 24 Sep 2010 09:26:21 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285320381.79.0.95863317169.issue9552@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file18992/py3k_better_build_ssl.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Fri Sep 24 11:26:42 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 24 Sep 2010 09:26:42 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285320402.83.0.388408143076.issue9552@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file18995/py3k_better_build_ssl.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Fri Sep 24 11:38:47 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 24 Sep 2010 09:38:47 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1285321127.35.0.889118262222.issue9784@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Fri Sep 24 11:40:11 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 24 Sep 2010 09:40:11 +0000
Subject: [issue9783] _elementtree.c warnings under 64-bit Windows
In-Reply-To: <1283777393.95.0.65520363014.issue9783@psf.upfronthosting.co.za>
Message-ID: <1285321211.89.0.439915245171.issue9783@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9783>
_______________________________________

From report at bugs.python.org  Fri Sep 24 13:34:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Sep 2010 11:34:24 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1285328064.21.0.504098914031.issue9630@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of the patch:
 - reencode sys.path_importer_cache (and remove the last FIXME)
 - fix different reference leaks
 - catch PyIter_Next() failures
 - create a subfunction to reencode sys.modules: it's easier to review and manager errors in shorter functions
 - add some comments

----------
Added file: http://bugs.python.org/file18996/reencode_modules_path-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 13:34:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Sep 2010 11:34:29 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1285328069.5.0.417113688583.issue9630@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file18561/reencode_modules_path-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 13:38:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Sep 2010 11:38:08 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1285328288.21.0.463901524975.issue9630@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I would rename the feature to something like "redecode-modules"

Yes, right. I will rename the functions before commiting the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 13:43:53 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 24 Sep 2010 11:43:53 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1285328064.21.0.504098914031.issue9630@psf.upfronthosting.co.za>
Message-ID: <4C9C8EF6.1050702@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> New version of the patch:
>  - reencode sys.path_importer_cache (and remove the last FIXME)
>  - fix different reference leaks
>  - catch PyIter_Next() failures
>  - create a subfunction to reencode sys.modules: it's easier to review and manager errors in shorter functions
>  - add some comments

Why is this needed ?

With PYTHONFSENCODING there should be no need to change the FS
encoding after startup.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 13:52:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Sep 2010 11:52:59 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1285329179.71.0.256662382673.issue9630@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Why is this needed ?

Short answer: to support filesystem encoding different than utf-8. See #8611 for a longer explanation.

Example:

$ pwd
/home/SHARE/SVN/py3k?
$ PYTHONFSENCODING=ascii ./python test_fs_encoding.py 
Fatal Python error: Py_Initialize: can't initialize sys standard streams
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 20: ordinal not in range(128)
Abandon

My patch fixes this specific case and prepare the work for the complete fix (support different *locale* encodings, see #8611 and #9425).

--

Longer answer: Py_FilesystemDefaultEncoding is changed too late. Some modules are already loaded, sys.executable is already set, etc. Py_FilesystemDefaultEncoding is changed but modules filenames are decoded with utf-8 and should be "redecoded".

It is not possible to set Py_FilesystemDefaultEncoding before loading the first module. initfsencoding() loads codecs and encodings modules to check the codec name. sys.executable is also set before initfsencoding().

Read my other messages of this issue to get other reasons why the patch is needed. I explained other possibilities (but they don't work).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:08:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 12:08:33 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1285330113.79.0.0115943788085.issue9630@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>It is not possible to set Py_FilesystemDefaultEncoding before loading 
>the first module. initfsencoding() loads codecs and encodings modules to 
>check the codec name.

Not sure it's related, but there seems to be a bug:

$ ./python -c "import sys; print(sys.getfilesystemencoding())"
utf-8
$ LC_CTYPE=latin1 ./python -c "import sys; print(sys.getfilesystemencoding())"
ascii
$ LC_CTYPE=fr_FR:iso8859-1 ./python -c "import sys; print(sys.getfilesystemencoding())"
ascii

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:14:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 12:14:01 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1285330441.53.0.858438290271.issue9630@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some things about your patch:
- as Amaury said, functions should be named "redecode*" rather than "reencode*"
- please use -1 for error return, not 1
- have you tried to measure if it made Python startup slower?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:15:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Sep 2010 12:15:32 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1285330113.79.0.0115943788085.issue9630@psf.upfronthosting.co.za>
Message-ID: <201009241415.22397.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Not sure it's related, but there seems to be a bug:

It's not a bug, it's a feature :-) If you specify a non-existing locale, the 
GNU libc fails back to ascii.

$ locale -a
C
fran?ais
french
fr_FR
fr_FR at euro
fr_FR.iso88591
fr_FR.iso885915 at euro
fr_FR.utf8

$ LC_CTYPE=fr_FR.iso88591 ./python -c "import locale; 
print(locale.nl_langinfo(locale.CODESET))"
ISO-8859-1

$ LC_CTYPE=xxx ./python -c "import locale; 
print(locale.nl_langinfo(locale.CODESET))"
ANSI_X3.4-1968

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:19:29 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 24 Sep 2010 12:19:29 +0000
Subject: [issue1542544] Improve dynamic linking support on AIX
Message-ID: <1285330769.2.0.582297636252.issue1542544@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I think this issue can be closed as a duplicate of issue 941346.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1542544>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:21:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 12:21:15 +0000
Subject: [issue1542544] Improve dynamic linking support on AIX
Message-ID: <1285330875.82.0.811759460459.issue1542544@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> AIX shared library fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1542544>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:22:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 12:22:10 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1285330930.82.0.137401792515.issue9630@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brett.cannon, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:23:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 12:23:05 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285330985.38.0.653744824118.issue9552@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not really able to review this kind of things. Please commit if you think it is ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:23:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 12:23:55 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285331035.42.0.955045348599.issue9937@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, haypo, tim.golden
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:35:29 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 24 Sep 2010 12:35:29 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1285329179.71.0.256662382673.issue9630@psf.upfronthosting.co.za>
Message-ID: <4C9C9B0D.9060407@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> Why is this needed ?
> 
> Short answer: to support filesystem encoding different than utf-8. See #8611 for a longer explanation.
> 
> Example:
> 
> $ pwd
> /home/SHARE/SVN/py3k?
> $ PYTHONFSENCODING=ascii ./python test_fs_encoding.py 
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 20: ordinal not in range(128)
> Abandon
> 
> My patch fixes this specific case and prepare the work for the complete fix (support different *locale* encodings, see #8611 and #9425).
> 
> --
> 
> Longer answer: Py_FilesystemDefaultEncoding is changed too late. Some modules are already loaded, sys.executable is already set, etc. Py_FilesystemDefaultEncoding is changed but modules filenames are decoded with utf-8 and should be "redecoded".
> 
> It is not possible to set Py_FilesystemDefaultEncoding before loading the first module. initfsencoding() loads codecs and encodings modules to check the codec name. sys.executable is also set before initfsencoding().
> 
> Read my other messages of this issue to get other reasons why the patch is needed. I explained other possibilities (but they don't work).

Thanks for the explanation. So the only reason why you have to go through
all those hoops is to

 * allow the complete set of Python supported encoding names
   for the PYTHONFSENCODING

 * make sure that the Py_FilesystemDefaultEncoding is set to
   the actual name of the codec as used by the system

Given that the redecoding of the filenames is fragile, I'd suggest
to drop the encoding name check and then setting the variable right
at the start of Py_Initialize().

If the encoding defined in PYTHONFSENCODING turns out not
to be defined, the module loader will complain later on during
startup.

To play extra safe, you might run get_codec_name() at the same
point in startup as you have initfsencoding() now. If something
failed to load, you won't even get there. If things loaded
fine, then you have a chance to safely double-check at that point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:40:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Sep 2010 12:40:40 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1285330441.53.0.858438290271.issue9630@psf.upfronthosting.co.za>
Message-ID: <201009241440.31182.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Some things about your patch:
> - as Amaury said, functions should be named "redecode*"
> rather than "reencode*" 

Yes, as written before (msg117269), I will do it in my next patch.

> - please use -1 for error return, not 1

Ok.

> - have you tried to measure if it made Python startup slower?

(Sploiter: the overhead is around 3%)

First, my patch doesn't concern Windows or Mac OS X, because the filesystem 
encoding is hardcoded in these platforms. Then, it only concerns systems with 
a filesystem encoding different than utf-8. utf-8 is now the default encoding of 
all Linux distributions. I suppose that BSD systems do also use it by default.

Let's try a dummy benchmark with py3k r84990. 5 runs, I kept the smallest 
time.

-- pydebug mode (gcc -O0) with the patch ---

$ unset PYTHONFSENCODING; time ./python  -c "pass"
real    0m0.084s
user    0m0.080s
sys     0m0.010s

$ export PYTHONFSENCODING=ascii; time ./python  -c "pass"
real    0m0.100s
user    0m0.100s
sys     0m0.000s

The startup time overhead is around 20%.

-- default mode (gcc -O3) without the patch ---

$ unset PYTHONFSENCODING; time ./python  -c "pass"

real    0m0.033s
user    0m0.030s
sys     0m0.000s

-- default mode (gcc -O3) with the patch ---

$ export PYTHONFSENCODING=utf-8; time ./python  -c "pass"

real    0m0.032s
user    0m0.030s
sys     0m0.000s

$ export PYTHONFSENCODING=ascii; time ./python  -c "pass"

real    0m0.033s
user    0m0.020s
sys     0m0.020s

Here is overhead is around 3%.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:47:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 12:47:48 +0000
Subject: [issue9929] subprocess.Popen unbuffered not work
In-Reply-To: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>
Message-ID: <1285332468.48.0.304694944257.issue9929@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You are right that it doesn't work anymore (under Linux too).

Your patch is almost ok. It should raise a ValueError if bufsize=0 and universal_newlines is true (the two can't be satisfied together, since universal newlines implies buffering).

It would also be better to add a test in test_subprocess.

As a sidenote, bufsize=1 (line buffering) doesn't work anymore either, and this can't be fixed without breaking compatibility.

----------
components: +Library (Lib) -Windows
nosy: +gregory.p.smith, pitrou
title: subprocess.Popen unbuffered not work (windows) -> subprocess.Popen unbuffered not work
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9929>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:50:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 12:50:00 +0000
Subject: [issue9929] subprocess.Popen unbuffered not work
In-Reply-To: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>
Message-ID: <1285332599.99.0.0809804277524.issue9929@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As another sidenote, `bufsize` should only be relevant for stdin. For stdout and stderr, disabling buffering will only reduce performance, not add functionality. So I would suggest only setting buffering on stding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9929>
_______________________________________

From report at bugs.python.org  Fri Sep 24 14:58:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Sep 2010 12:58:42 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <4C9C9B0D.9060407@egenix.com>
Message-ID: <201009241458.33354.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le vendredi 24 septembre 2010 14:35:29, Marc-Andre Lemburg a ?crit :
> Thanks for the explanation. So the only reason why you have to go through
> all those hoops is to
> 
>  * allow the complete set of Python supported encoding names
>    for the PYTHONFSENCODING
> 
>  * make sure that the Py_FilesystemDefaultEncoding is set to
>    the actual name of the codec as used by the system

Yes, the problem is the get_codec_name() function: it calls _PyCodec_Lookup() 
which loads codecs module and then the "encodings.xxx" module.

> Given that the redecoding of the filenames is fragile, I'd suggest
> to drop the encoding name check and then setting the variable right
> at the start of Py_Initialize().

Yes, it is fragile. If the import machinery is changed (eg. add a new cache), 
if the code object is changed, or if something else using filenames is changed, 
reencode_filenames() should also be changed.

Check the encoding name is very important. If I remember correctly, I added it 
to avoid an unlimited recusion loop. Or it was related to 
sys.setfilesystemencoding()? I don't remember :-)

I agree that my patch is not the most simple or safe method to fix the problem. 
I will try your solution.

But we have to be careful of the fallback to utf-8 if the encoding name is 
invalid.

> If the encoding defined in PYTHONFSENCODING turns out not
> to be defined, the module loader will complain later on during
> startup.

Yes. But I hope that it doesn't fill any cache or something else keeping a 
trace of the filename encoded to the wrong encoding.

> To play extra safe, you might run get_codec_name() at the same
> point in startup as you have initfsencoding() now. If something
> failed to load, you won't even get there. If things loaded
> fine, then you have a chance to safely double-check at that point.

Exactly.

As I wrote before, I don't like my reencode* patch, but I didn't found better 
solution. I will work on patch implementing your solution and check if it 
works or not ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Fri Sep 24 15:25:24 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 24 Sep 2010 13:25:24 +0000
Subject: [issue9418] Move _formatter_* methods from string type into _string
	module
In-Reply-To: <1280416899.1.0.0890176421306.issue9418@psf.upfronthosting.co.za>
Message-ID: <1285334724.22.0.645304021079.issue9418@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

My only concern with this is that it would cause other implementations to do the same thing. I assume it's not hard for them, but it is work. I know that IronPython implemented the _formatter_* methods so that they could use string.py as-is.

But that's a small concern, I think this is a good idea in general. I agree it should be its own C module _string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9418>
_______________________________________

From report at bugs.python.org  Fri Sep 24 15:28:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 13:28:12 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1285334892.66.0.51258991459.issue9935@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/issue9935>
_______________________________________

From report at bugs.python.org  Fri Sep 24 15:37:48 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 24 Sep 2010 13:37:48 +0000
Subject: [issue9790] ntpath contains imports inside functions
In-Reply-To: <1283867043.1.0.607515525376.issue9790@psf.upfronthosting.co.za>
Message-ID: <1285335468.2.0.648989193631.issue9790@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, I realised shortly after I sent my email in response to the checkin that the original version was covering more cases in that first try-block.

I'll defer to you when it comes to exactly which case that NotImplementedError was covering - patch looks good given the explanation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9790>
_______________________________________

From report at bugs.python.org  Fri Sep 24 15:56:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 13:56:07 +0000
Subject: [issue9790] ntpath contains imports inside functions
In-Reply-To: <1283867043.1.0.607515525376.issue9790@psf.upfronthosting.co.za>
Message-ID: <1285336567.25.0.339809526861.issue9790@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch looks ok, and it would hopefully fix build errors on the XP buildbots :)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9790>
_______________________________________

From report at bugs.python.org  Fri Sep 24 15:57:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 24 Sep 2010 13:57:56 +0000
Subject: [issue9790] ntpath contains imports inside functions
In-Reply-To: <1283867043.1.0.607515525376.issue9790@psf.upfronthosting.co.za>
Message-ID: <1285336676.05.0.165635332405.issue9790@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed in r84992. Thanks for having a look.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9790>
_______________________________________

From report at bugs.python.org  Fri Sep 24 16:27:08 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 24 Sep 2010 14:27:08 +0000
Subject: [issue9418] Move _formatter_* methods from string type into _string
	module
In-Reply-To: <1280416899.1.0.0890176421306.issue9418@psf.upfronthosting.co.za>
Message-ID: <1285338428.17.0.782249826895.issue9418@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Now that I start this, I see that it's complicated by the fact that the functions actually being wrapped are in stringlib/string_format.h. That's because in 2.x they compile as both unicode and str. Before the _string module is created, the code should really be moved out of stringlib (possibly into _string). But that's a much more involved task.

I guess it depends if we want to have a bytes version of format(). If we do, it's best to leave the code in stringlib so it can be shared between the implementations. If we never want that, it can be removed from stringlib and put somewhere else, removing the ability to call it both ways. I'll have to give that some thought.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9418>
_______________________________________

From report at bugs.python.org  Fri Sep 24 16:31:30 2010
From: report at bugs.python.org (Jay T)
Date: Fri, 24 Sep 2010 14:31:30 +0000
Subject: [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>


New submission from Jay T <jaytula at gmail.com>:

I want to create a custom interactive shell where I continually do 
parse_args.  Like the following: 
parser = argparse.ArgumentParser() 
command = raw_input() 
while(True): 
  args = parser.parse_args(shlex.split(command)) 
  # Do some magic stuff 
  command = raw_input() 
The problem is that if I give it invalid input, it errors and exits 
with a help message.

I learned from argparse-users group that you can override the exit method like the following:

class MyParser(ArgumentParser): 
  def exit(self, status=0, message=None): 
    # do whatever you want here 

I would be nice to have this usage documented perhaps along with best practices for doing help messages in this scenario.

----------
assignee: docs at python
components: Documentation
messages: 117287
nosy: docs at python, jayt
priority: normal
severity: normal
status: open
title: Documentation for argparse interactive use
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Fri Sep 24 16:59:51 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 24 Sep 2010 14:59:51 +0000
Subject: [issue9665] Buid issues on Cygwin - _curses, _curses_panel, and _io
In-Reply-To: <1282599121.2.0.918330648156.issue9665@psf.upfronthosting.co.za>
Message-ID: <1285340391.03.0.657184496436.issue9665@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee: brian.curtin -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9665>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:04:47 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 24 Sep 2010 15:04:47 +0000
Subject: [issue766910] fix one or two bugs in trace.py
Message-ID: <1285340687.91.0.456062409729.issue766910@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
Removed message: http://bugs.python.org/msg117114

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:04:57 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 24 Sep 2010 15:04:57 +0000
Subject: [issue766910] fix one or two bugs in trace.py
Message-ID: <1285340697.26.0.141563517808.issue766910@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
Removed message: http://bugs.python.org/msg117113

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:05:27 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 24 Sep 2010 15:05:27 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1285340727.32.0.317031788389.issue9923@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee: ronaldoussoren -> 
components:  -Macintosh
nosy:  -ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:07:05 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 24 Sep 2010 15:07:05 +0000
Subject: [issue9907] interactive mode TAB does not insert on OS X built with
	editline instead of GNU readline
In-Reply-To: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>
Message-ID: <1285340825.72.0.313435426191.issue9907@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Patch looks fine and should IMO be applied

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9907>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:11:54 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 24 Sep 2010 15:11:54 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285341114.13.0.276983888251.issue9937@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm not able to reproduce any MemoryError on 2.6, 2.7, or 3.2 on Windows 7 using your registry data and test script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:13:43 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Fri, 24 Sep 2010 15:13:43 +0000
Subject: [issue459007] Document sys.path on Windows
Message-ID: <1285341223.17.0.858743932495.issue459007@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

I made patch which move comment from PC/getpathp.c to Doc/using/windows.rst. And did a little editing, reST markup.

http://codereview.appspot.com/2211046

----------
keywords: +patch
Added file: http://bugs.python.org/file18997/comment_move_to_windows_rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue459007>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:14:07 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 24 Sep 2010 15:14:07 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285341247.87.0.457418599628.issue9937@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I can reproduce the issue on python2.x. I cannot on
python3.x.

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:19:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 15:19:22 +0000
Subject: [issue9939] Add a pipe type (FIFO) to the io module
In-Reply-To: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za>
Message-ID: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

While writing tests for nntplib, it came to me that a PipeIO or BytesPipeIO would be useful (I actually wrote a minimal one). It would be a non-seekable in-memory bytes buffer with distinct read and write pointers, so as to act like a system FIFO or a socket.makefile() object. A pure Python implementation would probably be sufficient, since the main use would be for test purposes. What do you think?

(you may point to os.pipe() but it has problems such as limited buffer size: try to write many bytes to the write end and it will block until the other end tries to read something)

----------
components: Library (Lib)
messages: 117292
nosy: benjamin.peterson, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: Add a pipe type (FIFO) to the io module
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9939>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:21:37 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 24 Sep 2010 15:21:37 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285341697.44.0.782370843992.issue9937@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This happens because RegQueryInfoKeyA returns maximum value
name length in *Unicode* characters. Strange API.

lpcMaxValueNameLen [out, optional]

    A pointer to a variable that receives the size of the key's longest value name, in Unicode characters. The size does not include the terminating null character. This parameter can be NULL.

http://msdn.microsoft.com/en-us/library/ms724902%28VS.85%29.aspx

The Unicode length equals to Ansi length in ascii locale,
so this may not happen where people live in ascii locale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:22:12 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 24 Sep 2010 15:22:12 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285341732.85.0.767008117089.issue9937@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
Removed message: http://bugs.python.org/msg117293

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:26:30 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 24 Sep 2010 15:26:30 +0000
Subject: [issue9939] Add a pipe type (FIFO) to the io module
In-Reply-To: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za>
Message-ID: <1285341990.86.0.837646493437.issue9939@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> It would be a non-seekable in-memory bytes buffer with distinct 
> read and write pointers, so as to act like a system FIFO or a 
> socket.makefile() object.

What would it do when the equivalent system FIFO object would block?

> (you may point to os.pipe() but it has problems such as limited buffer
> size: try to write many bytes to the write end and it will block until
> the other end tries to read something)

In the past, I've gotten around that limitation by using threads (which, admittedly, certainly had its own drawbacks)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9939>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:29:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 15:29:19 +0000
Subject: [issue9815] assertRaises as a context manager keeps tracebacks and
	frames alive
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1285342159.23.0.395983858007.issue9815@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Note that the original issue (test_tarfile failures on the Windows buildbots) now seems fixed thanks to the various tarfile and test_tarfile improvements.

I have no opinion on whether assertRaises should take care of cleaning the tracebacks or not. As the test_tarfile issue shows, the resource consumption issues were tied to actual bugs both in the library and in the test suite.

----------
stage: commit review -> patch review
title: test_tarfile sometimes ends with error "Cannot remove dir" -> assertRaises as a context manager keeps tracebacks and frames alive

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:33:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 15:33:06 +0000
Subject: [issue9939] Add a pipe type (FIFO) to the io module
In-Reply-To: <1285341990.86.0.837646493437.issue9939@psf.upfronthosting.co.za>
Message-ID: <1285342378.3243.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > It would be a non-seekable in-memory bytes buffer with distinct 
> > read and write pointers, so as to act like a system FIFO or a 
> > socket.makefile() object.
> 
> What would it do when the equivalent system FIFO object would block?

Simply buffer everything.
(this is more aimed at mocking sockets than system FIFOs; system FIFOs
can be trivially wrapped in a BufferedRWPair)

> > (you may point to os.pipe() but it has problems such as limited buffer
> > size: try to write many bytes to the write end and it will block until
> > the other end tries to read something)
> 
> In the past, I've gotten around that limitation by using threads
> (which, admittedly, certainly had its own drawbacks)

Sure, but that's a lot of complication in itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9939>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:35:10 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 24 Sep 2010 15:35:10 +0000
Subject: [issue9939] Add a pipe type (FIFO) to the io module
In-Reply-To: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za>
Message-ID: <1285342510.51.0.143061337471.issue9939@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The _multiprocessing module already have similar objects.
_multiprocessing.Connection is based on file descriptors (and initialized with the result of os.pipe())
_multiprocessing.PipeConnection uses Windows named pipes.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9939>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:36:38 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 24 Sep 2010 15:36:38 +0000
Subject: [issue9939] Add a pipe type (FIFO) to the io module
In-Reply-To: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za>
Message-ID: <1285342598.3.0.661031307388.issue9939@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> Simply buffer everything.

That works for when a write operation would block.  What would it do when a read operation would block?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9939>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:41:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 15:41:56 +0000
Subject: [issue9940] Strange error reporting with "with" statement
In-Reply-To: <1285342916.31.0.472051249531.issue9940@psf.upfronthosting.co.za>
Message-ID: <1285342916.31.0.472051249531.issue9940@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Under 3.2 and 3.1:

>>> with open("foo", "wb") as x: pass
... 
>>> with open("foo", "wb") as (x, y): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: read

Similar oddities under 2.7:

>>> with open("foo", "wb") as (x, y): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: File not open for reading
>>> with io.open("foo", "wb") as (x, y): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: read

----------
components: Interpreter Core, Library (Lib)
messages: 117299
nosy: benjamin.peterson, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: Strange error reporting with "with" statement
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9940>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:44:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 15:44:31 +0000
Subject: [issue9939] Add a pipe type (FIFO) to the io module
In-Reply-To: <1285342598.3.0.661031307388.issue9939@psf.upfronthosting.co.za>
Message-ID: <1285343063.3243.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Simply buffer everything.
> 
> That works for when a write operation would block.  What would it do
> when a read operation would block?

Good question. It could either return an empty bytes object, or perhaps
raise EOFError (it could be a constructor argument).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9939>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:48:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 15:48:04 +0000
Subject: [issue9939] Add a pipe type (FIFO) to the io module
In-Reply-To: <1285342510.51.0.143061337471.issue9939@psf.upfronthosting.co.za>
Message-ID: <1285343279.3243.16.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The _multiprocessing module already have similar objects.
> _multiprocessing.Connection is based on file descriptors (and initialized with the result of os.pipe())
> _multiprocessing.PipeConnection uses Windows named pipes.

_multiprocessing.Connection exposes a socket-like API (recv/send) rather
than file-like (read/write/etc.).
Furthermore, _multiprocessing isn't available everywhere; and I wouldn't
really trust it in terms of stability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9939>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:54:01 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 24 Sep 2010 15:54:01 +0000
Subject: [issue9939] Add a pipe type (FIFO) to the io module
In-Reply-To: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za>
Message-ID: <1285343641.59.0.2808290227.issue9939@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Another option would be to have the read-end act like a non-blocking socket (i.e., raise EAGAIN).

Since it would mostly be for testing, would it make more sense to add it to test.support or someplace similar instead of io?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9939>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:59:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 15:59:37 +0000
Subject: [issue9939] Add a pipe type (FIFO) to the io module
In-Reply-To: <1285343641.59.0.2808290227.issue9939@psf.upfronthosting.co.za>
Message-ID: <1285343972.3243.21.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Another option would be to have the read-end act like a non-blocking
> socket (i.e., raise EAGAIN).
> 
> Since it would mostly be for testing, would it make more sense to add
> it to test.support or someplace similar instead of io?

I thought it might be useful for third-party libraries, or even
non-testing situations (although obviously the latter wouldn't be very
common). But, yes, a starting point could be test.support. It would also
avoid having to write unit tests and docs :)
In this case, I would like to do it as a part of the nntplib patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9939>
_______________________________________

From report at bugs.python.org  Fri Sep 24 18:11:04 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 24 Sep 2010 16:11:04 +0000
Subject: [issue9926] Wrapped TestSuite subclass does not get __call__ executed
In-Reply-To: <1285252368.31.0.189981048833.issue9926@psf.upfronthosting.co.za>
Message-ID: <1285344664.53.0.417350484521.issue9926@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Ok, so here is an idea that could remove the need for TestSuite._wrapped_run. 

TestSuite.run could "tag" the result object (set an attribute). Nested TestSuites would see an already tagged suite and do nothing (beyond running tests of course). The suite that does the tagging would call the necessary module / class level test suites on exit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9926>
_______________________________________

From report at bugs.python.org  Fri Sep 24 18:11:49 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 24 Sep 2010 16:11:49 +0000
Subject: [issue9939] Add a pipe type (FIFO) to the io module
In-Reply-To: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za>
Message-ID: <1285344709.72.0.263168499292.issue9939@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> I thought it might be useful for third-party libraries, or even
> non-testing situations 

That might be true, but I prefer that we give code a more vigorous exercise before putting it in the standard library proper.  When we try to use it for something more than nntplib tests we might find that we need to alter its behavior slightly or flesh out the functionality more.

> But, yes, a starting point could be test.support. It would also
> avoid having to write unit tests and docs :)

+1 from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9939>
_______________________________________

From report at bugs.python.org  Fri Sep 24 18:12:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 16:12:57 +0000
Subject: [issue9936] trace misreports "missing" lines
In-Reply-To: <1285296955.25.0.310844622187.issue9936@psf.upfronthosting.co.za>
Message-ID: <1285344777.29.0.116055214532.issue9936@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: unit test needed -> commit review
Added file: http://bugs.python.org/file18998/issue9936a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9936>
_______________________________________

From report at bugs.python.org  Fri Sep 24 18:38:22 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 24 Sep 2010 16:38:22 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1285346302.04.0.349531830387.issue9552@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you, I've committed in r84993(py3k)
I'll close this issue after merging to other branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9552>
_______________________________________

From report at bugs.python.org  Fri Sep 24 18:39:47 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 24 Sep 2010 16:39:47 +0000
Subject: [issue9940] Strange error reporting with "with" statement
In-Reply-To: <1285342916.31.0.472051249531.issue9940@psf.upfronthosting.co.za>
Message-ID: <1285346387.02.0.0227751052466.issue9940@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Of course, you get the same error with:

>>> f = open('foo', 'wb')
>>> x, y = f
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: File not open for reading

i.e. the tuple assignment iterates over the file, and calls readline()

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9940>
_______________________________________

From report at bugs.python.org  Fri Sep 24 18:56:29 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 24 Sep 2010 16:56:29 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285347389.42.0.696166592125.issue9937@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This happens because RegQueryInfoKeyA returns maximum value
name length not in *Ansi* characters but in *Unicode" characters.
I don't know clue why.

http://msdn.microsoft.com/en-us/library/ms724902%28VS.85%29.aspx

In multibyte environment, 2 or 3 bytes characters are
mapped to one size unicode. So usually, the length of *Ansi*
characters are larger than or equals to the length of *Unicode*
characters. If every Ansi characters are mapped to one size
Unicode, lengthes are equal, so probably this issue won't happen.

I'll attach the patch to fix this issue. But be care, this is not 
tested so densely. At least, the script to reproduce this issue
ran fine.

----------
keywords: +patch
Added file: http://bugs.python.org/file18999/py27_winreg_EnumValue.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Fri Sep 24 18:57:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 16:57:48 +0000
Subject: [issue9941] Unify trace and profile interfaces
In-Reply-To: <1285347468.19.0.483467963743.issue9941@psf.upfronthosting.co.za>
Message-ID: <1285347468.19.0.483467963743.issue9941@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The trace and profile modules provide similar functionality, but have some gratuitous differences in their APIs and command line interfaces.

For example, the method to trace a single call is Trace.runfunc, but almost identical Profile method is called "runcall".

The CLIs provided by the two modules are vastly different: profile splits out formatting of the results into a separate module, pstats, while trace module includes many options to control the output of traced runs.

This situation leeds to an unnecessary burden on users who need to learn two different ways to do very similar things.

----------
assignee: belopolsky
components: Library (Lib)
messages: 117309
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Unify trace and profile interfaces
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9941>
_______________________________________

From report at bugs.python.org  Fri Sep 24 19:00:41 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 24 Sep 2010 17:00:41 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285347641.07.0.470781951979.issue9937@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Again, I'm not sure this is right fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Fri Sep 24 19:01:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 17:01:19 +0000
Subject: [issue9941] Unify trace and profile interfaces
In-Reply-To: <1285347468.19.0.483467963743.issue9941@psf.upfronthosting.co.za>
Message-ID: <1285347679.1.0.46586904957.issue9941@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The runfunc/runcall difference is the easiest to address.  I propose to add runcall to Trace as an alias to runfunc and deprecate runfunc.  In addition, I propose to add __enter__ and __exit__ methods to both Trace and Profile so that they can be used as context managers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9941>
_______________________________________

From report at bugs.python.org  Fri Sep 24 19:25:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 17:25:07 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285349107.42.0.815090185083.issue6608@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

MunSic,

Your patch does not apply cleanly to the py3k branch.  Please not that new features can only go to py3k.  While some may argue that this issue is a bug, I think it is more likely that it will only be accepted for 3.2.  In any case, a py3k patch should be the starting point.  Could you post a patch agains the py3k branch?

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Fri Sep 24 19:30:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 17:30:10 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285349410.93.0.9838091546.issue6608@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Hmm, it looks like issue6608-timemodule-2nd.patch is a patch on top of your previous patches.  I'll check if I can apply last three patches in order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Fri Sep 24 19:33:42 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Sep 2010 17:33:42 +0000
Subject: [issue9940] Strange error reporting with "with" statement
In-Reply-To: <1285342916.31.0.472051249531.issue9940@psf.upfronthosting.co.za>
Message-ID: <1285349622.72.0.124800108911.issue9940@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I would say it's strange but correct. (and unavoidable I think)

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9940>
_______________________________________

From report at bugs.python.org  Fri Sep 24 19:36:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 17:36:31 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285349791.82.0.610467480111.issue6608@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

No, it looks like the starting patch is against 2.7.  We need a py3k patch.  Meanwhile, I've noticed a couple of grammatical mistakes in comments:

"strftime(), asctime() does not" -> "strftime() and asctime() do not"
"fixes bug #897625, #6608" -> "fixes bugs #897625 and #6608"

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Fri Sep 24 19:52:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Sep 2010 17:52:12 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1285350732.37.0.400690396746.issue9784@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1 for the patch. I still maintain that it is better to follow the current SDK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Fri Sep 24 19:52:39 2010
From: report at bugs.python.org (Kevin Hunter)
Date: Fri, 24 Sep 2010 17:52:39 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>


New submission from Kevin Hunter <hunteke at earlham.edu>:

Should Python enable a way for folks to inform the OS of MADV_MERGEABLE memory?

I can't speak for other OSs, but Linux added the ability for processes to inform the kernel that they have memory that will likely not change for a while in 2.6.32.  This is done through the madvise syscall with MADV_MERGEABLE.

http://www.kernel.org/doc/Documentation/vm/ksm.txt

After initial conversations in IRC, it was suggested that this would be difficult in the Python layer, but that the OS doesn't care what byte page it's passed as "mergeable".  Thus when I, as an application programmer, know that I have some objects that will be around "for awhile", and that won't change, I can let the OS know that it might be beneficial to merge them.

I suggest this might be a library because it may only be useful for certain projects.

----------
components: Library (Lib)
messages: 117317
nosy: hunteke
priority: normal
severity: normal
status: open
title: Allow memory sections to be OS MERGEABLE
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Fri Sep 24 20:04:06 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 24 Sep 2010 18:04:06 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1285351446.76.0.700853212179.issue9942@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

With CPython, even objects that don't change see their reference counter modified quite frequently, just by looking at them.
What kind of memory would you mark this way?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Fri Sep 24 20:07:46 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 24 Sep 2010 18:07:46 +0000
Subject: [issue9418] Move _formatter_* methods from string type into _string
	module
In-Reply-To: <1280416899.1.0.0890176421306.issue9418@psf.upfronthosting.co.za>
Message-ID: <1285351666.52.0.636687226189.issue9418@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The more I think about this, the more sense it makes to leave the module in unicodeobject.c. Certainly all the code it's likely to ever contain would already be in unicodeobject.c.

While I agree there's some conceptual clarity to be had by having the code in a new Modules/_stringmodule.c (and indeed, that's the first place I'd go if I were looking for it), I think that practically it might make sense to leave it in unicodeobject.c.

On the other hand, there are no modules defined in Objects/*.c, so this is clearly an unusual and unexpected practice.

Maybe a first step would be to commit Georg's patch as-is. Later I'll get rid of stringlib (at least for format()), then at that point rethink where any module should live.

I note that Georg's code doesn't need any tests because the affected code in string.py is already tested and will fail if the module is moved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9418>
_______________________________________

From report at bugs.python.org  Fri Sep 24 20:12:46 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 24 Sep 2010 18:12:46 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1285351966.48.0.780756507042.issue3873@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I get this error with the patch:

python: /home/alex/src/python.org/py3k/Modules/_pickle.c:908: _Unpickler_ReadFromFile: Assertion `self->next_read_idx == 0' failed.
Aborted

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Fri Sep 24 20:15:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 18:15:51 +0000
Subject: [issue9936] trace misreports "missing" lines
In-Reply-To: <1285296955.25.0.310844622187.issue9936@psf.upfronthosting.co.za>
Message-ID: <1285352151.84.0.440539036038.issue9936@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Fixed in r84994, r84995 (3.1) and r84996 (2.7).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9936>
_______________________________________

From report at bugs.python.org  Fri Sep 24 20:23:31 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Sep 2010 18:23:31 +0000
Subject: [issue9926] Wrapped TestSuite subclass does not get __call__ executed
In-Reply-To: <1285256805.92.0.256732788553.issue9926@psf.upfronthosting.co.za>
Message-ID: <4C9CEC9F.3090209@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Perhaps slightly ironically (for this particular bug report) is that
> the change was introduced to support class and module level setUp and
> tearDown (similar to the use-case it now blocks).

FWIW, this issue arrived from pygresql, see TestSuite2 in
http://tinyurl.com/2ap9t6d

Here, the objective is to wrap a number of test suite classes
with a single setup/teardown, covering all test cases that occur
in either test suite, so that the expensive database creation
happens only once. I can't see how either class or module level
setup could easily replace this.

> A backwards compatible change would be to rename BaseTestSuite *back*
> to TestSuite and give the current TestSuite a new name.

That sounds good to me.

> The disadvantage of this approach is that it is not uncommon for test
> frameworks to create suites themselves - and doing this could 'break'
> tests using class / module fixtures.

You mean, for test suites that have been modified to explicitly
support Python 2.7?

> Any other suggestions or ideas?

I think this would then be for python-dev to discuss.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9926>
_______________________________________

From report at bugs.python.org  Fri Sep 24 20:25:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 18:25:02 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1285352702.65.0.0609245830442.issue3873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, thank you. I hadn't tested in debug mode and there was a wrong assert from the previous code.
Here is a patch with the assert removed.

----------
versions: +Python 3.2 -Python 3.1
Added file: http://bugs.python.org/file19000/unpickleprefetch2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Fri Sep 24 20:32:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Sep 2010 18:32:14 +0000
Subject: [issue9783] _elementtree.c warnings under 64-bit Windows
In-Reply-To: <1285293633.89.0.14013025074.issue9783@psf.upfronthosting.co.za>
Message-ID: <4C9CEEAB.9080500@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> issue9783.diff provides a patch that will compile clean on 32 and 64
> bit Windows systems.  I tried to avoid explicit casts where I could,
> but it was not always possible. I have ported a lot of my company's
> code to 64 bit (all Windows based).  In my experience many warnings
> are because of programmers using the int type in places where a
> size_t may be more appropriate. Most of the warnings here are due to
> mixing int and Py_ssize_t types.

I think the patch is incorrect as it stands: the casts may cause
truncation. As you say, int is still being used where size_t was
more appropriate, so I think we should change it in that manner
(e.g. make element_resize accept Py_ssize_t).

In cases where we really can't propagate Py_ssize_t to (e.g.
XML_Parse), we need to check for an int overflow, and raise
an exception if it does overflow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9783>
_______________________________________

From report at bugs.python.org  Fri Sep 24 20:36:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 24 Sep 2010 18:36:12 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1285353372.01.0.637286296723.issue8879@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

In a round-about way, that's what the tests do via sameopenfile.

Maybe the behavior of os.path.samefile for Windows hard links should be documented? Possibly just a small note explaining that os.path.sameopenfile is an alternate solution due to how GetFinalPathNameByHandle works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Fri Sep 24 21:15:29 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 24 Sep 2010 19:15:29 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1285355729.43.0.308825332313.issue9923@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the patches.  Can you also add a test case to Lib/test/mailcap.py to cover this problem?

----------
nosy: +ned.deily
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Fri Sep 24 21:44:19 2010
From: report at bugs.python.org (Geoffrey Bache)
Date: Fri, 24 Sep 2010 19:44:19 +0000
Subject: [issue9943] TypeError message became less helpful in Python 2.7
In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za>
Message-ID: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za>


New submission from Geoffrey Bache <gjb1002 at users.sourceforge.net>:

Consider the following code:

### keywords.py

def f(**kw):
    print arg, kw

f("hello", keyword=True)

and compare the behaviour in Python 2.6 and Python 2.7:

$ python keywords.py 
Traceback (most recent call last):
  File "keywords.py", line 5, in <module>
    f("hello", keyword=True)
TypeError: f() takes exactly 0 non-keyword arguments (1 given)

$ python2.7 keywords.py
Traceback (most recent call last):
  File "keywords.py", line 5, in <module>
    f("hello", keyword=True)
TypeError: f() takes exactly 0 arguments (2 given)

The error message from 2.6 is I would say a more accurate description of the situation.

----------
components: Interpreter Core
messages: 117327
nosy: gjb1002
priority: normal
severity: normal
status: open
title: TypeError message became less helpful in Python 2.7
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9943>
_______________________________________

From report at bugs.python.org  Fri Sep 24 21:58:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Sep 2010 19:58:40 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285358320.35.0.0285446691881.issue9864@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

http://launchpad.net/python-email6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Fri Sep 24 22:15:55 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 24 Sep 2010 20:15:55 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1285359355.1.0.991060533957.issue6706@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Here's a rewriting attempt (not tested).
Now that I look at it I must say it's quite ugly, so I don't think we should follow this road.
An alternative I see is to return None in case of errors occurring on accept() and make this very clear in doc. 
Other than accept(), doc should explicitly show how to use handle_accept() in general, which would end up looking like this:

class SomeServer(asyncore.dispatcher):
    
    ...

    def handle_accept():
       conn = self.accept()
       if conn is None:
           return
       else:
           sock, addr = conn
       ...

    ...


A completely different approach could be to provide a new "TCPServer" class which deprecates direct accept() method usage. Something like this:


class TCPServer(asyncore.dispatcher):

    def __init__(self, ip, port, handler, interface='', map=None):
        asyncore.dispatcher.__init__(self, map=map)
        self.create_socket(family=socket.AF_INET, type=socket.SOCK_STREAM)
        self.bind((ip, port))
        self.listen(5)
        self.handler = handler

    def handle_accept(self):
        try:
            sock, addr = self.accept()
        except TypeError:
            return
        except socket.error, err:
            if err[0] != errno.ECONNABORTED:
                raise
            return
        else:
            if addr == None:
                return
        handler = self.handler(conn, self._map)

    def writable(self):
        return 0



...but for some reason I don't like it either. Point is asyncore API design is fundamentally wrong and there's nothing we can do about it unless we break backward compatibility or a brand new "asyncore2" module is written.

----------
keywords: +patch
nosy: +pitrou
Added file: http://bugs.python.org/file19001/accept.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Fri Sep 24 22:29:40 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 24 Sep 2010 20:29:40 +0000
Subject: [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1285360180.6.0.913551492306.issue9938@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


----------
nosy: +bethard
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Fri Sep 24 22:40:21 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Sep 2010 20:40:21 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1285360821.81.0.434135183818.issue9896@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Range objects are new in 3.0; they supersede 2.x xrange objects, which are perhaps 10 years old. I do not remember that xrange objects had such attributes. On the other hand, I believe there were requests.

The request, with either implementation, seems reasonable in that range objects could be regarded as iterable slice objects. The differences are that range objects have __getitem__, __iter__, and __reversed__ special methods while slice objects have start, stop, and stop real-only attributes and the indices method. (I could not really understand the last from the doc; I had to experiment.) Starting fresh, we might do with just one class instead of two.

I guess this makes me +0.3 at the moment.

----------
nosy: +terry.reedy
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Fri Sep 24 22:42:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Sep 2010 20:42:04 +0000
Subject: [issue9889] PyUnicode_FormatV and Py_UNICODE*?
In-Reply-To: <1284751931.03.0.894481141092.issue9889@psf.upfronthosting.co.za>
Message-ID: <1285360924.51.0.655899148649.issue9889@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/issue9889>
_______________________________________

From report at bugs.python.org  Fri Sep 24 22:47:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 20:47:56 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1285361276.88.0.207584946922.issue9360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch adding tests for article(), head() and body(), as well as for the "file" parameter.
As far as code is concerned, this should now be complete. Documentation remains to be updated :)

----------
Added file: http://bugs.python.org/file19002/nntplib_cleanup6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Fri Sep 24 23:18:51 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Sep 2010 21:18:51 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285363131.32.0.476646445459.issue9915@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The posted experiments on sorted data do not do any sorting. They only test the difference in setup and comparison speed and not sorting/swapping speed. Please post something with large arrays of random data.

Since the patch is intended to speed up 3.2 and your posted experiments were run on that, I am puzzled that you would post a test script to run under late 2.x instead of 3.1+.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Fri Sep 24 23:26:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Sep 2010 21:26:43 +0000
Subject: [issue9925] Idle doesn't launch
In-Reply-To: <1285249574.15.0.491090079116.issue9925@psf.upfronthosting.co.za>
Message-ID: <1285363603.4.0.376121006761.issue9925@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9925>
_______________________________________

From report at bugs.python.org  Fri Sep 24 23:29:31 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Sep 2010 21:29:31 +0000
Subject: [issue9934] Python Docs Typo
In-Reply-To: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>
Message-ID: <1285363771.06.0.993171908712.issue9934@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +easy, patch
stage:  -> needs patch
versions:  -Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9934>
_______________________________________

From report at bugs.python.org  Fri Sep 24 23:30:24 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Sep 2010 21:30:24 +0000
Subject: [issue9934] Python Docs Typo
In-Reply-To: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>
Message-ID: <1285363824.55.0.945830167727.issue9934@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Agreed. Should happen sometime. Thanks for catching this.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9934>
_______________________________________

From report at bugs.python.org  Fri Sep 24 23:30:34 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 24 Sep 2010 21:30:34 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285363834.78.0.754537553735.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> Since the patch is intended to speed up 3.2 and your posted 
> experiments were run on that, I am puzzled that you would post a
> test script to run under late 2.x instead of 3.1+.

I had originally written the test script was originally written for something else and repurposed it.  Actually, it's been repurposed at least twice so it has a long history and an unfortunate amount of cruft.  I will work on porting it to run on py3k.

My original examples did not use random data because timeit is challenging to use to time sorting of random data and I wanted to post something relatively concise.

Sometime next week I plan to post extensive timing results on random data.  I have been working on some fine-tuning of my patch as well as to my timing script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Fri Sep 24 23:49:51 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Sep 2010 21:49:51 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285364991.19.0.534160911948.issue9915@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Does this help any?
>>> import random
>>> from timeit import timeit
>>> testlist = list(range(100000))
>>> random.shuffle(testlist)
>>> timeit('t=list(testlist); t.sort()',
    'from __main__ import testlist', number=1)
0.1467957519740679

I just learned the import trick from the tracker issue suggesting that it be made more prominent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Sat Sep 25 00:02:18 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 24 Sep 2010 22:02:18 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285365738.52.0.0031136682724.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> Does this help any?

No :-)

The problem is that the random data you run in interpreter 1 won't be the same data you run in interpreter 2, so the results are not directly comparable.  One of the sets of random data may be more easily sortable than the other.

That leaves two options:
1. save the random data to a file and use it in both interpreters, or
2. run a sufficiently large number of tests, with new random data for each test, such that you get a good measurement of the time required to sort average random data

I have been using approach #2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Sat Sep 25 00:05:11 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 24 Sep 2010 22:05:11 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285365911.21.0.389789426462.issue9915@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> the random data you run in interpreter 1 won't be the same data
> you run in interpreter 2

what about adding a simple "random.seed(12345)"

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Sat Sep 25 00:12:23 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 24 Sep 2010 22:12:23 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285366343.95.0.780828131679.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> what about adding a simple "random.seed(12345)"

That's an excellent suggestion!  In fact, I'm embarrassed that it never occurred to me (especially since I have used it in other projects).

I will have a revised speed_test along with more extensive measurement results sometime next week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Sat Sep 25 00:15:44 2010
From: report at bugs.python.org (Jon Clements)
Date: Fri, 24 Sep 2010 22:15:44 +0000
Subject: [issue9944] Typo in doc for itertools recipe of consume
In-Reply-To: <1285366544.01.0.313980902629.issue9944@psf.upfronthosting.co.za>
Message-ID: <1285366544.01.0.313980902629.issue9944@psf.upfronthosting.co.za>


New submission from Jon Clements <joncle at googlemail.com>:

Very low priority.

def consume(iterator, n):
    "Advance the iterator n-steps ahead. If n is none, consume entirely."
    # Use functions that consume iterators at C speed.
    if n is None:
        # feed the entire iterator into a zero-length deque
        collections.deque(iterator, maxlen=0)
    else:
        # advance to the emtpy slice starting at position n
        next(islice(iterator, n, n), None)

Hardly a show stoppper, and not me worth submitting a patch, but "emtpy" should be "empty". Just thought I'd make note of it before I forgot.

----------
assignee: docs at python
components: Documentation
messages: 117339
nosy: docs at python, joncle
priority: normal
severity: normal
status: open
title: Typo in doc for itertools recipe of consume
versions: Python 2.5, 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/issue9944>
_______________________________________

From report at bugs.python.org  Sat Sep 25 00:33:04 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 24 Sep 2010 22:33:04 +0000
Subject: [issue9926] Wrapped TestSuite subclass does not get __call__ executed
In-Reply-To: <4C9CEC9F.3090209@v.loewis.de>
Message-ID: <4C9D2715.1010901@voidspace.org.uk>


Michael Foord <michael at voidspace.org.uk> added the comment:

On 24/09/2010 19:23, Martin v. L?wis wrote:
> Martin v. L?wis<martin at v.loewis.de>  added the comment:
>> Perhaps slightly ironically (for this particular bug report) is that
>> the change was introduced to support class and module level setUp and
>> tearDown (similar to the use-case it now blocks).
> FWIW, this issue arrived from pygresql, see TestSuite2 in
> http://tinyurl.com/2ap9t6d

Thanks.

Heh, well - allowing multiple testcases to share fixtures like expensive 
databases was one of the primary use cases given for introducing 
setUpModule and setUpClass.

>> A backwards compatible change would be to rename BaseTestSuite *back*
>> to TestSuite and give the current TestSuite a new name.
> That sounds good to me.
>

As I mentioned, the introduction of _wrapped_run to TestSuite has been 
released in Python 2.7 - so I don't think that we can pursue this option.

>> The disadvantage of this approach is that it is not uncommon for test
>> frameworks to create suites themselves - and doing this could 'break'
>> tests using class / module fixtures.
> You mean, for test suites that have been modified to explicitly
> support Python 2.7?
>

No, I just mean that directly creating test collections using TestSuite 
is a common thing for test frameworks to do. If the base TestSuite 
didn't support class / module fixtures then these test frameworks would 
no longer be able to use these features.

>> Any other suggestions or ideas?
> I think this would then be for python-dev to discuss.
>

I think the result tagging idea will work both as a bugfix for 2.7 and 
3.2. I'll work on a  patch and test. If it doesn't work we can take it 
to python-dev, but bearing in mind that we have to remain compatible 
with the released 2.7 as well (i.e. not changing the behaviour of 
TestSuite drastically).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9926>
_______________________________________

From report at bugs.python.org  Sat Sep 25 00:42:39 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 24 Sep 2010 22:42:39 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1285368159.2.0.0492365410642.issue9784@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Which "SDK Example" are you referring to? I could not find any example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Sat Sep 25 00:54:49 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Sep 2010 22:54:49 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1285368889.07.0.40130176057.issue9784@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

See, for example, the link you gave in msg115750. It has this sample code in it (listed in the "Examples" section):

FNFCIREAD(fnFileRead)
{
    DWORD dwBytesRead = 0;

    UNREFERENCED_PARAMETER(pv);

    if( ReadFile((HANDLE)hf, memory, cb, &dwBytesRead, NULL) == FALSE )
    {
        dwBytesRead = (DWORD)-1;
        *err = GetLastError();
    }
		 
    return dwBytesRead;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Sat Sep 25 03:10:52 2010
From: report at bugs.python.org (Jon Anglin)
Date: Sat, 25 Sep 2010 01:10:52 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1285377052.31.0.352382282021.issue9784@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

Martin Lowis do you mean API when you type SDK?  If I understand what you are saying, you would rather use the Win32 API instead of the CRT API?  

It may interest you to know that _open calls CreateFile internally, _read calls ReadFile, _write calls WriteFile, _lseek calls SetFilePointer, and _close calls CloseHandle.  There is a bit more to it than that but it is not really relevant to this discussion.

What is relevant is that inside _open, CreateFile will return an OS HANDLE type (64 bits in our case) that is mapped to a 32 bit integer CRT file descriptor that is then returned.  The other functions such as _read, etc?, will look up the 64 bit OS HANDLE value from the given 32 bit file descriptor and call the corresponding Win32 API function.

We could rewrite the functions using the Win32 API directly but we don?t have to.  I realize this is a Windows only module but the use of the CRT API is more familiar to a majority of the Python developers (I would guess).

I stand by the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Sat Sep 25 04:40:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 25 Sep 2010 02:40:33 +0000
Subject: [issue9934] Python Docs Typo
In-Reply-To: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>
Message-ID: <1285382433.78.0.27396611772.issue9934@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in r85002. This was taken care of on py3k a while ago.

----------
assignee: docs at python -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9934>
_______________________________________

From report at bugs.python.org  Sat Sep 25 05:03:44 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 25 Sep 2010 03:03:44 +0000
Subject: [issue9910] Add Py_SetPath API for embeddint python
In-Reply-To: <1285050754.57.0.81319423251.issue9910@psf.upfronthosting.co.za>
Message-ID: <1285383824.87.0.422544004856.issue9910@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Right, forgot about getpath.c.
Added documentation.
See the latest version of the patch.
Please note that I was unable to test the non-windows compile.

----------
Added file: http://bugs.python.org/file19003/py_setpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9910>
_______________________________________

From report at bugs.python.org  Sat Sep 25 05:15:15 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Sep 2010 03:15:15 +0000
Subject: [issue9943] TypeError message became less helpful in Python 2.7
In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za>
Message-ID: <1285384515.81.0.117533193336.issue9943@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85003 Thanks for the report.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9943>
_______________________________________

From report at bugs.python.org  Sat Sep 25 05:22:50 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 25 Sep 2010 03:22:50 +0000
Subject: [issue9910] Add Py_SetPath API for embedding python
In-Reply-To: <1285050754.57.0.81319423251.issue9910@psf.upfronthosting.co.za>
Message-ID: <1285384970.05.0.455277058299.issue9910@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
title: Add Py_SetPath API for embeddint python -> Add Py_SetPath API for embedding python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9910>
_______________________________________

From report at bugs.python.org  Sat Sep 25 05:24:20 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Sat, 25 Sep 2010 03:24:20 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285385060.67.0.804907636251.issue6608@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


Removed file: http://bugs.python.org/file18976/issue6608-timemodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Sat Sep 25 05:24:25 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Sat, 25 Sep 2010 03:24:25 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285385065.7.0.659681257025.issue6608@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


Removed file: http://bugs.python.org/file18978/issue6608-testcase.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Sat Sep 25 05:24:29 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Sat, 25 Sep 2010 03:24:29 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285385069.76.0.595168647557.issue6608@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


Removed file: http://bugs.python.org/file18987/issue6608-timemodule-2nd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Sat Sep 25 05:26:27 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Sep 2010 03:26:27 +0000
Subject: [issue9943] TypeError message became less helpful in Python 2.7
In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za>
Message-ID: <1285385187.13.0.489408100173.issue9943@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Reverted, however. Let me clarify: you think the unhelpful part is that the count includes keyword arguments? This change was intentional, actually wrt to cases like this:

    >>> def f(a):
    ...    pass
    >>> f(6, a=4, *(1, 2, 3))
    Traceback (most recent call last):
      ...
    TypeError: f() takes exactly 1 positional argument (5 given)
    >>> def f(a, *, kw):
    ...    pass
    >>> f(6, 4, kw=4)
    Traceback (most recent call last):
      ...
    TypeError: f() takes exactly 1 positional argument (3 given)

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9943>
_______________________________________

From report at bugs.python.org  Sat Sep 25 05:31:06 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Sat, 25 Sep 2010 03:31:06 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285385466.27.0.224336125675.issue6608@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

I uploaded a patch against py3k branch.

Sorry for many "Added file" and "Removed file" mails. I am learning customs Trac now.

----------
Added file: http://bugs.python.org/file19004/issue6608-p3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Sat Sep 25 07:41:31 2010
From: report at bugs.python.org (Kevin Hunter)
Date: Sat, 25 Sep 2010 05:41:31 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1285393291.81.0.300634620473.issue9942@psf.upfronthosting.co.za>


Kevin Hunter <hunteke at earlham.edu> added the comment:

My first thought is "Why is the reference counter stored with the object itself?"  I imagine there are very good reasons, however, and this is not an area in which I have much mastery.

Answering the question as best I can: I don't know how the reference counter is implemented in CPython, but if it's just a field in a struct, then madvise could be sent the memory location starting with the byte immediately following the reference counter.

If there's more to it than that, I'll have to back off with "I don't know."  I'm perhaps embarrassed that I'm not at all a Python developer, merely a Python application developer.  I have a few Python projects that are memory hungry, that at first glance I believe to be creating MERGEABLE objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Sat Sep 25 08:36:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 25 Sep 2010 06:36:00 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1285377052.31.0.352382282021.issue9784@psf.upfronthosting.co.za>
Message-ID: <4C9D984C.2010708@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin Lowis do you mean API when you type SDK?

When I said "SDK examples", then I really meant "examples as published
in the SDK", not "examples as published in the API" (and the SDK
documentation, in turn, is published on msdn).
But yes, the SDK examples use Win32 directly.

> If I understand what you are saying, you would rather use the Win32
> API instead of the CRT API?

Correct.

> It may interest you to know that _open calls CreateFile internally,
> _read calls ReadFile, _write calls WriteFile, _lseek calls
> SetFilePointer, and _close calls CloseHandle. 

I'm fully aware of that.

> We could rewrite the functions using the Win32 API directly but we
> don?t have to.  I realize this is a Windows only module but the use
> of the CRT API is more familiar to a majority of the Python
> developers (I would guess).

I have the long-term plan to eliminate all CRT usage from Python
on Windows. In this case, there is a straight-forward opportunity
to do so. Nothing is really gained from using the CRT (as the cabinet
SDK is probably even less familiar to Python developers than
CreateFile), plus using the CRT causes compiler warnings, as
Microsoft clearly intends that these routines would be implemented
using the Windows API directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Sat Sep 25 12:22:17 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 10:22:17 +0000
Subject: [issue9940] Strange error reporting with "with" statement
In-Reply-To: <1285342916.31.0.472051249531.issue9940@psf.upfronthosting.co.za>
Message-ID: <1285410137.09.0.231800172027.issue9940@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

At least not without losing generality, and we don't like that.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9940>
_______________________________________

From report at bugs.python.org  Sat Sep 25 12:23:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 10:23:15 +0000
Subject: [issue9941] Unify trace and profile interfaces
In-Reply-To: <1285347468.19.0.483467963743.issue9941@psf.upfronthosting.co.za>
Message-ID: <1285410195.57.0.237943271544.issue9941@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sounds good to me.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9941>
_______________________________________

From report at bugs.python.org  Sat Sep 25 12:26:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 10:26:46 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1285410406.97.0.674493112332.issue9942@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> My first thought is "Why is the reference counter stored with the object itself?"

Because if you move the reference counter out of the object, you a) add another indirection and b) depending on how you implement it require a certain amount of memory more per object.

It's far from obvious that the possible benefits are worth this, and needs to be tested carefully, which nobody has done yet.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Sat Sep 25 12:27:52 2010
From: report at bugs.python.org (Geoffrey Bache)
Date: Sat, 25 Sep 2010 10:27:52 +0000
Subject: [issue9943] TypeError message became less helpful in Python 2.7
In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za>
Message-ID: <1285410472.91.0.862591679487.issue9943@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

I think the unhelpful part is mostly that it does not distinguish between argument types any more when the distinction is important in this context. In fact, it could be argued that what it said isn't even true:

f() takes exactly 0 arguments (2 given)

f() doesn't take exactly 0 arguments. It takes any number of arguments, so long as they are keyword arguments.

Surely you agree that the Python 2.6 error describes the problem more accurately?

As for your examples, the message in the first one has changed from

TypeError: f() takes exactly 1 non-keyword argument (4 given)

to 

TypeError: f() takes exactly 1 argument (5 given)

which is possibly a marginal improvement, although taken together I would say this isn't an improvement, especially as I think examples like my first one are more widespread (OK, I didn't even know this syntax was legal...)

Your second example is only legal syntax in Python 3, so I don't really get the point with respect to comparing Python 2.6 and Python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9943>
_______________________________________

From report at bugs.python.org  Sat Sep 25 12:34:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 10:34:45 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1285410885.61.0.662159471861.issue9942@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Answering the question as best I can: I don't know how the reference
> counter is implemented in CPython, but if it's just a field in a
> struct, then madvise could be sent the memory location starting with
> the byte immediately following the reference counter

Well, first, this would only work for large objects. Must objects in Python are quite small individually, unless you have very large (unicode or binary) strings, or very big integers.

Second, madvise() works at the page granularity (4096 bytes on most system), and it will be very likely this will include the reference count for the current object.

Third, MADV_MERGEABLE will only be efficient if you have actual duplications of whole memory pages (and, practically, if you have enough of them to make a real difference). Why do you think you might have such duplication in your workload?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Sat Sep 25 12:37:47 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 25 Sep 2010 10:37:47 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1285411067.78.0.00495719026011.issue6706@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch in attachment makes accept() return None in case no connection takes place and modifies the doc to make this very clear, also providing an example on how an asyncore-based server should be properly set-up .

----------
versions: +Python 2.6
Added file: http://bugs.python.org/file19005/accept.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Sat Sep 25 12:54:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 10:54:45 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1285412085.4.0.536454600811.issue6706@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> EAGAIN can be raised too. I never experienced this error condition 
> myself in pyftpdlib

>From the accept() man page:

EAGAIN or EWOULDBLOCK
              The  socket  is  marked  nonblocking and no connections are present to be accepted.
              POSIX.1-2001 allows either error to be returned for this case, and does not require
              these  constants to have the same value, so a portable application should check for
              both possibilities.

> The resulting address can be None, which means that the connection 
> didn't take place.

The only way this can happen is if the accept() system call returned 0 in addrlen, which sounds rather strange. I'm not convinced hiding operating system bugs is a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Sat Sep 25 13:09:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 11:09:26 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1285412966.24.0.543938218381.issue9931@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pmoore
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Sat Sep 25 13:12:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 11:12:35 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1285413155.78.0.78564688417.issue8445@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sat Sep 25 13:12:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 11:12:53 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1285413173.86.0.370432383569.issue8423@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Sat Sep 25 13:43:41 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 25 Sep 2010 11:43:41 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1285415021.97.0.618894500609.issue6706@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> I'm not convinced hiding operating system bugs is a good idea.

Do you propose to let the error raise then?
The point of frameworks such as asyncore and twisted is to hide all system-specific errors as much as possible and provide a portable interface across all platforms.
AFAICT, the whole point of this issue is that there should be only one way for an asyncore-based server to accept an incoming connection, possibly avoiding the user to deal with low-level details such as catching EWOULDBLOCK/ECONNABORTED/... in his application, and looking for accept() returning None is one possibility.

As I said, in a better designed framework the user shouldn't be supposed to call accept() at all, but that's how asyncore is designed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Sat Sep 25 13:56:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 11:56:49 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1285415021.97.0.618894500609.issue6706@psf.upfronthosting.co.za>
Message-ID: <1285415803.3192.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The point of frameworks such as asyncore and twisted is to hide all
> system-specific errors as much as possible and provide a portable
> interface across all platforms.

As long as these errors are reasonably explainable.
If a strange error only occurs when running nmap on an OS X server, then
it might be useful for the user to know that the OS X server isn't able
to service all connections properly due to a bug in the operating
system.

> AFAICT, the whole point of this issue is that there should be only one
> way for an asyncore-based server to accept an incoming connection,
> possibly avoiding the user to deal with low-level details such as
> catching EWOULDBLOCK/ECONNABORTED/...

I am talking specifically about the address being None (i.e., a (sock,
None) tuple is successfully returned).
EWOULDBLOCK and ECONNABORTED are documented error conditions for
accept(), but returning 0 in addrlen is not.

> As I said, in a better designed framework the user shouldn't be
> supposed to call accept() at all, but that's how asyncore is designed.

Perhaps it's time to add an alternative handle_accepted(sock, addr)
which relieves the user from calling accept() :))
Then, perhaps self.accept() shouldn't filter any errors at all, but the
default handle_accept() would silence them before calling
handle_accepted().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Sat Sep 25 14:34:55 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 25 Sep 2010 12:34:55 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1285418095.71.0.71464011493.issue6706@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> As long as these errors are reasonably explainable.
> If a strange error only occurs when running nmap on an OS X server, 
> then it might be useful for the user to know that the OS X server 
> isn't able to service all connections properly due to a bug in the 
> operating system.

It might be useful to find whether this is tracked somewhere.
For the record, here (comment #10) is a code which should reproduce this problem:
https://bugs.launchpad.net/zodb/+bug/135108
As for what asyncore should in this case I think it should theoretically be safe for accept() to return (sock, None). What usually happen after that is that the socket object is passed to another dispatcher subclass (the handler) and the connection gets automatically closed once recv() or send() get called on the next async-loop.

> Perhaps it's time to add an alternative handle_accepted(sock, addr)
> which relieves the user from calling accept() :))

This sounds like a very good idea for 3.2.
As for 3.1 and 2.7 (2.6?) I think it can be useful to suppress EWOULDBLOCK/ECONNABORTED and return None instead.
Considering accept() can *already* return None it wouldn't break backward compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Sat Sep 25 14:53:55 2010
From: report at bugs.python.org (Jon Anglin)
Date: Sat, 25 Sep 2010 12:53:55 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1285419235.07.0.691501762457.issue9784@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

> I have the long-term plan to eliminate all CRT usage from Python
> on Windows. In this case, there is a straight-forward opportunity
> to do so.

Oh, OK. If that is the plan then I am on board. I will re-code the patch using the Win32 API directly.

>> It may interest you to know that _open calls CreateFile internally,
> I'm fully aware of that.

I meant no disrespect, I just didn't know if you were a "Windows" guy. If you asked me what system call _open (or others) calls on Linux or Mac, I would have no clue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Sat Sep 25 15:07:08 2010
From: report at bugs.python.org (Jon Anglin)
Date: Sat, 25 Sep 2010 13:07:08 +0000
Subject: [issue9783] _elementtree.c warnings under 64-bit Windows
In-Reply-To: <1283777393.95.0.65520363014.issue9783@psf.upfronthosting.co.za>
Message-ID: <1285420028.44.0.844166355961.issue9783@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

Martin is correct about this patch.

> In cases where we really can't propagate Py_ssize_t to (e.g.
> XML_Parse), we need to check for an int overflow, and raise
> an exception if it does overflow.

Is this an appropriate approach?

int
PySize_AsInt(Py_ssize_t value)
{
    if (value > (Py_ssize_t)INT_MAX || value < (Py_ssize_t)INT_MIN) {
        PyErr_SetString(PyExc_OverflowError, 
                        "Size value can not be represented as an integer");
    }
    return (int)value;
}

I would only define this when sizeof(Py_ssize_t) > sizeof(int) of course. In other cases it would be a macro that just evaluates to value.
I would most likely need an unsigned version as well (although not for this particular issue).

This code could be used in many C modules. Where in the Python code base should such functions be placed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9783>
_______________________________________

From report at bugs.python.org  Sat Sep 25 15:23:07 2010
From: report at bugs.python.org (Jan-Philip Gehrcke)
Date: Sat, 25 Sep 2010 13:23:07 +0000
Subject: [issue6634] sys.exit() called from threads other than the main one:
	undocumented behaviour
In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>
Message-ID: <1285420987.43.0.0682498030093.issue6634@psf.upfronthosting.co.za>


Jan-Philip Gehrcke <jgehrcke at gmail.com> added the comment:

Sorry for the delay.

Before suggesting a doc change to correct/complete the description of the *current* situation, we actually should consider changing this situation. I think this is reasonable and I feel encouraged by Gabriel Genellina:

> I see no reason for sys.exit("msg") NOT to write to stderr
> inside a child thread.

This patch enables printing to stderr from child threads and clones the behavior of `sys.exit(arg)` called from the main thread:

# PATCH BEGIN
--- C:/Python27/Lib/threading.py    Sat Apr 10 18:55:48 2010
+++ C:/python_sys_exit_issue/threading.py    Sat Sep 25 14:50:24 2010
@@ -531,6 +531,15 @@
 except SystemExit:
     if __debug__:
         self._note("%s.__bootstrap(): raised SystemExit", self)
+    # Now get and handle the "exit code", given by the user via
+    # the second expression after `raise` or via the argument of 
+    # sys.exit().
+    code = self.__exc_info()[1].code
+    # Ignore None and integer exit code. Print any other object
+    # to stderr as it is the behavior of sys.exit(arg) called
+    # from the main thread.
+    if code is not None and not isinstance(code, int):
+        _sys.stderr.write("%s\n" % code)
 except:
     if __debug__:
         self._note("%s.__bootstrap(): unhandled exception", self)
# PATCH END

A script with different testcases including output is attached.

What do you think?

All the best,

Jan-Philip Gehrcke

----------
Added file: http://bugs.python.org/file19006/thread_sys_exit_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6634>
_______________________________________

From report at bugs.python.org  Sat Sep 25 15:27:33 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 25 Sep 2010 13:27:33 +0000
Subject: [issue9945] Improper locking in logging
In-Reply-To: <1285421253.55.0.777992318976.issue9945@psf.upfronthosting.co.za>
Message-ID: <1285421253.55.0.777992318976.issue9945@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

I found a a useless lock acquiring in the 27 maintenance branch in logging and a missing one as well:

Logger.removeHandler() locks around a handler lock, however the code executed in this lock is not depending on anything of that lock.  However there is a race condition when two pieces of code try to remove the same handler at the same time because between the if and the remove() no locking takes place.

I would recommend this instead (and also add locking to the addHandler):

    def addHandler(self, hdlr):
        """
        Add the specified handler to this logger.
        """
        _acquireLock()
        try:
            if hdlr not in self.handlers:
                self.handlers.append(hdlr)
        finally:
            _releaseLock()

    def removeHandler(self, hdlr):
        """
        Remove the specified handler from this logger.
        """
        _acquireLock()
        try:
            if hdlr in self.handlers:
                self.handlers.remove(hdlr)
        finally:
            _releaseLock()

I suppose in 3.x there might be something similar.

----------
assignee: vinay.sajip
components: Library (Lib)
messages: 117364
nosy: aronacher, vinay.sajip
priority: normal
severity: normal
status: open
title: Improper locking in logging
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9945>
_______________________________________

From report at bugs.python.org  Sat Sep 25 15:30:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 13:30:20 +0000
Subject: [issue9944] Typo in doc for itertools recipe of consume
In-Reply-To: <1285366544.01.0.313980902629.issue9944@psf.upfronthosting.co.za>
Message-ID: <1285421420.39.0.677922734243.issue9944@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r85008.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9944>
_______________________________________

From report at bugs.python.org  Sat Sep 25 15:32:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 13:32:52 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1285421572.87.0.793192705103.issue9896@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> One other thought.  If there is a perceived need, I would rather an
> alternate approach that unifies a language a bit by letting range()
> expose its arguments as a slice and modify its input to accept a slice.

This sounds like an obscure complication to me. A range is not a slice and I don't see the point of trying to bridge both concepts. It is even more YAGNI than the original request.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Sat Sep 25 15:46:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 13:46:53 +0000
Subject: [issue1865] Document bytes alias for 2.7
In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za>
Message-ID: <1285422413.94.0.686765206471.issue1865@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r85010.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1865>
_______________________________________

From report at bugs.python.org  Sat Sep 25 15:58:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 13:58:38 +0000
Subject: [issue9946] lock use in logging
In-Reply-To: <1285423118.6.0.459283406836.issue9946@psf.upfronthosting.co.za>
Message-ID: <1285423118.6.0.459283406836.issue9946@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

>From logging.Logger:

    def removeHandler(self, hdlr):
        """
        Remove the specified handler from this logger.
        """
        if hdlr in self.handlers:
            hdlr.acquire()
            try:
                self.handlers.remove(hdlr)
            finally:
                hdlr.release()

I don't see what the use is for locking the handler.  The only shared resource that is accessed is self.handlers, which is not locked by the handler lock.

----------
assignee: vinay.sajip
components: Library (Lib)
keywords: easy
messages: 117368
nosy: georg.brandl, vinay.sajip
priority: normal
severity: normal
status: open
title: lock use in logging
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9946>
_______________________________________

From report at bugs.python.org  Sat Sep 25 16:02:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 14:02:15 +0000
Subject: [issue9946] lock use in logging
In-Reply-To: <1285423118.6.0.459283406836.issue9946@psf.upfronthosting.co.za>
Message-ID: <1285423335.37.0.63648181174.issue9946@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Dupe of #9945, sorry.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9946>
_______________________________________

From report at bugs.python.org  Sat Sep 25 16:17:40 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 25 Sep 2010 14:17:40 +0000
Subject: [issue9947] Weird locking in logging config system
In-Reply-To: <1285424260.64.0.915728022787.issue9947@psf.upfronthosting.co.za>
Message-ID: <1285424260.64.0.915728022787.issue9947@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

Another case of improper locking in logging.  The stopListening() method of the logging config acquires the logging lock, but it doesn't do it early enough.  In order for this function to be thread safe it would have to lock before the if.

Currently that lock used is useless because it locks assigning to a single attribute assignment and a global assignment that is never checked to existence besides the stopListening() function.

The attached patch proposes moving the lock before the if to make it threadsafe, but in all fairness sake that method is probably never executed from more than one thread.

----------
assignee: vinay.sajip
files: logging-config-threadsafety.patch
keywords: patch
messages: 117370
nosy: aronacher, vinay.sajip
priority: normal
severity: normal
status: open
title: Weird locking in logging config system
versions: Python 2.7
Added file: http://bugs.python.org/file19007/logging-config-threadsafety.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9947>
_______________________________________

From report at bugs.python.org  Sat Sep 25 16:26:04 2010
From: report at bugs.python.org (Kevin Hunter)
Date: Sat, 25 Sep 2010 14:26:04 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1285424764.69.0.831923069805.issue9942@psf.upfronthosting.co.za>


Kevin Hunter <hunteke at earlham.edu> added the comment:

> Well, first, this would only work for large objects. [...]
> Why do you think you might have such duplication in your workload?

Some of the projects with which I work involve multiple manipulations of large datasets.  Often, we use Python scripts as "first and third" stages in a pipeline.  For example, in one current workflow, we read a large file into a cStringIO object, do a few manipulations with it, pass it off to a second process, and await the results.  Meanwhile, the large file is sitting around in memory because we need to do more manipulations after we get results back from the second application in the pipeline.  "Graphically":

Python Script A    ->    External App    ->    Python Script A
read large data          process data          more manipulations

Within a single process, I don't see any gain to be had.  However, in this one use-case, this pipeline is running concurrently with a number of copies with slightly different command line parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Sat Sep 25 16:31:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 14:31:36 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285424764.69.0.831923069805.issue9942@psf.upfronthosting.co.za>
Message-ID: <1285425088.3192.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Well, first, this would only work for large objects. [...]
> > Why do you think you might have such duplication in your workload?
> 
> Some of the projects with which I work involve multiple manipulations
> of large datasets.  Often, we use Python scripts as "first and third"
> stages in a pipeline.  For example, in one current workflow, we read a
> large file into a cStringIO object, do a few manipulations with it,
> pass it off to a second process, and await the results.

Why do you read it into a cStringIO? A cStringIO has the same interface
as a file, so you could simply operate on the file directly.

(you could also try mmap if you need quick random access to various
portions of the file)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Sat Sep 25 16:32:30 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 25 Sep 2010 14:32:30 +0000
Subject: [issue9948] findCaller is slow and loses case information on Windows
In-Reply-To: <1285425150.17.0.662006958911.issue9948@psf.upfronthosting.co.za>
Message-ID: <1285425150.17.0.662006958911.issue9948@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

findCaller() on loses case information on the files on Windows and has in general a really bad performance.  The attached patch does not depend on filename comparisions and instead compares the object identity of the caller's global namespace against the one from the logging module.

----------
assignee: vinay.sajip
components: Library (Lib)
files: find-caller.patch
keywords: patch
messages: 117373
nosy: aronacher, vinay.sajip
priority: normal
severity: normal
status: open
title: findCaller is slow and loses case information on Windows
versions: Python 2.7
Added file: http://bugs.python.org/file19008/find-caller.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9948>
_______________________________________

From report at bugs.python.org  Sat Sep 25 16:33:45 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 25 Sep 2010 14:33:45 +0000
Subject: [issue9948] findCaller is slow and loses case information on Windows
In-Reply-To: <1285425150.17.0.662006958911.issue9948@psf.upfronthosting.co.za>
Message-ID: <1285425225.82.0.989530699973.issue9948@psf.upfronthosting.co.za>


Changes by Armin Ronacher <armin.ronacher at active-4.com>:


Added file: http://bugs.python.org/file19009/find-caller.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9948>
_______________________________________

From report at bugs.python.org  Sat Sep 25 16:33:49 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 25 Sep 2010 14:33:49 +0000
Subject: [issue9948] findCaller is slow and loses case information on Windows
In-Reply-To: <1285425150.17.0.662006958911.issue9948@psf.upfronthosting.co.za>
Message-ID: <1285425229.6.0.548831224509.issue9948@psf.upfronthosting.co.za>


Changes by Armin Ronacher <armin.ronacher at active-4.com>:


Removed file: http://bugs.python.org/file19008/find-caller.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9948>
_______________________________________

From report at bugs.python.org  Sat Sep 25 17:03:14 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 25 Sep 2010 15:03:14 +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: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In Lib/ntpath.py:

# realpath is a no-op on systems without islink support
realpath = abspath


However, Windows Vista and newer support symbolic links and other Python methods support them.

(noticed this through source code inspection; haven't actually tested it)

----------
components: Library (Lib)
messages: 117374
nosy: brian.curtin, eric.smith, jaraco, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: os.path.realpath on Windows does not follow symbolic links
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9949>
_______________________________________

From report at bugs.python.org  Sat Sep 25 17:22:23 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 25 Sep 2010 15:22:23 +0000
Subject: [issue1703592] have a way to ignore nonexisting locales in
	locale.setlocale
Message-ID: <1285428143.42.0.473203518529.issue1703592@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Certainly at a minimum, the docs should describe the exception and workaround instead of just:

"setlocale() is not thread safe on most systems. Applications typically start with a call of

    import locale
    locale.setlocale(locale.LC_ALL, '')

This sets the locale for all categories to the user?s default setting (typically specified in the LANG environment variable). If the locale is not changed thereafter, using multithreading should not cause problems."

+0 for a new function in Python 3.2.

For Python 2.7 though, we can't really add that new function or change the behavior of setlocale() so I'm not sure what the right thing to do is.  A documentation change is probably as good as it's going to get for Python 2.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1703592>
_______________________________________

From report at bugs.python.org  Sat Sep 25 17:29:45 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 25 Sep 2010 15:29:45 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1285428585.78.0.0896997153655.issue5412@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


Removed file: http://bugs.python.org/file18760/issue5412.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Sat Sep 25 17:31:35 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 25 Sep 2010 15:31:35 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1285428695.23.0.091971843302.issue5412@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Patch updated:

 * uses collections because they are built into the executable for 3.2
 * uses itertools for the same reasons
 * in the end doesn't use weakrefs since after recent commits (Raymond removed __del__ from OrderedDict) the reference cycle problem went away on its own

Still needs docs but I didn't manage to make sensible edits last night (the train I took from Hannover arrived 80 minutes later).

----------
Added file: http://bugs.python.org/file19010/issue5412.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Sat Sep 25 18:16:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 16:16:08 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1285431368.57.0.811025688572.issue9360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

And here is a patch integrating doc fixes and updates.

----------
Added file: http://bugs.python.org/file19011/nntplib_cleanup7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Sat Sep 25 18:20:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Sep 2010 16:20:43 +0000
Subject: [issue6634] sys.exit() called from threads other than the main one:
	undocumented behaviour
In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>
Message-ID: <1285431643.55.0.412298924756.issue6634@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I do not use threads so I cannot comment on the technical issue.

Since the current behavior is not clearly a bug, I do not think a change would or know that it should be applied to 2.7/3.1. So I suggest that you both

1. Suggest a doc patch on this issue. That should not controversial and might be quickly applied.

2. Submit a separate feature request issue to change behavior in 3.2 or beyond. You could request that the change be backported to 2.7 and try to make a case for doing so.

Unless you can quickly write a tested patch, such a change in unlikely to make it into 3.2 anyway. And even then, no guarantee.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6634>
_______________________________________

From report at bugs.python.org  Sat Sep 25 18:37:01 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 25 Sep 2010 16:37:01 +0000
Subject: [issue8831] recv and recvfrom on UDP socket do not return/throw
	exception after a close()
In-Reply-To: <1274949794.75.0.209181492423.issue8831@psf.upfronthosting.co.za>
Message-ID: <1285432621.41.0.425043849404.issue8831@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Are you sure of that? I don't see how Python behaviour would be different to a the same program written in C. Could you write a short example written in C to prove that?

I also found this surprising, so I wroke a quick C program to test this (see attached C code), and as expected, calling close() from the main thread _doesn't_ result in recv() returning (and the socket still shows up in a "netstat -A inet -a").

Furthermore, closing a socket still in use by another thread is probably quite questionable, and close(2) man page makes it clear:
"It  is  probably  unwise to close file descriptors while they may be in use by
system calls in other threads in the same process.  Since a file descriptor
may be re-used, there are some obscure race conditions that may cause
unintended side effects."

So I'd suggest to close this issue.

----------
nosy: +neologix
Added file: http://bugs.python.org/file19012/test_socket.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8831>
_______________________________________

From report at bugs.python.org  Sat Sep 25 18:44:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 16:44:16 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1285433056.43.0.600828376661.issue8445@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sat Sep 25 18:50:32 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Sep 2010 16:50:32 +0000
Subject: [issue9562] Slightly misleading wording in documentation of
	dict.update
In-Reply-To: <1281473403.13.0.50491902338.issue9562@psf.upfronthosting.co.za>
Message-ID: <1285433432.43.0.996858583034.issue9562@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
does the attached patch contains the expected wording?

Thanks,
Sandro

----------
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19013/issue9562-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9562>
_______________________________________

From report at bugs.python.org  Sat Sep 25 18:56:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 16:56:48 +0000
Subject: [issue9562] Slightly misleading wording in documentation of
	dict.update
In-Reply-To: <1281473403.13.0.50491902338.issue9562@psf.upfronthosting.co.za>
Message-ID: <1285433808.5.0.924721967444.issue9562@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed original suggestion as r85011.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9562>
_______________________________________

From report at bugs.python.org  Sat Sep 25 19:43:46 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 25 Sep 2010 17:43:46 +0000
Subject: [issue9945] Improper locking in logging
In-Reply-To: <1285421253.55.0.777992318976.issue9945@psf.upfronthosting.co.za>
Message-ID: <1285436626.79.0.954557224295.issue9945@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into py3k and release27-maint branches, r85012. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9945>
_______________________________________

From report at bugs.python.org  Sat Sep 25 19:49:13 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 25 Sep 2010 17:49:13 +0000
Subject: [issue9947] Weird locking in logging config system
In-Reply-To: <1285424260.64.0.915728022787.issue9947@psf.upfronthosting.co.za>
Message-ID: <1285436953.62.0.312027608956.issue9947@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into py3k and release27-maint, r85013.

Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9947>
_______________________________________

From report at bugs.python.org  Sat Sep 25 20:02:42 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Sep 2010 18:02:42 +0000
Subject: [issue6293] Have regrtest.py echo back sys.flags
In-Reply-To: <1245173731.34.0.991251966726.issue6293@psf.upfronthosting.co.za>
Message-ID: <1285437762.45.0.981520038413.issue6293@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
I've changed the initial patch to add a CLI option ('-g/--sysflags', '-f' is already used) to enable the echoing of sys.flags.

If you need some other changes, just ping me.

Regards,
Sandro

----------
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19014/issue6293-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6293>
_______________________________________

From report at bugs.python.org  Sat Sep 25 21:07:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 19:07:48 +0000
Subject: [issue9950] socket.sendall() crash when receiving a signal
In-Reply-To: <1285441668.88.0.256888401487.issue9950@psf.upfronthosting.co.za>
Message-ID: <1285441668.88.0.256888401487.issue9950@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This was introduced by r74426 which addressed issue1628205. socket.sendall() calls PyErr_CheckSignals() (and potentially returns to the caller) without having the GIL.

>>> import socket
>>> c, s = socket.socketpair()
>>> s.sendall(b"x"*(100 * 1024**2))
^C^CFatal Python error: PyThreadState_Get: no current thread

----------
components: Library (Lib)
messages: 117385
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
status: open
title: socket.sendall() crash when receiving a signal
type: crash
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9950>
_______________________________________

From report at bugs.python.org  Sat Sep 25 21:08:21 2010
From: report at bugs.python.org (=?utf-8?q?G=C3=B6sta_Huldt?=)
Date: Sat, 25 Sep 2010 19:08:21 +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: <1285441701.61.0.0944370419399.issue9890@psf.upfronthosting.co.za>


G?sta Huldt <ghuldt at gmail.com> added the comment:

I get the same error, but only when IDLE is run with the -n flag. 
In my case, the error occurs when attempting to switch back to the IDLE gui after executing a script that opens a graphics window (using the vtk module). This is with Python 2.6. 

I have Visual C++ 2010 Express installed, along with a previous install of the 2008 redistributable.

The following message is returned to the prompt:

Fatal Python error: PyEval_RestoreThread: NULL tstate

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

----------
nosy: +G?sta.Huldt
versions: +Python 2.6 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9890>
_______________________________________

From report at bugs.python.org  Sat Sep 25 21:11:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 19:11:20 +0000
Subject: [issue9950] socket.sendall() crash when receiving a signal
In-Reply-To: <1285441668.88.0.256888401487.issue9950@psf.upfronthosting.co.za>
Message-ID: <1285441880.57.0.523927737009.issue9950@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The fix is very simple, but perhaps a test should be added.

diff -r af0d7b32d6ce Modules/socketmodule.c
--- a/Modules/socketmodule.c    Fri Sep 24 20:03:12 2010 +0200
+++ b/Modules/socketmodule.c    Sat Sep 25 21:09:58 2010 +0200
@@ -2581,8 +2581,8 @@ sock_sendall(PySocketSockObject *s, PyOb
         return select_error();
     }
 
-    Py_BEGIN_ALLOW_THREADS
     do {
+        Py_BEGIN_ALLOW_THREADS
         timeout = internal_select(s, 1);
         n = -1;
         if (timeout)
@@ -2592,6 +2592,7 @@ sock_sendall(PySocketSockObject *s, PyOb
 #else
         n = send(s->sock_fd, buf, len, flags);
 #endif
+        Py_END_ALLOW_THREADS
         if (n < 0) {
 #ifdef EINTR
             /* We must handle EINTR here as there is no way for
@@ -2610,7 +2611,6 @@ sock_sendall(PySocketSockObject *s, PyOb
         buf += n;
         len -= n;
     } while (len > 0);
-    Py_END_ALLOW_THREADS
     PyBuffer_Release(&pbuf);
 
     if (timeout == 1) {

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9950>
_______________________________________

From report at bugs.python.org  Sat Sep 25 21:26:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 19:26:22 +0000
Subject: [issue9950] socket.sendall() crash when receiving a signal
In-Reply-To: <1285441668.88.0.256888401487.issue9950@psf.upfronthosting.co.za>
Message-ID: <1285442782.36.0.100015495005.issue9950@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, the patch is enough to suppress the crash, but sendall() behaviour is buggy in another way: EINTR may be received as part of the select() call (on sockets with a timeout), in which case the loop will be exited early instead of retrying, losing track of the number of bytes written (something which the original patch aimed to avoid).

For example:

>>> def handler(*args): print (args)
... 
>>> signal.signal(signal.SIGALRM, handler)
0
>>> c, s = socket.socketpair()
>>> s.settimeout(60.0)
>>> signal.alarm(1); s.sendall(b"x" * (100 * 1024**2))
0
(14, <frame object at 0x2b8f220>)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.error: [Errno 4] Interrupted system call

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9950>
_______________________________________

From report at bugs.python.org  Sat Sep 25 21:54:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 19:54:23 +0000
Subject: [issue9950] socket.sendall() crash when receiving a signal
In-Reply-To: <1285441668.88.0.256888401487.issue9950@psf.upfronthosting.co.za>
Message-ID: <1285444463.91.0.365858397815.issue9950@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oh, and an additional bug is that send() can return a successful partial write when it was actually interrupted by a signal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9950>
_______________________________________

From report at bugs.python.org  Sat Sep 25 22:27:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 20:27:28 +0000
Subject: [issue9950] socket.sendall() crash when receiving a signal
In-Reply-To: <1285441668.88.0.256888401487.issue9950@psf.upfronthosting.co.za>
Message-ID: <1285446448.06.0.843874111871.issue9950@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch fixing the aforementioned issues, and with tests.

----------
keywords: +patch
nosy: +exarkun
Added file: http://bugs.python.org/file19015/sendallinterrupt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9950>
_______________________________________

From report at bugs.python.org  Sat Sep 25 22:48:06 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Sep 2010 20:48:06 +0000
Subject: [issue7110] Output test failures on stderr in regrtest.py
In-Reply-To: <1255334934.67.0.943013773261.issue7110@psf.upfronthosting.co.za>
Message-ID: <1285447686.42.0.0708356222618.issue7110@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
the attached patch seems to do the trick, at least on what I can verify here on my machine. I'd appreciate a bit more of test from more experienced developers, just to catch corner cases I didn't see.

Regards,
Sandro

----------
keywords: +patch
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19016/issue7110-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7110>
_______________________________________

From report at bugs.python.org  Sat Sep 25 23:23:11 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Sep 2010 21:23:11 +0000
Subject: [issue9628] runtests.sh -x doesn't work with more than two args (sed
	error)
In-Reply-To: <1282062577.36.0.157889963246.issue9628@psf.upfronthosting.co.za>
Message-ID: <1285449791.56.0.419674723675.issue9628@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
the patch applies cleanly against up-to-date py3k branch: is there anything else to do before committing it?

Regards,
Sandro

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9628>
_______________________________________

From report at bugs.python.org  Sat Sep 25 23:27:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 25 Sep 2010 21:27:39 +0000
Subject: [issue8831] recv and recvfrom on UDP socket do not return/throw
	exception after a close()
In-Reply-To: <1274949794.75.0.209181492423.issue8831@psf.upfronthosting.co.za>
Message-ID: <1285450059.92.0.964199628024.issue8831@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing, as suggested by neologix

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8831>
_______________________________________

From report at bugs.python.org  Sat Sep 25 23:34:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 21:34:37 +0000
Subject: [issue9910] Add Py_SetPath API for embedding python
In-Reply-To: <1285050754.57.0.81319423251.issue9910@psf.upfronthosting.co.za>
Message-ID: <1285450477.61.0.271125442455.issue9910@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch compiles fine under Linux, but please don't use tabs for indentation of C files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9910>
_______________________________________

From report at bugs.python.org  Sun Sep 26 00:38:39 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Sat, 25 Sep 2010 22:38:39 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1285454319.3.0.618663696084.issue9923@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

I'm also creating a test for mailcap (Issue 6484), which is how I found this bug. I'll have an update to that test submitted soon once I implement r.david.murray's helpful suggestions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Sun Sep 26 00:42:53 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 25 Sep 2010 22:42:53 +0000
Subject: [issue9926] Wrapped TestSuite subclass does not get __call__ executed
In-Reply-To: <1285252368.31.0.189981048833.issue9926@psf.upfronthosting.co.za>
Message-ID: <1285454573.37.0.308113234655.issue9926@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The attached patch fixes the issue (I think...) by tagging the result object. It removes the need for _wrapped_result altogether. The test fails without the change to TestSuite and passes with the change.

This could be applied to 2.7-maint and py3k.

Uhm... the patch needs a better name for the TestResult tag attribute.

----------
keywords: +patch
Added file: http://bugs.python.org/file19017/suite.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9926>
_______________________________________

From report at bugs.python.org  Sun Sep 26 01:38:48 2010
From: report at bugs.python.org (Arnon Yaari)
Date: Sat, 25 Sep 2010 23:38:48 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>


New submission from Arnon Yaari <wiggin15 at gmail.com>:

Following up on these discussions:
http://psf.upfronthosting.co.za/roundup/tracker/issue3532
http://www.gossamer-threads.com/lists/python/dev/863892

I'm submitting a patch to add bytes.hex method in accordance to PEP 358.
The code was taken from binascii so it should be "tested".
Also added bytearray.hex and fixed the documentation and testing.

There are additional things to discuss, for example:
* multiple and different implementations of tohex\fromhex - in binascii, sha1module, bytes, bytearray...
* binascii's functions which perform the same thing, but those functions and the rest of binascii's functions receive and return wrong types. I would fix this but it breaks compatibility.

----------
components: Interpreter Core
files: bytes.hex.diff
keywords: patch
messages: 117397
nosy: wiggin15
priority: normal
severity: normal
status: open
title: introduce bytes.hex method
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19018/bytes.hex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9951>
_______________________________________

From report at bugs.python.org  Sun Sep 26 04:13:49 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 26 Sep 2010 02:13:49 +0000
Subject: [issue9910] Add Py_SetPath API for embedding python
In-Reply-To: <1285050754.57.0.81319423251.issue9910@psf.upfronthosting.co.za>
Message-ID: <1285467229.79.0.348788653793.issue9910@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Sorry, my mistake, I work in a mixed environment.  If there are no objections, I?ll submit this (with fixed whitespace)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9910>
_______________________________________

From report at bugs.python.org  Sun Sep 26 06:17:50 2010
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 26 Sep 2010 04:17:50 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1285474670.98.0.228406385649.issue8445@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Hi there,

I believe I've fixed most of these errors. But I couldn't replicate the last error on the first message, so I guessed what could be the problem.

Could you try the patch and see how it works for you ?

(Thanks for the nosy addition, I rarely check for bugs as you may know).

----------
keywords: +patch
Added file: http://bugs.python.org/file19019/issue8445.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Sep 26 06:43:33 2010
From: report at bugs.python.org (Kevin Hunter)
Date: Sun, 26 Sep 2010 04:43:33 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1285476213.97.0.331675138201.issue9942@psf.upfronthosting.co.za>


Kevin Hunter <hunteke at earlham.edu> added the comment:

> Why do you read it into a cStringIO? A cStringIO has the same interface
> as a file, so you could simply operate on the file directly.

In that particular case, because it isn't actually a file.  That workflow was my attempt at simplification to illustrate a point.

I think the point is moot however, as I've gotten what I needed from this feature request/discussion.  Not one, but three Python developers seem opposed to the idea, or at least skeptical.  That's enough to tell me that my first-order supposition that Python objects could be MERGEABLE is not on target.

Cheers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Sun Sep 26 07:21:38 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 26 Sep 2010 05:21:38 +0000
Subject: [issue9815] assertRaises as a context manager keeps tracebacks and
	frames alive
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1285478498.84.0.599645366715.issue9815@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> Note that the original issue (test_tarfile failures on the Windows
> buildbots) now seems fixed thanks to the various tarfile and
> test_tarfile improvements.

Yes, thanks. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Sun Sep 26 07:27:39 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 26 Sep 2010 05:27:39 +0000
Subject: [issue9289] Skip test_long_key(test_winreg) on win2k + py2.x
In-Reply-To: <1279414134.03.0.595847788627.issue9289@psf.upfronthosting.co.za>
Message-ID: <1285478859.22.0.468076578598.issue9289@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I found workaround for this. (Probably self.deletetree is
more handful, though)

----------
versions:  -Python 2.6
Added file: http://bugs.python.org/file19020/py27_fix_test_winreg_long_key.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9289>
_______________________________________

From report at bugs.python.org  Sun Sep 26 07:40:58 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 26 Sep 2010 05:40:58 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285479658.42.0.203284323708.issue9937@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, my patch didn't pass test_dynamic_key(test_winreg).
(Apologize for not testing on unit test)

RegEnumValueA and RegQueryInfoKeyA always returned 0 for 
required data size if target is HKEY_PERFORMANCE_DATA.

The possible fixes I can imagine are...

1. Use GetCPInfo() to get MaxCharSize.
http://msdn.microsoft.com/en-us/library/dd317780%28v=VS.85%29.aspx
We can get a large value enough to store the key name in ANSI by
"The length in Unicode" * MaxCharSize.

2. Use RegEnumValueW and convert result via WideCharToMultiByte

I'll attach the patch with option 1.

----------
Added file: http://bugs.python.org/file19021/py27_fix_winreg_EnumValue_op1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Sun Sep 26 07:55:10 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 26 Sep 2010 05:55:10 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285480510.47.0.705774707882.issue9937@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I shall create unit test later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Sun Sep 26 08:13:51 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 26 Sep 2010 06:13:51 +0000
Subject: [issue9929] subprocess.Popen unbuffered not work
In-Reply-To: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>
Message-ID: <1285481631.45.0.33686031498.issue9929@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Antoine, can you create the patch? I'm not familiar with IO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9929>
_______________________________________

From report at bugs.python.org  Sun Sep 26 10:44:19 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 26 Sep 2010 08:44:19 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1285490659.17.0.781826573141.issue8445@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

With Guilherme's patch;

We are down to 1 error but thats a new errror;


test test_ttk_guionly failed -- Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/tkinter/test/test_ttk/test_widgets.py", line 28, in test_identify
    self.widget.winfo_height() / 2), "label")
  File "/Users/cartman/Sources/py3k/Lib/tkinter/ttk.py", line 568, in identify
    return self.tk.call(self._w, "identify", x, y)
_tkinter.TclError: expected integer but got "30.5"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Sep 26 11:28:09 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 26 Sep 2010 09:28:09 +0000
Subject: [issue6031] BaseServer.shutdown documentation is incomplete
In-Reply-To: <1242431876.91.0.139343855315.issue6031@psf.upfronthosting.co.za>
Message-ID: <1285493289.74.0.272914607725.issue6031@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
I've refreshed this patch (correct the file name & because it applies now with an offset), other than that it seems ok: can someone review (it's quite small :) and apply it?

Thanks,
Sandro

----------
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19022/issue6031-py3k-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6031>
_______________________________________

From report at bugs.python.org  Sun Sep 26 12:16:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 26 Sep 2010 10:16:34 +0000
Subject: [issue9869] long_subtype_new segfault in pure-Python code
In-Reply-To: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>
Message-ID: <1285496194.81.0.587184700975.issue9869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Right. In practice, returning a long instead of an int can produce bugs,
> mainly because some C functions will only accept ints and refuse longs.

I'd say 'in theory' rather than 'in practice' here.  In this particular case, I don't see much danger:  any C code explicitly calling PyNumber_Long (rather than PyNumber_Int) surely has to be prepared to deal with a long, since that's what's going to be returned in the vast majority of cases.  Similarly for Python code calling 'long' rather than 'int'.

I'd also note that the docs state clearly that PyNumber_Long returns a long (while PyNumber_Int, in contrast, is permitted to return either an int or a long);  similarly for the builtin 'long' function.

And finally, looking at the history of the test_class test (see issue 1671298), it doesn't look as if anyone was thinking too hard about return types at that point---it looks like the test was just fit to the existing semi-broken behaviour.

So I'm still proposing to apply this patch, in spite of Antoine's -1. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9869>
_______________________________________

From report at bugs.python.org  Sun Sep 26 12:38:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 26 Sep 2010 10:38:33 +0000
Subject: [issue9869] long_subtype_new segfault in pure-Python code
In-Reply-To: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>
Message-ID: <1285497513.38.0.396488230806.issue9869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed in r85016.  I'll take responsibility for any broken 3rd party code...

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9869>
_______________________________________

From report at bugs.python.org  Sun Sep 26 13:03:00 2010
From: report at bugs.python.org (Martin Rinehart)
Date: Sun, 26 Sep 2010 11:03:00 +0000
Subject: [issue9952] Martin Rinehart wants to stay in touch on LinkedIn
In-Reply-To: <139977402.6246160.1285498974918.JavaMail.app@ech3-cdn11.prod>
Message-ID: <139977402.6246160.1285498974918.JavaMail.app@ech3-cdn11.prod>


New submission from Martin Rinehart <MartinRinehart at gmail.com>:

LinkedIn
------------

I'd like to add you to my professional network on LinkedIn.

- Martin Rinehart

Martin Rinehart
Student at Strayer Online
Greater New York City Area

Confirm that you know Martin Rinehart
https://www.linkedin.com/e/-3qcne3-gejswd6s-6f/isd/1711537782/WJZqc_fZ/

----------
files: unnamed
messages: 117410
nosy: MartinRinehart
priority: normal
severity: normal
status: open
title: Martin Rinehart wants to stay in touch on LinkedIn
Added file: http://bugs.python.org/file19023/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9952>
_______________________________________
-------------- next part --------------

<html>
  <body>

  

<table border="0" width="550" cellpadding="0" cellspacing="0" style="max-width:550px; border-top:4px solid #39C; font: 12px arial, sans-serif; margin: 0 auto;"><tr><td>  
  <h1 style="color: #000; font: bold 23px arial; margin:5px 0;" >LinkedIn</h1>

<div style="font:13px arial, sans-serif; width:540px">  
    
    <p>
      I'd like to add you to my professional network on LinkedIn.<br/>
<br/>
- Martin Rinehart
    </p>
    
    <table cellpadding="0" cellspacing="0" style="margin-bottom: 10px;">
      <tr>
        <td style="font: 13px arial, sans-serif; width: 490px;">
          <div style="padding: 5px 5px 5px 0">
            Martin Rinehart<br>
                  Student at Strayer Online
            <br>
                  Greater New York City Area
          </div>
          </div>
        </td>
      </tr>
    </table>

    <p>
              <a style="background-color:#ffcc00; display:inline-block; border-right: 1px solid #7a5a20; border-bottom: 1px solid #7a5a20; padding:10px; text-decoration: none; color: #000; text-align: center; white-space:none; font-weight: bold;" href="https://www.linkedin.com/e/-3qcne3-gejswd6s-6f/isd/1711537782/WJZqc_fZ/EML-invg_59/">Confirm that you know Martin</a>
    </p>
</div>



  <p style="width: 550px; margin: 3px auto; font: 10px arial, sans-serif; color: #999;">&#169; 2010, LinkedIn Corporation</p>
<img src="http://www.linkedin.com/emimp/-3qcne3-gejswd6s-6f.gif" style="width:1px; height:1px;"/></body>
</html>

From report at bugs.python.org  Sun Sep 26 13:25:21 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Sep 2010 11:25:21 +0000
Subject: [issue9952] Martin Rinehart wants to stay in touch on LinkedIn
In-Reply-To: <139977402.6246160.1285498974918.JavaMail.app@ech3-cdn11.prod>
Message-ID: <1285500321.36.0.2501117831.issue9952@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9952>
_______________________________________

From report at bugs.python.org  Sun Sep 26 14:12:51 2010
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 26 Sep 2010 12:12:51 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1285490659.17.0.781826573141.issue8445@psf.upfronthosting.co.za>
Message-ID: <AANLkTinfHJvfoSrgJcomnh1HXOsbqxCMN9GaVHrN7yZg@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> We are down to 1 error but thats a new errror;
>
>
> test test_ttk_guionly failed -- Traceback (most recent call last):
> ?File "/Users/cartman/Sources/py3k/Lib/tkinter/test/test_ttk/test_widgets.py", line 28, in test_identify
> ? ?self.widget.winfo_height() / 2), "label")
> ?File "/Users/cartman/Sources/py3k/Lib/tkinter/ttk.py", line 568, in identify
> ? ?return self.tk.call(self._w, "identify", x, y)
> _tkinter.TclError: expected integer but got "30.5"
>

Just convert to integer the results from winfo and you should be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Sep 26 14:17:27 2010
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 26 Sep 2010 12:17:27 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1285503447.29.0.16443951353.issue8445@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

You should convert the whole expressions actually, but that is because the patch wasn't done for py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Sep 26 14:28:50 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Sep 2010 12:28:50 +0000
Subject: [issue9943] TypeError message became less helpful in Python 2.7
In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za>
Message-ID: <1285504130.59.0.207887374415.issue9943@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Having seen the reversion go by on the checkins list, I think there are distinctions the interpreter should be making here in order to improve the error messages, but it isn't.

Ideally, we want to be able to tell the user (without writing War and Peace as an error message):

1. How many positional parameters are expected
2. How many positional parameters were supplied as positional arguments
3. How many positional parameters were supplied as keyword arguments

For example:

Def: f(**kw)
Call: f("hello", keyword=True)
Error: f() does not accept positional arguments (1 given)

Def: f(x, **kw)
Call: f("hello", "goodbye", keyword=True)
Error: f() accepts at most 1 positional argument (2 given)

Def: f(x, **kw)
Call: f("hello", x="goodbye", keyword=True)
Error: f() accepts at most 1 positional argument (2 given, 1 via keyword)

Basically:
1. Get rid of the "exactly"/"at most" distinction ("exactly" is wrong, since you can always provide positional arguments as keyword arguments instead)
2. Use "positional" instead of the awkward "non-keyword"
3. Append additional info when some or all of the positional arguments are provided as keywords.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9943>
_______________________________________

From report at bugs.python.org  Sun Sep 26 14:31:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Sep 2010 12:31:48 +0000
Subject: [issue9899] tkinter test_font fails on OS X with Aqua Tk
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1285504308.81.0.362696939651.issue9899@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, most buildbots were fixed but a couple of them still show a problem:

test_font_eq (tkinter.test.test_tkinter.test_font.FontTest) ... ERROR
testLoadTk (tkinter.test.test_tkinter.test_loadtk.TkLoadTest) ... skipped 'No $DISPLAY set.'
testLoadTkFailure (tkinter.test.test_tkinter.test_loadtk.TkLoadTest) ... ok
test_search (tkinter.test.test_tkinter.test_text.TextTest) ... ok

======================================================================
ERROR: test_font_eq (tkinter.test.test_tkinter.test_font.FontTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/test_tkinter/test_font.py", line 18, in test_font_eq
    font1 = font.nametofont("TkDefaultFont")
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/font.py", line 22, in nametofont
    return Font(name=name, exists=True)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/font.py", line 83, in __init__
    "named font %s does not already exist" % (self.name,))
_tkinter.TclError: named font TkDefaultFont does not already exist


Intriguingly, when the test gets re-run at the end of the test suite, the test succeeds.
Does it depend on another initialization that is done in another test file?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9899>
_______________________________________

From report at bugs.python.org  Sun Sep 26 14:44:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Sep 2010 12:44:43 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1285505083.43.0.752364707591.issue8445@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is Guilherme's patch converted for py3k.

----------
nosy: +pitrou
Added file: http://bugs.python.org/file19024/ttk3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Sep 26 14:54:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Sep 2010 12:54:05 +0000
Subject: [issue9673] Entry Widget Not Editable under Windows XP
In-Reply-To: <1282672182.44.0.886074830019.issue9673@psf.upfronthosting.co.za>
Message-ID: <1285505645.09.0.129890798557.issue9673@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9673>
_______________________________________

From report at bugs.python.org  Sun Sep 26 14:54:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Sep 2010 12:54:36 +0000
Subject: [issue8716] test_tk fails on OS X if run from buildbot slave daemon
	-- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1285505676.27.0.679049151847.issue8716@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Sun Sep 26 15:52:56 2010
From: report at bugs.python.org (yuri)
Date: Sun, 26 Sep 2010 13:52:56 +0000
Subject: [issue9953] 2 scripts running from crontab simultaneously reference
	the same instance of a variable
In-Reply-To: <1285509172.89.0.598446218983.issue9953@psf.upfronthosting.co.za>
Message-ID: <1285509172.89.0.598446218983.issue9953@psf.upfronthosting.co.za>


New submission from yuri <toozik at gmail.com>:

Originally the problem was that one script used a logger instance initialized in another script, and, as a result, log entries were "signed" by the later one.

Setup: python 3.1.1, Suse Linux enterprise server 9

2 scripts are scheduled in crontab as follows:
*/1 * * * * /my_path/python/test1.py > /dev/null 2>&1
*/1 * * * * /my_path/python/test2.py > /dev/null 2>&1

Each script does:
1) gets a logger instance and adds FileHandler, 
2) prints to its log the current time and PID, 
3) prints ID of the logger instance, 
4) prints ID and value of some variable
5) sleeps for 3 sec, 
6) prints the current time again.

Result: each script prints the same IDs of the variables

test1.py
______________________________
#!/usr/local/bin/python3
import logging
from logging import FileHandler
from datetime import datetime
import time
import os
import sys
log = logging.getLogger('MyLog1')
log.setLevel(logging.INFO)
logFilePath = os.path.join(os.path.realpath(os.path.dirname(sys.argv[0])), 'log')
dh = FileHandler(os.path.join(logFilePath, 'log1'))
log.addHandler(dh)
someVariable = 9
log.info(str(datetime.now()) + ' PID=' + str(os.getpid()))
log.info('logger ID=' + str(id(log)))
log.info('someVariable ID=' + str(id(someVariable)) + 'value=' + str(someVariable))
time.sleep(3)
log.info(str(datetime.now()) + ' PID=' + str(os.getpid()))

test2.py:
_________________________________
#!/usr/local/bin/python3
import logging
from logging import FileHandler
from datetime import datetime
import time
import os
import sys
log = logging.getLogger('MyLog2')
log.setLevel(logging.INFO)
logFilePath = os.path.join(os.path.realpath(os.path.dirname(sys.argv[0])), 'log')
dh = FileHandler(os.path.join(logFilePath, 'log2'))
log.addHandler(dh)
someVariable = 10
log.info(str(datetime.now()) + ' PID=' + str(os.getpid()))
log.info('logger ID=' + str(id(log)))
log.info('someVariable ID=' + str(id(someVariable)) + 'value=' + str(someVariable))
time.sleep(3)
log.info(str(datetime.now()) + ' PID=' + str(os.getpid()))

Result:

log1:
2010-09-26 15:45:01.531460 PID=5704
logger ID=182908380624
someVariable ID=7167488value=9
2010-09-26 15:45:04.535591 PID=5704

log2:
2010-09-26 15:45:01.528691 PID=5705
logger ID=182908380624
someVariable ID=7167520value=10
2010-09-26 15:45:04.534598 PID=5705

If I change value of someVariable to 9 in the both scripts, I have:

log1:
2010-09-26 15:48:01.488008 PID=6036
logger ID=182908380624
someVariable ID=7167488value=9
2010-09-26 15:48:04.491977 PID=6036

log2:
2010-09-26 15:48:01.490214 PID=6035
logger ID=182908380624
someVariable ID=7167488value=9
2010-09-26 15:48:04.494991 PID=6035

----------
components: Interpreter Core
messages: 117416
nosy: yuri
priority: normal
severity: normal
status: open
title: 2 scripts running from crontab simultaneously reference the same instance of a variable
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9953>
_______________________________________

From report at bugs.python.org  Sun Sep 26 15:55:28 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 26 Sep 2010 13:55:28 +0000
Subject: [issue9953] 2 scripts running from crontab simultaneously reference
	the same instance of a variable
In-Reply-To: <1285509172.89.0.598446218983.issue9953@psf.upfronthosting.co.za>
Message-ID: <1285509328.54.0.218449539257.issue9953@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

You can't rely on id() to return distinct values across different processes.  It guarantees uniqueness *within a single process* (at any particular moment).

In other words, you're misusing id() here.  This is not a Python bug.

----------
nosy: +exarkun
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9953>
_______________________________________

From report at bugs.python.org  Sun Sep 26 16:32:26 2010
From: report at bugs.python.org (Dan L)
Date: Sun, 26 Sep 2010 14:32:26 +0000
Subject: [issue9954] include sqlite3.exe in PythonXX/Scripts
In-Reply-To: <1285511546.38.0.691891047401.issue9954@psf.upfronthosting.co.za>
Message-ID: <1285511546.38.0.691891047401.issue9954@psf.upfronthosting.co.za>


New submission from Dan L <choralreef at naver.com>:

since sqlite3 is included in the standard library, it would be useful to have access to the command line tool that's part of sqlite.  Including the command-line binary for each respective OS in the respective Scripts or bin folder would allow python users to create a connection in order to examine their sqlite databases and perform some manual operations easily.  While the tool isn't in python, it's not that big of a file and such a tool is a pretty fundamental part of having a database(miniaturized or not).

----------
components: Library (Lib)
messages: 117418
nosy: jdan
priority: normal
severity: normal
status: open
title: include sqlite3.exe in PythonXX/Scripts
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9954>
_______________________________________

From report at bugs.python.org  Sun Sep 26 16:46:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Sep 2010 14:46:54 +0000
Subject: [issue9954] include sqlite3.exe in PythonXX/Scripts
In-Reply-To: <1285511546.38.0.691891047401.issue9954@psf.upfronthosting.co.za>
Message-ID: <1285512414.39.0.577943493448.issue9954@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ghaering
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9954>
_______________________________________

From report at bugs.python.org  Sun Sep 26 16:49:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Sep 2010 14:49:40 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1285512580.6.0.409027265781.issue9951@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/issue9951>
_______________________________________

From report at bugs.python.org  Sun Sep 26 16:54:30 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Sep 2010 14:54:30 +0000
Subject: [issue9954] include sqlite3.exe in PythonXX/Scripts
In-Reply-To: <1285511546.38.0.691891047401.issue9954@psf.upfronthosting.co.za>
Message-ID: <1285512870.03.0.892171029438.issue9954@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1. On Linux, and many other systems based on or using free software, the sqlite command line tool is readily available, and including it would conflict with the one provided by the system vendor.

For Windows, pre-built binaries for command line access are available from http://sqlite.org/download.html

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9954>
_______________________________________

From report at bugs.python.org  Sun Sep 26 18:28:08 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 26 Sep 2010 16:28:08 +0000
Subject: [issue9899] tkinter test_font fails on OS X with Aqua Tk
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1285518488.79.0.634275918787.issue9899@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Could be, particularly if the user name under which the test is running is not logged in (to the window manager) on the buildbot.  I'll investigate.

----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9899>
_______________________________________

From report at bugs.python.org  Sun Sep 26 18:30:20 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 26 Sep 2010 16:30:20 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1285518620.09.0.477056821617.issue8445@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Patch fixes the problem for me, please apply. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Sep 26 18:37:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Sep 2010 16:37:22 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1285519042.86.0.943913985526.issue8445@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85018, will watch the buildbots.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Sep 26 18:50:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 26 Sep 2010 16:50:04 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1285519804.96.0.26753595341.issue8445@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's an issue remaining on the buildbots:

======================================================================
FAIL: test_heading_callback (tkinter.test.test_ttk.test_widgets.TreeviewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/test_ttk/test_widgets.py", line 945, in test_heading_callback
    self.fail("The command associated to the treeview heading wasn't "
AssertionError: The command associated to the treeview heading wasn't invoked.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Sep 26 18:50:58 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 26 Sep 2010 16:50:58 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1285519858.92.0.984826171857.issue8445@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Works for me on Snow Leopard for the record.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Sep 26 19:04:08 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 26 Sep 2010 17:04:08 +0000
Subject: [issue9948] findCaller is slow and loses case information on Windows
In-Reply-To: <1285425150.17.0.662006958911.issue9948@psf.upfronthosting.co.za>
Message-ID: <1285520648.9.0.135196563643.issue9948@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Your basic fix looks fine, but there's a couple of other issues to consider:

1. Users can use _srcFile = None to avoid calling findCaller() altogether, so I can't do away with the _srcFile altogether as it may cause some issues with existing code.

2. If using e.g. a LoggerAdapter derived class, there needs to be some way in which you can skip (in addition to the logging package itself) other user-defined modules until you get to the appropriate stack frame.

I'm thinking about these, but if you have any ideas about these, I'm listening :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9948>
_______________________________________

From report at bugs.python.org  Sun Sep 26 19:43:03 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Sep 2010 17:43:03 +0000
Subject: [issue9954] include sqlite3.exe in PythonXX/Scripts
In-Reply-To: <1285511546.38.0.691891047401.issue9954@psf.upfronthosting.co.za>
Message-ID: <1285522983.5.0.204328433047.issue9954@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Indeed, -1. We don't make a habit of distributing 3rd party binaries.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9954>
_______________________________________

From report at bugs.python.org  Sun Sep 26 21:01:35 2010
From: report at bugs.python.org (Zbynek Winkler)
Date: Sun, 26 Sep 2010 19:01:35 +0000
Subject: [issue9955] multiprocessing.Pipe segmentation fault when recv of
	unpicklable object
In-Reply-To: <1285527695.71.0.573625122377.issue9955@psf.upfronthosting.co.za>
Message-ID: <1285527695.71.0.573625122377.issue9955@psf.upfronthosting.co.za>


New submission from Zbynek Winkler <zbynek.winkler at gmail.com>:

$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from lxml import etree
>>> from pickle import dumps
>>> from multiprocessing import Pipe
>>> n = etree.Element('new')
>>> dumps(n)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/pickle.py", line 1366, in dumps
    Pickler(file, protocol).dump(obj)
  File "/usr/lib/python2.6/pickle.py", line 224, in dump
    self.save(obj)
  File "/usr/lib/python2.6/pickle.py", line 306, in save
    rv = reduce(self.proto)
  File "/usr/lib/python2.6/copy_reg.py", line 70, in _reduce_ex
    raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle _Element objects
>>> p1, p2 = Pipe()
>>> p1.send(n)
>>> p2.recv()
Segmentation fault

----------
components: Library (Lib)
messages: 117427
nosy: Zbynek.Winkler
priority: normal
severity: normal
status: open
title: multiprocessing.Pipe segmentation fault when recv of unpicklable object
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9955>
_______________________________________

From report at bugs.python.org  Sun Sep 26 21:09:27 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Sep 2010 19:09:27 +0000
Subject: [issue9954] include sqlite3.exe in PythonXX/Scripts
In-Reply-To: <1285511546.38.0.691891047401.issue9954@psf.upfronthosting.co.za>
Message-ID: <1285528167.26.0.0563355824564.issue9954@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9954>
_______________________________________

From report at bugs.python.org  Sun Sep 26 22:02:19 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 26 Sep 2010 20:02:19 +0000
Subject: [issue9948] findCaller is slow and loses case information on Windows
In-Reply-To: <1285425150.17.0.662006958911.issue9948@psf.upfronthosting.co.za>
Message-ID: <1285531339.66.0.783967610278.issue9948@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

> 1. Users can use _srcFile = None to avoid calling findCaller() 
> altogether, so I can't do away with the _srcFile altogether as it may 
> cause some issues with existing code.
That is very undocumented behaviour and relying on that sounds like a terrible idea.

> 2. If using e.g. a LoggerAdapter derived class, there needs to be 
> some way in which you can skip (in addition to the logging package 
> itself) other user-defined modules until you get to the appropriate 
> stack frame.
First of all that should not be a global setting, secondly this is currently not possible in logging either.  A better solution would be to do what warnings does and making it possible provide a stacklevel to the caller finder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9948>
_______________________________________

From report at bugs.python.org  Sun Sep 26 23:41:34 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 26 Sep 2010 21:41:34 +0000
Subject: [issue9948] findCaller is slow and loses case information on Windows
In-Reply-To: <1285425150.17.0.662006958911.issue9948@psf.upfronthosting.co.za>
Message-ID: <1285537294.76.0.641839514522.issue9948@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> That is very undocumented behaviour and relying on that sounds like a terrible idea.

Agreed, I'm just fretting about it ...

> First of all that should not be a global setting, secondly this is currently not possible in logging either.

True, but you have pointed out in the past that this *is* a problem - so it would be good to solve it.

> A better solution would be to do what warnings does and making it possible provide a stacklevel to the caller finder.

I'm not that familiar with how warnings does it, but I will take a look.

Thanks for the suggestions.

BTW re. your patch - where you say "os.co_filename", do you mean "co.co_filename"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9948>
_______________________________________

From report at bugs.python.org  Sun Sep 26 23:47:24 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 26 Sep 2010 21:47:24 +0000
Subject: [issue9936] trace misreports "missing" lines
In-Reply-To: <1285296955.25.0.310844622187.issue9936@psf.upfronthosting.co.za>
Message-ID: <1285537644.47.0.0640717187649.issue9936@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

test_issue9936 fails on 2.7 branch.
See e.g. http://www.python.org/dev/buildbot/2.7.stable/builders/sparc%20solaris10%20gcc%202.7/builds/268/steps/test/logs/stdio

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9936>
_______________________________________

From report at bugs.python.org  Mon Sep 27 01:38:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 26 Sep 2010 23:38:19 +0000
Subject: [issue9936] trace misreports "missing" lines
In-Reply-To: <1285537644.47.0.0640717187649.issue9936@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=LVEwagObodgiBESkef2d0muAiN-1dFbL_r8kp@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Sep 26, 2010 at 5:47 PM, Arfrever Frehtes Taifersar Arahesis
<report at bugs.python.org> wrote:
..
>
> test_issue9936 fails on 2.7 branch.

Should be fixed by r85020.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9936>
_______________________________________

From report at bugs.python.org  Mon Sep 27 01:44:29 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 26 Sep 2010 23:44:29 +0000
Subject: [issue9956] memoryview type documentation lacks versionadded
In-Reply-To: <1285544669.44.0.903225365456.issue9956@psf.upfronthosting.co.za>
Message-ID: <1285544669.44.0.903225365456.issue9956@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

Title says all, attached is a patch against trunk (2.7). I'm not familiar with what version is correct for the Python 3 documentation.

----------
assignee: docs at python
components: Documentation
files: stdtypes-memoryview-2.7.patch
keywords: patch
messages: 117432
nosy: Trundle, docs at python, pitrou
priority: normal
severity: normal
status: open
title: memoryview type documentation lacks versionadded
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19025/stdtypes-memoryview-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9956>
_______________________________________

From report at bugs.python.org  Mon Sep 27 01:49:31 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Sep 2010 23:49:31 +0000
Subject: [issue9956] memoryview type documentation lacks versionadded
In-Reply-To: <1285544669.44.0.903225365456.issue9956@psf.upfronthosting.co.za>
Message-ID: <1285544971.62.0.198309297736.issue9956@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85022

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9956>
_______________________________________

From report at bugs.python.org  Mon Sep 27 03:18:21 2010
From: report at bugs.python.org (Tokio Kikuchi)
Date: Mon, 27 Sep 2010 01:18:21 +0000
Subject: [issue1079] decode_header does not follow RFC 2047
In-Reply-To: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za>
Message-ID: <1285550301.24.0.72201925086.issue1079@psf.upfronthosting.co.za>


Tokio Kikuchi <tkikuchi at users.sourceforge.net> added the comment:

Hi, all

I am against applying these patches because they will insert space separations in re-composed header (with str() function).

Sm=?ISO-8859-1?B?9g==?=rg=?ISO-8859-1?B?5Q==?=sbord 
-> [('Sm', None), ('\xf6', 'iso-8859-1'), ('rg', None), ('\xe5', 'iso-8859-1'), ('sbord', None)]
-> Sm =?iso-8859-1?q?=F6?= rg =?iso-8859-1?q?=E5?= sbord

Instead, I submit a small recipe for decoding non-compliant RFC2047 header where space separation is not properly inserted between encoded_word and us-ascii characters.

Please try!

----------
Added file: http://bugs.python.org/file19026/u2u_decode.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1079>
_______________________________________

From report at bugs.python.org  Mon Sep 27 03:41:30 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 27 Sep 2010 01:41:30 +0000
Subject: [issue1595365] Urllib2 user-agent header added by an opener is
	"frozen"
Message-ID: <1285551690.63.0.693480525253.issue1595365@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r85025 (py3k), r85026 (release31-maint) and r85027 (release27-maint).

----------
resolution: accepted -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1595365>
_______________________________________

From report at bugs.python.org  Mon Sep 27 04:02:31 2010
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 27 Sep 2010 02:02:31 +0000
Subject: [issue9957] SpooledTemporayFile.truncate should take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

Both file.truncate() and StringIO.truncate() accept an optional "size" parameter to truncate the file to a specific size.  SpooledTemporaryFile should accept a similar parameter and pass it on.

The only tricky part is that truncate can potentially increase the size of a file, so it needs to check the max size and rollover if appropriate.

Patch is against py3k branch; should work on trunk modulo the use of b"xxx" in the tests.

----------
components: Library (Lib)
files: spooledtemporaryfile_truncate.patch
keywords: patch
messages: 117436
nosy: rfk
priority: normal
severity: normal
status: open
title: SpooledTemporayFile.truncate should take size parameter
type: behavior
Added file: http://bugs.python.org/file19027/spooledtemporaryfile_truncate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From report at bugs.python.org  Mon Sep 27 04:07:20 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 27 Sep 2010 02:07:20 +0000
Subject: [issue9955] multiprocessing.Pipe segmentation fault when recv of
	unpicklable object
In-Reply-To: <1285527695.71.0.573625122377.issue9955@psf.upfronthosting.co.za>
Message-ID: <1285553240.18.0.966182122854.issue9955@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9955>
_______________________________________

From report at bugs.python.org  Mon Sep 27 05:19:42 2010
From: report at bugs.python.org (Meador Inge)
Date: Mon, 27 Sep 2010 03:19:42 +0000
Subject: [issue2180] tokenize: mishandles line joining
In-Reply-To: <1203904758.19.0.84784431119.issue2180@psf.upfronthosting.co.za>
Message-ID: <1285557582.21.0.00132348889587.issue2180@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/issue2180>
_______________________________________

From report at bugs.python.org  Mon Sep 27 05:51:55 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 27 Sep 2010 03:51:55 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1285559515.51.0.803448559727.issue5103@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/issue5103>
_______________________________________

From report at bugs.python.org  Mon Sep 27 07:33:36 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 27 Sep 2010 05:33:36 +0000
Subject: [issue9910] Add Py_SetPath API for embedding python
In-Reply-To: <1285050754.57.0.81319423251.issue9910@psf.upfronthosting.co.za>
Message-ID: <1285565616.84.0.0603810031646.issue9910@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Completed in revision 85028

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9910>
_______________________________________

From report at bugs.python.org  Mon Sep 27 10:22:58 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 27 Sep 2010 08:22:58 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285575778.17.0.133625790133.issue9937@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file18999/py27_winreg_EnumValue.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Mon Sep 27 10:23:14 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 27 Sep 2010 08:23:14 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285575794.99.0.978587910817.issue9937@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file19021/py27_fix_winreg_EnumValue_op1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Mon Sep 27 10:25:05 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 27 Sep 2010 08:25:05 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285575905.31.0.370780252473.issue9937@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've withdrew my patch... It has still problem, and
I cannot fix it yet. I suppose option 2 is easy.
ANSI API's limitation makes it harder to implement
correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Mon Sep 27 13:10:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Sep 2010 11:10:16 +0000
Subject: [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285585816.14.0.425599712216.issue9937@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can't we use RegEnumValueW and RegQueryInfoKeyW?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Mon Sep 27 14:25:44 2010
From: report at bugs.python.org (Valentin Kuznetsov)
Date: Mon, 27 Sep 2010 12:25:44 +0000
Subject: [issue9958] (c)elementTree missing children
In-Reply-To: <1285590344.49.0.534410398751.issue9958@psf.upfronthosting.co.za>
Message-ID: <1285590344.49.0.534410398751.issue9958@psf.upfronthosting.co.za>


New submission from Valentin Kuznetsov <vkuznet at gmail.com>:

Hi, I found that parsing XML file with identical structure leads to missing children item at some point. In my test case which I attach it happens at id=183. Basically I have XML with bunch of elements of the following structure:

<processed_dataset id='0'>
        <path dataset_path='/aaa/0'/>
</processed_dataset>
<processed_dataset id='1'>
        <path dataset_path='/aaa/0'/>
</processed_dataset>
....

when I parse them recursively, all, except the one with id=183, are parsed identically. The one with id=183 does not contain children. I tried the code with python 2.6 and python 2.7 on Mac and Linux. Bug exists in both version of ElementTree and cElementTree. Code and testbed XML are attached. Please untar and run as python test_bug.py.
Thanks,
Valentin

----------
files: em_bug.tar
messages: 117440
nosy: vkuznet
priority: normal
severity: normal
status: open
title: (c)elementTree missing children
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file19028/em_bug.tar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9958>
_______________________________________

From report at bugs.python.org  Mon Sep 27 14:54:42 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 27 Sep 2010 12:54:42 +0000
Subject: [issue9958] (c)elementTree missing children
In-Reply-To: <1285590344.49.0.534410398751.issue9958@psf.upfronthosting.co.za>
Message-ID: <1285592082.97.0.128763622403.issue9958@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The given script yields an item on a "start" event; but the element may not be fully populated at this point. please read http://docs.python.org/library/xml.etree.elementtree.html#xml.etree.ElementTree.iterparse

You should use the "end" events instead.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9958>
_______________________________________

From report at bugs.python.org  Mon Sep 27 15:06:15 2010
From: report at bugs.python.org (Geoffrey Bache)
Date: Mon, 27 Sep 2010 13:06:15 +0000
Subject: [issue2972] arguments and default path not set in site.py and
	sitecustomize.py
In-Reply-To: <1211818636.32.0.584139114136.issue2972@psf.upfronthosting.co.za>
Message-ID: <1285592775.85.0.238487723948.issue2972@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

I also just ran into this. Is it likely that an enhancement request to provide access to the "raw" command line, as requested by the previous commenter, would be accepted? It's sometimes useful to have some idea about what kind of Python process is being started at this point.

----------
nosy: +gjb1002

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2972>
_______________________________________

From report at bugs.python.org  Mon Sep 27 15:20:55 2010
From: report at bugs.python.org (Tim Golden)
Date: Mon, 27 Sep 2010 13:20:55 +0000
Subject: [issue2972] arguments and default path not set in site.py and
	sitecustomize.py
In-Reply-To: <1285592775.85.0.238487723948.issue2972@psf.upfronthosting.co.za>
Message-ID: <4CA09A32.7090101@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Merely from a Windows point-of-view, you could get the full
command line fairly easily:

<code>

import ctypes
pstring = ctypes.windll.kernel32.GetCommandLineW ()
print (ctypes.c_wchar_p (pstring).value)

</code>

TJG

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2972>
_______________________________________

From report at bugs.python.org  Mon Sep 27 15:23:04 2010
From: report at bugs.python.org (akira)
Date: Mon, 27 Sep 2010 13:23:04 +0000
Subject: [issue9959] int(math.log(4,2)) == 1 instead of 2
In-Reply-To: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>
Message-ID: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

$ python3.1 -c'import math; f = math.log(4,2); print(int(f), f.as_integer_ratio())'
2 (2, 1)

$ python3.2 -c'import math; f = math.log(4,2); print(int(f), f.as_integer_ratio())'
1 (9007199254740991, 4503599627370496)

Python 3.2a2+ (py3k:85028, Sep 27 2010, 16:46:11) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> f = math.log(32, 2)
>>> f
4.999999999999999
>>> int(f)
4
>>> f.as_integer_ratio()
(5629499534213119, 1125899906842624)

I'm not sure whether it is a bug, but it is an unexpected change in behavior between 3.1 and 3.2.

----------
components: Library (Lib)
messages: 117444
nosy: akira
priority: normal
severity: normal
status: open
title: int(math.log(4,2)) == 1 instead of 2
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9959>
_______________________________________

From report at bugs.python.org  Mon Sep 27 15:53:01 2010
From: report at bugs.python.org (Geoffrey Bache)
Date: Mon, 27 Sep 2010 13:53:01 +0000
Subject: [issue2972] arguments and default path not set in site.py and
	sitecustomize.py
In-Reply-To: <1211818636.32.0.584139114136.issue2972@psf.upfronthosting.co.za>
Message-ID: <1285595581.44.0.175317428278.issue2972@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

Interesting. Any idea if something similar is possible on Linux?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2972>
_______________________________________

From report at bugs.python.org  Mon Sep 27 16:01:50 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 27 Sep 2010 14:01:50 +0000
Subject: [issue9955] multiprocessing.Pipe segmentation fault when recv of
	unpicklable object
In-Reply-To: <1285527695.71.0.573625122377.issue9955@psf.upfronthosting.co.za>
Message-ID: <1285596110.84.0.303861604562.issue9955@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9955>
_______________________________________

From report at bugs.python.org  Mon Sep 27 16:05:38 2010
From: report at bugs.python.org (Tim Golden)
Date: Mon, 27 Sep 2010 14:05:38 +0000
Subject: [issue2972] arguments and default path not set in site.py and
	sitecustomize.py
In-Reply-To: <1211818636.32.0.584139114136.issue2972@psf.upfronthosting.co.za>
Message-ID: <1285596338.46.0.153154462422.issue2972@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

I'm afraid I don't know; might be worth asking that on the main python mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2972>
_______________________________________

From report at bugs.python.org  Mon Sep 27 16:09:24 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Sep 2010 14:09:24 +0000
Subject: [issue9959] int(math.log(4,2)) == 1 instead of 2
In-Reply-To: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>
Message-ID: <1285596564.38.0.245989378177.issue9959@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

No, it's not really a bug:  math.log(x, 2) isn't an atomic operation: it's computed internally as something like log(x) / log(2), and since each of the three steps (computation of the logs, division) can introduce a small rounding error, you shouldn't be surprised if the result doesn't come out exactly.

The difference between 3.1 and 3.2 was a side-effect of a change to remove the dependence of the math module on the internal long integer representation.

Having said that, it would be possible to improve the algorithm that's used to compute log of an integer (see the loghelper function in Modules/mathmodule.c): currently, for positive k, log(2**k) ends up being computed as log(0.5) + (k+1)*log(2), which doesn't help;  it would be slightly better if it were computed directly as k*log(2) instead.  But you still can't (and shouldn't) rely on log(x, 2) giving exact results for powers of 2.

I'm not sure what you're using math.log(x, 2) for, but you may be interested in the int.bit_length method.

----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9959>
_______________________________________

From report at bugs.python.org  Mon Sep 27 17:11:36 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 27 Sep 2010 15:11:36 +0000
Subject: [issue9960] test_structmembers fails on s390x (bigendian 64-bit):
	int/Py_ssize_t issue
In-Reply-To: <1285600296.08.0.731959847047.issue9960@psf.upfronthosting.co.za>
Message-ID: <1285600296.08.0.731959847047.issue9960@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

test test_structmembers crashed -- <type 'exceptions.ValueError'>:
string too long
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7/Lib/test/regrtest.py", line 863, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/builddir/build/BUILD/Python-2.7/Lib/test/test_structmembers.py", line 12, in <module>
    9.99999, 10.1010101010, "hi")
ValueError: string too long

_testcapimodule.c: test_structmembers_new's fmt has:
  "s#"
and these args:
  &s, &string_len

for grabbing this data:
    const char *s = NULL;
    Py_ssize_t string_len = 0;

However, the module doesn't define PY_SSIZE_T_CLEAN, which leads to &string_len being treated as an (int*) rather than a (Py_ssize_t*) and thus written to with just the first 32-bits of the size, rather than the full size.

The PyArgs_ call without PY_SSIZE_T_CLEAN writes the size of the string (2) through (int*)&string_len, writing 0x00000002 to the first 4 bytes, setting the 64-bit "string_len" value to 0x0000000200000000 i.e. 2^34, wildly too large for the iirc 5 byte buffer.

Confirmed in gdb:
  (gdb) p string_len
  $2 = 8589934592

  (gdb) p /x string_len
  $3 = 0x200000000

Am attaching a patch (against 2.7 maintenance branch) which defines PY_SSIZE_T_CLEAN; doing so requires updating another int to be a Py_ssize_t in that module, within test_u_code.


http://docs.python.org/c-api/arg.html lists "u# (Unicode) [Py_UNICODE *, int]" and has no reference to the effect of PY_SSIZE_T_CLEAN on the "u#" format specifier.  My reading of Python/getargs.c is that this macro does affect "u#" in a manner analogous to "s#"; does this documentation need clarifying?

----------
components: Tests
files: python-test_structmembers.patch
keywords: easy, patch
messages: 117448
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: test_structmembers fails on s390x (bigendian 64-bit): int/Py_ssize_t issue
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19029/python-test_structmembers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9960>
_______________________________________

From report at bugs.python.org  Mon Sep 27 17:20:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Sep 2010 15:20:14 +0000
Subject: [issue9960] test_structmembers fails on s390x (bigendian 64-bit):
	int/Py_ssize_t issue
In-Reply-To: <1285600296.08.0.731959847047.issue9960@psf.upfronthosting.co.za>
Message-ID: <1285600814.48.0.511487254017.issue9960@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/issue9960>
_______________________________________

From report at bugs.python.org  Mon Sep 27 17:30:23 2010
From: report at bugs.python.org (Bill Hawkes)
Date: Mon, 27 Sep 2010 15:30:23 +0000
Subject: [issue9961] Identity Crisis! variable assignment using strftime fails
	comparison test.
In-Reply-To: <1285601423.86.0.66942906829.issue9961@psf.upfronthosting.co.za>
Message-ID: <1285601423.86.0.66942906829.issue9961@psf.upfronthosting.co.za>


New submission from Bill Hawkes <williamhawkesjr at yahoo.com>:

See below. When variable assignment is used with strftime for the day of the week, it fails comparison checks for the days of the week. Even when using the str() function it still fails. Manual entry of variable assignment is required for a successful comparison. This pretty well defeats the purpose of computer programming (automation). There seems to be a real identity crisis here!

$ python3
Python 3.0rc1+ (py3k, Oct 28 2008, 09:23:29) 
[GCC 4.3.2] on linux2
>>> import time
>>> from datetime import date
>>> today = date.today()
>>> print("This line will always print")
This line will always print
>>> myday = today.fromordinal(today.toordinal() - 31)
>>> printthis = myday.strftime("%m-%d-%y. %d %b %Y is a %A on the %d day of %B.")
>>> print("%s" % printthis)
08-27-10. 27 Aug 2010 is a Friday on the 27 day of August.
>>> # dow is Day Of Week variable
... dow = myday.strftime("%A")
>>> chkval = dow
>>> dow is chkval
True
>>> print("dow is %s" % dow)
dow is Friday
>>> print("chkval is %s" % chkval)
chkval is Friday
>>> print("%s" % dow)
Friday
>>> print("%s" % chkval)
Friday
>>> dow is chkval
True
>>> if dow is 'Sunday':
...    cntbck = 0
... elif dow is 'Monday':
...    cntbck = 1
... elif dow is 'Tuesday':
...    cntbck = 2
... elif dow is 'Wednesday':
...    cntbck = 3
... elif dow is 'Thursday':
...    cntbck = 4
... elif dow is 'Friday':
...    cntbck = 5
... elif dow is 'Saturday':
...    cntbck = 6
... else:
...    cntbck = 'undefined'
...    print("What day is it? It is %s" % dow)
... 
What day is it? It is Friday
>>> print('finished with script')
finished with script
>>> dow is 'Friday'
False
>>> dow = 'Friday'
>>> dow is 'Friday'
True
>>> chkval
'Friday'
>>> dow
'Friday'
>>> chkval is dow
False
>>>  chkval is 'Friday'
False
>>> chkval
'Friday'
>>> chkval = str(chkval)
>>> chkval
'Friday'
>>> chkval is 'Friday'
False
>>> cntbck
'undefined'
>>>

----------
components: Interpreter Core
messages: 117449
nosy: BillHawkes
priority: normal
severity: normal
status: open
title: Identity Crisis! variable assignment using strftime fails comparison test.
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9961>
_______________________________________

From report at bugs.python.org  Mon Sep 27 17:31:54 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 27 Sep 2010 15:31:54 +0000
Subject: [issue9961] Identity Crisis! variable assignment using strftime fails
	comparison test.
In-Reply-To: <1285601423.86.0.66942906829.issue9961@psf.upfronthosting.co.za>
Message-ID: <1285601514.18.0.578505274975.issue9961@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

You mistakenly used "is" for these comparisons, rather than "==".  The strftime involvement is a red herring.  The real problem is the use of an /identity/ comparison rather than an /equality/ comparison.

----------
nosy: +exarkun
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9961>
_______________________________________

From report at bugs.python.org  Mon Sep 27 17:33:07 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 27 Sep 2010 15:33:07 +0000
Subject: [issue1615376] subprocess doesn\'t handle SIGPIPE
Message-ID: <1285601587.53.0.066324442433.issue1615376@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/issue1615376>
_______________________________________

From report at bugs.python.org  Mon Sep 27 17:33:19 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 27 Sep 2010 15:33:19 +0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1285601599.6.0.0401079019904.issue1652@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/issue1652>
_______________________________________

From report at bugs.python.org  Mon Sep 27 18:31:31 2010
From: report at bugs.python.org (Todd Whiteman)
Date: Mon, 27 Sep 2010 16:31:31 +0000
Subject: [issue9609] make cProfile multi-stack aware
In-Reply-To: <1281884976.7.0.103613520648.issue9609@psf.upfronthosting.co.za>
Message-ID: <1285605091.09.0.493722637826.issue9609@psf.upfronthosting.co.za>


Changes by Todd Whiteman <twhitema at yahoo.com.au>:


----------
nosy: +twhitema

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9609>
_______________________________________

From report at bugs.python.org  Mon Sep 27 19:26:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 27 Sep 2010 17:26:17 +0000
Subject: [issue9941] Unify trace and profile interfaces
In-Reply-To: <1285347468.19.0.483467963743.issue9941@psf.upfronthosting.co.za>
Message-ID: <1285608377.01.0.699247005178.issue9941@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I've ran into a problem adding context manager functionality to Profile/Trace objects.  When profile/trace function is set in __enter__ and removed in __exit__ it catches two spurious events: a return from __enter__ and a call to __exit__.  This is particularly problematic with Profile which is not prepared to handle a return event that does not follow a matching call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9941>
_______________________________________

From report at bugs.python.org  Mon Sep 27 19:36:30 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 27 Sep 2010 17:36:30 +0000
Subject: [issue1634774] locale 1251 does not convert to upper case properly
Message-ID: <1285608990.47.0.493513346921.issue1634774@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

the OP is right: str.upper is supposed to be locale-dependent
http://docs.python.org/library/stdtypes.html#str.upper

But the implementation uses _toupper() which is a macro with Visual Studio, and obviously not locale-dependent:

#define _toupper(_Char)    ( (_Char)-'a'+'A' )

----------
nosy: +amaury.forgeotdarc
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1634774>
_______________________________________

From report at bugs.python.org  Mon Sep 27 19:56:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 17:56:53 +0000
Subject: [issue9950] socket.sendall() crash when receiving a signal
In-Reply-To: <1285441668.88.0.256888401487.issue9950@psf.upfronthosting.co.za>
Message-ID: <1285610213.27.0.855183461093.issue9950@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r85032. I'm gonna watch the buildbots a bit, in case the test fails on some platforms.

----------
assignee:  -> pitrou
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9950>
_______________________________________

From report at bugs.python.org  Mon Sep 27 19:57:30 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 27 Sep 2010 17:57:30 +0000
Subject: [issue8521] Allow some winreg functions to accept named arguments
In-Reply-To: <1272136603.7.0.986572012684.issue8521@psf.upfronthosting.co.za>
Message-ID: <1285610250.42.0.660155185456.issue8521@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed in r85033.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8521>
_______________________________________

From report at bugs.python.org  Mon Sep 27 20:02:04 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 27 Sep 2010 18:02:04 +0000
Subject: [issue8158] documentation of 'optparse' module incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1285610524.74.0.199058875162.issue8158@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
since 2.7 optparse is deprecated in favor of argparse: is this bug still worth to be fixed? If so, I can work on a patch for the doc.

Regards,
Sandro

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8158>
_______________________________________

From report at bugs.python.org  Mon Sep 27 20:13:16 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 27 Sep 2010 18:13:16 +0000
Subject: [issue8158] documentation of 'optparse' module incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1285611196.89.0.50327192002.issue8158@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Sorry, I probably overlooked at the situation. After a quick chat with Antoine on IRC, it's clear optparse is here to stay for all the lifetime of 2.7 (quite a long and prosper, we hope :) so yes, it's worth work on its documentation, hence I'll start preparing a patch and I'll submit it asap.

Cheers,
Sandro

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8158>
_______________________________________

From report at bugs.python.org  Mon Sep 27 20:14:24 2010
From: report at bugs.python.org (akira)
Date: Mon, 27 Sep 2010 18:14:24 +0000
Subject: [issue9959] int(math.log(4,2)) == 1 instead of 2
In-Reply-To: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>
Message-ID: <1285611264.03.0.638506478445.issue9959@psf.upfronthosting.co.za>


akira <4kir4.1i at gmail.com> added the comment:

> No, it's not really a bug: math.log(x, 2) isn't an atomic operation:

It is not a bug, but values of math.log(4) differs between 3.1 and 3.2
i.e., math.log(4.0) in 3.2 returns value that is consistent with
math.log(4) in 3.1 but math.log(4) in 3.2 doesn't.

> I'm not sure what you're using math.log(x, 2) for, but you may be
interested in the int.bit_length method.

The docs for int.bit_length say: 

> if x is nonzero, then x.bit_length() is the unique positive integer
k such that 2**(k-1) <= abs(x) < 2**k. Equivalently, when abs(x) is
small enough to have a correctly rounded logarithm, then k = 1 +
int(log(abs(x), 2)).

It is expected that int(log(n,2)) produces correct result for small n.

> Having said that, it would be possible to improve the algorithm
 that's used to compute log of an integer (see the loghelper function
 in Modules/mathmodule.c): currently, for positive k, log(2**k) ends
 up being computed as log(0.5) + (k+1)*log(2), which doesn't help; it
 would be slightly better if it were computed directly as k*log(2)
 instead.  But you still can't (and shouldn't) rely on log(x, 2)
 giving exact results for powers of 2.

I've changed loghelper() to return improved result for power of 2

----------
keywords: +patch
Added file: http://bugs.python.org/file19030/math_log_power_two.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9959>
_______________________________________

From report at bugs.python.org  Mon Sep 27 20:15:06 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 27 Sep 2010 18:15:06 +0000
Subject: [issue9441] increase logging handlers test coverage
In-Reply-To: <1280597180.41.0.450800729974.issue9441@psf.upfronthosting.co.za>
Message-ID: <1285611306.28.0.695460510278.issue9441@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

It would be nice to see tests for NTEventLogHandler, as there are currently none.

I looked into implementing NTEventLogHandler's Win32 calls in a C extension rather than requiring a third-party module, but stopped once I realized there weren't any tests. I may get to it myself, but I thought I'd throw this out there.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9441>
_______________________________________

From report at bugs.python.org  Mon Sep 27 20:15:54 2010
From: report at bugs.python.org (akira)
Date: Mon, 27 Sep 2010 18:15:54 +0000
Subject: [issue9959] int(math.log(4,2)) == 1 instead of 2
In-Reply-To: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>
Message-ID: <1285611354.26.0.0728649327387.issue9959@psf.upfronthosting.co.za>


Changes by akira <4kir4.1i at gmail.com>:


Added file: http://bugs.python.org/file19031/test_log_power_two.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9959>
_______________________________________

From report at bugs.python.org  Mon Sep 27 20:27:57 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 27 Sep 2010 18:27:57 +0000
Subject: [issue1665333] Documentation missing for OptionGroup class in optparse
Message-ID: <1285612077.29.0.56562107678.issue1665333@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I will work on it, it noone objects.

Cheers,
Sandro

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1665333>
_______________________________________

From report at bugs.python.org  Mon Sep 27 20:33:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 18:33:39 +0000
Subject: [issue9950] socket.sendall() crash when receiving a signal
In-Reply-To: <1285441668.88.0.256888401487.issue9950@psf.upfronthosting.co.za>
Message-ID: <1285612419.39.0.757906131991.issue9950@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch passes at least on Linux, OS X and Solaris buildbots. Backported to 3.1 (r85034) and 2.7 (r85035).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9950>
_______________________________________

From report at bugs.python.org  Mon Sep 27 20:38:49 2010
From: report at bugs.python.org (akira)
Date: Mon, 27 Sep 2010 18:38:49 +0000
Subject: [issue9959] int(math.log(4,2)) == 1 instead of 2
In-Reply-To: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>
Message-ID: <1285612729.12.0.827707192659.issue9959@psf.upfronthosting.co.za>


Changes by akira <4kir4.1i at gmail.com>:


----------
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9959>
_______________________________________

From report at bugs.python.org  Mon Sep 27 20:53:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Sep 2010 18:53:55 +0000
Subject: [issue9929] subprocess.Popen unbuffered not work
In-Reply-To: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>
Message-ID: <1285613635.0.0.676827236594.issue9929@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

But if line buffering doesn't work, disabling buffering on stdout/stderr does have a functional consequence: it allows process output to appear as generated instead of coming in chunks when the buffer is full.  Of course, I could be completely misunderstanding what you are talking about :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9929>
_______________________________________

From report at bugs.python.org  Mon Sep 27 20:59:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 18:59:04 +0000
Subject: [issue9929] subprocess.Popen unbuffered not work
In-Reply-To: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>
Message-ID: <1285613944.92.0.0747627770598.issue9929@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But if line buffering doesn't work, disabling buffering on 
> stdout/stderr does have a functional consequence: it allows process 
> output to appear as generated instead of coming in chunks when the
> buffer is full

Yes, sorry, I had it backwards. It's buffering on stdin which doesn't make any functional difference (whether it's buffered or not, you always get data as soon as it arrives).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9929>
_______________________________________

From report at bugs.python.org  Mon Sep 27 21:00:54 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 27 Sep 2010 19:00:54 +0000
Subject: [issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning
	correctly in Python 2.7
In-Reply-To: <1276153559.93.0.766128008061.issue8959@psf.upfronthosting.co.za>
Message-ID: <1285614054.36.0.566043638638.issue8959@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This doesn't seem to be an issue anymore.

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Mon Sep 27 21:17:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 19:17:34 +0000
Subject: [issue9934] Python Docs Typo
In-Reply-To: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>
Message-ID: <1285615054.74.0.476674902815.issue9934@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ported to distutils2 in 2f460982b025, thanks!

----------
components: +Distutils2
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9934>
_______________________________________

From report at bugs.python.org  Mon Sep 27 21:50:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 19:50:51 +0000
Subject: [issue9943] TypeError message became less helpful in Python 2.7
In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za>
Message-ID: <1285617051.36.0.127738661832.issue9943@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/issue9943>
_______________________________________

From report at bugs.python.org  Mon Sep 27 21:51:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 19:51:50 +0000
Subject: [issue9945] Improper locking in logging
In-Reply-To: <1285421253.55.0.777992318976.issue9945@psf.upfronthosting.co.za>
Message-ID: <1285617110.2.0.59665025022.issue9945@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Just to be sure: this does not apply to 3.1?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9945>
_______________________________________

From report at bugs.python.org  Mon Sep 27 21:52:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 19:52:13 +0000
Subject: [issue9946] lock use in logging
In-Reply-To: <1285423118.6.0.459283406836.issue9946@psf.upfronthosting.co.za>
Message-ID: <1285617133.72.0.459405543946.issue9946@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
superseder:  -> Improper locking in logging

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9946>
_______________________________________

From report at bugs.python.org  Mon Sep 27 21:56:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 19:56:18 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1285617378.5.0.329982930866.issue3532@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See #9951 for a patch adding bytes.hex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Mon Sep 27 21:56:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 19:56:45 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1285617405.65.0.093666704768.issue9951@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/issue9951>
_______________________________________

From report at bugs.python.org  Mon Sep 27 21:58:14 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 27 Sep 2010 19:58:14 +0000
Subject: [issue9957] SpooledTemporayFile.truncate should take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <1285617494.27.0.84271964817.issue9957@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +georg.brandl
stage:  -> patch review
type: behavior -> feature request
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:01:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 20:01:03 +0000
Subject: [issue9956] memoryview type documentation lacks versionadded
In-Reply-To: <1285544669.44.0.903225365456.issue9956@psf.upfronthosting.co.za>
Message-ID: <1285617663.87.0.79191947071.issue9956@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Python 3.1 is considered a new start, so there is no versionadded:: 3.1.  The directive is used for things new in 3.2 and later versions.  Thanks for the patch!

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9956>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:06:00 2010
From: report at bugs.python.org (Geoffrey Bache)
Date: Mon, 27 Sep 2010 20:06:00 +0000
Subject: [issue9943] TypeError message became less helpful in Python 2.7
In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za>
Message-ID: <1285617960.2.0.59986178899.issue9943@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

I agree with Nick :) 

Though I'd say fixing a regression should take priority over further enhancing the messages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9943>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:06:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 20:06:13 +0000
Subject: [issue9957] SpooledTemporayFile.truncate should take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <1285617973.81.0.890773133963.issue9957@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the report and patch.  Not sure if this a bug or a new feature.

Patch looks good, thanks for including a test too!.  Can you also edit the documentation?

(There are very minor whitespace nits in the patch, but I leave it to Georg to fix them or ignore them.)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:10:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 20:10:28 +0000
Subject: [issue1703592] have a way to ignore nonexisting locales in
	locale.setlocale
Message-ID: <1285618228.08.0.114860418375.issue1703592@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1703592>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:28:29 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Sep 2010 20:28:29 +0000
Subject: [issue9959] int(math.log(4,2)) == 1 instead of 2
In-Reply-To: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>
Message-ID: <1285619309.44.0.601633733763.issue9959@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It is not a reasonable request for math float functions to produce exact integer values and there is some harm in making further alterations to the existing algorithm (the more you tweak it in one place, the more you create oddities somewhere else).

There may be a case for a separate math.log2() function but this has never been requested before, so it is a low priority.

If the docs for bit_length() bug you, I can change them.  They are meant to be the exact math definition of bit_length, not an executable exact result using limited precision floating point.   Those docs are trying to inform users about bit_length() and are not making a promise about the behavior of math.log().

If you're wanting exact log results for integer inputs and bases, the math module is going to disappoint you no matter what we do.  This is a limited-precision-floating-point fact of life.

----------
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9959>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:39:02 2010
From: report at bugs.python.org (Constantin Veretennicov)
Date: Mon, 27 Sep 2010 20:39:02 +0000
Subject: [issue1776674] glob.glob inconsistent
Message-ID: <1285619942.81.0.680688178169.issue1776674@psf.upfronthosting.co.za>


Changes by Constantin Veretennicov <kveretennicov at gmail.com>:


----------
nosy: +kveretennicov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1776674>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:39:42 2010
From: report at bugs.python.org (Constantin Veretennicov)
Date: Mon, 27 Sep 2010 20:39:42 +0000
Subject: [issue9584] Allow curly braces in fnmatch
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1285619982.84.0.110864848541.issue9584@psf.upfronthosting.co.za>


Changes by Constantin Veretennicov <kveretennicov at gmail.com>:


----------
nosy: +kveretennicov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:40:12 2010
From: report at bugs.python.org (Constantin Veretennicov)
Date: Mon, 27 Sep 2010 20:40:12 +0000
Subject: [issue4573] zsh-style subpattern matching for fnmatch/glob
In-Reply-To: <1228637877.49.0.438531462048.issue4573@psf.upfronthosting.co.za>
Message-ID: <1285620012.83.0.23817133457.issue4573@psf.upfronthosting.co.za>


Changes by Constantin Veretennicov <kveretennicov at gmail.com>:


----------
nosy: +kveretennicov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4573>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:41:29 2010
From: report at bugs.python.org (Constantin Veretennicov)
Date: Mon, 27 Sep 2010 20:41:29 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1285620089.73.0.269331714628.issue8402@psf.upfronthosting.co.za>


Changes by Constantin Veretennicov <kveretennicov at gmail.com>:


----------
nosy: +kveretennicov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:52:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 20:52:16 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1285620736.19.0.259687265957.issue3873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

One problem with the seek() approach is that some file-like objects have expensive seeks. One example is GzipFile, where seek(n) is O(n) (it first rewinds to the start of file, then reads n decompressed bytes). In the end, unpickling from a GzipFile becomes O(n**2).

I will try to use peek() instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:58:07 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 27 Sep 2010 20:58:07 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1285620736.19.0.259687265957.issue3873@psf.upfronthosting.co.za>
Message-ID: <AANLkTinUg=1r6ashosG5p5T7fR2jhOtTsu=E-=BUB+jR@mail.gmail.com>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Didn't Victor say that only one seek at the end is necessary per
pickle? If this is the case, I don't think expensive seeks will be an
issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Mon Sep 27 22:59:58 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Sep 2010 20:59:58 +0000
Subject: [issue8787] warnings inside PyRun_SimpleString() display argv[1]
In-Reply-To: <1274536832.39.0.220188636264.issue8787@psf.upfronthosting.co.za>
Message-ID: <1285621198.99.0.464821168241.issue8787@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/issue8787>
_______________________________________

From report at bugs.python.org  Mon Sep 27 23:08:59 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Sep 2010 21:08:59 +0000
Subject: [issue7397] __import__ docs should reference importlib.import_module
In-Reply-To: <1259235199.82.0.599302527492.issue7397@psf.upfronthosting.co.za>
Message-ID: <1285621739.92.0.281056679854.issue7397@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixed in r85043.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7397>
_______________________________________

From report at bugs.python.org  Mon Sep 27 23:23:43 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Sep 2010 21:23:43 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1285622623.67.0.1957162086.issue9082@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

What specific failures are you talking about, Michael? I just ran regrtest with -O and had no (unexpected) failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Mon Sep 27 23:38:34 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 27 Sep 2010 21:38:34 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1285623514.32.0.760255965445.issue9082@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

When I run with -OO I get 42 test failures. Most of them look like they are due to missing docstrings but some are likely to be due to missing asserts.

42 tests failed:
    test_bisect test_cmd test_code test_collections test_compileall
    test_ctypes test_decimal test_deque test_descrtut test_dictcomps
    test_difflib test_dis test_distutils test_doctest test_extcall
    test_generators test_genexps test_getopt test_http_cookies
    test_import test_itertools test_json test_lib2to3 test_listcomps
    test_math test_metaclass test_pdb test_pickle test_pickletools
    test_pyclbr test_setcomps test_syntax test_threading_local
    test_tokenize test_unpack test_unpack_ex test_urllib2 test_weakref
    test_xml_etree test_xml_etree_c test_zipimport
    test_zipimport_support

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Mon Sep 27 23:38:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 21:38:35 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

GzipFile claims to implement BufferedIOBase but doesn't have peek().

----------
components: Library (Lib)
messages: 117476
nosy: nirai, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: GzipFile doesn't have peek()
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9962>
_______________________________________

From report at bugs.python.org  Mon Sep 27 23:40:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 21:40:52 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1285623652.85.0.865143995182.issue9082@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Mon Sep 27 23:42:32 2010
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 27 Sep 2010 21:42:32 +0000
Subject: [issue9957] SpooledTemporayFile.truncate should take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <1285623752.61.0.680171782147.issue9957@psf.upfronthosting.co.za>


Ryan Kelly <ryan at rfk.id.au> added the comment:

I went looking for places to update the documentation but the description of SpooledTemporaryFile doesn't go into any detail of its methods, so I haven't added anything.  New patch fixes some whitespace issues.

I'd like to argue that this is a bug, since SpooledTemporaryFile is documented as "operates exactly as TemporaryFile() does", and TemporaryFile.truncate accepts a "size" parameter.

----------
Added file: http://bugs.python.org/file19032/spooledtemporaryfile_truncate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From report at bugs.python.org  Mon Sep 27 23:42:42 2010
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 27 Sep 2010 21:42:42 +0000
Subject: [issue9957] SpooledTemporayFile.truncate should take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <1285623762.38.0.751499169071.issue9957@psf.upfronthosting.co.za>


Changes by Ryan Kelly <ryan at rfk.id.au>:


Removed file: http://bugs.python.org/file19027/spooledtemporaryfile_truncate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From report at bugs.python.org  Mon Sep 27 23:48:17 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 27 Sep 2010 21:48:17 +0000
Subject: [issue9945] Improper locking in logging
In-Reply-To: <1285421253.55.0.777992318976.issue9945@psf.upfronthosting.co.za>
Message-ID: <1285624097.17.0.717468195269.issue9945@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Good call, ?ric - fix backported into release31-maint (r85045).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9945>
_______________________________________

From report at bugs.python.org  Mon Sep 27 23:51:56 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 27 Sep 2010 21:51:56 +0000
Subject: [issue9947] Weird locking in logging config system
In-Reply-To: <1285424260.64.0.915728022787.issue9947@psf.upfronthosting.co.za>
Message-ID: <1285624316.43.0.51247457072.issue9947@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into release31-maint (r85046).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9947>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:06:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 22:06:37 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <AANLkTinUg=1r6ashosG5p5T7fR2jhOtTsu=E-=BUB+jR@mail.gmail.com>
Message-ID: <1285625191.10095.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Didn't Victor say that only one seek at the end is necessary per
> pickle? If this is the case, I don't think expensive seeks will be an
> issue.

If you are unpickling from a multi-megabyte gzip file and the seek at
the end makes you uncompress all the gzip file again, it can certainly
be a problem.

Another issue with seeking only at the end is that it would make
readline() quite more complicated. And, apparently, readline() is not
only used on protocol 0 but also on binary protocols.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:11:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 22:11:38 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1285625498.17.0.930612191253.issue3873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an update bench_pickle which also makes the file unpeekable.

----------
Added file: http://bugs.python.org/file19033/bench_pickle.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:11:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 22:11:43 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1285625503.98.0.557768947916.issue3873@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file18241/bench_pickle.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:11:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 22:11:48 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1285625508.09.0.280000919733.issue3873@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file18983/bench_pickle.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:23:08 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 27 Sep 2010 22:23:08 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1285626188.56.0.479635758355.issue9082@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Most of those failures look like they have a similar cause (not all of them though) related to running doctests. When issue 6292 was closed all tests passed with -OO, so this is a regression. I'm raising a separate issue for that. 

Looking at the code actually in warnings.filterwarnings (currently at any rate) I wonder what tests possibly could fail due to the asserts not being run? Maybe I hallucinated the problem... (Or more likely it was actually another issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:23:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 22:23:15 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1285626195.53.0.699037729019.issue3873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch using peek() rather than seek(). There are some inefficiencies around (such as using read() to skip the consumed prefetched bytes), but the benchmark results are still as good as with seek():

Protocol 0
- dump: 142.5 ms
- load (seekable=False): 598.8 ms
- load (seekable=True): 240.2 ms

Protocol 1
- dump: 28.9 ms
- load (seekable=False): 253.2 ms
- load (seekable=True): 25.7 ms

Protocol 2
- dump: 28.9 ms
- load (seekable=False): 253.3 ms
- load (seekable=True): 25.7 ms

----------
Added file: http://bugs.python.org/file19034/unpickleprefetch3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:26:35 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Sep 2010 22:26:35 +0000
Subject: [issue9963] test_sysconfig when LDFLAGS defined in the user's
	environment
In-Reply-To: <1285626395.1.0.70736928165.issue9963@psf.upfronthosting.co.za>
Message-ID: <1285626395.1.0.70736928165.issue9963@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

test_sysconfig.test_ldshared_value is failing for me on Mac because my LDFLAGS environment variable is being defined twice in what sysconfig.get_config_var('LDFLAGS') returns. This fails in a comparison against sysconfig.get_config_var('LDSHARED') as the values are only set once::

AssertionError: '-L/Users/brett/.slash/_/lib -L/Users/brett/.local/lib  -L/Users/brett/.slash/_/lib -L/Users/brett/.local/lib' not found in 'clang  -L/Users/brett/.slash/_/lib -L/Users/brett/.local/lib -bundle -undefined dynamic_lookup'

I suspect what is happening is sysconfig is using PY_LDFLAGS, which uses both CONFIGURE_LDFLAGS *and* LDFLAGS when the Makefile is run. This leads to LDFLAGS being set twice if it was pulled from the user's environment variable

----------
components: Library (Lib)
messages: 117484
nosy: brett.cannon
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: test_sysconfig when LDFLAGS defined in the user's environment
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9963>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:27:00 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 27 Sep 2010 22:27:00 +0000
Subject: [issue9964] Test failures with -OO
In-Reply-To: <1285626420.9.0.187351711939.issue9964@psf.upfronthosting.co.za>
Message-ID: <1285626420.9.0.187351711939.issue9964@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

When I run the test suite (py3k branch) with -OO I get 42 failures. Most of these look like they are caused by the same (or a similar) problem (attempting to run doctests from now-non-existent docstrings).

The tests that fail are:

When I run with -OO I get 42 test failures. Most of them look like they are due to missing docstrings but some are likely to be due to missing asserts.

42 tests failed:
    test_bisect test_cmd test_code test_collections test_compileall
    test_ctypes test_decimal test_deque test_descrtut test_dictcomps
    test_difflib test_dis test_distutils test_doctest test_extcall
    test_generators test_genexps test_getopt test_http_cookies
    test_import test_itertools test_json test_lib2to3 test_listcomps
    test_math test_metaclass test_pdb test_pickle test_pickletools
    test_pyclbr test_setcomps test_syntax test_threading_local
    test_tokenize test_unpack test_unpack_ex test_urllib2 test_weakref
    test_xml_etree test_xml_etree_c test_zipimport
    test_zipimport_support

Typical tracebacks (one explicitly calling doctest code, the other through test.support):

Traceback (most recent call last):
  File "Lib/test/test_collections.py", line 3, in <module>
    import unittest, doctest, operator
  File "/compile/py3k/Lib/doctest.py", line 97, in <module>
    import unittest, difflib, pdb, tempfile
  File "/compile/py3k/Lib/pdb.py", line 1348, in <module>
    __doc__ += getattr(Pdb, 'do_' + _command).__doc__.strip() + '\n\n'
AttributeError: 'NoneType' object has no attribute 'strip'

Traceback (most recent call last):
  File "Lib/test/test_code.py", line 169, in <module>
    test_main()
  File "Lib/test/test_code.py", line 164, in test_main
    run_doctest(test_code, verbose)
  File "/compile/py3k/Lib/test/support.py", line 1142, in run_doctest
    import doctest
  File "/compile/py3k/Lib/doctest.py", line 97, in <module>
    import unittest, difflib, pdb, tempfile
  File "/compile/py3k/Lib/pdb.py", line 1348, in <module>
    __doc__ += getattr(Pdb, 'do_' + _command).__doc__.strip() + '\n\n'
AttributeError: 'NoneType' object has no attribute 'strip'


Issue 6292 was previously closed when all tests ran successfully with -OO, so this is a more recent regression.

----------
components: Tests
messages: 117485
nosy: michael.foord, r.david.murray
priority: normal
severity: normal
status: open
title: Test failures with -OO
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9964>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:28:13 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Sep 2010 22:28:13 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1285626493.43.0.857844239142.issue9082@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'm going to close this as I don't think any of the failures are because of the asserts, else -O would pick them up just as well as -OO.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:44:40 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 27 Sep 2010 22:44:40 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1285627480.48.0.127648993666.issue9082@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Cool - although I *do* see failures under -O; test_import for example. That one is a __pycache__ test, so barry's fault I think.

I'll detail the failures in issue 9964 as I think *most* of them are caused by a problem with pdb.py

In fact, if you run Python with -OO you can't even *import* pdb.

The attached patch fixes that problem (a hasty and untested patch though), and that reduces the number of failures to 5:

5 tests failed:
    test_compileall test_dis test_import test_lib2to3 test_xml_etree

----------
keywords: +patch
Added file: http://bugs.python.org/file19035/pdb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:45:19 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 27 Sep 2010 22:45:19 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1285627519.31.0.43768510584.issue9082@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


Removed file: http://bugs.python.org/file19035/pdb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:46:13 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 27 Sep 2010 22:46:13 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1285627573.0.0.176583546246.issue9082@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Oops. The patch should go to issue 9964. Sorry for all this noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:47:31 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 27 Sep 2010 22:47:31 +0000
Subject: [issue9964] Test failures with -OO
In-Reply-To: <1285626420.9.0.187351711939.issue9964@psf.upfronthosting.co.za>
Message-ID: <1285627651.91.0.619575763248.issue9964@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Most of the failures are caused by a problem in pdb.

In fact, if you run Python with -OO you can't even *import* pdb.

The attached patch fixes that problem (a hasty and untested patch though), and that reduces the number of failures to 5:

5 tests failed:
    test_compileall test_dis test_import test_lib2to3 test_xml_etre

----------
keywords: +patch
nosy: +georg.brandl
Added file: http://bugs.python.org/file19036/pdb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9964>
_______________________________________

From report at bugs.python.org  Tue Sep 28 01:50:19 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 27 Sep 2010 23:50:19 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1285631419.58.0.968134794329.issue4111@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Updated py3k version of patch.

Changes:
  - renamed the probepoints:
      "function__entry" -> "frame__entry"
      "function__return" -> "frame__exit"
    as I believe this better describes what these do    
  - added a test suite: Lib/test/test_systemtap.py
  - reformatted to use 4-space indentation
  - slightly reworked the configure.in code

Some error-handling issue remain (see the FIXMEs in the code)

Tested and working on Fedora 13 x86_64, using:
  systemtap-1.3-1.fc13.x86_64
  kernel-2.6.33.3-84.fc13.x86_64
  kernel-devel-2.6.33.3-84.fc13.x86_64
  kernel-headers-2.6.33.3-84.fc13.x86_64
  kernel-debuginfo-2.6.33.3-84.fc13.x86_64
  kernel-debuginfo-common-x86_64-2.6.33.3-84.fc13.x86_64

----------
Added file: http://bugs.python.org/file19037/py3k-add-systemtap-2010-09-27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Sep 28 01:56:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 23:56:50 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285631810.42.0.605684974492.issue9962@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a first patch, tests still need to be written.

----------
keywords: +patch
Added file: http://bugs.python.org/file19038/gzippeek.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9962>
_______________________________________

From report at bugs.python.org  Tue Sep 28 02:07:48 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 28 Sep 2010 00:07:48 +0000
Subject: [issue9965] Loading malicious pickle may cause excessive memory usage
In-Reply-To: <1285632468.19.0.235987005106.issue9965@psf.upfronthosting.co.za>
Message-ID: <1285632468.19.0.235987005106.issue9965@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

This was mentioned during the review of issue #9410
(http://codereview.appspot.com/1694050/diff/2001/3001#newcode347), however we forgot to fix this.

The new array-based memo for the Unpickler class assumes incorrectly that memo indices are always contiguous. This is not the case. And due to this, the following pickle will cause Unpickler to use about 3GB of memory to store the memo array.

./python -c "import pickle; pickle.loads(b'\x80\x02]r\xff\xff\xff\x06.')"

To fix this, we can add code to fall-back to a dictionary-based memo when the memo keys are not contiguous.

----------
components: Extension Modules
messages: 117492
nosy: alexandre.vassalotti
priority: critical
severity: normal
stage: needs patch
status: open
title: Loading malicious pickle may cause excessive memory usage
type: security
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9965>
_______________________________________

From report at bugs.python.org  Tue Sep 28 02:08:21 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 28 Sep 2010 00:08:21 +0000
Subject: [issue9965] Loading malicious pickle may cause excessive memory usage
In-Reply-To: <1285632468.19.0.235987005106.issue9965@psf.upfronthosting.co.za>
Message-ID: <1285632501.99.0.65860178683.issue9965@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9965>
_______________________________________

From report at bugs.python.org  Tue Sep 28 02:12:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 00:12:56 +0000
Subject: [issue9965] Loading malicious pickle may cause excessive memory usage
In-Reply-To: <1285632468.19.0.235987005106.issue9965@psf.upfronthosting.co.za>
Message-ID: <1285632776.62.0.243087715603.issue9965@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think there's any point doing this. Pickle is insecure by construction; it shouldn't crash when used legitimately, but trying to make it robust in the face of hand-crafted pickle strings sounds like an uphill battle (*).

(*) e.g. http://nadiana.com/python-pickle-insecure

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9965>
_______________________________________

From report at bugs.python.org  Tue Sep 28 02:27:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 00:27:18 +0000
Subject: [issue9965] Loading malicious pickle may cause excessive memory usage
In-Reply-To: <1285632468.19.0.235987005106.issue9965@psf.upfronthosting.co.za>
Message-ID: <1285633638.73.0.969141786557.issue9965@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As an example of malicious pickle causing "excessive" memory usage, you can simply write:

>>> s = b'\x80\x03cbuiltins\nbytearray\nq\x00J\x00\x00\x00\x7f\x85q\x01Rq\x02.'
>>> _ = pickle.loads(s)

This will allocate an almost 2GB bytearray. You can of course change the size as you like. Here is the disassembly:

>>> pickletools.dis(s)
    0: \x80 PROTO      3
    2: c    GLOBAL     'builtins bytearray'
   22: q    BINPUT     0
   24: J    BININT     2130706432
   29: \x85 TUPLE1
   30: q    BINPUT     1
   32: R    REDUCE
   33: q    BINPUT     2
   35: .    STOP
highest protocol among opcodes = 2


Therefore, I would recommend closing this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9965>
_______________________________________

From report at bugs.python.org  Tue Sep 28 02:34:45 2010
From: report at bugs.python.org (Florent Gallaire)
Date: Tue, 28 Sep 2010 00:34:45 +0000
Subject: [issue9966] platform : a boolean to know easily when a system is posix
In-Reply-To: <1285634085.25.0.52252512228.issue9966@psf.upfronthosting.co.za>
Message-ID: <1285634085.25.0.52252512228.issue9966@psf.upfronthosting.co.za>


New submission from Florent Gallaire <fgallaire at gmail.com>:

Hi,

The platform module could provide a boolean to know easily if a system is posix or not.

The expected result, when the system is posix :

>>> import platform
>>> platform.isposix
True

otherwise :

>>> import platform
>>> platform.isposix
False

Here is a patch to do so. It also provides an update for the platform
documentation and a test case.

Best regards

Florent Gallaire

----------
components: Library (Lib)
files: platform_isposix_boolean.py
messages: 117495
nosy: fgallaire
priority: normal
severity: normal
status: open
title: platform : a boolean to know easily when a system is posix
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file19039/platform_isposix_boolean.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9966>
_______________________________________

From report at bugs.python.org  Tue Sep 28 02:36:53 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Tue, 28 Sep 2010 00:36:53 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285634213.09.0.61318219126.issue9864@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

Here's a patch for the python-email6 branch.

It seemed to make sense to remove parsedate_tz() and mktime_tz() here, since the parsedate() function now returns a datetime object, including timezone information (if it was parsed from the input string).

Also required updating several tests to work with the new return type, and removing a test that checked if the returned value of parsedate() (a time tuple) was "acceptable" for use with functions from the time module.

----------
Added file: http://bugs.python.org/file19040/issue9864.datetime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Tue Sep 28 02:37:58 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 28 Sep 2010 00:37:58 +0000
Subject: [issue9966] platform : a boolean to know easily when a system is posix
In-Reply-To: <1285634085.25.0.52252512228.issue9966@psf.upfronthosting.co.za>
Message-ID: <1285634278.59.0.117293025077.issue9966@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

It could, but why introduce this redundancy with `os.name`?

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9966>
_______________________________________

From report at bugs.python.org  Tue Sep 28 02:45:26 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 28 Sep 2010 00:45:26 +0000
Subject: [issue9965] Loading malicious pickle may cause excessive memory usage
In-Reply-To: <1285632468.19.0.235987005106.issue9965@psf.upfronthosting.co.za>
Message-ID: <1285634726.46.0.614090089511.issue9965@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I was going to say this method http://docs.python.org/dev/py3k/library/pickle.html#restricting-globals  could be used to prevent this kind of attack on bytearray. But, I came up with this fun thing:

pickle.loads(b'\x80\x03cbuiltins\nlist\ncbuiltins\nrange\nJ\xff\xff\xff\x03\x85R\x85R.')

Sigh... you are right about pickle being insecure by design. The only solution is to use HMAC to check the integrity and the authenticity of incoming pickles.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9965>
_______________________________________

From report at bugs.python.org  Tue Sep 28 02:47:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 28 Sep 2010 00:47:07 +0000
Subject: [issue9966] platform : a boolean to know easily when a system is posix
In-Reply-To: <1285634085.25.0.52252512228.issue9966@psf.upfronthosting.co.za>
Message-ID: <1285634827.21.0.185662750199.issue9966@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I second what Jean-Paul said. os.name is well established and I don't think a second way to get the same information is needed.

Thanks for the suggestion and patch, Florent.

----------
nosy: +brian.curtin
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9966>
_______________________________________

From report at bugs.python.org  Tue Sep 28 03:57:46 2010
From: report at bugs.python.org (Tokio Kikuchi)
Date: Tue, 28 Sep 2010 01:57:46 +0000
Subject: [issue9967] encoded_word regular expression in
	email.header.decode_header()
In-Reply-To: <1285639066.52.0.877288279278.issue9967@psf.upfronthosting.co.za>
Message-ID: <1285639066.52.0.877288279278.issue9967@psf.upfronthosting.co.za>


New submission from Tokio Kikuchi <tkikuchi at users.sourceforge.net>:

Regular expression ecre for RFC2047 encoded_word in email.header module have bugs:

1. encoded_word should be separated by SPACEs in both leading and trailing ends.  Current expression take care only trailing end.

2. encoded_text in the third part of encoded_word should not include literal ? or SPACE.

Also, ecre should not match against multiline.

The patch includes two test cases for test/test_email.py

----------
components: Library (Lib)
files: email_header_ecrefix.patch
keywords: patch
messages: 117500
nosy: tkikuchi
priority: normal
severity: normal
status: open
title: encoded_word regular expression in email.header.decode_header()
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file19041/email_header_ecrefix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9967>
_______________________________________

From report at bugs.python.org  Tue Sep 28 04:07:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 02:07:04 +0000
Subject: [issue9929] subprocess.Popen unbuffered not work
In-Reply-To: <1285613944.92.0.0747627770598.issue9929@psf.upfronthosting.co.za>
Message-ID: <1285639618.3174.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > But if line buffering doesn't work, disabling buffering on 
> > stdout/stderr does have a functional consequence: it allows process 
> > output to appear as generated instead of coming in chunks when the
> > buffer is full
> 
> Yes, sorry, I had it backwards. It's buffering on stdin which doesn't
> make any functional difference (whether it's buffered or not, you
> always get data as soon as it arrives).

Actually, I had it right (you confused me :-)). In the context of
subprocess, you write to the child's stdin pipe, and you read from the
child's stdout and stderr pipes. So, whether or not you buffer the reads
from stdout and stderr pipes doesn't make a difference (except in
performance): as soon as the child outputs a single byte, it becomes
available for the parent. But if you buffer the writes to stdin, the
child process will see data arrive only when the buffer is flushed.

Here is the relevant code in subprocess.py:

        if p2cwrite != -1:
            self.stdin = io.open(p2cwrite, 'wb', bufsize)
            if self.universal_newlines:
                self.stdin = io.TextIOWrapper(self.stdin)
        if c2pread != -1:
            self.stdout = io.open(c2pread, 'rb', bufsize)
            if universal_newlines:
                self.stdout = io.TextIOWrapper(self.stdout)
        if errread != -1:
            self.stderr = io.open(errread, 'rb', bufsize)
            if universal_newlines:
                self.stderr = io.TextIOWrapper(self.stderr)

Only stdin is opened in write mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9929>
_______________________________________

From report at bugs.python.org  Tue Sep 28 04:16:57 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 28 Sep 2010 02:16:57 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1285640217.93.0.906739855422.issue5753@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/issue5753>
_______________________________________

From report at bugs.python.org  Tue Sep 28 05:11:44 2010
From: report at bugs.python.org (Lenard Lindstrom)
Date: Tue, 28 Sep 2010 03:11:44 +0000
Subject: [issue9602] PyObject_AsCharBuffer() should only accept read-only
	objects
In-Reply-To: <1281793352.06.0.62940034279.issue9602@psf.upfronthosting.co.za>
Message-ID: <1285643504.27.0.37437105195.issue9602@psf.upfronthosting.co.za>


Lenard Lindstrom <len-l at telus.net> added the comment:

PEP 3118

"""
Rationale

...

3) There is no way for a consumer to tell the buffer-API-exporting object it is "finished" with its view of the memory and therefore no way for the exporting object to be sure that it is safe to reallocate the pointer to the memory that it owns (for example, the array object reallocating its memory after sharing it with the buffer object which held the original pointer led to the infamous buffer-object problem).
"""


Let's consider Pygame, and the SDL surface it wraps as a pygame.Surface. Pygame exposes a surface's data through the buffer protocol for manipulation by a NumPy array. Now some SDL surfaces need locking before accessing, so Pygame will lock the surface for the lifetime of the consumer array. How is the surface unlocked when the array is reclaimed? By a buffer proxy that is owned by the array. The proxy unlocks the surface when the proxy is garbage collected. The new buffer protocol suggests a simpler way, equivalent to contexts, but only if the buffer release mechanism works as advertised. This promise is broken when a consumer calls PyBuffer_Release before it is done with the buffer.

All the questionable buffer api functions use the PyBUF_SIMPLE access flag. So I suggest a PyBUF_SIMPLE access request requires a returned buffer to remain valid for the lifetime of the exporter, not the Py_buffer view. If an exporter cannot honor this request, due to locking requirements for instance, then it raises an exception. All other access request flags promise that PyBuffer_Release, and therefore bf_releasebuffer, is called only when the buffer is released, not before.

----------
nosy: +kermode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9602>
_______________________________________

From report at bugs.python.org  Tue Sep 28 05:16:45 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 28 Sep 2010 03:16:45 +0000
Subject: [issue9675] segfault: PyDict_SetItem: Assertion `value' failed.
In-Reply-To: <1282683108.48.0.667769171779.issue9675@psf.upfronthosting.co.za>
Message-ID: <1285643805.59.0.0807658457363.issue9675@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

In the spirit of moving this forward:
http://mail.python.org/pipermail/python-dev/2010-September/104201.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9675>
_______________________________________

From report at bugs.python.org  Tue Sep 28 05:25:17 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 28 Sep 2010 03:25:17 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1285644317.14.0.178366297729.issue5753@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

This issue is equivalent to MS Windows DLL hijacking (the MS situation is worse, because the DDL can be in network shares or, even , in remote webdav servers):

http://blog.metasploit.com/2010/08/exploiting-dll-hijacking-flaws.html
http://news.cnet.com/8301-27080_3-20014625-245.html

When I learned about this attack, my first thought was "what if sys.path.index('')>=0?". Arg!.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Tue Sep 28 07:59:13 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 28 Sep 2010 05:59:13 +0000
Subject: [issue9950] socket.sendall() crash when receiving a signal
In-Reply-To: <1285612419.39.0.757906131991.issue9950@psf.upfronthosting.co.za>
Message-ID: <AANLkTimeKdc4HFSLOE0tP-zRatLbuVofsq=Q1COEKZen@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

thanks Antoine!

----------
Added file: http://bugs.python.org/file19042/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9950>
_______________________________________
-------------- next part --------------
thanks Antoine!

From report at bugs.python.org  Tue Sep 28 09:13:19 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 28 Sep 2010 07:13:19 +0000
Subject: [issue9441] increase logging handlers test coverage
In-Reply-To: <1280597180.41.0.450800729974.issue9441@psf.upfronthosting.co.za>
Message-ID: <1285657999.57.0.514293553651.issue9441@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

You're right about there not being tests, but if there had been, they would be using the PyWin32 libraries as well and so would need to be reimplemented (if the purpose is to remove the dependency).

Perhaps ctypes would be an alternative implementation approach. Certainly the code has hardly been touched since the initial release, and I would guess that it gets used a fair amount.

I'm not sure to what extent the external dependency is a practical problem: I would guess a large number of Windows users would be using the ActiveState distribution, which includes this dependency.

Of course I'm not saying any of this as an excuse for not having tests :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9441>
_______________________________________

From report at bugs.python.org  Tue Sep 28 09:22:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Sep 2010 07:22:46 +0000
Subject: [issue9959] int(math.log(4,2)) == 1 instead of 2
In-Reply-To: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>
Message-ID: <1285658566.27.0.726043836426.issue9959@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've tweaked the loghelper algorithm in r85048.

Looking at [n for n in range(100) if log(2**n) != n], I get:

Python 3.1:  14 bad values out of 1st 100;  first is 29
Python 3.2 (patched): 10 bad values;  first is 29
Python 3.2 (unpatched): 25 bad values; first is 2.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9959>
_______________________________________

From report at bugs.python.org  Tue Sep 28 09:23:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Sep 2010 07:23:41 +0000
Subject: [issue9959] int(math.log(4,2)) == 1 instead of 2
In-Reply-To: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>
Message-ID: <1285658621.86.0.84935307392.issue9959@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> [n for n in range(100) if log(2**n) != n]

Should be:

[n for n in range(100) if log(2**n, 2) != n]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9959>
_______________________________________

From report at bugs.python.org  Tue Sep 28 09:43:00 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Sep 2010 07:43:00 +0000
Subject: [issue9967] encoded_word regular expression in
	email.header.decode_header()
In-Reply-To: <1285639066.52.0.877288279278.issue9967@psf.upfronthosting.co.za>
Message-ID: <1285659780.51.0.757816510272.issue9967@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +barry, r.david.murray
stage:  -> patch review
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9967>
_______________________________________

From report at bugs.python.org  Tue Sep 28 09:44:59 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 Sep 2010 07:44:59 +0000
Subject: [issue9950] socket.sendall() crash when receiving a signal
In-Reply-To: <1285441668.88.0.256888401487.issue9950@psf.upfronthosting.co.za>
Message-ID: <1285659899.73.0.752324845963.issue9950@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file19042/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9950>
_______________________________________

From report at bugs.python.org  Tue Sep 28 10:18:28 2010
From: report at bugs.python.org (Bill Hawkes)
Date: Tue, 28 Sep 2010 08:18:28 +0000
Subject: [issue9961] Identity Crisis! variable assignment using strftime fails
	comparison test.
In-Reply-To: <1285601423.86.0.66942906829.issue9961@psf.upfronthosting.co.za>
Message-ID: <1285661908.73.0.420298363998.issue9961@psf.upfronthosting.co.za>


Bill Hawkes <williamhawkesjr at yahoo.com> added the comment:

Yes, it is working now. Thanks for the timely response.

In looking at the tutorial, the only "strings" used with boolean operators ("<" | ">" | "==" | ">=" | "<=" | "!=") were strings of the numeric variety. I saw no examples using words. I know the datetime module has a function for enumerating the days of the week, but it starts with Monday and ends with Sunday. I needed to start with Sunday and end with Saturday. The first thing I found for checking letter-filled strings was the "is" operator.

Perhaps a brief example of word comparisons in the tutorial would be useful. I know it would have helped me.

I can't say I have a clear understanding of the difference between the "is" and "==" operators, but I can accept that there apparently is some difference and there are situations where that difference matters. Again, thanks for the quick response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9961>
_______________________________________

From report at bugs.python.org  Tue Sep 28 12:36:17 2010
From: report at bugs.python.org (Mark Wielaard)
Date: Tue, 28 Sep 2010 10:36:17 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1285670177.87.0.483259829086.issue4111@psf.upfronthosting.co.za>


Mark Wielaard <mjw at redhat.com> added the comment:

>  - renamed the probepoints:
>      "function__entry" -> "frame__entry"
>      "function__return" -> "frame__exit"
>    as I believe this better describes what these do    

Are you sure you want to do this? You are right that it better describes the action that these probe points signify. But since previous versions of this patch have been used and applied people might be depending on the old names. It is not a very big issue, we can always write a tapset to translate the old to new names. But it is an interface break for anybody who might already have scripts around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Sep 28 13:49:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 11:49:16 +0000
Subject: [issue9602] PyObject_AsCharBuffer() should only accept read-only
	objects
In-Reply-To: <1285643504.27.0.37437105195.issue9602@psf.upfronthosting.co.za>
Message-ID: <1285674542.3141.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mardi 28 septembre 2010 ? 03:11 +0000, Lenard Lindstrom a ?crit :
> 
> Let's consider Pygame, and the SDL surface it wraps as a
> pygame.Surface. Pygame exposes a surface's data through the buffer
> protocol for manipulation by a NumPy array. Now some SDL surfaces need
> locking before accessing, so Pygame will lock the surface for the
> lifetime of the consumer array. How is the surface unlocked when the
> array is reclaimed? By a buffer proxy that is owned by the array. The
> proxy unlocks the surface when the proxy is garbage collected. The new
> buffer protocol suggests a simpler way, equivalent to contexts, but
> only if the buffer release mechanism works as advertised. This promise
> is broken when a consumer calls PyBuffer_Release before it is done
> with the buffer.

I don't know why you're saying that. The purpose of PyBuffer_Release is
precisely to solve these kinds of use cases (where you want timely
release of a resource rather than rely on the garbage collector).

(you shouldn't even need a proxy anymore; just make the surface object
expose the buffer API, with bf_getbuffer() acquiring the lock and
bf_releasebuffer() releasing the lock. If you want to support several
buffer exports at once, just maintain some internal count of them)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9602>
_______________________________________

From report at bugs.python.org  Tue Sep 28 13:58:16 2010
From: report at bugs.python.org (phep)
Date: Tue, 28 Sep 2010 11:58:16 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>


New submission from phep <patrice.pillot at teletopie.net>:

Hi,

Presently, in cgi.FieldStorage, uploaded file are accessible through a file-like object created by a call to tempfile.TemporaryFile(), probably in order to ensure the file is deleted when the process terminates.

The problem is that when one wants to save the data to some permanent location, one does not have other choice thant read() from this file descriptor then write() to the desired place, which means the file data shall be duplicated. This is greatly undesirable when the uploaded file is huge.

Replacing the call to tempfile.TemporaryFile() by a call to tempfile.NamedTemporaryFile() (available from 2.3) would have the following advantages :
1) no impact on existing code,
2) saving a file would be as simple as invoking os.link(fieldstorage['filenamefield'].file.name, "/some/path")
3) There would be no need to duplicate data anymore.

The sole real inconvenience of this change would be to update the documentation accordingly.

tia,

phep

----------
components: Extension Modules
messages: 117512
nosy: phep
priority: normal
severity: normal
status: open
title: Let cgi.FieldStorage have named uploaded file
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Tue Sep 28 14:15:33 2010
From: report at bugs.python.org (phep)
Date: Tue, 28 Sep 2010 12:15:33 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1285676133.28.0.322940775402.issue9968@psf.upfronthosting.co.za>


phep <patrice.pillot at teletopie.net> added the comment:

Oops. I forgot to aknowledge the fact that presently cgi.FieldStorage class documentation (but not the cgi module documentation) tells about the possibility to override the make_file() method in a user subclass to change the present limitation (which is actually how I work around the problem presently).

Yet, this does not (IMHO) render this feature request invalid.

phep

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Tue Sep 28 14:28:02 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Tue, 28 Sep 2010 12:28:02 +0000
Subject: [issue8098] PyImport_ImportModuleNoBlock() may solve problems but
	causes others.
In-Reply-To: <1268131645.26.0.730387379265.issue8098@psf.upfronthosting.co.za>
Message-ID: <1285676882.11.0.935707591442.issue8098@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


----------
nosy: +ruseel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8098>
_______________________________________

From report at bugs.python.org  Tue Sep 28 14:33:16 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 28 Sep 2010 12:33:16 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1285677196.45.0.520086627756.issue4111@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I don't understand the last request. Is there already a practice to depend on patches that were applied by people, but were not released, reviewed or documented in some PEP?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Sep 28 14:33:20 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Tue, 28 Sep 2010 12:33:20 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1285677200.17.0.357745582894.issue7980@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


----------
nosy: +ruseel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Tue Sep 28 15:14:46 2010
From: report at bugs.python.org (Mark Wielaard)
Date: Tue, 28 Sep 2010 13:14:46 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1285679686.7.0.877476803783.issue4111@psf.upfronthosting.co.za>


Mark Wielaard <mjw at redhat.com> added the comment:

The original patch was created to be as close as possible to the support that Sun and Apple added to their python implementation for Solaris and MacOS. Changing the probe point names would make the current patch slightly different for scripts written against those. That isn't a major problem, and can be worked around in user scripts or a tapset that translates the old names to new names. But it is something to consider before changing the probe names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Sep 28 15:17:19 2010
From: report at bugs.python.org (Meador Inge)
Date: Tue, 28 Sep 2010 13:17:19 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

Currently with 'py3k' only 'bytes' objects are accepted for tokenization:

>>> import io
>>> import tokenize
>>> tokenize.tokenize(io.StringIO("1+1").readline)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/minge/Code/python/py3k/Lib/tokenize.py", line 360, in tokenize
    encoding, consumed = detect_encoding(readline)
  File "/Users/minge/Code/python/py3k/Lib/tokenize.py", line 316, in detect_encoding
    if first.startswith(BOM_UTF8):
TypeError: Can't convert 'bytes' object to str implicitly
>>> tokenize.tokenize(io.BytesIO(b"1+1").readline)
<generator object _tokenize at 0x1007566e0>

In a discussion on python-dev (http://www.mail-archive.com/python-dev at python.org/msg52107.html) it was generally considered to be a good idea to add support for tokenizing 'str' objects as well.

----------
messages: 117516
nosy: meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: tokenize: add support for tokenizing 'str' objects
type: feature request
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9969>
_______________________________________

From report at bugs.python.org  Tue Sep 28 15:18:28 2010
From: report at bugs.python.org (Meador Inge)
Date: Tue, 28 Sep 2010 13:18:28 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1285679908.25.0.50670111533.issue9969@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9969>
_______________________________________

From report at bugs.python.org  Tue Sep 28 15:21:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 13:21:30 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1285680090.37.0.618102067288.issue9935@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

My patch breaks pickling of transparent proxies such as weakref.proxy().
(since these have a different __class__ than Py_TYPE(self), through tp_getattr hackery). I will need to remove a couple of optimizations.

(unfortunately, there don't seem to be any tests for such case; my initial patch breaks neither test_pickle nor test_pickletools)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9935>
_______________________________________

From report at bugs.python.org  Tue Sep 28 15:22:00 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Sep 2010 13:22:00 +0000
Subject: [issue9970] PyMemoryView_FromBuffer is not documented
In-Reply-To: <1285680120.22.0.180975662294.issue9970@psf.upfronthosting.co.za>
Message-ID: <1285680120.22.0.180975662294.issue9970@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

PyMemoryView_FromBuffer() in Include/memoryobject.h is undocumented.

The function name seems to indicate that it intended to be a public API.

----------
assignee: docs at python
components: Documentation
messages: 117518
nosy: docs at python, ronaldoussoren
priority: normal
severity: normal
status: open
title: PyMemoryView_FromBuffer is not documented
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9970>
_______________________________________

From report at bugs.python.org  Tue Sep 28 15:34:51 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 28 Sep 2010 13:34:51 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1285680891.63.0.672404283761.issue9969@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9969>
_______________________________________

From report at bugs.python.org  Tue Sep 28 15:57:31 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 28 Sep 2010 13:57:31 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1285682251.83.0.713480619819.issue4111@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

So, it was released. But why they didn't send their patches here? We could review them, or we want Sun and Apple create Python specifications unilaterally? It would be best to contact them and notify about the change. Is it something a PSF should do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Sep 28 16:00:59 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Sep 2010 14:00:59 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285682459.92.0.904226596529.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Attached patch is a very rough first cut at this. I've gone with the basic approach of simply assigning the literals to local variables in each function that uses them. My rationale for that is:
1. Every function has to have some kind of boilerplate to switch based on the type of the argument
2. Some functions need to switch other values (such as the list of scheme_chars or the unparse function), so a separate object with literal attributes won't be enough
3. Given 1 and 2, the overhead of a separate namespace for the literal references isn't justified

I've also gone with a philosophy that only str objects are treated as strings and everything else is implicitly assumed to be bytes. This is in keeping with the general interpreter behaviour where we *really* don't support duck-typing when it comes to strings.

The test updates aren't comprehensive yet, but they were enough to uncover quite a few things I had missed.

quoting is still a bit ugly, so I may still add a byte->bytes/str->str variant of those APIs.

----------
keywords: +patch
Added file: http://bugs.python.org/file19043/issue9873_initial_attempt.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Tue Sep 28 16:01:11 2010
From: report at bugs.python.org (John Levon)
Date: Tue, 28 Sep 2010 14:01:11 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1285682471.98.0.0247987586667.issue4111@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

Anatoly, see above. We have done exactly that. (Honestly, when I first wrote the changes, I saw them as too hacky to ever be accepted upstream).

This name change seems frivolous and will indeed break existing scripts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Sep 28 16:04:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 14:04:33 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1285682673.5.0.653525811444.issue9935@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Corrected patch, including new tests for pickling of weak proxies.

----------
Added file: http://bugs.python.org/file19044/pickleinst2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9935>
_______________________________________

From report at bugs.python.org  Tue Sep 28 16:04:59 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 28 Sep 2010 14:04:59 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1285682699.31.0.82798494256.issue9969@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Note from Nick Coghlan from the Python-dev discussion:

A very quick scan of _tokenize suggests it is designed to support
detect_encoding returning None to indicate the line iterator will
return already decoded lines. This is confirmed by the fact the
standard library uses it that way (via generate_tokens).

An API that accepts a string, wraps a StringIO around it, then calls
_tokenise with an encoding of None would appear to be the answer here.
A feature request on the tracker is the best way to make that happen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9969>
_______________________________________

From report at bugs.python.org  Tue Sep 28 16:05:09 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Sep 2010 14:05:09 +0000
Subject: [issue9701] Update ZSH profile on Mac OS installation
In-Reply-To: <1282914673.78.0.162248680277.issue9701@psf.upfronthosting.co.za>
Message-ID: <1285682709.88.0.0693457295173.issue9701@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed in r85059 (3.2), r85060 (2.7), r85061 (3.1)

Thanks again.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9701>
_______________________________________

From report at bugs.python.org  Tue Sep 28 16:32:30 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Sep 2010 14:32:30 +0000
Subject: [issue9594] typo on Mac/Makefile.in? s/pythonw/python/
In-Reply-To: <1281735276.23.0.449873150799.issue9594@psf.upfronthosting.co.za>
Message-ID: <1285684350.69.0.743779201471.issue9594@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

There is no typo. The python and pythonw executables are the same and are build as 'pythonw' and installed with the right name.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9594>
_______________________________________

From report at bugs.python.org  Tue Sep 28 16:44:15 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Sep 2010 14:44:15 +0000
Subject: [issue9568] test_urllib2_localnet fails on OS X 10.3
In-Reply-To: <1281514296.56.0.121028925935.issue9568@psf.upfronthosting.co.za>
Message-ID: <1285685055.22.0.776647443263.issue9568@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Applied the patch in r85062 (3.2), r85063 (3.1), r85064 (2.7)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9568>
_______________________________________

From report at bugs.python.org  Tue Sep 28 16:50:26 2010
From: report at bugs.python.org (Ben Bass)
Date: Tue, 28 Sep 2010 14:50:26 +0000
Subject: [issue5131] pprint doesn't know how to print a defaultdict
In-Reply-To: <1233592442.21.0.0563262599933.issue5131@psf.upfronthosting.co.za>
Message-ID: <1285685426.74.0.126428719443.issue5131@psf.upfronthosting.co.za>


Ben Bass <benpaulbass at googlemail.com> added the comment:

Same applies to collections.deque, which seems closely related (being another collections class).  Can this get addressed here or should I open another issue?

(just been pprinting defaultdict(deque) objects, which clearly fails :)

----------
nosy: +bpb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5131>
_______________________________________

From report at bugs.python.org  Tue Sep 28 17:12:27 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 28 Sep 2010 15:12:27 +0000
Subject: [issue9948] findCaller is slow and loses case information on Windows
In-Reply-To: <1285425150.17.0.662006958911.issue9948@psf.upfronthosting.co.za>
Message-ID: <1285686747.01.0.381643069908.issue9948@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I made a temporary change to logging to time the two different approaches: see this gist:

http://gist.github.com/601162

According to these findings, the use of module globals seems to make only a marginal difference:

vinay at eta-jaunty:~/projects/scratch$ python3.2 timefc.py
filename_comparison 50.61 microseconds
module_globals 49.56 microseconds
vinay at eta-jaunty:~/projects/scratch$ python2.7 timefc.py
filename_comparison 50.79 microseconds
module_globals 50.01 microseconds

Have I missed something obvious?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9948>
_______________________________________

From report at bugs.python.org  Tue Sep 28 17:15:15 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Sep 2010 15:15:15 +0000
Subject: [issue9907] interactive mode TAB does not insert on OS X built with
	editline instead of GNU readline
In-Reply-To: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>
Message-ID: <1285686915.65.0.305046760281.issue9907@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On second thought, the patch isn't quite as harmless as I first thought: the default key-bindings that are created after the call to rl_initialize will replace custom bindings in the users .editrc file.

I've attached a new version of the py3k patch that works around this problem by calling rl_read_init_file(NULL) after setting the default bindings.

This allows me to override the bindings for TAB in ~/.editrc as before.

----------
Added file: http://bugs.python.org/file19045/issue9907-py3k-ronald.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9907>
_______________________________________

From report at bugs.python.org  Tue Sep 28 17:19:02 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 28 Sep 2010 15:19:02 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The readinto() method is intended to offer better performance than read() by allowing the caller to read into a preallocated buffer rather than constantly allocate and deallocate buffers.

However, bufferediobase_readinto() calls read(), so the extra allocations and deallocations happen anyway.  On a related note, buffered_readinto() has a comment reading "TODO: use raw.readinto() instead!" which should be explored.

I can write a patch for this, but it will probably be awhile before I get to it.  Anyone else who feels inspired should feel free to write one. :-)

----------
assignee: stutzbach
components: IO
messages: 117530
nosy: benjamin.peterson, pitrou, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Optimize BufferedReader.readinto
type: performance
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Tue Sep 28 17:22:20 2010
From: report at bugs.python.org (Lisandro Dalcin)
Date: Tue, 28 Sep 2010 15:22:20 +0000
Subject: [issue9972] PyGILState_XXX missing in Python builds without threads
In-Reply-To: <1285687340.14.0.296693885275.issue9972@psf.upfronthosting.co.za>
Message-ID: <1285687340.14.0.296693885275.issue9972@psf.upfronthosting.co.za>


New submission from Lisandro Dalcin <dalcinl at gmail.com>:

I've built Python-2.6.5 form with this :

$ ./configure --without-threads --prefix=$HOME/python-without-threads
$ make && make install

$ cd ~/python-without-threads/lib
$ nm libpython2.6.so | grep PyGILState
$ 

At Include/pystate.h,  PyGILState_{Ensure|Release} are not protected with #ifdef WITH_THREADS

At Python/pystate.c PyGILState_{Ensure|Release} are implemented in a block protected with #ifdef WITH_THREADS

AFAIK, this happens in all Python versions back to 2.3 and up to 3.2

----------
messages: 117531
nosy: dalcinl
priority: normal
severity: normal
status: open
title: PyGILState_XXX missing in Python builds without threads
versions: Python 2.5, 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/issue9972>
_______________________________________

From report at bugs.python.org  Tue Sep 28 17:35:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 15:35:41 +0000
Subject: [issue9970] PyMemoryView_FromBuffer is not documented
In-Reply-To: <1285680120.22.0.180975662294.issue9970@psf.upfronthosting.co.za>
Message-ID: <1285688141.06.0.562141135125.issue9970@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed, thank you.

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9970>
_______________________________________

From report at bugs.python.org  Tue Sep 28 17:46:00 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 28 Sep 2010 15:46:00 +0000
Subject: [issue9675] segfault: PyDict_SetItem: Assertion `value' failed.
In-Reply-To: <1282683108.48.0.667769171779.issue9675@psf.upfronthosting.co.za>
Message-ID: <1285688760.62.0.453628994543.issue9675@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/issue9675>
_______________________________________

From report at bugs.python.org  Tue Sep 28 17:46:39 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Sep 2010 15:46:39 +0000
Subject: [issue812750] OSA support for properties broken
Message-ID: <1285688799.33.0.433136456665.issue812750@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've applied the documentation patch that Ned suggests in r

I'm furthermore closing this issue as "Won't Fix" because the OSA bindings are no longer developed and we'll therefore not implement the new feature that Jack mentions.

----------
nosy: +ronaldoussoren
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812750>
_______________________________________

From report at bugs.python.org  Tue Sep 28 17:47:42 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Sep 2010 15:47:42 +0000
Subject: [issue812750] OSA support for properties broken
Message-ID: <1285688862.09.0.73105483931.issue812750@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Sent the message too soon... the documentation update is in r85069.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812750>
_______________________________________

From report at bugs.python.org  Tue Sep 28 18:19:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 16:19:23 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1285690763.94.0.80793517364.issue9090@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch wrapping all variants of recv() and send(), except sendall() which already has its own retry loop.

----------
Added file: http://bugs.python.org/file19046/selectretry2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Tue Sep 28 18:34:20 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 28 Sep 2010 16:34:20 +0000
Subject: [issue9973] Sometimes buildbot fails to cleanup working copy
In-Reply-To: <1285691660.36.0.731785440446.issue9973@psf.upfronthosting.co.za>
Message-ID: <1285691660.36.0.731785440446.issue9973@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Sometimes, buildbot fails to clean working copy.

/////////////////////////////////////////////

(snip)
Clean started: Project: _hashlib, Configuration: Debug|Win32
Deleting intermediate and output files for project '_hashlib', configuration 'Debug|Win32'
_hashlib : error PRJ0008 : Could not delete file 'c:\buildslave\2.7.moore-windows\build\PCbuild\_hashlib_d.pyd'.
Make sure that the file is not open by another process and is not write-protected.
_hashlib - 1 error(s), 0 warning(s)

Build complete: 8 Projects succeeded, 17 Projects failed, 1 Projects skipped

/////////////////////////////////////////////

This might cause checkout error next time. Maybe attached
patch can improve this situation. Thanks.

----------
components: Tests
files: py3k_buildbot_error_in_clean_faze.patch
keywords: buildbot, patch
messages: 117536
nosy: ocean-city
priority: normal
severity: normal
status: open
title: Sometimes buildbot fails to cleanup working copy
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19047/py3k_buildbot_error_in_clean_faze.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9973>
_______________________________________

From report at bugs.python.org  Tue Sep 28 18:45:11 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 28 Sep 2010 16:45:11 +0000
Subject: [issue3674] test_dbm_ndbm skip is unexpected on win32?
In-Reply-To: <1219635810.63.0.758747925367.issue3674@psf.upfronthosting.co.za>
Message-ID: <1285692311.42.0.715376019163.issue3674@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3674>
_______________________________________

From report at bugs.python.org  Tue Sep 28 18:45:59 2010
From: report at bugs.python.org (Lenard Lindstrom)
Date: Tue, 28 Sep 2010 16:45:59 +0000
Subject: [issue9602] PyObject_AsCharBuffer() should only accept read-only
	objects
In-Reply-To: <1281793352.06.0.62940034279.issue9602@psf.upfronthosting.co.za>
Message-ID: <1285692359.13.0.278085270749.issue9602@psf.upfronthosting.co.za>


Lenard Lindstrom <len-l at telus.net> added the comment:

>I don't know why you're saying that. The purpose of PyBuffer_Release is
>precisely to solve these kinds of use cases (where you want timely
>release of a resource rather than rely on the garbage collector).

Yes, I was unclear. This refers to Python 3.2, not the 2.x series. PyObject_AsReadBuffer (defined at line 270 in abstract.c, code of routine attached) calls bf_getbuffer with the PyBUF_SIMPLE flag to retrieve a bytes buffer. It then calls bf_releasebuffer before returning the buffer to the caller. PyObject_AsCharBuffer and PyObject_AsWriteBuffer do the same. It is not be exactly the same issue discussed so far, but is closely related.

Deprecating PyObject_AsReadBuffer is extreme, and doesn't solve the early release problem. Redefining the PyBUF_SIMPLE flag to be like the old buffer protocol warns those implementing a new buffer interface to  avoid processing PyBUF_SIMPLE requests when locking is required.

----------
Added file: http://bugs.python.org/file19048/PyObject_AsReadBuffer.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9602>
_______________________________________

From report at bugs.python.org  Tue Sep 28 19:15:20 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 28 Sep 2010 17:15:20 +0000
Subject: [issue9666] 'hasattr' fix to suppress only AttributeError
In-Reply-To: <1282618571.72.0.746588634044.issue9666@psf.upfronthosting.co.za>
Message-ID: <1285694120.7.0.192531423343.issue9666@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/issue9666>
_______________________________________

From report at bugs.python.org  Tue Sep 28 19:31:06 2010
From: report at bugs.python.org (=?utf-8?q?Brian_Boss=C3=A9?=)
Date: Tue, 28 Sep 2010 17:31:06 +0000
Subject: [issue9974] tokenizer.untokenize not invariant with line continuations
In-Reply-To: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>
Message-ID: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>


New submission from Brian Boss? <penrif at gmail.com>:

Executing the following code against a py file which contains line continuations generates an assert:
import tokenize
foofile = open(filename, "r")
tokenize.untokenize(list(tokenize.generate_tokens(foofile.readline)))

(note, the list() is important due to issue #8478)

The assert triggered is:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\tokenize.py", line 262, in untokenize
    return ut.untokenize(iterable)
  File "C:\Python27\lib\tokenize.py", line 198, in untokenize
    self.add_whitespace(start)
  File "C:\Python27\lib\tokenize.py", line 187, in add_whitespace
    assert row <= self.prev_row
AssertionError

I have tested this in 2.6.5, 2.7 and 3.1.2.  The line numbers may differ but the stack is otherwise identical between these versions.

Example input code:
foo = \
   3

If the assert is removed, the code generated is still incorrect.  For example, the input:
foo = 3
if foo == 5 or \
   foo == 1
    pass

becomes:
foo = 3
if foo == 5 orfoo == 1
    pass

which besides not having the line continuation, is functionally incorrect.

I'm wrapping my head around the functionality of this module and am willing to do the legwork to get a fix in.  Ideas on how to go about it are more than welcome.

Ironic aside:  this bug is present when tokenize.py itself is used as input.

----------
components: Library (Lib)
messages: 117538
nosy: Brian.Boss?
priority: normal
severity: normal
status: open
title: tokenizer.untokenize not invariant with line continuations
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9974>
_______________________________________

From report at bugs.python.org  Tue Sep 28 20:08:50 2010
From: report at bugs.python.org (Sylvain Mora)
Date: Tue, 28 Sep 2010 18:08:50 +0000
Subject: [issue9701] Update ZSH profile on Mac OS installation
In-Reply-To: <1282914673.78.0.162248680277.issue9701@psf.upfronthosting.co.za>
Message-ID: <1285697330.87.0.826810863536.issue9701@psf.upfronthosting.co.za>


Sylvain Mora <sylvain.mora at googlemail.com> added the comment:

You're welcome, and thank you for you work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9701>
_______________________________________

From report at bugs.python.org  Tue Sep 28 20:35:46 2010
From: report at bugs.python.org (Vilmos Nebehaj)
Date: Tue, 28 Sep 2010 18:35:46 +0000
Subject: [issue9975] Incorrect use of flowinfo and scope_id in IPv6 sockaddr
	tuple
In-Reply-To: <1285698946.58.0.377750793336.issue9975@psf.upfronthosting.co.za>
Message-ID: <1285698946.58.0.377750793336.issue9975@psf.upfronthosting.co.za>


New submission from Vilmos Nebehaj <v.nebehaj at gmail.com>:

Module/socketmodule.c incorrectly treats both sockaddr_in6->sin6_flowinfo and sockaddr_in6->sin6_scope_id as signed integers.  They are 32-bit unsigned integers (even though sin6_flowinfo is just 20 bits).

sin6_flowinfo also lacks the necessary endian conversions when an IPv6 sockaddr tuple is parsed or returned.  This makes it difficult to deal with sockets using sin6_flowinfo and deviates from RFCs.  With the use of a signed int it also makes impossible to use flowinfo values that are larger than 2^31 if converted to little endian byte order (socketmodule.c raising an overflow exception).

sin6_scope_id has meaning only on the local machine (as an interface index), thus no endian conversion is needed for it.

----------
components: Library (Lib)
files: python_flowinfo.patch
keywords: patch
messages: 117540
nosy: vnebehaj
priority: normal
severity: normal
status: open
title: Incorrect use of flowinfo and scope_id in IPv6 sockaddr tuple
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19049/python_flowinfo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9975>
_______________________________________

From report at bugs.python.org  Tue Sep 28 21:47:52 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Tue, 28 Sep 2010 19:47:52 +0000
Subject: [issue6640] urlparse should parse mailto: URL headers as query
	parameters
In-Reply-To: <1249346554.96.0.279967945769.issue6640@psf.upfronthosting.co.za>
Message-ID: <1285703272.13.0.661294591161.issue6640@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

Adding the 'mailto' scheme to the urllib.parse.uses_query list changes the behavior as described in msg91249. A patch with a test is attached.

Note that this changes the behavior of urllib.parse.urlparse() on 'mailto:' URLs: with this patch, the function returns the "foo at example.com" in the "netloc" named tuple position instead of in the "path" position.

----------
keywords: +patch
nosy: +jfinkels
Added file: http://bugs.python.org/file19050/issue6640.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6640>
_______________________________________

From report at bugs.python.org  Tue Sep 28 22:05:22 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Tue, 28 Sep 2010 20:05:22 +0000
Subject: [issue2972] arguments and default path not set in site.py and
	sitecustomize.py
In-Reply-To: <1211818636.32.0.584139114136.issue2972@psf.upfronthosting.co.za>
Message-ID: <1285704322.17.0.13380436811.issue2972@psf.upfronthosting.co.za>


Matthew Woodcraft <matthew at woodcraft.me.uk> added the comment:

open("/proc/self/cmdline").read() should work on linux (note that the arguments are separated by NULs).

----------
nosy: +mattheww

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2972>
_______________________________________

From report at bugs.python.org  Tue Sep 28 22:14:44 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Tue, 28 Sep 2010 20:14:44 +0000
Subject: [issue9976] Make TestCase._formatMessage public
In-Reply-To: <1285704884.2.0.185747132173.issue9976@psf.upfronthosting.co.za>
Message-ID: <1285704884.2.0.185747132173.issue9976@psf.upfronthosting.co.za>


New submission from Matthew Woodcraft <matthew at woodcraft.me.uk>:

It would be pleasant if TestCase._formatMessage, or something similar,
could be made part of the documented API; I think pretty much anyone
writing a custom TypeEqualityFunc is going to end up reimplementing it.

(This is the code that makes the TestCase.longMessage attribute take
effect.)

----------
messages: 117543
nosy: mattheww, michael.foord
priority: normal
severity: normal
status: open
title: Make TestCase._formatMessage public
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9976>
_______________________________________

From report at bugs.python.org  Tue Sep 28 22:14:52 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 28 Sep 2010 20:14:52 +0000
Subject: [issue1665333] Documentation missing for OptionGroup class in optparse
Message-ID: <1285704892.65.0.984792809574.issue1665333@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
attached is a patch to improve the OptionGroup documentation. I've also changed usage->Usage and options->Options in the examples output, since now the code tries to guess the lower case word and rewrites with the capitalized one.

I'm willing to improve the patch in case there's something not good (and I bet there is, since it's my first complex patch for Python documentation) so please be nice :) and point me to parts that can be improved.

Thanks in advance,
Sandro

----------
keywords: +patch
Added file: http://bugs.python.org/file19051/issue1665333-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1665333>
_______________________________________

From report at bugs.python.org  Tue Sep 28 22:15:22 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Tue, 28 Sep 2010 20:15:22 +0000
Subject: [issue9977] TestCase.assertItemsEqual's description of differences
In-Reply-To: <1285704922.32.0.659854668668.issue9977@psf.upfronthosting.co.za>
Message-ID: <1285704922.32.0.659854668668.issue9977@psf.upfronthosting.co.za>


New submission from Matthew Woodcraft <matthew at woodcraft.me.uk>:

TestCase.assertItemsEqual uses two different techniques to describe the
differences in the inputs that it compares.

If the inputs are sortable, it sorts them and then uses
assertSequenceEqual to describe the difference between them considered
as ordered sequences.

Otherwise, it uses unittest.util.unorderable_list_difference, which
is essentially a multiset comparison.

In practice, I think the output from unorderable_list_difference is
usually more readable, so I wonder if something of that kind should be
made the default.


Example:

a = [('b', (2, 3)), ('w', (3, 4))]
b = [('x', (2, 3)), ('w', (3, 4))]
case.assertItemsEqual(a, b)


unorderable_list_difference gives

Expected, but missing:
    [('b', (2, 3))]
Unexpected, but present:
    [('x', (2, 3))]


while the current assertItemsEqual gives

Sequences differ: [('b', (2, 3)), ('w', (3, 4))] != [('w', (3, 4)), ('x', (2, 3))]

First differing element 0:
('b', (2, 3))
('w', (3, 4))

- [('b', (2, 3)), ('w', (3, 4))]
+ [('w', (3, 4)), ('x', (2, 3))]


In general, I think that the 'first differing element' paragraph that
assertSequenceEqual produces is as likely to be misleading as it is to
be helpful (when we're really comparing unordered sequences).

----------
messages: 117545
nosy: mattheww, michael.foord
priority: normal
severity: normal
status: open
title: TestCase.assertItemsEqual's description of differences
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9977>
_______________________________________

From report at bugs.python.org  Tue Sep 28 22:24:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 20:24:56 +0000
Subject: [issue9602] PyObject_AsCharBuffer() should only accept read-only
	objects
In-Reply-To: <1285692359.13.0.278085270749.issue9602@psf.upfronthosting.co.za>
Message-ID: <1285705490.3183.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, I was unclear. This refers to Python 3.2, not the 2.x series.
> PyObject_AsReadBuffer (defined at line 270 in abstract.c, code of
> routine attached) calls bf_getbuffer with the PyBUF_SIMPLE flag to
> retrieve a bytes buffer. It then calls bf_releasebuffer before
> returning the buffer to the caller. PyObject_AsCharBuffer and
> PyObject_AsWriteBuffer do the same. It is not be exactly the same
> issue discussed so far, but is closely related.
> 
> Deprecating PyObject_AsReadBuffer is extreme,

I disagree. PyObject_As*Buffer functions are remnants of the old buffer
API in Python 2.x. They are here only to ease porting of existing C
code, but carefully written 3.x code should switch to
PyObject_GetBuffer() (or one of the dedicated typecodes in
PyArg_ParseTuple: "y*", "w*", etc.).

> Redefining the PyBUF_SIMPLE flag to be like the old buffer protocol
> warns those implementing a new buffer interface to  avoid processing
> PyBUF_SIMPLE requests when locking is required.

Well, the new buffer API was designed precisely because the old API
wasn't appropriate, so your proposal to revive the old API doesn't sound
very compelling, to say the least.

To restate things a bit more clearly: you should use
PyObject_GetBuffer(), not any of the PyObject_As*Buffer functions.
Perhaps you should explain why you care about the latter rather than the
former.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9602>
_______________________________________

From report at bugs.python.org  Tue Sep 28 22:34:02 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 28 Sep 2010 20:34:02 +0000
Subject: [issue1665333] Documentation missing for OptionGroup class in optparse
Message-ID: <1285706042.4.0.60377975326.issue1665333@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

sorry, I forgot to wrap at column 80, this patch just changes that.

----------
Added file: http://bugs.python.org/file19052/issue1665333-py3k-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1665333>
_______________________________________

From report at bugs.python.org  Tue Sep 28 23:09:58 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 28 Sep 2010 21:09:58 +0000
Subject: [issue3612] Add some missing basic types in ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1285708198.65.0.886088496754.issue3612@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry for too late. I've committed in r85073(py3k).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________

From report at bugs.python.org  Tue Sep 28 23:10:59 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 28 Sep 2010 21:10:59 +0000
Subject: [issue3612] Add some missing basic types in ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1285708259.19.0.672528914824.issue3612@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________

From report at bugs.python.org  Tue Sep 28 23:24:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 21:24:14 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1285709054.75.0.0461827886458.issue9090@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in 3.2 in r85074. I don't plan to backport it, since the _PyTime_gettimeofday abstraction is not available on earlier versions.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Tue Sep 28 23:31:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Sep 2010 21:31:17 +0000
Subject: [issue9602] PyObject_AsCharBuffer() should only accept read-only
	objects
In-Reply-To: <1285705490.3183.1.camel@localhost.localdomain>
Message-ID: <201009282331.08392.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mardi 28 septembre 2010 22:24:56, vous avez ?crit :
> I disagree. PyObject_As*Buffer functions are remnants of the old buffer
> API in Python 2.x. They are here only to ease porting of existing C
> code, but carefully written 3.x code should switch to
> PyObject_GetBuffer() (or one of the dedicated typecodes in
> PyArg_ParseTuple: "y*", "w*", etc.).

Do you mean that PyObject_As*Buffer functions are deprecated? The documentation 
doesn't tell that the new buffer API should be use instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9602>
_______________________________________

From report at bugs.python.org  Tue Sep 28 23:35:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 21:35:02 +0000
Subject: [issue9602] PyObject_AsCharBuffer() should only accept read-only
	objects
In-Reply-To: <201009282331.08392.victor.stinner@haypocalc.com>
Message-ID: <1285709697.3183.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Le mardi 28 septembre 2010 22:24:56, vous avez ?crit :
> > I disagree. PyObject_As*Buffer functions are remnants of the old buffer
> > API in Python 2.x. They are here only to ease porting of existing C
> > code, but carefully written 3.x code should switch to
> > PyObject_GetBuffer() (or one of the dedicated typecodes in
> > PyArg_ParseTuple: "y*", "w*", etc.).
> 
> Do you mean that PyObject_As*Buffer functions are deprecated? The documentation 
> doesn't tell that the new buffer API should be use instead.

Well, the documentation should be updated then. Given that the old
buffer API doesn't exist anymore, the old functions don't have any
practical purpose except for ease of porting code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9602>
_______________________________________

From report at bugs.python.org  Tue Sep 28 23:35:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 21:35:11 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285709711.65.0.548158316155.issue9962@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Same patch with tests.

----------
Added file: http://bugs.python.org/file19053/gzippeek2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9962>
_______________________________________

From report at bugs.python.org  Tue Sep 28 23:36:24 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 28 Sep 2010 21:36:24 +0000
Subject: [issue9518] PyModuleDef_HEAD_INIT does not explicitly initialize all
	fields of m_base
In-Reply-To: <1280965412.21.0.0751804906986.issue9518@psf.upfronthosting.co.za>
Message-ID: <1285709784.99.0.432757118966.issue9518@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

the patch looks OK, but out of curiosity: do you really declare all the fields of a PyTypeObject?
This structure is really designed so that newer members are left at the end; most types don't need to initialize them, C standard ensures that they will be zero.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9518>
_______________________________________

From report at bugs.python.org  Tue Sep 28 23:54:18 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Sep 2010 21:54:18 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1285710858.05.0.587248130168.issue9969@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Possible approach (untested):

def get_tokens(source):
    if hasattr(source, "encode"):
        # Already decoded, so bypass encoding detection
        return _tokenize(io.StringIO(source).readline, None)
    # Otherwise attempt to detect the correct encoding
    return tokenize(io.BytesIO(source).readline)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9969>
_______________________________________

From report at bugs.python.org  Tue Sep 28 23:56:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Sep 2010 21:56:28 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1285710988.4.0.344438712659.issue9864@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks, Jeffrey.  I've applied your patch (with minor doc tweaks) to the email6 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Tue Sep 28 23:56:32 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Sep 2010 21:56:32 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285710992.63.0.754231987344.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A possible duck-typing approach here would be to replace the "instance(x, str)" tests with "hasattr(x, 'encode')" checks instead.

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Tue Sep 28 23:59:17 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 28 Sep 2010 21:59:17 +0000
Subject: [issue9977] TestCase.assertItemsEqual's description of differences
In-Reply-To: <1285704922.32.0.659854668668.issue9977@psf.upfronthosting.co.za>
Message-ID: <1285711157.73.0.850603067029.issue9977@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee:  -> michael.foord
components: +Library (Lib)
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9977>
_______________________________________

From report at bugs.python.org  Wed Sep 29 00:00:40 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 28 Sep 2010 22:00:40 +0000
Subject: [issue9976] Make TestCase._formatMessage public
In-Reply-To: <1285704884.2.0.185747132173.issue9976@psf.upfronthosting.co.za>
Message-ID: <1285711240.83.0.507298607304.issue9976@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee:  -> michael.foord
components: +Library (Lib)
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9976>
_______________________________________

From report at bugs.python.org  Wed Sep 29 00:04:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 22:04:01 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285711441.99.0.542431100511.issue9962@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/issue9962>
_______________________________________

From report at bugs.python.org  Wed Sep 29 00:05:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Sep 2010 22:05:28 +0000
Subject: [issue6031] BaseServer.shutdown documentation is incomplete
In-Reply-To: <1242431876.91.0.139343855315.issue6031@psf.upfronthosting.co.za>
Message-ID: <1285711528.92.0.753566004658.issue6031@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  It seems as though since issue 2302 is now closed, the comment about deadlocking if called before serve_forever may no longer be true.  Gabriel?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6031>
_______________________________________

From report at bugs.python.org  Wed Sep 29 00:14:32 2010
From: report at bugs.python.org (Thomas Wouters)
Date: Tue, 28 Sep 2010 22:14:32 +0000
Subject: [issue4684] sys.exit() exits program when non-daemonic threads are
	still running
In-Reply-To: <1229536748.7.0.859607140582.issue4684@psf.upfronthosting.co.za>
Message-ID: <1285712072.67.0.690957000408.issue4684@psf.upfronthosting.co.za>


Changes by Thomas Wouters <thomas at python.org>:


----------
resolution:  -> fixed
status: open -> closed
superseder:  -> Thread shutdown exception in Thread.notify()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4684>
_______________________________________

From report at bugs.python.org  Wed Sep 29 00:17:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Sep 2010 22:17:29 +0000
Subject: [issue6031] BaseServer.shutdown documentation is incomplete
In-Reply-To: <1242431876.91.0.139343855315.issue6031@psf.upfronthosting.co.za>
Message-ID: <1285712249.8.0.354027223059.issue6031@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6031>
_______________________________________

From report at bugs.python.org  Wed Sep 29 00:28:34 2010
From: report at bugs.python.org (Ryan Seto)
Date: Tue, 28 Sep 2010 22:28:34 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1285712914.35.0.728469004946.issue7511@psf.upfronthosting.co.za>


Ryan Seto <mr.werewolf at gmail.com> added the comment:

I came across this issue while trying to install mercurial using easy_install. I applied the vcvars4.diff to my distutils and this solved the problem.


Environment:

Python 2.6.6 (64 bit)

setuptools-0.6c11.tar.gz
installed using the following instructions:
http://stackoverflow.com/questions/309412/how-to-setup-setuptools-for-python-2-6-on-windows

pywin32-214.win-amd64-py2.6 (installed binaries)
py2exe-0.6.9.win64-py2.6.amd64 (installed binaries)


Windows 7 (64 bit)
Visual Studio Team System 2008 (installed everything)
Visual Studio 2008 SDK 1.1 (installed everything)

----------
nosy: +MrWerewolf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Wed Sep 29 00:45:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Sep 2010 22:45:03 +0000
Subject: [issue9628] runtests.sh -x doesn't work with more than two args (sed
	error)
In-Reply-To: <1282062577.36.0.157889963246.issue9628@psf.upfronthosting.co.za>
Message-ID: <1285713903.55.0.397073487091.issue9628@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in py3k r85078, 3.1 r85079.  Note that the only fix required was to the 'PAT' line, the other sed expressions are operating only on single filenames-per-line and so don't need the 'g' added.

I don't see runtests.sh in 2.7 (or 2.6), yet the history goes back quite a few years...

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type:  -> behavior
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9628>
_______________________________________

From report at bugs.python.org  Wed Sep 29 00:46:44 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 28 Sep 2010 22:46:44 +0000
Subject: [issue9518] PyModuleDef_HEAD_INIT does not explicitly initialize all
	fields of m_base
In-Reply-To: <1280965412.21.0.0751804906986.issue9518@psf.upfronthosting.co.za>
Message-ID: <1285714004.85.0.496703272342.issue9518@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Thanks.  The code in question is a wrapper to a security-sensitive library (user-space SELinux code), hence the compilation warnings have been turned up as much as possible.

The .c code in question is generated by SWIG, and that does indeed appear to be writing out full initializers for PyTypeObject instances (and the other associated structs).

It appears to be just Python 3's PyModuleDef_HEAD_INIT macro that leaves fields uninitialized (hence this patch).

The gory details of the SWIG-generated code can be seen at:
  http://userspace.selinuxproject.org/trac/browser/libselinux/src/selinuxswig_wrap.c
(and the .i files in that directory)

Although it's not on by default gcc will issue a "missing initializer" warning when fields aren't initialized when "-Wmissing-field-initializers" is enabled (in this case, due to the use of "-W").  This becomes an error with -Werror.

Whether or not this is a useful warning isn't clear to me, but it seems to be reasonable to suppress the warning given that as-is, people who use gcc's "-W" catch-all will run into this on all Python 3 modules, and that the patch is trivial, and that this case gives no warnings when building such code against Python 2.*

Hope this makes sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9518>
_______________________________________

From report at bugs.python.org  Wed Sep 29 01:14:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 23:14:00 +0000
Subject: [issue9978] test_os failures on XP-4 buildbot
In-Reply-To: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>
Message-ID: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This has started showing up since r85073.

======================================================================
ERROR: test_CTRL_BREAK_EVENT (test.test_os.Win32KillTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_os.py", line 1068, in test_CTRL_BREAK_EVENT
    self._kill_with_event(signal.CTRL_BREAK_EVENT, "CTRL_BREAK_EVENT")
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_os.py", line 1039, in _kill_with_event
    os.kill(proc.pid, event)
WindowsError: [Error 5] Access is denied

http://www.python.org/dev/buildbot/builders/x86%20XP-4%203.x

----------
components: Library (Lib), Tests, Windows
keywords: buildbot
messages: 117561
nosy: brian.curtin, ocean-city, pitrou, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: test_os failures on XP-4 buildbot
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9978>
_______________________________________

From report at bugs.python.org  Wed Sep 29 01:21:01 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 28 Sep 2010 23:21:01 +0000
Subject: [issue7346] Redirected stdout fires [Errno 9]
In-Reply-To: <1258564533.69.0.0908463291045.issue7346@psf.upfronthosting.co.za>
Message-ID: <1285716061.27.0.391084229049.issue7346@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, mingw uses a different C runtime (msvcrt.dll) than Python (msvcr90.dll), so file descriptors are completely different and this causes the error.

I can see two solutions:

- Use the same compiler as python26; I've also heard about a way to force mingw to use msvcr90.dll.

- Avoid to pass mingw file descriptors to the python interpreter.  This requires more work: create a PyTypeObject that mimics a file object, and set this as sys.stdout. It should be enough to implement .write() and .flush(); you can use the C system calls (fwrite, fflush or whatever) there, and the file descriptors are used in a consistent way.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7346>
_______________________________________

From report at bugs.python.org  Wed Sep 29 01:43:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 23:43:44 +0000
Subject: [issue9602] PyObject_AsCharBuffer() should only accept read-only
	objects
In-Reply-To: <1281793352.06.0.62940034279.issue9602@psf.upfronthosting.co.za>
Message-ID: <1285717424.56.0.0476620638371.issue9602@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, 3.x documentation is fixed to recommend the new buffer API funcs over the old compatibility funcs. On Victor's private suggestion, I'm now closing the issue.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9602>
_______________________________________

From report at bugs.python.org  Wed Sep 29 01:47:03 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 28 Sep 2010 23:47:03 +0000
Subject: [issue7938] makesetup interprets macros -DA=B as a Make variable
	definition
In-Reply-To: <1266281072.48.0.268109023834.issue7938@psf.upfronthosting.co.za>
Message-ID: <1285717623.96.0.930626393035.issue7938@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

"man sh" does not list [[:alpha:]]* as an accepted pattern. This is a glob pattern, not a regular expression.
While the proposed patch may work for some environments, we should find a more compatible way.  Maybe a new case
   "[ ]*=") ;;
(a space somewhere before the '=') could be used before to prevent '*=*' from matching the sqlite line.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7938>
_______________________________________

From report at bugs.python.org  Wed Sep 29 02:14:38 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Sep 2010 00:14:38 +0000
Subject: [issue5131] pprint doesn't know how to print a defaultdict
In-Reply-To: <1233592442.21.0.0563262599933.issue5131@psf.upfronthosting.co.za>
Message-ID: <1285719278.05.0.378218444669.issue5131@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Ben, I don't think there is any value is opening more issues like pprint-doesn't-handle-object-x (named tuples, defautdicts, deques, generators, etc).

As it is currently designed, pprint doesn't offer usable hooks and it is not easy to build-out to handle new object types.  For the most part, users just cast to a list before calling pprint.

ISTM, the RightAnswer(tm) is to overhaul pprint and add hooks for handling new objects.  Ideally, there would be flexible print options and reprlib-like features for limiting output and for marking recursive constructs with "..."

It would be better to start fresh than to continually pile on to the current hodge-podge.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5131>
_______________________________________

From report at bugs.python.org  Wed Sep 29 02:20:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 00:20:50 +0000
Subject: [issue9979] Create PyUnicode_AsWideCharString() function
In-Reply-To: <1285719650.86.0.122072445011.issue9979@psf.upfronthosting.co.za>
Message-ID: <1285719650.86.0.122072445011.issue9979@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyUnicode_AsWideChar() doesn't merge surrogate pairs on a system with 32 bits wchar_t and Python compiled in narrow mode (sizeof(wchar_t) == 4 and sizeof(Py_UNICODE) == 2) => see issue #8670.

It is not easy to fix this problem because the callers of PyUnicode_AsWideChar() suppose that the output (wide character) string has the same length (in character) than the input (PyUnicode) string (suppose that sizeof(wchar_t) == sizeof(Py_UNICODE)). And PyUnicode_AsWideChar() doesn't write nul character at the end if the output string is truncated.

To prepare this change, a new PyUnicode_AsWideCharString() function would help because it does compute the size of the output buffer (whereas PyUnicode_AsWideChar() requires the output buffer in an argument).

Attached patch implements it:
-------
/* Convert the Unicode object to a wide character string. The output string
   always ends with a nul character. If size is not NULL, write the number of
   wide characters (including the final nul character) into *size.

   Returns a buffer allocated by PyMem_Alloc() (use PyMem_Free() to free it) on
   success. On error, returns NULL and *size is undefined. */

PyAPI_FUNC(wchar_t*) PyUnicode_AsWideCharString(
    PyUnicodeObject *unicode,   /* Unicode object */
    Py_ssize_t *size            /* number of characters of the result */
    );
-------

----------
components: Interpreter Core, Unicode
files: pyunicode_aswidecharstring.patch
keywords: patch
messages: 117566
nosy: haypo
priority: normal
severity: normal
status: open
title: Create PyUnicode_AsWideCharString() function
versions: Python 3.2
Added file: http://bugs.python.org/file19054/pyunicode_aswidecharstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9979>
_______________________________________

From report at bugs.python.org  Wed Sep 29 02:21:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 00:21:33 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285719693.54.0.203518107853.issue8670@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

#9979 proposes to create a new PyUnicode_AsWideCharString() function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8670>
_______________________________________

From report at bugs.python.org  Wed Sep 29 02:27:52 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 29 Sep 2010 00:27:52 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285720072.53.0.364047563712.issue8670@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I know enough about Unicode to have reported this bug, but I don't feel knowledgeable enough about Python's Unicode implementation to comment on your suggested solution.

I'm adding the other people listed in Misc/maintainers.rst as interested in Unicode to the nosy list on this issue and the one you just linked to.

----------
nosy: +ezio.melotti, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8670>
_______________________________________

From report at bugs.python.org  Wed Sep 29 02:28:14 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 29 Sep 2010 00:28:14 +0000
Subject: [issue9979] Create PyUnicode_AsWideCharString() function
In-Reply-To: <1285719650.86.0.122072445011.issue9979@psf.upfronthosting.co.za>
Message-ID: <1285720094.96.0.942831650262.issue9979@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +ezio.melotti, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9979>
_______________________________________

From report at bugs.python.org  Wed Sep 29 02:59:32 2010
From: report at bugs.python.org (Willem de Bruijn)
Date: Wed, 29 Sep 2010 00:59:32 +0000
Subject: [issue7938] makesetup interprets macros -DA=B as a Make variable
	definition
In-Reply-To: <1266281072.48.0.268109023834.issue7938@psf.upfronthosting.co.za>
Message-ID: <1285721972.31.0.577790127333.issue7938@psf.upfronthosting.co.za>


Willem de Bruijn <wdebruij at dds.nl> added the comment:

Good call. The posix regular expression character class [[:alpha:]] is apparently not as universally supported as I thought. Posix mandates it for filepath expansion[1], but that's not of much help on older and non-compliant systems. However, from what I can gather even standard Bourne accepts plain character classes ([a-z]) in its filename expansion[2]. If so, a simple fix is to rewrite it as 

-		*=*)	DEFS="$line$NL$DEFS"; continue;;
+		[a-zA-Z]*=*) DEFS="$line$NL$DEFS"; continue;;


On the other hand, your solution should also work and is actually more robust, so I'd go with that.

  willem

--
references:

[1] http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_01
[2] http://steve-parker.org/sh/bourne.shtml

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7938>
_______________________________________

From report at bugs.python.org  Wed Sep 29 03:00:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 01:00:58 +0000
Subject: [issue9979] Create PyUnicode_AsWideCharString() function
In-Reply-To: <1285719650.86.0.122072445011.issue9979@psf.upfronthosting.co.za>
Message-ID: <1285722058.65.0.0646178690486.issue9979@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of the patch:
 - fix PyUnicode_AsWideCharString() :-)
 - replace PyUnicode_AsWideChar() by PyUnicode_AsWideCharString() in most functions using PyUnicode_AsWideChar()
 - indicate that PyUnicode_AsWideCharString() raises a MemoryError on error

Keep the call to PyUnicode_AsWideChar() in:
 - Modules/getpath.c because getpath.c uses a global limitation of MAXPATHLEN+1 characters
 - WCharArray_set_value() and U_set() of ctypes because the output buffer size is fixed

----------
Added file: http://bugs.python.org/file19055/pyunicode_aswidecharstring-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9979>
_______________________________________

From report at bugs.python.org  Wed Sep 29 03:01:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 01:01:03 +0000
Subject: [issue9979] Create PyUnicode_AsWideCharString() function
In-Reply-To: <1285719650.86.0.122072445011.issue9979@psf.upfronthosting.co.za>
Message-ID: <1285722063.01.0.406421347064.issue9979@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file19054/pyunicode_aswidecharstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9979>
_______________________________________

From report at bugs.python.org  Wed Sep 29 03:06:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 01:06:54 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1285722414.12.0.729469062921.issue9969@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #4626 which introduced PyCF_IGNORE_COOKIE and PyPARSE_IGNORE_COOKIE flags to support unicode string for the builtin compile() function.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9969>
_______________________________________

From report at bugs.python.org  Wed Sep 29 03:09:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Sep 2010 01:09:37 +0000
Subject: [issue7110] Output test failures on stderr in regrtest.py
In-Reply-To: <1255334934.67.0.943013773261.issue7110@psf.upfronthosting.co.za>
Message-ID: <1285722577.82.0.00649610721598.issue7110@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks good to me.  Committed in r85086.  Thanks, Sandro.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7110>
_______________________________________

From report at bugs.python.org  Wed Sep 29 03:23:01 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 29 Sep 2010 01:23:01 +0000
Subject: [issue9974] tokenizer.untokenize not invariant with line continuations
In-Reply-To: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>
Message-ID: <1285723381.54.0.702269063851.issue9974@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9974>
_______________________________________

From report at bugs.python.org  Wed Sep 29 03:23:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Sep 2010 01:23:42 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1285723422.28.0.960681229737.issue8845@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Added version print to test_sqlite in r85807.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Wed Sep 29 04:08:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Sep 2010 02:08:31 +0000
Subject: [issue9975] Incorrect use of flowinfo and scope_id in IPv6 sockaddr
	tuple
In-Reply-To: <1285698946.58.0.377750793336.issue9975@psf.upfronthosting.co.za>
Message-ID: <1285726111.45.0.657667794478.issue9975@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9975>
_______________________________________

From report at bugs.python.org  Wed Sep 29 05:11:32 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Wed, 29 Sep 2010 03:11:32 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>


New submission from Kiriakos Vlahos <pyscripter at gmail.com>:

I am the author of PyScripter a popular python IDE (pyscripter.googlecode.com).  Following a user report I found out that str(float) occasionally produces wrong results with Python 2.7 and 3.1.

eg.
>>> str(38210.0)  //wrong
'3820:.0'
>>> str(37210.0) // correct
'37210.0'
>>> str(36210.0)  //wrong
'3620:.0'

This only happens with the embedded python engine which uses the pythonxx.dll of the official distribution.  It does not happen using the stand alone interpreter of the PyScripter remote engine.

The recent changes in Python 3.2a2 fix this issue.
Any ideas why the embedded Python would give different results from the stand alone interpreter?

----------
components: Interpreter Core, Windows
messages: 117574
nosy: Kiriakos.Vlahos
priority: normal
severity: normal
status: open
title: str(float) failure
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 07:18:43 2010
From: report at bugs.python.org (Lenard Lindstrom)
Date: Wed, 29 Sep 2010 05:18:43 +0000
Subject: [issue9602] PyObject_AsCharBuffer() should only accept read-only
	objects
In-Reply-To: <1285709697.3183.2.camel@localhost.localdomain>
Message-ID: <4CA2CC1E.2030205@telus.net>


Lenard Lindstrom <len-l at telus.net> added the comment:

That is perfectly fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9602>
_______________________________________

From report at bugs.python.org  Wed Sep 29 08:28:38 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 29 Sep 2010 06:28:38 +0000
Subject: [issue9981] let make_buildinfo use a temporary directory on windows
In-Reply-To: <1285741718.07.0.0571419018875.issue9981@psf.upfronthosting.co.za>
Message-ID: <1285741718.07.0.0571419018875.issue9981@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

make_buildinfo currently creates temporary files getbuildinfo2.c and getbuildinfo.o in the current build directory.  This update allows the caller to specify a temp directory to put those files in.
The PCBuild pythoncore.vcproj now makes use of this, to put the.c and .o files in the current temporary directory $(IntDir).

This makes it possible to compile multiple project configurations in parallel, with tools such as incredibuild, without fearing that each will trample the other's getbuildinfo files.

Also removed an unnecessary 64 bit config for make_buildinfo.

----------
components: Interpreter Core
messages: 117576
nosy: krisvale
priority: normal
severity: normal
status: open
title: let make_buildinfo use a temporary directory on windows
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9981>
_______________________________________

From report at bugs.python.org  Wed Sep 29 08:54:21 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 29 Sep 2010 06:54:21 +0000
Subject: [issue9979] Create PyUnicode_AsWideCharString() function
In-Reply-To: <1285719650.86.0.122072445011.issue9979@psf.upfronthosting.co.za>
Message-ID: <4CA2E2A9.7050609@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner at haypocalc.com>:
> 
> PyUnicode_AsWideChar() doesn't merge surrogate pairs on a system with 32 bits wchar_t and Python compiled in narrow mode (sizeof(wchar_t) == 4 and sizeof(Py_UNICODE) == 2) => see issue #8670.
> 
> It is not easy to fix this problem because the callers of PyUnicode_AsWideChar() suppose that the output (wide character) string has the same length (in character) than the input (PyUnicode) string (suppose that sizeof(wchar_t) == sizeof(Py_UNICODE)). And PyUnicode_AsWideChar() doesn't write nul character at the end if the output string is truncated.
> 
> To prepare this change, a new PyUnicode_AsWideCharString() function would help because it does compute the size of the output buffer (whereas PyUnicode_AsWideChar() requires the output buffer in an argument).

Great idea !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9979>
_______________________________________

From report at bugs.python.org  Wed Sep 29 09:02:30 2010
From: report at bugs.python.org (John Machin)
Date: Wed, 29 Sep 2010 07:02:30 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285743750.02.0.558603149095.issue9980@psf.upfronthosting.co.za>


Changes by John Machin <sjmachin at users.sourceforge.net>:


----------
nosy: +sjmachin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 09:04:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Sep 2010 07:04:45 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285743885.6.0.25645529499.issue9980@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +eric.smith, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 09:11:27 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 29 Sep 2010 07:11:27 +0000
Subject: [issue9979] Create PyUnicode_AsWideCharString() function
In-Reply-To: <1285719650.86.0.122072445011.issue9979@psf.upfronthosting.co.za>
Message-ID: <1285744287.59.0.722291764266.issue9979@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

+1 from me as well.
But shouldn't PyUnicode_AsWideCharString() merge surrogate pairs when it can? The implementation doesn't do this.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9979>
_______________________________________

From report at bugs.python.org  Wed Sep 29 09:16:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Sep 2010 07:16:59 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285744619.77.0.086674410325.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This sounds similar to issue 9215, which was due to a compiler optimization bug.  Certainly it points to something going wrong in _Py_dg_dtoa.

What platform are these results from?

Do you have minimal code that can be used to reproduce?

I'm surprised that 3.2 fixes this:  the float-to-string conversion code is pretty much identical in both 3.1 and 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 09:27:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Sep 2010 07:27:25 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285745245.9.0.587500866615.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'm surprised that 3.2 fixes this:  the float-to-string conversion code > is pretty much identical in both 3.1 and 3.2.

Whoops---not quite.  The conversion code *is* pretty much identical, but 3.2 now uses a different algorithm for str (it's equal to repr now).  So I'd expect that you'll see the issue in 3.2 too if you try something like

    '%.12g' % 38210.0

Kiriakos, can you explain a bit more what the difference is between the 'remote engine' and the 'stand along interpreter'?  Is the core Python library compiled using different compilers for these two?

Eric, are you able to reproduce this at all?  I don't have access to Windows at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 10:17:58 2010
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Wed, 29 Sep 2010 08:17:58 +0000
Subject: [issue1669539] Change (fix!) os.path.isabs() semantics on Win32
Message-ID: <1285748278.8.0.299955101029.issue1669539@psf.upfronthosting.co.za>


Changes by Ulrich Eckhardt <eckhardt at satorlaser.com>:


----------
nosy: +eckhardt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669539>
_______________________________________

From report at bugs.python.org  Wed Sep 29 10:40:27 2010
From: report at bugs.python.org (Marvin Mundry)
Date: Wed, 29 Sep 2010 08:40:27 +0000
Subject: [issue9982] Pointer problem in initializing array of arrays
In-Reply-To: <1285749627.74.0.65331145627.issue9982@psf.upfronthosting.co.za>
Message-ID: <1285749627.74.0.65331145627.issue9982@psf.upfronthosting.co.za>


New submission from Marvin Mundry <marvin.mun at gmx.de>:

>>> m1=[[0,0,0,0]]*4
>>> m1
[[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]]
>>> m1[0][0]+=1
>>> m1
[[1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0]]

after initializing an array of arrays as done in the first line of the code snippet all elements in the array point to the same object in memory.

----------
components: None
messages: 117581
nosy: mastermarv
priority: normal
severity: normal
status: open
title: Pointer problem in initializing array of arrays
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9982>
_______________________________________

From report at bugs.python.org  Wed Sep 29 10:46:21 2010
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Wed, 29 Sep 2010 08:46:21 +0000
Subject: [issue1669539] Change (fix!) os.path.isabs() semantics on Win32
Message-ID: <1285749981.42.0.338607012888.issue1669539@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

I just stumbled across the issue with isabs(). I'd also say that Mark Hammond already provided the typical use case for this, i.e. that you allow relative paths for convenience when storing them or putting them on the commandline, but for actual use you first convert them so that their meaning doesn't change under your feet, e.g. because they depend on volatile things like the current working directory or drive.

If you assume that is the intention or typical use case, then calling isabs() to determine if the path is stable doesn't work. Of course, the wording of the documentation then needs to change, too, as it explicitly says "after chopping off a potential drive letter".

Concerning the behaviour of path.join() and support for "\\server\share" paths, I'm not sure, but I think that these are issues that can be discussed/changed separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669539>
_______________________________________

From report at bugs.python.org  Wed Sep 29 10:51:50 2010
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Wed, 29 Sep 2010 08:51:50 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1285750310.64.0.79781616348.issue5117@psf.upfronthosting.co.za>


Changes by Ulrich Eckhardt <eckhardt at satorlaser.com>:


----------
nosy: +eckhardt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Wed Sep 29 10:56:26 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 29 Sep 2010 08:56:26 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285750586.07.0.885186161758.issue9980@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

>From their web page, it looks like PyScripter only runs on Windows, so I assume these results are generated there.

I won't be able to test on Windows until tonight.

Kiriakos: Does this only happen within PyScripter, or does it also happen when you use the python.exe using the same pythonxx.dll?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 10:58:02 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Wed, 29 Sep 2010 08:58:02 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285750682.45.0.760804256984.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

PyScripter is a Windows only IDE.  I am using the official release 
*** Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32. ***

Python 3.2a2 fixes this since, according to SVN, str is now using the same code (or at least the same parameters to the _Py_dg_dtoa call) as repr.

I am afraid I do not have a minimal code to reproduce this, since the error only occurs with the python.dll embedded to PyScripter.  To reproduce with PyScripter you need to

a) Download and install the latest version of PyScripter from pyscripter.googlecode.com
b) Set the python engine to the internal (embedded python) using the menu (Run, Python Engine, Internal)
c) Execute in the interpreter window str(38210.0) etc.

The puzzling thing is that the same Python.dll when used by python.exe and not PyScripter produces correct results.  PyScripter does not mess up with built-ins in any way or set any special flags and I see no reason why results would differ.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 11:08:04 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Wed, 29 Sep 2010 09:08:04 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285751284.42.0.0875727364334.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

Answer to Mark's question:

*** Python 3.2a2 (r32a2:84522, Sep  5 2010, 22:35:34) [MSC v.1500 32 bit (Intel)] on win32. ***
>>> '%.12g' % 38210.0
'3820:'

So indeed the error still exists in _Py_dg_dtoa.

The internal engine uses an embedded python.dll.  The remote engine uses a stand-alone pythonw.exe in a separate process and communicates with it with rpyc (http://rpyc.wikidot.com/).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 11:14:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 09:14:25 +0000
Subject: [issue9979] Create PyUnicode_AsWideCharString() function
In-Reply-To: <1285744287.59.0.722291764266.issue9979@psf.upfronthosting.co.za>
Message-ID: <201009291114.17306.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> But shouldn't PyUnicode_AsWideCharString() merge surrogate pairs when it
> can? The implementation doesn't do this.

I don't want to do two different things at the same time. My plan is:
 - create PyUnicode_AsWideCharString()
 - use PyUnicode_AsWideCharString() everywhere
 - patch unicode_aswidechar() (used by PyUnicode_AsWideChar() and 
PyUnicode_AsWideCharString()) to convert surrogates when needed

So, you agree with the API (and the documentation)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9979>
_______________________________________

From report at bugs.python.org  Wed Sep 29 11:19:55 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 29 Sep 2010 09:19:55 +0000
Subject: [issue9981] let make_buildinfo use a temporary directory on windows
In-Reply-To: <1285741718.07.0.0571419018875.issue9981@psf.upfronthosting.co.za>
Message-ID: <1285751995.6.0.690733794297.issue9981@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ooops, here is the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file19056/make_buildinfo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9981>
_______________________________________

From report at bugs.python.org  Wed Sep 29 11:57:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 09:57:41 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285754261.79.0.860478937831.issue9873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> A possible duck-typing approach here would be to replace the
> "instance(x, str)" tests with "hasattr(x, 'encode')" checks instead.

Looks more ugly than useful to me. People wanting to emulate str had better subclass it anyway...

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Wed Sep 29 12:01:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 10:01:12 +0000
Subject: [issue9975] Incorrect use of flowinfo and scope_id in IPv6 sockaddr
	tuple
In-Reply-To: <1285698946.58.0.377750793336.issue9975@psf.upfronthosting.co.za>
Message-ID: <1285754472.04.0.725432675908.issue9975@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis
stage:  -> patch review
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9975>
_______________________________________

From report at bugs.python.org  Wed Sep 29 12:04:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 10:04:07 +0000
Subject: [issue9982] Pointer problem in initializing array of arrays
In-Reply-To: <1285749627.74.0.65331145627.issue9982@psf.upfronthosting.co.za>
Message-ID: <1285754647.6.0.319013080835.issue9982@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That's expected behaviour, syntactically. Multiplying a sequence doesn't deep-copy its elements.
If you want an array of distinct arrays, just write:

>>> m1 = [[0,0,0,0] for i in range(4)]
>>> m1[1][0] = 6
>>> m1
[[0, 0, 0, 0], [6, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]]

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9982>
_______________________________________

From report at bugs.python.org  Wed Sep 29 12:21:59 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 29 Sep 2010 10:21:59 +0000
Subject: [issue9978] test_os failures on XP-4 buildbot
In-Reply-To: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>
Message-ID: <1285755719.45.0.867071664536.issue9978@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I cannot reproduce this in my environment...

E:\python-dev\py3k>py3k -m test.regrtest test_os
[1/1] test_os
[33503 refs]
1 test OK.
[85140 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9978>
_______________________________________

From report at bugs.python.org  Wed Sep 29 12:32:16 2010
From: report at bugs.python.org (Nick Craig-Wood)
Date: Wed, 29 Sep 2010 10:32:16 +0000
Subject: [issue5131] pprint doesn't know how to print a defaultdict
In-Reply-To: <1233592442.21.0.0563262599933.issue5131@psf.upfronthosting.co.za>
Message-ID: <1285756336.38.0.567376596131.issue5131@psf.upfronthosting.co.za>


Nick Craig-Wood <nick at craig-wood.com> added the comment:

Raymond Hettinger (rhettinger) wrote:
> Ben, I don't think there is any value is opening more issues like pprint-doesn't-handle-object-x (named tuples, defautdicts, deques, generators, etc).
> 
> As it is currently designed, pprint doesn't offer usable hooks and it is not easy to build-out to handle new object types.  For the most part, users just cast to a list before calling pprint.

I mildly disagree, IMHO pprint should be able to make a decent job of all the built in types otherwise it loses its value as a debugging tool.  It is a suprise when a built in type doesn't pprint properly.

This would surely be an excellent use of the abstract base classes defined in the collections module for pprint to make a best guess as to how to print types it doesn't understand directly?

> ISTM, the RightAnswer(tm) is to overhaul pprint and add hooks for handling new objects.  Ideally, there would be flexible print options and reprlib-like features for limiting output and for marking recursive constructs with "..."

That is a very good idea, but might be unecessary with the ABC idea above

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5131>
_______________________________________

From report at bugs.python.org  Wed Sep 29 12:41:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 10:41:58 +0000
Subject: [issue9979] Create PyUnicode_AsWideCharString() function
In-Reply-To: <1285719650.86.0.122072445011.issue9979@psf.upfronthosting.co.za>
Message-ID: <1285756918.55.0.845107982404.issue9979@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I fixed in this issue in multiple commits:
 - r85093: create PyUnicode_AsWideCharString()
 - r85094: use it in import.c
 - r85095: use it for _locale.strcoll()
 - r85096: use it for time.strftime()
 - r85097: use it in _ctypes module

> So, you agree with the API (and the documentation)?

Well, you can now directly patch the documentation. I think that the API is simple and fine :-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9979>
_______________________________________

From report at bugs.python.org  Wed Sep 29 12:48:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 10:48:43 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1285757323.39.0.76994449268.issue9630@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Forget my previous message, I forgot important points.

> So the only reason why you have to go through
> all those hoops is to
>
> * allow the complete set of Python supported encoding
>   names for the PYTHONFSENCODING
>
> * make sure that the Py_FilesystemDefaultEncoding is set
>   to the actual name of the codec as used by the system

Not only. As I wrote in my first message (msg114191), there are two
other good reasons to keep the current code but redecode filenames:

 * Encoding aliases: locale encoding is not always written as the
   official Python encoding name. Eg. utf8 vs UTF-8, iso8859-1 vs
   latin_1, etc. We have to be able to load Lib/encodings/aliases.py to
   to get the Python codec.

 * Codecs implemented in Python: only ascii, latin1, utf8 and mbcs
   codecs are builtin. All other encodings are implemented in Python. If
   your filesystem encoding is ShiftJIS, you have to load
   Lib/encodings/shift_jis.py to load the codec.

For these two reasons, we have to import Python modules before being
able to set the filesystem encoding. So we have to redecode filenames
after setting the filesystem encodings.

> the redecoding of the filenames is fragile

We can setup a buildbot installed in a non-ascii path. Antoine had such
buildbot, which already helped to find many bugs related to non-ascii paths.

--

We can choose to only support ascii, latin1, utf8 and mbcs for the
filesystem encoding, but users will complain that we break compatibility
with old systems. Python3 already "breaks" the language, I don't think
that it is a good idea to choose to become incompatible with old systems
just to simplify (too much) the code.

--

Another solution would be to unload all modules, clear all caches,
delete all code objects, etc. after setting the filesystem encoding. But
I think that it is inefficient and nobody wants a slower Python startup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Wed Sep 29 12:50:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 10:50:09 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285757409.68.0.195028824192.issue9962@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85100.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9962>
_______________________________________

From report at bugs.python.org  Wed Sep 29 12:50:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 10:50:29 +0000
Subject: [issue9630] Redecode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1285757429.92.0.496594834741.issue9630@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 4:
 - Rename "reencode" to "redecode"
 - Return -1 (instead of 1) on error

----------
title: Reencode filenames when setting the filesystem encoding -> Redecode filenames when setting the filesystem encoding
Added file: http://bugs.python.org/file19057/redecode_modules_path-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Wed Sep 29 12:50:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 10:50:51 +0000
Subject: [issue9630] Redecode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1285757451.04.0.913395300862.issue9630@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file18996/reencode_modules_path-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Wed Sep 29 12:52:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 10:52:40 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1285757560.32.0.704182525738.issue9090@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:11:42 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:11:42 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

please add a large NOTE explaining that urllib does not perform any ssl validation.

----------
assignee: docs at python
components: Documentation
messages: 117596
nosy: db, docs at python
priority: normal
severity: normal
status: open
title: please add a large NOTE explaining that urllib does not perform any ssl validation
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:12:10 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:12:10 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285758730.59.0.656379503498.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

--> (out of the box)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:13:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:13:11 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285758791.56.0.750974853584.issue9983@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sounds reasonable to me.
(although I would like that to change, see issue1589)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:13:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:13:36 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285758816.55.0.878075707656.issue9983@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:14:03 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:14:03 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285758843.9.0.544065139159.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

This is issue is in respect to https connections :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:16:54 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:16:54 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285759014.52.0.307888445885.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

Hi pitrou, that bug you linked to is really long can state a summary of any changes made to python and their impact - alternatively the lack of (changes) and their impact.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:17:38 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:17:38 +0000
Subject: [issue9984] please add a large NOTE explaining that urllib2 does not
	perform any ssl validation
In-Reply-To: <1285759058.32.0.409782287474.issue9984@psf.upfronthosting.co.za>
Message-ID: <1285759058.32.0.409782287474.issue9984@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

please add a large NOTE explaining that urllib2 does not perform any ssl (for https connection) validation out of the box. 
Also see 9983 for urrlib.

----------
messages: 117601
nosy: db
priority: normal
severity: normal
status: open
title: please add a large NOTE explaining that urllib2 does not perform any ssl validation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9984>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:18:21 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:18:21 +0000
Subject: [issue9984] please add a large NOTE explaining that urllib2 does not
	perform any ssl validation
In-Reply-To: <1285759058.32.0.409782287474.issue9984@psf.upfronthosting.co.za>
Message-ID: <1285759101.89.0.0100286775563.issue9984@psf.upfronthosting.co.za>


Changes by david <db.pub.mail at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9984>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:22:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:22:45 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285759014.52.0.307888445885.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285759360.3168.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Hi pitrou, that bug you linked to is really long can state a summary
> of any changes made to python and their impact - alternatively the
> lack of (changes) and their impact.

No changes yet unfortunately. As for the impact, you already know it,
since you filed this very issue :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:32:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:32:11 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285759931.91.0.202122448829.issue9983@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've added warnings for httplib, urllib, urllib2 in r85101, r85102 and r85103. The changes can take a day or two to appear online.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:32:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:32:45 +0000
Subject: [issue9984] please add a large NOTE explaining that urllib2 does not
	perform any ssl validation
In-Reply-To: <1285759058.32.0.409782287474.issue9984@psf.upfronthosting.co.za>
Message-ID: <1285759965.19.0.60821264216.issue9984@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> please add a large NOTE explaining that urllib does not perform any ssl validation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9984>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:41:40 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:41:40 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285760500.68.0.800730068202.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

thank you :)

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:41:46 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 29 Sep 2010 11:41:46 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1285760506.41.0.796034161171.issue1589@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
Removed message: http://bugs.python.org/msg58435

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:42:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:42:32 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285760552.03.0.271920457384.issue9983@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/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:45:15 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 29 Sep 2010 11:45:15 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1285757323.39.0.76994449268.issue9630@psf.upfronthosting.co.za>
Message-ID: <4CA326C4.90601@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Forget my previous message, I forgot important points.
> 
>> So the only reason why you have to go through
>> all those hoops is to
>>
>> * allow the complete set of Python supported encoding
>>   names for the PYTHONFSENCODING
>>
>> * make sure that the Py_FilesystemDefaultEncoding is set
>>   to the actual name of the codec as used by the system
> 
> Not only. As I wrote in my first message (msg114191), there are two
> other good reasons to keep the current code but redecode filenames:
> 
>  * Encoding aliases: locale encoding is not always written as the
>    official Python encoding name. Eg. utf8 vs UTF-8, iso8859-1 vs
>    latin_1, etc. We have to be able to load Lib/encodings/aliases.py to
>    to get the Python codec.
> 
>  * Codecs implemented in Python: only ascii, latin1, utf8 and mbcs
>    codecs are builtin. All other encodings are implemented in Python. If
>    your filesystem encoding is ShiftJIS, you have to load
>    Lib/encodings/shift_jis.py to load the codec.
> 
> For these two reasons, we have to import Python modules before being
> able to set the filesystem encoding. So we have to redecode filenames
> after setting the filesystem encodings.

No, that's not needed ! Please see my earlier message: you can still
do all this at a later time during startup and double-check that
the encoding is indeed valid.

The main point is that you don't need to apply all those checks
before setting the file system encoding in the interpreter.
Early on you just assume that the env vars are setup correctly
and head on into starting up the interpreter.

If the decoding fails during startup due to a wrong encoding of
file or path names, the interpreter will signal this. If you have
a case where everything imports fine, you can then still double
check at the time the file system encoding is set now to e.g.
detect cases where the encoding was set to ascii, but in reality
the interpreter was just lucky and the file system encoding
should be utf-8.

----------
title: Redecode filenames when setting the filesystem encoding -> Reencode filenames when setting the filesystem encoding

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:52:12 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 29 Sep 2010 11:52:12 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1285761132.7.0.523304253866.issue1589@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Removed this message by mistake.

Author	ahasenack
Date	2007-12-11.21:11:53

Ups, typo in the script:
cert = "verisign-inc-class-3-public-primary.pem"

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 29 14:18:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 12:18:08 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <4CA326C4.90601@egenix.com>
Message-ID: <201009291417.59634.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mercredi 29 septembre 2010 13:45:15, vous avez ?crit :
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> STINNER Victor wrote:
> > STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> > 
> > Forget my previous message, I forgot important points.
> > 
> >> So the only reason why you have to go through
> >> all those hoops is to
> >> 
> >> * allow the complete set of Python supported encoding
> >> 
> >>   names for the PYTHONFSENCODING
> >> 
> >> * make sure that the Py_FilesystemDefaultEncoding is set
> >> 
> >>   to the actual name of the codec as used by the system
> > 
> > Not only. As I wrote in my first message (msg114191), there are two
> > 
> > other good reasons to keep the current code but redecode filenames:
> >  * Encoding aliases: locale encoding is not always written as the
> >  
> >    official Python encoding name. Eg. utf8 vs UTF-8, iso8859-1 vs
> >    latin_1, etc. We have to be able to load Lib/encodings/aliases.py to
> >    to get the Python codec.
> >  
> >  * Codecs implemented in Python: only ascii, latin1, utf8 and mbcs
> >  
> >    codecs are builtin. All other encodings are implemented in Python. If
> >    your filesystem encoding is ShiftJIS, you have to load
> >    Lib/encodings/shift_jis.py to load the codec.
> > 
> > For these two reasons, we have to import Python modules before being
> > able to set the filesystem encoding. So we have to redecode filenames
> > after setting the filesystem encodings.
> 
> No, that's not needed ! Please see my earlier message: you can still
> do all this at a later time during startup and double-check that
> the encoding is indeed valid.

I don't understand how. Eg. if you set Py_FileSystemDefaultEncoding to 
"cp1252" before loading the first module, import a module will have to load the 
codec. Load the codec require to import a module. But how can you open cp1252 
module since you are unable to encode paths to the filesystem encoding (because 
the cp1252 codec is not available yet)?

> If the decoding fails during startup due to a wrong encoding of
> file or path names, ...

It is not not problem described in my previous message. How do you load non-
builtin codecs?

Can you write a patch implementing your ideas? I tried to write such patch 
(set Py_FileSystemDefaultEncoding before loading the first module), but it 
doesn't work for different reasons (all described in this issue). Maybe I 
misunderstood your proposition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Wed Sep 29 15:07:20 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 13:07:20 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285765640.77.0.351320281403.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

@pitrou you should also put an example of how to ACTUALLY establish a connection that can't be MITMed. Because lots of people are getting this wrong....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 15:11:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 13:11:56 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285765640.77.0.351320281403.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285765909.3168.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> @pitrou you should also put an example of how to ACTUALLY establish a
> connection that can't be MITMed. Because lots of people are getting
> this wrong....

It would require writing the code for checking hostnames that the ssl
module currently lacks, so if I write that code I'd rather add it to the
ssl module rather than as an example in the docs :)

But, yes, I agree that the situation is quite unsatisfying right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 16:01:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Sep 2010 14:01:27 +0000
Subject: [issue6640] urlparse should parse mailto: URL headers as query
	parameters
In-Reply-To: <1249346554.96.0.279967945769.issue6640@psf.upfronthosting.co.za>
Message-ID: <1285768887.71.0.202884186688.issue6640@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Which would be a bug.  According to RFC3986 it should be the path.  So the change can't be quite so simple as adding mailto to uses_query.  Since the query component is defined for generic uris according to the RFC, it sounds like urllib's parser needs some enhancement.

----------
nosy: +r.david.murray
type: behavior -> feature request
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6640>
_______________________________________

From report at bugs.python.org  Wed Sep 29 16:32:10 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 14:32:10 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285765909.3168.13.camel@localhost.localdomain>
Message-ID: <AANLkTinWkSQQxzuwJJO94PC7XOTDjqeG0qAcuZCvKzCi@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

Yes totally imho these modules should get fixed to actually do ssl checking.
This means that most users of these methods, even if they think they
are doing it properly as per the ssl module page, are still vulnerable
to attack.

I will add this comment to the bug you linked to above.
As an example, it only took a few minutes to confirm that the default
bzr install on ubuntu is vulnerable ->
https://bugs.edge.launchpad.net/bzr/+bug/651161
(bzr is only vulnerable if pycurl isn't installed but pycurl is only a
suggestion not a dependency ... ).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 16:32:19 2010
From: report at bugs.python.org (Marien Zwart)
Date: Wed, 29 Sep 2010 14:32:19 +0000
Subject: [issue9985] difflib.SequenceMatcher has slightly buggy and
	undocumented caching behavior
In-Reply-To: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za>
Message-ID: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za>


New submission from Marien Zwart <m_zwart at 123mail.org>:

SequenceMatcher caches the result of get_matching_blocks and get_opcodes. There are some problems with this:

What get_matching_blocks caches is a list of tuples. The first call does not return that list: it returns map(Match._make, self.matching_blocks) (converting the tuples to namedtuples). Subsequent calls just return self.matching_blocks directly. Especially in python 3 and up this is weird, since the first call returns a map object while later calls return a list.

This caching behavior is not documented, so calling code may mutate the returned list. One example of calling code is difflib itself: get_grouped_opcodes mutates the result of get_opcodes (a cached list). I am not sure if the right fix is to have get_grouped_opcodes copy before it mutates or to have get_opcodes return a copy.

Snippet demonstrating both bugs:

matcher = difflib.SequenceMatcher(a='aaaaaaaabc', b='aaaaaaaadc')
print(list(matcher.get_matching_blocks()))
# This should print the same thing, but it does not:
print(list(matcher.get_matching_blocks()))

print(matcher.get_opcodes())
print(list(matcher.get_grouped_opcodes()))
# This should print the same thing as the previous get_opcodes()
# list, but it does not:
print(matcher.get_opcodes())

----------
components: Library (Lib)
messages: 117612
nosy: marienz
priority: normal
severity: normal
status: open
title: difflib.SequenceMatcher has slightly buggy and undocumented caching behavior
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/issue9985>
_______________________________________

From report at bugs.python.org  Wed Sep 29 16:39:56 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 14:39:56 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1285771196.72.0.074694874619.issue1589@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

Welcome to 2010.
SSL shouldn't be difficult to use anymore or support in python applications. But yet, until the changes in http://bugs.python.org/issue9983 was fixed python devs were using modules without any warning of the security implications. pycurl works ... but a *LOT* of coders are not using pycurl. 

Today they are still getting it wrong and are still vulnerable to mitm attacks against https on the client side.

I have an example in fairly large open source project:
bzr --> (by default due to a dependency failure ... on not depending on pycurl).  
https://bugs.edge.launchpad.net/ubuntu/+source/checkbox/+bug/625076


Less large:
libcloud http://github.com/apache/libcloud/issues/issue/2
linode-python http://github.com/tjfontaine/linode-python/issues/issue/1

I would *very* much like to see these methods fixed by default.
You can talk about how the ssl protocol is not secure because of ca's handling certificates poorly, but until you *actually* perform proper validation you cannot say these things imho. 

I can keep on looking at python projects and reporting these issues but it is really easy, just look at anything that says and is important that mitm isn't possible against it -> then check the deps. in ubuntu /debian and pick the ones that don't use pycurl, check they don't validate the common name etc. and then you have a bunch of mitm'able apps probably ;)

----------
nosy: +db

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 29 16:54:14 2010
From: report at bugs.python.org (Amber Jain)
Date: Wed, 29 Sep 2010 14:54:14 +0000
Subject: [issue9986] PDF files of python docs have text missing
In-Reply-To: <1285772054.59.0.857308007062.issue9986@psf.upfronthosting.co.za>
Message-ID: <1285772054.59.0.857308007062.issue9986@psf.upfronthosting.co.za>


New submission from Amber Jain <i.amber.jain at gmail.com>:

CC: docs at python.org

I was planning to print the official python "2.7" tutorial: http://docs.python.org/tutorial/index.html.
So, I went over to Download page: http://docs.python.org/download.html and downloaded the PDF file. But the PDF have some missing text due to width of page being less than number of chars to put on a line.
For example, please have a look at page-21 (Section 3.1.3 titled "Unicode Strings"). It has an incomplete line from HTML documentation.
Here's a screenshot of what I see (and mean):
http://amberj.devio.us/pub/screenshots/pdfdoc.png

There's a line somewhere in the middle of screenshot which goes out of boundary of PDF document and fails to put out-of-boundary text on newline.
>From what I had read, it seems that this happens only with 'code snippets' in tutorial. This is probably a problem with convertor (HTML to PDF?).

Can you guys please fix it?
Thanks a lot.

----------
components: None
messages: 117614
nosy: amberj
priority: normal
severity: normal
status: open
title: PDF files of python docs have text missing
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9986>
_______________________________________

From report at bugs.python.org  Wed Sep 29 16:57:37 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 29 Sep 2010 14:57:37 +0000
Subject: [issue9978] test_os failures on XP-4 buildbot
In-Reply-To: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>
Message-ID: <1285772257.6.0.49009934184.issue9978@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I created the patch to fix this issue. WINFUNCTYPE is not member
of ctypes.wintypes, but ctypes.

----------
keywords: +patch
Added file: http://bugs.python.org/file19058/py3k_fix_test_os.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9978>
_______________________________________

From report at bugs.python.org  Wed Sep 29 16:59:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 29 Sep 2010 14:59:53 +0000
Subject: [issue9978] test_os failures on XP-4 buildbot
In-Reply-To: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>
Message-ID: <1285772393.03.0.0516458117754.issue9978@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I just checked in the importing changes to r85109 and r85110 (I saw your branch checkins happening at the same time, sorry).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9978>
_______________________________________

From report at bugs.python.org  Wed Sep 29 17:03:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 29 Sep 2010 15:03:41 +0000
Subject: [issue9978] test_os failures on XP-4 buildbot
In-Reply-To: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>
Message-ID: <1285772621.96.0.907434120685.issue9978@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Do you think we need the other parts of that patch? It seems like the only real issue here was the importing.

----------
resolution:  -> fixed
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9978>
_______________________________________

From report at bugs.python.org  Wed Sep 29 17:05:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 15:05:03 +0000
Subject: [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1285772703.03.0.927680247.issue9360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the latest patch in r85111.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9360>
_______________________________________

From report at bugs.python.org  Wed Sep 29 17:07:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Sep 2010 15:07:52 +0000
Subject: [issue9986] PDF files of python docs have text missing
In-Reply-To: <1285772054.59.0.857308007062.issue9986@psf.upfronthosting.co.za>
Message-ID: <1285772872.39.0.00884187965737.issue9986@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9986>
_______________________________________

From report at bugs.python.org  Wed Sep 29 17:15:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Sep 2010 15:15:05 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285773305.61.0.85802985782.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> The puzzling thing is that the same Python.dll when used by python.exe and not PyScripter produces correct results.

Yes, this is indeed puzzling.  Are you absolutely sure that both python.exe and PyScripter are using the exact same Python.dll file?  E.g., can you check that renaming/deleting/moving the Python.dll file to somewhere else causes both python.exe and PyScripter to fail to execute?

I really can't think of anything in the environment which might affect whether this bug occurs or not.

It's difficult to proceed here without a concrete way to reproduce the error.  I can (and will) add the particular bad values you found as new testcases, so that if the error is present on any of the buildbots it'll show up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 17:17:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Sep 2010 15:17:04 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285773424.45.0.932741330498.issue9980@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 17:22:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 15:22:11 +0000
Subject: [issue9963] test_sysconfig when LDFLAGS defined in the user's
	environment
In-Reply-To: <1285626395.1.0.70736928165.issue9963@psf.upfronthosting.co.za>
Message-ID: <1285773731.76.0.478611936742.issue9963@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks like a duplicate of #9437, and there's a patch you can review there :)

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> can't build extensions with non-default ldflags (e.g. -m32)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9963>
_______________________________________

From report at bugs.python.org  Wed Sep 29 17:22:12 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 29 Sep 2010 15:22:12 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285773732.0.0.883431767013.issue9980@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It's interesting to note that '9' is ascii 57, and ':' is 58. It's like the code is incrementing the wrong digit. If it's related to that, that indeed sounds like a compiler optimization bug to me, but of course I'm just guessing. And I'm not sure that conclusion matches the rest of the known facts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 17:32:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 29 Sep 2010 15:32:12 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285774332.18.0.411991259308.issue9980@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I get different results than Kiriakos' last example.


>PCbuild\amd64\python_d.exe
Python 3.2a2+ (py3k, Sep 29 2010, 09:43:42) [MSC v.1500 64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> '%.12g' % 38210.0
'38210'

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 17:43:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Sep 2010 15:43:37 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285775017.3.0.396797412537.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It's interesting to note that '9' is ascii 57, and ':' is 58.

Right;  it's that part that convinces me that the problem is somewhere deep in _Py_dg_dtoa, in the guts of the float to string conversion, where a xxx999999... result is rounded up to xx(x+1)000000... incorrectly.  And it seems at least possible that there's a compiler bug somewhere, since it's happened before.  It's also possible that there's a bug in _Py_dg_dtoa;  this seems fairly unlikely (but certainly not out of the question), since this bit is pretty much exactly David Gay's original code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 17:48:22 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 29 Sep 2010 15:48:22 +0000
Subject: [issue9978] test_os failures on XP-4 buildbot
In-Reply-To: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>
Message-ID: <1285775302.65.0.929128744299.issue9978@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Other parts are needed for my environment. If machine
is really slow, there is possibility of subprocess
being killed before execution reaches "wintypes.WINFUNCTYPE"
line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9978>
_______________________________________

From report at bugs.python.org  Wed Sep 29 18:00:25 2010
From: report at bugs.python.org (Matt Bond)
Date: Wed, 29 Sep 2010 16:00:25 +0000
Subject: [issue9621] Graphviz output for 2to3 fixer patterns
In-Reply-To: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za>
Message-ID: <1285776025.89.0.695214741197.issue9621@psf.upfronthosting.co.za>


Matt Bond <gmattbond at gmail.com> added the comment:

Huh. I must have diffed the wrong version of my code - how embarrassing!

I'll update the attached patch later this week. Thanks for catching that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9621>
_______________________________________

From report at bugs.python.org  Wed Sep 29 18:02:53 2010
From: report at bugs.python.org (Ludvig Ericson)
Date: Wed, 29 Sep 2010 16:02:53 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1285776173.35.0.661943320384.issue5672@psf.upfronthosting.co.za>


Ludvig Ericson <ludvig at lericson.se> added the comment:

I use the setproctitle module extensively. It has worked flawlessly.

What would be needed for this to get accepted? I realize one shouldn't stress such a decision, but still I feel this is something the standard library should be able to do.

My justification for inclusion into the standard library is that one has to make a workaround on systems where setproctitle ISN'T installed (I don't feel such a small component should be a requirement for production use.)

Everywhere I use setproctitle, I have to go:

    try:
        from setproctitle import setproctitle
    except ImportError:
        setproctitle = lambda t: None

Which is not only rather lengthy, but also IMO entirely unnecessary. As I noted, setting the process title is mostly for convenience and aesthetics, and therefore it's hard to justify the dependency. For that reason I think standard library inclusion is more relevant than otherwise.

So, are there any other reasons to wait with this other than the need of a PEP and proposing that to python-dev or whatever forum is best suited?

----------
nosy: +lericson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Wed Sep 29 18:07:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 16:07:13 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1285776433.6.0.144096042681.issue5672@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/issue5672>
_______________________________________

From report at bugs.python.org  Wed Sep 29 18:09:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 16:09:24 +0000
Subject: [issue9987] usenetrc option broken
In-Reply-To: <1285776563.1.0.517353919652.issue9987@psf.upfronthosting.co.za>
Message-ID: <1285776563.1.0.517353919652.issue9987@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The nntplib cleanup broke the "usenetrc" option to NNTP:


Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_nntplib.py", line 167, in setUp
    self.server = NNTP(self.NNTP_HOST, timeout=TIMEOUT)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/nntplib.py", line 937, in __init__
    readermode, usenetrc, timeout)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/nntplib.py", line 329, in __init__
    auth = credentials.authenticators(host)
NameError: global name 'host' is not defined

----------
assignee: pitrou
components: Library (Lib)
messages: 117627
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: usenetrc option broken
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9987>
_______________________________________

From report at bugs.python.org  Wed Sep 29 18:20:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 16:20:09 +0000
Subject: [issue9987] usenetrc option broken
In-Reply-To: <1285776563.1.0.517353919652.issue9987@psf.upfronthosting.co.za>
Message-ID: <1285777209.58.0.0245359328893.issue9987@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r85114.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9987>
_______________________________________

From report at bugs.python.org  Wed Sep 29 18:23:49 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Sep 2010 16:23:49 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1285777429.64.0.0601706061067.issue9437@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/issue9437>
_______________________________________

From report at bugs.python.org  Wed Sep 29 18:37:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 16:37:09 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za>
Message-ID: <1285778229.7.0.937562399388.issue9630@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited redecode_modules_path-4.patch as r85115 in Python 3.2.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Wed Sep 29 18:42:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 16:42:22 +0000
Subject: [issue9425] Rewrite import machinery to work with unicode paths
In-Reply-To: <1280448814.73.0.312881779361.issue9425@psf.upfronthosting.co.za>
Message-ID: <1285778542.93.0.927042472851.issue9425@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r85115 closes #9630: an important patch for #9425, redecode all filenames when setting the filesystem encoding.

Next tasks (maybe not in this order):
 - merge getpath.c
 - redecode argv[0] used by PySys_SetArgvEx() to feed sys.path (encode argv[0] with the locale encoding and then decode it using the filesystem encoding): it is required if PYTHONFSENCODING environment variable is used
 - merge import.c (in small patchs if it's possible)
 - and other things that I forgot

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9425>
_______________________________________

From report at bugs.python.org  Wed Sep 29 19:23:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 17:23:23 +0000
Subject: [issue9988] test_warnings fails with PYTHONFSENCODING=latin-1 on
	UNIX/BSD
In-Reply-To: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>
Message-ID: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

$ PYTHONFSENCODING=latin-1 ./python Lib/test/test_warnings.py 
...
======================================================================
FAIL: test_nonascii (__main__.CEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_warnings.py", line 731, in test_nonascii
    "['ignore:Deprecaci?nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcf3nWarning']" != b"['ignore:Deprecaci\xc3\xb3nWarning']"

======================================================================
FAIL: test_nonascii (__main__.PyEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_warnings.py", line 731, in test_nonascii
    "['ignore:Deprecaci?nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcf3nWarning']" != b"['ignore:Deprecaci\xc3\xb3nWarning']"

----------------------------------------------------------------------

The problem is that subprocess encodes PYTHONWARNINGS environment variable value with the filesystem encoding, whereas Py_main() decodes the variable value with the locale encoding.

History of how the variable is read in py3k:
 - #7301: r79880 creates this variable, use mbstowcs() and PySys_AddWarnOption()
 - #7301: r80066 uses setlocale(LC_ALL, ""), and replaces mbstowcs() by _Py_char2wchar() (to support surrogates)
 - #8589: r81358 creates PySys_AddWarnOptionUnicode() and replaces _Py_char2wchar() by PyUnicode_DecodeFSDefault()
 - #8589: r84694 replaces PyUnicode_DecodeFSDefault() by _Py_char2wchar() + PyUnicode_FromWideChar() "because the PyCodec machinery is not ready yet"
 - #8589: r84731 uses PyUnicode_FromString() (utf-8) on Mac OS X

----------
components: Tests, Unicode
messages: 117631
nosy: haypo
priority: normal
severity: normal
status: open
title: test_warnings fails with PYTHONFSENCODING=latin-1 on UNIX/BSD
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9988>
_______________________________________

From report at bugs.python.org  Wed Sep 29 19:30:54 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Sep 2010 17:30:54 +0000
Subject: [issue5131] pprint doesn't know how to print a defaultdict
In-Reply-To: <1233592442.21.0.0563262599933.issue5131@psf.upfronthosting.co.za>
Message-ID: <1285781454.8.0.0188897387932.issue5131@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>IMHO pprint should be able to make a decent job of all the built in types 

Agreed, already true as far as I know, and irrelevant. This issue is not about built-in types in the builtins module, as documented Lib Ref chapter 5 *Built-in Types*. Collections is an Python-coded stdlib  module that happens to import a couple of its classes from _collections, written in C for speed. 

I agree with Raymond that pprint needs a generic solution better than special-casing one class after another. Your idea of using ABCs intriguing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5131>
_______________________________________

From report at bugs.python.org  Wed Sep 29 19:32:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 17:32:39 +0000
Subject: [issue9647] os.confstr() does not handle value changing length
	between calls
In-Reply-To: <1282243493.08.0.1214343728.issue9647@psf.upfronthosting.co.za>
Message-ID: <1285781559.72.0.62593560462.issue9647@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If I understood correctly, you don't want the value to be truncated if the variable grows between the two calls to confstr(). Which behaviour would you expect? A Python exception?

> but Victor Stinner has expressed concern that a buggy
> confstr() could create a near-infinite loop with that patch
> applied

Yes, I think that two calls to confstr() should be enough.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9647>
_______________________________________

From report at bugs.python.org  Wed Sep 29 19:39:05 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 29 Sep 2010 17:39:05 +0000
Subject: [issue9630] Reencode filenames when setting the filesystem encoding
In-Reply-To: <201009291417.59634.victor.stinner@haypocalc.com>
Message-ID: <4CA379B3.8010300@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Le mercredi 29 septembre 2010 13:45:15, vous avez ?crit :
>> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>>
>> STINNER Victor wrote:
>>> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>>>
>>> Forget my previous message, I forgot important points.
>>>
>>>> So the only reason why you have to go through
>>>> all those hoops is to
>>>>
>>>> * allow the complete set of Python supported encoding
>>>>
>>>>   names for the PYTHONFSENCODING
>>>>
>>>> * make sure that the Py_FilesystemDefaultEncoding is set
>>>>
>>>>   to the actual name of the codec as used by the system
>>>
>>> Not only. As I wrote in my first message (msg114191), there are two
>>>
>>> other good reasons to keep the current code but redecode filenames:
>>>  * Encoding aliases: locale encoding is not always written as the
>>>  
>>>    official Python encoding name. Eg. utf8 vs UTF-8, iso8859-1 vs
>>>    latin_1, etc. We have to be able to load Lib/encodings/aliases.py to
>>>    to get the Python codec.
>>>  
>>>  * Codecs implemented in Python: only ascii, latin1, utf8 and mbcs
>>>  
>>>    codecs are builtin. All other encodings are implemented in Python. If
>>>    your filesystem encoding is ShiftJIS, you have to load
>>>    Lib/encodings/shift_jis.py to load the codec.
>>>
>>> For these two reasons, we have to import Python modules before being
>>> able to set the filesystem encoding. So we have to redecode filenames
>>> after setting the filesystem encodings.
>>
>> No, that's not needed ! Please see my earlier message: you can still
>> do all this at a later time during startup and double-check that
>> the encoding is indeed valid.
> 
> I don't understand how. Eg. if you set Py_FileSystemDefaultEncoding to 
> "cp1252" before loading the first module, import a module will have to load the 
> codec. Load the codec require to import a module. But how can you open cp1252 
> module since you are unable to encode paths to the filesystem encoding (because 
> the cp1252 codec is not available yet)?

Ah, sorry, I forgot about that important circular reference :-)

You're right: there's no way to guarantee that file and path
decoding will work without first setting the file system encoding
to one of the builin codec names (latin-1 would be a good choice).

The other option would be to import everything using relative
paths (since Python itself only uses ASCII path names to the modules),
until the codec is loaded and then add the absolute paths to
these relative ones, once the codec has been loaded successfully.

A third option is the one you mentioned earlier on: we simply
don't allow Python to be installed on paths that are not
decodable using one of the builtin codecs.

>> If the decoding fails during startup due to a wrong encoding of
>> file or path names, ...
> 
> It is not not problem described in my previous message. How do you load non-
> builtin codecs?
> 
> Can you write a patch implementing your ideas? I tried to write such patch 
> (set Py_FileSystemDefaultEncoding before loading the first module), but it 
> doesn't work for different reasons (all described in this issue). Maybe I 
> misunderstood your proposition.

No, I wasn't thinking of the situation where you want to use a
codec that requires a Python module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9630>
_______________________________________

From report at bugs.python.org  Wed Sep 29 19:56:40 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 29 Sep 2010 17:56:40 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1285783000.84.0.472736486819.issue9971@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Wed Sep 29 20:03:51 2010
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 29 Sep 2010 18:03:51 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1285783431.14.0.180526346114.issue1589@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

This appears to be a concern for some people. Maybe the builtin ssl module should be deprecated if there isn't a lot of manpower to maintain it and instead the well-maintained pyOpenSSL package should become the recommended tool?

Here is a letter that I just received, in my role as a developer of Tahoe-LAFS, from a concerned coder who doesn't know much about Python:

> An FYI on Python.
> 
> I'm not sure how businesses handle this (I've always worked in Windows
> shops), but I imagine some might consider pulling Python until it is
> properly secured. Pulling Python might affect Tahoe, which I would
> like to see do well.

Here is my reply to him:

> Thanks for the note warning me about this issue! I appreciate it.
> 
> The Tahoe-LAFS project doesn't use the builtin "ssl" module that comes
> with the Python Standard Library and instead uses the separate
> pyOpenSSL package (and uses the separate Twisted package for HTTP and
> other networking protocols). Therefore this isn't an issue for
> Tahoe-LAFS. I agree that it is potentially a "marketing" issue in that
> people might mistakenly think that Tahoe-LAFS is vulnerable or might,
> as you suggest, blacklist Python as such and thus hit Tahoe-LAFS as
> collateral damage. There's not much I can do about that from the
> perspective of a Tahoe-LAFS developer. From the perspective of 
> contributor to Python, I'm also not sure what to do, except perhaps to
> complain. :-) I guess I'll try to stir the waters a bit by suggesting
> that Python should deprecate the builtin "ssl" module and recommend
> the pyOpenSSL package instead.

----------
nosy: +zooko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 29 20:12:06 2010
From: report at bugs.python.org (Ryan Tucker)
Date: Wed, 29 Sep 2010 18:12:06 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1285783926.47.0.517305471611.issue1589@psf.upfronthosting.co.za>


Changes by Ryan Tucker <rtucker at gmail.com>:


----------
nosy: +Ryan.Tucker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 29 20:27:37 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 29 Sep 2010 18:27:37 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285784857.21.0.860616523022.issue9983@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/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 20:34:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 18:34:28 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1285783431.14.0.180526346114.issue1589@psf.upfronthosting.co.za>
Message-ID: <1285785261.3194.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Here is a letter that I just received, in my role as a developer of
> Tahoe-LAFS, from a concerned coder who doesn't know much about Python:
> 
> > An FYI on Python.
> > 
> > I'm not sure how businesses handle this (I've always worked in
> Windows
> > shops), but I imagine some might consider pulling Python until it is
> > properly secured. Pulling Python might affect Tahoe, which I would
> > like to see do well.

That sounds like an inventively outrageous kind of FUD. It's the first
time I hear of someone writing to third-party library authors in order
to pressure them to pressure the maintainers of a programming language
implementation to make some "decisions".

By the way, if "businesses" are really concerned about the security
problems induced by this issue, they can sponsor the effort to get the
bug fixed. It shouldn't be a lot of work.

> This appears to be a concern for some people. Maybe the builtin ssl
> module should be deprecated if there isn't a lot of manpower to
> maintain it and instead the well-maintained pyOpenSSL package should
> become the recommended tool?

Correct me if I'm wrong, but the "well-maintained pyOpenSSL package"
doesn't have the missing functionality (hostname checking in server
certificates), either. M2Crypto has it, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 29 20:34:54 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 29 Sep 2010 18:34:54 +0000
Subject: [issue9989] ctypes bitfield problem
In-Reply-To: <1285785294.07.0.231109223206.issue9989@psf.upfronthosting.co.za>
Message-ID: <1285785294.07.0.231109223206.issue9989@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The following program should print "0xdead" but instead prints "0x0".  This came from the following stackoverflow question:
http://stackoverflow.com/questions/3824617/python-structure-always-stuck-at-0-no-matter-what-value-you-assign-to-it

import ctypes
class Blah(ctypes.Structure):
    _fields_ = [("a", ctypes.c_uint64, 64),
                ("b", ctypes.c_uint16, 16),
                ("c", ctypes.c_uint8, 8),
                ("d", ctypes.c_uint8, 8)]

x = Blah(0xDEAD,0xBEEF,0x44,0x12)
print(hex(x.a))

----------
components: Library (Lib)
messages: 117637
nosy: stutzbach, theller
priority: normal
severity: normal
stage: unit test needed
status: open
title: ctypes bitfield problem
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9989>
_______________________________________

From report at bugs.python.org  Wed Sep 29 20:42:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Sep 2010 18:42:35 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285785755.61.0.383641989524.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Added the extra test cases (for py3k only) in r85119.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 20:42:55 2010
From: report at bugs.python.org (Devin Cook)
Date: Wed, 29 Sep 2010 18:42:55 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1285785775.01.0.823911189888.issue1589@psf.upfronthosting.co.za>


Devin Cook <devin.c.cook at gmail.com> added the comment:

> Correct me if I'm wrong, but the "well-maintained pyOpenSSL
> package" doesn't have the missing functionality (hostname
> checking in server certificates), either.

I'm pretty sure it's just a wrapper around the openssl library, which does not include it. That was Bill Janssen's argument for why the ssl module shouldn't do that verification. Well, that and the fact that there's no finalized standard for it yet. I believe this is the latest draft:
http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-09

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 29 20:45:35 2010
From: report at bugs.python.org (geremy condra)
Date: Wed, 29 Sep 2010 18:45:35 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1285785261.3194.12.camel@localhost.localdomain>
Message-ID: <AANLkTinGjkcgB6J0N8XTnVKhz-_WkVtGYFgGetm-GrmL@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Wed, Sep 29, 2010 at 11:34 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> Here is a letter that I just received, in my role as a developer of
>> Tahoe-LAFS, from a concerned coder who doesn't know much about Python:
>>
>> > An FYI on Python.
>> >
>> > I'm not sure how businesses handle this (I've always worked in
>> Windows
>> > shops), but I imagine some might consider pulling Python until it is
>> > properly secured. Pulling Python might affect Tahoe, which I would
>> > like to see do well.
>
> That sounds like an inventively outrageous kind of FUD. It's the first
> time I hear of someone writing to third-party library authors in order
> to pressure them to pressure the maintainers of a programming language
> implementation to make some "decisions".

Not to add fuel to the fire, but I've had a user report this behavior
as a bug as well, so this isn't entirely outside the scope of
plausibility to me.

> By the way, if "businesses" are really concerned about the security
> problems induced by this issue, they can sponsor the effort to get the
> bug fixed. It shouldn't be a lot of work.

What would the approximate cost on that be, do you think? My
understanding was that the code was pretty much written given John
Nagle's patch and M2Crypto.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 29 20:46:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 18:46:28 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1285785775.01.0.823911189888.issue1589@psf.upfronthosting.co.za>
Message-ID: <1285785983.3194.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Correct me if I'm wrong, but the "well-maintained pyOpenSSL
> > package" doesn't have the missing functionality (hostname
> > checking in server certificates), either.
> 
> I'm pretty sure it's just a wrapper around the openssl library, which
> does not include it. That was Bill Janssen's argument for why the ssl
> module shouldn't do that verification. Well, that and the fact that
> there's no finalized standard for it yet. I believe this is the latest
> draft:
> http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-09

Well, to be clear, it shouldn't be done *automatically*. But providing a
helper function that implements the feature and lets higher layers like
http.client and urllib.request call it if desired would be more than
reasonable.

(openssl may not provide such a function, but gnutls does, by the way)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 29 20:51:15 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 29 Sep 2010 18:51:15 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1285786275.66.0.62566101404.issue8879@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Now that I think of it, that behavior is expected. Hard links are *supposed* to be different directory entries, so they would come out of that function as-is, and the current tests are correctly implemented.

Uploaded to http://codereview.appspot.com/2290042

----------
Added file: http://bugs.python.org/file19059/issue8879_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Wed Sep 29 21:00:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 19:00:49 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <AANLkTinGjkcgB6J0N8XTnVKhz-_WkVtGYFgGetm-GrmL@mail.gmail.com>
Message-ID: <1285786845.3194.24.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What would the approximate cost on that be, do you think? My
> understanding was that the code was pretty much written given John
> Nagle's patch and M2Crypto.

To err on the safe side and account for integration work (unit tests,
coding style, and use in http.client / urllib), I would say a couple of
days. Also because it's rather boring code :-)

(but, don't assume that urllib will then be secure by default; Python
doesn't ship with CA certificates, so existing code will still need a
bit of work to activate cert validation and pass the location of the
system's CA certs)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 29 21:03:38 2010
From: report at bugs.python.org (Lenard Lindstrom)
Date: Wed, 29 Sep 2010 19:03:38 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom <len-l at telus.net>:

If an exporter returns a Py_buffer with ndim 1, PyMemoryView_FromObject changes the shape and strides pointer fields to point to a local Py_buffer array field. This array field is undocumented. Any heap memory these pointers reference is lost. Should the exporter's bf_releasebuffer later try and free the memory, the Python interpreter may segfault.

Attached is a demonstration program. Its output is:

Accessing buffer directly...
Accessing buffer through a memory view...
* View->shape has changed.
Done.

where the third line shows bf_releasebuffer has detected a changed pointer.

----------
components: Interpreter Core
files: bufrel.c.gz
messages: 117644
nosy: kermode
priority: normal
severity: normal
status: open
title: PyMemoryView_FromObject alters the Py_buffer after calling PyObject_GetBuffer when ndim 1
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file19060/bufrel.c.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Wed Sep 29 21:14:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Sep 2010 19:14:08 +0000
Subject: [issue9959] int(math.log(4,2)) == 1 instead of 2
In-Reply-To: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>
Message-ID: <1285787648.94.0.651606000534.issue9959@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied further tweaks in r85120:  for an integer n, log(n) is now computed as log(float(n)), provided only that n is small enough to be converted to a float without overflow.  This puts log on a more equal footing with all the other math module functions, and satisfies the (reasonable, IMO) expectation that log(n) == log(float(n)) for small integers n.

As a nice side-effect, this change guarantees that on a machine where log10 has reasonable accuracy (e.g., accurate to within 0.9 ulps or so), log10(10**n)==n for any nonnegative integer n such that 10**n is within the range of a double.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9959>
_______________________________________

From report at bugs.python.org  Wed Sep 29 21:18:31 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 29 Sep 2010 19:18:31 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285787911.42.0.182904982724.issue9980@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I can reproduce this using the internal (embedded python) of PyScripter
(nice work BTW!).

I can't reproduce it under any other circumstances. The test case
from #9215 runs fine in VS, and also this produces the correct output:


#include <Python.h>

int
main(int argc, char *argv[])
{
  Py_Initialize();
  PyRun_SimpleString("print str(38210.0)");
  Py_Finalize();
  return 0;
}


I ran all tests with the x86 release of 2.7.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 21:20:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 19:20:38 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1285788039.0.0.730011406976.issue9990@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou
nosy: +pitrou
stage:  -> needs patch
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Wed Sep 29 21:43:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 19:43:14 +0000
Subject: [issue9988] test_warnings fails with PYTHONFSENCODING=latin-1 on
	UNIX/BSD
In-Reply-To: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>
Message-ID: <1285789394.92.0.00971266233279.issue9988@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9988>
_______________________________________

From report at bugs.python.org  Wed Sep 29 22:12:15 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 20:12:15 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1285791135.87.0.616816429378.issue1589@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

imho it would be nice to be 'secure by default' in say the next python stable releases... (or perhaps only 3.X ? ).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 29 22:16:35 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Sep 2010 20:16:35 +0000
Subject: [issue9988] test_warnings fails with PYTHONFSENCODING=latin-1 on
	UNIX/BSD
In-Reply-To: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>
Message-ID: <1285791395.13.0.140553499738.issue9988@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, so who's messing up: subprocess or Py_main()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9988>
_______________________________________

From report at bugs.python.org  Wed Sep 29 22:20:51 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 29 Sep 2010 20:20:51 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285791651.56.0.410701285702.issue9980@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/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 22:25:11 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 29 Sep 2010 20:25:11 +0000
Subject: [issue9988] test_warnings fails with PYTHONFSENCODING=latin-1 on
	UNIX/BSD
In-Reply-To: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>
Message-ID: <1285791911.37.0.54314364839.issue9988@psf.upfronthosting.co.za>


Changes by Philip Jenvey <pjenvey at underboss.org>:


----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9988>
_______________________________________

From report at bugs.python.org  Wed Sep 29 22:26:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 29 Sep 2010 20:26:32 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285791992.13.0.189907405344.issue9983@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please don't say that "urllib does not perform any ssl validation". It certainly *does* perform ssl validation, namely it validates whether the payload received over ssl matches the certificate received from the server.

What it does not do is to validate the server certificate in any form (AFAIU).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 22:31:10 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 20:31:10 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285792270.43.0.898818387896.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

@loewis yes.. that is assumed imho.
This ticket is closed, is this a real issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 22:40:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 20:40:20 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285791992.13.0.189907405344.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285792813.3194.46.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What it does not do is to validate the server certificate in any form (AFAIU).

The warning I have added says ?When opening HTTPS (or FTPS) URLs, it is
not attempted to validate the server certificate.?
(see http://docs.python.org/library/urllib.html )

So I don't think we have a disagreement here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 22:46:43 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Sep 2010 20:46:43 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1285793203.12.0.938966098517.issue9969@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As per Antoine's comment on #9873, requiring a real string via isinstance(source, str) to trigger the string IO version is likely to be cleaner than attempting to duck-type this. Strings are an area where we make so many assumptions about the way their internals work that duck-typing generally isn't all that effective.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9969>
_______________________________________

From report at bugs.python.org  Wed Sep 29 22:49:12 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Sep 2010 20:49:12 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285793352.4.0.506496923742.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Agreed - I think there's a non-zero chance of triggering the str-path by mistake if we try to duck-type it (I just added a similar comment to #9969 regarding a possible convenience API for tokenisation)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Wed Sep 29 22:56:16 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Sep 2010 20:56:16 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285793776.22.0.133353653915.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Added to Reitveld: http://codereview.appspot.com/2318041/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Wed Sep 29 23:04:15 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Wed, 29 Sep 2010 21:04:15 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285794255.21.0.692506289532.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

Does _Py_dg_dtoa depend on FPU flags that affect rounding or exceptions?  I failed to mention that python is embedded in a Delphi executable.  Delphi uses the following code at initialization.

procedure       _FpuInit;
asm
        FNINIT
        FWAIT
{$IFDEF PIC}
        CALL    GetGOT
        MOV     EAX,[EAX].OFFSET Default8087CW
        FLDCW   [EAX]
{$ELSE}
        FLDCW   Default8087CW
{$ENDIF}
end;

  Default8087CW: Word = $1332;{ Default 8087 control word.  FPU control
                                register is set to this value.
                                CAUTION:  Setting this to an invalid value
                                could cause unpredictable behavior. }

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 23:13:05 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Wed, 29 Sep 2010 21:13:05 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285794785.71.0.95989950332.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

Let me that add that it is impossible to fully unit test for the correctness of the str(float).  I only found out by accident, because one of the users bumped into such a case.  I tried to find a pattern in the misbehaved cased and it was rather difficult.  Here is what I got but it is not conclusive

-  If the number has decimal points it prints correctly. Problems only occur with xxxxxx.0
-  More specifically they only occur with xxxxx1.0
-  Small numbers (less than 10000) print OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 23:15:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 29 Sep 2010 21:15:39 +0000
Subject: [issue9983] please add a large NOTE explaining that urllib does not
	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285794939.33.0.368774612269.issue9983@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Yes, the new text is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 23:42:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 21:42:47 +0000
Subject: [issue9988] test_warnings fails with PYTHONFSENCODING=latin-1 on
	UNIX/BSD
In-Reply-To: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>
Message-ID: <1285796567.6.0.194798496695.issue9988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> OK, so who's messing up: subprocess or Py_main()?

Well, this is the real question :-)

locale encoding is used to decode command line arguments (sys.argv), filesystem encoding is used to decode environment variables and to encode subprocess arguments and environment variables.

It means that we have something funny if a Python process creates a Python subprocess: child process arguments are encoded using the filesystem encoding, whereas the arguments are decoded using the locale encoding. If both encodings are different (eg. if PYTHONFSENCODING is used by at least the parent process), we have the bug similar to #4388. See also issue #8775.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9988>
_______________________________________

From report at bugs.python.org  Wed Sep 29 23:45:43 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Wed, 29 Sep 2010 21:45:43 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285796743.37.0.49344617649.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

OK problem solved!
If I set the FPU control word to $00xx I get the correct answers.  Now I think that if _Py_dg_dtoa depends on specific values for the FPU control word that is bad design and likely to lead to such problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 23:48:45 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 29 Sep 2010 21:48:45 +0000
Subject: [issue9988] test_warnings fails with PYTHONFSENCODING=latin-1 on
	UNIX/BSD
In-Reply-To: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>
Message-ID: <1285796925.47.0.917089846479.issue9988@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

It sounds like you had PYTHONWARNINGS using the fs encoding before r84694, but reverted it due to bootstrapping issues.

Indeed, the fs encoding isn't initialized until later in Py_InitializeEx. Maybe the PYTHONWARNINGS code should be moved there instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9988>
_______________________________________

From report at bugs.python.org  Wed Sep 29 23:55:58 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Sep 2010 21:55:58 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285797358.89.0.615919758335.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

One of Antoine's review comments made me realise I hadn't explicitly noted the "why not decode with latin-1?" rationale for the bytes handling. (It did come up in one or more of the myriad python-dev discussions on the topic, I just hadn't noted it here)

The primary reason for supporting ASCII compatible bytes directly is specifically to avoid the encoding and decoding overhead associated with the translation to unicode text. Making that overhead implicit rather than avoiding it altogether would be to quite miss the point of the API change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Wed Sep 29 23:56:49 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Wed, 29 Sep 2010 21:56:49 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285797409.96.0.541805055626.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

If _Py_dg_dtoa requires a specific FPU control word to work correctly, it should save its state, set it to the desired state and restore it after finishing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:00:15 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 29 Sep 2010 22:00:15 +0000
Subject: [issue9989] ctypes bitfield problem
In-Reply-To: <1285785294.07.0.231109223206.issue9989@psf.upfronthosting.co.za>
Message-ID: <1285797615.37.0.569535220092.issue9989@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

An endian issue? (i.e. on OS X, it works on ppc but not Intel)
A slightly more detailed test case:

$ more test_ctypes.py
import ctypes
class Blah2(ctypes.Structure):
    _fields_ = [("x", ctypes.c_uint64, 64),
                ("y", ctypes.c_uint64)]
val = 0x0123456789ABCDEF
x = Blah2(val, val)
print(Blah2.x)
print(hex(x.x))
print(Blah2.y)
print(hex(x.y))
$ arch -i386 python2.7 test_ctypes.py
<Field type=c_ulonglong, ofs=0:0, bits=64>
0x0L
<Field type=c_ulonglong, ofs=8, size=8>
0x123456789abcdefL
$ arch -x86_64 python2.7 test_ctypes.py
<Field type=c_ulong, ofs=0:0, bits=64>
0x0L
<Field type=c_ulong, ofs=8, size=8>
0x123456789abcdefL
$ arch -ppc python2.7 test_ctypes.py
<Field type=c_ulonglong, ofs=0:0, bits=64>
0x123456789abcdefL
<Field type=c_ulonglong, ofs=8, size=8>
0x123456789abcdefL

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9989>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:04:39 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 29 Sep 2010 22:04:39 +0000
Subject: [issue9989] ctypes bitfield problem
In-Reply-To: <1285785294.07.0.231109223206.issue9989@psf.upfronthosting.co.za>
Message-ID: <1285797879.72.0.630871217023.issue9989@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Could be.  FWIW, I had tested and observed the problem on a 32-bit Intel Windows box and 64-bit Intel Linux box.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9989>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:05:32 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 29 Sep 2010 22:05:32 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285797932.15.0.46804775459.issue9980@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree that in an ideal world there would not be a dependency on global flags.

There's no doubt a performance issue with doing so, although someone would have to measure that. It may well be swamped by the memory allocation, etc. that is going on at the same time and so won't matter.

Mark will no doubt know this better than I do, but I also assume that there's an issue with thread safety when changing such global state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:09:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 22:09:31 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1285797358.89.0.615919758335.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285798167.3194.56.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The primary reason for supporting ASCII compatible bytes directly is
> specifically to avoid the encoding and decoding overhead associated
> with the translation to unicode text.

I think it's quite misguided. latin1 encoding and decoding is blindingly
fast (on the order of 1GB/s. here). Unless you have multi-megabyte URLs,
you won't notice any overhead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:15:34 2010
From: report at bugs.python.org (Jonathan Niehof)
Date: Wed, 29 Sep 2010 22:15:34 +0000
Subject: [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>
Message-ID: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>


New submission from Jonathan Niehof <jniehof at lanl.gov>:

This has been reported before (#6494, #7987) and closed as "You need to build Python with SSL support." However, this error is raised even if ssl support is included.

The SSL check in xmlrpc.client for Python 3.1 is:
if not hasattr(socket, "ssl")
but ssl was removed from socket and into its own class for Py3k. So one workaround, provided ssl support is available:

import socket
if not hasattr(socket, 'ssl')
    socket.ssl = None
import xmlrpc.client

at which point everything works fine.

The attached patch fixes the bug, checking for ssl support based on the existence of http.client.HTTPSConnection, which is similar to the check in Python 2.7.

----------
components: Library (Lib)
files: xmlrpc_client_ssl_check.patch
keywords: patch
messages: 117667
nosy: jniehof
priority: normal
severity: normal
status: open
title: xmlrpc client ssl check faulty
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19061/xmlrpc_client_ssl_check.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9991>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:19:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 22:19:34 +0000
Subject: [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>
Message-ID: <1285798774.8.0.110487410702.issue9991@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9991>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:23:41 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Sep 2010 22:23:41 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1285798167.3194.56.camel@localhost.localdomain>
Message-ID: <AANLkTi=X08tqYbm8iSqf9UC22mObpeZtrUXpxjhGFQ3g@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

> I think it's quite misguided. latin1 encoding and decoding is blindingly
> fast (on the order of 1GB/s. here). Unless you have multi-megabyte URLs,
> you won't notice any overhead.

Ah, I didn't know that (although it makes sense now I think about it).
I'll start exploring ideas along those lines then. Having to name all
the literals as I do in the patch is really quite ugly.

A general sketch of such a strategy would be to stick the following
near the start of affected functions:

encode_result = not isinstance(url, str) # or whatever the main
parameter is called
if encode_result:
    url = url.decode('latin-1')
    # decode any other arguments that need it
    # Select the bytes versions of any relevant globals
else:
    # Select the str versions of any relevant globals

Then, at the end, do an encoding step. However, the encoding step may
get a little messy when it comes to the structured data types. For
that, I'll probably take a leaf out of the email6 book and create a
parallel bytes API, with appropriate encode/decode methods to
transform one into the other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:36:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 22:36:23 +0000
Subject: [issue9992] Command line arguments are not correctly decoded if
	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

On UNIX/BSD systems, Python decodes arguments with the locale encoding, whereas subprocess encodes arguments with the fileystem encoding. If both encodings are differents, we have a problem.

There was already the issue #4388 but it was closed because it was specific to old versions of Mac OS X. With the PYTHONFSENCODING environment variable (added to Python 3.2), it is easy to trigger this issue: run Python with a filesystem encoding different than the locale encoding. Attached script demonstrates the bug.

--

I see two possible encodings to encode and decode command line arguments (with surrogateescape error handler):

 (a) filesystem encoding
 (b) locale encoding

Decode Python command line arguments is one of the first operation executed when running Python, in the main() function. We don't have import machinery or codec API available at this moment. So I don't see how we can use the filesystem encoding here. Read issue #9630 to see how complex it is to use the filesystem encoding when initializing Python.

Use the locale encoding is easier because we already have _Py_char2wchar() and _Py_wchar2char() functions to decode/encode with the locale encoding and the surrogateescape error handler. These functions use the wchar_t* type which is less pratical than PyUnicodeObject*, but it is an advantage because wchar_t* type doesn't need Python to be completly initialized (whereas some PyUnicode methods loads modules, eg. encode and decode).

In #8775, I proposed to create a new variable to store the "command line encoding": sys.getcmdlineencoding(). But this issue was closed because there was only one use case: #4388 (which was closed but not fixed).

I don't know, or don't really care, how sys.getcmdlineencoding() should be initialized. The important point is that we have to use the same encoding to decode and encode command line arguments.

--

I don't really know if using another encoding is the right solution. The problem is maybe that the filesystem encoding should not be controlable by the user?

And what about environment variables: should we continue to encode and decode them with the filesystem encoding, or should we use the new "command line encoding"?

----------
components: Interpreter Core, Unicode
files: locale_fs_encoding.py
messages: 117669
nosy: haypo
priority: normal
severity: normal
status: open
title: Command line arguments are not correctly decoded if locale and fileystem encodings are different
versions: Python 3.2
Added file: http://bugs.python.org/file19062/locale_fs_encoding.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:48:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 22:48:55 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285800535.07.0.453227879878.issue9873@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't understand why you would like to implicitly convert bytes to str (which is one of the worse design choice of Python2). If you don't want to care about encodings, use bytes is fine. Decode bytes using an arbitrary encoding is the fastest way to mojibake.

So You have two choices: create new functions with bytes as input and output (like os.getcwd() and os.getcwdb()), or the output type will depend on the input type (solution choosen by os.path). Example of ther later:

>>> os.path.expanduser('~')
'/home/haypo'
>>> os.path.expanduser(b'~')
b'/home/haypo'

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:52:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 22:52:59 +0000
Subject: [issue9988] test_warnings fails with PYTHONFSENCODING=latin-1 on
	UNIX/BSD
In-Reply-To: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>
Message-ID: <1285800779.45.0.134474033325.issue9988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Indeed, the fs encoding isn't initialized until later in
> Py_InitializeEx. Maybe the PYTHONWARNINGS code should be moved 
> there instead?

sys.warnopts should be filled early because it is used to initialize the _warnings module, and the _warnings module have to be initialized before loading another non-builtin module because importing a module may emit a warning.

> OK, so who's messing up: subprocess or Py_main()?

I opened issue #9992 to decide which encoding should be used to encode and decode command line arguments: locale or filesystem encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9988>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:56:34 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Wed, 29 Sep 2010 22:56:34 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285800994.67.0.158038894934.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

Actually with control word $0032 or $3F I still do not get identical results to python.exe.

PyScripter
>>> '%.12g' % 38210.0
'38210.0009918'
>>> str(38210.0)
'38210.0009918'

Python
>>> '%.12g' % 38210.0
'38210'
>>> str(38210.0)
'38210.0'

Does anybody know what is the FPU control word should be to match the results of Python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:03:12 2010
From: report at bugs.python.org (Jonathan Niehof)
Date: Wed, 29 Sep 2010 23:03:12 +0000
Subject: [issue9993] shutil.move fails on symlink source
In-Reply-To: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>
Message-ID: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>


New submission from Jonathan Niehof <jniehof at lanl.gov>:

shutil.move does not behave as I expect when moving a symlink across filesystems. (This is when src itself is a symlink, not when it is a directory tree including symlinks.)

-If src is a symlink to file, rather than moving the symlink, it copies the contents of the file
-If src is a symlink to a directory, rather than moving the symlink, it copies the contents of the directory to a new directory
-If src is a dangling symlink, it errors out

Attached patch against the py3k branch adds tests for these cases and adds the expected behaviour, which is to recreate the symlink.

(I have encountered this on 2.6 - current SVN; it is probably in 2.5 as well but I have not confirmed.)

----------
components: Library (Lib)
files: shutil_move_symlinks.patch
keywords: patch
messages: 117673
nosy: jniehof
priority: normal
severity: normal
status: open
title: shutil.move fails on symlink source
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19063/shutil_move_symlinks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9993>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:10:23 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Wed, 29 Sep 2010 23:10:23 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285801823.36.0.754616366458.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

Also note that different compilers initialize the FPU control word with different values.  This creates a problem with embedded python that behaves differently or even produces wrong results depending on which language/compiler is used to embed it.  At least this is a documentation issue.  The expected value of the FPU control word should be documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:11:21 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 29 Sep 2010 23:11:21 +0000
Subject: [issue9992] Command line arguments are not correctly decoded if
	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1285801881.43.0.320205969814.issue9992@psf.upfronthosting.co.za>


Changes by Philip Jenvey <pjenvey at underboss.org>:


----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:26:41 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Wed, 29 Sep 2010 23:26:41 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285802801.3.0.974327957001.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

I found out that $x2xx (test both $12xx and $02xx) gives identical results to python.  Here is what it means.

The PC field (bits 9 and 8) or Precision Control determines to what precision the FPU rounds results after each arithmetic instruction in one of three ways:

00 = 24 bits (REAL4)
01 = Not used
10 = 53 bits (REAL8) <- This is required by _Py_dg_dtoa
11 = 64 bits (REAL10) (this is the initialized state) 

So contrary to my expectation it is not the rounding control bits but the Precision control bits that matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:41:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:41:52 +0000
Subject: [issue8680] Add a sandbox in Distutils2
In-Reply-To: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>
Message-ID: <1285803712.48.0.442711114009.issue8680@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8680>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:43:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:43:03 +0000
Subject: [issue5243] Missing dependency in distutils build
In-Reply-To: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
Message-ID: <1285803783.69.0.431877344765.issue5243@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5243>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:43:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:43:18 +0000
Subject: [issue6114] distutils build_ext path comparison only based on strings
In-Reply-To: <1243335359.03.0.865660639037.issue6114@psf.upfronthosting.co.za>
Message-ID: <1285803798.19.0.256456535934.issue6114@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6114>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:43:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:43:28 +0000
Subject: [issue9831] test_distutils fails on MacOSX 10.6
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1285803808.59.0.39255614163.issue9831@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:43:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:43:42 +0000
Subject: [issue901727] extra_path kwarg to setup() undocumented
Message-ID: <1285803822.24.0.585061008176.issue901727@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue901727>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:43:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:43:53 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1285803833.75.0.422110697993.issue6087@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:44:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:44:02 +0000
Subject: [issue9181] Solaris extension building does not work with 64 bit
	python
In-Reply-To: <1278429433.49.0.398235894568.issue9181@psf.upfronthosting.co.za>
Message-ID: <1285803842.79.0.867994318575.issue9181@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9181>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:44:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:44:43 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1285803883.63.0.783909206145.issue6011@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:45:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 23:45:59 +0000
Subject: [issue9992] Command line arguments are not correctly decoded if
	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1285803959.95.0.943974192019.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

[cmdline_encoding-2.patch] Patch to use locale encoding to decode and encode command line arguments. Remarks about the patch:

 - failing to get the locale encoding (very unlikely) is a fatal error
 - TODO: in initfsencoding(), Py_FileSystemDefaultEncoding should reuse Py_CommandLineEncoding instead of calling get_codeset() again
 - subprocess encodes arguments to the command line encoding for _posixsubprocess and Python implementations
 - _posixsubprocess doesn't support unicode command line arguments anymore

The patch is an updated version of the patch attached to #8775.

Using the patch, locale_fs_encoding.py test script pass.

----------
keywords: +patch
Added file: http://bugs.python.org/file19064/cmdline_encoding-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:46:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:46:21 +0000
Subject: [issue1887] distutils doesn't support out-of-source builds
In-Reply-To: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za>
Message-ID: <1285803981.13.0.475958105308.issue1887@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1887>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:46:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:46:55 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1285804015.01.0.131643917571.issue2200@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:47:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:47:02 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1285804022.97.0.148215691933.issue9561@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:47:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:47:26 +0000
Subject: [issue3621] it would be nice if installers made by bdist_wininst
	stored an EstimatedSize property in the Windows registry
In-Reply-To: <1219248850.4.0.277642755083.issue3621@psf.upfronthosting.co.za>
Message-ID: <1285804046.55.0.904281589822.issue3621@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3621>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:48:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:48:10 +0000
Subject: [issue5187] distutils upload should prompt for the user/password too
In-Reply-To: <1234128468.86.0.0554273106388.issue5187@psf.upfronthosting.co.za>
Message-ID: <1285804090.72.0.223926813949.issue5187@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5187>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:51:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:51:02 +0000
Subject: [issue1682403] Transform reST to styled text in
	bdist_wininst-produced installers
Message-ID: <1285804262.65.0.65452581536.issue1682403@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682403>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:51:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:51:16 +0000
Subject: [issue1109659] distutils argument parsing is bogus
Message-ID: <1285804276.78.0.444756596427.issue1109659@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1109659>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:51:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:51:32 +0000
Subject: [issue5309] setup.py doesn't parallelize extension module compilation
In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za>
Message-ID: <1285804292.72.0.749943927255.issue5309@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5309>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:53:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:53:51 +0000
Subject: [issue7894] too aggressive dependency tracking in distutils
In-Reply-To: <1265741724.72.0.383807580582.issue7894@psf.upfronthosting.co.za>
Message-ID: <1285804431.84.0.144147579286.issue7894@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7894>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:54:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:54:10 +0000
Subject: [issue4673] Distutils should provide an uninstall command
In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>
Message-ID: <1285804450.99.0.969935887228.issue4673@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4673>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:58:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:58:50 +0000
Subject: [issue5411] add xz compression support to distutils
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1285804730.46.0.169019776216.issue5411@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:58:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:58:56 +0000
Subject: [issue3992] remove custom log module from distutils2
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1285804736.48.0.490635692845.issue3992@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:59:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:59:37 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1285804777.75.0.81574994768.issue8933@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8933>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:59:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:59:46 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1285804786.54.0.367361950193.issue1222585@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:00:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:00:25 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1285804825.05.0.202698512472.issue7546@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7546>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:00:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:00:32 +0000
Subject: [issue8668] add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1285804832.29.0.250793220619.issue8668@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:01:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:01:04 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <1285804864.18.0.387285728707.issue9709@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9709>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:01:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:01:30 +0000
Subject: [issue1083299] Distutils doesn't pick up all the files it should.
Message-ID: <1285804890.1.0.300805586939.issue1083299@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083299>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:05:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:05:09 +0000
Subject: [issue1109658] distutils dry-run breaks when attempting to bytecompile
Message-ID: <1285805109.52.0.470878297456.issue1109658@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1109658>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:05:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:05:27 +0000
Subject: [issue8501] --dry-run option doesn't work
In-Reply-To: <1271972145.51.0.00309332974734.issue8501@psf.upfronthosting.co.za>
Message-ID: <1285805127.48.0.152709826031.issue8501@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8501>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:12:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Sep 2010 00:12:38 +0000
Subject: [issue9988] test_warnings fails with PYTHONFSENCODING=latin-1 on
	UNIX/BSD
In-Reply-To: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>
Message-ID: <1285805558.12.0.196482336167.issue9988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Maybe the PYTHONWARNINGS code should be moved there instead?

sys.warnoptions is read by the warnings module (not the _warnings module) when this module is loaded. The warnings module is loaded by Py_InitializeEx() if sys.warnoptions list is not empty.

It might be possible to read PYTHONWARNINGS env var after initfsencoding() but before loading the warnings module. But we have to ensure that Py_InitializeEx() can still be called multiple times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9988>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:12:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:12:54 +0000
Subject: [issue9309] Add environment variable complementing command line
	option -no-user-cfg
In-Reply-To: <1279574081.87.0.528312419657.issue9309@psf.upfronthosting.co.za>
Message-ID: <1285805574.87.0.158761848447.issue9309@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If someone creates a .pydistutils.cfg file with a prefix option, it means to me that they want distutils to respect it.  Can you explain to me why it?s always wrong to follow this option for Sage?

Assuming you?ve convinced us prefix is bad, why can?t you require that the power users who do set this option use --no-user-cfg?

I?m not friendly toward adding an envvar, since we removed the one we were using (DISTUTILS_DEBUG) in distutils2, but I can be convinced.  Tarek will also have a major vote.  Challenge! :)

----------
components:  -Distutils
versions: +3rd party -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9309>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:25:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:25:07 +0000
Subject: [issue9674] make install DESTDIR=/home/blah fails when the prefix
	specified is /
In-Reply-To: <1282677588.85.0.771807305266.issue9674@psf.upfronthosting.co.za>
Message-ID: <1285806307.04.0.844307635167.issue9674@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Re-adding distutils since we?re not sure the bug does not apply there.

aj, have you add time to test it?

----------
assignee:  -> tarek
components: +Distutils
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9674>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:25:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:25:31 +0000
Subject: [issue2942] mingw/cygwin do not accept asm file as extension source
In-Reply-To: <1211451880.92.0.894703588073.issue2942@psf.upfronthosting.co.za>
Message-ID: <1285806331.74.0.174926088143.issue2942@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2942>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:26:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:26:18 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1285806378.34.0.748169130887.issue1597850@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:26:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:26:28 +0000
Subject: [issue1294032] Distutils writes keywords comma-separated
Message-ID: <1285806388.85.0.427639592737.issue1294032@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294032>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:26:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:26:47 +0000
Subject: [issue1294032] Distutils writes keywords comma-separated
Message-ID: <1285806407.62.0.886471249234.issue1294032@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg102723

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294032>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:26:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:26:53 +0000
Subject: [issue1294032] Distutils writes keywords comma-separated
Message-ID: <1285806413.99.0.583785821923.issue1294032@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg114556

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294032>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:27:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:27:13 +0000
Subject: [issue1092365] Distutils needs a way *not* to install files
Message-ID: <1285806433.14.0.58707440866.issue1092365@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1092365>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:27:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:27:32 +0000
Subject: [issue1635363] Add command line help to windows unistall binary
Message-ID: <1285806452.71.0.841517243885.issue1635363@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1635363>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:30:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:30:06 +0000
Subject: [issue1382562] --install-base not honored on win32
Message-ID: <1285806606.62.0.343321356054.issue1382562@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1382562>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:30:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:30:54 +0000
Subject: [issue7694] DeprecationWarning from build_ext needs stacklevel
In-Reply-To: <1263401319.23.0.932890994142.issue7694@psf.upfronthosting.co.za>
Message-ID: <1285806654.32.0.998415516046.issue7694@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7694>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:34:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:34:51 +0000
Subject: =?utf-8?q?=5Bissue1011113=5D_Make_=E2=80=9Cinstall=E2=80=9D_find_the_buil?=
	=?utf-8?q?d=5Fbase_directory?=
Message-ID: <1285806891.06.0.473690618821.issue1011113@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1011113>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:35:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:35:04 +0000
Subject: [issue1052827] filelist.findall should not fail on dangling symlinks
Message-ID: <1285806904.93.0.976207818849.issue1052827@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1052827>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:36:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:36:03 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1285806963.67.0.636215386959.issue828450@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adding the ?easy? keyword to encourage someone to write a test.

----------
keywords: +easy
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:36:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:36:53 +0000
Subject: [issue793069] Add --remove-source option
Message-ID: <1285807013.18.0.362596008221.issue793069@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue793069>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:40:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:40:26 +0000
Subject: [issue9841] sysconfig and distutils.sysconfig differ in subtle ways
In-Reply-To: <1284333988.17.0.109581594915.issue9841@psf.upfronthosting.co.za>
Message-ID: <1285807226.49.0.829248435191.issue9841@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I understand.  This means that sysconfig fixes will have to be ported to distutils.sysconfig and d2/sysconfig.

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9841>
_______________________________________

From report at bugs.python.org  Thu Sep 30 02:52:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 00:52:51 +0000
Subject: [issue6860] Inconsistent naming of custom command in setup.py help
	output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1285807971.65.0.0411653790531.issue6860@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg102824

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6860>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:01:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:01:59 +0000
Subject: [issue6860] Inconsistent naming of custom command in setup.py help
	output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1285808519.0.0.645620245957.issue6860@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is a murky area, I?m not sure we have to refactor so much just to fix this bug.  Maybe it?s a doc bug: People have to define command_name if their command has a name that is different from the class name.  Maybe it?s a simple fix in the code for -h.  I?d like us to try this way first.

Improving the command registration system can be a feature request in another bug report targeted at distutils2.

----------
components: +Distutils -Distutils2
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6860>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:10:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:10:20 +0000
Subject: [issue870479] Scripts need platform-dependent handling
Message-ID: <1285809020.85.0.813692641766.issue870479@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> it's possible that the #! line processing may rely on \n line endings
It does.  Python on POSIX can import modules with CLRF, but the shebang machinery can?t parse the first line to get the interpreter to run.  Does anyone object about changing that?

Re: generating scripts, I?m moving from -0.5 to +0.  I think this requires a bit of summing up previous discussions (bug reports, emails, pros and cons here and there) so I won?t get to it for weeks or months, but someone else is free to do it.  I suggest opening a new feature request and linking to it from here.

----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue870479>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:17:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:17:26 +0000
Subject: [issue976869] Stripping script extensions with distutils
Message-ID: <1285809446.93.0.102684730378.issue976869@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Akira: Why require people to manually run this command instead of bundling it into distutils?  After all, install_scripts is just a cp, but distutils still does it :)

I wonder if this should be a built-in functionality like in Fred?s patch or an install hook shipped in a subpackage of distutils2, say contrib.hooks or ext.hooks.  Hooks have the nice properties of being small standalone pieces of functionality that are composable (think WSGI middleware), and this would also be a good hook example.

----------
keywords: +needs review
stage:  -> patch review
type:  -> feature request
versions: +3rd party -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue976869>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:18:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:18:32 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1285809512.29.0.903736002642.issue8591@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:21:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:21:09 +0000
Subject: [issue9395] clean does not remove all temp files
In-Reply-To: <1280311771.86.0.556150594835.issue9395@psf.upfronthosting.co.za>
Message-ID: <1285809669.72.0.786795189218.issue9395@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9395>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:23:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:23:24 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1285809804.76.0.389982117076.issue809163@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adding the ?easy? keyword so that a beginner or sprinter can find this and write a test.  Hint: Forget the part about RPM, write a test about inclusion of file with spaces in their name.

----------
keywords: +easy
versions: +3rd party, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:24:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:24:45 +0000
Subject: [issue8927] Handle version conflicts in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1285809885.67.0.398984789475.issue8927@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:33:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:33:11 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1285810391.93.0.600612381835.issue8254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Status update.

* configure works: it checks options (like install does) and writes to a file.

* New design for build: It uses set_undefined_options to get options from configure (previously it read the cache file, but this caused nasty issues; I?ll document those designs some day, it was instructional for me).  All tests pass.

* Same thing for install, but it?s harder to make it work.  install.finalize_options checks for conflicts (for example you can?t set --user and --prefix=x) and then fills all options (so prefix gets a value).  Now configure has the same checks, so that it does not write non-working options to the cache file.  The problem is that all options are set in configure.finalize_install_options and then passed to install with set_undefined_options, and then install.finalize_options shouts at you because you can?t set all options.  I tried a simple and stupid fix for that (disable option conflict check when options come from configure), which fixed all configure tests but caused test_core to fail.  This means that while the configure tests passed, they were only superficially working; I have to be suspicious to my own tests and out general test coverage.

----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:34:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:34:00 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1285810440.71.0.0243523888496.issue8254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(BTW I haven?t pushed the work in progress yet but I will shortly.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:34:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:34:13 +0000
Subject: [issue8253] add a resource+files section in setup.cfg
In-Reply-To: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>
Message-ID: <1285810453.66.0.211817577582.issue8253@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8253>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:34:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:34:32 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1285810472.14.0.516920811313.issue8252@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:35:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:35:42 +0000
Subject: [issue8908] friendly errors for UAC misbehavior in windows installers
In-Reply-To: <1275756301.53.0.564921810654.issue8908@psf.upfronthosting.co.za>
Message-ID: <1285810542.36.0.354484696029.issue8908@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you please tell if this still applies now that distutils has been reverted to its previous stable state?  Can you test with distutils2?  Thanks in advance.

----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8908>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:36:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:36:28 +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: <1285810588.87.0.101165123843.issue8876@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
type:  -> behavior
versions: +3rd party, Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8876>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:47:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:47:18 +0000
Subject: [issue8190] Add a PyPI XML-RPC client module
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1285811238.76.0.653761315818.issue8190@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

distutils2.index implements an XML-RPC client, a crawler for the so-called simple index and a wrapper for them.  A quick test showed that not all calls listed on the wiki page work now; Alexis, can you give us a status update?

----------
resolution:  -> accepted
stage: needs patch -> patch review
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:49:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:49:59 +0000
Subject: [issue4931] distutils does not show any error msg when can't build C
	module extensions due to a missing C compiler
In-Reply-To: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>
Message-ID: <1285811399.89.0.465428884895.issue4931@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I will commit this if Tarek does not do it shortly.

In distutils2, I?ll remove grok_environment_error wholly, since it exists for 1.5 compat only.

----------
assignee: tarek -> eric.araujo
keywords:  -needs review
stage:  -> patch review
type:  -> behavior
versions: +3rd party, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4931>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:50:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:50:40 +0000
Subject: [issue8679] write a distutils to distutils2 converter
In-Reply-To: <1273527573.05.0.844239277503.issue8679@psf.upfronthosting.co.za>
Message-ID: <1285811440.21.0.136708123331.issue8679@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8679>
_______________________________________

From report at bugs.python.org  Thu Sep 30 03:54:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 01:54:56 +0000
Subject: [issue8679] write a distutils to distutils2 converter
In-Reply-To: <1273527573.05.0.844239277503.issue8679@psf.upfronthosting.co.za>
Message-ID: <1285811696.09.0.217993444918.issue8679@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Now that we want d2 to use only a static configuration file, I think lib2to3 is not the right tool.  mkpkg (to be given a better name) should be able to convert an existing setup.py to a setup.cfg, and also create a setup.py from a setup.cfg.

----------
dependencies: +add a metadata section in setup.cfg, add a resource+files section in setup.cfg, update mkpkg to latest coding standards

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8679>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:01:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:01:56 +0000
Subject: [issue8255] step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1285812116.47.0.4770615862.issue8255@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Documentation
versions: +3rd party -Python 2.5, 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/issue8255>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:02:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:02:20 +0000
Subject: [issue8255] step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1285812140.89.0.813853295912.issue8255@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8255>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:03:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:03:41 +0000
Subject: [issue8274] test_run failing
In-Reply-To: <1270044707.08.0.0364512730756.issue8274@psf.upfronthosting.co.za>
Message-ID: <1285812221.85.0.505802738983.issue8274@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t get this failure.

----------
nosy: +eric.araujo
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8274>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:07:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:07:16 +0000
Subject: [issue8369] Add a lint command to distutils
In-Reply-To: <1270995426.89.0.712440512698.issue8369@psf.upfronthosting.co.za>
Message-ID: <1285812436.0.0.201008327626.issue8369@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There has been a lengthy discussion on the fellowship-of-the-packaging ML about what should or should not be a command.  One side argues that distutils commands should only concern themselves with packaging, distributing and installing, the other side defends that distutils, like a makefile, is a place to put useful functionality for developers.  test is in a gray area, lint even more.  I?ll ask for feedback on this later.

----------
resolution:  -> remind
versions: +3rd party -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8369>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:08:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:08:41 +0000
Subject: [issue6555] distutils config file should have the same name on both
	platforms and all scopes
In-Reply-To: <1248379635.87.0.00387112145543.issue6555@psf.upfronthosting.co.za>
Message-ID: <1285812521.85.0.924567240479.issue6555@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Re-adding distutils because of the $HOME vs. os.path.expanduser fix.

----------
components: +Distutils
versions: +3rd party, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6555>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:10:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:10:10 +0000
Subject: [issue5300] Distutils ignores file permissions
In-Reply-To: <1234907694.25.0.317480697226.issue5300@psf.upfronthosting.co.za>
Message-ID: <1285812610.22.0.740201543182.issue5300@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
stage:  -> unit test needed
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5300>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:10:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:10:56 +0000
Subject: [issue6466] duplicate get_version() code between cygwinccompiler and
	emxccompiler
In-Reply-To: <1247386841.98.0.269164765319.issue6466@psf.upfronthosting.co.za>
Message-ID: <1285812656.47.0.665876898832.issue6466@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> needs patch
versions: +3rd party -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6466>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:15:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:15:26 +0000
Subject: [issue8357] Add a --show-installation-paths in the install command
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1285812926.92.0.775207961003.issue8357@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8357>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:16:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:16:16 +0000
Subject: [issue1371826] distutils is silent about multiple -I/-L/-R
Message-ID: <1285812976.02.0.468817821001.issue1371826@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1371826>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:16:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:16:24 +0000
Subject: [issue1371826] distutils is silent about multiple -I/-L/-R
Message-ID: <1285812984.53.0.0381333023605.issue1371826@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg107248

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1371826>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:18:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:18:51 +0000
Subject: [issue1371826] distutils is silent about multiple -I/-L/-R
Message-ID: <1285813131.34.0.572822594682.issue1371826@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 on handling those options like gcc in distutils2.

+1 on printing warnings in distutils1, but I don?t know if it could break third-party code, so Tarek will accept or reject.

----------
components: +Distutils
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1371826>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:19:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:19:18 +0000
Subject: [issue5302] Allow package_data globs match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1285813158.35.0.215155375784.issue5302@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5302>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:19:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:19:35 +0000
Subject: [issue5302] Allow package_data globs match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1285813175.32.0.388025172914.issue5302@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg107422

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5302>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:19:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:19:42 +0000
Subject: [issue5302] Allow package_data globs match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1285813182.95.0.948519121032.issue5302@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg109658

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5302>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:22:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Sep 2010 02:22:03 +0000
Subject: [issue6466] duplicate get_version() code between cygwinccompiler and
	emxccompiler
In-Reply-To: <1247386841.98.0.269164765319.issue6466@psf.upfronthosting.co.za>
Message-ID: <1285813323.38.0.199097329311.issue6466@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/issue6466>
_______________________________________

From report at bugs.python.org  Thu Sep 30 04:23:11 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Sep 2010 02:23:11 +0000
Subject: [issue5302] Allow package_data globs match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1285813391.11.0.0763751494337.issue5302@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/issue5302>
_______________________________________

From report at bugs.python.org  Thu Sep 30 05:25:21 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Sep 2010 03:25:21 +0000
Subject: [issue9993] shutil.move fails on symlink source
In-Reply-To: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>
Message-ID: <1285817121.26.0.796916466831.issue9993@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +tarek
stage:  -> patch review
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9993>
_______________________________________

From report at bugs.python.org  Thu Sep 30 05:51:55 2010
From: report at bugs.python.org (Jon Anglin)
Date: Thu, 30 Sep 2010 03:51:55 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1285818715.07.0.122491065871.issue9784@psf.upfronthosting.co.za>


Jon Anglin <janglin at fortresgrand.com> added the comment:

I have uploaded another patch that replaces CRT API calls with Win32 API calls.  It compiles cleanly under 32 and 64 bit Windows. Is there a unit test for msilib? I was not able to find one, thus the patch is not fully tested.

----------
Added file: http://bugs.python.org/file19065/issue9784.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Thu Sep 30 06:13:22 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Thu, 30 Sep 2010 04:13:22 +0000
Subject: [issue8927] Handle version conflicts in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1285820002.36.0.270251677572.issue8927@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

I'm not sure the change of title you made is appropriate.  The case I described isn't a conflict, in the sense that there is a version of D that satisfies everybody's requirements.

Maybe the real title should be something like "exhaustively or comprehensively test dependency resolution."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Thu Sep 30 06:15:46 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Thu, 30 Sep 2010 04:15:46 +0000
Subject: [issue8927] Handle version conflicts in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1285820146.24.0.582981159379.issue8927@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

Oh, and http://distutils2.notmyidea.org/depgraph.html is a 404 for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8927>
_______________________________________

From report at bugs.python.org  Thu Sep 30 08:13:28 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 30 Sep 2010 06:13:28 +0000
Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100
In-Reply-To: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za>
Message-ID: <1285827208.72.0.750415145639.issue1491@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed and committed in revision 85125.

Actually, this changes the behavior of BaseHTTPServer a little and adds two new methods to the code, so I don't think, this should be back-ported to 2.7 and 3.1. If older code were to encounter the new 100 Continue response, then chances are that it may break.

I have added Misc/NEWS too.

BTW, there are tests for BaseHTTPServer in test_httpservers, thought it often gets overlooked. I merged the tests in the patch to that file.

I shall back-port some of the other tests which are useful.

Thanks!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491>
_______________________________________

From report at bugs.python.org  Thu Sep 30 09:01:37 2010
From: report at bugs.python.org (David)
Date: Thu, 30 Sep 2010 07:01:37 +0000
Subject: [issue9994] Python becoming orphaned over ssh
In-Reply-To: <1285830097.12.0.730062200867.issue9994@psf.upfronthosting.co.za>
Message-ID: <1285830097.12.0.730062200867.issue9994@psf.upfronthosting.co.za>


New submission from David <wizzardx at gmail.com>:

Hi, I mentioned this on the mailing list over here:

http://mail.python.org/pipermail/python-list/2010-September/1256407.html

I think it's a Python bug, so reposting it here:

-------------
Hi there, I have a strange situation.

If I do this:

1. Make a script /tmp/test.py on a remote server, with this contents:

#!/usr/bin/python
from subprocess import check_call
check_call(['ping', 'www.google.com'])

2. Call the script like this over SSH:

ssh root at testbox /tmp/test.py

3. Interrupt the script with Ctrl+C.

Then what happens:

The SSH session terminates, as expected.

However:

On the testing box, the Python script is still running, and so is the
ping session.

However, if I make an equivalent shell script, /tmp/test.sh, with this contents:

#!/bin/bash
ping www.google.com

And then run it over ssh like this:

ssh root at testbox /tmp/test.sh

And then hit Ctrl+C, then the shell script and ping are both
interrupted remotely, as expected.

Here is how 'pstree -p' looks for the python script on the test box,
before Ctrl+C:

<init (1) up here>
??sshd(1158)???sshd(19756)???test.py(19797)???ping(19798)
?            ??sshd(20233)???bash(20269)???pstree(19875)

And after Ctrl+C:

<init (1) up here>
??sshd(1158)???sshd(20233)???bash(20269)???pstree(20218)
??test.py(19797)???ping(19798)

Basically, the server-side sshd sub-process has disconnected, but the
Python script (and it's ping subprocess) have become orphaned, and now
belong to the init process.

Note, this only seems to happen if Python is executing a subprocess,
and only while Python is being run through a non-interactive ssh
session.

How can I make Python behave better? I want it to close down itself
and it's subprocess, and not orphan itself when I hit ctrl+C

PS:

The Python version on the testing box: 2.6.4, and the box itself is
running Ubuntu Karmic. Also, it's not just ping, but other utilities,
eg wget.

PPS:

I did also try adding logic to the python script, to keep an eye on
all the ppids (parent, grandparent, etc), and then to interrupt itself
and kill it's subprocess, but that doesn't seem to work: For whatever
reason, Python seems to be unable to kill it's subprocess in this
situation. The Python process closes, and ping becomes a child of
init. But I can then kill ping manually, from a separate ssh session.
-------------

I've seen this in both Python 2.6 and Python 3.1.

----------
components: Library (Lib)
messages: 117700
nosy: wizzardx
priority: normal
severity: normal
status: open
title: Python becoming orphaned over ssh
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9994>
_______________________________________

From report at bugs.python.org  Thu Sep 30 09:09:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Sep 2010 07:09:27 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285830567.52.0.662282059665.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Delphi uses the following code at initialization.

Yep.  That would explain the problem.  On x86 machines, Python's string-to-float and float-to-string conversions require that the x87 FPU has precision set to 53 bits rather than 64 bits (and also that the FPU rounding mode is round-half-to-even, but this rarely gets changed).

There's a configure-time check that works out whether resetting the precision is necessary;  if so, the precision is changed before each conversion and reverted again afterwards (see the _Py_SET_53BIT_PRECISION_START and _Py_SET_53BIT_PRECISION_END macros used in Python/pystrtod.c ).  It looks like you may need to override these macros for PyScripter.

Note that this isn't usually a problem on Windows:  the default setting on Windows is 53 bit precision;  I've no idea why Delphi changes it.  The main problem platform is 32-bit Linux, which uses 64-bit precision by default.  (And 64-bit Linux generally uses the appropriate SSE2 instructions instead of the x87; these are always 53-bit precision.)

So in general there's an issue if the runtime FPU settings don't match the configure-time FPU settings.  I'm not sure what the best mechanism for solving this is.  Checking the FPU state before *every* conversion would be possible, I guess, but it most cases that's unnecessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 09:16:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Sep 2010 07:16:00 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285830960.35.0.687512912632.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Eric]
> There's no doubt a performance issue with doing so, although someone
> would have to measure that. It may well be swamped by the memory
> allocation, etc. that is going on at the same time and so won't matter.

Yes, I think changing the FPU state involves a pipeline flush, with potentially serious performance impact.  But as you say, that may well be insignificant compared with everything else that's going on.

> Mark will no doubt know this better than I do, but I also assume that
> there's an issue with thread safety when changing such global state.

I don't *think* there's an issue here:  wouldn't FPU state be thread-local?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 09:35:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Sep 2010 07:35:06 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285832106.76.0.777261827802.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It looks like you may need to override these macros for PyScripter.

Stupid.  Of course, this isn't an option if you're using the existing Python dll directly.

For PyScripter, can you alter your Delphi layer to drop back to the normal default 53-bit precision before calling any Python stuff?  (Isn't there a SetPrecisionMode function?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 09:53:17 2010
From: report at bugs.python.org (Alexander Dreyer)
Date: Thu, 30 Sep 2010 07:53:17 +0000
Subject: [issue9309] Add environment variable complementing command line
	option -no-user-cfg
In-Reply-To: <1279574081.87.0.528312419657.issue9309@psf.upfronthosting.co.za>
Message-ID: <1285833197.49.0.157751547241.issue9309@psf.upfronthosting.co.za>


Alexander Dreyer <adreyer at gmx.de> added the comment:

The idea is, that an environment variable can be set globally by the master-build system or the packaging system. In contrary, the --no-user-cfg switch has to be added to the build description of each individial package. For strongly community-driven projects - like Sage - it is very likely, that this will be forgotten by some package maintainers. Since usually .pydistutils.cfg is not used in automated test environments this error will be detected, when a package is accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9309>
_______________________________________

From report at bugs.python.org  Thu Sep 30 09:55:22 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 30 Sep 2010 07:55:22 +0000
Subject: [issue9992] Command line arguments are not correctly decoded
	if	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <4CA44263.3090509@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner at haypocalc.com>:
> 
> On UNIX/BSD systems, Python decodes arguments with the locale encoding, whereas subprocess encodes arguments with the fileystem encoding. If both encodings are differents, we have a problem.
> 
> There was already the issue #4388 but it was closed because it was specific to old versions of Mac OS X. With the PYTHONFSENCODING environment variable (added to Python 3.2), it is easy to trigger this issue: run Python with a filesystem encoding different than the locale encoding. Attached script demonstrates the bug.
> 
> --
> 
> I see two possible encodings to encode and decode command line arguments (with surrogateescape error handler):
> 
>  (a) filesystem encoding
>  (b) locale encoding
> 
> Decode Python command line arguments is one of the first operation executed when running Python, in the main() function. We don't have import machinery or codec API available at this moment. So I don't see how we can use the filesystem encoding here. Read issue #9630 to see how complex it is to use the filesystem encoding when initializing Python.
> 
> Use the locale encoding is easier because we already have _Py_char2wchar() and _Py_wchar2char() functions to decode/encode with the locale encoding and the surrogateescape error handler. These functions use the wchar_t* type which is less pratical than PyUnicodeObject*, but it is an advantage because wchar_t* type doesn't need Python to be completly initialized (whereas some PyUnicode methods loads modules, eg. encode and decode).
> 
> In #8775, I proposed to create a new variable to store the "command line encoding": sys.getcmdlineencoding(). But this issue was closed because there was only one use case: #4388 (which was closed but not fixed).
> 
> I don't know, or don't really care, how sys.getcmdlineencoding() should be initialized. The important point is that we have to use the same encoding to decode and encode command line arguments.
> 
> --
> 
> I don't really know if using another encoding is the right solution. The problem is maybe that the filesystem encoding should not be controlable by the user?
> 
> And what about environment variables: should we continue to encode and decode them with the filesystem encoding, or should we use the new "command line encoding"?

The problem with command line arguments is that they don't necessarily
have just one encoding (just like env vars may well use more than
one encoding) on Unix platforms.

When using path and file names on the command line they will likely
use the file system encoding. When passing in configuration variables,
the arguments will likely use the current locale settings.

The use of wchar C lib functions is not ideal for parsing the
command line arguments, since this always uses the locale
settings.

Creating a copy as Python3 of argv is also not ideal,
since manipulating argv to change the OS process ps-output is
common on Unix, and there is currently no access (AFAIK) provided
to the original argv array passed to Python in Python3.

I think we should use a similar approach as the one for os.environ
here, where we keep the original bytes buffers around and have
a second copy with str objects which may not necessarily be
complete (e.g. when decoding a string fails).

Unfortunately, the use of wchar_t for command line arguments
has already spread throughout the code base, so I see little
chance of fixing this use.

What we could do, is at least make the original bytes version
of argv available to Python, so that decoding errors can be worked
around in the application (just like we have for os.environ with
os.environb).

----------
nosy: +lemburg
title: Command line arguments are not correctly decoded if locale and fileystem encodings are different -> Command line arguments are not correctly decoded if	locale and fileystem encodings are different

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Sep 30 10:03:07 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 30 Sep 2010 08:03:07 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285833787.36.0.596999547528.issue9962@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Hi Antoine,

BufferedIOBase is not documented to have peek():
http://docs.python.org/dev/py3k/library/io.html

Small note about patch:
1) IOError string says "read() on write-only...", should be "peek() on write-only..." ?
2) Should be min() in self._read(max(self.max_read_chunk, n))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9962>
_______________________________________

From report at bugs.python.org  Thu Sep 30 10:04:02 2010
From: report at bugs.python.org (Alexander Dreyer)
Date: Thu, 30 Sep 2010 08:04:02 +0000
Subject: [issue9309] Add environment variable complementing command line
	option -no-user-cfg
In-Reply-To: <1279574081.87.0.528312419657.issue9309@psf.upfronthosting.co.za>
Message-ID: <1285833842.88.0.428129062501.issue9309@psf.upfronthosting.co.za>


Alexander Dreyer <adreyer at gmx.de> added the comment:

Of course, I mean: The error will *not* be detected...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9309>
_______________________________________

From report at bugs.python.org  Thu Sep 30 10:28:34 2010
From: report at bugs.python.org (Michael Brickenstein)
Date: Thu, 30 Sep 2010 08:28:34 +0000
Subject: [issue9309] Add environment variable complementing command line
	option -no-user-cfg
In-Reply-To: <1279574081.87.0.528312419657.issue9309@psf.upfronthosting.co.za>
Message-ID: <1285835314.37.0.52861440714.issue9309@psf.upfronthosting.co.za>


Michael Brickenstein <brickenstein at mfo.de> added the comment:

Actually, Sage acts in a similar way like virtualenvs do.
In fact, config files are also a problem for virtualenv, see second red box here:

http://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox

cite:
---
Virtualenv is currently incompatible with distutils.cfg and ~/.pydistutils.cfg. If you have either of these files, virtualenv will put easy_install into the bin directory specified in the config file, rather than into the virtualenv where it belongs.

----------
nosy: +Michael.Brickenstein

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9309>
_______________________________________

From report at bugs.python.org  Thu Sep 30 10:57:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Sep 2010 08:57:02 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif	locale
	and fileystem encodings aredifferent
In-Reply-To: <4CA44263.3090509@egenix.com>
Message-ID: <201009301056.53095.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The problem with command line arguments is that they don't necessarily
> have just one encoding (just like env vars may well use more than
> one encoding) on Unix platforms.

The issue #8776 proposes the creation of sys.argv.

> When using path and file names on the command line they will likely
> use the file system encoding. When passing in configuration variables,
> the arguments will likely use the current locale settings.

Ok, and? We have to pick up one and use it. We cannot guess the encoding of 
each argument, nor change sys.argv to use bytes. (And the creation sys.argvb 
will not solve this issue.)

I still think that using the filesystem encoding is not possible for technical 
reasons (it might be possible, but it will be very hard), whereas I attached a 
working patch to use the locale encoding.

----------
title: Command line arguments are not correctly decoded if	locale and fileystem encodings are different -> Command line arguments are not correctly decodedif	locale and fileystem encodings aredifferent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Sep 30 11:01:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 09:01:35 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1285837295.94.0.599580705511.issue9968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Do you want to work on a patch?

----------
components: +Library (Lib) -Extension Modules
nosy: +eric.araujo, orsenthil
stage:  -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Thu Sep 30 11:02:05 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 30 Sep 2010 09:02:05 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif
	locale	and fileystem encodings aredifferent
In-Reply-To: <201009301056.53095.victor.stinner@haypocalc.com>
Message-ID: <4CA45209.2020706@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> The problem with command line arguments is that they don't necessarily
>> have just one encoding (just like env vars may well use more than
>> one encoding) on Unix platforms.
> 
> The issue #8776 proposes the creation of sys.argv.

Right, I think you meant sys.argvb and yes, I think it's a good idea.

>> When using path and file names on the command line they will likely
>> use the file system encoding. When passing in configuration variables,
>> the arguments will likely use the current locale settings.
> 
> Ok, and? We have to pick up one and use it. We cannot guess the encoding of 
> each argument, nor change sys.argv to use bytes. (And the creation sys.argvb 
> will not solve this issue.)

Sure and using the locale setting is fine. The point is that we pick
one, but keep the original data around for the application to use in
case it knows better, so this will solve the problem.

> I still think that using the filesystem encoding is not possible for technical 
> reasons (it might be possible, but it will be very hard), whereas I attached a 
> working patch to use the locale encoding.

----------
title: Command line arguments are not correctly decodedif	locale and fileystem encodings aredifferent -> Command line arguments are not correctly decodedif locale	and fileystem encodings aredifferent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Sep 30 11:04:43 2010
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 30 Sep 2010 09:04:43 +0000
Subject: [issue2972] arguments and default path not set in site.py and
	sitecustomize.py
In-Reply-To: <1211818636.32.0.584139114136.issue2972@psf.upfronthosting.co.za>
Message-ID: <1285837483.98.0.680914015539.issue2972@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

Thanks for the tips, looks like we have the basis for a solid workaround here. Perhaps that could be encapsulated and added as sys.raw_argv or something in future?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2972>
_______________________________________

From report at bugs.python.org  Thu Sep 30 11:27:22 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 30 Sep 2010 09:27:22 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

That's very annoying that distutils asks to save your pass when uploading to PyPI, but refuses to upload if you refuse. So you end up with storing your password in cleartext.

Try the next command to see what I mean:

setup.py register sdist upload

----------
assignee: tarek
components: Distutils
messages: 117713
nosy: eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: "setup.py register sdist upload" requires pass to be saved
type: security
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9995>
_______________________________________

From report at bugs.python.org  Thu Sep 30 11:54:27 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 30 Sep 2010 09:54:27 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285840467.89.0.163007382103.issue9980@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I wonder if calling _Py_SET_53BIT_PRECISION_START/_Py_SET_53BIT_PRECISION_END 
every time will have any measurable effect on performance.  First, string
conversions have a lot of overhead already. Then, for compilers that already
set the correct control word, only fnstcw is called. 


Attached is a quick and dirty benchmark. The correct state is set at
the start of the program. The first loop does not change the FPU state,
the second one uses the macros, the third one always sets/restores. 


time:                   0.000000    result: 1.90013e+122
time (fnstcw):          0.570000    result: 1.90013e+122
time (fnstcw/fldcw):    2.560000    result: 1.90013e+122



I would feel more comfortable if the correct FPU state is guaranteed.

----------
Added file: http://bugs.python.org/file19066/fpuspeed.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 12:02:55 2010
From: report at bugs.python.org (Tim Golden)
Date: Thu, 30 Sep 2010 10:02:55 +0000
Subject: [issue2972] arguments and default path not set in site.py and
	sitecustomize.py
In-Reply-To: <1211818636.32.0.584139114136.issue2972@psf.upfronthosting.co.za>
Message-ID: <1285840975.73.0.0844423130219.issue2972@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

Suggest you raise a separate feature-request issue for that, Geoff, perhaps offering the two implementations described. Perhaps raise it it on python-ideas first to gauge reactions. I'm +0 myself since it's so easy to do anyway and I don't know how common a requirement it would be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2972>
_______________________________________

From report at bugs.python.org  Thu Sep 30 12:43:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Sep 2010 10:43:18 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif
	locale	and fileystem encodings aredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1285843398.78.0.158280849116.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Extract of an interesting message (msg111432) of #8775 (issue specific to Mac OS X):

<< A system where the filesystem encoding doesn't match the locale encoding is hard to get right. While it would be possible to add sys.cmdlineencoding that doesn't actually solve the semantic problem because external tools might not cooperate.

That is, most system tools seem to work with bytes internally and do not treat arguments as text encoded in the locale encoding that should be re-encoded in the filesystem encoding before passing them to the C APIs.

That is, when calling "ls somefile" the "ls" command will pass the bytes in argv[1] to the POSIX routines for getting file information without trying to reencode. >>

----------
nosy: +loewis, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Sep 30 12:53:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Sep 2010 10:53:39 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif
	locale	and fileystem encodings aredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1285844019.95.0.710761152673.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> A system where the filesystem encoding doesn't match the locale
> encoding is hard to get right.

Mmmh. The problem is maybe that the new PYTHONFSENCODING environment variable (added by #8622) introduced an horrible inconstency between Python and other applications. Other applications ignore PYTHONFSENCODING.

The simplest solution to fix this issue is to remove PYTHONFSENCODING variable. In this case, the user have to set LANG, LC_ALL or LC_CTYPE, instead of PYTHONFSENCODING, to set Python filesystem encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Sep 30 12:54:33 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 30 Sep 2010 10:54:33 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285844073.12.0.815861367924.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

>From a function *user* perspective, the latter API (bytes->bytes, str->str) is exactly what I'm doing.

Antoine's point is that there are two ways to achieve that:

Option 1 (what my patch currently does):
- provide bytes and str variants of all constants
- choose which set to use at the start of each function
- be careful never to index, only slice (even for single characters)
- a few other traps that I don't remember off the top of my head

Option 2 (the alternative Antoine suggested and I'm considering):
- "decode" the ASCII compatible bytes to str objects by treating them as nominally latin-1
- use the same str-based constants as are used to handle actual str inputs
- be able to index to your heart's content inside the algorithm
- *ensure* that any bytes-as-pseudo-str objects are "encoded" back to actual bytes before they are returned

>From outside the function, a user shouldn't be able to tell which approach we're using internally.

The nice thing about option 2 is to make sure you're doing it correctly, you only need to check three kinds of location:
- the initial parameter handling in each function
- any return statements, raise statements that allow a value to leave the function
- any yield expressions (both input and output)

The effects of option 1 are scattered all over your algorithms, so it's hard to be sure you've caught everything.

The downside of option 2 is if you make a mistake and let your bytes-as-pseudo-str objects escape from the confines of your function, you're going to see some very strange behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 30 12:59:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Sep 2010 10:59:31 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285844371.34.0.555090920821.issue9873@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Option 2 (the alternative Antoine suggested and I'm considering):
> - "decode" ... to str ...
> - ... objects are "encoded" back to actual bytes before 
>   they are returned

In this case, you have to be very careful to not mix str and bytes decoded to str using a pseudo-encoding. Dummy example: urljoin('unicode', b'bytes') should raise an error.

I don't care of the internals if you write tests to ensure that it is not possible to mix str and bytes with the public API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 30 13:07:12 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 30 Sep 2010 11:07:12 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285844832.57.0.987060669081.issue9980@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I benchmarked _PyOS_ascii_strtod without the macros, with the macros
and with always calling both fnstcw/fldcw. There is no real difference:


import timeit

s = "str(38210.0)"
t = timeit.Timer(stmt=s)

t.timeit(number=10000000)
t.timeit(number=10000000)
t.timeit(number=10000000)

# None
>>> t.timeit(number=10000000)
3.7519991397857666
>>> t.timeit(number=10000000)
3.759944200515747
>>> t.timeit(number=10000000)
3.7730538845062256
>>>

# Macros
>>> t.timeit(number=10000000)
3.780745029449463
>>> t.timeit(number=10000000)
3.777444839477539
>>> t.timeit(number=10000000)
3.7622230052948

# fnstcw/fldcw
>>> t.timeit(number=10000000)
3.765655994415283
>>> t.timeit(number=10000000)
3.7517099380493164
>>> t.timeit(number=10000000)
3.749257802963257

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 13:11:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Sep 2010 11:11:52 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285845112.87.0.235224460633.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the numbers, Stefan.

What about in the reverse direction (string to float)?  I don't expect any real difference there, either, but it would be good to check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 13:12:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Sep 2010 11:12:18 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285845138.97.0.210600866172.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Whoops;  that *was* string to float.  How about float to string?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 13:15:50 2010
From: report at bugs.python.org (Ole Laursen)
Date: Thu, 30 Sep 2010 11:15:50 +0000
Subject: [issue1580] Use shorter float repr when possible
In-Reply-To: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>
Message-ID: <1285845350.99.0.930196032119.issue1580@psf.upfronthosting.co.za>


Ole Laursen <olau at iola.dk> added the comment:

Just came across this bug, I don't want to reopen this or anything, but regarding the SSE2 code I couldn't help thinking that why can't you just detect the presence of SSE2 when the interpreter starts up and then switch implementations based on that? I think that's what liboil does (http://liboil.freedesktop.org/wiki/).

----------
nosy: +olau

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________

From report at bugs.python.org  Thu Sep 30 13:40:49 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 30 Sep 2010 11:40:49 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285846849.68.0.578267493387.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, the general implementation concept I'm thinking of going with for option 2 will use a few helper functions:

url, coerced_to_str = _coerce_to_str(url)
if coerced_to_str:
    param = _force_to_str(param) # as appropriate
...
return _undo_coercion(result, coerced_to_str)

The first helper function standardises the typecheck, the second one complains if it is given something that is already a string.

The last one just standardises the check to see if the coercion needs to be undone, and actually undoing the coercion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 30 13:49:18 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 30 Sep 2010 11:49:18 +0000
Subject: [issue976869] Stripping script extensions with distutils
Message-ID: <1285847358.96.0.784617102118.issue976869@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

At this point, I'm more in favor of adopting something closer to the setuptools scripts based on "console_scripts" entry points, and dropping old-style scripts entirely (most *because* of the issues I mentioned at the start).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue976869>
_______________________________________

From report at bugs.python.org  Thu Sep 30 13:56:07 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 30 Sep 2010 11:56:07 +0000
Subject: [issue870479] Scripts need platform-dependent handling
Message-ID: <1285847767.67.0.17755803563.issue870479@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

As noted in issue 976869, I'm very much in the camp of entry-point based generated scripts, which should clearly use the right line endings for the host platform.

Hacking around with the file copy just doesn't make sense moving forward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue870479>
_______________________________________

From report at bugs.python.org  Thu Sep 30 13:57:36 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 30 Sep 2010 11:57:36 +0000
Subject: [issue9873] Allow bytes in some APIs that use string literals
	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1285847856.67.0.55014722418.issue9873@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 30 14:03:28 2010
From: report at bugs.python.org (Arnon Yaari)
Date: Thu, 30 Sep 2010 12:03:28 +0000
Subject: [issue9996] binascii should convert unicode strings
In-Reply-To: <1285848203.41.0.985893389249.issue9996@psf.upfronthosting.co.za>
Message-ID: <1285848203.41.0.985893389249.issue9996@psf.upfronthosting.co.za>


New submission from Arnon Yaari <wiggin15 at gmail.com>:

binascii is currently bytes-only, although the "a" in a2b\b2a should refer to unicode strings.
This patch fixes all a2b functions to take str type and all b2a functions to return str types.
This was discussed several times, for example:
http://www.gossamer-threads.com/lists/python/dev/863892
http://bugs.python.org/issue4770#msg78475
As discussed, the required behavior in Python 3k is that a2b should convert str to bytes and vice versa, and this was implemented in this patch.

This patch breaks backward compatibility in several functions... It also required fixing several files under Lib (although most cases were simplified), and also to change the interface of the base64 and quopri modules (this was also requested, e.g. http://bugs.python.org/issue4769).
Note that there already was a small change in this behavior from 3.1 to 3.2 (http://bugs.python.org/issue4770) - b2a_hex and b2a_qp COULD receive strings as input in 3.1 and this was changed in 3.2, so technically, compatibility was already broken...

The patch includes updates to the standard library, the tests and documentation.
rlecode and rledecode were left untouched because they are not a2b\b2a functions per se - they work on the input and output of the hqx functions (maybe it's a good idea to add new a2b\b2a functions for rle_hqx).

Any thoughts are welcome.

----------
components: Interpreter Core
files: binascii.diff
keywords: patch
messages: 117727
nosy: wiggin15
priority: normal
severity: normal
status: open
title: binascii should convert unicode strings
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19067/binascii.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9996>
_______________________________________

From report at bugs.python.org  Thu Sep 30 14:04:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Sep 2010 12:04:15 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285848255.44.0.518693216551.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I would feel more comfortable if the correct FPU state is guaranteed.

I agree, in principle.  In practice there are some thorny issues to deal with, and things to think about:

(1) The method for getting and setting the FPU precision varies from platform to platform

(2) Most modern x86 processors have *two* FPUs that might be used (the SSE unit, and the x87), each with their own control words.

(3) Depending on the platform and compiler flags, a Python executable / shared library might be using the x87 instructions, the SSE2 instructions, or a mixture of both.

(4) We need to bear in mind that an executable created on a modern 32-bit Linux machine (with SSE2) might still need to run on older machines that don't have SSE2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 14:11:36 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 30 Sep 2010 12:11:36 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285845138.97.0.210600866172.issue9980@psf.upfronthosting.co.za>
Message-ID: <20100930121056.GA6610@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark Dickinson <report at bugs.python.org> wrote:
> Whoops;  that *was* string to float.  How about float to string?

These are the results for format_float_short. The first one is quite funny:

If the control word is left as is (64-bit prec on Linux), _Py_dg_dtoa
apparently requires more iterations (but still produces the correct
result in this case).

import timeit

s = "str(38210.0)"
t = timeit.Timer(stmt=s)

4.266580820083618
>>> t.timeit(number=10000000)
4.3112568855285645
>>> t.timeit(number=10000000)
4.313380002975464
>>>

3.7413151264190674
>>> t.timeit(number=10000000)
3.7296619415283203
>>> t.timeit(number=10000000)
3.737776041030884

3.756165027618408
>>> t.timeit(number=10000000)
3.775428056716919
>>> t.timeit(number=10000000)
3.775447130203247

In general, execution times for _Py_dg_dtoa vary quite a bit depending on
the number that is converted:

5.097490072250366

2.417008876800537

Judging from these numbers, I think the macros could be called by default without
any real effect on performance. How about setting the rounding mode as well (you
suggested that in #9009)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 14:14:28 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 30 Sep 2010 12:14:28 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285848868.6.0.695743029598.issue9980@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The tracker swallowed some parts of my mail:

In general, execution times for _Py_dg_dtoa vary quite a bit depending on
the number that is converted:

>>> s = "str(1.00000000000000005e300)"
>>> t = timeit.Timer(stmt=s)
>>> t.timeit(number=10000000)
5.097490072250366

>>> s = "str(1.00000000000000005e384)"
>>> t = timeit.Timer(stmt=s)
>>> t.timeit(number=10000000)
2.417008876800537

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 14:17:41 2010
From: report at bugs.python.org (Ivo van der Wijk)
Date: Thu, 30 Sep 2010 12:17:41 +0000
Subject: [issue9997] function named 'top' gets unexpected namespace/scope
	behaviour
In-Reply-To: <1285849061.79.0.383989167237.issue9997@psf.upfronthosting.co.za>
Message-ID: <1285849061.79.0.383989167237.issue9997@psf.upfronthosting.co.za>


New submission from Ivo van der Wijk <python.org at in.m3r.nl>:

This issue is also discussed on Stackoverflow: http://stackoverflow.com/q/3828611/320057

The following code

def top(deck):
    pass

def b():
    global deck

results in the error "SyntaxError: name 'deck' is local and global" (slightly different for 3.x). This is strange by itself, and is caused by special namespace behaviour attached to the "top" symbol. Renaming the "top" function actually solves the error!

More technical details are in the stackoverflow link above.

----------
components: Interpreter Core
messages: 117731
nosy: iivvoo
priority: normal
severity: normal
status: open
title: function named 'top' gets unexpected namespace/scope behaviour
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/issue9997>
_______________________________________

From report at bugs.python.org  Thu Sep 30 15:20:33 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Thu, 30 Sep 2010 13:20:33 +0000
Subject: [issue9997] function named 'top' gets unexpected namespace/scope
	behaviour
In-Reply-To: <1285849061.79.0.383989167237.issue9997@psf.upfronthosting.co.za>
Message-ID: <1285852833.47.0.819198507173.issue9997@psf.upfronthosting.co.za>


Jeremy Hylton <jhylton at gmail.com> added the comment:

Let me fix that.

----------
nosy: +Jeremy.Hylton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9997>
_______________________________________

From report at bugs.python.org  Thu Sep 30 15:21:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Sep 2010 13:21:33 +0000
Subject: [issue9994] Python becoming orphaned over ssh
In-Reply-To: <1285830097.12.0.730062200867.issue9994@psf.upfronthosting.co.za>
Message-ID: <1285852893.63.0.0964183359613.issue9994@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9994>
_______________________________________

From report at bugs.python.org  Thu Sep 30 15:35:09 2010
From: report at bugs.python.org (v_peter)
Date: Thu, 30 Sep 2010 13:35:09 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1285853709.37.0.246952217989.issue9042@psf.upfronthosting.co.za>


v_peter <leanmeandonothingmachine at gmail.com> added the comment:

Which branches should i make patches for then? release27-maint and release31-maint?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9042>
_______________________________________

From report at bugs.python.org  Thu Sep 30 16:10:39 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 30 Sep 2010 14:10:39 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285855839.61.0.0532543607201.issue9980@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

On an older Celeron platform the differences are up to 7%, but again,
the number that is converted has a far greater impact:


None:
=====

>>> s = "str(38210.0)"
>>> t = timeit.Timer(stmt=s)
>>> 
>>> t.timeit(number=1000000)
3.277189016342163
>>> t.timeit(number=1000000)
3.293405055999756
>>> t.timeit(number=1000000)
3.302845001220703
>>> 
>>> s = "str(1.31232223e300)"
>>> t = timeit.Timer(stmt=s)
>>> 
>>> t.timeit(number=1000000)
5.678447008132935
>>> t.timeit(number=1000000)
5.695156097412109
>>> t.timeit(number=1000000)
5.690100193023682


fnstcw only:
============

>>> s = "str(38210.0)"
>>> t = timeit.Timer(stmt=s)
>>> 
>>> t.timeit(number=1000000)
3.3676700592041016
>>> t.timeit(number=1000000)
3.339860200881958
>>> t.timeit(number=1000000)
3.365180015563965
>>> 
>>> s = "str(1.31232223e300)"
>>> t = timeit.Timer(stmt=s)
>>> 
>>> t.timeit(number=1000000)
5.869584798812866
>>> t.timeit(number=1000000)
5.8620688915252686
>>> t.timeit(number=1000000)
5.882143020629883
>>> 


fnstcw/fldcw:
=============

>>> s = "str(38210.0)"
>>> t = timeit.Timer(stmt=s)
>>> 
>>> t.timeit(number=1000000)
3.5034677982330322
>>> t.timeit(number=1000000)
3.496767044067383
>>> t.timeit(number=1000000)
3.5118331909179688
>>> 
>>> s = "str(1.31232223e300)"
>>> t = timeit.Timer(stmt=s)
>>> 
>>> t.timeit(number=1000000)
5.808370113372803
>>> t.timeit(number=1000000)
5.80784010887146
>>> t.timeit(number=1000000)
5.837070941925049
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 16:21:01 2010
From: report at bugs.python.org (Tim Peters)
Date: Thu, 30 Sep 2010 14:21:01 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285856461.74.0.719978117876.issue9980@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

About thread state, the C standard is no help.  That's an OS decision.  All OSes I'm aware of do save/restore FPU state across thread switches.  Doesn't mean all OSes do, just that I don't know of an exception.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 16:37:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Sep 2010 14:37:47 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285857467.16.0.732449168085.issue9980@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> There's a configure-time check that works out whether resetting the
> precision is necessary;  if so, the precision is changed before each
> conversion and reverted again afterwards

How about doing the check in Py_Initialize() instead? Then it will work for embedders too.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 16:40:27 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Thu, 30 Sep 2010 14:40:27 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285857627.5.0.182056602228.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

>>For PyScripter, can you alter your Delphi layer to drop back to the >>normal default 53-bit precision before calling any Python stuff? 

Yes sure. That is how I traced the source of the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 16:45:10 2010
From: report at bugs.python.org (Jonathan Niehof)
Date: Thu, 30 Sep 2010 14:45:10 +0000
Subject: [issue9998] find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>


New submission from Jonathan Niehof <jniehof at lanl.gov>:

It's come up on occasion (#2936, http://osdir.com/ml/python.ctypes/2008-05/msg00046.html) that ctypes find_library doesn't search LD_LIBRARY_PATH for libraries, which is different behaviour from the runtime linker. The attached patch adds this search.

Unfortunately I can't conceive of a reasonable unit test for this (compiling a shared library in setUp seems a bit overkill.)

----------
assignee: theller
components: ctypes
files: ctypes_ld_lib_path.patch
keywords: patch
messages: 117738
nosy: jniehof, theller
priority: normal
severity: normal
status: open
title: find_library should search LD_LIBRARY_PATH on linux
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19068/ctypes_ld_lib_path.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Thu Sep 30 16:56:37 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Thu, 30 Sep 2010 14:56:37 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285858597.59.0.496258395483.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

>>How about doing the check in Py_Initialize() instead? Then it will >>work for embedders too.
It is not good practice for DLLs to change the FPU control word when loaded, because the host application may have set it to a specific value for a good reason.  Delphi provides a SafeLoadLibrary function that saves the the control word and restores it after loading the DLL.

If _Py_dg_dtoa can be made to work correctly independently of the value of the FPU control word that should be much better.  If this means setting and restoring the control word, then this sounds like a good way forward.

By the way the reason Delphi sets the precision to 64bits is that by design all floating calculations are done in 64 bit presision and then truncated back if needed.  A native 10 byte floating type called Extended is also provided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 16:56:53 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Thu, 30 Sep 2010 14:56:53 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285858613.54.0.908414668949.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

>>How about doing the check in Py_Initialize() instead? Then it will >>work for embedders too.
It is not good practice for DLLs to change the FPU control word when loaded, because the host application may have set it to a specific value for a good reason.  Delphi provides a SafeLoadLibrary function that saves the the control word and restores it after loading the DLL.

If _Py_dg_dtoa can be made to work correctly independently of the value of the FPU control word that should be much better.  If this means setting and restoring the control word, then this sounds like a good way forward.

By the way the reason Delphi sets the precision to 64bits is that by design all floating calculations are done in 64 bit presision and then truncated back if needed.  A native 10 byte floating type called Extended is also provided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Thu Sep 30 17:00:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Sep 2010 15:00:31 +0000
Subject: [issue9996] binascii should convert unicode strings
In-Reply-To: <1285848203.41.0.985893389249.issue9996@psf.upfronthosting.co.za>
Message-ID: <1285858831.21.0.323037171934.issue9996@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9996>
_______________________________________

From report at bugs.python.org  Thu Sep 30 17:12:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Sep 2010 15:12:44 +0000
Subject: [issue9996] binascii should convert unicode strings
In-Reply-To: <1285848203.41.0.985893389249.issue9996@psf.upfronthosting.co.za>
Message-ID: <1285859564.4.0.376223210086.issue9996@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Regardless of the various arguments, I think it is too late to break compatibility again, by disallowing bytes input, or changing the output type.
What we could do is allow str arguments to a2b_ functions, with the restriction that the argument must not contain non-ASCII characters.

(Please note that the "a" is for ASCII; otherwise it would be "u" for Unicode :-))

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9996>
_______________________________________

From report at bugs.python.org  Thu Sep 30 17:17:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 15:17:20 +0000
Subject: [issue9986] PDF files of python docs have text missing
In-Reply-To: <1285772054.59.0.857308007062.issue9986@psf.upfronthosting.co.za>
Message-ID: <1285859840.51.0.874876142535.issue9986@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It looks like this should be solved in Sphinx.  Can you report this on its tracker at Bitbucket?  Thanks.

----------
nosy: +eric.araujo, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9986>
_______________________________________

From report at bugs.python.org  Thu Sep 30 17:18:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 15:18:06 +0000
Subject: [issue9977] TestCase.assertItemsEqual's description of differences
In-Reply-To: <1285704922.32.0.659854668668.issue9977@psf.upfronthosting.co.za>
Message-ID: <1285859886.95.0.642412890746.issue9977@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/issue9977>
_______________________________________

From report at bugs.python.org  Thu Sep 30 17:29:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Sep 2010 15:29:10 +0000
Subject: [issue9999] test_shutil cross-file-system tests are fragile (may not
	test what they pruport to test)
In-Reply-To: <1285860550.74.0.246130427134.issue9999@psf.upfronthosting.co.za>
Message-ID: <1285860550.74.0.246130427134.issue9999@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

In investigating issue 9993, I noticed that test_shutil wants to test things that require cross-file-system links, and arranges to have such links by creating a files and directories in the cwd and using tempfile.  Presumably the hope (and the comments make it clear it is a hope) is that frequently these will be different filesystems.  This is likely to be true on some systems (principally those that put /tmp on a memory file system), there is no guarantee that it is true for any system in the buildbot fleet (for example).

In addition, relatively recent changes to regrtest ensure that when the tests are run for an installed Python, the cwd is *guaranteed* to be in the same file system as things created by tempfile, since in that case the tempfile module is used by regrtest to run all tests in a temporary cwd.

It is this latter case that most concerns me and prompts this bug report, since a distribution should be able to reasonably expect that running the tests after installation (either real or sandboxed) should in fact test python on the target system.

Unfortunately I don't currently have a suggestion for how to reliably create a cross-file-system link for testing purposes.

----------
components: Tests
messages: 117744
nosy: r.david.murray, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_shutil cross-file-system tests are fragile (may not test what they pruport to test)
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9999>
_______________________________________

From report at bugs.python.org  Thu Sep 30 17:39:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 30 Sep 2010 15:39:17 +0000
Subject: [issue9996] binascii should convert unicode strings
In-Reply-To: <1285848203.41.0.985893389249.issue9996@psf.upfronthosting.co.za>
Message-ID: <1285861157.3.0.925124384443.issue9996@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1 on this patch; I think any change must get consensus on python-dev first, and there is no point in resolving this in the bug tracker. If no agreement can be found (which is actually likely), a PEP needs to be written.

My personal favorite would be to a) leave the binascii module alone, and b) add more functions to the base64 module, taking and returning Unicode strings as encoded objects.

However, I really fail to see what's so bad about

  binascii.b2a_hex(B).decode('ascii')

Under the rule "not every two line function belongs into the standard library", I would then be -0 on adding it to base64.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9996>
_______________________________________

From report at bugs.python.org  Thu Sep 30 17:48:15 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Sep 2010 15:48:15 +0000
Subject: [issue10000] mark more tests as CPython specific
In-Reply-To: <1285861695.5.0.301447830736.issue10000@psf.upfronthosting.co.za>
Message-ID: <1285861695.5.0.301447830736.issue10000@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

When porting pypy to 2.7, we found that many tests actually exercise features specific to CPython, either the garbage collector, or the precise memory layout (__sizeof__).
They should be marked as such, and skipped when run with pypy.

----------
messages: 117746
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: mark more tests as CPython specific

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10000>
_______________________________________

From report at bugs.python.org  Thu Sep 30 17:57:04 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 30 Sep 2010 15:57:04 +0000
Subject: [issue6253] optparse.OptionParser.get_usage uses wrong formatter
In-Reply-To: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>
Message-ID: <1285862224.91.0.421624327971.issue6253@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello Jan,
I noticed this bug and I wondered: what's your opinion now?

Optparse is deprecated and it will be replaced by argparse, so I'm not sure it's "interesting" to introduce a new feature (the format_usage() method) but it might still be interesting to fix the previous behaviour.

So, are you still more inclined to add the new method or just correcting the harcoded formatter in get_usage() may be just fine?

If it's ok going on with the get_usage() fix, it's it just enough to:

    def get_usage(self, formatter=self.formatter):

and then just use 'formatter' (instead of checking if it's None, and then defaulting to self.formatter)? I didn't try this solution, so it might also be you've already tested and it's not working, just brain dumping :)

Regards,
Sandro

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6253>
_______________________________________

From report at bugs.python.org  Thu Sep 30 18:12:31 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 30 Sep 2010 16:12:31 +0000
Subject: [issue9994] Python becoming orphaned over ssh
In-Reply-To: <1285830097.12.0.730062200867.issue9994@psf.upfronthosting.co.za>
Message-ID: <1285863151.96.0.645751530521.issue9994@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

can i have you do another experiment here?

after you "ssh root at testbox /tmp/test.{py,sh}" can you:

1) login to testbox, run pstree -p
2) run an strace -p pid_of_python_or_bash >strace_for_foo.out  (for each of the test.py and test.sh processes)
3) interrupt both scripts with Ctrl-C
4) repeat the above 1..3 using a sleep.py that is simply a while True: time.sleep(1) loop.

and attach the strace output for each here?

I'm looking for differences in what happens with signals delivered and processed by each.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9994>
_______________________________________

From report at bugs.python.org  Thu Sep 30 18:14:57 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 30 Sep 2010 16:14:57 +0000
Subject: [issue9994] Python becoming orphaned over ssh
In-Reply-To: <1285830097.12.0.730062200867.issue9994@psf.upfronthosting.co.za>
Message-ID: <1285863297.3.0.457014634792.issue9994@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

fwiw http://mail.python.org/pipermail/python-list/2010-September/1256545.html

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9994>
_______________________________________

From report at bugs.python.org  Thu Sep 30 18:19:34 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 30 Sep 2010 16:19:34 +0000
Subject: [issue9994] Python becoming orphaned over ssh
In-Reply-To: <1285830097.12.0.730062200867.issue9994@psf.upfronthosting.co.za>
Message-ID: <1285863574.22.0.365525361374.issue9994@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Ah right, thanks.  I added a restore_signals=True argument to Popen in Python 3.2's subprocess module that does what you want:

http://docs.python.org/dev/library/subprocess.html

The way to emulate that in earlier versions is to use a preexec_fn to restore the signal handler for SIGPIPE to SIGDFL.

You can also use backport of 3.2's subprocess module available here: http://code.google.com/p/python-subprocess32/

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9994>
_______________________________________

From report at bugs.python.org  Thu Sep 30 18:27:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Sep 2010 16:27:48 +0000
Subject: [issue9993] shutil.move fails on symlink source
In-Reply-To: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>
Message-ID: <1285864068.88.0.712710902801.issue9993@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can confirm that the tests fail before the patch (but if an only if /tmp is a different file system from the one where the build is, see issue 9999) and pass after the patch.  The patch itself looks good to me and does accord better with how 'mv' works.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9993>
_______________________________________

From report at bugs.python.org  Thu Sep 30 18:37:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Sep 2010 16:37:09 +0000
Subject: [issue9996] binascii should convert unicode strings
In-Reply-To: <1285848203.41.0.985893389249.issue9996@psf.upfronthosting.co.za>
Message-ID: <1285864629.6.0.750145032949.issue9996@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9996>
_______________________________________

From report at bugs.python.org  Thu Sep 30 19:01:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Sep 2010 17:01:16 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285833787.36.0.596999547528.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285866068.3172.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hir Nir,

> BufferedIOBase is not documented to have peek():
> http://docs.python.org/dev/py3k/library/io.html

Ah, you're right.

> Small note about patch:
> 1) IOError string says "read() on write-only...", should be "peek() on write-only..." ?

Indeed.

> 2) Should be min() in self._read(max(self.max_read_chunk, n))

Actually, I think I should have reproduced the algorithm in read(),
where there's a read_size distinct from the size requested by the user.

Thanks for the review, it looks like I should have waited a bit before
committing :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9962>
_______________________________________

From report at bugs.python.org  Thu Sep 30 19:01:59 2010
From: report at bugs.python.org (Jonathan Niehof)
Date: Thu, 30 Sep 2010 17:01:59 +0000
Subject: [issue9999] test_shutil cross-file-system tests are fragile (may not
	test what they pruport to test)
In-Reply-To: <1285860550.74.0.246130427134.issue9999@psf.upfronthosting.co.za>
Message-ID: <1285866119.56.0.00897814598968.issue9999@psf.upfronthosting.co.za>


Jonathan Niehof <jniehof at lanl.gov> added the comment:

Might it make sense to skip-decorate those tests which require cross-filesystem? Put a test above the TestMove definition which compares tempfile.gettempdir() and os.path.dirname(__file__).

I don't know of an out-of-the-box function to see if two paths are on the same filesystem; I suppose one approach would be to walk up the directory tree of each, checking ismount. (Looks like somebody's tried it: http://stackoverflow.com/questions/1138383/python-get-mount-point-on-windows-or-linux)

----------
nosy: +jniehof

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9999>
_______________________________________

From report at bugs.python.org  Thu Sep 30 19:46:48 2010
From: report at bugs.python.org (Lenard Lindstrom)
Date: Thu, 30 Sep 2010 17:46:48 +0000
Subject: [issue10001] ~Py_buffer.obj field is undocumented, though not hidden
In-Reply-To: <1285868807.58.0.617972550499.issue10001@psf.upfronthosting.co.za>
Message-ID: <1285868807.58.0.617972550499.issue10001@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom <len-l at telus.net>:

Python 3.2a2+ (py3k:85072M, Sep 29 2010, 12:11:17) (from SVN)
[GCC 4.4.5 20100728 (prerelease)] on linux2 (Debian squeeze)

The ~Py_buffer.obj field is undocumented. Yet memoryview, that acts as a wrapper, includes the field in gc traversal. Also, if the field is not initialized by bf_getbuffer its value can be indeterminate. For memoryview the gc can crash (see attached C demo program).

----------
components: Interpreter Core
files: bufobj.c.gz
messages: 117754
nosy: kermode
priority: normal
severity: normal
status: open
title: ~Py_buffer.obj field is undocumented, though not hidden
versions: Python 3.2
Added file: http://bugs.python.org/file19069/bufobj.c.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10001>
_______________________________________

From report at bugs.python.org  Thu Sep 30 20:00:37 2010
From: report at bugs.python.org (Dan Uznanski)
Date: Thu, 30 Sep 2010 18:00:37 +0000
Subject: [issue9997] function named 'top' gets unexpected namespace/scope
	behaviour
In-Reply-To: <1285849061.79.0.383989167237.issue9997@psf.upfronthosting.co.za>
Message-ID: <1285869637.81.0.0701987532418.issue9997@psf.upfronthosting.co.za>


Changes by Dan Uznanski <duznanski at gmail.com>:


----------
nosy: +dan.uznanski

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9997>
_______________________________________

From report at bugs.python.org  Thu Sep 30 20:25:42 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 30 Sep 2010 18:25:42 +0000
Subject: [issue10000] mark more tests as CPython specific
In-Reply-To: <1285861695.5.0.301447830736.issue10000@psf.upfronthosting.co.za>
Message-ID: <1285871142.53.0.895215916008.issue10000@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This seems rather open-ended and all-encompassing. Wouldn't it be better to have individual issues for specific tests?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10000>
_______________________________________

From report at bugs.python.org  Thu Sep 30 20:29:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 18:29:38 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1285871378.29.0.030155115742.issue9042@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Antoine: Thanks for the correction.  I was mistaken about versions some months ago and wrote such misleading comments in a handful of bugs.  It has been corrected in some of them but not all.

v_peter: You don?t have to do anything, it?s the job of the committer to do the backport.  We use a tool (svnmerge) for that, so additional patches wouldn?t help.  If a backport is difficult, for example because of bytes/characters issues in 2.x, the committer may ask for help or feedback.

Sorry for the delay, I?ve been rather taken by the start of year and other bugs.  Be sure your fix will be in the next releases for all three branches.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9042>
_______________________________________

From report at bugs.python.org  Thu Sep 30 20:31:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 18:31:13 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1285871473.9.0.175046741013.issue9042@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(I?m not sure my last line is unambiguous.  I meant?: Don?t worry, this will get in shortly.)

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9042>
_______________________________________

From report at bugs.python.org  Thu Sep 30 20:36:44 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 30 Sep 2010 18:36:44 +0000
Subject: [issue9112] argparse missing documentation for error() method
In-Reply-To: <1277798810.6.0.529590004484.issue9112@psf.upfronthosting.co.za>
Message-ID: <1285871804.3.0.0874884182621.issue9112@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
attached a patch that adds the exiting methods (exit() and error()) to argparse documentation.

Regards,
Sandro

----------
keywords: +patch
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19070/issue9112-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9112>
_______________________________________

From report at bugs.python.org  Thu Sep 30 22:52:03 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 30 Sep 2010 20:52:03 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1285879923.18.0.829998217348.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I have a some code available for review here:

http://codereview.appspot.com/2340041/

I've actually gone down a farther path than I originally intended, but I do kind of like where this is heading.  It will allow me to install different Python builds of the same version without collision, at least when you use 'make altinstall'.  There are different versions even of python-config (with an added --abiflag option) so you can tell exactly what you're getting.

Note that 'make install' still adds all the symlinks so that you get a 'python3' and 'python3-config' as defaults.

Still broken are importing extensions.  E.g. if I do the following:

./configure --prefix=/tmp/python && make altinstall
./configure --prefix=/tmp/python --with-wide-unicode --with-pydebug && make altinstall
(cd some simple module with an extension)
/tmp/python/bin/python3.2dmu setup.py install
/tmp/python/bin/python3.2m
>>> import myextension

it tries to import the 3.2dmu version and fails.  I'm still investigating that, but in the meantime, please go to codereview and let me know what you think so far.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep 30 23:37:09 2010
From: report at bugs.python.org (joblack)
Date: Thu, 30 Sep 2010 21:37:09 +0000
Subject: [issue10002] Installer doesn't install on Windows Server 2008
	DataCenter R2
In-Reply-To: <1285882629.62.0.145594356076.issue10002@psf.upfronthosting.co.za>
Message-ID: <1285882629.62.0.145594356076.issue10002@psf.upfronthosting.co.za>


New submission from joblack <johannes.black at gmail.com>:

I tried to install the 32 Bit Python 2.7 Version (32 Bit version because of some 32 bit plugins) on a Windows Server 2008 DataCenter R2 and short at the end it throws the attached error message.

Have you tried your Python 2.7 on a Windows Server 2008 R2?

----------
components: Installation
files: python27bug.png
messages: 117760
nosy: joblack
priority: normal
severity: normal
status: open
title: Installer doesn't install on Windows Server 2008 DataCenter R2
versions: Python 2.7
Added file: http://bugs.python.org/file19071/python27bug.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10002>
_______________________________________

From report at bugs.python.org  Thu Sep 30 23:40:05 2010
From: report at bugs.python.org (joblack)
Date: Thu, 30 Sep 2010 21:40:05 +0000
Subject: [issue10002] Installer doesn't install on Windows Server 2008
	DataCenter R2
In-Reply-To: <1285882629.62.0.145594356076.issue10002@psf.upfronthosting.co.za>
Message-ID: <1285882805.79.0.926039484363.issue10002@psf.upfronthosting.co.za>


Changes by joblack <johannes.black at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10002>
_______________________________________

From report at bugs.python.org  Thu Sep 30 23:46:08 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 30 Sep 2010 21:46:08 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1285883168.96.0.645989365338.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

dmalcom and doko remind me that we need to handle the .so when --enable-shared is included

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep 30 23:50:06 2010
From: report at bugs.python.org (Yotam Medini)
Date: Thu, 30 Sep 2010 21:50:06 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1285883406.35.0.460129064114.issue670664@psf.upfronthosting.co.za>


Yotam Medini <yotam at users.sourceforge.net> added the comment:

The HTMLParser.py fails when inside 
  <script> ... </script>
it can fooled by JavaScript with less-than '<' conditional expressions.
In the attached example:

 $ tar tvzf lt-in-script-example.tgz | cut -c24-
     796 2010-09-30 16:52 h2t.py
   23678 2010-09-30 16:39 t.html

here's what happens:

 $ python h2t.py t.html /tmp/t.txt
 HTMLParser: /home/yotam/src/wog/HTMLParser.bug/HTMLParser.py
 Traceback (most recent call last):
   File "h2t.py", line 31, in <module>
     text = html2text(f_html.read())
   File "h2t.py", line 23, in html2text
     te = TextExtractor(html)
   File "h2t.py", line 15, in __init__
     self.feed(html)
   File "/home/yotam/src/wog/HTMLParser.bug/HTMLParser.py", line 108, in feed
     self.goahead(0)
   File "/home/yotam/src/wog/HTMLParser.bug/HTMLParser.py", line 148, in goahead
     k = self.parse_starttag(i)
   File "/home/yotam/src/wog/HTMLParser.bug/HTMLParser.py", line 229, in parse_starttag
     endpos = self.check_for_whole_start_tag(i)
   File "/home/yotam/src/wog/HTMLParser.bug/HTMLParser.py", line 304, in check_for_whole_start_tag
     self.error("malformed start tag")
   File "/home/yotam/src/wog/HTMLParser.bug/HTMLParser.py", line 115, in error
     raise HTMLParseError(message, self.getpos())
 HTMLParser.HTMLParseError: malformed start tag, at line 396, column 332


I have a suggested patch 
   HTMLParser.diff
fixing this problem, soon to be attached.

-- yotam

----------
nosy: +yotam
Added file: http://bugs.python.org/file19072/lt-in-script-example.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Thu Sep 30 23:52:29 2010
From: report at bugs.python.org (Yotam Medini)
Date: Thu, 30 Sep 2010 21:52:29 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1285883549.08.0.622421226336.issue670664@psf.upfronthosting.co.za>


Yotam Medini <yotam at users.sourceforge.net> added the comment:

The attached suggested patch fixes the problems shown in msg117762.

----------
Added file: http://bugs.python.org/file19073/HTMLParser.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Thu Sep 30 23:54:02 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 30 Sep 2010 21:54:02 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1285883642.36.0.629178518519.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

<doko> so -Wl,-h <soname> is what counts  [17:48]
<doko> barry: and it would be good to have this soname available in this new module too  [17:49]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________